Hi Amadeusz, Cezary Thank you for your feedback. > > I would like to understand the problem here, before I start to discuss > > potential solutions. You seem to be saying that there is some kind of > > card<->component connection limitation? Is there specific use case you > > have in mind? > > > > Personally I don't see a reason for connecting component to multiple > > cards. Even if it would be possible it soon becomes problematic when you > > for example try to decide which card controls clock on component. As > > I've wrote I would like to first see some use case definition, before > > jumping into a rewrite. Sorry, my head was biased. I thought people are thinking same things as me. In my case, my CPU Component has many channels. We have "basic board" which has simple sound system, it is using CPU ch0 for example. And customer can expand it by using "expansion board", it can use CPU ch1 or later channels. +-- basic board --------+ |+--------+ | || CPU ch0| <--> CodecA | || ch1| <-+ | |+--------+ | | +-------------|---------+ +-- expansion board ----+ | | | | +-> CodecB| +-----------------------+ Both sounds are using same CPU Component, but different Codecs. I'm not sure how to count the Card, but "basic board sound" is 1st card, "expansion board sound" is 2nd card for us in intuitively. But, because we can't use same Component (= CPU) to different Cards, we need to merge both sound into one Card. We can do that, but not intuitively, and needs overwrite settings. About Power, our CPU don't have DAPM, and Power itself is controlled via PM-runtime, so we don't have worry about multi card case. About Clock, our CPU clock is controlled by DAI base (= not Component base), and no loopbacks. So at least our case, having multi Card connection for CPU Component has no problem, and is useful (At least someone had been doing it by removing the limitation locally). I had thought similar things are happening. Yes, "my case" is not same as "any cases". It's impossible to make "perfect" one from the beginning, so I thought start from small, and expand step-by-step (= complex Power/Clock). My suggestion was for first step. > Thanks for your input Kuninori! Some questions first though :) On top of > what Amadeo already highlighted, I'd like to understand what do the > below three mean: > > >> - fixed playback vs capture > >> - fixed CPU vs Codec > >> - DPCM connection vs normal connection > > Especially the first two - what does 'fixed' stand here for? Oops, sorry to my lack of explanation. About 1st one (= playback vs capture), Current ASoC is assuming it has both playback and capture, but sometimes it is playback only or capture only. We are handling it, but I think it can be more flexible (or we can have multi playbacks or multi capture ? I'm not sure). And/or in Codec2Codec case, this naming is confusable. >From HW point of view, Transmit/Receive is more understandable ? Similar things happen on 2nd one case (= CPU vs Codec). ASoC is assuming it has both CPU and Codec. I think we can handle it more flexible. Codec2Codec is good sample. And topic is back and forth, but if we can handle "normal connection" as one of "DPCM connection", we don't need to have both CPU vs Codec, because no one want to have "dummuy CPU" or "dummuy Codec". Thank you for your help !! Best regards --- Kuninori Morimoto
