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.