* Re: [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Nishanth Menon @ 2014-02-11 14:17 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: bcousson, balbi, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, Hans de Goede
In-Reply-To: <52FA2B4F.3010408@ti.com>
On 02/11/2014 07:53 AM, Roger Quadros wrote:
> On 02/10/2014 08:10 PM, Roger Quadros wrote:
>> The OMAP EHCI controller is not compatible with the EHCI
>> platform HCD driver so don't claim that we are.
>>
>> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
>> e.g. multi_v7_defconfig
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>
> Please ignore this patch as Hans has agreed to do a more proper fix in
>
> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015
umm.. even then, drivers/usb/host/ehci-ppc-of.c claims compatibility
with usb,ehci -> and we wont function with that driver either.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH RFC v3 0/3] ARM: defining idle states DT bindings
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-kernel, linux-pm, Lorenzo Pieralisi, Dave Martin,
Mark Rutland, Sudeep Holla, Charles Garcia Tobin, Nicolas Pitre,
Rob Herring, Peter De Schrijver, Grant Likely, Kumar Gala,
Santosh Shilimkar, Russell King, Mark Hambleton, Hanjun Guo,
Daniel Lezcano, Amit Kucheria, Vincent Guittot, Antti Miettinen,
Stephen Boyd, Tomasz Figa, Kevin
This is v3 of a previous posting:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226901.html
This patchset depends on the following bindings to be approved and augmented
to cater for hierarchical power domains in DT:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224928.html
Changes in v3:
- Renamed C-states to "idle states" in patches and cover letter
- Added SBSA definitions
- Added power_state parameter to PSCI
- Removed OPP dependency
- Split latency into entry/exit latencies
- Reintroduced processor and cache retention boolean
- Made power_state generic parameter for all entry methods
- Redefined idle state hierarchy
Changes in v2:
- Updated cache bindings according to review
- Added power domain phandle to cache bindings
- Added power domains to C-states bindings
- Removed useless reg property from C-states bindings
- Removed cpu-map references from C-states bindings
- Added dependency on OPP in C-states parameters
- Added C-state state hierarchy
ARM based systems embed power management HW that allows SW to enter
low-power states according to run-time criteria based on parameters (eg
power state entry/exit latency) that define how an idle state has to be
managed and its respective properties. ARM partners implement HW power
management schemes through custom HW, with power controllers and relative
control mechanisms differing on both HW implementations and the way SW can
control them. This differentiation forces PM software in the kernel to cope
with states differences in power management drivers, which cause code
fragmentation and duplication of functionality.
Most of the power control scheme HW parameters are not probeable on ARM
platforms from a SW point of view, hence, in order to tackle the drivers
fragmentation problem, this patch series defines device tree bindings to
describe idle states parameters on ARM platforms.
Device tree bindings for idle states also require the introduction of device
tree bindings for processor caches, since idle states entry/exit require
SW cache maintainance; in some ARM systems, where firmware does not
support power down interfaces, cache maintainance must be carried out in the
OS power management layer, which then requires a description of the cache
topology through device tree nodes.
Idle states device tree standardization shares most of the concepts and
definitions with the ongoing ACPI ARM C-state bindings proposal so that
both standards can contain a coherent set of parameters, simplifying the
way SW will have to handle the respective device drivers.
Lorenzo Pieralisi (3):
Documentation: devicetree: psci: define CPU suspend parameter
Documentation: arm: add cache DT bindings
Documentation: arm: define DT idle states bindings
Documentation/devicetree/bindings/arm/cache.txt | 165 +++
Documentation/devicetree/bindings/arm/cpus.txt | 10 +
Documentation/devicetree/bindings/arm/idle-states.txt | 690 ++++++++++
Documentation/devicetree/bindings/arm/psci.txt | 7 +
4 files changed, 872 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cache.txt
create mode 100644 Documentation/devicetree/bindings/arm/idle-states.txt
--
1.8.4
^ permalink raw reply
* [PATCH RFC v3 1/3] Documentation: devicetree: psci: define CPU suspend parameter
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-kernel, linux-pm, Lorenzo Pieralisi, Dave Martin,
Mark Rutland, Sudeep Holla, Charles Garcia Tobin, Nicolas Pitre,
Rob Herring, Peter De Schrijver, Grant Likely, Kumar Gala,
Santosh Shilimkar, Russell King, Mark Hambleton, Hanjun Guo,
Daniel Lezcano, Amit Kucheria, Vincent Guittot, Antti Miettinen,
Stephen Boyd, Tomasz Figa, Kevin
In-Reply-To: <1392128273-8614-1-git-send-email-lorenzo.pieralisi@arm.com>
OS layers built on top of PSCI to enter low-power states require the
power_state parameter to be passed to the PSCI CPU suspend method.
This parameter is specific to a power state and platform specific,
therefore must be provided by firmware to the OS in order to enable
proper call sequence.
This patch adds a property in the PSCI bindings that describes how
the CPU suspend power_state parameter should be defined in DT in
all device nodes that rely on PSCI CPU suspend method usage.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
Documentation/devicetree/bindings/arm/psci.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index 433afe9..6fc32a5 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -42,6 +42,13 @@ Main node optional properties:
- migrate : Function ID for MIGRATE operation
+Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
+states bindings) must specify the following properties:
+
+- power-state
+ Value type: <u32>
+ Definition: power_state parameter to pass to the PSCI
+ suspend call.
Example:
--
1.8.4
^ permalink raw reply related
* [PATCH RFC v3 2/3] Documentation: arm: add cache DT bindings
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-kernel, linux-pm, Lorenzo Pieralisi, Dave Martin,
Mark Rutland, Sudeep Holla, Charles Garcia Tobin, Nicolas Pitre,
Rob Herring, Peter De Schrijver, Grant Likely, Kumar Gala,
Santosh Shilimkar, Russell King, Mark Hambleton, Hanjun Guo,
Daniel Lezcano, Amit Kucheria, Vincent Guittot, Antti Miettinen,
Stephen Boyd, Tomasz Figa, Kevin
In-Reply-To: <1392128273-8614-1-git-send-email-lorenzo.pieralisi@arm.com>
On ARM systems the cache topology cannot be probed at runtime, in
particular, it is impossible to probe which CPUs share a given cache
level. Power management software requires this knowledge to implement
optimized power down sequences, hence this patch adds a document that
defines the DT cache bindings for ARM systems. The bindings supersede
cache bindings in the ePAPR (PowerPC bindings), because caches geometry for
architected caches is probeable on ARM systems. This patch also adds
properties that are specific to ARM architected caches to the existing ones
defined in the ePAPR v1.1, as bindings extensions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
Documentation/devicetree/bindings/arm/cache.txt | 165 ++++++++++
1 file changed, 165 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt
new file mode 100644
index 0000000..bd9f3d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cache.txt
@@ -0,0 +1,165 @@
+==========================================
+ARM processors cache binding description
+==========================================
+
+Device tree bindings for cache nodes are already part of the ePAPR standard
+v1.1 ([2]) for PowerPC platforms. This document defines the cache bindings
+for caches on ARM processor systems.
+
+On ARM based systems most of the cache properties related to cache geometry
+are probeable in HW (please refer to the processor TRMs in [1] for register
+details), hence, unless otherwise stated, the properties defined in ePAPR for
+internal, multi-level and shared caches ([2], 3.7.3, 3.8) are to be considered
+superseded on ARM.
+
+On ARM, caches are either architected (directly controlled by the processor
+through coprocessor instructions and tightly coupled with the processor
+implementation) or unarchitected (controlled through a memory mapped
+interface, implemented as a stand-alone IP external to the processor
+implementation).
+
+This document provides the device tree bindings for ARM architected caches.
+
+- ARM architected cache node
+
+ Description: must be a direct child of the cpu node.
+ A system can contain multiple architected cache nodes
+ per cpu node, linked through the next-level-cache phandle.
+ The next-level-cache property in the cpu node points to
+ the first level of architected cache for the CPU.
+ The next-level-cache links ordering must represent the
+ system cache hierarchy in the system, with the upper
+ cache level represented by a cache node with a missing
+ next-level-cache property.
+
+ ARM architected cache node defines the following properties:
+
+ - compatible
+ Usage: Required
+ Value type: <string>
+ Definition: value shall be "arm,arch-cache".
+
+ - power-domain
+ Usage: Optional
+ Value type: phandle
+ Definition: A phandle and power domain specifier as defined by
+ bindings of power domain specified by the
+ phandle [3].
+
+Example(dual-cluster big.LITTLE system 32-bit)
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x0>;
+ next-level-cache = <&L1_0>;
+
+ L1_0: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ };
+
+ L2_0: l2-cache {
+ compatible = "arm,arch-cache";
+ };
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x1>;
+ next-level-cache = <&L1_1>;
+
+ L1_1: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ };
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x2>;
+ next-level-cache = <&L1_2>;
+
+ L1_2: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ };
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x3>;
+ next-level-cache = <&L1_3>;
+
+ L1_3: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ };
+ };
+
+ cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ next-level-cache = <&L1_4>;
+
+ L1_4: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ };
+
+ L2_1: l2-cache {
+ compatible = "arm,arch-cache";
+ };
+ };
+
+ cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ next-level-cache = <&L1_5>;
+
+ L1_5: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ };
+ };
+
+ cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ next-level-cache = <&L1_6>;
+
+ L1_6: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ };
+ };
+
+ cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x103>;
+ next-level-cache = <&L1_7>;
+
+ L1_7: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ };
+ };
+ };
+
+[1] ARM Architecture Reference Manuals
+ http://infocenter.arm.com/help/index.jsp
+[2] ePAPR standard
+ https://www.power.org/documentation/epapr-version-1-1/
+[3] Kernel documentation - power domain bindings
+ Documentation/devicetree/bindings/power/power_domain.txt
--
1.8.4
^ permalink raw reply related
* [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Lorenzo Pieralisi @ 2014-02-11 14:17 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-kernel, linux-pm, Lorenzo Pieralisi, Dave Martin,
Mark Rutland, Sudeep Holla, Charles Garcia Tobin, Nicolas Pitre,
Rob Herring, Peter De Schrijver, Grant Likely, Kumar Gala,
Santosh Shilimkar, Russell King, Mark Hambleton, Hanjun Guo,
Daniel Lezcano, Amit Kucheria, Vincent Guittot, Antti Miettinen,
Stephen Boyd, Tomasz Figa, Kevin
In-Reply-To: <1392128273-8614-1-git-send-email-lorenzo.pieralisi@arm.com>
ARM based platforms implement a variety of power management schemes that
allow processors to enter idle states at run-time.
The parameters defining these idle states vary on a per-platform basis forcing
the OS to hardcode the state parameters in platform specific static tables
whose size grows as the number of platforms supported in the kernel increases
and hampers device drivers standardization.
Therefore, this patch aims at standardizing idle state device tree bindings for
ARM platforms. Bindings define idle state parameters inclusive of entry methods
and state latencies, to allow operating systems to retrieve the configuration
entries from the device tree and initialize the related power management
drivers, paving the way for common code in the kernel to deal with idle
states and removing the need for static data in current and previous kernel
versions.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 10 +
Documentation/devicetree/bindings/arm/idle-states.txt | 690 ++++++++++
2 files changed, 700 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 9130435..fb7f008 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -191,6 +191,13 @@ nodes to be present and contain the properties described below.
property identifying a 64-bit zero-initialised
memory location.
+ - cpu-idle-states
+ Usage: Optional
+ Value type: <prop-encoded-array>
+ Definition:
+ # List of phandles to cpu idle state nodes supported
+ by this cpu [1].
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
@@ -382,3 +389,6 @@ cpus {
cpu-release-addr = <0 0x20000000>;
};
};
+
+[1] ARM Linux kernel documentation - idle state bindings
+ Documentation/devicetree/bindings/arm/idle-states.txt
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
new file mode 100644
index 0000000..f155e70
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -0,0 +1,690 @@
+==========================================
+ARM idle states binding description
+==========================================
+
+==========================================
+1 - Introduction
+==========================================
+
+ARM systems contain HW capable of managing power consumption dynamically,
+where cores can be put in different low-power states (ranging from simple
+wfi to power gating) according to OSPM policies. The CPU states representing
+the range of dynamic idle states that a processor can enter at run-time, can be
+specified through device tree bindings representing the parameters required
+to enter/exit specific idle states on a given processor.
+
+According to the Server Base System Architecture document (SBSA, [3]), the
+power states an ARM CPU can be put into are identified by the following list:
+
+1 - Running
+2 - Idle_standby
+3 - Idle_retention
+4 - Sleep
+5 - Off
+
+ARM platforms implement the power states specified in the SBSA through power
+management schemes that allow an OS PM implementation to put the processor in
+different idle states (which include states 1 to 4 above; "off" state is not
+an idle state since it does not have wake-up capabilities, hence it is not
+considered in this document).
+
+Idle state parameters (eg entry latency) are platform specific and need to be
+characterized with bindings that provide the required information to OSPM
+code so that it can build the required tables and use them at runtime.
+
+The device tree binding definition for ARM idle states is the subject of this
+document.
+
+===========================================
+2 - cpu-idle-states node
+===========================================
+
+ARM processor idle states are defined within the cpu-idle-states node, which is
+a direct child of the cpus node and provides a container where the processor
+states, defined as device tree nodes, are listed.
+
+- cpu-idle-states node
+
+ Usage: Optional - On ARM systems, is a container of processor idle
+ states nodes. If the system does not provide CPU
+ power management capabilities or the processor just
+ supports idle_standby a cpu-idle-states node is not
+ required.
+
+ Description: cpu-idle-states node is a container node, where its
+ subnodes describe the CPU idle states.
+
+ Node name must be "cpu-idle-states".
+
+ The cpu-idle-states node's parent node must be the cpus node.
+
+ The cpu-idle-states node's child nodes can be:
+
+ - one or more state nodes
+
+ Any other configuration is considered invalid.
+
+The nodes describing the idle states (state) can only be defined within the
+cpu-idle-states node.
+
+Any other configuration is consider invalid and therefore must be ignored.
+
+===========================================
+2 - state node
+===========================================
+
+A state node represents an idle state description and must be defined as
+follows:
+
+- state node
+
+ Description: must be child of either the cpu-idle-states node or
+ a state node.
+
+ The state node name shall be "stateN", where N = {0, 1, ...} is
+ the node number; state nodes which are siblings within a single common
+ parent node must be given a unique and sequential N value, starting
+ from 0.
+
+ A state node can contain state child nodes. A state node with
+ children represents a hierarchical state, which is a superset of
+ the child states. Hierarchical states require all CPUs on which
+ they are valid to request the state in order for it to be entered.
+
+ A state node defines the following properties:
+
+ - compatible
+ Usage: Required
+ Value type: <stringlist>
+ Definition: Must be "arm,cpu-idle-state".
+
+ - index
+ Usage: Required
+ Value type: <u32>
+ Definition: It represents an idle state index, starting from 2.
+ Index 0 represents the processor state "running"
+ and index 1 represents processor mode
+ "idle_standby", entered by executing a wfi
+ instruction (SBSA,[3]); indexes 0 and 1 are
+ standard ARM states that need not be described.
+
+ - entry-method
+ Usage: Required
+ Value type: <stringlist>
+ Definition: Describes the method by which a CPU enters the
+ idle state. This property is required and must be
+ one of:
+
+ - "arm,psci-cpu-suspend"
+ ARM PSCI firmware interface, CPU suspend
+ method[2].
+
+ - "[vendor],[method]"
+ An implementation dependent string with
+ format "vendor,method", where vendor is a string
+ denoting the name of the manufacturer and
+ method is a string specifying the mechanism
+ used to enter the idle state.
+
+ - power-state
+ Usage: See definition.
+ Value type: <u32>
+ Definition: Depends on the entry-method property value.
+ If entry-method is "arm,psci-cpu-suspend":
+ # Property is required and represents
+ psci-power-state parameter. Please refer to
+ [2] for PSCI bindings definition.
+
+ - entry-latency
+ Usage: Required
+ Value type: <prop-encoded-array>
+ Definition: u32 value representing worst case latency
+ in microseconds required to enter the idle state.
+
+ - exit-latency
+ Usage: Required
+ Value type: <prop-encoded-array>
+ Definition: u32 value representing worst case latency
+ in microseconds required to exit the idle state.
+
+ - min-residency
+ Usage: Required
+ Value type: <prop-encoded-array>
+ Definition: u32 value representing time in microseconds
+ required for the CPU to be in the idle state to
+ make up for the dynamic power consumed to
+ enter/exit the idle state in order to break even
+ in terms of power consumption compared to idle
+ state index 1 (idle_standby).
+
+ - power-domains
+ Usage: Optional
+ Value type: <prop-encoded-array>
+ Definition: List of power domain specifiers ([1]) describing
+ the power domains that are affected by the idle
+ state entry.
+
+ - cache-state-retained
+ Usage: See definition
+ Value type: <none>
+ Definition: if present cache memory is retained on power down,
+ otherwise it is lost.
+
+ - processor-state-retained
+ Usage: See definition
+ Value type: <none>
+ Definition: if present CPU processor logic is retained on
+ power down, otherwise it is lost.
+
+===========================================
+3 - Examples
+===========================================
+
+Example 1 (ARM 64-bit, 16-cpu system):
+
+pd_clusters: power-domain-clusters@80002000 {
+ compatible = "arm,power-controller";
+ reg = <0x0 0x80002000 0x0 0x1000>;
+ #power-domain-cells = <1>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pd_cores: power-domain-cores@80000000 {
+ compatible = "arm,power-controller";
+ reg = <0x0 0x80000000 0x0 0x1000>;
+ #power-domain-cells = <1>;
+ };
+};
+
+cpus {
+ #size-cells = <0>;
+ #address-cells = <2>;
+
+ cpu-idle-states {
+
+ STATE0: state0 {
+ compatible = "arm,cpu-idle-state";
+ index = <3>;
+ entry-method = "arm,psci-cpu-suspend";
+ psci-power-state = <0x1010000>;
+ entry-latency = <500>;
+ exit-latency = <1000>;
+ min-residency = <2500>;
+ power-domains = <&pd_clusters 0>;
+ STATE0_1: state0 {
+ compatible = "arm,cpu-idle-state";
+ index = <2>;
+ entry-method = "arm,psci-cpu-suspend";
+ psci-power-state = <0x0010000>;
+ entry-latency = <200>;
+ exit-latency = <400>;
+ min-residency = <300>;
+ power-domains = <&pd_cores 0>,
+ <&pd_cores 1>,
+ <&pd_cores 2>,
+ <&pd_cores 3>,
+ <&pd_cores 4>,
+ <&pd_cores 5>,
+ <&pd_cores 6>,
+ <&pd_cores 7>;
+ };
+ };
+
+ STATE1: state1 {
+ compatible = "arm,cpu-idle-state";
+ index = <3>;
+ entry-method = "arm,psci-cpu-suspend";
+ psci-power-state = <0x1010000>;
+ entry-latency = <1000>;
+ exit-latency = <3000>;
+ min-residency = <6500>;
+ power-domains = <&pd_clusters 1>;
+ STATE1_0: state0 {
+ compatible = "arm,cpu-idle-state";
+ index = <2>;
+ entry-method = "arm,psci-cpu-suspend";
+ psci-power-state = <0x0010000>;
+ entry-latency = <200>;
+ exit-latency = <400>;
+ min-residency = <500>;
+ power-domains = <&pd_cores 8>,
+ <&pd_cores 9>,
+ <&pd_cores 10>,
+ <&pd_cores 11>,
+ <&pd_cores 12>,
+ <&pd_cores 13>,
+ <&pd_cores 14>,
+ <&pd_cores 15>;
+ };
+ };
+ };
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&L1_0>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_0: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 0>;
+ };
+ L2_0: l2-cache {
+ compatible = "arm,arch-cache";
+ power-domain = <&pd_clusters 0>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&L1_1>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_1: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 1>;
+ };
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&L1_2>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_2: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 2>;
+ };
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ next-level-cache = <&L1_3>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_3: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 3>;
+ };
+ };
+
+ CPU4: cpu@10000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x10000>;
+ enable-method = "psci";
+ next-level-cache = <&L1_4>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_4: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 4>;
+ };
+ };
+
+ CPU5: cpu@10001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x10001>;
+ enable-method = "psci";
+ next-level-cache = <&L1_5>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_5: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 5>;
+ };
+ };
+
+ CPU6: cpu@10100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x10100>;
+ enable-method = "psci";
+ next-level-cache = <&L1_6>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_6: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 6>;
+ };
+ };
+
+ CPU7: cpu@10101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a57";
+ reg = <0x0 0x10101>;
+ enable-method = "psci";
+ next-level-cache = <&L1_7>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_7: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 7>;
+ };
+ };
+
+ CPU8: cpu@100000000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&L1_8>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_8: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 8>;
+ };
+ L2_1: l2-cache {
+ compatible = "arm,arch-cache";
+ power-domain = <&pd_clusters 1>;
+ };
+ };
+
+ CPU9: cpu@100000001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&L1_9>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_9: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 9>;
+ };
+ };
+
+ CPU10: cpu@100000100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&L1_10>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_10: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 10>;
+ };
+ };
+
+ CPU11: cpu@100000101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x101>;
+ enable-method = "psci";
+ next-level-cache = <&L1_11>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_11: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 11>;
+ };
+ };
+
+ CPU12: cpu@100010000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x10000>;
+ enable-method = "psci";
+ next-level-cache = <&L1_12>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_12: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 12>;
+ };
+ };
+
+ CPU13: cpu@100010001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x10001>;
+ enable-method = "psci";
+ next-level-cache = <&L1_13>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_13: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 13>;
+ };
+ };
+
+ CPU14: cpu@100010100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x10100>;
+ enable-method = "psci";
+ next-level-cache = <&L1_14>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_14: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 14>;
+ };
+ };
+
+ CPU15: cpu@100010101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x1 0x10101>;
+ enable-method = "psci";
+ next-level-cache = <&L1_15>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_15: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 15>;
+ };
+ };
+};
+
+Example 2 (ARM 32-bit, 8-cpu system, two clusters):
+
+pd_clusters: power-domain-clusters@80002000 {
+ compatible = "arm,power-controller";
+ reg = <0x80002000 0x1000>;
+ #power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pd_cores: power-domain-cores@80000000 {
+ compatible = "arm,power-controller";
+ reg = <0x80000000 0x1000>;
+ #power-domain-cells = <1>;
+ };
+};
+
+cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ cpu-idle-states {
+
+ STATE0: state0 {
+ compatible = "arm,cpu-idle-state";
+ index = <3>;
+ entry-method = "psci";
+ psci-power-state = <0x1010000>;
+ entry-latency = <1000>;
+ exit-latency = <1500>;
+ min-residency = <1500>;
+ power-domains = <&pd_clusters 0>;
+ STATE0_1: state0 {
+ compatible = "arm,cpu-idle-state";
+ index = <2>;
+ entry-method = "psci";
+ psci-power-state = <0x0010000>;
+ entry-latency = <400>;
+ exit-latency = <500>;
+ min-residency = <300>;
+ power-domains = <&pd_cores 0>,
+ <&pd_cores 1>,
+ <&pd_cores 2>,
+ <&pd_cores 3>;
+ };
+ };
+
+ STATE1: state1 {
+ compatible = "arm,cpu-idle-state";
+ index = <3>;
+ entry-method = "psci";
+ psci-power-state = <0x1010000>;
+ entry-latency = <800>;
+ exit-latency = <2000>;
+ min-residency = <6500>;
+ power-domains = <&pd_clusters 1>;
+ STATE1_0: state0 {
+ compatible = "arm,cpu-idle-state";
+ index = <2>;
+ entry-method = "psci";
+ psci-power-state = <0x0010000>;
+ entry-latency = <300>;
+ exit-latency = <500>;
+ min-residency = <500>;
+ power-domains = <&pd_cores 4>,
+ <&pd_cores 5>,
+ <&pd_cores 6>,
+ <&pd_cores 7>;
+ };
+ };
+ };
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x0>;
+ next-level-cache = <&L1_0>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_0: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 0>;
+ };
+ L2_0: l2-cache {
+ compatible = "arm,arch-cache";
+ power-domain = <&pd_clusters 0>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x1>;
+ next-level-cache = <&L1_1>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_1: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 1>;
+ };
+ };
+
+ CPU2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x2>;
+ next-level-cache = <&L1_2>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_2: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 2>;
+ };
+ };
+
+ CPU3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x3>;
+ next-level-cache = <&L1_3>;
+ cpu-idle-states = <&STATE0_1 &STATE0>;
+ L1_3: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_0>;
+ power-domain = <&pd_cores 3>;
+ };
+ };
+
+ CPU4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ next-level-cache = <&L1_4>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_4: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 4>;
+ };
+ L2_1: l2-cache {
+ compatible = "arm,arch-cache";
+ power-domain = <&pd_clusters 1>;
+ };
+ };
+
+ CPU5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ next-level-cache = <&L1_5>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_5: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 5>;
+ };
+ };
+
+ CPU6: cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ next-level-cache = <&L1_6>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_6: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 6>;
+ };
+ };
+
+ CPU7: cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x103>;
+ next-level-cache = <&L1_7>;
+ cpu-idle-states = <&STATE1_0 &STATE1>;
+ L1_7: l1-cache {
+ compatible = "arm,arch-cache";
+ next-level-cache = <&L2_1>;
+ power-domain = <&pd_cores 7>;
+ };
+ };
+};
+
+===========================================
+4 - References
+===========================================
+
+[1] ARM Linux Kernel documentation - power domain bindings
+ Documentation/devicetree/bindings/power/power_domain.txt
+
+[2] ARM Linux Kernel documentation - PSCI bindings
+ Documentation/devicetree/bindings/arm/psci.txt
+
+[3] ARM Server Base System Architecture (SBSA)
+ http://infocenter.arm.com/help/index.jsp
--
1.8.4
^ permalink raw reply related
* Re: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size
From: Ezequiel Garcia @ 2014-02-11 14:19 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Brian Norris
Cc: David Woodhouse, Pekon Gupta, Thomas Petazzoni, Gregory Clement,
Seif Mazareeb, Lior Amsalem,
b.brezillon.dev-Re5JQEeQqe8AvxtiuMwx3w, Grant Likely
In-Reply-To: <1389960820-18696-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Jan 17, 2014 at 09:13:40AM -0300, Ezequiel Garcia wrote:
> Some flashes can only be properly accessed when the ECC mode is
> specified, and a way to describe such mode is required.
>
> Such ECC mode is completely driver-specific so instead of having one binding
> per compatible-string, let's add generic ECC strength and ECC step size.
> Driver's can choose the appropriate ECC mode, based on this specification.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> index 03855c8..683a310 100644
> --- a/Documentation/devicetree/bindings/mtd/nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> @@ -3,5 +3,9 @@
> - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> "soft_bch".
> +- nand-ecc-strength : integer ECC required strength.
> +- nand-ecc-size : integer step size associated to the ECC strength.
> + The exact meaning of the ECC strength and ECC size parameters is completely
> + driver-specific.
> - nand-bus-width : 8 or 16 bus width if not present 8
> - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
> --
> 1.8.1.5
>
Brian, do you agree (as MTD maintainer) with this new binding?
Can we get any Acks from a devicetree binding maintainer? Grant has already
given his (informal) approval [1], but I'd rather have a formal ack from
binding maintainer.
Once this binding gets accepted, I'll submit an of_helper patch, and a patch
for pxa3xx-nand to use it.
[1] http://www.spinics.net/lists/devicetree/msg20534.html
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Your Email ID Has Won One Million USD from United Nation Grant Award for Claims Contact Mr.robin steven
From: kadri karim @ 2014-02-11 14:23 UTC (permalink / raw)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Tomasz Figa @ 2014-02-11 14:29 UTC (permalink / raw)
To: Grant Likely, Marek Szyprowski, linux-kernel, linux-arm-kernel,
linaro-mm-sig, devicetree, linux-doc
Cc: Kyungmin Park, Benjamin Herrenschmidt, Arnd Bergmann,
Michal Nazarewicz, Sascha Hauer, Laura Abbott, Rob Herring,
Olof Johansson, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Tomasz Figa, Kumar Gala, Nishanth Peethambaran,
Marc, Josh Cartwright
In-Reply-To: <20140211121316.24032C40C4D@trevor.secretlab.ca>
Hi,
On 11.02.2014 13:13, Grant Likely wrote:
> On Tue, 11 Feb 2014 12:45:50 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> Hello,
>>
>> On 2014-02-05 12:05, Grant Likely wrote:
>>> On Tue, 04 Feb 2014 13:09:29 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>>>> This patch adds device tree support for contiguous and reserved memory
>>>> regions defined in device tree.
>>>>
>>>> Large memory blocks can be reliably reserved only during early boot.
>>>> This must happen before the whole memory management subsystem is
>>>> initialized, because we need to ensure that the given contiguous blocks
>>>> are not yet allocated by kernel. Also it must happen before kernel
>>>> mappings for the whole low memory are created, to ensure that there will
>>>> be no mappings (for reserved blocks) or mapping with special properties
>>>> can be created (for CMA blocks). This all happens before device tree
>>>> structures are unflattened, so we need to get reserved memory layout
>>>> directly from fdt.
>>>>
>>>> Later, those reserved memory regions are assigned to devices on each
>>>> device structure initialization.
>>>>
>>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Cc: Laura Abbott <lauraa@codeaurora.org>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> [joshc: rework to implement new DT binding, provide mechanism for
>>>> plugging in new reserved-memory node handlers via
>>>> RESERVEDMEM_OF_DECLARE]
>>>> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
>>>> [mszyprow: little code cleanup]
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>> drivers/of/Kconfig | 6 +
>>>> drivers/of/Makefile | 1 +
>>>> drivers/of/of_reserved_mem.c | 219 +++++++++++++++++++++++++++++++++++++
>>>> drivers/of/platform.c | 7 ++
>>>> include/asm-generic/vmlinux.lds.h | 11 ++
>>>> include/linux/of_reserved_mem.h | 62 +++++++++++
>>>> 6 files changed, 306 insertions(+)
>>>> create mode 100644 drivers/of/of_reserved_mem.c
>>>> create mode 100644 include/linux/of_reserved_mem.h
>>>>
>>>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>>>> index c6973f101a3e..aba13df56f3a 100644
>>>> --- a/drivers/of/Kconfig
>>>> +++ b/drivers/of/Kconfig
>>>> @@ -75,4 +75,10 @@ config OF_MTD
>>>> depends on MTD
>>>> def_bool y
>>>>
>>>> +config OF_RESERVED_MEM
>>>> + depends on HAVE_MEMBLOCK
>>>> + def_bool y
>>>> + help
>>>> + Helpers to allow for reservation of memory regions
>>>> +
>>>> endmenu # OF
>>>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>>>> index efd05102c405..ed9660adad77 100644
>>>> --- a/drivers/of/Makefile
>>>> +++ b/drivers/of/Makefile
>>>> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
>>>> obj-$(CONFIG_OF_PCI) += of_pci.o
>>>> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
>>>> obj-$(CONFIG_OF_MTD) += of_mtd.o
>>>> +obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>>>> new file mode 100644
>>>> index 000000000000..f17cd56e68d9
>>>> --- /dev/null
>>>> +++ b/drivers/of/of_reserved_mem.c
>>>> @@ -0,0 +1,219 @@
>>>> +/*
>>>> + * Device tree based initialization code for reserved memory.
>>>> + *
>>>> + * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
>>>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>>>> + * http://www.samsung.com
>>>> + * Author: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> + * Author: Josh Cartwright <joshc@codeaurora.org>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU General Public License as
>>>> + * published by the Free Software Foundation; either version 2 of the
>>>> + * License or (at your optional) any later version of the license.
>>>> + */
>>>> +#include <linux/memblock.h>
>>>> +#include <linux/err.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_fdt.h>
>>>> +#include <linux/of_platform.h>
>>>> +#include <linux/mm.h>
>>>> +#include <linux/sizes.h>
>>>> +#include <linux/of_reserved_mem.h>
>>>> +
>>>> +#define MAX_RESERVED_REGIONS 16
>>>> +static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
>>>> +static int reserved_mem_count;
>>>> +
>>>> +int __init of_parse_flat_dt_reg(unsigned long node, const char *uname,
>>>> + phys_addr_t *base, phys_addr_t *size)
>>>
>>> Useful utility function; move to drivers/of/fdt.c
>>>
>>>> +{
>>>> + unsigned long len;
>>>> + __be32 *prop;
>>>> +
>>>> + prop = of_get_flat_dt_prop(node, "reg", &len);
>>>> + if (!prop)
>>>> + return -EINVAL;
>>>> +
>>>> + if (len < (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32)) {
>>>> + pr_err("Reserved memory: invalid reg property in '%s' node.\n",
>>>> + uname);
>>>> + return -EINVAL;
>>>> + }
>>>
>>> This is /okay/ for an initial implementation, but it is naive. While I
>>> suggested making #address-cells and #size-cells equal the root node
>>> values for the purpose of simplicity, it should still be perfectly valid
>>> to have different values if the ranges property is correctly formed.
>>>
>>>> +
>>>> + *base = dt_mem_next_cell(dt_root_addr_cells, &prop);
>>>> + *size = dt_mem_next_cell(dt_root_size_cells, &prop);
>>>
>>> Future enhancement; allow for parsing more than just the first reg
>>> tuple.
>>
>> One more question. Does it really makes any sense to support more than
>> one tuple for reg property? For consistency we should also allow more
>> than one entry in size, align and alloc-ranges property, but I don't
>> see any benefits for defining more than one range for a single region.
>> Same can be achieved by defining more regions instead if one really
>> needs such configuration.
>
> Yes, if only because it is an define usage of the reg property. If a
> devtree has multiple tuples in reg, then all of those tuples should be
> treated as reserved, even if the kernel doesn't know how to use them.
>
> I would not do the same for size/align/alloc-ranges unless there is a
> very specific use case that you can define. These ones are different
> from the static regions because they aren't ever used to protect
> something that already exists in the memory.
Is there a reason why multiple regions could not be used for this
purpose, instead of adding extra complexity of having multiple reg
entries per region?
I.e. I don't see a difference between
reg1: region@00000000 {
reg = <0x00000000 0x1000>;
};
reg2: region@10000000 {
reg = <0x10000000 0x1000>;
};
user {
regions = <®1>, <®2>;
};
and
reg: region@00000000 {
reg = <0x00000000 0x1000>, <0x10000000 0x1000>;
};
user {
regions = <®>;
};
except that the former IMHO better suits the definition of memory
region, which I see as a single contiguous range of memory and can be
simplified to have a single reg entry per region.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Hans de Goede @ 2014-02-11 14:35 UTC (permalink / raw)
To: Nishanth Menon, Roger Quadros, tony
Cc: bcousson, balbi, linux-omap, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <52FA3102.7080407@ti.com>
Hi,
On 02/11/2014 03:17 PM, Nishanth Menon wrote:
> On 02/11/2014 07:53 AM, Roger Quadros wrote:
>> On 02/10/2014 08:10 PM, Roger Quadros wrote:
>>> The OMAP EHCI controller is not compatible with the EHCI
>>> platform HCD driver so don't claim that we are.
>>>
>>> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
>>> e.g. multi_v7_defconfig
>>>
>>> Reported-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>
>> Please ignore this patch as Hans has agreed to do a more proper fix in
>>
>> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015
> umm.. even then, drivers/usb/host/ehci-ppc-of.c claims compatibility
> with usb,ehci -> and we wont function with that driver either.
Right, but that has never been an issue as no kernel will ever include
both ppc and omap support.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver
From: Arnd Bergmann @ 2014-02-11 14:38 UTC (permalink / raw)
To: Mohit KUMAR DCG
Cc: Pratyush ANAND, Kishon Vijay Abraham I, spear-devel,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Lee Jones
In-Reply-To: <2CC2A0A4A178534D93D5159BF3BCB66189FD2CAA9B@EAPEX1MAIL1.st.com>
On Tuesday 11 February 2014 11:57:46 Mohit KUMAR DCG wrote:
>
> > Maybe mention that this phy is used inside the spear13xx
> > SoC here rather than a standalone phy.
>
> - Yes, for spear13xx its used internally. Do you think that
> it requires to be mentioned here?
> We have few prototype boards that uses this as external phy.
[adding Lee since he mentioned working on a similar part]
I'm a bit confused. Is it actually the same IP block that can
be used internally as part of a SoC and as a standalone chip?
Since some of the settings of the PHY are controlled through
the misc register in case of spear13xx, I assume that part
is different on the standalone version. How do you actually
select the mode in that case?
It would certainly be helpful to explain this somewhere,
and the binding might not be the worst place for this.
On a related note, the driver in its current shape looks
a bit silly since it doesn't contain any of the miphy specific
code but only the SoC specific parts (as I suggested you
do, so I'm not blaming you :-)) and a multiplexer that
switches between the two possible implementations.
What is your plan for the future, do you intend to add
the actual miphy code soon, or is that something you just
want to leave as an option for the future but have no
specific plans to do right now? If not, the driver
would probably look nicer if it were split into two
separate implementations, one for each spear13xx SoC
and with a separate set of phy_ops but no multiplexer.
The connection to the miphy code (if you want to keep
your options open) could be done by implementing some
kind of nested phy model where the st,spear1340-phy contains
another "phys" property pointing to the st,miphy40 node
and the driver just calls the slave phy_ops recursively,
or the sata and pcie nodes actually link to two phy nodes
that are separate from one another.
Arnd
^ permalink raw reply
* Re: [PATCH] of: Turn of_match_node into a static inline when CONFIG_OF isn't set
From: Josh Cartwright @ 2014-02-11 14:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Grant Likely, Rob Herring
In-Reply-To: <1392122211-11422-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Hey Laurent-
On Tue, Feb 11, 2014 at 01:36:51PM +0100, Laurent Pinchart wrote:
> when CONFIG_OF is disabled of_match_node is defined as a macro that
> evaluates to NULL. This breaks compilation of drivers that dereference
> the function's return value directly. Fix it by turning the macro into a
> static inline function that returns NULL.
Just this past week I did the same thing, but noticed that it breaks the
following usecase:
#ifdef CONFIG_OF
static const struct of_device_id foobar_matches[] = {
{ .compatible = "foobar,whatsit", },
{ },
};
#endif
static int probeme(struct platform_device *pdev)
{
struct of_device_id *id;
id = of_match_node(foobar_matches, pdev->dev.of_node);
if (id) {
/* ... */
}
return 0;
}
When !CONFIG_OF and with your change, this will fail to build due to
foobar_matches being undefined.
Josh
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Nishanth Menon @ 2014-02-11 14:41 UTC (permalink / raw)
To: Hans de Goede, Roger Quadros, tony
Cc: bcousson, balbi, linux-omap, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <52FA3531.8090308@redhat.com>
On 02/11/2014 08:35 AM, Hans de Goede wrote:
> On 02/11/2014 03:17 PM, Nishanth Menon wrote:
>> On 02/11/2014 07:53 AM, Roger Quadros wrote:
>>> On 02/10/2014 08:10 PM, Roger Quadros wrote:
>>>> The OMAP EHCI controller is not compatible with the EHCI
>>>> platform HCD driver so don't claim that we are.
>>>>
>>>> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
>>>> e.g. multi_v7_defconfig
>>>>
>>>> Reported-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>
>>> Please ignore this patch as Hans has agreed to do a more proper fix in
>>>
>>> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015
>> umm.. even then, drivers/usb/host/ehci-ppc-of.c claims compatibility
>> with usb,ehci -> and we wont function with that driver either.
>
> Right, but that has never been an issue as no kernel will ever include
> both ppc and omap support.
Conceptually, we have compatibility string today in dts description
that maps a driver that cant ever handle the device. I dont have
strong opinions either way.. just something i noticed with a git grep..
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Russell King - ARM Linux @ 2014-02-11 14:52 UTC (permalink / raw)
To: Rob Herring
Cc: Philipp Zabel, Mauro Carvalho Chehab, Grant Likely, Rob Herring,
Sylwester Nawrocki, Laurent Pinchart, Tomi Valkeinen,
Kyungmin Park, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Philipp Zabel
In-Reply-To: <CAL_Jsq+U9zU1i+STLHMBjY5BeEP6djYnJVE5X1ix-D2q_zWztQ@mail.gmail.com>
On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
> On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > This allows to reuse the same parser code from outside the V4L2 framework,
> > most importantly from display drivers. There have been patches that duplicate
> > the code (and I am going to send one of my own), such as
> > http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
> > and others that parse the same binding in a different way:
> > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
> >
> > I think that all common video interface parsing helpers should be moved to a
> > single place, outside of the specific subsystems, so that it can be reused
> > by all drivers.
>
> Perhaps that should be done rather than moving to drivers/of now and
> then again to somewhere else.
Do you have a better suggestion where it should move to?
drivers/gpu/drm - no, because v4l2 wants to use it
drivers/media/video - no, because DRM drivers want to use it
drivers/video - no, because v4l2 and drm drivers want to use it
Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
into drivers/of ?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Re: [PATCH 1/2] OF: update stdout-path parsing
From: Grant Likely @ 2014-02-11 14:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Sascha Hauer, Jean-Christophe PLAGNIOL-VILLARD,
linux-serial
In-Reply-To: <1391860433-5343-1-git-send-email-plagnioj@jcrosoft.com>
On Sat, 8 Feb 2014 12:53:52 +0100, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> Today we only check if the linux,stdout-path property is present and retreive
> the node. But the DT specification allow to pass the serial options too as
> this
> linux,stdout-path = &UART0;
>
> or with options
>
> inux,stdout-path = "/plb@0/serial@84000000:115200";
typo. :-)
>
> So update the parsing to support and also the backward compatible stdout-path
> property.
Looks reasonable to me. Comment below, but otherwise:
Acked-by: Grant Likely <grant.likely@linaro.org>
>
> Cc: linux-serial@vger.kernel.org
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> drivers/of/base.c | 57 +++++++++++++++++++++++++++++++++++++++++++++---------
> include/linux/of.h | 4 ++--
> 2 files changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ff85450..ab9ff2f 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -34,6 +34,7 @@ EXPORT_SYMBOL(of_allnodes);
> struct device_node *of_chosen;
> struct device_node *of_aliases;
> static struct device_node *of_stdout;
> +static char *of_stdout_option;
>
> DEFINE_MUTEX(of_aliases_mutex);
>
> @@ -1783,6 +1784,45 @@ static void of_alias_add(struct alias_prop *ap, struct device_node *np,
> }
>
> /**
> + * of_stdout_path_scan - check if a device node matches the
> + * linux,stdout-path property and parse it
> + */
> +static void of_stdout_path_scan(void)
> +{
> + const char *name;
> + const char *tmp;
> + const char *tmp_option;
> +
> + name = of_get_property(of_chosen, "linux,stdout-path", NULL);
> + if (!name)
> + name = of_get_property(of_chosen, "stdout-path", NULL);
Should protect against unterminated strings. Use of_property_read_string()
> +
> + if (!name)
> + return;
> +
> + tmp_option = strchr(name, ':');
> +
> + if (!tmp_option) {
> + of_stdout = of_find_node_by_path(name);
> + return;
> + }
> +
> + tmp = kstrndup(name, strlen(name) - strlen(tmp_option), GFP_KERNEL);
> + if (!tmp)
> + return;
Having to do a strdup is kind of ugly and expensive when the only
problem is the terminating colon. I would rather see
of_find_node_by_path modified to do the right thing by ignoring the
colon which is illegal in path names anyway.
> +
> + of_stdout = of_find_node_by_path(tmp);
> + if (!of_stdout)
> + goto out;
> +
> + tmp_option++;
> + of_stdout_option = kstrdup(tmp_option, GFP_KERNEL);
The strdup is unnecessary. tmp_option is already null terminated, is
immutable, and contains the data you need.
> +
> +out:
> + kfree(tmp);
Please reverse the to eliminate the non-error goto:
of_stdout = of_find_node_by_path(tmp);
if (of_stdout)
of_stdout_option = tmp_option++;
kfree(tmp);
> +}
> +
> +/**
> * of_alias_scan - Scan all properties of 'aliases' node
> *
> * The function scans all the properties of 'aliases' node and populate
> @@ -1800,13 +1840,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
> if (of_chosen == NULL)
> of_chosen = of_find_node_by_path("/chosen@0");
>
> - if (of_chosen) {
> - const char *name;
> -
> - name = of_get_property(of_chosen, "linux,stdout-path", NULL);
> - if (name)
> - of_stdout = of_find_node_by_path(name);
> - }
> + if (of_chosen)
> + of_stdout_path_scan();
Move the of_chosen check directly into the function.
>
> of_aliases = of_find_node_by_path("/aliases");
> if (!of_aliases)
> @@ -1923,13 +1958,17 @@ EXPORT_SYMBOL_GPL(of_prop_next_string);
> * linux,stdout-path property
> *
> * Check if this device node matches the linux,stdout-path property
> - * in the chosen node. return true if yes, false otherwise.
> + * in the chosen node. return true if yes, false otherwise with the option if
> + * requested.
> */
> -int of_device_is_stdout_path(struct device_node *dn)
> +int of_device_is_stdout_path(struct device_node *dn, char** option)
> {
> if (!of_stdout)
> return false;
>
> + if (option)
> + *option = of_stdout_option;
> +
> return of_stdout == dn;
> }
> EXPORT_SYMBOL_GPL(of_device_is_stdout_path);
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 70c64ba..a8afe44 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -352,7 +352,7 @@ const __be32 *of_prop_next_u32(struct property *prop, const __be32 *cur,
> */
> const char *of_prop_next_string(struct property *prop, const char *cur);
>
> -int of_device_is_stdout_path(struct device_node *dn);
> +int of_device_is_stdout_path(struct device_node *dn, char** option);
>
> #else /* CONFIG_OF */
>
> @@ -542,7 +542,7 @@ static inline int of_machine_is_compatible(const char *compat)
> return 0;
> }
>
> -static inline int of_device_is_stdout_path(struct device_node *dn)
> +static inline int of_device_is_stdout_path(struct device_node *dn, char** option)
> {
> return 0;
> }
> --
> 1.9.rc1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] of: Turn of_match_node into a static inline when CONFIG_OF isn't set
From: Laurent Pinchart @ 2014-02-11 14:55 UTC (permalink / raw)
To: Josh Cartwright; +Cc: linux-kernel, devicetree, Grant Likely, Rob Herring
In-Reply-To: <20140211144108.GB841@joshc.qualcomm.com>
Hi Josh,
On Tuesday 11 February 2014 08:41:08 Josh Cartwright wrote:
> On Tue, Feb 11, 2014 at 01:36:51PM +0100, Laurent Pinchart wrote:
> > when CONFIG_OF is disabled of_match_node is defined as a macro that
> > evaluates to NULL. This breaks compilation of drivers that dereference
> > the function's return value directly. Fix it by turning the macro into a
> > static inline function that returns NULL.
>
> Just this past week I did the same thing, but noticed that it breaks the
> following usecase:
>
> #ifdef CONFIG_OF
> static const struct of_device_id foobar_matches[] = {
> { .compatible = "foobar,whatsit", },
> { },
> };
> #endif
>
> static int probeme(struct platform_device *pdev)
> {
> struct of_device_id *id;
>
> id = of_match_node(foobar_matches, pdev->dev.of_node);
> if (id) {
> /* ... */
> }
> return 0;
> }
>
> When !CONFIG_OF and with your change, this will fail to build due to
> foobar_matches being undefined.
Good point. What would you think about
#define of_match_node(_matches, _node) ((const struct of_device_id *)NULL)
?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
From: Roger Quadros @ 2014-02-11 15:00 UTC (permalink / raw)
To: Hans de Goede, Greg Kroah-Hartman
Cc: Alan Stern, Tony Prisk, Florian Fainelli, Maxime Ripard,
linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Grant Likely, jwboyer-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <1392127826-31290-3-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Hans,
On 02/11/2014 04:10 PM, Hans de Goede wrote:
> The initial versions of the devicetree enablement patches for ehci-platform
> used "ehci-platform" as compatible string. However this was disliked by various
> reviewers because the platform bus is a Linux invention and devicetree is
> supposed to be OS agnostic. After much discussion I gave up, added a:
> "depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
> and went with the generic usb-ehci as requested.
>
> In retro-spect I should have stuck to my guns, because the dts files for many
> existing boards already claim to be compatible with "usb-ehci", ie they have:
>
> compatible = "ti,ehci-omap", "usb-ehci";
>
> In theory this should not be a problem since the "ti,ehci-omap" entry takes
> presedence, but in practice using a conflicting compatible string is an issue,
> because it makes which driver gets used depent on driver registration order.
>
> This patch changes the compatible string claimed by ehci-platform (back) to
> "ehci-platform", avoiding the driver registration / module loading ordering
> problems, and removes the "depends on !PPC_OF" workaround.
>
> Note that there already is a precedent for using ?hci-platform, in the form
> of xhci-platform.c using "xhci-platfrom" as compatible string.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/usb-ehci.txt | 4 ++--
> drivers/usb/host/Kconfig | 1 -
> drivers/usb/host/ehci-platform.c | 2 +-
> 3 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> index 2c1aeeb..46f428a 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> @@ -1,7 +1,7 @@
> USB EHCI controllers
>
> Required properties:
> - - compatible : should be "usb-ehci".
> + - compatible : should be "ehci-platform".
Won't this break DT binding info for power PC?
I'm even OK with removing "usb-ehci" and "usb-ohci" compatibles from all OMAP dts files
since they aren't really compatible with the original PPC driver.
cheers,
-roger
> - reg : should contain at least address and length of the standard EHCI
> register set for the device. Optional platform-dependent registers
> (debug-port or other) can be also specified here, but only after
> @@ -27,7 +27,7 @@ Example (Sequoia 440EPx):
>
> Example (Allwinner sun4i A10 SoC):
> ehci0: usb@01c14000 {
> - compatible = "allwinner,sun4i-a10-ehci", "usb-ehci";
> + compatible = "allwinner,sun4i-a10-ehci", "ehci-platform";
> reg = <0x01c14000 0x100>;
> interrupts = <39>;
> clocks = <&ahb_gates 1>;
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index e28cbe0..a9707da 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -255,7 +255,6 @@ config USB_EHCI_ATH79
>
> config USB_EHCI_HCD_PLATFORM
> tristate "Generic EHCI driver for a platform device"
> - depends on !PPC_OF
> default n
> ---help---
> Adds an EHCI host driver for a generic platform device, which
> diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> index 8fde649..4f4d78f 100644
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -333,7 +333,7 @@ static int ehci_platform_resume(struct device *dev)
> static const struct of_device_id vt8500_ehci_ids[] = {
> { .compatible = "via,vt8500-ehci", },
> { .compatible = "wm,prizm-ehci", },
> - { .compatible = "usb-ehci", },
> + { .compatible = "ehci-platform", },
> {}
> };
> MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
>
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Russell King - ARM Linux @ 2014-02-11 15:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Brown, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
pawel.moll-5wv7dgnIgG8, Linus Walleij,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <201402111508.06267.arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Feb 11, 2014 at 03:08:06PM +0100, Arnd Bergmann wrote:
> On Tuesday 11 February 2014, Mark Brown wrote:
> > On Tue, Feb 11, 2014 at 11:37:09AM +0000, Mark Rutland wrote:
> >
> > > - pl022->clk = devm_clk_get(&adev->dev, NULL);
> > > + /*
> > > + * For compatibility with old DTBs and platform data, fall back to the
> > > + * first clock if there's not an explicitly named "sspclk" entry.
> > > + */
> > > + pl022->clk = devm_clk_get(&adev->dev, "sspclk");
> > > + if (IS_ERR(pl022->clk))
> > > + pl022->clk = devm_clk_get(&adev->dev, NULL);
> > > +
> >
> > I'll just have a bit of a grumble here and point out that this sort of
> > stuff always worries me with the convention of using nameless clocks -
> > it causes hassle adding further clocks.
>
> I think the best solution for this is to continue with anonymous clocks
> rather than adding names after the fact. This could be done (for DT-only
> drivers) using the of_clk_get() interface that takes an index, or
> we could add a generic dev_clk_get_index() or similar interface that
> has the same behavior but also works for clkdev.
Mixing devm_* and non-devm_* interfaces doesn't work. If you want to do
that, devm_of_clk_get() would be a prerequisit.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ohci-platform: Change compatible string from usb-ohci to ohci-platform
From: Kumar Gala @ 2014-02-11 15:06 UTC (permalink / raw)
To: Hans De Goede
Cc: Greg Kroah-Hartman, devicetree, Florian Fainelli, linux-usb,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Alan Stern, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Roger Quadros
In-Reply-To: <1392127826-31290-2-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Feb 11, 2014, at 8:10 AM, Hans De Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> The initial versions of the devicetree enablement patches for ohci-platform
> used "ohci-platform" as compatible string. However this was disliked by various
> reviewers because the platform bus is a Linux invention and devicetree is
> supposed to be OS agnostic. After much discussion I gave up and went with
> the generic usb-ohci as requested.
>
> In retro-spect I should have stuck to my guns, because the dts files for many
> existing boards already claim to be compatible with "usb-ohci", ie they have:
>
> compatible = "ti,ohci-omap3", "usb-ohci";
>
> In theory this should not be a problem since the "ti,ohci-omap3" entry takes
> presedence, but in practice using a conflicting compatible string is an issue,
> because it makes which driver gets used depent on driver registration order.
>
> This patch changes the compatible string claimed by ohci-platform (back) to
> "ohci-platform", avoiding the driver registration / module loading ordering
> problems. Note that there already is a precedent for using ?hci-platform, in
> the form of xhci-platform.c using "xhci-platfrom" as compatible string.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/usb-ohci.txt | 4 ++--
> drivers/usb/host/ohci-platform.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
> index 6933b0c..a8e576a 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
> @@ -1,7 +1,7 @@
> USB OHCI controllers
>
> Required properties:
> -- compatible : "usb-ohci”
Why not leave ‘usb-ohci’ and deprecate it?
> +- compatible : "ohci-platform"
> - reg : ohci controller register range (address and length)
> - interrupts : ohci controller interrupt
>
> @@ -16,7 +16,7 @@ Optional properties:
> Example:
>
> ohci0: usb@01c14400 {
> - compatible = "allwinner,sun4i-a10-ohci", "usb-ohci";
> + compatible = "allwinner,sun4i-a10-ohci", "ohci-platform";
> reg = <0x01c14400 0x100>;
> interrupts = <64>;
> clocks = <&usb_clk 6>, <&ahb_gates 2>;
> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> index e2c28fd..59f3551 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -319,7 +319,7 @@ static int ohci_platform_resume(struct device *dev)
> #endif /* CONFIG_PM */
>
> static const struct of_device_id ohci_platform_ids[] = {
> - { .compatible = "usb-ohci", },
> + { .compatible = "ohci-platform", },
> { }
> };
> MODULE_DEVICE_TABLE(of, ohci_platform_ids);
> --
> 1.8.5.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ohci-platform: Change compatible string from usb-ohci to ohci-platform
From: Hans de Goede @ 2014-02-11 15:21 UTC (permalink / raw)
To: Kumar Gala
Cc: Greg Kroah-Hartman, devicetree, Florian Fainelli, linux-usb,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Alan Stern, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Roger Quadros
In-Reply-To: <954E6E26-EEF1-4A0A-A9BC-D5CA918FAD43-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi,
On 02/11/2014 04:06 PM, Kumar Gala wrote:
>
> On Feb 11, 2014, at 8:10 AM, Hans De Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> The initial versions of the devicetree enablement patches for ohci-platform
>> used "ohci-platform" as compatible string. However this was disliked by various
>> reviewers because the platform bus is a Linux invention and devicetree is
>> supposed to be OS agnostic. After much discussion I gave up and went with
>> the generic usb-ohci as requested.
>>
>> In retro-spect I should have stuck to my guns, because the dts files for many
>> existing boards already claim to be compatible with "usb-ohci", ie they have:
>>
>> compatible = "ti,ohci-omap3", "usb-ohci";
>>
>> In theory this should not be a problem since the "ti,ohci-omap3" entry takes
>> presedence, but in practice using a conflicting compatible string is an issue,
>> because it makes which driver gets used depent on driver registration order.
>>
>> This patch changes the compatible string claimed by ohci-platform (back) to
>> "ohci-platform", avoiding the driver registration / module loading ordering
>> problems. Note that there already is a precedent for using ?hci-platform, in
>> the form of xhci-platform.c using "xhci-platfrom" as compatible string.
>>
>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/usb-ohci.txt | 4 ++--
>> drivers/usb/host/ohci-platform.c | 2 +-
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
>> index 6933b0c..a8e576a 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
>> @@ -1,7 +1,7 @@
>> USB OHCI controllers
>>
>> Required properties:
>> -- compatible : "usb-ohci"
>
> Why not leave 'usb-ohci' and deprecate it?
As it was introduced just a couple of days ago in linux-next, and has never seen
the light in any released kernel.
Regards,
Hans
^ permalink raw reply
* Re: regression(ti platforms): next-20140210 (ehci?)
From: Alan Stern @ 2014-02-11 15:21 UTC (permalink / raw)
To: Kevin Hilman
Cc: Nishanth Menon, Roger Quadros, linux-omap,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Balbi, Felipe,
linux-next-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org
In-Reply-To: <7h38jq8nk9.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org>
On Mon, 10 Feb 2014, Kevin Hilman wrote:
> > The issue started I think with the following patch getting merged:
> > ehci-platform: Add support for clks and phy passed through devicetree
> > some version of http://www.spinics.net/lists/linux-usb/msg101061.html
> > introduced { .compatible = "usb-ehci", },
>
> This is what I was getting at: an understanding of what caused the
> failue in the first place.
>
> > Now, in the build we have two drivers which dts claims compatibility
> > with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
> > for the platform. Thinking that way, in fact, the current
> > compatibility even matches drivers/usb/host/ehci-ppc-of.c which
> > obviously wont work either.
>
> Right, so I agree that it makes sense to remove a compatible string
> where there is no compatability, but a couple other things should happen
> here.
>
> 1) changelog should describe why this compatible string is in the omap
> dtsi files in first place.
>
> 2) investigation into the patch that introduced this change to double
> check it's not introducing other breakage as well.
Oddly enough, it was Roger who introduced this incorrect compatibility
string in commit f17c89948dcd6 (ARM: dts: OMAP4: Add HS USB Host IP
nodes). There is no explanation in the commit log of why the string is
there.
We better remove it from all the files where it doesn't belong. Of
course, this won't help existing hardware. It will still be necessary
to change the compatibility string used for the generic platform
drivers.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Laurent Pinchart @ 2014-02-11 15:23 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Rob Herring, Philipp Zabel, Mauro Carvalho Chehab, Grant Likely,
Rob Herring, Sylwester Nawrocki, Tomi Valkeinen, Kyungmin Park,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, Philipp Zabel
In-Reply-To: <20140211145248.GI26684@n2100.arm.linux.org.uk>
Hi Russell,
On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote:
> On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
> > On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote:
> > > This allows to reuse the same parser code from outside the V4L2
> > > framework, most importantly from display drivers. There have been
> > > patches that duplicate the code (and I am going to send one of my own),
> > > such as
> > > http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
> > > and others that parse the same binding in a different way:
> > > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
> > >
> > > I think that all common video interface parsing helpers should be moved
> > > to a single place, outside of the specific subsystems, so that it can
> > > be reused by all drivers.
> >
> > Perhaps that should be done rather than moving to drivers/of now and
> > then again to somewhere else.
>
> Do you have a better suggestion where it should move to?
>
> drivers/gpu/drm - no, because v4l2 wants to use it
> drivers/media/video - no, because DRM drivers want to use it
> drivers/video - no, because v4l2 and drm drivers want to use it
Just pointing out a missing location (which might be rejected due to similar
concerns), there's also drivers/media, which isn't V4L-specific.
> Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
> into drivers/of ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
From: Hans de Goede @ 2014-02-11 15:26 UTC (permalink / raw)
To: Roger Quadros, Greg Kroah-Hartman
Cc: Alan Stern, Tony Prisk, Florian Fainelli, Maxime Ripard,
linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Grant Likely, jwboyer-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <52FA3B2B.7050906-l0cyMroinI0@public.gmane.org>
Hi,
On 02/11/2014 04:00 PM, Roger Quadros wrote:
> Hi Hans,
>
> On 02/11/2014 04:10 PM, Hans de Goede wrote:
>> The initial versions of the devicetree enablement patches for ehci-platform
>> used "ehci-platform" as compatible string. However this was disliked by various
>> reviewers because the platform bus is a Linux invention and devicetree is
>> supposed to be OS agnostic. After much discussion I gave up, added a:
>> "depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
>> and went with the generic usb-ehci as requested.
>>
>> In retro-spect I should have stuck to my guns, because the dts files for many
>> existing boards already claim to be compatible with "usb-ehci", ie they have:
>>
>> compatible = "ti,ehci-omap", "usb-ehci";
>>
>> In theory this should not be a problem since the "ti,ehci-omap" entry takes
>> presedence, but in practice using a conflicting compatible string is an issue,
>> because it makes which driver gets used depent on driver registration order.
>>
>> This patch changes the compatible string claimed by ehci-platform (back) to
>> "ehci-platform", avoiding the driver registration / module loading ordering
>> problems, and removes the "depends on !PPC_OF" workaround.
>>
>> Note that there already is a precedent for using ?hci-platform, in the form
>> of xhci-platform.c using "xhci-platfrom" as compatible string.
>>
>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/usb-ehci.txt | 4 ++--
>> drivers/usb/host/Kconfig | 1 -
>> drivers/usb/host/ehci-platform.c | 2 +-
>> 3 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> index 2c1aeeb..46f428a 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> @@ -1,7 +1,7 @@
>> USB EHCI controllers
>>
>> Required properties:
>> - - compatible : should be "usb-ehci".
>> + - compatible : should be "ehci-platform".
>
> Won't this break DT binding info for power PC?
The powerpc bindings have never been really properly documented, ie
they rely on both usb-ehci and ibm,usb-ehci-440epx strings being there,
which was never documented. Given the issues surrounding using usb-ehci
as a compatible string I think completely removing it from the bindings
docs is best.
> I'm even OK with removing "usb-ehci" and "usb-ohci" compatibles from all OMAP dts files
> since they aren't really compatible with the original PPC driver.
I don't think that is necessary, as your grep has shown there are a lot
of dts files using compatible = "foo", "usb-?hci"; and some may even have
the dts in firmware, so we should simply make sure not to break such dts.
Regards,
Hans
^ permalink raw reply
* Re: ohci-/ehci-platform: Change compatible string to ?hci-platform
From: Alan Stern @ 2014-02-11 15:27 UTC (permalink / raw)
To: Hans de Goede
Cc: Greg Kroah-Hartman, Roger Quadros, Tony Prisk, Florian Fainelli,
Maxime Ripard, linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1392127826-31290-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, 11 Feb 2014, Hans de Goede wrote:
> Hi Greg,
>
> Can you please add these 2 patches to usb-next, to unbreak usb on various
> ARM platforms?
>
> These 2 patches can either be squashed into the first 2 patches of my previous
> set or added as is to preserve history, either way is fine with me.
>
> The 2nd patch also fixes one of the Kconfig issues and I've a better plan
> for the 2nd Kconfig issue too, so please consider this a self-nack for my
> drivers/usb/host/Kconfig patches.
>
> Here is a copy of the echi-platform commit-msg to explain the rationale of
> these changes, as well as how the breakage happened in the first place:
>
> The initial versions of the devicetree enablement patches for ehci-platform
> used "ehci-platform" as compatible string. However this was disliked by various
> reviewers because the platform bus is a Linux invention and devicetree is
> supposed to be OS agnostic. After much discussion I gave up, added a:
> "depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
> and went with the generic usb-ehci as requested.
>
> In retro-spect I should have stuck to my guns, because the dts files for many
> existing boards already claim to be compatible with "usb-ehci", ie they have:
>
> compatible = "ti,ehci-omap", "usb-ehci";
>
> In theory this should not be a problem since the "ti,ehci-omap" entry takes
> presedence, but in practice using a conflicting compatible string is an issue,
> because it makes which driver gets used depend on driver registration order.
>
> This patch changes the compatible string claimed by ehci-platform (back) to
> "ehci-platform", avoiding the driver registration / module loading ordering
> problems, and removes the "depends on !PPC_OF" workaround.
>
> Note that there already is a precedent for using ?hci-platform, in the form
> of xhci-platform.c using "xhci-platfrom" as compatible string.
I still think that "ehci-generic" would be better than "ehci-platform"
(and the same for ohci). The reason is that "-platform" is essentially
meaningless, whereas "-generic" strongly suggests that the hardware
matches the specification with no special features or requirements.
Since the compatibility string -- like everything else in DT -- is
supposed to be a description of the hardware, this seems only logical.
It might even be a good idea to change the "xhci-platform" string to
match, it that doesn't cause too much trouble.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Philipp Zabel @ 2014-02-11 15:27 UTC (permalink / raw)
To: Rob Herring
Cc: Russell King - ARM Linux, Mauro Carvalho Chehab, Grant Likely,
Rob Herring, Sylwester Nawrocki, Laurent Pinchart, Tomi Valkeinen,
Kyungmin Park, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Philipp Zabel
In-Reply-To: <CAL_Jsq+U9zU1i+STLHMBjY5BeEP6djYnJVE5X1ix-D2q_zWztQ@mail.gmail.com>
Hi Rob,
Am Dienstag, den 11.02.2014, 07:56 -0600 schrieb Rob Herring:
> On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > From: Philipp Zabel <philipp.zabel@gmail.com>
> >
> > This patch moves the parsing helpers used to parse connected graphs
> > in the device tree, like the video interface bindings documented in
> > Documentation/devicetree/bindings/media/video-interfaces.txt, from
> > drivers/media/v4l2-core to drivers/of.
>
> This is the opposite direction things have been moving...
I understand subsystem specific functionality is moving from drivers/of
into the subsystems. In this case three subsystems all could benefit
from the same set of parsing functions, so it is not clear to me where
if not drivers/of would be the correct place for this code.
> > This allows to reuse the same parser code from outside the V4L2 framework,
> > most importantly from display drivers. There have been patches that duplicate
> > the code (and I am going to send one of my own), such as
> > http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
> > and others that parse the same binding in a different way:
> > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
> >
> > I think that all common video interface parsing helpers should be moved to a
> > single place, outside of the specific subsystems, so that it can be reused
> > by all drivers.
>
> Perhaps that should be done rather than moving to drivers/of now and
> then again to somewhere else.
>
> > I moved v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
> > and v4l2_of_get_remote_port_parent. They are renamed to
> > of_graph_get_next_endpoint, of_graph_get_remote_port, and
> > of_graph_get_remote_port_parent, respectively.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> > drivers/media/Kconfig | 1 +
> > drivers/media/v4l2-core/v4l2-of.c | 117 ---------------------------------
> > drivers/of/Kconfig | 3 +
> > drivers/of/Makefile | 1 +
> > drivers/of/of_graph.c | 133 ++++++++++++++++++++++++++++++++++++++
> > include/linux/of_graph.h | 23 +++++++
> > include/media/v4l2-of.h | 16 ++---
> > 7 files changed, 167 insertions(+), 127 deletions(-)
> > create mode 100644 drivers/of/of_graph.c
> > create mode 100644 include/linux/of_graph.h
>
> [snip]
>
> > diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> > index 541cea4..404a493 100644
> > --- a/include/media/v4l2-of.h
> > +++ b/include/media/v4l2-of.h
> > @@ -17,6 +17,7 @@
> > #include <linux/list.h>
> > #include <linux/types.h>
> > #include <linux/errno.h>
> > +#include <linux/of_graph.h>
> >
> > #include <media/v4l2-mediabus.h>
> >
> > @@ -72,11 +73,6 @@ struct v4l2_of_endpoint {
> > #ifdef CONFIG_OF
> > int v4l2_of_parse_endpoint(const struct device_node *node,
> > struct v4l2_of_endpoint *endpoint);
> > -struct device_node *v4l2_of_get_next_endpoint(const struct device_node *parent,
> > - struct device_node *previous);
> > -struct device_node *v4l2_of_get_remote_port_parent(
> > - const struct device_node *node);
> > -struct device_node *v4l2_of_get_remote_port(const struct device_node *node);
> > #else /* CONFIG_OF */
> >
> > static inline int v4l2_of_parse_endpoint(const struct device_node *node,
> > @@ -85,25 +81,25 @@ static inline int v4l2_of_parse_endpoint(const struct device_node *node,
> > return -ENOSYS;
> > }
> >
> > +#endif /* CONFIG_OF */
> > +
> > static inline struct device_node *v4l2_of_get_next_endpoint(
> > const struct device_node *parent,
> > struct device_node *previous)
> > {
> > - return NULL;
> > + return of_graph_get_next_endpoint(parent, previous);
>
> Won't this break for !OF?
It will. The of_graph_* functions should get their own stubs for that
case.
regards
Philipp
^ permalink raw reply
* [PATCH] ARM: dts: omap3-n9 family: mark proper OMAP version
From: Nishanth Menon @ 2014-02-11 15:29 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel,
Nishanth Menon, Aaro Koskinen
Nokia N900 uses OMAP3430 and N9/N950 uses OMAP3630. Mark SoC compatibilty
as per Documentation/devicetree/bindings/arm/omap/omap.txt else
N9/N950 will be probed as a OMAP3430 type device, since default ti,omap3
maps to OMAP3430 compatibility.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
just build tested. but given examples such as
http://thread.gmane.org/gmane.linux.ports.arm.omap/110006
I guess, some form of failure is expected.
based on v3.14-rc2
arch/arm/boot/dts/omap3-n9.dts | 2 +-
arch/arm/boot/dts/omap3-n900.dts | 2 +-
arch/arm/boot/dts/omap3-n950.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 39828ce..9938b5d 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -14,5 +14,5 @@
/ {
model = "Nokia N9";
- compatible = "nokia,omap3-n9", "ti,omap3";
+ compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6fc85f9..97db027 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -13,7 +13,7 @@
/ {
model = "Nokia N900";
- compatible = "nokia,omap3-n900", "ti,omap3";
+ compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index b076a52..261c558 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -14,5 +14,5 @@
/ {
model = "Nokia N950";
- compatible = "nokia,omap3-n950", "ti,omap3";
+ compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
};
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox