From: Andrew Jeffery <hidden> Date: 2016-12-06 02:55:33
Hi Lee,
Here's a series describing the bindings for some MFDs in the Aspeed SoCs. I
expect there will be discussion about how I've gone about this with adding a
ranges property to the MFD bindings: The motivation here is to allow re-use of
the standard regs property to describe resources used inside the MFD. This is
partly driven by wanting to avoid modifying the existing IPMI Block Transfer
bindings which were written prior to sorting out how we were going to represent
the Aspeed LPC controller, but also because the register layout for sub-devices
of the LPC controller is quite esoteric. Further, the pinmux state depends on
bits in the Low Pin Count (LPC) bus controller, which is the motivation for
exposing a part of the LPC space as a syscon.
These issues were described in the comments of a small RFC patch, and the
implementation provided here is an extension of those thoughts:
https://lkml.org/lkml/2016/11/17/24
Some of the patches in this MFD series has been split from the v2 of Aspeed
pinmux patches posted below:
https://lkml.org/lkml/2016/11/2/263
and to address your comments on relevant patches in the v2 above I've created a
syscon directory under mfd. The Aspeed SoC Display Controller is the first
bindings document to live there (and is otherwise unchanged), and a subsequent
patch moves all documents whose compatible contains "syscon" but not
"simple-mfd".
Andrew Jeffery (6):
mfd: dt: Fix "indicates" typo in mfd bindings document
mfd: dt: ranges, #address-cells and #size-cells as optional properties
mfd: dt: Add Aspeed Low Pin Count Controller bindings
mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
mfd: dt: Move syscon bindings to syscon subdirectory
.../devicetree/bindings/mfd/aspeed-lpc.txt | 133 +++++++++++++++++++++
Documentation/devicetree/bindings/mfd/mfd.txt | 12 +-
.../devicetree/bindings/mfd/syscon/aspeed-gfx.txt | 17 +++
.../bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
.../bindings/mfd/{ => syscon}/atmel-gpbr.txt | 0
.../bindings/mfd/{ => syscon}/atmel-matrix.txt | 0
.../bindings/mfd/{ => syscon}/atmel-smc.txt | 0
.../bindings/mfd/{ => syscon}/qcom,tcsr.txt | 0
.../bindings/mfd/{ => syscon}/syscon.txt | 0
.../mfd/{ => syscon}/ti-keystone-devctrl.txt | 0
10 files changed, 161 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
create mode 100644 Documentation/devicetree/bindings/mfd/syscon/aspeed-gfx.txt
rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
--
2.9.3
--
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
From: Andrew Jeffery <hidden> Date: 2016-12-06 02:55:37
Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resources within the multi-function
device.
Signed-off-by: Andrew Jeffery <redacted>
---
Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
@@ -25,6 +25,16 @@ Optional properties: be used. In the latter case the child devices will be determined by the operating system.+- ranges: Describes the address mapping relationship to the parent. Should set+ the child's base address to 0, the physical address within parent's address+ space, and the length of the address map.++- #address-cells: Specifies the number of cells used to represent physical base+ addresses. Must be present if ranges is used.++- #size-cells: Specifies the number of cells used to represent the size of an+ address. Must be present if ranges is used.+ Example: foo@1000 {
From: Rob Herring <robh@kernel.org> Date: 2016-12-09 22:49:32
On Tue, Dec 06, 2016 at 01:53:17PM +1100, Andrew Jeffery wrote:
Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resources within the multi-function
device.
Signed-off-by: Andrew Jeffery <redacted>
---
Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
No objections to this, but this is all implied by having a reg property.
Acked-by: Rob Herring <redacted>
Rob
--
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
From: Andrew Jeffery <hidden> Date: 2016-12-09 22:55:32
On Fri, 2016-12-09 at 16:49 -0600, Rob Herring wrote:
On Tue, Dec 06, 2016 at 01:53:17PM +1100, Andrew Jeffery wrote:
quoted
Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resources within the multi-function
device.
No objections to this, but this is all implied by having a reg property.
Thanks for clarifying. I wasn't sure so I wrote the patch with the
thought that we could drop it if it wasn't necessary. Regardless, I
think being explicit about the properties is nice.
From: Lee Jones <hidden> Date: 2017-01-03 17:46:08
On Tue, 06 Dec 2016, Andrew Jeffery wrote:
Whilst describing a device and not a bus, simple-mfd is modelled on
simple-bus where child nodes are iterated and registered as platform
devices. Some complex devices, e.g. the Aspeed LPC controller, can
benefit from address space mapping such that child nodes can use the
regs property to describe their resources within the multi-function
device.
Signed-off-by: Andrew Jeffery <redacted>
@@ -25,6 +25,16 @@ Optional properties: be used. In the latter case the child devices will be determined by the operating system.+- ranges: Describes the address mapping relationship to the parent. Should set+ the child's base address to 0, the physical address within parent's address+ space, and the length of the address map.++- #address-cells: Specifies the number of cells used to represent physical base+ addresses. Must be present if ranges is used.++- #size-cells: Specifies the number of cells used to represent the size of an+ address. Must be present if ranges is used.+ Example: foo@1000 {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
@@ -19,7 +19,7 @@ Optional properties: - compatible : "simple-mfd" - this signifies that the operating system should consider all subnodes of the MFD device as separate devices akin to how- "simple-bus" inidicates when to see subnodes as children for a simple+ "simple-bus" indicates when to see subnodes as children for a simple memory-mapped bus. For more complex devices, when the nexus driver has to probe registers to figure out what child devices exist etc, this should not be used. In the latter case the child devices will be determined by the
On Tue, Dec 6, 2016 at 3:53 AM, Andrew Jeffery [off-list ref] wrote:
Signed-off-by: Andrew Jeffery <redacted>
My speling mistak.
Acked-by: Linus Walleij <redacted>
Yours,
Linus Walleij
--
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
Acked-by: Rob Herring <redacted>
--
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
@@ -19,7 +19,7 @@ Optional properties: - compatible : "simple-mfd" - this signifies that the operating system should consider all subnodes of the MFD device as separate devices akin to how- "simple-bus" inidicates when to see subnodes as children for a simple+ "simple-bus" indicates when to see subnodes as children for a simple memory-mapped bus. For more complex devices, when the nexus driver has to probe registers to figure out what child devices exist etc, this should not be used. In the latter case the child devices will be determined by the
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Jeffery <hidden> Date: 2016-12-06 02:55:42
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
Signed-off-by: Andrew Jeffery <redacted>
---
.../devicetree/bindings/mfd/aspeed-lpc.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
@@ -109,3 +109,25 @@ lpc: lpc@1e789000 { }; };+Host Node Children+==================++LPC Host Controller+-------------------++The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour+between the host and the baseboard management controller. The registers exist+in the "host" portion of the Aspeed LPC controller, which must be the parent of+the LPC host controller node.++Required properties:+- compatible: "aspeed,ast2500-lhc";+- reg: contains offset/length value of the LHC memory+ region.++Example:++lhc: lhc@20 {+ compatible = "aspeed,ast2500-lhc";+ reg = <0x20 0x24 0x48 0x8>;+};
On Tue, Dec 6, 2016 at 3:53 AM, Andrew Jeffery [off-list ref] wrote:
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
Signed-off-by: Andrew Jeffery <redacted>
Reviewed-by: Linus Walleij <redacted>
Yours,
Linus Walleij
--
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
From: Joel Stanley <joel@jms.id.au> Date: 2016-12-08 02:12:53
On Tue, Dec 6, 2016 at 1:23 PM, Andrew Jeffery [off-list ref] wrote:
quoted hunk
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
Signed-off-by: Andrew Jeffery <redacted>
---
.../devicetree/bindings/mfd/aspeed-lpc.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
@@ -109,3 +109,25 @@ lpc: lpc@1e789000 { }; };+Host Node Children+==================++LPC Host Controller+-------------------++The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour+between the host and the baseboard management controller. The registers exist+in the "host" portion of the Aspeed LPC controller, which must be the parent of+the LPC host controller node.++Required properties:+- compatible: "aspeed,ast2500-lhc";
Can you remind me why this binding doesn't cover the ast2400?
Cheers,
Joel
--
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
From: Andrew Jeffery <hidden> Date: 2016-12-08 12:08:38
On Thu, 2016-12-08 at 12:42 +1030, Joel Stanley wrote:
quoted
On Tue, Dec 6, 2016 at 1:23 PM, Andrew Jeffery [off-list ref] wrote:
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
};
};
+Host Node Children
+==================
+
+LPC Host Controller
+-------------------
+
+The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
+between the host and the baseboard management controller. The registers exist
+in the "host" portion of the Aspeed LPC controller, which must be the parent of
+the LPC host controller node.
+
+Required properties:
+- compatible: "aspeed,ast2500-lhc";
Can you remind me why this binding doesn't cover the ast2400?
Partly that we haven't yet needed the LHC for the AST2400.
Mostly that I overlooked it.
If there are other problems with series I'll address this issue, but if
not we can add it when we need it down the track.
Andrew
Cheers,
Joel
quoted
+- reg: contains offset/length value of the LHC memory
+ region.
+
+Example:
+
From: Rob Herring <robh@kernel.org> Date: 2016-12-12 15:30:22
On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
quoted hunk
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
Signed-off-by: Andrew Jeffery <redacted>
---
.../devicetree/bindings/mfd/aspeed-lpc.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
@@ -109,3 +109,25 @@ lpc: lpc@1e789000 { }; };+Host Node Children+==================++LPC Host Controller+-------------------++The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour+between the host and the baseboard management controller. The registers exist+in the "host" portion of the Aspeed LPC controller, which must be the parent of+the LPC host controller node.++Required properties:+- compatible: "aspeed,ast2500-lhc";+- reg: contains offset/length value of the LHC memory+ region.
--
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
From: Andrew Jeffery <hidden> Date: 2016-12-13 04:40:19
On Mon, 2016-12-12 at 09:30 -0600, Rob Herring wrote:
On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
quoted
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
};
+Host Node Children
+==================
+
+LPC Host Controller
+-------------------
+
+The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
+between the host and the baseboard management controller. The registers exist
+in the "host" portion of the Aspeed LPC controller, which must be the parent of
+the LPC host controller node.
+
+Required properties:
quoted
quoted
+- compatible: "aspeed,ast2500-lhc";
+- reg: contains offset/length value of the LHC memory
+ region.
How many regions? Looks like 2.
Yes, two. The first region is registers configuring various LPC host
controller properties. The second region is for configuring the LPC
serial IRQ trigger modes.
Would you like me to say as much in the patch? It's not a completely
clear split of functionality as other serial IRQ properties are also
described in the first region. Maybe describing the datasheet's
register names for the regions (LHCR[0-8] for the first, LHCR[A-B] for
the second) would help?
Cheers,
Andrew
From: Lee Jones <hidden> Date: 2017-01-03 17:46:28
On Tue, 06 Dec 2016, Andrew Jeffery wrote:
The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
on bits in both the System Control Unit and the LPC Host Controller.
The Aspeed LPC Host Controller is described as a child node of the
LPC host-range syscon device for arbitration of access by the host
controller and pinmux drivers.
Signed-off-by: Andrew Jeffery <redacted>
@@ -109,3 +109,25 @@ lpc: lpc@1e789000 { }; };+Host Node Children+==================++LPC Host Controller+-------------------++The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour+between the host and the baseboard management controller. The registers exist+in the "host" portion of the Aspeed LPC controller, which must be the parent of+the LPC host controller node.++Required properties:+- compatible: "aspeed,ast2500-lhc";+- reg: contains offset/length value of the LHC memory+ region.++Example:++lhc: lhc@20 {+ compatible = "aspeed,ast2500-lhc";+ reg = <0x20 0x24 0x48 0x8>;+};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Jeffery <hidden> Date: 2016-12-06 02:56:18
The Aspeed SoC Display Controller is presented as a syscon device to
arbitrate access by display and pinmux drivers. Video pinmux
configuration on fifth generation SoCs depends on bits in both the
System Control Unit and the Display Controller.
Signed-off-by: Andrew Jeffery <redacted>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/mfd/syscon/aspeed-gfx.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/syscon/aspeed-gfx.txt
@@ -0,0 +1,17 @@+* Device tree bindings for Aspeed SoC Display Controller (GFX)++The Aspeed SoC Display Controller primarily does as its name suggests, but also+participates in pinmux requests on the g5 SoCs. It is therefore considered a+syscon device.++Required properties:+- compatible: "aspeed,ast2500-gfx", "syscon"+- reg: contains offset/length value of the GFX memory+ region.++Example:++gfx: display@1e6e6000 {+ compatible = "aspeed,ast2500-gfx", "syscon";+ reg = <0x1e6e6000 0x1000>;+};
From: Lee Jones <hidden> Date: 2017-01-03 17:47:35
On Tue, 06 Dec 2016, Andrew Jeffery wrote:
The Aspeed SoC Display Controller is presented as a syscon device to
arbitrate access by display and pinmux drivers. Video pinmux
configuration on fifth generation SoCs depends on bits in both the
System Control Unit and the Display Controller.
Signed-off-by: Andrew Jeffery <redacted>
Acked-by: Rob Herring <robh@kernel.org>
@@ -0,0 +1,17 @@+* Device tree bindings for Aspeed SoC Display Controller (GFX)++The Aspeed SoC Display Controller primarily does as its name suggests, but also+participates in pinmux requests on the g5 SoCs. It is therefore considered a+syscon device.++Required properties:+- compatible: "aspeed,ast2500-gfx", "syscon"+- reg: contains offset/length value of the GFX memory+ region.++Example:++gfx: display@1e6e6000 {+ compatible = "aspeed,ast2500-gfx", "syscon";+ reg = <0x1e6e6000 0x1000>;+};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Jeffery <hidden> Date: 2016-12-06 02:56:21
The use of syscons is growing, lets collate them in their own part of
the bindings tree.
Signed-off-by: Andrew Jeffery <redacted>
---
Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt | 0
.../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt | 0
7 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/syscon/aspeed-scu.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/aspeed-scu.txtrename to Documentation/devicetree/bindings/mfd/syscon/aspeed-scu.txtdiff --git a/Documentation/devicetree/bindings/mfd/atmel-gpbr.txt b/Documentation/devicetree/bindings/mfd/syscon/atmel-gpbr.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/atmel-gpbr.txtrename to Documentation/devicetree/bindings/mfd/syscon/atmel-gpbr.txtdiff --git a/Documentation/devicetree/bindings/mfd/atmel-matrix.txt b/Documentation/devicetree/bindings/mfd/syscon/atmel-matrix.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/atmel-matrix.txtrename to Documentation/devicetree/bindings/mfd/syscon/atmel-matrix.txtdiff --git a/Documentation/devicetree/bindings/mfd/atmel-smc.txt b/Documentation/devicetree/bindings/mfd/syscon/atmel-smc.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/atmel-smc.txtrename to Documentation/devicetree/bindings/mfd/syscon/atmel-smc.txtdiff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/syscon/qcom,tcsr.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/qcom,tcsr.txtrename to Documentation/devicetree/bindings/mfd/syscon/qcom,tcsr.txtdiff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon/syscon.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/syscon.txtrename to Documentation/devicetree/bindings/mfd/syscon/syscon.txtdiff --git a/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt b/Documentation/devicetree/bindings/mfd/syscon/ti-keystone-devctrl.txtsimilarity index 100%rename from Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txtrename to Documentation/devicetree/bindings/mfd/syscon/ti-keystone-devctrl.txt
--
2.9.3
From: Rob Herring <robh@kernel.org> Date: 2016-12-12 15:39:15
On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
The use of syscons is growing, lets collate them in their own part of
the bindings tree.
Signed-off-by: Andrew Jeffery <redacted>
---
Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt | 0
Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt | 0
.../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt | 0
7 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
I'm not so sure this is the right direction. syscon usage is pretty much
spread throughout the tree.
Rob
--
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
I'm not so sure this is the right direction. syscon usage is pretty much
spread throughout the tree.
This patch was created based on my interpretation of Lee's feedback
here:
https://lkml.org/lkml/2016/11/18/650
Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.
I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.
Andrew
I'm not so sure this is the right direction. syscon usage is pretty much
spread throughout the tree.
This patch was created based on my interpretation of Lee's feedback
here:
https://lkml.org/lkml/2016/11/18/650
Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.
I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.
The sub-directory is a good idea for drivers who are *solely* syscon
based.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
I'm not so sure this is the right direction. syscon usage is pretty much
spread throughout the tree.
This patch was created based on my interpretation of Lee's feedback
here:
https://lkml.org/lkml/2016/11/18/650
Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.
I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.
The sub-directory is a good idea for drivers who are *solely* syscon
based.
Yes, I wasn't saying otherwise, just commenting on my motivation and
approach.
As far as I can tell all of the bindings I move here describe solely
syscon-based devices.
Cheers,
Andrew
On Tuesday, December 13, 2016 10:35:34 PM CET Andrew Jeffery wrote:
On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
quoted
On Tue, 13 Dec 2016, Andrew Jeffery wrote:
quoted
On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
quoted
On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.
I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.
The sub-directory is a good idea for drivers who are *solely* syscon
based.
Yes, I wasn't saying otherwise, just commenting on my motivation and
approach.
As far as I can tell all of the bindings I move here describe solely
syscon-based devices.
But do we know which ones they are?
In principle, any syscon device node can have a specialized driver
exporting an interface, the bindings always allow it to be done
one way or the other, and we may change the driver or run a different
OS that has decided differently.
Arnd
--
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
From: Andrew Jeffery <hidden> Date: 2016-12-13 12:39:16
On Tue, 2016-12-13 at 13:17 +0100, Arnd Bergmann wrote:
On Tuesday, December 13, 2016 10:35:34 PM CET Andrew Jeffery wrote:
quoted
On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
quoted
On Tue, 13 Dec 2016, Andrew Jeffery wrote:
quoted
On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
quoted
On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.
I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.
The sub-directory is a good idea for drivers who are *solely* syscon
based.
Yes, I wasn't saying otherwise, just commenting on my motivation and
approach.
As far as I can tell all of the bindings I move here describe solely
syscon-based devices.
But do we know which ones they are?
In principle, any syscon device node can have a specialized driver
exporting an interface, the bindings always allow it to be done
one way or the other, and we may change the driver or run a different
OS that has decided differently.
Right; for the Linux case there are currently no driver implementations
that match on the compatible strings in the documents I moved (save for
qcom,tcsr, except that it's the qcom,gsbi compatible driver parsing a
phandle to the qcom,tcsr syscon node).
However, I can't guarantee the solely-syscon property for other
operating systems. Given that, it now looks to me like we shouldn't
have such a directory at all.
Cheers,
Andrew
@@ -0,0 +1,111 @@+======================================================================+Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller+======================================================================++The LPC bus is a means to bridge a host CPU to a number of low-bandwidth+peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The+primary use case of the Aspeed LPC controller is as a slave on the bus+(typically in a Baseboard Management Controller SoC), but under certain+conditions it can also take the role of bus master.++The LPC controller is represented as a multi-function device to account for the+mix of functionality it provides. The principle split is between the register+layout at the start of the I/O space which is, to quote the Aspeed datasheet,+"basically compatible with the [LPC registers from the] popular BMC controller+H8S/2168[1]", and everything else, where everything else is an eclectic+collection of functions with a esoteric register layout. "Everything else",+here labeled the "host" portion of the controller, includes, but is not limited+to:++* An IPMI Block Transfer[2] Controller++* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the+ physical properties of some LPC pins, configuration of serial IRQs, and+ APB-to-LPC bridging amonst other functions.++* An LPC Host Interface Controller: Manages functions exposed to the host such+ as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART+ management and bus snoop configuration.++* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom+ hardware management protocols for handover between the host and baseboard+ management controller.++Additionally the state of the LPC controller influences the pinmux+configuration, therefore the host portion of the controller is exposed as a+syscon as a means to arbitrate access.++[0] http://www.intel.com/design/chipsets/industry/25128901.pdf+[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4+[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf+[3] https://en.wikipedia.org/wiki/Super_I/O++Required properties+===================++- compatible: One of:+ "aspeed,ast2400-lpc", "simple-mfd"+ "aspeed,ast2500-lpc", "simple-mfd"++- reg: contains the physical address and length values of the Aspeed+ LPC memory region.++- #address-cells: <1>+- #size-cells: <1>+- ranges: Maps 0 to the physical address and length of the LPC memory+ region++Required LPC Child nodes+========================++BMC Node+--------++- compatible: One of:+ "aspeed,ast2400-lpc-bmc"+ "aspeed,ast2500-lpc-bmc"++- reg: contains the physical address and length values of the+ H8S/2168-compatible LPC controller memory region++Host Node+---------++- compatible: One of:+ "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"+ "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"++- reg: contains the address and length values of the host-related+ register space for the Aspeed LPC controller++- #address-cells: <1>+- #size-cells: <1>+- ranges: Maps 0 to the address and length of the host-related LPC memory+ region++Example:++lpc: lpc@1e789000 {+ compatible = "aspeed,ast2500-lpc", "simple-mfd";+ reg = <0x1e789000 0x1000>;++ #address-cells = <1>;+ #size-cells = <1>;+ ranges = <0x0 0x1e789000 0x1000>;++ lpc_bmc: lpc-bmc@0 {+ compatible = "aspeed,ast2500-lpc-bmc";+ reg = <0x0 0x80>;+ };++ lpc_host: lpc-host@80 {+ compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";+ reg = <0x80 0x1e0>;+ reg-io-width = <4>;++ #address-cells = <1>;+ #size-cells = <1>;+ ranges = <0x0 0x80 0x1e0>;+ };+};+
@@ -0,0 +1,111 @@+======================================================================+Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller+======================================================================++The LPC bus is a means to bridge a host CPU to a number of low-bandwidth+peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The+primary use case of the Aspeed LPC controller is as a slave on the bus+(typically in a Baseboard Management Controller SoC), but under certain+conditions it can also take the role of bus master.++The LPC controller is represented as a multi-function device to account for the+mix of functionality it provides. The principle split is between the register+layout at the start of the I/O space which is, to quote the Aspeed datasheet,+"basically compatible with the [LPC registers from the] popular BMC controller+H8S/2168[1]", and everything else, where everything else is an eclectic+collection of functions with a esoteric register layout. "Everything else",+here labeled the "host" portion of the controller, includes, but is not limited+to:++* An IPMI Block Transfer[2] Controller++* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the+ physical properties of some LPC pins, configuration of serial IRQs, and+ APB-to-LPC bridging amonst other functions.++* An LPC Host Interface Controller: Manages functions exposed to the host such+ as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART+ management and bus snoop configuration.++* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom+ hardware management protocols for handover between the host and baseboard+ management controller.++Additionally the state of the LPC controller influences the pinmux+configuration, therefore the host portion of the controller is exposed as a+syscon as a means to arbitrate access.++[0] http://www.intel.com/design/chipsets/industry/25128901.pdf+[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4+[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf+[3] https://en.wikipedia.org/wiki/Super_I/O++Required properties+===================++- compatible: One of:+ "aspeed,ast2400-lpc", "simple-mfd"+ "aspeed,ast2500-lpc", "simple-mfd"++- reg: contains the physical address and length values of the Aspeed+ LPC memory region.++- #address-cells: <1>+- #size-cells: <1>+- ranges: Maps 0 to the physical address and length of the LPC memory+ region++Required LPC Child nodes+========================++BMC Node+--------++- compatible: One of:+ "aspeed,ast2400-lpc-bmc"+ "aspeed,ast2500-lpc-bmc"++- reg: contains the physical address and length values of the+ H8S/2168-compatible LPC controller memory region++Host Node+---------++- compatible: One of:+ "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"+ "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"++- reg: contains the address and length values of the host-related+ register space for the Aspeed LPC controller++- #address-cells: <1>+- #size-cells: <1>+- ranges: Maps 0 to the address and length of the host-related LPC memory+ region++Example:++lpc: lpc@1e789000 {+ compatible = "aspeed,ast2500-lpc", "simple-mfd";+ reg = <0x1e789000 0x1000>;++ #address-cells = <1>;+ #size-cells = <1>;+ ranges = <0x0 0x1e789000 0x1000>;++ lpc_bmc: lpc-bmc@0 {+ compatible = "aspeed,ast2500-lpc-bmc";+ reg = <0x0 0x80>;+ };++ lpc_host: lpc-host@80 {+ compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";+ reg = <0x80 0x1e0>;+ reg-io-width = <4>;++ #address-cells = <1>;+ #size-cells = <1>;+ ranges = <0x0 0x80 0x1e0>;+ };+};+
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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