Re: [alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Lars, Mark

My previous mail was missing point...

> > > In my opinion the flags are just as much a hack as the pointer. In an ideal
> > > setup the component does not need to know what type it is. The reason why we
> > > need this in ASoC is because the framework has grown over time and we need
> > > to support legacy code.
> > 
> > Yes, the pointer is essentially already a flag - having a separate flag
> > really doesn't add a huge amount here.  What we need to do is get rid of
> > the need for the flag entirely.
> 
> I can agree to remove flag entirely, and actually it is my final target.
> But we need many steps for it IMO.
> 
> I would like to cleanup (= remove random pointer) as 1st step.
> My 1st concern is that each struct which want to have codec pointer has
> codec pointer randomly.
> And it makes component cleanup difficult IMO.
> 
> 2nd concern is rtd has *codec, *platform, and *dai (for cpu/codec).
> These are different type of pointer.
> If platform can have dummy *dai, we can do like below ?
> 
> 	struct snd_soc_pcm_runtime {
> 		...
> 		struct snd_soc_dai *cpu;
> 		struct snd_soc_dai *codec;
> 		struct snd_soc_dai *platform;
> 		...
> 	}
> 
> Here, we can get original *codec or *platform by
> using component_to_xxx, because dai already have *component;
> It can be more cleanup ?

I mean current ALSA SoC has duplicate pointer,
and using different type of pointer for CPU/Codec/Platform/Card.
I agree that we would like to have flag-less style.

If my understanding was correct, we can more cleanup struct
relationship if we can exchange pointer style.
I think this is related to flag-less style.

For example, current rtd <-> CPU/Codec/Platform relationship
is using different type of pointer.
It makes flag-less style difficult.
But we can use same type of pointer if we can have dummy dai on platform,
like above idea. Similar idea is for component.

I think this kind of cleanup is needed, and it makes hotplug support easier.
Otherwise, hotplug support will add more random pointer on each struct,
and it makes cleanup more difficult.

# Here, I said "flag-less" style, but maybe we need flag somehow to keep
# current style ? For example I don't think we can have flag-less cristal-clear
# style for CODEC-CODEC support or DPCM etc ...



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux