On Wed, 03 Jan 2018 05:55:33 +0100, Rakesh Ughreja wrote:
Enhanced HD Audio capabilities introduced in HD Audio controllers are added in backward compatible way i.e. it does not change the behavior of the controller with respect to HDA Bus and HDA devices.
Since there is no change in the hardware with respect to the HDA bus and HDA device it is more appropriate to represent the same in software as well.
In order to align software representation with hardware it makes more sense to have common data structures across device, bus and driver for both enhanced HDA controllers and legacy HDA controllers.
This patch series removes the hdac_ext_device structure, hdac_ext_bus and hdac_ext_driver data structures so that legacy and enhanced HDaudio capabilities can be handled in a backwards-compatible way without separate definitions.
Once this clean-up is complete, additional patches will allow for HDaudio codec support in an ASoC framework without the need to develop new codec drivers, thereby enabling the use of the Intel DSP on more platforms (currently limited to hdmi).
Changes in v5:
- No functionality changes in this series except rebase.
Thanks for the new patchset.
It took some time until I figure out that topic/intel branch isn't new enough, so the patches can't be applied. The whole previous cleanups of hdac_hdmi were slipped into topic/dai-drv branch.
Mark, could you make topic/intel branch more usable, by merging topic/dai-drv branch? Otherwise it's pretty hard to apply these patches.
Unfortunately my Dell machine has no DSP, and it doesn't give the proper NHLT entry, thus the snd-soc-skl loading fails. (BTW, there was a kernel WARNING hit by that; will submit the fix patch later.)
So, only judging from the quick glance over the patches: first off, the less change in ALSA legacy side than previous versions is nice. Where to call the probe and the remove of ext_ops is still a slight question (whether it has to be the very beginning or not), but it's a good start.
Maybe we can drop the introduction of bus type, too. Basically just checking the non-NULL bus->ext_ops should be enough to identify the ext-bus type.
thanks,
Takashi