lkml.org 
[lkml]   [2018]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv4 1/4] dt-bindings: sound: add motorola,cpcap-audio-codec
    Hi,

    On Fri, Feb 16, 2018 at 01:44:48PM +0000, Mark Brown wrote:
    > On Fri, Feb 16, 2018 at 02:25:38PM +0100, Sebastian Reichel wrote:
    > > On Fri, Feb 16, 2018 at 11:30:08AM +0000, Mark Brown wrote:
    >
    > > > Why are we adding a separate DT node with no content for this? This is
    > > > a single chip, we already know that the CODEC part is there from the DT
    > > > telling us that the chip is there and what we decide is part of the
    > > > CODEC is going to depend on what the OS running on the system is doing.
    >
    > > While it looks empty in the DT binding file, it's actually not empty
    > > once some standard properties are added to support audio-graph-card.
    >
    > This tells me you're missing something in the binding defining the
    > DAIs and...

    Well it is described by the following document:

    Documentation/devicetree/bindings/sound/audio-graph-card.txt

    Previous revision of the codec also worked perfectly fine
    with the simple card binding, which does the DAI stuff
    differently:

    Documentation/devicetree/bindings/sound/simple-card.txt

    A quick check of the other codecs suggested, that none of them
    descibes the graph based binding style. AFAIUI they could be
    used with it, though. So if you have a suggestion for a better
    binding document I can adopt this in the next version.

    > > A real world example looks like this:
    >
    > > &cpcap {
    > > audio-codec {
    > > compatible = "motorola,cpcap-audio-codec";
    > > #sound-dai-cells = <1>;
    >
    > ...that still doesn't require a compatible here.

    I agree, that it's not required. Also the node is not required.
    Everything could be dumped into the main node. Many things are
    not required, but they make implementations easier and help in
    regards to DT readability and consistency. Having the compatible
    means, that all sub-functions _can_ be handled equally by the
    operating system. Not having the compatible means you _always_
    need special handling for the audio codec. This basically makes
    the codec node different for the simple purpose of "because it is
    not strictly required". If we have a compatible node, other
    operating systems can still decide to ignore it, right?

    -- Sebastian
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2018-02-16 15:13    [W:4.705 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site