On Wed, Apr 18, 2012 at 11:27:05AM +0200, Pavel Hofman wrote:
> Dne 18.4.2012 11:06, Mark Brown napsal(a):

> > BTW, this probably deserves picking up a bit more: there's really no
> > distinction between commercial and non-commercial contributors, if
> > anything I'd say that on average the hobbyist contributors tend to be
> > working to a higher standard on average.

> Mark, my whole point is most nonASoC alsa developers have no idea they
> are supposed to use stuff in the asoc subdir for the drivers outside of
> the asoc subtree. And I guess they mostly do not follow mailinglist
> messages prefixed ASoC either.

You're not engaging with my core point here - the simple fact that
there is an existing driver for the device ought to be enough of a clue
to allow someone to figure out that there's a problem here.  This
doesn't really need understanding of the code.

> If sound/asoc/codecs was in sound/codecs, they would certainly take a
> look. But right now to them asoc really feels like a separate world.

To be honest if you're at the point where you're familiar enough with
development to be ignoring bits of the tree you don't normally work on
then not noticing the duplicate driver is in many ways even more
surprising.

If we're going to reorganise the tree then there's a whole bunch of
other things that could usefully be cleaned up like moving to drivers/
and cleaning up all the legacy embedded platforms.  This wouldn't be a
bad thing, I'm sure it's actually been discussed before.  I'd expect
we'd probably still end up with all these devices grouped together
though as organising by subframework does seem sensible, the issue is
more that we've got some things that are duplicating effort.

In fact I'm actually tempted to create a legacy subdirectory as a first
step...

> I understand you would like to change that (or IOW - it would be
> beneficial to whole alsa to change that), very good. That is why I am
> talking about some guidelines for the non-asoc developers. I cannot
> write them, I am one of those having lived in the old-ages dark so far :)

Well, it's pretty simple really - anything where the audio CODEC is a
distinct piece of hardware connected with I2S or similar format
interfaces ought to be using ASoC.

Aside from legacy drivers like this, and the few in media/ it's really
where we're at already.  We do from time to time get vendors trying to
submit their own custom stacks but they get just the same sort of
pushback for exactly the same reason.