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