[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150418113957.GF26185@sirena.org.uk>
Date: Sat, 18 Apr 2015 12:39:57 +0100
From: Mark Brown <broonie@...nel.org>
To: Lars-Peter Clausen <lars@...afoo.de>
Cc: Kevin Cernekee <cernekee@...omium.org>, lgirdwood@...il.com,
devicetree@...r.kernel.org, alsa-devel@...a-project.org,
abrestic@...omium.org, linux-kernel@...r.kernel.org,
dgreid@...omium.org, olofj@...omium.org
Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: tas571x: New driver for TI
TAS571x power amplifiers
On Thu, Apr 16, 2015 at 02:57:49PM +0200, Lars-Peter Clausen wrote:
> On 04/15/2015 11:42 PM, Kevin Cernekee wrote:
> >+ case TAS571X_ID_5711:
> >+ priv->codec_driver.controls = tas5711_controls;
> >+ priv->codec_driver.num_controls = ARRAY_SIZE(tas5711_controls);
> >+ break;
> >+ case TAS571X_ID_5717:
> >+ case TAS571X_ID_5719:
> >+ priv->codec_driver.controls = tas5717_controls;
> >+ priv->codec_driver.num_controls = ARRAY_SIZE(tas5717_controls);
> Typically when a driver supports multiple chips with different control sets
> the snd_soc_codec_driver implements a probe callback in which the correct
> controls are registered.
I'm fine with doing it with tables (though just having two static CODEC
driver structures would be a bit cleaner). The pattern with probe() is
usually that there's some base set of controls all the devices have
which then gets device specific controls/routes/whatever added to it so
you get benefits fromm sharing the table but in this case the table is
so tiny anyway that I'm not sure it's worth caring.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists