On 6/2/18 4:00 AM, Takashi Iwai wrote:
On Sat, 02 Jun 2018 05:53:48 +0200, Pierre-Louis Bossart wrote:
Many Intel platforms (SKL, KBL) etc. in the market supports enhanced audio capabilities which also includes DSP processing. The default HDaudio legacy driver does not allow for the use of the DSP, this patch set makes it possible while reusing existing code for HDAudio codecs and without significant changes to the legacy driver.
This v3 is not split into two batches as done for v1 and v2, but keeps the same logical progression. The first three patches are mostly data structure changes, the DSP support capability is added then with an ASoC HDA driver and the last patches are fixes required for Skylake+. The changes to the HDAudio legacy driver are minimal.
Tests were run successfully on multiple platforms (Dell XPS13, KBL NUC, APL NUC and LeafHill reference board).
Credits: all the initial code was written by Rakesh Ughreja, the rebase to broonie/for-next, cleanups and additional tests were done by Pierre Bossart.
Changes v3:
- port to component model
- additional tests on ApolloLake and KabyLake NUC devices
- cleanups (alignment, typos, etc)
Changes v2:
- Resolved review comments and rebased to latest kernel.
- added module load support for codec drivers.
Rakesh Ughreja (13): ALSA: hdac: Remove usage of struct hdac_ext_device and use hdac_device instead ALSA: hdac: Remove usage of struct hdac_ext_bus and use hdac_bus instead ALSA: hdac: Remove usage of struct hdac_ext_driver, use hdac_driver instead ASoC: Intel: Boards: Machine driver for SKL+ w/ HDAudio codecs ASoC: Intel: Skylake: Add entry in sst_acpi_mach for HDA codecs ASoC: Intel: Skylake: add HDA BE DAIs ASoC: Intel: Skylake: use hda_bus instead of hdac_bus ALSA: hda: split snd_hda_codec_new function ALSA: hdac: remove memory allocation from snd_hdac_ext_bus_device_init ALSA: hdac: add extended ops in the hdac_bus ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers ALSA: hdac: ext: add wait for codec to respond after link reset ASoC: Intel: Skylake: fix widget handling
Thanks for the patches. But, from obvious reasons, we can't take these for the next merge window. So it's really no good timing for such a big series...
I wasn't asking for a forced merge or trying to make your life complicated, it was more that I had a bit of time this week to provide an update and wanted to check how we deal with the multiple changes in different parts (Skylake, hda, hdac). It's fine if those patches land in 4.19 with additional time for reviews/testing.
In anyways, the patch series look like a mixture of lots of different things. Maybe it's better to split to multiple series, namely:
- Individual fixes
Patches 12 and 13 are irrelevant with the whole story, and they are merely fixes, can be applied individually. (the patch13 might be depending on others, though; didn't take a deeper look at it yet.)
- The removal of hdac_ext_* structs
These are basically no functional changes and local in hdac_ext. The preliminary work. The regression test is mandatory.
- Some code split / exports in snd_hda_codec_*(), adaption of hdac_bus extended ops
Another preliminary work and a setup for the new binding. They should be also no functional changes, and the existing setup should work as is. The regression test is mandatory.
- The new hdac_hdmi codec support and the new board codes
These are the new stuff, and applied after the preparations above.
I can split the code, but as you highlighted the series is pretty much organized as - cleanups - code split - addition of new functionaliy - fixes ...
... and these patches are touching both ASoC and HD-audio legacy, we'd need the coordinated patch application. That is, we'd need a topic branch that will be merged to both Mark and my trees. We can branch it off after 4.18-rc1 release, for example, as a clean start point.
... And I am not sure I understand the topic branch merged in both directions. If we want to perform a non-regression with the first parts (without ASoC additions) then we may need to create a partial topic branch, then add the rest later?
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel