[alsa-devel] [PATCH 3/4] Add Wolfson Microelectronics WM8776 codec ALSA driver

[Mark Brown]

On Tue, Apr 17, 2012 at 10:16:01PM +0200, Pavel Hofman wrote:

> Mark, I have always viewed alsa drivers as split to two parts

> 1. the "PC world" where mostly individual often amateur developers
> post patches improving support of the hardware they own.

> 2. the ASoC world of embedded solutions, where mostly vendors
> contribute patches for the hardware they produce. All ASoC posts are

That's really not a good split - while audio seems to be one of the few
areas where embedded vendors are in the forefront of contributing code
for their own parts there's a fair amount of hobbyist work in the
embedded space too.  The first example that springs to mind is the
Kirkwood support which has never had any involvement at all from
Marvell.  Even where people are employed to work on the code they're
often not working for the device vendor but rather for some other
company who happens to be using the device.

> Even the until recently highly active intel-hda section does not use
> any of the ASoC infrastructure. If you read the ASoC documentation

It wouldn't be appropriate for HDA to use ASoC, the hardware has a
rather different model for how it's constructed - the main thing being
that obviously there's only one control interface for all devices and
you're supposed to be able to write a generic HDA driver which works on
any system using HDA.

> http://alsa-project.org/main/index.php/ASoC, it would not occur to
> me I should be using asoc codecs infrastructure for ice1724 card.

If you feel there's something that could be improved about the wiki
please contribute to it.  Though that said as far as I'm aware the ALSA
wiki is about as actively maintained as the bug tracker which we still
haven't managed to get shut down.  All the content I've ever had any
cause to look at is links to off site documentation, most of which are
now broken as they're to pre-breakin kernel.org, and most of what's
there is extremely old.

> Working hard on series of patches and being met with cold attitude
> as for not adhering to ASoC standards (quoting the alsa-project.org:

It's really the fact that it's not using ASoC, it's the fact that patch
here is adding a driver for a device which already has an in-tree
driver; that alone should be a very big warning sign.  Ending up with
two totally separate drivers for a single device is never a good idea,
if only from a duplication of work point of view.

I'd at least expect the presence of the existing driver to have prompted
a question along the lines of "I can't figure out how I'm supposed to
use this driver here, what am I missing?", or something in the changelog
indicating that this issue had been considered and that the duplication
is a sensible solution for whatever reason.

> If you want these independent contributors to start using the kernel
> infrastructure common in the ASoC "tree", please tell them clearly on
> the alsa-project.org website, at best directly at
> http://alsa-project.org/main/index.php/Developer_Zone

Again, if you feel the documentation needs to be improved please
contribute to the documentation.  I honestly can't see where I'd put any
information so that people would usefully find it, but then like I say
that's largely because it doesn't look like the wiki gets much use so
it'd put me off looking in the first place.  If you're saying people
actively use the wiki then probably you've got a better idea of where
they're looking in there.

> I can understand the very active ASoC subproject is defining current
> standards for the rest of alsa tree but please tell the currently
> valid rules to all the developers.

Like I say the major issue here is further back at the point where we're
ending up with two drivers for one bit of hardware.  That's not
something to do with knowing about ASoC, it's more general good
practice.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120417/d374552f/attachment-0001.sig