On 6/30/2020 4:31 PM, Mark Brown wrote:
On Tue, Jun 30, 2020 at 01:22:29PM +0530, Sameer Pujar wrote:
Yes there are complex use cases, but if we look at the amount of changes
required in simple-card driver that is not too much. Existing binding for
simple-card driver would still work fine for our cases. Yes there are some
deviations and we don't want to break existing users, that is why a *new*
compatible was introduced and specific items can be pushed under it.
Majority of the simple-card driver is getting re-used here. We just need to
make sure it does not affect anyone else.
Why simple-card and not audio-graph-card?
Frankly speaking I have not used audio-graph-card before. I had a brief
look at the related binding. It seems it can use similar DT properties
that simple-card uses, although the binding style appears to be
different. However I am not sure if it offers better solutions to the
problems I am facing. For example, the ability to connect or form a
chain of components to realize more complicated use cases with DPCM,
some of which were discussed in [0]. Can you please help me understand
why it could be preferred?
[0] https://lkml.org/lkml/2020/4/30/519
Using fe/be instead of cpu/codec is easy to understand.
I guess you are referring to DT binding part. The parsing code specifically
looks for "codec" sub node and thus present conventions had to be used.
Remember that this stuff gets fixed into the ABI so we'd have to live
with this for ever.
