simple-mfd and syscon LEDs
Subsystems (5)
cover simple-mfd and syscon LEDs
This patch series implements a suggestion from Lee Jones on how to resolve the dilemma with subnodes under syscons that do things like the simple syscon LEDs.
Please see the bigger picture, this is not about LEDs only but any simple subnodes under an MFD.
Linus Walleij (5):
MFD/OF: document MFD devices and handle simple-mfd
ARM: dts: update syscons to use simple-mfd
leds: syscon: instantiate from platform device
arm64: juno: Add APB registers and LEDs using syscon
arm64: add LEDs and some trigger support to defconfig
Documentation/devicetree/bindings/mfd/mfd.txt | 40 ++++++ arch/arm/boot/dts/arm-realview-pb1176.dts | 2 +- arch/arm/boot/dts/integrator.dtsi | 4 +- arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 68 +++++++++++ arch/arm64/configs/defconfig | 6 + drivers/leds/leds-syscon.c | 170 +++++++++++++------------- drivers/of/platform.c | 1 + 7 files changed, 203 insertions(+), 88 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
Signature · 1 line
1.9.3
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
---
I make the patch to the OF core in this one, it makes much more sense since it's a oneliner
Lee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2
--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txt
Documentation/devicetree/bindings/mfd/mfd.txt new file +40 -0
@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks spawning +multiple child devices. + +A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough + silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a + mix of unrelated registers. + +Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system. + +Example: + +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "myled"; + default-state = "on"; + }; +};
drivers/of/platform.c +1 -0
@@ -26,6 +26,7 @@const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, + { .compatible ="simple-mfd" , }, #ifdef CONFIG_ARM_AMBA { .compatible ="arm,amba-bus" , }, #endif /* CONFIG_ARM_AMBA */
Signature · 1 line
1.9.3
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 46 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>---
I make the patch to the OF core in this one, it makes much more sense since it's a onelinerLee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txtDocumentation/devicetree/bindings/mfd/mfd.txt new file +0
-0
Documentation/devicetree/bindings/mfd/mfd.txt line 3
Quoted 3 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +3
-0@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks
I don't think you meant 'comprise' here. Perhaps 'represent' might fit better?
Documentation/devicetree/bindings/mfd/mfd.txt line 4
Quoted 1 line
Documentation/devicetree/bindings/mfd/mfd.txt new file +1
-0+spawning multiple child devices.
Spawning devices is something software will do. Think less about what the actions the OS will take order to handle these IPs and more about what they are physically. I would prefer the description mentions that these chips are single pieces of silicon which contain >1 devices with non-unique/varying functionality.
Documentation/devicetree/bindings/mfd/mfd.txt line 9
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +4
-0+A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough
Please capitalise the expanded PMIC abbreviation.
Documentation/devicetree/bindings/mfd/mfd.txt line 16
Quoted 7 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +7
-0+ silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a + mix of unrelated registers.
s/registers/{hardware|devices}/
Documentation/devicetree/bindings/mfd/mfd.txt line 21
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +4
-0+Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how
This is pretty Linux specific IMHO. Other OSes might not spawn seperate devices to handle MFD type h/w. The idea is fine, but please generify a little.
Documentation/devicetree/bindings/mfd/mfd.txt line 29
Quoted 8 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +8
-0+ "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system. + +Example: + +foo at 1000 {
Should be 10000.
Documentation/devicetree/bindings/mfd/mfd.txt line 30
Quoted 1 line
Documentation/devicetree/bindings/mfd/mfd.txt new file +1
-0+ compatible = "syscon", "simple-mfd";
Please address your tabbing issues.
Quoted 22 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +10
-0+ reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "myled"; + default-state = "on"; + }; +};drivers/of/platform.c +1
-0@@ -26,6 +26,7 @@const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, + { .compatible ="simple-mfd" , }, #ifdef CONFIG_ARM_AMBA { .compatible ="arm,amba-bus" , }, #endif /* CONFIG_ARM_AMBA */
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 8 lines · Lee Jones
Documentation/devicetree/bindings/mfd/mfd.txt
Quoted 3 lines · Linus Walleij
Documentation/devicetree/bindings/mfd/mfd.txt new file +3
-0+Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocksI don't think you meant 'comprise' here. Perhaps 'represent' might fit better?
I meant "comprise", even looked up the same word in a Swedish-English dictionary. I mean those devices really are such heterogeneous things, not just modeled like such in Linux.
Quoted 7 lines
Quoted 1 line
+spawning multiple child devices.
Spawning devices is something software will do. Think less about what the actions the OS will take order to handle these IPs and more about what they are physically. I would prefer the description mentions that these chips are single pieces of silicon which contain >1 devices with non-unique/varying functionality.
OK.
Quoted 6 lines
Documentation/devicetree/bindings/mfd/mfd.txt line 9
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +4
-0+A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (roughPlease capitalise the expanded PMIC abbreviation.
OK.
Quoted 9 lines
Documentation/devicetree/bindings/mfd/mfd.txt line 16
Quoted 7 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +7
-0+ silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a + mix of unrelated registers.s/registers/{hardware|devices}/
OK.
Quoted 8 lines
Documentation/devicetree/bindings/mfd/mfd.txt line 21
Quoted 4 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +4
-0+Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to howThis is pretty Linux specific IMHO. Other OSes might not spawn seperate devices to handle MFD type h/w. The idea is fine, but please generify a little.
OK.
Quoted 3 lines
Quoted 1 line
+foo at 1000 {
Should be 10000.
OK.
Quoted 3 lines
Quoted 1 line
+ compatible = "syscon", "simple-mfd";
Please address your tabbing issues.
OK.
Yours,
Linus Walleij
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Linus WalleijQuoted 61 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>---
I make the patch to the OF core in this one, it makes much more sense since it's a onelinerLee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txtDocumentation/devicetree/bindings/mfd/mfd.txt new file +15
-0@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks spawning +multiple child devices. + +A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough + silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a
Documentation/devicetree/bindings/mfd/mfd.txt line 25
Quoted 10 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +10
-0+ mix of unrelated registers. + +Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system.
If you point of_platform_populate to the parent node, it should instantiate all children regardless of "simple-bus" or any other match. The match is to probe the grandchildren. I could be mistaken, but that's how it works at the root level. You don't have a driver probe for the parent, so you want the top level of_platform_populate call to instantiate these devices?
Why does simple-bus not work for you? After all, it is not "simple-memory-map-bus."
Rob
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 80 lines · Rob Herring
Quoted 61 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>---
I make the patch to the OF core in this one, it makes much more sense since it's a onelinerLee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txtDocumentation/devicetree/bindings/mfd/mfd.txt new file +15
-0@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks spawning +multiple child devices. + +A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough + silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing aDocumentation/devicetree/bindings/mfd/mfd.txt line 25
Quoted 10 lines
Documentation/devicetree/bindings/mfd/mfd.txt new file +10
-0+ mix of unrelated registers. + +Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system.If you point
of_platform_populateto the parent node, it should instantiate all children regardless of "simple-bus" or any other match. The match is to probe the grandchildren. I could be mistaken, but that's how it works at the root level. You don't have a driver probe for the parent, so you want the top levelof_platform_populatecall to instantiate these devices?
Quoted 2 lines
Why does simple-bus not work for you? After all, it is not "simple-memory-map-bus."
simple-bus does 'work'. There are even some (3 I think) platforms actively making use of it. However, there was some controversy over using it, as syscon isn't really a bus.
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Rob HerringQuoted 14 lines · Rob Herring
Documentation/devicetree/bindings/mfd/mfd.txt line 25
Quoted 8 lines · Linus Walleij
Documentation/devicetree/bindings/mfd/mfd.txt new file +8
-0+Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system.If you point
of_platform_populateto the parent node, it should instantiate all children regardless of "simple-bus" or any other match. The match is to probe the grandchildren.
Yep, if children are only children of the top node, yes.
Quoted 2 lines
I could be mistaken,
but that's how it works at the root level.
Yes but only at the root level.
Quoted 3 lines
You don't have a driver
probe for the parent, so you want the top levelof_platform_populatecall to instantiate these devices?
of_platform_populate() only populates one level unless the node has something like "simple-bus" or this new "simple-mfd" compatible on it.
Quoted 2 lines
Why does simple-bus not work for you? After all, it is not "simple-memory-map-bus."
As Lee says it works (obviously since I'm just adding a oneliner doing exactly the same thing as "simple-bus"), but the terminology is just wrong. It's not a bus in any hardware sense, as MFD is a logical subdevice split, nothing else.
Yours,
Linus Walleij
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Linus WalleijHi,
As part of the system timer cleanup, I'll actually be needing that patch. Is it scheduled for inclusion or should I use "simple-bus" in the meantime?
Quoted 106 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>---
I make the patch to the OF core in this one, it makes much more sense since it's a onelinerLee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txtDocumentation/devicetree/bindings/mfd/mfd.txt new file +40
-0@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks spawning +multiple child devices. + +A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough + silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a + mix of unrelated registers. + +Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system. + +Example: + +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "myled"; + default-state = "on"; + }; +};drivers/of/platform.c +1
-0@@ -26,6 +26,7 @@const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, + { .compatible ="simple-mfd" , }, #ifdef CONFIG_ARM_AMBA { .compatible ="arm,amba-bus" , }, #endif /* CONFIG_ARM_AMBA */Signature · 7 lines
1.9.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 3 lines
Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 3 lines · Alexandre Belloni
As part of the system timer cleanup, I'll actually be needing that patch. Is it scheduled for inclusion or should I use "simple-bus" in the meantime?
No replies to the thread so I will send a pull request to ARM SoC cleanup branch.
Yours,
Linus Walleij
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 9 lines · Linus Walleij
Quoted 3 lines · Alexandre Belloni
As part of the system timer cleanup, I'll actually be needing that patch. Is it scheduled for inclusion or should I use "simple-bus" in the meantime?
No replies to the thread so I will send a pull request to ARM SoC cleanup branch.
Ah well I had some pending changes requested by Lee. Once Lee ACK it for MFD and (hopefully) Bryan pitches in for LEDs, I'll post a pull request.
BTW: Alexandre: your ACK or Reviewed-by would be appreciated ;)
Antione: if you're also using this, pls provide your ACK on the series.
Yours,
Linus Walleij
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Linus WalleijQuoted 9 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Quoted 11 lines
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>
Signature · 3 lines
Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Linus WalleijQuoted 9 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Quoted 11 lines
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>
Since I'm also using this,
Quoted 86 lines
---
I make the patch to the OF core in this one, it makes much more sense since it's a onelinerLee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txtDocumentation/devicetree/bindings/mfd/mfd.txt new file +40
-0@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks spawning +multiple child devices. + +A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough + silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a + mix of unrelated registers. + +Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system. + +Example: + +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "myled"; + default-state = "on"; + }; +};drivers/of/platform.c +1
-0@@ -26,6 +26,7 @@const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, + { .compatible ="simple-mfd" , }, #ifdef CONFIG_ARM_AMBA { .compatible ="arm,amba-bus" , }, #endif /* CONFIG_ARM_AMBA */Signature · 7 lines
1.9.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 3 lines
Antoine T?nart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Linus WalleijQuoted 91 lines · Linus Walleij
This defines a new compatible option for MFD devices "simple-mfd" that will make the OF core spawn child devices for all subnodes of that MFD device. It is optional but handy for things like syscon and possibly other simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity to make a small writeup on MFD devices and add the compatible definition there.
Suggested-by Lee Jones <[email protected]>Cc Arnd Bergmann <[email protected]>Cc Devicetree <[email protected]>Cc Rob Herring <[email protected]>Cc Benjamin Herrenschmidt <[email protected]>Cc Grant Likely <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Cc Ian Campbell <[email protected]>Cc Kumar Gala <[email protected]>Signed-off-by Linus Walleij <[email protected]>---
I make the patch to the OF core in this one, it makes much more sense since it's a onelinerLee: this is a (tested!) implementation of your suggestion for simple-mfd. If you can eventually ACK this from the MFD side, I think it should be funneled through the ARM SoC tree.
Grant/Rob: if either of you can ACK the change to the OF core likewise it can be taken through ARM SoC.
DT binings maintainers: there is some background discussion on this here:
http://marc.info/?l=linux-arm-kernel&m=142486676603889&w=2
http://marc.info/?l=devicetree&m=142166313621469&w=2--- Documentation/devicetree/bindings/mfd/mfd.txt | 40 +++++++++++++++++++++++++++ drivers/of/platform.c | 1 + 2 files changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/mfd.txtDocumentation/devicetree/bindings/mfd/mfd.txt new file +40
-0@@ -0,0 +1,40 @@ +Multi-Function Devices (MFD) + +These devices comprise a nexus for heterogeneous hardware blocks spawning +multiple child devices. + +A typical MFD can be: + +- A mixed signal ASIC on an external bus, sometimes a PMIC (power management + integrated circuit) that is manufactured in a lower technology node (rough + silicon) that handles analog drivers for things like audio amplifiers, LED + drivers, level shifters, PHY (physical interfaces to things like USB or + ethernet), regulators etc. + +- A range of memory registers containing "miscellaneous system registers" also + known as a system controller "syscon" or any other memory range containing a + mix of unrelated registers. + +Optional properties: + +- compatible : "simple-mfd" - this signifies that the operating system should + spawn child devices for all the subnodes of the MFD device akin to how + "simple-bus" inidicates when to spawn children for a simple memory-mapped + bus. For more complex devices, when the nexus driver has to probe registers + to figure out what children exist etc, this should not be used. In the latter + case the child devices will be instantiated by the operating system. + +Example: + +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "myled"; + default-state = "on"; + }; +};drivers/of/platform.c +0
-0
drivers/of/platform.c line 32
Quoted 7 lines
drivers/of/platform.c +1
-0@@ -26,6 +26,7 @@const struct of_device_id of_default_bus_match_table[] = { { .compatible ="simple-bus" , }, + { .compatible ="simple-mfd" , }, #ifdef CONFIG_ARM_AMBA { .compatible ="arm,amba-bus" , }, #endif /* CONFIG_ARM_AMBA */
Alright, so:
However, I think this is going to lead to a future problem. It solves the immediate case of getting an MFD device to be auto populated when the kernel doesn't need to immediately do something. However, I can forsee a situation where the device can be supported by simple-mfd, but at some point it is discovered that better features can be enabled if the mfd device has a proper driver.
If/when we get into that situation, the above still works, but we're going to need to add a blacklist match table so that simple-mfd can be overridden by a more-specific compatible value. I don't have any problems with doing that, but someone needs to implement it.
g.
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 6 lines · Grant Likely
However, I think this is going to lead to a future problem. It solves the immediate case of getting an MFD device to be auto populated when the kernel doesn't need to immediately do something. However, I can forsee a situation where the device can be supported by simple-mfd, but at some point it is discovered that better features can be enabled if the mfd device has a proper driver.
For the general case where access to the MFD needs some mediation or marshalling yes, I think this is theoretically possible.
For the most common MMIO case where the MFD devide is a syscon, it is not so likely. Or rather extremelt unlikely.
We could restrict the use cases to strictly syscon/MMIO MFD devices but it would just be a documentation fix.
Yours,
Linus Walleij
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Linus WalleijHi,
I understand this is bikeshedding to some extent, but I'd also like to avoid needless variation in binding formats:
Documentation/devicetree/bindings/mfd/mfd.txt line 33
Quoted 6 lines · Linus Walleij
Documentation/devicetree/bindings/mfd/mfd.txt new file +6
-0+ +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 {
This doesn't seem to be a typo, you're using a period in the unit address. I've never seen that done before, usually commas are used instead.
Was there a reason for going with period?
-Olof
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
Quoted 18 lines · Olof Johansson
Hi,
I understand this is bikeshedding to some extent, but I'd also like to avoid needless variation in binding formats:
Documentation/devicetree/bindings/mfd/mfd.txt line 33
Quoted 6 lines · Linus Walleij
Documentation/devicetree/bindings/mfd/mfd.txt new file +6
-0+ +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 {This doesn't seem to be a typo, you're using a period in the unit address. I've never seen that done before, usually commas are used instead.
Quoted 1 line
Was there a reason for going with period?
LEDs have always done it [1]. I guess Bryan would be the best person to answer the 'why'.
git grep "led.*@[0-9]*[.,][0-9]*" -- Documentation/devicetree/ arch/arm/boot/dts/
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH 1/5 MFD/OF: document MFD devices and handle simple-mfd
In reply to Olof JohanssonQuoted 13 lines · Olof Johansson
Documentation/devicetree/bindings/mfd/mfd.txt line 33
Quoted 6 lines · Linus Walleij
Documentation/devicetree/bindings/mfd/mfd.txt new file +6
-0+ +foo at 1000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 {This doesn't seem to be a typo, you're using a period in the unit address. I've never seen that done before, usually commas are used instead.
Quoted 1 line
Was there a reason for going with period?
It was the suggested syntax from DT binding maintainer Rob Herring in July last year:
http://marc.info/?l=linux-arm-kernel&m=140629736615939&w=2
Yours,
Linus Walleij
PATCH 2/5 ARM: dts: update syscons to use simple-mfd
In reply to Linus WalleijThe Integrators and the RealView use simple MFD devices with register bit LEDs as subnodes, update these to use the "simple-mfd" compatible property so that subdevices get spawned from the MFD nexi.
--- arch/arm/boot/dts/arm-realview-pb1176.dts | 2 +- arch/arm/boot/dts/integrator.dtsi | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/arm/boot/dts/arm-realview-pb1176.dts +1 -1
@@ -114,7 +114,7 @@ ranges; syscon: syscon at 10000000 { - compatible = "arm,realview-pb1176-syscon", "syscon"; + compatible = "arm,realview-pb1176-syscon", "syscon", "simple-mfd"; reg = <0x10000000 0x1000>; led at 08.0 {
arch/arm/boot/dts/integrator.dtsi +2 -2
@@ -6,7 +6,7 @@ / { core-module at 10000000 { - compatible = "arm,core-module-integrator", "syscon"; + compatible = "arm,core-module-integrator", "syscon", "simple-mfd"; reg = <0x10000000 0x200>; /* Use core module LED to indicate CPU load */
@@ -95,7 +95,7 @@ syscon { /* Debug registers mapped as syscon */ - compatible = "syscon"; + compatible = "syscon", "simple-mfd"; reg = <0x1a000000 0x10>; led at 04.0 {
Signature · 1 line
1.9.3
PATCH 3/5 leds: syscon: instantiate from platform device
In reply to Linus WalleijCurrently syscon LEDs will traverse the device tree looking for syscon devices and if found, traverse any subnodes of these to identify matching children and from there instantiate LED class devices.
This is not a good use of the Linux device model. Instead we have converted the device trees to add the "simple-mfd" property to the MFD nexi spawning syscon LEDs so that these will appear as platform devices in the system and we can use the proper device probing mechanism.
---
Bryan: if you're OK with it, please ACK this patch so we can funnel it through ARM SoC with the rest of the patches in this series.
--- drivers/leds/leds-syscon.c | 170 ++++++++++++++++++++++----------------------- 1 file changed, 85 insertions(+), 85 deletions(-)
drivers/leds/leds-syscon.c +85 -85
@@ -20,6 +20,7 @@* MA 02111-1307 USA */ #include <linux/io.h> +#include <linux/module.h> #include <linux/of_device.h> #include <linux/of_address.h> #include <linux/platform_device.h>
@@ -66,102 +67,101 @@ static void syscon_led_set(struct led_classdev *led_cdev,dev_err (sled->cdev.dev,"error updating LED status\n" ); } -static int __init syscon_leds_spawn (struct device_node *np, -struct device *dev, -struct regmap *map) +static int syscon_led_probe (struct platform_device *pdev) { -struct device_node *child; +struct device *dev = &pdev->dev; +struct device_node *np = dev->of_node; +struct device *parent; +struct regmap *map; +struct syscon_led *sled; +const char *state;int ret; -for_each_available_child_of_node (np, child) { -struct syscon_led *sled; -const char *state; - -/* Only check for register-bit-leds */ -if (of_property_match_string (child,"compatible" , -"register-bit-led" ) <0 ) -continue ; - - sled =devm_kzalloc (dev,sizeof (*sled),GFP_KERNEL ); -if (!sled) -return -ENOMEM ; - - sled->map = map; - -if (of_property_read_u32 (child,"offset" , &sled->offset)) -return -EINVAL ; -if (of_property_read_u32 (child,"mask" , &sled->mask)) -return -EINVAL ; - sled->cdev.name = -of_get_property (child,"label" ,NULL ) ? : child->name; - sled->cdev.default_trigger = -of_get_property (child,"linux,default-trigger" ,NULL ); - - state =of_get_property (child,"default-state" ,NULL ); -if (state) { -if (!strcmp (state,"keep" )) { -u32 val; - - ret =regmap_read (map, sled->offset, &val); -if (ret <0 ) -return ret; - sled->state = !!(val & sled->mask); - }else if (!strcmp (state,"on" )) { - sled->state = true; - ret =regmap_update_bits (map, sled->offset, - sled->mask, - sled->mask); -if (ret <0 ) -return ret; - }else { - sled->state = false; - ret =regmap_update_bits (map, sled->offset, - sled->mask,0 ); -if (ret <0 ) -return ret; - } + parent = dev->parent; +if (!parent) { +dev_err (dev,"no parent for syscon LED\n" ); +return -ENODEV ; + } + map =syscon_node_to_regmap (parent->of_node); +if (!map) { +dev_err (dev,"no regmap for syscon LED parent\n" ); +return -ENODEV ; + } + + sled =devm_kzalloc (dev,sizeof (*sled),GFP_KERNEL ); +if (!sled) +return -ENOMEM ; + + sled->map = map; + +if (of_property_read_u32 (np,"offset" , &sled->offset)) +return -EINVAL ; +if (of_property_read_u32 (np,"mask" , &sled->mask)) +return -EINVAL ; + sled->cdev.name = +of_get_property (np,"label" ,NULL ) ? : np->name; + sled->cdev.default_trigger = +of_get_property (np,"linux,default-trigger" ,NULL ); + + state =of_get_property (np,"default-state" ,NULL ); +if (state) { +if (!strcmp (state,"keep" )) { +u32 val; + + ret =regmap_read (map, sled->offset, &val); +if (ret <0 ) +return ret; + sled->state = !!(val & sled->mask); + }else if (!strcmp (state,"on" )) { + sled->state = true; + ret =regmap_update_bits (map, sled->offset, + sled->mask, + sled->mask); +if (ret <0 ) +return ret; + }else { + sled->state = false; + ret =regmap_update_bits (map, sled->offset, + sled->mask,0 ); +if (ret <0 ) +return ret; } - sled->cdev.brightness_set = syscon_led_set; + } + sled->cdev.brightness_set = syscon_led_set; - ret =led_classdev_register (dev, &sled->cdev); -if (ret <0 ) -return ret; + ret =led_classdev_register (dev, &sled->cdev); +if (ret <0 ) +return ret; + +platform_set_drvdata (pdev, sled); +dev_info (dev,"registered LED %s\n" , sled->cdev.name); -dev_info (dev,"registered LED %s\n" , sled->cdev.name); - }return 0 ; } -static int __init syscon_leds_init (void ) +static int syscon_led_remove (struct platform_device *pdev) { -struct device_node *np; - -for_each_of_allnodes (np) { -struct platform_device *pdev; -struct regmap *map; -int ret; +struct syscon_led *sled =platform_get_drvdata (pdev); -if (!of_device_is_compatible (np,"syscon" )) -continue ; +led_classdev_unregister (&sled->cdev); +/* Turn it off */ +regmap_update_bits (sled->map, sled->offset, sled->mask,0 ); +return 0 ; +} - map =syscon_node_to_regmap (np); -if (IS_ERR (map)) { -pr_err ("error getting regmap for syscon LEDs\n" ); -continue ; - } +static const struct of_device_id of_syscon_leds_match[] = { + { .compatible ="register-bit-led" , }, + {}, +}; -/* -* If the map is there, the device should be there, we allocate -* memory on the syscon device's behalf here. -*/ - pdev =of_find_device_by_node (np); -if (!pdev) -return -ENODEV ; - ret =syscon_leds_spawn (np, &pdev->dev, map); -if (ret) -dev_err (&pdev->dev,"could not spawn syscon LEDs\n" ); - } +MODULE_DEVICE_TABLE (of, of_syscon_leds_match); -return 0 ; -} -device_initcall (syscon_leds_init); +static struct platform_driver syscon_led_driver = { + .probe = syscon_led_probe, + .remove = syscon_led_remove, + .driver = { + .name ="leds-syscon" , + .of_match_table = of_syscon_leds_match, + }, +}; +module_platform_driver (syscon_led_driver);
Signature · 1 line
1.9.3
PATCH 3/5 leds: syscon: instantiate from platform device
Quoted 9 lines · Linus Walleij
Currently syscon LEDs will traverse the device tree looking for syscon devices and if found, traverse any subnodes of these to identify matching children and from there instantiate LED class devices.
This is not a good use of the Linux device model. Instead we have converted the device trees to add the "simple-mfd" property to the MFD nexi spawning syscon LEDs so that these will appear as platform devices in the system and we can use the proper device probing mechanism.
Quoted 8 lines
Cc Arnd Bergmann <[email protected]>Cc Lee Jones <[email protected]>Cc Pawel Moll <[email protected]>Cc Mark Rutland <[email protected]>Signed-off-by Linus Walleij <[email protected]>---
Bryan: if you're OK with it, please ACK this patch so we can funnel it through ARM SoC with the rest of the patches in this series.
Bryan, ping.
Yours,
Linus Walleij
PATCH 3/5 leds: syscon: instantiate from platform device
In reply to Linus WalleijOn Tue, Mar 3, 2015 at 10:32 AM, Linus Walleij <[email protected]> wrote:
[..]
Quoted 5 lines
drivers/leds/leds-syscon.c +1
-3+static int syscon_led_remove (struct platform_device *pdev) { -struct device_node *np; - -for_each_of_allnodes (np) {
drivers/leds/leds-syscon.c static void syscon_led_set(struct led_classdev *led_cdev, · line 148
Quoted 10 lines
drivers/leds/leds-syscon.c +4
-5-struct platform_device *pdev; -struct regmap *map; -int ret; +struct syscon_led *sled =platform_get_drvdata (pdev); -if (!of_device_is_compatible (np,"syscon" )) -continue ; +led_classdev_unregister (&sled->cdev); +/* Turn it off */ +regmap_update_bits (sled->map, sled->offset, sled->mask,0 );
led_classdev_unregister() should have called your brightness_set op already to disable the LED - see led-class.c line 279. So you shouldn't need this.
I like the rest and have been missing "simple-mfd" in other use cases...
So part of the extra disable:
Regards,
Bjorn
PATCH 4/5 arm64: juno: Add APB registers and LEDs using syscon
In reply to Linus WalleijThis defines the Juno "APB system registers" as a syscon device, and all the LEDs controlled by the APB system registers right below it using the syscon LEDs driver on top of syscon. Define LED0 for heartbeat, LED1 for MMC0 activity and the following four LEDs indicating CPU activity using the Linux-specific DT bindings for triggers.
This is the pattern and same drivers as used on the legacy platform device trees for the ARM Integrators and the RealView PB1176.
---
ChangeLog v1->v2:
- Use "simple-mfd" so that the syscon LEDs get spawned from the syscon as sub-platform devices.
--- arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 68 +++++++++++++++++++++++++++ 1 file changed, 68 insertions(+)
arch/arm64/boot/dts/arm/juno-motherboard.dtsi +68 -0
@@ -66,6 +66,74 @@ #size-cells = <1>; ranges = <0 3 0 0x200000>; + apbregs at 010000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "vexpress:0"; + linux,default-trigger = "heartbeat"; + default-state = "on"; + }; + led at 08.1 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x02>; + label = "vexpress:1"; + linux,default-trigger = "mmc0"; + default-state = "off"; + }; + led at 08.2 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x04>; + label = "vexpress:2"; + linux,default-trigger = "cpu0"; + default-state = "off"; + }; + led at 08.3 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x08>; + label = "vexpress:3"; + linux,default-trigger = "cpu1"; + default-state = "off"; + }; + led at 08.4 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x10>; + label = "vexpress:4"; + linux,default-trigger = "cpu2"; + default-state = "off"; + }; + led at 08.5 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x20>; + label = "vexpress:5"; + linux,default-trigger = "cpu3"; + default-state = "off"; + }; + led at 08.6 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x40>; + label = "vexpress:6"; + default-state = "off"; + }; + led at 08.7 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x80>; + label = "vexpress:7"; + default-state = "off"; + }; + }; + mmci at 050000 { compatible = "arm,pl180", "arm,primecell"; reg = <0x050000 0x1000>;
Signature · 1 line
1.9.3
Liviu Dudau
maintainerPATCH 4/5 arm64: juno: Add APB registers and LEDs using syscon
Quoted 11 lines · Linus Walleij
This defines the Juno "APB system registers" as a syscon device, and all the LEDs controlled by the APB system registers right below it using the syscon LEDs driver on top of syscon. Define LED0 for heartbeat, LED1 for MMC0 activity and the following four LEDs indicating CPU activity using the Linux-specific DT bindings for triggers.
This is the pattern and same drivers as used on the legacy platform device trees for the ARM Integrators and the RealView PB1176.
Quoted 6 lines
Cc Arnd Bergmann <[email protected]>Cc Liviu Dudau <[email protected]>Cc Mark Rutland <[email protected]>Cc Robin Murphy <[email protected]>Cc Pawel Moll <[email protected]>Signed-off-by Linus Walleij <[email protected]>
KITT test shell script working beautifully. :)
Best regards,
Liviu
Quoted 91 lines
---
ChangeLogv1->v2:
- Use "simple-mfd" so that the syscon LEDs get spawned from the syscon as sub-platform devices.--- arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 68 +++++++++++++++++++++++++++ 1 file changed, 68 insertions(+)arch/arm64/boot/dts/arm/juno-motherboard.dtsi +68
-0@@ -66,6 +66,74 @@ #size-cells = <1>; ranges = <0 3 0 0x200000>; + apbregs at 010000 { + compatible = "syscon", "simple-mfd"; + reg = <0x010000 0x1000>; + + led at 08.0 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x01>; + label = "vexpress:0"; + linux,default-trigger = "heartbeat"; + default-state = "on"; + }; + led at 08.1 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x02>; + label = "vexpress:1"; + linux,default-trigger = "mmc0"; + default-state = "off"; + }; + led at 08.2 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x04>; + label = "vexpress:2"; + linux,default-trigger = "cpu0"; + default-state = "off"; + }; + led at 08.3 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x08>; + label = "vexpress:3"; + linux,default-trigger = "cpu1"; + default-state = "off"; + }; + led at 08.4 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x10>; + label = "vexpress:4"; + linux,default-trigger = "cpu2"; + default-state = "off"; + }; + led at 08.5 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x20>; + label = "vexpress:5"; + linux,default-trigger = "cpu3"; + default-state = "off"; + }; + led at 08.6 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x40>; + label = "vexpress:6"; + default-state = "off"; + }; + led at 08.7 { + compatible = "register-bit-led"; + offset = <0x08>; + mask = <0x80>; + label = "vexpress:7"; + default-state = "off"; + }; + }; + mmci at 050000 { compatible = "arm,pl180", "arm,primecell"; reg = <0x050000 0x1000>;Signature · 1 line
1.9.3
Signature · 8 lines
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?PATCH 5/5 arm64: add LEDs and some trigger support to defconfig
In reply to Linus WalleijSince many boards for ARM, experimental or server alike, will feature LEDs, let's include LED class and trigger support for heartbeat and CPU in the defconfig. Many systems (such as the ARM Juno) will use a system controller "syscon" to access the LED registers, so include support for this as well.
--- arch/arm64/configs/defconfig | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm64/configs/defconfig +6 -0
@@ -122,6 +122,12 @@ CONFIG_MMC_ARMMMCI=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SPI=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_SYSCON=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_CPU=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_EFI=y CONFIG_RTC_DRV_XGENE=y
Signature · 1 line
1.9.3