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]

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]

[Dominik Brodowski]

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...


On Mon, May 04, 2015 at 06:26:25PM -0500, Mario Limonciello wrote:
> 
> On 04/28/2015 06:21 PM, Mario Limonciello wrote:
> >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,

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]

[Mario Limonciello]

On 05/11/2015 01:26 PM, Dominik Brodowski wrote:
> 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...
>
>
Dominik,

Yes I've noticed it's acting much worse for me too with 4.1-rc2 on Ubuntu 15.04 userspace (which is quite new indeed).  I really think the right solution is some sort of quirk against the XPS 13 on the _REV behavior until this is reasonably mature.

OT: Yes, this feedback has been taken to heart by the team.  We're working on adding more variants with alternate adapters.  :)

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]

[Jie, Yang]

+Liam.

> -----Original Message-----
> From: Dominik Brodowski [mailto:linux@dominikbrodowski.net]
> Sent: Tuesday, May 12, 2015 2:27 AM
> To: Mario Limonciello; Moore, Robert; Zheng, Lv; Wysocki, Rafael J
> Cc: linux-acpi@vger.kernel.org; broonie@kernel.org; Lu, Han; Jie, Yang; alsa-
> devel@alsa-project.org
> 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.
 
Lacking of IntcPP01.bin should not block Broadwell ADSP audio functions.

Suppose these should be the same issues Mark told us, right?

Yes, we are doing some fixes in alsa-lib/ucm/config part, without these fixes,
You can do manual volume +/- and switches on/off in alsamixer GUI interface.

BTW, if you can create kernel.org bugs to descript these issues, it will be helpful
for to trace and fix them after we got this XPS 13 machine.

Thanks,
~Keyon

> 
> 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...
> 
> 
> On Mon, May 04, 2015 at 06:26:25PM -0500, Mario Limonciello wrote:
> >
> > On 04/28/2015 06:21 PM, Mario Limonciello wrote:
> > >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,

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]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

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.

> 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.

> 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.

> 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).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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]

[Mario Limonciello]

On 05/12/2015 05:12 AM, Mark Brown wrote:
> 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.
>
>> 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.
>
>> 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.
>
>> 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).
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.

Keyon,

There is a bug opened at https://bugzilla.kernel.org/show_bug.cgi?id=93361.  I've added updated notes to this for 4.1-rc3 experience.

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]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

On Tue, May 12, 2015 at 10:26:24AM -0500, Mario Limonciello wrote:
> On 05/12/2015 05:12 AM, Mark Brown wrote:
> >On Mon, May 11, 2015 at 08:26:58PM +0200, Dominik Brodowski wrote:

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.

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

> >>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.

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

> >>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.

Yes, it is.

> >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:

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.

> 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.

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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]

[Mario Limonciello]

On 05/12/2015 11:18 AM, Mark Brown wrote:
>
> 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.

Sorry about that, I've adjusted my mail client settings.

> You need PulseAudio 6.0 but otherwise yes, it works for me.
Ubuntu 15.04 is running Pulseaudio 6.0.
>
> 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.
>
These are the different flows supported and what changes in the 
different flows.
This is up to date as of BIOS A03:

When Linux is detected (_OSI Windows 2013 & _REV 5):
* EC configures the audio controller for HDA mode on next cold boot.
* HDA audio device is included in PCI address space.
* Touchpad is put into I2C mode.

When Windows 8.1 is detected or currently Linux 4.1 (_OSI Windows 2013 & 
_REV 2):
* EC configures the audio controller for I2S mode on next cold boot.
* ADSP audio device included in ACPI (INT3438).
* Touchpad is put in I2C mode.

When Windows 7 is detected (_OSI Windows 2009):
* EC configures the audio controller for HDA mode on the next cold boot.
* HDA audio device included in PCI address space.
* Touchpad is put in PS2 mode.

> 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.

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]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

On Tue, May 12, 2015 at 11:45:40AM -0500, Mario Limonciello wrote:

> >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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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]

[Jie, Yang]

> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Wednesday, May 13, 2015 1:35 AM
> To: Mario Limonciello
> Cc: Dominik Brodowski; Moore, Robert; Zheng, Lv; Wysocki, Rafael J; linux-
> acpi@vger.kernel.org; Lu, Han; Jie, Yang; alsa-devel@alsa-project.org;
> 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]
> 
> On Tue, May 12, 2015 at 11:45:40AM -0500, Mario Limonciello wrote:
> 
> > >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.
> 
> 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

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]

[Mario Limonciello]

