[alsa-devel] [PATCH] ASoC: dapm: Add speaker driver widget.

Mark Brown broonie at opensource.wolfsonmicro.com
Tue Dec 7 00:09:49 CET 2010

On Mon, Dec 06, 2010 at 10:55:32PM +0000, Liam Girdwood wrote:
> On Mon, 2010-12-06 at 22:43 +0000, Mark Brown wrote:

> > Why not use the existing speaker widget?  It's at pretty much the same
> > point in the sequence and is intended for use with external GPIO
> > controlled speaker drivers.  It'd be good to discuss this in the
> > changelog.

> In this case the driver block is on the CODEC IC and after the PGA in
> the audio output path, hence this version is better suited than the
> external GPIO version.

Sure, but it's fulfiling the same role in the system - it's just that
these days a lot more CODECs are pulling speaker drivers directly into
the CODEC die.  Mostly these have worked well handled as PGAs so it's
not been an issue.

I'd certainly expect to see it handled the same way from a DAPM
sequencing point of view as it's fulfilling the same role in the system
(so in the same slot rather than separately as the patch was doing).  Do
we just need to refactor the existing external widgets to be able to
exist in either register or GPIO based versions?

> > > +#define SND_SOC_DAPM_DRV(wname, wreg, wshift, winvert,\
> > > +	 wcontrols, wncontrols) \
> > > +{	.id = snd_soc_dapm_drv, .name = wname, .reg = wreg, .shift = wshift, \
> > > +	.invert = winvert, .kcontrols = wcontrols, .num_kcontrols = wncontrols}

> > The _DRV name seems rather opaque - I'd suggest _SPK as a name but
> > obviously that's in use.  If we do want this I guess _SPK_DRV or
> > sommething.

> I was thinking this too, but then I thought we may want to drive other
> loads than just speakers here. e.g. haptic, vibra

My main thing here is _DRV - it's not just that it's undescriptive, it's
also that calling something a driver in a context like this is confusing.
_OUT_DRV is another idea?  The changelog also needs redoing to reflect
the more general use.

More information about the Alsa-devel mailing list