[PATCH RFC v2 05/11] ASoC: dt-bindings: amlogic: add schema for audin-formatter and audin-toddr

[Valerio Setti]

On 4/23/26 15:17, Krzysztof Kozlowski wrote:

>>>> Then the question might be: why not merging this together with
>>>> audin-fifo? Becuase these are 3 indipendent instances from the interface
>>>> and each of which can receive data from the interface. Each of them has
>>>> its own registers range (and optionally also an interrupt - which is not
>>>
>>> 4 bytes is not "registers range". It is one register of someone else's
>>> range.
>>
>> Yes, exactly like the AXG family which had an "audio bus" with reg and
>> ranges property of length 0x2000, like you are describing, and a
>> collection of smaller devices with very specific and targeted functions,
>> using the range in question.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-axg.dtsi?h=v6.8#n1317
>>
>> The registers length of devices in this examples are in then 0x10 to
>> 0x40 length. I honestly do not see the fundamental difference between 1
>> and 10 regs to define what is a device and what is not.
> 
> And that example above is probably also not right if you only looked at
> register range, but the difference is that you have distinctive other
> resource - clocks.
> 
> And just to remind the old antipattern - each clock is also a "separate"
> device and there is even old SoC architecture which did it. One clock
> per device node. Since some years this is not allowed.
> 
> This device has no other distinctive resources. Only 4 bytes wide IO
> range. So let me a bit clarify my previous statements:
>
> A device having only one resource - four bytes MMIO range - and nothing
> else, and being tightly coupled with other devices, almost certainly is
> not separate enough to be called a separate device node.

Wait, I re-checked the manual of this SoC and I realized that I missed a 
reset line for this formatter device. Sorry for that.
Also I was probably too conservative for the MMIO range because I 
limited it to cover only the features that I'm using in the driver. 
However I can extend it further to cover all formatting related 
registers: they are not used for now in the driver but they might be in 
the future.
This should overcome the above mentioned limitations and qualify the 
formatter as a standalone device, right?

-- 
Valerio