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

Takashi Iwai tiwai at suse.de
Fri May 22 15:35:03 CEST 2015


At Fri, 22 May 2015 13:56:34 +0100,
Mark Brown wrote:
> 
> On Mon, May 11, 2015 at 04:23:59PM +0530, Vinod Koul wrote:
> > From: Jeeja KP <jeeja.kp at intel.com>
> > 
> > ASoC hda codec driver will use id_table for registration.
> > id_table has info of codec vendor_id, revision_id and name.
> > For ASoC device/driver matching, device vendor_id, rev_id
> > will be matched to id_table to identify the device/driver.
> 
> 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:
> 
> > +/* HDA device table */
> > +#define HDA_NAME_SIZE      20
> > +struct soc_hda_device_id {
> > +	__u32 id;
> > +	__u32 rev_id;
> > +	char name[HDA_NAME_SIZE];
> > +	unsigned long driver_data;
> > +};
> > +
> > +struct soc_hda_codec_driver {
> > +	struct hdac_driver core;
> > +	const struct soc_hda_device_id *id_table;
> > +};
> 
> 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
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.


Takashi


More information about the Alsa-devel mailing list