On 03/24/2015 03:02 PM, Rafael J. Wysocki wrote:
On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
While I agree in general, one comment.
We haven't decided about the patch yet. We may decide to bump up the _REV
to 6 when ACPI 6 is out instead.
I'd be happy with this too.
That said
On Tue, Mar 24, 2015 at 02:53:24PM -0500, Mario Limonciello wrote:
> On 03/24/2015 01:01 PM, Matthew Garrett wrote:
> >Will it? You haven't shipped the firmware that changes this behaviour
> >yet.
> >
> This was posted a few days ago. BIOS A02, it resolves the broken behavior
> introduced in A01
On 03/24/2015 01:01 PM, Matthew Garrett wrote:
On Tue, Mar 24, 2015 at 12:22:18PM -0500, Mario Limonciello wrote:
Since we don't expose any way for the platform to detect that it's
running Linux, yes.
Will it? You haven't shipped the firmware that changes this behaviour
yet.
This was posted
On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
> 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
On Tue, Mar 24, 2015 at 12:22:18PM -0500, Mario Limonciello wrote:
> At that time rt286 I2S wasn't even in the kernel. Bard didn't start
> to land it until later that year
> (https://github.com/torvalds/linux/commit/07cf7cbadb4d97a78be61119a406de8fe446467e).
>
> Was it really that crazy to
On 03/24/2015 10:24 AM, Matt Fleming wrote:
On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
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
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
On 03/24/2015 04:17 AM, Liam Girdwood wrote:
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote:
There is some work in progress here to standardise the jack kcontrols
between HDA, ASoC and other ALSA drivers. I would expect this to be
upstream in the next week or two.
UCM configs and
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote:
> I believe a majority of the kernel work is complete, but from some off
> kernel mailing list discussions I understand that pulseaudio doesn't
> understand the control interface that gets used for I2S for jack
> detection.
There is
On 03/24/2015 04:17 AM, Liam Girdwood wrote:
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote:
There is some work in progress here to standardise the jack kcontrols
between HDA, ASoC and other ALSA drivers. I would expect this to be
upstream in the next week or two.
UCM configs and
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
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote:
I believe a majority of the kernel work is complete, but from some off
kernel mailing list discussions I understand that pulseaudio doesn't
understand the control interface that gets used for I2S for jack
detection.
There is some
On Tue, Mar 24, 2015 at 12:22:18PM -0500, Mario Limonciello wrote:
At that time rt286 I2S wasn't even in the kernel. Bard didn't start
to land it until later that year
(https://github.com/torvalds/linux/commit/07cf7cbadb4d97a78be61119a406de8fe446467e).
Was it really that crazy to plan
On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
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
On 03/24/2015 01:01 PM, Matthew Garrett wrote:
On Tue, Mar 24, 2015 at 12:22:18PM -0500, Mario Limonciello wrote:
Since we don't expose any way for the platform to detect that it's
running Linux, yes.
Will it? You haven't shipped the firmware that changes this behaviour
yet.
This was posted
On 03/24/2015 03:02 PM, Rafael J. Wysocki wrote:
On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
While I agree in general, one comment.
We haven't decided about the patch yet. We may decide to bump up the _REV
to 6 when ACPI 6 is out instead.
I'd be happy with this too.
That said
On Tue, Mar 24, 2015 at 02:53:24PM -0500, Mario Limonciello wrote:
On 03/24/2015 01:01 PM, Matthew Garrett wrote:
Will it? You haven't shipped the firmware that changes this behaviour
yet.
This was posted a few days ago. BIOS A02, it resolves the broken behavior
introduced in A01 and
On 03/24/2015 10:24 AM, Matt Fleming wrote:
On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
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
On 03/23/2015 07:04 AM, Matt Fleming wrote:
On Mon, 16 Mar, at 04:21:51PM, Jason Ekstrand wrote:
Sadly no, Dell are not doing something useful. Their use of _REV is
entirely misguided for the same reasons using _OSI(Linux) is discouraged
in drivers/acpi/osl.c; namely that working around kernel
On Mon, 16 Mar, at 04:21:51PM, Jason Ekstrand wrote:
>
> A quick update on the Dell XPS 13 for those of you who are following
> this discussion but aren't aware of the XPS 13-specific discussions.
> The "problem" triggered by _REV=5 is not a *real* problem. The reason
> they special-cased it for
On Mon, 16 Mar, at 04:21:51PM, Jason Ekstrand wrote:
A quick update on the Dell XPS 13 for those of you who are following
this discussion but aren't aware of the XPS 13-specific discussions.
The problem triggered by _REV=5 is not a *real* problem. The reason
they special-cased it for the
On 03/23/2015 07:04 AM, Matt Fleming wrote:
On Mon, 16 Mar, at 04:21:51PM, Jason Ekstrand wrote:
Sadly no, Dell are not doing something useful. Their use of _REV is
entirely misguided for the same reasons using _OSI(Linux) is discouraged
in drivers/acpi/osl.c; namely that working around kernel
On Sat, Mar 14, 2015 at 12:58 PM, Jason Ekstrand wrote:
> From: Jason Ekstrand
>
> On Wed, 11 Mar 2015 22:50:47, Matthew Garrett wrote:
>> The ACPI spec describes _REV as:
>>
>> "This predefined object evaluates to the revision of the ACPI Specification
>> that the specified \_OS implements"
On Mon, Mar 16, 2015 at 02:34:24PM -0600, Al Stone wrote:
> More a philosophical question -- the patch seems fine to me, personally, and
> for arm64, we have to have >= 5 anyway -- but would it make sense to just not
> acknowledge _REV and deprecate it from the kernel and the spec? I'm already
>
On 03/12/2015 02:50 AM, Matthew Garrett wrote:
> The ACPI spec describes _REV as:
>
> "This predefined object evaluates to the revision of the ACPI Specification
> that the specified \_OS implements"
>
> We've been assuming that this should increment as ACPICA gains support for
> new versions
On 03/12/2015 02:50 AM, Matthew Garrett wrote:
The ACPI spec describes _REV as:
This predefined object evaluates to the revision of the ACPI Specification
that the specified \_OS implements
We've been assuming that this should increment as ACPICA gains support for
new versions of the
On Sat, Mar 14, 2015 at 12:58 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
From: Jason Ekstrand ja...@jlekstrand.net
On Wed, 11 Mar 2015 22:50:47, Matthew Garrett mj...@srcf.ucam.org wrote:
The ACPI spec describes _REV as:
This predefined object evaluates to the revision of the ACPI
On Mon, Mar 16, 2015 at 02:34:24PM -0600, Al Stone wrote:
More a philosophical question -- the patch seems fine to me, personally, and
for arm64, we have to have = 5 anyway -- but would it make sense to just not
acknowledge _REV and deprecate it from the kernel and the spec? I'm already
From: Jason Ekstrand
On Wed, 11 Mar 2015 22:50:47, Matthew Garrett wrote:
> The ACPI spec describes _REV as:
>
> "This predefined object evaluates to the revision of the ACPI Specification
> that the specified \_OS implements"
>
> We've been assuming that this should increment as ACPICA
From: Jason Ekstrand ja...@jlekstrand.net
On Wed, 11 Mar 2015 22:50:47, Matthew Garrett mj...@srcf.ucam.org wrote:
The ACPI spec describes _REV as:
This predefined object evaluates to the revision of the ACPI Specification
that the specified \_OS implements
We've been assuming that this
The ACPI spec describes _REV as:
"This predefined object evaluates to the revision of the ACPI Specification
that the specified \_OS implements"
We've been assuming that this should increment as ACPICA gains support for
new versions of the spec. Unfortunately, Windows always reports "2" for
The ACPI spec describes _REV as:
This predefined object evaluates to the revision of the ACPI Specification
that the specified \_OS implements
We've been assuming that this should increment as ACPICA gains support for
new versions of the spec. Unfortunately, Windows always reports 2 for this
32 matches
Mail list logo
