| Message ID | 20201006064907.16277-1-cezary.rojewski@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: Intel: Remove obsolete solutions and components | expand |
On Tue, 2020-10-06 at 08:48 +0200, Cezary Rojewski wrote: > Follow up to catpt series as mentioned in: > > [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point > > https://www.spinics.net/lists/alsa-devel/msg116440.html > > > > As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a > > lot of code redudant. The second legacy solution - baytrail - is > > deprecated for a long time by sound/soc/intel/atom with SOF flavor > > available too. > > > > This series addresses the redudancy and removes obsolete code. Along > > with the legacy solutions, all orphaned components are removed too. > > > > As a consequence, further cleanups are unlocked: sound/soc/intel/skylake > > becomes the sole user of processing code found in > > sound/soc/intel/common. Those are not part of this series. All Acked-by: Liam Girdwood <liam.r.girdwood@intel.com>
On Tue, 6 Oct 2020 08:48:54 +0200, Cezary Rojewski wrote: > Follow up to catpt series as mentioned in: > [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point > https://www.spinics.net/lists/alsa-devel/msg116440.html > > As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a > lot of code redudant. The second legacy solution - baytrail - is > deprecated for a long time by sound/soc/intel/atom with SOF flavor > available too. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [01/13] ASoC: Intel: Remove haswell solution commit: ca756120d4bcf28dfde5e3df8882153303d4010f [02/13] ASoC: Intel: Remove max98090 support for baytrail solution commit: 5f3941b63c25d8123ebe4406a714c603525b1b90 [03/13] ASoC: Intel: Remove rt5640 support for baytrail solution commit: 3056cb0082feccee9a0012440ee5e4ca6a6e80ac [04/13] ASoC: Intel: Remove baytrail solution commit: 07833cd0569bb73cc9f82814cdab921abb3dfb4a [05/13] ASoC: Intel: Remove SST ACPI component commit: 05668be1b3644f9bd25b22f62e79ad7a5adbd3e2 [06/13] ASoC: Intel: Remove SST firmware components commit: fb94b7b11c6a20b786c6a8aec3d701ced8854419 [07/13] ASoC: Intel: Skylake: Unassign ram_read and read_write ops commit: a4bebce26d560a4a1dff557ad7822bab90dd1c3f [08/13] ASoC: Intel: Remove unused DSP operations commit: 37465972015cf7aeb586a9245da2a87d3b531959 [09/13] ASoC: Intel: Remove unused DSP interface fields commit: b4e60807182a243d9dfe985e9e13d295f5868f81 [10/13] ASoC: Intel: Remove SST-legacy specific constants commit: 7d07f9c1ba0e670d1a967f16eda53e5c87411753 [11/13] ASoC: Intel: Make atom components independent of sst-dsp commit: b972153d6c53a89dc92d991c466a6b4800a9c91f [12/13] ASoC: Intel: Remove sst_pdata structure commit: 720811f0e4ac5a31d38aaee20905692dd7150997 [13/13] ASoC: Intel: Remove sst_dsp_get_thread_context commit: eb062e47f7c8cc28f19ba8f897481c22d13db1ec All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On 10/6/20 7:22 AM, Liam Girdwood wrote: > On Tue, 2020-10-06 at 08:48 +0200, Cezary Rojewski wrote: >> Follow up to catpt series as mentioned in: >> >> [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point >> >> https://www.spinics.net/lists/alsa-devel/msg116440.html >> >> >> >> As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a >> >> lot of code redudant. The second legacy solution - baytrail - is >> >> deprecated for a long time by sound/soc/intel/atom with SOF flavor >> >> available too. >> >> >> >> This series addresses the redudancy and removes obsolete code. Along >> >> with the legacy solutions, all orphaned components are removed too. >> >> >> >> As a consequence, further cleanups are unlocked: sound/soc/intel/skylake >> >> becomes the sole user of processing code found in >> >> sound/soc/intel/common. Those are not part of this series. > > All > > Acked-by: Liam Girdwood <liam.r.girdwood@intel.com> Also re-adding my ack already provided for v1. Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Hi, On 10/6/20 8:48 AM, Cezary Rojewski wrote: > Follow up to catpt series as mentioned in: > [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point > https://www.spinics.net/lists/alsa-devel/msg116440.html > > As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a > lot of code redudant. The second legacy solution - baytrail - is > deprecated for a long time by sound/soc/intel/atom with SOF flavor > available too. > > This series addresses the redudancy and removes obsolete code. Along > with the legacy solutions, all orphaned components are removed too. > > As a consequence, further cleanups are unlocked: sound/soc/intel/skylake > becomes the sole user of processing code found in > sound/soc/intel/common. Those are not part of this series. Since I've mostly worked with Pierre-Louis on this, I guess you may not know this, but I have more or less single handedly have made sure that audio works properly on Bay Trail and Cherry Trail devices during the last few years. Can you please Cc me on future series which impact Bay Trail / Cherry Trail support ? FWIW (since that this is already merged) I'm fine with removing the quite old Bay Trail support from common/sst-acpi.c, at least Fedora has been using the medium-old (with SOF being the new thing) CONFIG_SND_SST_IPC_ACPI support for Bay Trail audio support for quite some time now. This is not just about Bay Trail And Cherry Trail devices though, this series also makes changes impacting Haswell and Broadwell devices. The commit removing this support claims that at least for Haswell the new sound/soc/intel/catpt replaces it, but I do not see that code in 5.9, so that means that in one cycle we are both introducing the replacement and dropping the old code ? I'm not sure if that is such a great idea, what is the fallback plan if testing does find significant issues with the new catpt code ? Anyways since AFAIK this series is already in next I guess we will find out how this goes. Regards, Hans
On Mon, 12 Oct 2020 10:26:17 +0200, Hans de Goede wrote: > > FWIW (since that this is already merged) I'm fine with removing the > quite old Bay Trail support from common/sst-acpi.c, at least Fedora > has been using the medium-old (with SOF being the new thing) > CONFIG_SND_SST_IPC_ACPI support for Bay Trail audio support for > quite some time now. The same for openSUSE. Since CONFIG_SND_SOC_INTEL_BAYTRAIL is exclusive against SOF and other modern codes, I guess it's quite unlikely that any recent distros enable it. > This is not just about Bay Trail And Cherry Trail devices though, > this series also makes changes impacting Haswell and Broadwell devices. > > The commit removing this support claims that at least for Haswell the > new sound/soc/intel/catpt replaces it, but I do not see that code in > 5.9, so that means that in one cycle we are both introducing the > replacement and dropping the old code ? I'm not sure if that is such > a great idea, what is the fallback plan if testing does find significant > issues with the new catpt code ? I find the action a bit too rushing, too. OTOH, the old code wasn't well maintained, honestly speaking. So, from another perspective, switching to a new code can be seen as a better chance to fix any bugs. Of course, we could keep two stuff parallel, but it's rather confusing. And, the HSW/BDW devices that need SST are quite rare and old, so the impact is limited, I guess. In anyway, let's cross fingers, and feed back to Cezary ASAP when we get a regression. thanks, Takashi
On 2020-10-12 10:26 AM, Hans de Goede wrote: > Hi, > > On 10/6/20 8:48 AM, Cezary Rojewski wrote: >> Follow up to catpt series as mentioned in: >> [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point >> https://www.spinics.net/lists/alsa-devel/msg116440.html >> >> As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a >> lot of code redudant. The second legacy solution - baytrail - is >> deprecated for a long time by sound/soc/intel/atom with SOF flavor >> available too. >> >> This series addresses the redudancy and removes obsolete code. Along >> with the legacy solutions, all orphaned components are removed too. >> >> As a consequence, further cleanups are unlocked: sound/soc/intel/skylake >> becomes the sole user of processing code found in >> sound/soc/intel/common. Those are not part of this series. > > Since I've mostly worked with Pierre-Louis on this, I guess you may not > know this, but I have more or less single handedly have made sure that > audio works properly on Bay Trail and Cherry Trail devices during the > last few years. Can you please Cc me on future series which impact > Bay Trail / Cherry Trail support ? > Hello Hans, Thanks for your help during maintenance of BYT & CHT products. Agreed, will Cc you in future series for listed devices. > FWIW (since that this is already merged) I'm fine with removing the > quite old Bay Trail support from common/sst-acpi.c, at least Fedora > has been using the medium-old (with SOF being the new thing) > CONFIG_SND_SST_IPC_ACPI support for Bay Trail audio support for > quite some time now. > Please note CONFIG_SND_SST_IPC_ACPI is targeting /atom/ solution, not the /baytrail/ one (see the /atom/sst/Makefile). Fact that is has been used within /common/sst-acpi.c is a developer's mistake probably caused by generic naming of mentioned kconfig. I'll send a patch today somewhat addressing this inconsistency. > This is not just about Bay Trail And Cherry Trail devices though, > this series also makes changes impacting Haswell and Broadwell devices. > > The commit removing this support claims that at least for Haswell the > new sound/soc/intel/catpt replaces it, but I do not see that code in > 5.9, so that means that in one cycle we are both introducing the > replacement and dropping the old code ? I'm not sure if that is such > a great idea, what is the fallback plan if testing does find significant > issues with the new catpt code ? > > Anyways since AFAIK this series is already in next I guess we will > find out how this goes. > Your report about this series being merged to v5.9 is worrying. It is not supposed to be there as catpt-series is its direct dependency. Cover letter for the latter mentions that explicitly while this series starts with "Follow up to catpt series". Old hsw/bdw code is in fact the main recipient, old baytrail is 'while at it' do (...). Over the past months I've heard more and more voices requesting sound/soc/intel/ code size reduction - dropping the redundant solutions and actually verify their correctness. Well, /haswell/ failed all tests but simple pb/cp. /baytrail/ has been flagged as ~100% duplicate to /atom/ and most of /common/ code isn't actually common. You can see that in this very series where one by one I'm dissecting regions to be removed. Given the work that has been done behind the scenes, I'd argue hsw/bdw has never been in the better place than it is today - that goes for both, Linux and Windows solutions as both worlds took part in this project. Code rewritten, actual CI running, several setups in racks, documentation refreshed, FW + SW windows again on thier legs and so on. I'll be sending ~2 patches addressing more advanced scenarios which /haswell/ wasn't even covering. Will keep you in Cc too. Regards, Czarek
HI, On 10/12/20 11:24 AM, Rojewski, Cezary wrote: > On 2020-10-12 10:26 AM, Hans de Goede wrote: >> Hi, >> >> On 10/6/20 8:48 AM, Cezary Rojewski wrote: <snip> > Hello Hans, > > Thanks for your help during maintenance of BYT & CHT products. > Agreed, will Cc you in future series for listed devices. Great, thank you. >> FWIW (since that this is already merged) I'm fine with removing the >> quite old Bay Trail support from common/sst-acpi.c, at least Fedora >> has been using the medium-old (with SOF being the new thing) >> CONFIG_SND_SST_IPC_ACPI support for Bay Trail audio support for >> quite some time now. >> > > Please note CONFIG_SND_SST_IPC_ACPI is targeting /atom/ solution, not > the /baytrail/ one (see the /atom/sst/Makefile). Fact that is has been > used within /common/sst-acpi.c is a developer's mistake probably caused > by generic naming of mentioned kconfig. > > I'll send a patch today somewhat addressing this inconsistency. Ok. >> This is not just about Bay Trail And Cherry Trail devices though, >> this series also makes changes impacting Haswell and Broadwell devices. >> >> The commit removing this support claims that at least for Haswell the >> new sound/soc/intel/catpt replaces it, but I do not see that code in >> 5.9, so that means that in one cycle we are both introducing the >> replacement and dropping the old code ? I'm not sure if that is such >> a great idea, what is the fallback plan if testing does find significant >> issues with the new catpt code ? >> >> Anyways since AFAIK this series is already in next I guess we will >> find out how this goes. >> > > Your report about this series being merged to v5.9 is worrying. It is > not supposed to be there as catpt-series is its direct dependency. Cover > letter for the latter mentions that explicitly while this series starts > with "Follow up to catpt series". Sorry for causing a misunderstanding, this series is not merged for 5.9, AFAICT it is queued up for 5.10. What I was trying to say is that the new catpt code is also NOT in 5.9. So 5.9 will both get the replacement catpt code and drop the old sst-acpi support for Broadwell / Haswell in a single cycle. <snip> > Given the work that has been done behind the scenes, I'd argue hsw/bdw > has never been in the better place than it is today - that goes for > both, Linux and Windows solutions as both worlds took part in this > project. Code rewritten, actual CI running, several setups in racks, > documentation refreshed, FW + SW windows again on thier legs and so on. Ok, sounds good, hopefully thing will work out fine for HSW/BDW in 5.10 then. Regards, Hans
On Mon, Oct 12, 2020 at 11:09:04AM +0200, Takashi Iwai wrote: > Hans de Goede wrote: > > replacement and dropping the old code ? I'm not sure if that is such > > a great idea, what is the fallback plan if testing does find significant > > issues with the new catpt code ? > I find the action a bit too rushing, too. OTOH, the old code wasn't > well maintained, honestly speaking. So, from another perspective, > switching to a new code can be seen as a better chance to fix any > bugs. That was my take as well - the old code seemed to be very fragile for structural reasons which are hopefully addressed here and Intel seem willing to actively work on supporting this version. I have to confess I had assumed Hans had seen all this stuff going past, the new driver got quite a few rounds of review. > Of course, we could keep two stuff parallel, but it's rather > confusing. And, the HSW/BDW devices that need SST are quite rare and > old, so the impact is limited, I guess. Yes, figuring out which of the various x86 audio driver options you need is fairly painful ATM. Worst case it's just a revert of this removal commit.
Hi, On 10/12/20 1:36 PM, Mark Brown wrote: > On Mon, Oct 12, 2020 at 11:09:04AM +0200, Takashi Iwai wrote: >> Hans de Goede wrote: > >>> replacement and dropping the old code ? I'm not sure if that is such >>> a great idea, what is the fallback plan if testing does find significant >>> issues with the new catpt code ? > >> I find the action a bit too rushing, too. OTOH, the old code wasn't >> well maintained, honestly speaking. So, from another perspective, >> switching to a new code can be seen as a better chance to fix any >> bugs. > > That was my take as well - the old code seemed to be very fragile for > structural reasons which are hopefully addressed here and Intel seem > willing to actively work on supporting this version. I have to confess > I had assumed Hans had seen all this stuff going past, the new driver > got quite a few rounds of review. My ASoC interest is 99% Intel Bay Trail / Cherry Trail support, so I'm not on alsa-devel list since that gets a lot more then just that. IOW I'm relying on being Cc-ed, which might not be the best tactic I guess. Anyways, the Bay Trail / Cherry Trail changes here are 100% ok with me. I pointed out the Haswell / Broadwell bits since I was taking a look anyways, I don't really have a strong opinion on those, I've never seen a Haswell / Broadwell machine actually using the SST/ASoC code, all those which I have seen use the HDA driver. And from the sounds of it for those rare Haswell / Broadwell machines which do use the SST code the new catpt code should be an improvement. So from my pov everything is good. Regards, Hans
On 2020-10-12 1:53 PM, Hans de Goede wrote: > Hi, > > On 10/12/20 1:36 PM, Mark Brown wrote: >> On Mon, Oct 12, 2020 at 11:09:04AM +0200, Takashi Iwai wrote: >>> Hans de Goede wrote: >> >>>> replacement and dropping the old code ? I'm not sure if that is such >>>> a great idea, what is the fallback plan if testing does find >>>> significant >>>> issues with the new catpt code ? >> >>> I find the action a bit too rushing, too. OTOH, the old code wasn't >>> well maintained, honestly speaking. So, from another perspective, >>> switching to a new code can be seen as a better chance to fix any >>> bugs. >> >> That was my take as well - the old code seemed to be very fragile for >> structural reasons which are hopefully addressed here and Intel seem >> willing to actively work on supporting this version. I have to confess >> I had assumed Hans had seen all this stuff going past, the new driver >> got quite a few rounds of review. Thanks for your encouraging words, Takashi and Mark. My faith is with accuracy of our CI, not the fingers crossing though : ) Happy to receive any feedback. Andy pushed me to dig several low-level issues e.g. DMA engine configuration and PCI description which were hidden since 2014 behind other errors, what I'm thankful for. v1 addressed the latter, further series the former. Indeed, given the resources that have been put into assembling active HSW/BDW CI - which happily joined the SKL-TGL family in racks -, commitment to support the catpt solution is assured. > > My ASoC interest is 99% Intel Bay Trail / Cherry Trail support, so > I'm not on alsa-devel list since that gets a lot more then just that. > > IOW I'm relying on being Cc-ed, which might not be the best tactic > I guess. > > Anyways, the Bay Trail / Cherry Trail changes here are 100% ok with me. > I pointed out the Haswell / Broadwell bits since I was taking a look > anyways, I don't really have a strong opinion on those, I've never seen > a Haswell / Broadwell machine actually using the SST/ASoC code, > all those which I have seen use the HDA driver. > > And from the sounds of it for those rare Haswell / Broadwell machines > which do use the SST code the new catpt code should be an improvement. > So from my pov everything is good. > Hans, I understand that actual DSP-hw is quite old (2011 dev, 2014 release) so besides what is already available, I won't be adding many things. Those are: firmware logs (debug feature), module support (WAVES). Nothing more, nothing less. Immediately afterward catpt enters hard-maintenance stage where only fixes are allowed. Stress tests are still ongoing as my goal is to remove basically any-hsw specific code (~50 lines) as hsw is here only from maintenance point of view as explained in catpt's series cover-letter. The more eyes looking at the code, the merrier : ) Thanks for your input. Regards, Czarek
On Mon, Oct 12, 2020 at 01:53:54PM +0200, Hans de Goede wrote: > My ASoC interest is 99% Intel Bay Trail / Cherry Trail support, so > I'm not on alsa-devel list since that gets a lot more then just that. > IOW I'm relying on being Cc-ed, which might not be the best tactic > I guess. Might be sensible to add you to the reviwers for at least the machine driver so you're more likely to get copied on things? > Anyways, the Bay Trail / Cherry Trail changes here are 100% ok with me. > I pointed out the Haswell / Broadwell bits since I was taking a look > anyways, I don't really have a strong opinion on those, I've never seen > a Haswell / Broadwell machine actually using the SST/ASoC code, > all those which I have seen use the HDA driver. OK, that's good.