[alsa-devel] [PATCH 0/2] ASoC: TWL4030: DAPM restructuring and Headset pop-attenuation fix

[Aggarwal, Anuj]

> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi at nokia.com]
> Sent: Wednesday, May 20, 2009 2:43 PM
> To: alsa-devel at alsa-project.org
> Cc: ext Mark Brown; Aggarwal, Anuj; sakoman at gmail.com;
> getarunks at gmail.com
> Subject: Re: [alsa-devel] [PATCH 0/2] ASoC: TWL4030: DAPM restructuring
> and Headset pop-attenuation fix
> 
> On Wednesday 20 May 2009 11:51:21 ext Mark Brown wrote:
> >
> > Applied - thanks for your hard work on this!
> >
> > BTW, I don't know if you noticed the DAPM changes I pushed the other
> > day.  One commit in particular,
> 452c5eaa0d5162e02ffee742ea17540887bc2904,
> > might be interesting for TWL4030 - it changes things so that we're in
> > BIAS_ON whenever there's a bias path active, not only when there's a DAC
> > or ADC path.  I've got a feeling some of the pop/click stuff may mean
> > that's not as useful as it might've been in the past.
> 
> I will look at this change.
> BTW: I just got the Beagle board, it will take some time to get familiar with
> it, but than I can really use the latest and greatest of ASoC...
> 
> > > [Aggarwal, Anuj] Since different platforms are using different ramp
> > > values, how should it be handled via the same codec source code? How
> > > should this be done, without modifying the code base? Or should it be
> > > done every time user wants to play an audio file?
> >
> > Since it's just a change in one parameter the driver should be able to
> > arrange to get that configuration value provided to it via platform
> > data.  It's still the same chip and needs the same driver, all that's
> > changing is configuration information.
> 
> As for now, storing the mixer settings and restoring those at boot time would
> be the way.
> I will look at the possibility to add platform data parameter to twl4030 codec
> to set the board specific initial ramp delay value.
[Aggarwal, Anuj] I tried to look into the soc-dapm.h for the appropriate platform/machine-domain specific widget which could do the needful but could not find any. What is the correct way of handling this? I want to pass the correct ramp value for my platform.
> 
> --
> Péter