Re: 'modern dailink' transition

Re: 'modern dailink' transition

[Kuninori Morimoto]

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

Re: 'modern dailink' transition

[Kuninori Morimoto]

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

Re: 'modern dailink' transition

[Mark Brown]

[-- 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 --]

Re: 'modern dailink' transition

[Kuninori Morimoto]

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

Re: 'modern dailink' transition

[Kuninori Morimoto]

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

Re: 'modern dailink' transition

[Pierre-Louis Bossart]

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

Re: 'modern dailink' transition

[Kuninori Morimoto]

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