[alsa-devel] [PATCH v4 1/7] ASoC: hda - add ASoC HDA codec match function

[Mark Brown]

On Wed, May 27, 2015 at 08:05:47AM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > This is still as clear as mud, sorry - why is the ID table not something
> > that the bus handles?  It seems like a core part of what a bus
> > abstracts.  Having two completely separate sets of controller and device
> > drivers that can't interact with each other (which seems like what we're
> > ending up with here) seems really worrying and I don't think I've seen
> > any plan for unification either.  It's not just the match function stuff
> > by the way, some of the later patches also made me wonder about the
> > mutiple implementations of the bus thing.

> HDA bus is the place for communication between a device and a
> controller.  This is common, no matter whether asoc or legacy.  That
> is, an ASoC HDA controller may communicate even with an HDA legacy
> codec device, if really wanted.  There is no distinction there.

I'm unclear how that would (practically speaking) be accomplished if
they're in two separate worlds for matching.  Come to think of it how
does this work if we have more than one matching system in use - how
does the driver model code cope with that, what happens if one match
function ends up looking at data for another match type?

> The fact you might be missing from the beginning of the story is that
> we need to implement two different driver sets for ASoC, both for
> controller and codec drivers.  They can't be unified with legacy HDA
> unless we merge ASoC core codes into ALSA core (e.g. DPCM or DAPM into
> ALSA core).  Also ASoC has the different ways of registration, too.

Wow, that's not what I'd have expected to be happening at all and really
should have been mentioned at some point.  I need to think about this
further.

What I had expected to see for ASoC/HDA integration was something where
ASoC devices were providing a standard HDA controller and then use the
same CODEC drivers as everything else.  Not doing that means that we
inveitably have some duplication for at least things like CODEC quirks
and device specific support which doesn't seem like the best idea.
There's also userspace interfaces for things like the HDA device graph
that'd need looking at.

Having HDA use ASoC doesn't seem like a terrible idea, there are aspects
of HDA that map quite well onto ASoC, but doesn't seem to be the
intention here and I'm ambivalent about it being worth the effort.  I
don't think it would need us to move ASoC into the core any more than
any other driver, it'd just make it much more widely used.

> > What you all seem to be saying is that the existing code for HDA is too
> > fragile to touch much so we don't want to move much of its functionality
> > to the new bus yet.  I can believe that but I think I'd be a lot happier
> > if we were handling that by having the existing HDA code override bus
> > functionality rather than by implementing key bus functionality in
> > random places.  It feels like trying to use the bus now is adding
> > technical debt.

> Well, the patchset looks more complicated because lots of codes you're
> seeing in this patchset are specific to SKL hardware extension, and it
> doesn't (maybe won't) exist in HDA legacy.  For example, patch 3
> contains many such codes, which is likely the point where you stopped
> reading the rest patches.

I'm too alarmed by what I'm seeing in the apparently generic code to
look at the platform specific code.
-------------- 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/20150527/00a2a17a/attachment.sig>