[alsa-devel] [PATCH 02/10] ALSA: hda - Bind codecs via standard bus

[Takashi Iwai]

At Sat, 28 Feb 2015 11:24:55 +0100,
Lars-Peter Clausen wrote:
> 
> On 02/28/2015 11:06 AM, Takashi Iwai wrote:
> > At Sat, 28 Feb 2015 10:55:32 +0100,
> > Lars-Peter Clausen wrote:
> >>
> >> On 02/26/2015 06:00 PM, Takashi Iwai wrote:
> >>> Now we create the standard HD-audio bus (/sys/bus/hdaudio), and bind
> >>> the codec driver with the codec device over there.  This is the first
> >>> step of the whole transition so that the changes to each codec driver
> >>> are kept as minimal as possible.
> >>>
> >>> Each codec driver needs to register hda_codec_driver struct containing
> >>> the currently existing preset via the new helper macro
> >>> module_hda_codec_driver().  The old hda_codec_preset_list is replaced
> >>> with this infrastructure.  The generic parsers (for HDMI and other)
> >>> are also included in the preset with the special IDs to bind
> >>> uniquely.
> >>>
> >>> In HD-audio core side, the device binding code is split to
> >>> hda_bind.c.  It provides the snd_hda_bus_type implementation to match
> >>> the codec driver with the given codec vendor ID.  It also manages the
> >>> module auto-loading by itself like before: when the matching isn't
> >>> found, it tries to probe the corresponding codec modules, and finally
> >>> falls back to the generic drivers.  (The special ID mentioned above is
> >>> set at this stage.)
> >>>
> >>> The only visible change to outside is that the hdaudio sysfs entry now
> >>> appears in /sys/bus/devices, not as a sound class device.
> >>>
> >>> More works to move the suspend/resume and remove ops will be
> >>> (hopefully) done in later patches.
> >>
> >> Great stuff. AC'97 is next? ;)
> >
> > Feel free to join to the club 97! :)
> >
> >> [...]
> >>> +	drv->driver.probe = hda_codec_driver_probe;
> >>> +	drv->driver.remove = hda_codec_driver_remove;
> >>
> >> Small nitpick, in my opinion it would be cleaner to use the snd_hda_bus_type
> >> probe/remove callbacks for this.
> >
> > Correct.  However, this would need more changes.  In this series, I'm
> > trying a gradual transition without a big surprise.  The merit of this
> > patch is that you need minimum changes in the codec driver side.
> 
> What I meant was instead of dynamically assigning the probe/remove callbacks 
> of each driver struct, just statistically setup the probe/remove callbacks 
> for the bus_type with the same callbacks. From a functional point of view 
> there should not be any difference.

Point taken.  Yes, it's feasible, but there is another plan for future
to make the bus more accessible to other drivers over HD-audio bus, so
the bus functionality is kept minimal as of now.


thanks,

Takashi