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

[Takashi Iwai]

At Wed, 27 May 2015 19:34:06 +0100,
Mark Brown wrote:
> 
> 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 matching function does the same thing, but it just looks at the
different embedded id tables.  The bus match function already checks
each device/driver type beforehand.

> > 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.

Actually that's the exact plan -- the codec graph will be parsed in
user-space (or pre-parsed) and mapped via DFW.

The quirks are still open questions.  Currently, ASoC HDA is targeted
only to the new systems with SKL.  The rest will keep supported by the
existing driver.  So, we expect that the amount of quirks can be
reduced much (starting from zero).

> 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.

Heh, that's the very reason why we started implementing a different
driver set, after all.  The new driver code is written in minimalistic
manner to fit better with ASoC.  The heavy part has been already
shifted into HDA core side, that is basically a stripped version from
the old HDA code.

ASoC implementation was requested rather due to DPCM, compress
support, etc, which is currently ASoC-specific features.  The current
patchset we've seen is really a tip of iceberg...

> > > 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.

Yeah, it's a bit unfortunate.  Maybe it'd have been easier if they
were split better.


Takashi