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

[Jerome Brunet <jbrunet@baylibre.com>]

On jeu. 23 avril 2026 at 11:42, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 16/04/2026 23:51, Valerio Setti wrote:
>> Hi,
>> 
>> thanks for your review and the feedbacks.
>> 
>>>> +examples:
>>>> +  - |
>>>> +    audio-controller@a040 {
>>>> +      compatible = "amlogic,meson-gxbb-audin-decoder-i2s",
>>>> +                   "amlogic,meson-gx-audin-decoder-i2s";
>>>> +      #sound-dai-cells = <0>;
>>>> +      sound-name-prefix = "AUDIN I2S Decoder";
>>>> +      reg = <0xa040 0x4>;
>>>
>>> One register-wide block? I have doubts this is a separate device
>> 
>> I understand that this might look as weird configuration, so please let 
>> me explain what's going on here.
>> 
>> In this SoC the audio part is split into 2 blocks: AIU for the audio 
>> output (already supported in the kernel) and AUDIN for the input (which 
>> is what I'm trying to add with this patch series). Unfortunately from 
>> the clock management point of view the two of them are not indipendent 
>> and interface clocks are in AIU register range. Moreover the two systems 
>
> Two devices of one-register-interface having mixed clock management is a
> CLEAR sign these are one device.

That's clear sign they belong to the same subsystem, nodoby has hidden
the fact there is a subsystem called "audin", which provide a collection
of devices.

>
>> are not in a continguous memory range, so creating a single audio 
>> component that implements both is not feasible (unless we want to add 
>> some dirty tricks with multiple regmaps, etc).
>
> OK, but then what is between these? Again, register ranges ARE NOT
> 4-bytes wide on a SoC. On several SoCs they are aligned per page or
> 0x1000 or more. I have no clue how it is here, but 4 bytes is just plain
> warning sign.

On several SoC, more than 0x1000 ?? This is quite an arbitrary limit you are
setting here. There is vast number of valid devices in the linux kernel or
the bindings than have way less registers than that. We even have
devices with no register at all.

I agree that SoC buses are usually at least that long, those are a
class of devices, that is certainly not the case for *all* devices.

A device is something that has defined inputs, outputs and function
and that can possibly be replicated for more instances.

>
>> This is where the AXG design comes into play: we use the backend DAI 
>> provided from AIU for both playback and capture and then we attach 
>> formatters (i.e. the audin-decoder-i2s we're discussing about) to 
>> properly format the data.
>> This explains why this is a relatively simple device with very few (1) 
>> register. To be noted that for example also similar component on the AXG 
>> platform (axg-tdmin.c) claims to have a larger register range, but in 
>> fact is almost entirely using the 1st register with only 2 occurences 
>> for the 2nd and 3rd. IMHO this is not that different from what I'm 
>> trying to achieve in this series for the GX platform.
>> Also looking at the implementation of "audin-decoder-i2s.c", even though 
>> it uses a single register, it really provides functionalities i.e. it's 
>> not a useless device and it can also be expanded in the future to 
>> support 24-bit sample format.
>
> I understand it is not useless. I claim this is writing bindings per
> driver. I claim this is not a correct representation of hardware,
> because hardware is not a device with 4 bytes of address space.

This has nothing to do with driver consideration but proper abstraction
of the HW tends to produce cleaner architecture, yes.

>
>> 
>> 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.

>
>
> Best regards,
> Krzysztof
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

-- 
Jerome

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic