On Sun, 12 Jan, at 11:05:46AM, Matt Fleming wrote:
> On Sun, 12 Jan, at 01:30:23AM, Rafael J. Wysocki wrote:
> > On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> > > On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> > > >
> > > > I'm not sure 100%, but I *think* we need to
On Tuesday, January 14, 2014 12:09:08 PM joeyli wrote:
> 於 日，2014-01-12 於 01:30 +0100，Rafael J. Wysocki 提到：
> > OK
> >
> > I don't see any adverse effects of the patch below on a couple of my
> > test
> > boxes, but (a) they are Intel-based and (b) they are non-EFI, so it
> > would be
> > good to
On Mon, 2014-01-13 at 19:04 -0700, Toshi Kani wrote:
> On Sun, 2014-01-12 at 10:06 +0100, Borislav Petkov wrote:
> > On Sun, Jan 12, 2014 at 01:30:23AM +0100, Rafael J. Wysocki wrote:
> > > I don't see any adverse effects of the patch below on a couple of my test
> > > boxes, but (a) they are Intel
於 日，2014-01-12 於 01:30 +0100，Rafael J. Wysocki 提到：
> OK
>
> I don't see any adverse effects of the patch below on a couple of my
> test
> boxes, but (a) they are Intel-based and (b) they are non-EFI, so it
> would be
> good to give it a go on as many machines as reasonably possible.
>
> Thanks,
>
On Sun, 2014-01-12 at 10:06 +0100, Borislav Petkov wrote:
> On Sun, Jan 12, 2014 at 01:30:23AM +0100, Rafael J. Wysocki wrote:
> > I don't see any adverse effects of the patch below on a couple of my test
> > boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> > good to g
On Sun, 12 Jan, at 01:30:23AM, Rafael J. Wysocki wrote:
> On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> > On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> > >
> > > I'm not sure 100%, but I *think* we need to do that with interrupts
> > > enabled.
> > > At least after
On Sun, Jan 12, 2014 at 01:30:23AM +0100, Rafael J. Wysocki wrote:
> I don't see any adverse effects of the patch below on a couple of my test
> boxes, but (a) they are Intel-based and (b) they are non-EFI, so it would be
> good to give it a go on as many machines as reasonably possible.
>
> Thank
On Saturday, December 21, 2013 12:21:48 PM Matt Fleming wrote:
> On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
> >
> > I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> > At least after mm_init(), because it relies on things initialized there if I
> > remembe
On Fri, 20 Dec, at 11:18:56PM, Rafael J. Wysocki wrote:
>
> I'm not sure 100%, but I *think* we need to do that with interrupts enabled.
> At least after mm_init(), because it relies on things initialized there if I
> remember correctly.
>
> From what I can tell at the moment, it might be possibl
於 五，2013-12-20 於 22:45 +0100，Rafael J. Wysocki 提到：
> On Friday, December 20, 2013 01:10:26 PM H. Peter Anvin wrote:
> > On 12/19/2013 09:38 PM, joeyli wrote:
> > >
> > > If don't use EFI time, then the first priority is using ACPI TAD if it
> > > present. Due to ACPI TAD is a generic acpi device t
On 12/20/2013 02:53 AM, Thomas Renninger wrote:
> On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote:
>> On 12/19/2013 08:05 PM, joeyli wrote:
>>> Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
>>> Present" flag. ACPI spec doesn't have clear definition on this.
>>
On Friday, December 20, 2013 09:50:56 PM Matt Fleming wrote:
> On Fri, 20 Dec, at 01:43:38PM, H. Peter Anvin wrote:
> >
> > Possibly... will have to investigate. I would also ask if the same
> > applies to the PNP0B0x devices -- all we really need there is the
> > presence/absence indication and
On Fri, 20 Dec, at 01:43:38PM, H. Peter Anvin wrote:
>
> Possibly... will have to investigate. I would also ask if the same
> applies to the PNP0B0x devices -- all we really need there is the
> presence/absence indication and the I/O port base.
It's worth noting that efi_late_init() exists solel
On 12/20/2013 01:45 PM, Rafael J. Wysocki wrote:
>
> My understanding, however, is that to use the TAD, we don't actually need to
> create a struct acpi_device for it. We just need a handle to the ACPICA
> object which can be found using acpi_get_devices() as soon as the namespace
> has been extr
On Friday, December 20, 2013 01:10:26 PM H. Peter Anvin wrote:
> On 12/19/2013 09:38 PM, joeyli wrote:
> >
> > If don't use EFI time, then the first priority is using ACPI TAD if it
> > present. Due to ACPI TAD is a generic acpi device that's need OS parsing
> > DSDT table before set system time.
On 12/20/2013 01:10 PM, H. Peter Anvin wrote:
> On 12/19/2013 09:38 PM, joeyli wrote:
>>
>> If don't use EFI time, then the first priority is using ACPI TAD if it
>> present. Due to ACPI TAD is a generic acpi device that's need OS parsing
>> DSDT table before set system time.
>>
>> Either move DSDT
On 12/20/2013 12:32 PM, Matthew Garrett wrote:
> On Fri, 2013-12-20 at 12:29 -0800, H. Peter Anvin wrote:
>> Yes, but the TZ isn't all that critical, either. It certainly doesn't
>> matter at all for a pure Linux system.
>
> No, but it does matter for a great number of deployed Linux systems.
>
On 12/20/2013 07:16 AM, Matthew Garrett wrote:
> On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote:
>> On 12/19/2013 08:05 PM, joeyli wrote:
>>> Can we use EFI time services on x86_64 after Borislav's patches accepted
>>> to mainline?
>>>
>>
>> No.
>
> We will want to use them to (at minimum
On 12/19/2013 09:38 PM, joeyli wrote:
>
> If don't use EFI time, then the first priority is using ACPI TAD if it
> present. Due to ACPI TAD is a generic acpi device that's need OS parsing
> DSDT table before set system time.
>
> Either move DSDT parser from subsystem initial stage to start_kernel
On Fri, 2013-12-20 at 12:29 -0800, H. Peter Anvin wrote:
> Yes, but the TZ isn't all that critical, either. It certainly doesn't matter
> at all for a pure Linux system.
No, but it does matter for a great number of deployed Linux systems.
Dealing with the timezone over DST changes has been a per
Yes, but the TZ isn't all that critical, either. It certainly doesn't matter
at all for a pure Linux system.
Matthew Garrett wrote:
>On Fri, 2013-12-20 at 08:57 -0800, H. Peter Anvin wrote:
>> But we prefer the TAD for that. The case where the EFI runtime is
>the only source of that info is pr
On Fri, 2013-12-20 at 08:57 -0800, H. Peter Anvin wrote:
> But we prefer the TAD for that. The case where the EFI runtime is the only
> source of that info is problematic as they are known to not work at runtime.
> We could collect it at boot and then never change it, although you end up in
>
But we prefer the TAD for that. The case where the EFI runtime is the only
source of that info is problematic as they are known to not work at runtime.
We could collect it at boot and then never change it, although you end up in
definitional issues between EFI and the hw RTC.
Matthew Garrett
On Thu, 2013-12-19 at 20:22 -0800, H. Peter Anvin wrote:
> On 12/19/2013 08:05 PM, joeyli wrote:
> > Can we use EFI time services on x86_64 after Borislav's patches accepted
> > to mainline?
> >
>
> No.
We will want to use them to (at minimum) obtain the clock timezone.
Using them for general RT
On Thursday, December 19, 2013 08:22:08 PM H. Peter Anvin wrote:
> On 12/19/2013 08:05 PM, joeyli wrote:
> > Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> > Present" flag. ACPI spec doesn't have clear definition on this.
>
> According to the Microsoft requirements document
於 四，2013-12-19 於 20:22 -0800，H. Peter Anvin 提到：
> On 12/19/2013 08:05 PM, joeyli wrote:
> >
> > Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> > Present" flag. ACPI spec doesn't have clear definition on this.
> >
>
> According to the Microsoft requirements documents, such
On 12/19/2013 08:05 PM, joeyli wrote:
>
> Then that means the priority of PNP0B0x is higher then "CMOS RTC Not
> Present" flag. ACPI spec doesn't have clear definition on this.
>
According to the Microsoft requirements documents, such a platform is
broken and shouldn't exist.
> I look forward t
於 四，2013-12-19 於 06:59 -0800，H. Peter Anvin 提到：
> On 12/18/2013 11:43 PM, Lee, Chun-Yi wrote:
> > This patchset add the timezone support of ACPI TAD and EFI TIME, it
> > also add codes for adjusting system time base on the timezone value
> > from EFI TIME services when system boot.
>
> EFI time is
On Thu, 19 Dec 2013 06:59:55 -0800
"H. Peter Anvin" wrote:
> EFI time is something we used to support and ripped out, because it
> doesn't work well, *at all*.
>
> I am hyper-skeptical to reintroducing them, and *definitely* will veto
> reintroducing them on a system which has PNP0B0x devices pr
On 12/18/2013 11:43 PM, Lee, Chun-Yi wrote:
> This patchset add the timezone support of ACPI TAD and EFI TIME, it
> also add codes for adjusting system time base on the timezone value
> from EFI TIME services when system boot.
EFI time is something we used to support and ripped out, because it
doe
This patchset add the timezone support of ACPI TAD and EFI TIME, it
also add codes for adjusting system time base on the timezone value
from EFI TIME services when system boot.
Those patches bring the following changes:
+ Add ACPI driver against ACPI000E ACPI Time and Alarm Device.
+ Add RTC d
This patchset add the timezone support of ACPI TAD and EFI TIME, it
also add codes for adjusting system time base on the timezone value
from EFI TIME services when system boot.
Those patches bring the following changes:
+ Add ACPI driver against ACPI000E ACPI Time and Alarm Device.
+ Add RTC d
32 matches
Mail list logo
