[alsa-devel] [RFC v5 0/3] Enable HDA Codec support on Intel Platforms (Series1)

[Takashi Iwai]

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