Messages in this thread | | | Subject | Re: [PATCH v4 12/23] ASoC: simple-card: Support DPCM DAI link with multiple Codecs | From | Sameer Pujar <> | Date | Tue, 30 Jun 2020 13:22:29 +0530 |
| |
On 6/30/2020 12:25 PM, Kuninori Morimoto wrote: > External email: Use caution opening links or attachments > > > 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 > >>> I'm not sure, this is just my guess. >>> I'm happy if we can support it more easily :) >> Right now I am trying re-use simple-card driver as much as possible >> 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, >>> we/you need to have new one. >> Patch 17/23 and 18/23 introduce new compatible >> '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? > This seems very complex system for current simple-card. > "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. 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.
> > Using cpu@0 node for BE is the 1st confusable point for me. Don't we use the same methodology for CODEC<->CODEC link and still describe the DAI link with 'cpu@0' and 'codec@0'?
> 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
| |