External email: Use caution opening links or attachmentsYes 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.
Hi Sameer
Thank you for explaining detail at off-list mail.
Your issue happen on (C) case, and you are tring to solve it.
It is easy to understand if it was indicated at log area.
I have imagined other system from "multiple CPU/Codec support".
(A) (B)
FE <-> BE
(C) (D)
BE <-> BE
This seems very complex system for current simple-card.I'm not sure, this is just my guess.Right now I am trying re-use simple-card driver as much as possible
I'm happy if we can support it more easily :)
and still make it work for flexible sound cards. I will be happy to
discuss and improve the patch wherever necessary. Please help me
understand which part you think looks to be hacky.
But, if it was difficult to keep compatibility on simple-card,Patch 17/23 and 18/23 introduce new compatible
we/you need to have new one.
'simple-cc-audio-card'. Idea was to use component chaining which
allows connection of FE<->BE and multiple BE<->BE components along the
DAPM path (patch 16/23). Do you think it would be fine?
"concept" of simple-card is simple (but "code" is not so simple...)
Because of it, it doesn't assume flexible connection.
Maybe your patch works for you, but might breaks other systems.
Or, makes code or DT settings more complex/ununderstandable.
Not sure, but my guess.
Don't we use the same methodology for CODEC<->CODEC link and still describe the DAI link with 'cpu@0' and 'codec@0'?
Using cpu@0 node for BE is the 1st confusable point for me.
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.
Thank you for your help !!
Best regards
---
Kuninori Morimoto