On 2015/3/10 16:06, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
- in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'
- clean up 'global_clock_event' handling: instead of a global
variable, move its management into x86_platform_ops::get_clockevent()
* Li, Aubrey wrote:
> >> - in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'
> >>
> >> - clean up 'global_clock_event' handling: instead of a global
> >>variable, move its management into x86_platform_ops::get_clockevent()
> >>and set the method to hpet/pit/abp/etc. speci
On 2015/3/5 20:42, Li, Aubrey wrote:
> On 2015/3/5 19:36, Ingo Molnar wrote:
>>
>> * Li, Aubrey wrote:
>>
>>> On 2015/3/5 4:11, Ingo Molnar wrote:
* Arjan van de Ven wrote:
> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
>> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van
> Besides, the "ACPI reduced hardware" case is kind of a red herring here,
> because it most likely is not the only case when we'll want has_8259_pic()
> to return 0 (quite likely, we'll want that on all BayTrail-based systems,
> for example).
No. Only those with ACPI reduced firmware. For others
> I'll do more investigation above items but I want to leave at least
> these two as the quirk today unless I am convinced I can do that because
> from my understanding, UEFI runtime services should not be supported in
> reduced hw mode.
What actually matters in this space is what Microsoft does.
On 2015/3/5 19:36, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On 2015/3/5 4:11, Ingo Molnar wrote:
>>>
>>> * Arjan van de Ven wrote:
>>>
On 3/4/2015 1:50 AM, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
>>>
>>> Using 'acpi_gbl_
* Li, Aubrey wrote:
> On 2015/3/5 4:11, Ingo Molnar wrote:
> >
> > * Arjan van de Ven wrote:
> >
> >> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
> >>> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> >
> > Using 'acpi_gbl_reduced_hardware' flag outside the ACPI cod
On 2015/3/5 5:52, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 08:21:01 PM Alan Cox wrote:
>> On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
>>> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
Sort of. What we need is a "do not touch PIC/PIT" bit for t
On 2015/3/5 4:11, Ingo Molnar wrote:
>
> * Arjan van de Ven wrote:
>
>> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
>>> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
>
> Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> is a mistake.
ideally
On Wednesday, March 04, 2015 08:21:01 PM Alan Cox wrote:
> On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
> > On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
> > > Sort of. What we need is a "do not touch PIC/PIT" bit for the code that
> > > tries to fall back to them
On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
> > Sort of. What we need is a "do not touch PIC/PIT" bit for the code that
> > tries to fall back to them in some cases (which may appear to work if
> > the hardware is p
On Wed, 2015-03-04 at 10:50 +0100, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> > >
> > >Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> > >is a mistake.
> >
> > ideally, the presence of that flag in the firmware table will clear/set
* Arjan van de Ven wrote:
> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
> >On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> >>>
> >>>Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> >>>is a mistake.
> >>
> >>ideally, the presence of that flag in the firmware tabl
On 3/4/2015 1:50 AM, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
is a mistake.
ideally, the presence of that flag in the firmware table will clear/set more
global settings,
for example,
On Wednesday, March 04, 2015 03:05:55 PM Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
> > Sort of. What we need is a "do not touch PIC/PIT" bit for the code that
> > tries to fall back to them in some cases (which may appear to work if
> > the hardwar
On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
> Sort of. What we need is a "do not touch PIC/PIT" bit for the code that
> tries to fall back to them in some cases (which may appear to work if
> the hardware is physically there, but it may confuse the platform).
Can "some case
On Wednesday, March 04, 2015 10:50:11 AM Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> > >
> > >Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> > >is a mistake.
> >
> > ideally, the presence of that flag in the firmware table will clear
On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> >
> >Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> >is a mistake.
>
> ideally, the presence of that flag in the firmware table will clear/set more
> global settings,
> for example, having that flag should cause t
Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
is a mistake.
ideally, the presence of that flag in the firmware table will clear/set more
global settings,
for example, having that flag should cause the 8042 input code to not probe for
the 8042.
for interrupts, there really ough
* Li, Aubrey wrote:
> On 2015/3/4 13:31, Ingo Molnar wrote:
> >
> > * Li, Aubrey wrote:
> >
> >> On 2015/3/4 13:08, Ingo Molnar wrote:
> >>>
> >>> * Li, Aubrey wrote:
> >>>
> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
> initialized even though they may be
On 2015/3/4 13:31, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On 2015/3/4 13:08, Ingo Molnar wrote:
>>>
>>> * Li, Aubrey wrote:
>>>
On ACPI hardware reduced platform, the legacy PIC and PIT may not be
initialized even though they may be present in silicon. Touching
these leg
* Li, Aubrey wrote:
> On 2015/3/4 13:08, Ingo Molnar wrote:
> >
> > * Li, Aubrey wrote:
> >
> >> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
> >> initialized even though they may be present in silicon. Touching
> >> these legacy components causes unexpected result on
On 2015/3/4 13:08, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
>> initialized even though they may be present in silicon. Touching
>> these legacy components causes unexpected result on system.
>>
>> On Bay Trail-T(ASUS-T10
* Li, Aubrey wrote:
> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
> initialized even though they may be present in silicon. Touching
> these legacy components causes unexpected result on system.
>
> On Bay Trail-T(ASUS-T100) platform, touching these legacy components
>
On ACPI hardware reduced platform, the legacy PIC and PIT may not be
initialized even though they may be present in silicon. Touching
these legacy components causes unexpected result on system.
On Bay Trail-T(ASUS-T100) platform, touching these legacy components
blocks platform hardware low idle p
25 matches
Mail list logo
