Eric Lee / smarc-fsl-linux-kernel

25 Feb, 2019

1 commit

16 Jan, 2019

1 commit

19 Mar, 2018

1 commit

06 Feb, 2018

1 commit

04 Aug, 2017

1 commit

  • 4eebedd8f   ACPICA: Divergences: reduce access size definitions ... Browse Code »

    ACPICA commit cf27b3c98883d2a15d932016792fcb8272ace96d

    The following commit introduces definition of access width to ACPICA.
    Commit: 2bece49394872d36bbc5767fd643deac05920c55
    Subject: ACPI: SPCR: Use access width to determine mmio usage

    Actually the access bit width can be calculated via access width. It
    would be better to define a macro calculating bit width rather than
    defining fixed values. This patch thus cleans up the definitions to
    reduce divergences.

    Link: https://github.com/acpica/acpica/commit/cf27b3c9
    Signed-off-by: Lv Zheng
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

11 Jul, 2017

1 commit

  • f19e80b39   Merge branches 'acpi-spcr', 'acpi-osi', 'acpi-bus', 'acpi-scan' and 'acpi-misc' ... Browse Code »

    * acpi-spcr:
    ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata
    ACPI: SPCR: Use access width to determine mmio usage

    * acpi-osi:
    ACPI / osi: Make local function acpi_osi_dmi_linux() static

    * acpi-bus:
    ACPI / bus: handle ACPI hotplug schedule errors completely

    * acpi-scan:
    ACPI / scan: Indicate to platform when hot remove returns busy

    * acpi-misc:
    ACPI / DPTF: constify attribute_group structures
    ACPI / LPSS: constify attribute_group structures
    ACPI: BGRT: constify attribute_group structures
    ACPI / power: constify attribute_group structures

    Rafael J. Wysocki
     

05 Jul, 2017

1 commit

  • 2bece4939   ACPI: SPCR: Use access width to determine mmio usage ... Browse Code »

    The current SPCR code does not check the access width of the MMIO, and
    uses a default of 8bit register accesses. This prevents devices that
    only do 16 or 32bit register accesses from working. By simply checking
    this field and setting the MMIO string appropriately, this issue can be
    corrected. To prevent any legacy issues, the code will default to 8bit
    accesses if the value is anything but 16 or 32.

    Signed-off-by: Jon Mason
    Signed-off-by: Loc Ho
    Acked-by: Greg Kroah-Hartman
    Signed-off-by: Rafael J. Wysocki

    Loc Ho
     

12 Jun, 2017