On 05/12/2015 09:14 PM, Jie, Yang wrote:
>   
> 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
>
>

Keyon,

Yes, if I kill pulseaudio (and prevent it from starting back up), I am 
able to get audio by running:
speaker-test -c 2 -t wav -D plughw:broadwellrt286

I've tried to remove .config/pulse, but it's still not working at all 
when pulse launches up.

Thanks,

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]

[Matthew Garrett]

On Tue, May 12, 2015 at 9:18 AM, Mark Brown <broonie@kernel.org> wrote:
> 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?

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]

[Mario Limonciello]

On 05/12/2015 12:21 PM, Matthew Garrett wrote:
> On Tue, May 12, 2015 at 9:18 AM, Mark Brown <broonie@kernel.org> wrote:
>> 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?
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.

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]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Tue, May 12, 2015 at 12:29:48PM -0500, Mario Limonciello wrote:
> On 05/12/2015 12:21 PM, Matthew Garrett wrote:

> >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?

If we're waiting for distros to have new enough userspace we're looking
at waiting several years at least, especially when you start looking at
distros like Debian (which two of the users in this thread are, though
I'm not on stable).

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

What Matthew suggested was making the quirk a compile time option.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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]

[Matthew Garrett]

On Tue, May 12, 2015 at 10:29 AM, Mario Limonciello
<mario_limonciello@dell.com> wrote:
> 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.

> 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.

-- 
Matthew Garrett | matthew.garrett@coreos.com

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]

[Mario Limonciello]

On 05/12/2015 12:43 PM, Matthew Garrett wrote:
> On Tue, May 12, 2015 at 10:29 AM, Mario Limonciello
> <mario_limonciello@dell.com> wrote:
>> 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.
Thanks for bringing this to my attention.  I'll check with my BIOS 
architecture team on this.  XPS 13 9343 was supposed to be the only 
system doing this.

>> 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.
>

OK, that makes more sense to me.  Thanks.

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]

[Rafael J. Wysocki]

On Tuesday, May 12, 2015 10:43:33 AM Matthew Garrett wrote:
> On Tue, May 12, 2015 at 10:29 AM, Mario Limonciello
> <mario_limonciello@dell.com> wrote:
> > 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.
> 
> > 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.

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?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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]

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

On Wed, May 13, 2015 at 01:38:59AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, May 12, 2015 10:43:33 AM Matthew Garrett wrote:
> > On Tue, May 12, 2015 at 10:29 AM, Mario Limonciello
> > <mario_limonciello@dell.com> wrote:
> > > 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.
> > 
> > > 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.
> 
> 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.

Sounds like a good plan. Thanks!

> 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?

Will try to prepare patches for that tomorrow.

Best,
	Dominik

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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]

[Rafael J. Wysocki]

On Wednesday, May 13, 2015 08:36:47 AM Dominik Brodowski wrote:
> 
> --3MwIy2ne0vdjdPXF
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Wed, May 13, 2015 at 01:38:59AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, May 12, 2015 10:43:33 AM Matthew Garrett wrote:
> > > On Tue, May 12, 2015 at 10:29 AM, Mario Limonciello
> > > <mario_limonciello@dell.com> wrote:
> > > > Just to be clear, from the Dell side only the XPS 13 9343 has this _R=
> EV
> > > > behavior.
> > >=20
> > > The Inspiron 7437 queries _REV and uses it to modify its EC behaviour,
> > > and apparently breaks on Linux without that.
> > >=20
> > > > 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.
> > >=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,
> > so to be able to return different values from it for different systems, w=
> e'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.
> >=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!
> 
> > 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.

Thanks a lot!
 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Tue, May 12, 2015 at 10:21:41AM -0700, Matthew Garrett wrote:

> 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?

That makes sense to me given that the firmware doesn't seem to do
anything problematic in Linux mode - hopefully we won't have too many
more of these systems to contend with.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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]

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

Mark,

On Tue, May 12, 2015 at 11:12:58AM +0100, Mark Brown wrote:
> > 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.

... 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.

> > 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).

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).

Best,
	Dominik

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Tue, May 12, 2015 at 07:13:46PM +0200, Dominik Brodowski wrote:

> ... 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.

IIRC I wasn't getting a useful GUI out of the box with Jessie either,
though that could've been installer stuff - I can't remember any more
(and the support for high DPI displays within the installer itself makes
me happy I've got an eye checkup booked soon).

> 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).

I just swapped my WiFi adaptor out for an Intel card, fairly easy to do.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]