From 3712655914530479b424e6f3db2130c48b931a41 Mon Sep 17 00:00:00 2001 From: Alessio Igor Bogani Date: Wed, 8 Apr 2015 11:04:39 +0200 Subject: of: add vendor prefix for Artesyn Signed-off-by: Alessio Igor Bogani Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index fae26d014aaf..404dc47f5dae 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -23,6 +23,7 @@ apm Applied Micro Circuits Corporation (APM) arasan Arasan Chip Systems arm ARM Ltd. armadeus ARMadeus Systems SARL +artesyn Artesyn Embedded Technologies Inc. asahi-kasei Asahi Kasei Corp. atmel Atmel Corporation auo AU Optronics Corporation -- cgit v1.2.3 From 65a71007a20cfe7ebd456d72c0bb155fe42de963 Mon Sep 17 00:00:00 2001 From: Kevin Cernekee Date: Thu, 9 Apr 2015 13:05:16 -0700 Subject: of: Document {little,big,native}-endian bindings These apply to newly converted drivers, like serial8250/libahci/... The examples were adapted from the regmap bindings document. Signed-off-by: Kevin Cernekee Reviewed-by: Peter Hurley Acked-by: Greg Kroah-Hartman Signed-off-by: Rob Herring --- .../devicetree/bindings/common-properties.txt | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/common-properties.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/common-properties.txt b/Documentation/devicetree/bindings/common-properties.txt new file mode 100644 index 000000000000..3193979b1d05 --- /dev/null +++ b/Documentation/devicetree/bindings/common-properties.txt @@ -0,0 +1,60 @@ +Common properties + +The ePAPR specification does not define any properties related to hardware +byteswapping, but endianness issues show up frequently in porting Linux to +different machine types. This document attempts to provide a consistent +way of handling byteswapping across drivers. + +Optional properties: + - big-endian: Boolean; force big endian register accesses + unconditionally (e.g. ioread32be/iowrite32be). Use this if you + know the peripheral always needs to be accessed in BE mode. + - little-endian: Boolean; force little endian register accesses + unconditionally (e.g. readl/writel). Use this if you know the + peripheral always needs to be accessed in LE mode. + - native-endian: Boolean; always use register accesses matched to the + endianness of the kernel binary (e.g. LE vmlinux -> readl/writel, + BE vmlinux -> ioread32be/iowrite32be). In this case no byteswaps + will ever be performed. Use this if the hardware "self-adjusts" + register endianness based on the CPU's configured endianness. + +If a binding supports these properties, then the binding should also +specify the default behavior if none of these properties are present. +In such cases, little-endian is the preferred default, but it is not +a requirement. The of_device_is_big_endian() and of_fdt_is_big_endian() +helper functions do assume that little-endian is the default, because +most existing (PCI-based) drivers implicitly default to LE by using +readl/writel for MMIO accesses. + +Examples: +Scenario 1 : CPU in LE mode & device in LE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... + native-endian; +}; + +Scenario 2 : CPU in LE mode & device in BE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... + big-endian; +}; + +Scenario 3 : CPU in BE mode & device in BE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... + native-endian; +}; + +Scenario 4 : CPU in BE mode & device in LE mode. +dev: dev@40031000 { + compatible = "name"; + reg = <0x40031000 0x1000>; + ... + little-endian; +}; -- cgit v1.2.3 From 4155fc07fa9fd691d424e7f8fb64591cccb88788 Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Fri, 20 Mar 2015 17:57:47 +0000 Subject: Doc: dt: arch_timer: discourage clock-frequency use The ARM Generic Timer (AKA the architected timer, arm_arch_timer) features a CPU register (CNTFRQ) which firmware is intended to initialize, and non-secure software can read to determine the frequency of the timer. On CPUs with secure state, this register cannot be written from non-secure states. The firmware of early SoCs featuring the timer did not correctly initialize CNTFRQ correctly on all CPUs, requiring the frequency to be described in DT as a workaround. This workaround is not complete however as it is exposed to all software in a privileged non-secure mode (including guests running under a hypervisor). The firmware and DTs for recent SoCs have followed the example set by these early SoCs. This patch updates the arch timer binding documentation to make it clearer that the use of the clock-frequency property is a poor work-around. The MMIO generic timer binding is similarly updated, though this is less of a concern as there is generally no need to expose the MMIO timers to guest OSs. Signed-off-by: Mark Rutland Acked-by: Catalin Marinas Acked-by: Marc Zyngier Acked-by: Olof Johansson Acked-by: Stephen Boyd Cc: Rob Herring Cc: Will Deacon Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 256b4d8bab7b..e774128935d5 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. - interrupts : Interrupt list for secure, non-secure, virtual and hypervisor timers, in that order. -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only where necessary to work around broken firmware which does not configure + CNTFRQ on all CPUs to a uniform correct value. Use of this property is + strongly discouraged; fix your firmware unless absolutely impossible. - always-on : a boolean property. If present, the timer is powered through an always-on power domain, therefore it never loses context. @@ -46,7 +49,8 @@ Example: - compatible : Should at least contain "arm,armv7-timer-mem". -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only when firmware has not configured the MMIO CNTFRQ registers. - reg : The control frame base address. -- cgit v1.2.3 From f3b07b8611ede9584ef27288d9c35bc2fd7a8353 Mon Sep 17 00:00:00 2001 From: Dinh Nguyen Date: Mon, 20 Apr 2015 09:55:47 -0500 Subject: Documentation: DT bindings: add doc for Altera's SoCFPGA platform Document "altr,socfpga-cyclone5", "altr,socfpga-arria5", and "altr,socfpga-arria10". Signed-off-by: Dinh Nguyen Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/altera.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/altera.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/altera.txt b/Documentation/devicetree/bindings/arm/altera.txt new file mode 100644 index 000000000000..558735aacca8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/altera.txt @@ -0,0 +1,14 @@ +Altera's SoCFPGA platform device tree bindings +--------------------------------------------- + +Boards with Cyclone 5 SoC: +Required root node properties: +compatible = "altr,socfpga-cyclone5", "altr,socfpga"; + +Boards with Arria 5 SoC: +Required root node properties: +compatible = "altr,socfpga-arria5", "altr,socfpga"; + +Boards with Arria 10 SoC: +Required root node properties: +compatible = "altr,socfpga-arria10", "altr,socfpga"; -- cgit v1.2.3