[alsa-devel] [RFC PATCH] ALSA: split params refinement to seperated file

[Jie, Yang]

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Monday, June 08, 2015 5:21 PM
> To: Jie, Yang
> Cc: Mark Brown; alsa-devel at alsa-project.org; Girdwood, Liam R; Zhang,
> Vivian
> Subject: Re: [RFC PATCH] ALSA: split params refinement to seperated file
> 
> At Mon, 8 Jun 2015 07:35:17 +0000,
> Jie, Yang wrote:
> >
> > > -----Original Message-----
> > > From: Mark Brown [mailto:broonie at kernel.org]
> > > Sent: Friday, June 05, 2015 3:16 AM
> > > To: Jie, Yang
> > > Cc: tiwai at suse.de; alsa-devel at alsa-project.org; Girdwood, Liam R;
> > > Zhang, Vivian
> > > Subject: Re: [RFC PATCH] ALSA: split params refinement to seperated
> > > file
> > >
> > > On Thu, Jun 04, 2015 at 10:47:45PM +0800, Jie Yang wrote:
> > >
> > > > The change moves refinement functions from original pcm_native.c
> > > > and pcm_lib.c, to pcm_refine.c(similarly the declaration from
> > > > pcm.h to pcm_refine.h), so it is not so big as it looks like.
> > >
> > > I'd suggest that for review it'd be easier to have one patch for the
> > > move and another for the change in behaviour: it's a bit hard to
> > > find the actual change in what the kernel does in this diff and
> > > that's the bit that needs most careful consideration.
> > >
> > > git format-patch -M may also help.
> >
> > Umm, Liam also suggested that, it's really hard for reviewing, but I
> > found that "git format-patch -M" doesn't help for partially
> > splitting/moving from a file to another/new file, I even tried '-M5%',
> > but no luck. :(
> >
> > I can't find good way to make it better, any suggestion?
> 
> Just begin with adding ifdefs instead of reshuffling the code.  This will make
> easier to understand what you're going to change.  At least, it's good enough
> for RFC.  After that, we can refactor the code.
 
That make sense.

> 
> But, before going further, I'd like to know the exact measurement you've
> done, the target and the goal.  Measuring only the static code size doesn't
 
Our target the minimum memory footprint usage for ALSA on small(e.g. IoT)
devices, and using 'lsmod' to check the status(including memory footprint)
of the modules.

> help much from the whole system POV.  Also, it's not clear which
> functionality has to be kept with which drivers and which configuration.
 
We suppose the bspoke application will pass down the specific params to
ALSA on those small devices, then hw refinement may be not needed.

We also made adapted change in tinyplay, did some testing and verified it works
in this case.

> 
> Removing the hw constraints refinement is rather a radical change.
> It's a part of the PCM core functionality, and removing it means that the
> driver has no ways to refuse the incompatible parameters even if it knows
 
Can we just return error and refuse doing stream playback/capture when we
know it's broken?

> it's broken.  So, IMO, this is the very last resort.  We can start from ripping off
> lower hanging fruits.
 
Agree that it is very last resort, I realized that it is a radical change and impact a
lot before sending this RFC. :|

thanks,
~Keyon
> 
> 
> thanks,
> 
> Takashi