Alternative binding proposal for tda998x audio (Was: Re: [PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports)

[Jyri Sarha]

On 03/01/16 18:16, Jean-Francois Moine wrote:
> On Tue, 1 Mar 2016 17:51:09 +0200
> Jyri Sarha <jsarha at ti.com> wrote:
>
>> I know that it works, I have used it myself until now, but it is not
>> needed and there is no driver that parses audio port endpoints. I see no
>> point specifying something in the binding that is not used and there no
>> specific plan to ever use it.
>>
>> AFAIU my proposed binding should work equally well with simple-card,
>> with or without multi-codec support.
>
> As told many times, the simple card is a pure Linux specific entity.
> It does not describe any hardware. It should not appear in a DT, or,
> if it does, its compatible should be "linux, simple-audio-card".
> Then, how can the other OSs know the links between the audio
> devices and the audio encoders/connectors?
>

I understand the short comings of simple-card and it's binding. However, 
the binding is documented and it is feasible to extract the audio 
connections from a simple-card binding too. In fact it models the I2S 
connections better than straight out of the box graph binding. Actually 
a graph is not the best way describe an i2s-bus with multiple DAIs 
(codec or CPU) connected to it.

> On the other way, the audio graph does not impose any particular
> software design. It just describes the links between the different
> hardware components and each OS is free to implement its own layout.
>

That is true. In the most narrow sense the i2s protocol details, or even 
TDM time-slot selections should not be in the dtb. However, is not 
feasible to write a generic machine driver that would deduce the ideal 
audio configuration just based on the i2s wiring between the audio 
components simply because that is not enough information*. So to put it 
simply the simple-card is not the perfect solution for the problem, but 
even with its flaws it is better than straight out of the box graph 
binding, and it is still entirely feasible to extract all needed 
information for any audio implementation from that binding.

Still even with my proposed binding there is nothing that prevents 
adding the graph binding on top of that if it is ever needed.

Best regards,
Jyri

* With a complete set of information of all audio wiring and component 
capabilities, including the analog only components, it would probably be 
possible to deduce a generic configuration that would work in the most 
common - simple cases, but let's not go there now.