[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