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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 03/01/16 18:16, Jean-Francois Moine wrote:
On Tue, 1 Mar 2016 17:51:09 +0200
Jyri Sarha <jsarha@xxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux