Hi Czarek,
On 10/12/20 9:58 AM, Rojewski, Cezary wrote:
On 2020-10-12 9:42 AM, Hans de Goede wrote:
Hi,
On 10/12/20 9:24 AM, Rojewski, Cezary wrote:
...
Hello,
Series:
[PATCH v2 00/13] ASoC: Intel: Remove obsolete solutions and components
https://lore.kernel.org/alsa-devel/20201006064907.16277-1-cezary.rojewski@xxxxxxxxx/
removes sst-acpi component along with many others so further changes to
said component will only cause conflicts -or- require commit reordering.
I'd advice against that.
As I already mentioned in the private-thread which Pierre-Louis started
with me, Jaroslav Kysela and Liam about this I would advice against
applying
that series for now. First we need to put in more work to make sure that
the new drivers are actually ready.
Also I must say that I'm quite disappointed that since I, as the person
who more or less single handedly have made sure that audio works properly o
Bay Trail and Cherry Traul devices (*), has not been Cc-ed on that series,
that seems like a huge oversight.
Anyways I will reply in the thread of the series and ask Mark to revert
the entire series. Since IMHO the new drivers are clearly not ready yet.
Yesterday I ran my first set of tested and I immediately hit a DSP
hang doing just a few very basic tests.
Regards,
Hans
*) And kept it working properly despite other people breaking it with
changes
like moving the userspace stuff to UCM2.
Hello,
What's the name of the private-thread? Or perhaps I'm not even invited
there?
You were not on the Cc when Pierre-Louis started the thread,
I'll try to remember to Cc you on further replies. I'll give a summary
at the end of this email, since this is probably useful info for
everyone reading along to have.
Please, elaborate "new drivers". /baytrail/ has been deprecated for
years with only two available boards (machine boards) to it - which are
somewhat duplicates of /atom/ -or- SOF equivalents (bytcr-xxxx). From
linux-kernel perspective, having 3x baytrail driver is simply bad.
Ah, sorry I think I jumped the gun a bit on becoming grumpy about this.
On second reading I see you are removing the old-old Bay Trail code,
while keeping the medium-old (CONFIG_SND_SST_IPC_ACPI) code around for
now, correct ?
Yes that should be fine. One request though in the future please Cc
me on (non trivial) changes impacting Bay and Cherry Trail devices.
Several teams, clients and groups have been asked on multiple occasions
about the usage of the /baytrail/ folder. Not once positive answer has
been given.
Right, I don't know about other distros but in Fedora we have had
the use of the old sound/soc/intel/common/sst-acpi.c code disabled
for BYT/CHT for a while now.
Note Fedora does have the common/sst-acpi.c Broadwell / Haswell
bits enabled all the way up to kernel 5.9, but lets discuss that
in the thread where you remove the common/sst-acpi.c code.
Regards,
Hans
p.s. The promised summary:
Pierre-Louis contacted me about moving BYT/CHT devices to the SOF
driver so that the medium-old / CONFIG_SND_SST_IPC_ACPI drivers can
eventually also be removed. I agreed with that plan, but I was and
still am against doing it immediately as I want to first run a set
of tests to make sure the switch will go smoothly.
The Bay / Cherry Trail work I do is a personal-time side project, which
means mostly working on it in the weekend. As discussed in the off-list
discussion at a minimum I would like to run the following setups:
Realtek codecs:
BYT(CR) RT5640 SSP0 AIF1
BYT(CR) RT5640 SSP0 AIF2
BYT RT5640 SSP2
CHT RT5640 (HP pavilion X2 10-p002nd uses this weird combo)
CHT RT5645
BYT(CR) RT5651
CHT RT5651
BYT RT5672
Other:
BYT(CR) ESS8316
CHT ESS8316
CHT NAU8824
Through the following test plan:
1. Test speakers
2. Test internal mic.
3. Plugin headset, test headphones
4. Test headset-mic
5. Stop all audio, suspend + resume, test speakers
6. suspend + resume while playing audio, audio should
resume playing after resume.
This weekend I ran the test-plan on the first setup and
at step 3 (a couple of minutes into testing) I hit a DSP
hang (which I could not reproduce). Other then the hang the
testing went smooth. We will need to see if the hang was a
glitch or if I will hit it more often when I test the other
setups.
I have dmesg output from the hang, if someone is interested.
