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

[Vinod Koul]

On Fri, May 22, 2015 at 08:13:45PM +0200, Takashi Iwai wrote:
> At Fri, 22 May 2015 18:41:06 +0100,
> Mark Brown wrote:
> > 
> > On Fri, May 22, 2015 at 03:35:03PM +0200, Takashi Iwai wrote:
> > > Mark Brown wrote:
> > 
> > > > I'm sorry but I still don't entirely understand what this is supposed to
> > > > do.  It *looks* like it's trying to create a bus for HDA with this:
> > 
> > > > but it's not actually defining a driver model bus type (though it does
> > > > use driver_register()) and I'd expect the bus type to be provided by the
> > > > generic HDA code.  Looking (fairly quickly admittedly) at the HDA code
> > > > it's not entirely obvious how it all fits together and the changelog for
> > > > that just talks about moving code around.
> > 
> > > The bus is already defined in sound/hda.  There, the actual binding is
> > 
> > I see there's a bus_type defined there but this is calling raw
> > device_register() and providing a match function so it seems like
> > there's something missing or an abstraction problem.  I'd expect a bus
> > to be providing things like match functions and bus specific
> > registration functions.
> 
> This was intentionally left in that way, so that the upper core layer
> (HDA ASoC or legacy core parts) can implement the matching method more
> specifically.  It can be done in the hdac_bus itself, but currently
> still leaves more room until we see the exact matching condition for
> ASoC.
> 
> Once when the matching method can be unified, we can move the it to
> hdac_bus.  But it's not necessarily done now.
> 
> > This is all setting off alarm bells, both the code and the very
> > aggressive pushing.
> > 
> > > done in each hda driver specifics, i.e. in sound/soc/hda and
> > > sound/pci/hda.  It's the way to allow binding completely different
> > > drivers for the very same PCI ID.
> > 
> > I don't really understand this, sorry.  What impact would HDA bus
> > implementation have on PCI device drivers (by the time you're
> > registering HDA devices presumably the PCI device will already be
> > enumerated)?  
> >
> > Having two drivers for the same PCI function doesn't sound like an
> > *obviously* good idea (as we discussed recently) but that's a bit of a
> > separate thing.
> 
> Suggesting two PCI IDs might have been confusing, sorry.
> 
> The point is that a HD-audio object can be inherited to two different
> level of objects, legacy and ASoC.  Both are bound on the same bus,
> but to the corresponding drivers.  Both objects use the very same bus
> ops, thus they share the same hdac_bus.
Thanks a bunch Takashi for clarifying :)

Mark,

I guess one clarification may still help, The SKL Audio controller is PCI
device, the PCM driver in this series will load against the PCI device.
Now the driver will go ahead and initialize the HDA bus. Also we provide our
own matching function here.

The matching function is for matching the devices on HDA link. The probing
of the bus will find the HDA codecs present in the bus and we will match
them based on Vendor ID and Device ID in match function above.

Let us know if you have more questions

-- 
~Vinod