[alsa-devel] [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers

Mark Brown broonie at kernel.org
Mon Apr 20 14:21:29 CEST 2015


On Sat, Apr 18, 2015 at 01:07:07PM -0700, Kevin Cernekee wrote:
> On Sat, Apr 18, 2015 at 10:11 AM, Mark Brown <broonie at kernel.org> wrote:

> > Someone trying to use the atmel_wm8904 driver with something other than
> > a wm8904 shouldn't really be expecting a good experince...

> The same check shows up in numerous other drivers, including the one
> for the audio controller on my board.

Sounds like either that (undisclosed) driver has a problem or you're
using it inappropriately.

> >> Is there a stub version that I can use instead?  Nothing jumped out at
> >> me when looking at the other codec drivers.

> > No, such a stub would make no sense - why would we put a stub in all the
> > drivers rather than just making the core do the right thing?

> AFAICT, implementing the set_sysclk callback is mandatory, even if it
> is a no-op on the codec side.  If I delete the stub function, audio
> playback fails.

For the reasons I mentioned above having a set_sysclk() function is not
mandatory and your driver will not be merged with a stub such as is
currently present.  As far as I can tell you are trying to bodge around
some problem elsewhere in either the code or your usage of it.

> Clearing just the LSB would accomplish the same thing, but would be
> less obvious IMO.  It would also require an extra read, and the code
> is less concise.

I don't think anyone is going to care about an extra read on system
init, and in any case if the driver followed best practice and provided
register defaults that read would be satisfied from cache.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150420/4a95173d/attachment.sig>


More information about the Alsa-devel mailing list