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
