aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-11-06linaro:acpi enable SBSA uart driverleg-20141106.0Graeme Gregory
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06linaro-configs: add enterprise-distro.confGraeme Gregory
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06arm64: build FVP dtb files (LP: #1261402)Fathi Boudra
Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06linaro-configs: add acpi and efi fragmentsGraeme Gregory
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06arm64: add dts files from arm-trusted-firmware repoGraeme Gregory
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06DO NOT MERGE: patch for testing UpdateCapsule() runtime serviceSemen Protsenko
Change-Id: Ifa871bad23aceecc1c049e277df787f3616366fc Signed-off-by: Semen Protsenko <semen.protsenko@linaro.org>
2014-11-06Merge remote-tracking branch 'gg/leg-kernel' into leg-kernelGraeme Gregory
2014-11-06Merge branch 'acpi-topic-seattle' into leg-kernelGraeme Gregory
Conflicts: drivers/tty/sbsauart.c
2014-11-06arm64: avoid need for console= to enable serial consoleMark Salter
Tell kernel to prefer one of the serial ports on platforms pl011, 8250, or sbsa uarts. console= on command line will override these assumed preferences. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06AMD / XGBE : remove duplicate function definitionAl Stone
The function amd_xgbe_an_enable_kr_training ended up being defined twice. Removed the first definition in the file. Signed-off-by: Al Stone <al.stone@linaro.org>
2014-11-06drivers/of: fix new device property function that could return a bad valueAl Stone
Got a compiler warning: CC drivers/of/base.o drivers/of/base.c: In function ‘of_property_read_string_array’: drivers/of/base.c:1472:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ Added a 'return 0;' so the function always returns a value as it should. Signed-off-by: Al Stone <al.stone@linaro.org>
2014-11-06drivers/base: correct function prototype to remove compiler warningAl Stone
Ended up with this compiler warning: CC drivers/base/dma-coherent.o drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type .device_init = rmem_dma_device_init, ^ drivers/base/dma-coherent.c:303:2: warning: (near initialization for ‘rmem_dma_ops.device_init’) Correct the function definition for rmem_dma_device_init to match what's required for a reserved_mem struct. Signed-off-by: Al Stone <al.stone@linaro.org>
2014-11-06arm64/pci/acpi: initial support for ACPI probing of PCIAl Stone
This is a first pass of ACPI probing of PCI; much of it comes from existing ia64 and x86 code, and will need refactoring later. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06iommu/arm-smmu: fix NULL dereference with ACPI PCI devicesMark Salter
Fix a NULL dereference in find_mmu_master which occurs when booting with ACPI. In that case, PCI bridges with not have an of_node. Add a check for NULL of_node and bail out if that is the case. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06arm64/acpi/pci: provide hook for MCFG fixupsMark Salter
Some MCFG tables may be broken or the underlying hardware may not be fully compliant with the PCIe ECAM mechanism. This patch provides a mechanism to override the default mmconfig read/write routines and/or do other MCFG related fixups. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06arm64/acpi/pci: add support for parsing MCFG tableMark Salter
Add support for parsing MCFG table and provide functions to read/write PCI configuration space based on the parsed info. This provides the low-level raw_pci_read/raw_pci_write functionality. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06arm64/pci: replace weak raw pci ops with settable opsMark Salter
The current code provides placeholder weak functions for for raw_pci_read() and raw_pci_write(). This patch creates a global 'raw_pci_ops' variable which points to a struct containing read and write ops. The weak attribute is removed from raw_pci_read() and raw_pci_write() which will use the ops provided by the raw_pci_ops pointer. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06clocksource: arm_arch_timer: fix system hangMark Salter
Arm allows for two possible architectural clock sources. One memory mapped and the other coprocessor based. If both timers exist, then the driver waits for both to be probed before registering a clocksource. Commit c387f07e6205 ("clocksource: arm_arch_timer: Discard unavailable timers correctly") attempted to fix a hang occurring when one of the two possible timers had a device node, but was disabled. In that case, the second probe would never occur and the system would hang without a clocksource being registered. Unfortunately, incorrect logic in that commit made things worse such that a hang would occur unless both timers had a device node and were enabled. This patch fixes the logic so that we don't wait to probe a second timer unless it exists and is enabled. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06arm64: [NOT FOR UPSTREAM] fix dma_ops for ACPI and PCI devicesMark Salter
Commit 2189064795dc3fb4101e5: arm64: Implement set_arch_dma_coherent_ops() to replace bus notifiers removed the bus notifiers from dma-mapping.c. This patch adds the notifier back for ACPI and PCI devices until a better permanent solution is worked out. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06acpi: add utility to test for device dma coherencyMark Salter
ACPI 5.1 adds a _CCA object to indicate memory coherency of a bus master device. It is an integer with zero meaning non-coherent and one meaning coherent. This attribute may be inherited from a parent device. It may also be missing entirely, in which case, an architecture-specific default is assumed. This patch adds a utility function to parse a device handle (and its parents) for a _CCA object and return the coherency attribute if found. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06amd-xgbe: AMD 10GbE driver APCI support for A0Tom Lendacky
This patch provides ACPI support for the AMD 10GbE device driver and AMD 10GbE phy driver. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
2014-11-06input: gpio_keys_polled - Make use of device property APIAaron Lu
Make use of device property API in this driver so that both OF based system and ACPI based system can use this driver. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06leds: leds-gpio: Make use of device property APIRafael J. Wysocki
Make use of device property API in this driver so that both OF and ACPI based system can use the same driver. This change contains material from Max Eliaser and Mika Westerberg. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06gpio: Support for unified device properties interfaceMika Westerberg
Some drivers need to deal with only firmware representation of its GPIOs. An example would be a GPIO button array driver where each button is described as a separate firmware node in device tree. Typically these child nodes do not have physical representation in the Linux device model. In order to help device drivers to handle such firmware child nodes we add dev[m]_get_named_gpiod_from_child() that takes a child firmware node pointer as its second argument (the first one is the parent device itself), finds the GPIO using whatever is the underlying firmware method, and requests the GPIO properly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06Driver core: Unified interface for firmware node propertiesRafael J. Wysocki
Add new generic routines are provided for retrieving properties from device description objects in the platform firmware in case there are no struct device objects for them (either those objects have not been created yet or they do not exist at all). The following functions are provided: fwnode_property_present() fwnode_property_read_u8() fwnode_property_read_u16() fwnode_property_read_u32() fwnode_property_read_u64() fwnode_property_read_string() fwnode_property_read_u8_array() fwnode_property_read_u16_array() fwnode_property_read_u32_array() fwnode_property_read_u64_array() fwnode_property_read_string_array() in analogy with the corresponding functions for struct device added previously. For all of them, the first argument is a pointer to struct fwnode_handle (new type) that allows a device description object (depending on what platform firmware interface is in use) to be obtained. Add a new macro device_for_each_child_node() for iterating over the children of the device description object associated with a given device and a new function device_get_child_node_count() returning the number of a given device's child nodes. The interface covers both ACPI and Device Trees. Suggested-by: Grant Likely <grant.likely@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06input: gpio_keys_polled - Add support for GPIO descriptorsAaron Lu
GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06leds: leds-gpio: Add support for GPIO descriptorsMika Westerberg
GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06gpio: sch: Consolidate core and resume banksMika Westerberg
This is actually a single device with two sets of identical registers, which just happen to start from a different offset. Instead of having separate GPIO chips created we consolidate them to be single GPIO chip. In addition having a single GPIO chip allows us to handle ACPI GPIO translation in the core in a more generic way, since the two GPIO chips share the same parent ACPI device. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06gpio / ACPI: Add support for _DSD device propertiesMika Westerberg
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and other things as well) returned by _CRS. Previously we were only able to use integer index to find the corresponding GPIO, which is pretty error prone if the order changes. With _DSD we can now query GPIOs using name instead of an integer index, like the below example shows: // Bluetooth device with reset and shutdown GPIOs Device (BTH) { Name (_HID, ...) Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }}, } }) } The format of the supported GPIO property is: Package () { "name", Package () { ref, index, pin, active_low }} ref - The device that has _CRS containing GpioIo()/GpioInt() resources, typically this is the device itself (BTH in our case). index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero. active_low - If 1 the GPIO is marked as active_low. Since ACPI GpioIo() resource does not have field saying whether it is active low or high, the "active_low" argument can be used here. Setting it to 1 marks the GPIO as active low. In our Bluetooth example the "reset-gpio" refers to the second GpioIo() resource, second pin in that resource with the GPIO number of 31. This patch implements necessary support to gpiolib for extracting GPIOs using _DSD device properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06misc: at25: Make use of device property APIMika Westerberg
Make use of device property API in this driver so that both DT and ACPI based systems can use this driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06ACPI: Allow drivers to match using Device Tree compatible propertyMika Westerberg
We have lots of existing Device Tree enabled drivers and allocating separate _HID for each is not feasible. Instead we allocate special _HID "PRP0001" that means that the match should be done using Device Tree compatible property using driver's .of_match_table instead if the driver is missing .acpi_match_table. If there is a need to distinguish from where the device is enumerated (DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06Driver core: Unified device properties interface for platform firmwareRafael J. Wysocki
Add a uniform interface by which device drivers can request device properties from the platform firmware by providing a property name and the corresponding data type. The purpose of it is to help to write portable code that won't depend on any particular platform firmware interface. The following general helper functions are added: device_property_present() device_property_read_u8() device_property_read_u16() device_property_read_u32() device_property_read_u64() device_property_read_string() device_property_read_u8_array() device_property_read_u16_array() device_property_read_u32_array() device_property_read_u64_array() device_property_read_string_array() The first one allows the caller to check if the given property is present. The next 5 of them allow single-valued properties of various types to be retrieved in a uniform way. The remaining 5 are for reading properties with multiple values (arrays of either numbers or strings). The interface covers both ACPI and Device Trees. This change set includes material from Mika Westerberg and Aaron Lu. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06ACPI: Add support for device specific propertiesMika Westerberg
Device Tree is used in many embedded systems to describe the system configuration to the OS. It supports attaching properties or name-value pairs to the devices it describe. With these properties one can pass additional information to the drivers that would not be available otherwise. ACPI is another configuration mechanism (among other things) typically seen, but not limited to, x86 machines. ACPI allows passing arbitrary data from methods but there has not been mechanism equivalent to Device Tree until the introduction of _DSD in the recent publication of the ACPI 5.1 specification. In order to facilitate ACPI usage in systems where Device Tree is typically used, it would be beneficial to standardize a way to retrieve Device Tree style properties from ACPI devices, which is what we do in this patch. If a given device described in ACPI namespace wants to export properties it must implement _DSD method (Device Specific Data, introduced with ACPI 5.1) that returns the properties in a package of packages. For example: Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"name1", <VALUE1>}, Package () {"name2", <VALUE2>}, ... } }) The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301 and is documented in the ACPI 5.1 companion document called "_DSD Implementation Guide" [1], [2]. We add several helper functions that can be used to extract these properties and convert them to different Linux data types. The ultimate goal is that we only have one device property API that retrieves the requested properties from Device Tree or from ACPI transparent to the caller. [1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm [2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-06drivers: net: AMD Seattle XGBE PHY support for A0 siliconTom Lendacky
This patch modifies the upstream AMD XGBE PHY driver to support A0 Seattle silicon in currently shipping systems. The upstream Linux driver is targetted for Seattle B0 silicon. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06drivers: net: AMD Seattle XGBE 10GbE support for A0 siliconTom Lendacky
This patch modifies the upstream AMD 10GbE XGBE Ethernet driver to support A0 Seattle silicon in currently shipping systems. The upstream Linux driver is targetted for Seattle B0 silicon. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06arm64: add parking protocol supportMark Salter
This is a first-cut effort at parking protocol support. It is very much a work in progress (as is the spec it is based on). This code deviates from the current spec in a number of ways to work around current firmware issues and issues with kernels using 64K page sizes. caveat utilitor Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06ARM64 / ACPI: Introduce some PCI functions when PCI is enabledHanjun Guo
Introduce some PCI functions to make ACPI can be compiled when CONFIG_PCI is enabled, these functions should be revisited when implemented on ARM64. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> [fixed up for 3.17-rc] Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06Fix arm64 compilation error in PNP codeAl Stone
Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06ata: ahci_platform: Add ACPI support for AMD Seattle SATA controllerSuravee Suthikulpanit
This patch adds ACPI support for non-PCI SATA contoller in ahci_platform driver. It adds ACPI matching table in ahci_platform to support AMD Seattle SATA controller with following ASL structure in DSDT: Device (SATA0) { Name(_HID, "AMDI0600") // Seattle AHSATA Name (_CCA, 1) // Cache-coherent controller Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xE0300000, 0x00010000) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,,,) { 387 } }) } Since ATA driver should not require PCI support for ATA_ACPI, this patch also removes dependency in the driver/ata/Kconfig. Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
2014-11-06tty: SBSA compatible UARTGraeme Gregory
This is a subset of pl011 UART which does not supprt DMA or baud rate changing. It does, however, provide earlycon support (i.e., using "earlycon=ttySBSA" on the kernel command line). It is specified in the Server Base System Architecture document from ARM. Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06acpi: fix acpi_os_ioremap for arm64Mark Salter
The acpi_os_ioremap() function may be used to map normal RAM or IO regions. The current implementation simply uses ioremap_cache(). This will work for some architectures, but arm64 ioremap_cache() cannot be used to map IO regions which don't support caching. So for arm64, use ioremap() for non-RAM regions. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-06acpi: add arm to the platforms that use ioremapGraeme Gregory
Now with the base changes to the arm memory mapping it is safe to convert to using ioremap to map in the tables. Signed-off-by: Al Stone <al.stone@linaro.org> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
2014-11-06arm64: use EFI as last resort for reboot and poweroffMark Salter
Wire in support for EFI reboot and poweroff functions. We use these only if no other mechanism has been registered with arm_pm_reboot and/or pm_power_off respectively. Signed-off-by: Mark Salter <msalter@redhat.com>
2014-11-04Merge branch 'tracking-llct-misc-fixes' into merge-linux-linaro-core-trackingAndrey Konovalov
2014-11-04Merge branch 'tracking-linaro-builddeb-tweaks' into ↵Andrey Konovalov
merge-linux-linaro-core-tracking
2014-11-04Merge branch 'tracking-gator' into merge-linux-linaro-core-trackingAndrey Konovalov
2014-11-04Merge branch 'tracking-fixes-linaro-android-3.18' into ↵Andrey Konovalov
merge-linux-linaro-core-tracking
2014-11-04Merge branch 'tracking-linaro-android-3.18' into ↵Andrey Konovalov
merge-linux-linaro-core-tracking
2014-11-04Merge branch 'tracking-basic-board-configs' into ↵Andrey Konovalov
merge-linux-linaro-core-tracking
2014-11-04Merge branch 'tracking-core-configs' into merge-linux-linaro-core-trackingAndrey Konovalov