[lkml]   [2015]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform
    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, 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 ought to be a "apic first/only" mode, which is then used on
    >>>> all modern systems (not just hw reduced).
    >>> Do we need some sort of platform-specific querying interfaces now too,
    >>> similar to cpu_has()? I.e., platform_has()...
    >>> if (platform_has(X86_PLATFORM_REDUCED_HW))
    >>> do stuff..
    >> more like
    >> platform_has(X86_PLATFORM_PIT)
    >> etc, one for each legacy io item
    > Precisely. The main problem is the generic, 'lumps everything
    > together' nature of the acpi_gbl_reduced_hardware flag.
    > (Like the big kernel lock lumped together all sorts of locking rules
    > and semantics.)
    > Properly split out, feature-ish or driver-ish interfaces for PIT and
    > other legacy details are the proper approach to 'turn them off'.
    > - x86_platform is a function pointer driven, driver-ish interface.
    > - platform_has(X86_PLATFORM_IT) is a flag driven, feature-flag-ish
    > interface.
    > Both are fine - for something as separate as the PIT (or the PIC) it
    > might make more sense to go towards a 'driver' interface though, as
    > modern drivers are (and will be) much different from the legacy PIT.
    > Whichever method is used, low level platforms can just switch them
    > on/off in their enumeration/detection routines, while the generic code
    > will have them enabled by default.

    Whichever method is used, we will face a problem how to determine PIT
    exists or not.

    When we enabled Bay Trail-T platform at the beginning, we were trying to
    make the code as generic as possible, and it works properly up to now.
    So we don't have a SUBARCH like X86_SUBARCH_INTEL_MID to use the
    platform specific functions. And for now I'm not quite sure it's a good
    idea to create one.

    If we make it as a flag driven, I don't know there is a flag in firmware
    better than ACPI HW reduced flag(Of course it's not good enough to cover
    all the cases). Or if we want to use platform info to turn on/off this
    flag, we'll have to maintain a platform list, which may be longer and
    more complicated than worth doing that.

    >> so we can clear it on hw reduced, but also in other cases. hw
    >> reduced is one way, but I'd be surprised if there weren't other ways
    >> (like quirks) where we'd want to do the same things
    > Exactly. The key step is the proper, clean separation out of hardware
    > interfaces.
    > Thanks,
    > Ingo

     \ /
      Last update: 2015-03-05 12:21    [W:2.326 / U:0.384 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site