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
