Message-ID: <20150324152412.GA4706@codeblueprint.co.uk>
Date:	Tue, 24 Mar 2015 15:24:12 +0000
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Mario Limonciello <mario_limonciello@...l.com>
Cc:	Jason Ekstrand <jason@...kstrand.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Bard Liao <bardliao@...ltek.com>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	linux-acpi@...r.kernel.org, lenb@...nel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: Re: [PATCH] ACPI: Adjust the return value of _REV on x86

On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
>
> Aside from the mistake that was made in A01 ( which has been corrected
> for the recently released A02 ), the goal of this workaround is to be
> able to provide a more functional audio solution across a wider
> user-base.  Supporting HDA audio for Linux means that users from older
> kernels will still have a mostly working solution and not need to wait
> for the entire set of I2S kernel and userspace patches to land in
> their distro of choice.  We can't expect everyone to run the latest
> kernel just to have working audio.

Running a recent kernel is the tradeoff to be paid for using brand new
hardware. I certainly don't expect to be able to install a 4-year old
version of Fedora on a laptop released this year and have it work
flawlessly.

Besides, distributions aggressively backport patches for new hardware
support anyway and you should work with the distribution developers to
ensure that happens for your hardware. Preferably before it gets
released.

Because, fundamentally, when you make these decisions about Linux in the
BIOS you're pitting the BIOS and kernel development models against each
other. What is going to happen when i2s/i2c finally works correctly in
the kernel and distros? It would seem unlikely that a BIOS update would
be available to switch everyone to that mode.

> The entire I2S experience is maturing (thanks Bard), but even in
> 4.0-rc5 there are still gaps.

I'm sure the audio folks would love to hear about them.

> >Non-Windows BIOS code paths are not validated to the same degree as
> >those traversed by running Windows, which is exactly why we try so hard
> >to emulate Windows whenever we interact with the BIOS.
>
> To be clear - this codepath is activating the Windows 7 audio
> experience even when Windows 8.1 is detected (Windows 2013 _OSI
> responds True).  It's still a Windows BIOS codepath and it's still
> heavily validated.  There are 3 values you'll find in a decompiled
> DSDT to achieve this in the _REV test block.  2 of them are used to
> provide inputs into the EC to toggle HDA or I2S mode.  The other
> modifies what ACPI audio device is presented to the system.  There
> isn't a special OS type to represent Linux here.  The selected OSTP
> corresponds to the Windows 7 OS type.
 
Thanks, that is clearer and it does address my concerns about Linux-only
code paths in the BIOS. But the use of _REV is still only exists to
detect Linux (or more accurately an ACPICA OS), and that's a big issue.

> In any case, if the _REV patch does land in the kernel, I think (we)
> Dell will still be mostly happy with the results.  Anything older than
> 4.x won't contain the the _REV patch and will run in HDA mode.

Unless the patch gets backported to stable kernel versions older than
4.x. Which is likely.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists