[alsa-devel] [PATCHv4 1/4] dt-bindings: sound: add motorola, cpcap-audio-codec

[Sebastian Reichel]

Hi,

On Fri, Feb 16, 2018 at 03:16:09PM +0000, Mark Brown wrote:
> On Fri, Feb 16, 2018 at 03:12:37PM +0100, Sebastian Reichel wrote:
> > 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:
> 
> > > > 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
> 
> You still need to say which DAIs exist on the device and how they are
> identified - if there's only one DAI it's obviously easy but if a device
> has multiple DAIs then there's some naming to do.

Ok, I will add some more description of the codec's capabilities.

> > > ...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?
> 
> It's not just other operating systems, it's also other versions of
> Linux we have to think about here. The most obvious issue with audio is
> the clocking where the division between ASoC and clock APIs is not super
> obvious and could easily change in the future.

Which does not change my argument. Other handling in Linux is
basically equal to other operating system. We don't loose anything
by having a compatible available.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20180216/5acb819b/attachment.sig>