5 commits

  • 044b72395   ACPICA: ACPI 6.2: Add support for PinGroupConfig() resource ... Browse Code »

    ACPICA commit 08b83591c0db751769d61fa889f4f50f575aeffb

    PinGroupConfig() is analogous to PinGroupFunction() but instead of mode
    (muxing), it is used to apply specific fine-grained configuration to a
    set of referenced pins.

    The format of this new resource is:

    PinGroupConfig (Shared/Exclusive, PinConfigType, PinConfigValue,
    ResourceSource, ResourceSourceIndex, ResourceSourceLabel,
    ResourceUsage, DescriptorName, VendorData)

    The PinConfigType/PinConfigValue are the same used by PinConfig()
    resource.

    Here also the combination of ResourceSource and ResourceSourceLabel is
    used to specify the PinGroup() this resource refers to.

    Link: https://github.com/acpica/acpica/commit/08b83591
    Signed-off-by: Mika Westerberg
    Signed-off-by: Lv Zheng
    Signed-off-by: Bob Moore
    Signed-off-by: Rafael J. Wysocki

    Mika Westerberg
     
  • f8a6c8664   ACPICA: ACPI 6.2: Add support for PinGroupFunction() resource ... Browse Code »

    ACPICA commit bd9a745749eac7137cd23085e6bdeb322de14ea2

    PinGroupFunction() is a new resource introduced with ACPI 6.2. It is
    used with PinGroup() to configure specific mode for a set of pins
    exposed by a GPIO controller.

    The format of the resource is:

    PinGroupFunction (Shared/Exclusive, FunctionNumber, ResourceSource,
    ResourceSourceIndex, ResourceSourceLabel,
    ResourceUsage, DescriptorName, VendorData)

    The resource_source and ResourceSourceLabel fields are used to specify
    the PinGroup() resource referenced by PinGroupFunction().

    Device (GPIO)
    {
    Name (_CRS, ResourceTemplate () {
    PinGroup ("group1") {2, 3}
    PinGroup ("group2") {4, 5}
    ...
    })
    }

    Device (I2C)
    {
    Name (_CRS, ResourceTemplate () {
    PinGroupFunction (Exclusive, 6, "^GPIO", 0, "mygroup2")
    })
    }

    In the above example the PinGroupFunction() references the second
    PinGroup() resource (using label "mygroup2" and configures pins 4 and 5
    into mode 6.

    Link: https://github.com/acpica/acpica/commit/bd9a7457
    Signed-off-by: Mika Westerberg
    Signed-off-by: Lv Zheng
    Signed-off-by: Bob Moore
    Signed-off-by: Rafael J. Wysocki

    Mika Westerberg
     
  • fdaa09807   ACPICA: ACPI 6.2: Add support for PinGroup() resource ... Browse Code »

    ACPICA commit 7d928e3174fb19d7dc0066b03c30bea07c001563

    ACPI 6.2 introduced a new resource that is used to declare set of pins
    belonging to a GPIO controller. This resource is referenced by new
    PinGroupFunction() and PinGroupConfig() resources using ResourceSource
    and ResourceLabel fields.

    The PinGroup() resource looks like this:

    PinGroup (ResourceLabel, ResourceUsage, DescriptorName,
    VendorData) {Pin List}

    This resource should be listed in _CRS under the GPIO/pincontroller
    device providing these pins.

    Link: https://github.com/acpica/acpica/commit/7d928e31
    Signed-off-by: Mika Westerberg
    Signed-off-by: Lv Zheng
    Signed-off-by: Bob Moore
    Signed-off-by: Rafael J. Wysocki

    Mika Westerberg
     
  • 97028ce6f   ACPICA: ACPI 6.2: Add support for PinConfig() resource ... Browse Code »

    ACPICA commit a06fdba686cefccd5dd5b93b52fa0f1e3f984906

    ACPI 6.2 introduced a new resource that is used to specify fine-grained
    configuration of a pin or set of pins used by a device. The ASL syntax of
    this new resource looks like:

    PinConfig (Shared/Exclusive, PinConfigType, PinConfigValue,
    ResourceSource, ResourceSourceIndex, ResourceUsage,
    DescriptorName, Vendordata) {Pin List}

    PinConfigType is an integer with following accepted values:

    0x00 (Default) - No configuration is applied to the pin
    0x01 (Bias Pull-up) - Pin is pulled up using certain size resistor
    0x02 (Bias Pull-down) - Pin is pulled down using certain size resistor
    0x03 (Bias Default) - Set to default biasing
    0x04 (Bias Disable) - All bias settings will be disabled
    0x05 (Bias High Impedance) - Configure the pin as hi_z
    0x06 (Bias Bus Hold) - Configure the pin in a weak latch state where
    it drives the last value on a tristate bus
    0x07 (Drive Open Drain) - Configure the pin into open drain state
    0x08 (Drive Open Source) - Configure the pin into open source state
    0x09 (Drive Push Pull) - Configure the pin into push-pull state
    0x0a (Drive Strength) - How much the pin can supply current
    0x0b (Slew Rate) - Configure slew rate of the pin
    0x0c (Input Debounce) - Enable input debouncer for the pin
    0x0d (Input Schmitt Trigger) - Enable schmitt trigger for the pin
    0x0e - 0x7f - Reserved
    0x80 - 0xff - Vendor defined types

    The PinConfigValue depends on the type and is expressed as units
    suitable for that type (for example bias uses Ohms).

    Link: https://github.com/acpica/acpica/commit/a06fdba6
    Signed-off-by: Mika Westerberg
    Signed-off-by: Lv Zheng
    Signed-off-by: Bob Moore
    Signed-off-by: Rafael J. Wysocki

    Mika Westerberg
     
  • 2b7269306   ACPICA: ACPI 6.2: Add support for PinFunction() resource ... Browse Code »

    ACPICA commit 6bbc6357f7061f1243601adde0ea45f7a89274e0

    ACPI 6.2 introduced a new resource that is used to describe how certain
    pins are muxed for a device. The ASL syntax of this new resource looks
    like below:

    PinFunction(Shared, PinConfig, FunctionNumber, ResourceSource,
    ResourceSourceIndex, ResourceUsage, DescriptorName,
    VendorData) {Pin List}

    Which is pretty similar to GpioIo()/GpioInt() resources.

    Teach ACPICA about this new resource.

    Link: https://github.com/acpica/acpica/commit/6bbc6357
    Signed-off-by: Mika Westerberg
    Signed-off-by: Lv Zheng
    Signed-off-by: Bob Moore
    Signed-off-by: Rafael J. Wysocki

    Mika Westerberg
     

09 Feb, 2017

1 commit

05 May, 2016

1 commit

16 Jan, 2016

1 commit

05 Feb, 2015

1 commit

26 Jan, 2015

1 commit

  • a45de93eb   ACPICA: Resources: Provide common part for struct acpi_resource_address structures. ... Browse Code »

    struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts
    just at different offsets. To unify the parsing functions, OSPMs like Linux
    need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
    extract the shared data.

    This patch also synchronizes the structure changes to the Linux kernel.
    The usages are searched by matching the following keywords:
    1. acpi_resource_address
    2. acpi_resource_extended_address
    3. ACPI_RESOURCE_TYPE_ADDRESS
    4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
    And we found and fixed the usages in the following files:
    arch/ia64/kernel/acpi-ext.c
    arch/ia64/pci/pci.c
    arch/x86/pci/acpi.c
    arch/x86/pci/mmconfig-shared.c
    drivers/xen/xen-acpi-memhotplug.c
    drivers/acpi/acpi_memhotplug.c
    drivers/acpi/pci_root.c
    drivers/acpi/resource.c
    drivers/char/hpet.c
    drivers/pnp/pnpacpi/rsparser.c
    drivers/hv/vmbus_drv.c

    Build tests are passed with defconfig/allnoconfig/allyesconfig and
    defconfig+CONFIG_ACPI=n.

    Original-by: Thomas Gleixner
    Original-by: Jiang Liu
    Signed-off-by: Lv Zheng
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

18 Mar, 2014

1 commit

27 Feb, 2014

1 commit

  • 4ac4c5fad   ACPICA: Headers: Deploy #pragma pack (push) and (pop). ... Browse Code »

    Use push and pop to both guarantee that the correct alignment is used,
    and to restore the alignment to whatever it was before the header
    was included.

    It is reported that the #pragma pack(push/pop) directives are not supported
    by the specific GCCs, but this patch still doesn't affect kernel build
    as there are already #pragma pack([1]) directives used in the old ACPICA
    headers, which means there shouldn't be GCCs that are currently used to
    compile the ACPI kernels do not support #pragma pack() directives.

    References: https://bugs.acpica.org/show_bug.cgi?id=1058
    Signed-off-by: Bob Moore
    Signed-off-by: Lv Zheng
    Signed-off-by: Rafael J. Wysocki

    Bob Moore
     

11 Feb, 2014

1 commit

25 Jan, 2013

1 commit

10 Jan, 2013

2 commits

17 Jul, 2012

2 commits

17 Jan, 2012

1 commit

19 Jan, 2011

1 commit

23 Jan, 2010

2 commits

  • 5df7e6cb4   ACPICA: Remove obsolete ACPI_INTEGER (acpi_integer) type ... Browse Code »

    This type was introduced as the code was migrated from ACPI 1.0
    (with 32-bit AML integers) to ACPI 2.0 (with 64-bit integers). It
    is now obsolete and this change removes it from the ACPICA code
    base, replaced by u64. The original typedef has been retained
    for now for compatibility with existing device driver code.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     
  • a8357b0c9   ACPICA: Update all ACPICA copyrights and signons to 2010 ... Browse Code »

    Add 2010 copyright to all module headers and signons, including
    the Linux header. This affects virtually every file in the ACPICA
    core subsystem, iASL compiler, and all utilities.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     

31 Dec, 2008

1 commit

  • 50df4d8b0   ACPICA: Restructure includes into public/private ... Browse Code »

    acpi.h now includes only the "public" acpica headers. All other
    acpica headers are "private" and should not be included by acpica
    users. One new file, accommon.h is used to include the commonly
    used private headers for acpica code generation. Future plans
    are to move all private headers to a new subdirectory.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore