Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2

Hi,

Due to b1ef2972586577e0ca9675254ee141f65a8824e5 landing recently as a result of some previous ACPI community discussion, the Dell XPS 13 (2015) no longer has fully functional audio. In case you aren't aware, the XPS 13 (2015) switches audio modes based upon a combination of what's detected for the _OSI string and _REV values. When "Windows 2013" is found with _REV=2 the audio codec will be configured for I2S audio mode. When "Windows 2013" with _REV=5 is found it will be configured for HDA audio mode.

I2S audio is improving, but not as mature as HDA audio mode is at this point. Currently jack detection does not work properly in 4.1 with I2S audio codecs. I've been notified that the support for jack detection will be landing in 4.2. I'd like to discuss the possibility of including a quirk for the _REV behavior when the DMI information corresponding to the Dell XPS 13 (2015) is detected for 4.1. This will let it continue to run in HDA mode until I2S mode is mature.

I'd also like to plan for the quirk to be dropped when jack detection has landed for 4.2 (or if it gets pushed out further when it lands for 4.3).

Would you guys be open to that?

Thanks,

Quoted 11 lines · Mario Limonciello

Hi,

Due to b1ef2972586577e0ca9675254ee141f65a8824e5 landing recently as a result of some previous ACPI community discussion, the Dell XPS 13 (2015) no longer has fully functional audio. In case you aren't aware, the XPS 13 (2015) switches audio modes based upon a combination of what's detected for the _OSI string and _REV values. When "Windows 2013" is found with _REV=2 the audio codec will be configured for I2S audio mode. When "Windows 2013" with _REV=5 is found it will be configured for HDA audio mode.

I2S audio is improving, but not as mature as HDA audio mode is at this point. Currently jack detection does not work properly in 4.1 with I2S audio codecs. I've been notified that the support for jack detection will be landing in 4.2. I'd like to discuss the possibility of including a quirk for the _REV behavior when the DMI information corresponding to the Dell XPS 13 (2015) is detected for 4.1. This will let it continue to run in HDA mode until I2S mode is mature.

I'd also like to plan for the quirk to be dropped when jack detection has landed for 4.2 (or if it gets pushed out further when it lands for 4.3).

Would you guys be open to that?

Thanks,

Hello,

I just wanted to follow up on this, I would like to come up with a solution before it's too late for 4.1 on the XPS 13 (2015).

Thanks,

Hi,

(CC'ing sound experts)

indeed, commit b1ef29725865 causes a severe regression -- actually, it causes sound to be totally unusuable on the Dell XPS 13 (2015) on Debian jessie, while it works fine in 4.0 / with b1ef29725865 reverted.

According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old. The matter is further complicated by the issue that the driver asks for some firmware blob intel/IntcPP01.bin which (at least) I cannot find anywhere.

Under the no-regression rule, this means that either b1ef29725865 needs to be reverted or we need to find another solution to this matter, such as an override. And I think it is needed for longer than just for 4.1, as it will continue to be cause regressions on quite recent userspace.

Best,
Dominik

PS/OT: Probably I'm preaching to the choir, but @Mario: it's a pity the XPS (or some versions of it) with pre-installed Ubuntu actually ships with a Wifi adapter which seems to be unsupported by upstream Linux...

-----Original Message-----
From: Dominik Brodowski [mailto:[email protected]]
Sent: Tuesday, May 12, 2015 2:27 AM
To: Mario Limonciello; Moore, Robert; Zheng, Lv; Wysocki, Rafael J
Cc: [email protected]; [email protected]; Lu, Han; Jie, Yang; alsa- [email protected]
Subject: commit b1ef29725865 (ACPI _REV=2) causes sound regression on Dell XPS 13 [Was: Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2]

Hi,

(CC'ing sound experts)

indeed, commit b1ef29725865 causes a severe regression -- actually, it causes sound to be totally unusuable on the Dell XPS 13 (2015) on Debian jessie, while it works fine in 4.0 / with b1ef29725865 reverted.

According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old. The matter is further complicated by the issue that the driver asks for some firmware blob intel/IntcPP01.bin which (at least) I cannot find anywhere.

Under the no-regression rule, this means that either b1ef29725865 needs to be reverted or we need to find another solution to this matter, such as an override. And I think it is needed for longer than just for 4.1, as it will continue to be cause regressions on quite recent userspace.

Best,
Dominik

PS/OT: Probably I'm preaching to the choir, but @Mario: it's a pity the XPS (or some versions of it) with pre-installed Ubuntu actually ships with a Wifi adapter which seems to be unsupported by upstream Linux...

Quoted 5 lines · Mario Limonciello

Quoted 3 lines · Mario Limonciello

Hi,

Due to b1ef2972586577e0ca9675254ee141f65a8824e5 landing recently as a

result of some previous ACPI community discussion, the Dell XPS 13 (2015) no longer has fully functional audio. In case you aren't aware, the XPS 13 (2015) switches audio modes based upon a combination of what's detected for the _OSI string and _REV values. When "Windows 2013" is found with _REV=2 the audio codec will be configured for I2S audio mode. When "Windows 2013" with _REV=5 is found it will be configured for HDA audio mode.

Quoted 2 lines

Quoted 2 lines

I2S audio is improving, but not as mature as HDA audio mode is at this

point. Currently jack detection does not work properly in 4.1 with I2S audio codecs. I've been notified that the support for jack detection will be landing in 4.2. I'd like to discuss the possibility of including a quirk for the _REV behavior when the DMI information corresponding to the Dell XPS 13 (2015) is detected for 4.1. This will let it continue to run in HDA mode until I2S mode is mature.

Quoted 2 lines

Quoted 2 lines

I'd also like to plan for the quirk to be dropped when jack detection has

landed for 4.2 (or if it gets pushed out further when it lands for 4.3).

Quoted 7 lines

Quoted 4 lines

Would you guys be open to that?

Thanks,

Hello,

I just wanted to follow up on this, I would like to come up with a solution

before it's too late for 4.1 on the XPS 13 (2015).

Quoted 2 lines

Thanks,

According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old.

The matter is further complicated by the issue that the driver asks for some firmware blob intel/IntcPP01.bin which (at least) I cannot find anywhere.

Under the no-regression rule, this means that either b1ef29725865 needs to be reverted or we need to find another solution to this matter, such as an override. And I think it is needed for longer than just for 4.1, as it will continue to be cause regressions on quite recent userspace.

On Mon, May 11, 2015 at 08:26:58PM +0200, Dominik Brodowski wrote:

Also CCing Matthew who came up with the original version of the version change and Liam who is one of Intel's audio experts.

Quoted 2 lines

According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old.

Right, it needs the userspace configuration files installing.

Quoted 4 lines

The matter is further complicated by the issue that the driver asks for some firmware blob intel/IntcPP01.bin which (at least) I cannot find anywhere.

As previously advised that firmware is optional.

Quoted 5 lines

Under the no-regression rule, this means that either b1ef29725865 needs to be reverted or we need to find another solution to this matter, such as an override. And I think it is needed for longer than just for 4.1, as it will continue to be cause regressions on quite recent userspace.

Does this also affect other behaviour of the system? I'd be pretty unhappy if it introduce power regressions for example, I mostly don't use audio on my laptops but I care a lot about how long it'll run disconnected. It *is* quite a new laptop and my experience installing was very much that it was in bringup (though quite a bit of this was userspace).

Quoted 1 line · Mark Brown

On Mon, May 11, 2015 at 08:26:58PM +0200, Dominik Brodowski wrote:

Quoted 7 lines

Also CCing Matthew who came up with the original version of the version change and Liam who is one of Intel's audio experts.

Quoted 2 lines

According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old.

Right, it needs the userspace configuration files installing.

Is it just configuration files? With 4.1-rc3 I've not been able to get sound working mucking with any mixers.

Quoted 5 lines

Quoted 3 lines

The matter is further complicated by the issue that the driver asks for some firmware blob intel/IntcPP01.bin which (at least) I cannot find anywhere.

As previously advised that firmware is optional.

The errors in dmesg make it seem like that was related to the firmware missing, but that is a red herring it sounds like.

Quoted 6 lines

Does this also affect other behaviour of the system? I'd be pretty unhappy if it introduce power regressions for example, I mostly don't use audio on my laptops but I care a lot about how long it'll run disconnected. It *is* quite a new laptop and my experience installing was very much that it was in bringup (though quite a bit of this was userspace).

I just tried it with 4.1-rc3 from Ubuntu's mainline PPA and an Ubuntu
15.04 userspace. It does affect the behavior of the system. See
all the PCM errors in dmesg:

https://bugzilla.kernel.org/attachment.cgi?id=176511

At least with BIOS A03 (latest), Ubuntu 15.04 (3.19ish and modern userspace) or with 4.0 and recent userspace the experience shouldn't be bringup.

Please fix your mail client to word wrap within paragraphs and leave blank lines between paragraphs. Your current mail client is doing neither which makes your mails hard to read.

You need PulseAudio 6.0 but otherwise yes, it works for me.

That wasn't my question. I'm asking what else the firmware is changing based on detecting Linux, we don't want to just move onto a different set of bugs somewhere else.

I'm not seeing any of the hw_params() issues with v4.1 - are you perhaps using an old linux-firmware? I don't know how up to date Ubuntu is there.

Quoted 3 lines

I'm not seeing any of the hw_params() issues with v4.1 - are you perhaps using an old linux-firmware? I don't know how up to date Ubuntu is there.

linux-firmware ubuntu 15.04 version: 1.143.
This is based off upstream cef33368c4d3425f11306496f0250f8ef1cf3c1f, updated on March 4 2015.

-----Original Message-----
From: Mark Brown [mailto:[email protected]]
Sent: Wednesday, May 13, 2015 1:35 AM
To: Mario Limonciello
Cc: Dominik Brodowski; Moore, Robert; Zheng, Lv; Wysocki, Rafael J; linux- [email protected]; Lu, Han; Jie, Yang; [email protected]; Matthew Garrett; Girdwood, Liam R
Subject: Re: commit b1ef29725865 (ACPI _REV=2) causes sound regression on Dell XPS 13 [Was: Discussion around quirking the _REV behavior for the XPS 13 (2015) until 4.2]

Quoted 3 lines · Mario Limonciello

Quoted 3 lines

I'm not seeing any of the hw_params() issues with v4.1 - are you perhaps using an old linux-firmware? I don't know how up to date Ubuntu is there.

Quoted 3 lines

linux-firmware ubuntu 15.04 version: 1.143.
This is based off upstream cef33368c4d3425f11306496f0250f8ef1cf3c1f, updated on March 4 2015.

That's the same firmware I have. Weird, I don't know if the Intel guys have any bright ideas here?

Hi Mario, can you try disabling pulseaudio to see if anything change? Once I got one XPS 13 9343, I can debug on it, we have ordered it, but been told still need wait 4 more weeks for lacking of the LCD screen materials.

~Keyon

Quoted 2 lines

According to an off-list discussion, the sound breakage (and not just some jack detection issue) seems to be caused due to alsa-lib being too old.

Right, it needs the userspace configuration files installing.

Quoted 4 lines

Under the no-regression rule, this means that either b1ef29725865 needs to be reverted or we need to find another solution to this matter, such as an override. And I think it is needed for longer than just for 4.1, as it will continue to be cause regressions on quite recent userspace.

Does this also affect other behaviour of the system? I'd be pretty unhappy if it introduce power regressions for example, I mostly don't use audio on my laptops but I care a lot about how long it'll run disconnected. It *is* quite a new laptop and my experience installing was very much that it was in bringup (though quite a bit of this was userspace).

... and PulseAudio 6.0, as you stated in another message, but which is not in Debian jessie. Therefore, commit b1ef29725865 does cause a regression (even though it's just a side effect): the Dell XPS 13 (2013) works just fine with a standard Debian jessie install and a current kernel. Sound worked fine until commit b1ef29725865 / works fine with commit b1ef29725865 reverted.

New kernels should continue to work on (reasonably) old userspace; and currently I do not see how this can be made to work with commit b1ef29725865 and no quirk / override. As soon as I find the time for that, I'll try to create a patch for that -- unless someone beats me to that.

Well, sound _is_ quite important to me; and as stated above, the laptop works just fine otherwise on Debian jessie (well, except the WiFi adapter, but that's another story).

You need PulseAudio 6.0 but otherwise yes, it works for me.

Quoted 1 line · Mark Brown

You need PulseAudio 6.0 but otherwise yes, it works for me.

Since there's no way to get this working without using new userspace, we're basically stuck with having to support _REV 5. And since we're supposed to support old userspace basically forever, this isn't going to be something that we can just remove in a few months. But since the hardware is intended to be used in I2S mode, we don't want this quirk to be there forever. So we're basically left with adding CONFIG_ACPI_WORKAROUND_BROKEN_DELLS which enables the quirk, default it to Y and then let distributions set it to N when they've got sufficiently new userspace. Unless someone has a better plan?

Quoted 4 lines · Matthew Garrett

to be there forever. So we're basically left with adding CONFIG_ACPI_WORKAROUND_BROKEN_DELLS which enables the quirk, default it to Y and then let distributions set it to N when they've got sufficiently new userspace. Unless someone has a better plan?

Just to be clear, from the Dell side only the XPS 13 9343 has this _REV behavior.

What's wrong with a DMI quirk until I2S is mature on the kernel side and userspace is new enough in distros? Is it too early in boot for DMI quirks?

That would enforce that no other machines can use _REV value of 5 to detect Linux without breaking the 9343.

Just to be clear, from the Dell side only the XPS 13 9343 has this _REV behavior.

What's wrong with a DMI quirk until I2S is mature on the kernel side and userspace is new enough in distros? Is it too early in boot for DMI quirks? That would enforce that no other machines can use _REV value of 5 to detect Linux without breaking the 9343.

Quoted 2 lines · Mario Limonciello

Just to be clear, from the Dell side only the XPS 13 9343 has this _REV behavior.

The Inspiron 7437 queries _REV and uses it to modify its EC behaviour, and apparently breaks on Linux without that.

Quoted 4 lines

What's wrong with a DMI quirk until I2S is mature on the kernel side and userspace is new enough in distros? Is it too early in boot for DMI quirks? That would enforce that no other machines can use _REV value of 5 to detect Linux without breaking the 9343.

DMI quirking is fine, but it has to be behind a config option. We're going to have to carry the quirk for several years because we have to support old userspace for an arbitrarily long time, and if there's no config option then Linux will be stuck in HDA mode for that entire time.

Quoted 2 lines · Mario Limonciello

Just to be clear, from the Dell side only the XPS 13 9343 has this _REV behavior.

The Inspiron 7437 queries _REV and uses it to modify its EC behaviour, and apparently breaks on Linux without that.

Quoted 4 lines

What's wrong with a DMI quirk until I2S is mature on the kernel side and userspace is new enough in distros? Is it too early in boot for DMI quirks? That would enforce that no other machines can use _REV value of 5 to detect Linux without breaking the 9343.

DMI quirking is fine, but it has to be behind a config option. We're going to have to carry the quirk for several years because we have to support old userspace for an arbitrarily long time, and if there's no config option then Linux will be stuck in HDA mode for that entire time.

Quoted 13 lines · Matthew Garrett

Quoted 2 lines · Mario Limonciello

Just to be clear, from the Dell side only the XPS 13 9343 has this _REV behavior.

The Inspiron 7437 queries _REV and uses it to modify its EC behaviour, and apparently breaks on Linux without that.

Quoted 4 lines

What's wrong with a DMI quirk until I2S is mature on the kernel side and userspace is new enough in distros? Is it too early in boot for DMI quirks? That would enforce that no other machines can use _REV value of 5 to detect Linux without breaking the 9343.

Quoted 5 lines

DMI quirking is fine, but it has to be behind a config option. We're going to have to carry the quirk for several years because we have to support old userspace for an arbitrarily long time, and if there's no config option then Linux will be stuck in HDA mode for that entire time.

One problem with the DMI-based approach is that _REV is constant in ACPICA, so to be able to return different values from it for different systems, we'll need to add some ACPICA-ish code handling that specifically for Linux and we're a bit too late in the cycle for that.

So here's what I'm going to do. I'll revert commit b1ef29725865 for 4.1, but *only* for 4.1 (I've actually queued up a revert of it already) and I'll revert that revert during the 4.2 merge window.

In the meantime, we'll develop the code to implement the DMI-based quirks for the Dells and apply it for 4.2.

Are there any volunteers for doing the last part?

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines · Matthew Garrett

Quoted 1 line · Mario Limonciello

Just to be clear, from the Dell side only the XPS 13 9343 has this _R=

EV

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

behavior.

=20
The Inspiron 7437 queries _REV and uses it to modify its EC behaviour, and apparently breaks on Linux without that.
=20

Quoted 1 line

What's wrong with a DMI quirk until I2S is mature on the kernel side =

and

Quoted 1 line

Quoted 1 line

Quoted 1 line

userspace is new enough in distros? Is it too early in boot for DMI =

quirks?

Quoted 1 line

Quoted 1 line

Quoted 1 line

That would enforce that no other machines can use _REV value of 5 to =

detect

Quoted 9 lines

Quoted 7 lines

Quoted 1 line

Linux without breaking the 9343.

=20
DMI quirking is fine, but it has to be behind a config option. We're going to have to carry the quirk for several years because we have to support old userspace for an arbitrarily long time, and if there's no config option then Linux will be stuck in HDA mode for that entire time.

=20
One problem with the DMI-based approach is that _REV is constant in ACPIC=

A,

Quoted 1 line

so to be able to return different values from it for different systems, w=

e'll

Quoted 6 lines

need to add some ACPICA-ish code handling that specifically for Linux and we're a bit too late in the cycle for that.
=20
So here's what I'm going to do. I'll revert commit b1ef29725865 for 4.1, but *only* for 4.1 (I've actually queued up a revert of it already) and I'll revert that revert during the 4.2 merge window.

Sounds like a good plan. Thanks!

Quoted 4 lines

In the meantime, we'll develop the code to implement the DMI-based quirks for the Dells and apply it for 4.2.
=20
Are there any volunteers for doing the last part?

Will try to prepare patches for that tomorrow.

Since there's no way to get this working without using new userspace, we're basically stuck with having to support _REV 5. And since we're supposed to support old userspace basically forever, this isn't going to be something that we can just remove in a few months. But since the hardware is intended to be used in I2S mode, we don't want this quirk to be there forever. So we're basically left with adding CONFIG_ACPI_WORKAROUND_BROKEN_DELLS which enables the quirk, default it to Y and then let distributions set it to N when they've got sufficiently new userspace. Unless someone has a better plan?