* Re: 'modern dailink' transition [not found] ` <87ftrbivbr.wl-kuninori.morimoto.gx@renesas.com> @ 2019-03-25 3:19 ` Kuninori Morimoto 2019-03-26 1:20 ` Kuninori Morimoto 2019-03-26 14:20 ` Mark Brown 1 sibling, 1 reply; 7+ messages in thread From: Kuninori Morimoto @ 2019-03-25 3:19 UTC (permalink / raw) To: Mark Brown, Pierre-Louis Bossart; +Cc: alsa-devel Oops ?? I exchanged mail address - alsa-devel@alsa-devel.org + alsa-devel@alsa-project.org > Hi Pierre, Mark > > > > I am however struggling with the notion of a 'snd-soc-dummy' platform that > > > exists in some legacy Intel machine drivers. I changed the code following > > > the pattern below but I have really no idea if this is correct. Shouldn't > > > all dailinks either point to a real platform driver or not provide any > > > information about the platform at all? Is there any specific expectation on > > > the ASoC side here? > > I guess my posted "no Platform" and "no implicit snd-soc-dummy" patch idea > confused you. If so, I'm so sorry about that. > I'm not sure this idea is Good or Bad. > > > I'd expect the dummy driver to just get automatically substituted when > > required, I'd not expect users to explicitly list it. > > Yes agree. > > This is my understanding, please correct me if I was wrong. > I think current many sound card which doesn't need "platfrom" are 2 patterns. > > 1) select snd-soc-dummy as platfrom > 2) select cpu component as platfrom > > Current ASoC selects 1) automatically if .platfrom_name was NULL. > And driver needs to have below if it want to be 2) > > dai_link->platform_of_node = dai_link->cpu_of_node > > But, I think one of them is enough ? > I mean select 2) automatically can be OK? > In other words, current some sound card which doesn't need > platfrom is calling snd-soc-dummy platfrom method in 1) case. > But, is it needed ? I'm not sure... > > It seems snd-soc-dummy platfrom is caring about DPCM-BE case, > but, I think CPU is snd-soc-dummy in such case. > Maybe we need same cade to dummy CPU (?), but *my* DPCM system > is working correctly without it. > > Best regards > --- > Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'modern dailink' transition 2019-03-25 3:19 ` 'modern dailink' transition Kuninori Morimoto @ 2019-03-26 1:20 ` Kuninori Morimoto 0 siblings, 0 replies; 7+ messages in thread From: Kuninori Morimoto @ 2019-03-26 1:20 UTC (permalink / raw) To: Pierre-Louis Bossart; +Cc: alsa-devel, Mark Brown Hi Pierre-Louis again > > > > I am however struggling with the notion of a 'snd-soc-dummy' platform that > > > > exists in some legacy Intel machine drivers. I changed the code following > > > > the pattern below but I have really no idea if this is correct. Shouldn't > > > > all dailinks either point to a real platform driver or not provide any > > > > information about the platform at all? Is there any specific expectation on > > > > the ASoC side here? > > > > I guess my posted "no Platform" and "no implicit snd-soc-dummy" patch idea > > confused you. If so, I'm so sorry about that. > > I'm not sure this idea is Good or Bad. > > > > > I'd expect the dummy driver to just get automatically substituted when > > > required, I'd not expect users to explicitly list it. > > > > Yes agree. > > > > This is my understanding, please correct me if I was wrong. > > I think current many sound card which doesn't need "platfrom" are 2 patterns. > > > > 1) select snd-soc-dummy as platfrom > > 2) select cpu component as platfrom > > > > Current ASoC selects 1) automatically if .platfrom_name was NULL. > > And driver needs to have below if it want to be 2) > > > > dai_link->platform_of_node = dai_link->cpu_of_node > > > > But, I think one of them is enough ? > > I mean select 2) automatically can be OK? > > In other words, current some sound card which doesn't need > > platfrom is calling snd-soc-dummy platfrom method in 1) case. > > But, is it needed ? I'm not sure... > > > > It seems snd-soc-dummy platfrom is caring about DPCM-BE case, > > but, I think CPU is snd-soc-dummy in such case. > > Maybe we need same cade to dummy CPU (?), but *my* DPCM system > > is working correctly without it. I want to tell here is that, if above idea works well, sound driver will not need to think about platfrom any more if it doesn't need platfrom. But, to avoid extra confuse/trouble, I think keeping current existing snd-soc-dummy platform settings (at legacy Intel machine driver ?) is safety plan. But what do you think ? Best regards --- Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'modern dailink' transition [not found] ` <87ftrbivbr.wl-kuninori.morimoto.gx@renesas.com> 2019-03-25 3:19 ` 'modern dailink' transition Kuninori Morimoto @ 2019-03-26 14:20 ` Mark Brown 2019-03-27 23:47 ` Kuninori Morimoto 1 sibling, 1 reply; 7+ messages in thread From: Mark Brown @ 2019-03-26 14:20 UTC (permalink / raw) To: Kuninori Morimoto; +Cc: alsa-devel, Pierre-Louis Bossart [-- Attachment #1.1: Type: text/plain, Size: 1186 bytes --] On Mon, Mar 25, 2019 at 10:54:52AM +0900, Kuninori Morimoto wrote: > This is my understanding, please correct me if I was wrong. > I think current many sound card which doesn't need "platfrom" are 2 patterns. > 1) select snd-soc-dummy as platfrom > 2) select cpu component as platfrom > Current ASoC selects 1) automatically if .platfrom_name was NULL. > And driver needs to have below if it want to be 2) > dai_link->platform_of_node = dai_link->cpu_of_node > But, I think one of them is enough ? > I mean select 2) automatically can be OK? > In other words, current some sound card which doesn't need > platfrom is calling snd-soc-dummy platfrom method in 1) case. > But, is it needed ? I'm not sure... > It seems snd-soc-dummy platfrom is caring about DPCM-BE case, > but, I think CPU is snd-soc-dummy in such case. > Maybe we need same cade to dummy CPU (?), but *my* DPCM system > is working correctly without it. It *should* work without it. If it actually does work is a separate question - that code is a bit fragile so there may be some problems. Since the most complicated user of DPCM is x86 I think if a change to this stuff tests out well there it should be OK. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'modern dailink' transition 2019-03-26 14:20 ` Mark Brown @ 2019-03-27 23:47 ` Kuninori Morimoto 2019-04-05 0:31 ` Kuninori Morimoto 0 siblings, 1 reply; 7+ messages in thread From: Kuninori Morimoto @ 2019-03-27 23:47 UTC (permalink / raw) To: Mark Brown; +Cc: alsa-devel, Pierre-Louis Bossart Hi Mark, Pierre-Louis > > 1) select snd-soc-dummy as platfrom > > 2) select cpu component as platfrom (snip) > > It seems snd-soc-dummy platfrom is caring about DPCM-BE case, > > but, I think CPU is snd-soc-dummy in such case. > > Maybe we need same cade to dummy CPU (?), but *my* DPCM system > > is working correctly without it. > > It *should* work without it. If it actually does work is a separate > question - that code is a bit fragile so there may be some problems. > Since the most complicated user of DPCM is x86 I think if a change to > this stuff tests out well there it should be OK. OK, nice to know. Thank you Best regards --- Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'modern dailink' transition 2019-03-27 23:47 ` Kuninori Morimoto @ 2019-04-05 0:31 ` Kuninori Morimoto 2019-04-05 12:53 ` Pierre-Louis Bossart 0 siblings, 1 reply; 7+ messages in thread From: Kuninori Morimoto @ 2019-04-05 0:31 UTC (permalink / raw) To: Pierre-Louis Bossart; +Cc: alsa-devel, Mark Brown Hi Pierre-Louis Cc: Mark > > > 1) select snd-soc-dummy as platfrom > > > 2) select cpu component as platfrom > (snip) > > > It seems snd-soc-dummy platfrom is caring about DPCM-BE case, > > > but, I think CPU is snd-soc-dummy in such case. > > > Maybe we need same cade to dummy CPU (?), but *my* DPCM system > > > is working correctly without it. > > > > It *should* work without it. If it actually does work is a separate > > question - that code is a bit fragile so there may be some problems. > > Since the most complicated user of DPCM is x86 I think if a change to > > this stuff tests out well there it should be OK. I want to ask you about "Multi CPU" support. When you can post it ? I'm asking because I'm waiting it for a long term, and "switch to modern style" is based on it. But, v3 is not yet posted, right ? If you can post it soon, I can keep waiting. But, if it will takes more long term, can I suggest ? I think there is few conflict around soc.h and soc-core.c between this suggestion and your patch, but not super much. 1. I will post "modern style CPU" support, it is still "single CPU" 2. All sound card switch to "modern style" 3. remove "legacy style" I think, your "Multi CPU" support can be implemented on top of it. And, I can continue, like this 4. post "allow no Platfrom" 5. remove "snd-soc-dummy Platfrom", and "CPU = Platfrom" code from Intel card as trial. If it was OK, continue for all card. I want to know your plan/opinion. Thank you for your help Best regards --- Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'modern dailink' transition 2019-04-05 0:31 ` Kuninori Morimoto @ 2019-04-05 12:53 ` Pierre-Louis Bossart 2019-04-08 1:08 ` Kuninori Morimoto 0 siblings, 1 reply; 7+ messages in thread From: Pierre-Louis Bossart @ 2019-04-05 12:53 UTC (permalink / raw) To: Kuninori Morimoto; +Cc: alsa-devel, Mark Brown Hi Morimoto-san, > I want to ask you about "Multi CPU" support. > When you can post it ? > I'm asking because I'm waiting it for a long term, > and "switch to modern style" is based on it. > But, v3 is not yet posted, right ? the multi-cpu part is required for SoundWire, but the directions taken to support multi-cpu are changing due to additional developments in the MIPI Software WG (contributors only at this point). So the plan for now is to develop with single cpu-dai first, and add multi-cpu support at a later stage. In other words, the multi-cpu/multi-link part isn't the most urgent priority and it shouldn't impact your work. > > If you can post it soon, I can keep waiting. > But, if it will takes more long term, can I suggest ? > I think there is few conflict around soc.h and soc-core.c > between this suggestion and your patch, but not super much. > > 1. I will post "modern style CPU" support, > it is still "single CPU" > 2. All sound card switch to "modern style" > 3. remove "legacy style" > > I think, your "Multi CPU" support can be implemented > on top of it. yes that's fine, this plan works fine for me. > And, I can continue, like this > > 4. post "allow no Platfrom" > 5. remove "snd-soc-dummy Platfrom", > and "CPU = Platfrom" code from Intel card > as trial. If it was OK, continue for all card. there are only 2 or 3 cases of this snd-soc-dummy platform and I'll try to remove it as part of the first batch. I don't think it's necessary at all. Thanks! -Pierre ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 'modern dailink' transition 2019-04-05 12:53 ` Pierre-Louis Bossart @ 2019-04-08 1:08 ` Kuninori Morimoto 0 siblings, 0 replies; 7+ messages in thread From: Kuninori Morimoto @ 2019-04-08 1:08 UTC (permalink / raw) To: Pierre-Louis Bossart; +Cc: alsa-devel, Mark Brown Hi Pierre-Louis Thank you for your feedback > > 1. I will post "modern style CPU" support, > > it is still "single CPU" > > 2. All sound card switch to "modern style" > > 3. remove "legacy style" > > > > I think, your "Multi CPU" support can be implemented > > on top of it. > > yes that's fine, this plan works fine for me. > > > And, I can continue, like this > > > > 4. post "allow no Platfrom" > > 5. remove "snd-soc-dummy Platfrom", > > and "CPU = Platfrom" code from Intel card > > as trial. If it was OK, continue for all card. > > there are only 2 or 3 cases of this snd-soc-dummy platform and I'll > try to remove it as part of the first batch. I don't think it's > necessary at all. Thank you for sharing plan ! OK, I will work for 1, 2, 3 plan from now. Best regards --- Kuninori Morimoto ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-04-08 1:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <21d1e439-7ecd-dd6a-9a43-e66e8db1ac85@linux.intel.com> [not found] ` <20190321141242.GE5684@sirena.org.uk> [not found] ` <87ftrbivbr.wl-kuninori.morimoto.gx@renesas.com> 2019-03-25 3:19 ` 'modern dailink' transition Kuninori Morimoto 2019-03-26 1:20 ` Kuninori Morimoto 2019-03-26 14:20 ` Mark Brown 2019-03-27 23:47 ` Kuninori Morimoto 2019-04-05 0:31 ` Kuninori Morimoto 2019-04-05 12:53 ` Pierre-Louis Bossart 2019-04-08 1:08 ` Kuninori Morimoto
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.