* [PATCH v3/resend 0/4] drivers: bus: Add Simple Power-Managed Bus @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Hi all, The Renesas Bus State Controller (BSC) provides an external bus for connecting multiple external devices to an SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB. On the kzm9g and ape6evm development boards, an smsc9220 Ethernet controller is connnected to the BSC of an SH-Mobile AG5 (sh73a0) resp. R-Mobile APE6 (r8a73a4) SoC. The BSC is a fairly simple memory-mapped bus, hence a "simple-bus" compatibility seems suitable. However, the BSC is special in two ways: 1. It is part of a PM domain (A4S on sh73a0), 2. It has a gateable functional clock (ZB). Before a device connected to the BSC can be accessed, the PM domain containing the BSC must be powered on, and the functional clock driving the BSC must be enabled. Both special properties can be described in DT in a standardized way ("power-domains = <&pd_a4s>" and "clocks = <&zb_clk>", cfr. the example in the DT binding documentation). Externally connected devices are described as children of the BSC node. Unfortunately this doesn't mean everything will work out-of-the-box. There are two problems: 1. Without a device driver bound to the bus device, this device is not attached to the PM domain. And although a child device is present and active, the PM domain may be powered down, as it's considered unused by the PM domain core. 2. Without a device driver calling pm_runtime_enable(), its functional clock is not enabled. Once runtime PM is enabled, the R-Mobile PM domain platform driver manages the functional clock using runtime PM. As none of the above is really bus hardware-specific (PM domains and functional clocks in clock domains are handled from genpd and platform code), this series adds a Simple Power-Managed Bus driver for transparent busses, which just enables runtime PM for the bus device. Due to the child-parent relationship of devices connected to the bus, as long as the device drivers for the child devices are runtime PM enabled, the bus's PM domain will be powered, and the bus's clock will be enabled automatically when needed, for both runtime PM and s2ram. Currently this driver supports the Renesas Bus State Controller only, but support for other SoCs and other bus controllers can easily be added later by adding more compatible values. Note that this driver cannot just bind against "simple-bus", as that may prevent a device-specific driver from taking precedence. This was tested on sh73a0/kzm9g-multiplatform (by me), and on r8a73a4/ape6evm-multiplatform (by Ulrich Hecht). Without this, Ethernet doesn't work, as the ZB clock is disabled by clk_disable_unused(). As drivers/bus doesn't have a maintainer, and this driver is needed to move two shmobile platforms away from legacy to multiplatform, I think this can go in through Simon's shmobile tree. Changes compared to v2: - Document required properties inherited from "simple-bus", - Document required "reg" property for "renesas,bsc", - Move "ranges" before "reg" in the example, - Add Tested-by, - Split-off sh73a0/kzm9g and r8a73a4/ape6evm DTS updates. Changes compared to v1 (more detailed change logs in the individual patches): - Added sorting of drivers/bus Kconfig and Makefile entries, - Added DT binding documentation, - Rename from "Renesas Bus State Controller Driver" (renesas-bsc) to "Simple Power-Managed Bus Driver" (simple-pm-bus), - Postponed adding power-domains properties to the dtsi, - Added updates for r8a73a4/ape6evm. Thanks for your review comments! Geert Uytterhoeven (4): drivers: bus: Sort Kconfig entries alphabetically drivers: bus: Sort Makefile entries alphabetically drivers: bus: Add Simple Power-Managed Bus DT Bindings drivers: bus: Add Simple Power-Managed Bus Driver .../devicetree/bindings/bus/simple-pm-bus.txt | 52 +++++++++++++++++++++ drivers/bus/Kconfig | 53 ++++++++++++++-------- drivers/bus/Makefile | 15 +++--- drivers/bus/simple-pm-bus.c | 51 +++++++++++++++++++++ 4 files changed, 144 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt create mode 100644 drivers/bus/simple-pm-bus.c -- 1.9.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 0/4] drivers: bus: Add Simple Power-Managed Bus @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Hi all, The Renesas Bus State Controller (BSC) provides an external bus for connecting multiple external devices to an SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB. On the kzm9g and ape6evm development boards, an smsc9220 Ethernet controller is connnected to the BSC of an SH-Mobile AG5 (sh73a0) resp. R-Mobile APE6 (r8a73a4) SoC. The BSC is a fairly simple memory-mapped bus, hence a "simple-bus" compatibility seems suitable. However, the BSC is special in two ways: 1. It is part of a PM domain (A4S on sh73a0), 2. It has a gateable functional clock (ZB). Before a device connected to the BSC can be accessed, the PM domain containing the BSC must be powered on, and the functional clock driving the BSC must be enabled. Both special properties can be described in DT in a standardized way ("power-domains = <&pd_a4s>" and "clocks = <&zb_clk>", cfr. the example in the DT binding documentation). Externally connected devices are described as children of the BSC node. Unfortunately this doesn't mean everything will work out-of-the-box. There are two problems: 1. Without a device driver bound to the bus device, this device is not attached to the PM domain. And although a child device is present and active, the PM domain may be powered down, as it's considered unused by the PM domain core. 2. Without a device driver calling pm_runtime_enable(), its functional clock is not enabled. Once runtime PM is enabled, the R-Mobile PM domain platform driver manages the functional clock using runtime PM. As none of the above is really bus hardware-specific (PM domains and functional clocks in clock domains are handled from genpd and platform code), this series adds a Simple Power-Managed Bus driver for transparent busses, which just enables runtime PM for the bus device. Due to the child-parent relationship of devices connected to the bus, as long as the device drivers for the child devices are runtime PM enabled, the bus's PM domain will be powered, and the bus's clock will be enabled automatically when needed, for both runtime PM and s2ram. Currently this driver supports the Renesas Bus State Controller only, but support for other SoCs and other bus controllers can easily be added later by adding more compatible values. Note that this driver cannot just bind against "simple-bus", as that may prevent a device-specific driver from taking precedence. This was tested on sh73a0/kzm9g-multiplatform (by me), and on r8a73a4/ape6evm-multiplatform (by Ulrich Hecht). Without this, Ethernet doesn't work, as the ZB clock is disabled by clk_disable_unused(). As drivers/bus doesn't have a maintainer, and this driver is needed to move two shmobile platforms away from legacy to multiplatform, I think this can go in through Simon's shmobile tree. Changes compared to v2: - Document required properties inherited from "simple-bus", - Document required "reg" property for "renesas,bsc", - Move "ranges" before "reg" in the example, - Add Tested-by, - Split-off sh73a0/kzm9g and r8a73a4/ape6evm DTS updates. Changes compared to v1 (more detailed change logs in the individual patches): - Added sorting of drivers/bus Kconfig and Makefile entries, - Added DT binding documentation, - Rename from "Renesas Bus State Controller Driver" (renesas-bsc) to "Simple Power-Managed Bus Driver" (simple-pm-bus), - Postponed adding power-domains properties to the dtsi, - Added updates for r8a73a4/ape6evm. Thanks for your review comments! Geert Uytterhoeven (4): drivers: bus: Sort Kconfig entries alphabetically drivers: bus: Sort Makefile entries alphabetically drivers: bus: Add Simple Power-Managed Bus DT Bindings drivers: bus: Add Simple Power-Managed Bus Driver .../devicetree/bindings/bus/simple-pm-bus.txt | 52 +++++++++++++++++++++ drivers/bus/Kconfig | 53 ++++++++++++++-------- drivers/bus/Makefile | 15 +++--- drivers/bus/simple-pm-bus.c | 51 +++++++++++++++++++++ 4 files changed, 144 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt create mode 100644 drivers/bus/simple-pm-bus.c -- 1.9.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 0/4] drivers: bus: Add Simple Power-Managed Bus @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki Cc: Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, linux-sh, linux-pm, linux-arm-kernel, linux-kernel, Geert Uytterhoeven Hi all, The Renesas Bus State Controller (BSC) provides an external bus for connecting multiple external devices to an SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB. On the kzm9g and ape6evm development boards, an smsc9220 Ethernet controller is connnected to the BSC of an SH-Mobile AG5 (sh73a0) resp. R-Mobile APE6 (r8a73a4) SoC. The BSC is a fairly simple memory-mapped bus, hence a "simple-bus" compatibility seems suitable. However, the BSC is special in two ways: 1. It is part of a PM domain (A4S on sh73a0), 2. It has a gateable functional clock (ZB). Before a device connected to the BSC can be accessed, the PM domain containing the BSC must be powered on, and the functional clock driving the BSC must be enabled. Both special properties can be described in DT in a standardized way ("power-domains = <&pd_a4s>" and "clocks = <&zb_clk>", cfr. the example in the DT binding documentation). Externally connected devices are described as children of the BSC node. Unfortunately this doesn't mean everything will work out-of-the-box. There are two problems: 1. Without a device driver bound to the bus device, this device is not attached to the PM domain. And although a child device is present and active, the PM domain may be powered down, as it's considered unused by the PM domain core. 2. Without a device driver calling pm_runtime_enable(), its functional clock is not enabled. Once runtime PM is enabled, the R-Mobile PM domain platform driver manages the functional clock using runtime PM. As none of the above is really bus hardware-specific (PM domains and functional clocks in clock domains are handled from genpd and platform code), this series adds a Simple Power-Managed Bus driver for transparent busses, which just enables runtime PM for the bus device. Due to the child-parent relationship of devices connected to the bus, as long as the device drivers for the child devices are runtime PM enabled, the bus's PM domain will be powered, and the bus's clock will be enabled automatically when needed, for both runtime PM and s2ram. Currently this driver supports the Renesas Bus State Controller only, but support for other SoCs and other bus controllers can easily be added later by adding more compatible values. Note that this driver cannot just bind against "simple-bus", as that may prevent a device-specific driver from taking precedence. This was tested on sh73a0/kzm9g-multiplatform (by me), and on r8a73a4/ape6evm-multiplatform (by Ulrich Hecht). Without this, Ethernet doesn't work, as the ZB clock is disabled by clk_disable_unused(). As drivers/bus doesn't have a maintainer, and this driver is needed to move two shmobile platforms away from legacy to multiplatform, I think this can go in through Simon's shmobile tree. Changes compared to v2: - Document required properties inherited from "simple-bus", - Document required "reg" property for "renesas,bsc", - Move "ranges" before "reg" in the example, - Add Tested-by, - Split-off sh73a0/kzm9g and r8a73a4/ape6evm DTS updates. Changes compared to v1 (more detailed change logs in the individual patches): - Added sorting of drivers/bus Kconfig and Makefile entries, - Added DT binding documentation, - Rename from "Renesas Bus State Controller Driver" (renesas-bsc) to "Simple Power-Managed Bus Driver" (simple-pm-bus), - Postponed adding power-domains properties to the dtsi, - Added updates for r8a73a4/ape6evm. Thanks for your review comments! Geert Uytterhoeven (4): drivers: bus: Sort Kconfig entries alphabetically drivers: bus: Sort Makefile entries alphabetically drivers: bus: Add Simple Power-Managed Bus DT Bindings drivers: bus: Add Simple Power-Managed Bus Driver .../devicetree/bindings/bus/simple-pm-bus.txt | 52 +++++++++++++++++++++ drivers/bus/Kconfig | 53 ++++++++++++++-------- drivers/bus/Makefile | 15 +++--- drivers/bus/simple-pm-bus.c | 51 +++++++++++++++++++++ 4 files changed, 144 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt create mode 100644 drivers/bus/simple-pm-bus.c -- 1.9.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 1/4] drivers: bus: Sort Kconfig entries alphabetically 2015-01-22 9:34 ` Geert Uytterhoeven (?) @ 2015-01-22 9:34 ` Geert Uytterhoeven -1 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - New. --- drivers/bus/Kconfig | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index b99729e368608bda..626960819e6df16c 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -4,6 +4,21 @@ menu "Bus devices" +config ARM_CCI + bool "ARM CCI driver support" + depends on ARM && OF && CPU_V7 + help + Driver supporting the CCI cache coherent interconnect for ARM + platforms. + +config ARM_CCN + bool "ARM CCN driver support" + depends on ARM || ARM64 + depends on PERF_EVENTS + help + PMU (perf) driver supporting the ARM CCN (Cache Coherent Network) + interconnect. + config BRCMSTB_GISB_ARB bool "Broadcom STB GISB bus arbiter" depends on ARM || MIPS @@ -27,15 +42,6 @@ config MVEBU_MBUS Driver needed for the MBus configuration on Marvell EBU SoCs (Kirkwood, Dove, Orion5x, MV78XX0 and Armada 370/XP). -config OMAP_OCP2SCP - tristate "OMAP OCP2SCP DRIVER" - depends on ARCH_OMAP2PLUS - help - Driver to enable ocp2scp module which transforms ocp interface - protocol to scp protocol. In OMAP4, USB PHY is connected via - OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via - OCP2SCP. - config OMAP_INTERCONNECT tristate "OMAP INTERCONNECT DRIVER" depends on ARCH_OMAP2PLUS @@ -43,20 +49,14 @@ config OMAP_INTERCONNECT help Driver to enable OMAP interconnect error handling driver. -config ARM_CCI - bool "ARM CCI driver support" - depends on ARM && OF && CPU_V7 - help - Driver supporting the CCI cache coherent interconnect for ARM - platforms. - -config ARM_CCN - bool "ARM CCN driver support" - depends on ARM || ARM64 - depends on PERF_EVENTS +config OMAP_OCP2SCP + tristate "OMAP OCP2SCP DRIVER" + depends on ARCH_OMAP2PLUS help - PMU (perf) driver supporting the ARM CCN (Cache Coherent Network) - interconnect. + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. config VEXPRESS_CONFIG bool "Versatile Express configuration bus" -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 1/4] drivers: bus: Sort Kconfig entries alphabetically @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - New. --- drivers/bus/Kconfig | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index b99729e368608bda..626960819e6df16c 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -4,6 +4,21 @@ menu "Bus devices" +config ARM_CCI + bool "ARM CCI driver support" + depends on ARM && OF && CPU_V7 + help + Driver supporting the CCI cache coherent interconnect for ARM + platforms. + +config ARM_CCN + bool "ARM CCN driver support" + depends on ARM || ARM64 + depends on PERF_EVENTS + help + PMU (perf) driver supporting the ARM CCN (Cache Coherent Network) + interconnect. + config BRCMSTB_GISB_ARB bool "Broadcom STB GISB bus arbiter" depends on ARM || MIPS @@ -27,15 +42,6 @@ config MVEBU_MBUS Driver needed for the MBus configuration on Marvell EBU SoCs (Kirkwood, Dove, Orion5x, MV78XX0 and Armada 370/XP). -config OMAP_OCP2SCP - tristate "OMAP OCP2SCP DRIVER" - depends on ARCH_OMAP2PLUS - help - Driver to enable ocp2scp module which transforms ocp interface - protocol to scp protocol. In OMAP4, USB PHY is connected via - OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via - OCP2SCP. - config OMAP_INTERCONNECT tristate "OMAP INTERCONNECT DRIVER" depends on ARCH_OMAP2PLUS @@ -43,20 +49,14 @@ config OMAP_INTERCONNECT help Driver to enable OMAP interconnect error handling driver. -config ARM_CCI - bool "ARM CCI driver support" - depends on ARM && OF && CPU_V7 - help - Driver supporting the CCI cache coherent interconnect for ARM - platforms. - -config ARM_CCN - bool "ARM CCN driver support" - depends on ARM || ARM64 - depends on PERF_EVENTS +config OMAP_OCP2SCP + tristate "OMAP OCP2SCP DRIVER" + depends on ARCH_OMAP2PLUS help - PMU (perf) driver supporting the ARM CCN (Cache Coherent Network) - interconnect. + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. config VEXPRESS_CONFIG bool "Versatile Express configuration bus" -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 1/4] drivers: bus: Sort Kconfig entries alphabetically @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki Cc: Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, linux-sh, linux-pm, linux-arm-kernel, linux-kernel, Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - New. --- drivers/bus/Kconfig | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index b99729e368608bda..626960819e6df16c 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -4,6 +4,21 @@ menu "Bus devices" +config ARM_CCI + bool "ARM CCI driver support" + depends on ARM && OF && CPU_V7 + help + Driver supporting the CCI cache coherent interconnect for ARM + platforms. + +config ARM_CCN + bool "ARM CCN driver support" + depends on ARM || ARM64 + depends on PERF_EVENTS + help + PMU (perf) driver supporting the ARM CCN (Cache Coherent Network) + interconnect. + config BRCMSTB_GISB_ARB bool "Broadcom STB GISB bus arbiter" depends on ARM || MIPS @@ -27,15 +42,6 @@ config MVEBU_MBUS Driver needed for the MBus configuration on Marvell EBU SoCs (Kirkwood, Dove, Orion5x, MV78XX0 and Armada 370/XP). -config OMAP_OCP2SCP - tristate "OMAP OCP2SCP DRIVER" - depends on ARCH_OMAP2PLUS - help - Driver to enable ocp2scp module which transforms ocp interface - protocol to scp protocol. In OMAP4, USB PHY is connected via - OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via - OCP2SCP. - config OMAP_INTERCONNECT tristate "OMAP INTERCONNECT DRIVER" depends on ARCH_OMAP2PLUS @@ -43,20 +49,14 @@ config OMAP_INTERCONNECT help Driver to enable OMAP interconnect error handling driver. -config ARM_CCI - bool "ARM CCI driver support" - depends on ARM && OF && CPU_V7 - help - Driver supporting the CCI cache coherent interconnect for ARM - platforms. - -config ARM_CCN - bool "ARM CCN driver support" - depends on ARM || ARM64 - depends on PERF_EVENTS +config OMAP_OCP2SCP + tristate "OMAP OCP2SCP DRIVER" + depends on ARCH_OMAP2PLUS help - PMU (perf) driver supporting the ARM CCN (Cache Coherent Network) - interconnect. + Driver to enable ocp2scp module which transforms ocp interface + protocol to scp protocol. In OMAP4, USB PHY is connected via + OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via + OCP2SCP. config VEXPRESS_CONFIG bool "Versatile Express configuration bus" -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 2/4] drivers: bus: Sort Makefile entries alphabetically 2015-01-22 9:34 ` Geert Uytterhoeven (?) @ 2015-01-22 9:34 ` Geert Uytterhoeven -1 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - New. --- drivers/bus/Makefile | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 2973c18cbcc27816..3cfaf2c7f25ac4f0 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -2,16 +2,16 @@ # Makefile for the bus drivers. # +# Interconnect bus drivers for ARM platforms +obj-$(CONFIG_ARM_CCI) += arm-cci.o +obj-$(CONFIG_ARM_CCN) += arm-ccn.o + obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o -obj-$(CONFIG_IMX_WEIM) += imx-weim.o -obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o -obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_IMX_WEIM) += imx-weim.o +obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o # Interconnect bus driver for OMAP SoCs. obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o -# Interconnect bus drivers for ARM platforms -obj-$(CONFIG_ARM_CCI) += arm-cci.o -obj-$(CONFIG_ARM_CCN) += arm-ccn.o - +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 2/4] drivers: bus: Sort Makefile entries alphabetically @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - New. --- drivers/bus/Makefile | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 2973c18cbcc27816..3cfaf2c7f25ac4f0 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -2,16 +2,16 @@ # Makefile for the bus drivers. # +# Interconnect bus drivers for ARM platforms +obj-$(CONFIG_ARM_CCI) += arm-cci.o +obj-$(CONFIG_ARM_CCN) += arm-ccn.o + obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o -obj-$(CONFIG_IMX_WEIM) += imx-weim.o -obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o -obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_IMX_WEIM) += imx-weim.o +obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o # Interconnect bus driver for OMAP SoCs. obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o -# Interconnect bus drivers for ARM platforms -obj-$(CONFIG_ARM_CCI) += arm-cci.o -obj-$(CONFIG_ARM_CCN) += arm-ccn.o - +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 2/4] drivers: bus: Sort Makefile entries alphabetically @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki Cc: Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, linux-sh, linux-pm, linux-arm-kernel, linux-kernel, Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - New. --- drivers/bus/Makefile | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 2973c18cbcc27816..3cfaf2c7f25ac4f0 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -2,16 +2,16 @@ # Makefile for the bus drivers. # +# Interconnect bus drivers for ARM platforms +obj-$(CONFIG_ARM_CCI) += arm-cci.o +obj-$(CONFIG_ARM_CCN) += arm-ccn.o + obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o -obj-$(CONFIG_IMX_WEIM) += imx-weim.o -obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o -obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_IMX_WEIM) += imx-weim.o +obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o # Interconnect bus driver for OMAP SoCs. obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o -# Interconnect bus drivers for ARM platforms -obj-$(CONFIG_ARM_CCI) += arm-cci.o -obj-$(CONFIG_ARM_CCN) += arm-ccn.o - +obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings 2015-01-22 9:34 ` Geert Uytterhoeven (?) @ 2015-01-22 9:34 ` Geert Uytterhoeven -1 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, - Document required properties inherited from "simple-bus", - Document required "reg" property for "renesas,bsc", - Move "ranges" before "reg" in the example, v2: - New. --- .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt new file mode 100644 index 0000000000000000..d03abf7fd8e3997a --- /dev/null +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt @@ -0,0 +1,52 @@ +Simple Power-Managed Bus +============ + +A Simple Power-Managed Bus is a transparent bus that doesn't need a real +driver, as it's typically initialized by the boot loader. + +However, its bus controller is part of a PM domain, or under the control of a +functional clock. Hence, the bus controller's PM domain and/or clock must be +enabled for child devices connected to the bus (either on-SoC or externally) +to function. + + +Generic compatible values and properties +---------------------------------------- + +Required properties: + - compatible: Must be at least one of the vendor-specific compatible values + from a vendor-specific section below, and "simple-bus" as a + fallback. + - #address-cells, #size-cells, ranges: Must describe the mapping between + parent address and child address spaces. + +Optional platform-specific properties for clock or PM domain control (at least +one of them is required): + - clocks: Must contain a reference to the functional clock(s), + - power-domains: Must contain a reference to the PM domain. + + +Vendor-specific compatible values and properties +------------------------------------------------ + +Renesas Bus State Controller (BSC): + - compatible: Must be an SoC-specific value, and "renesas,bsc" as a fallback. + SoC-specific values can be: + "renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4) + "renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0) + - reg: Must contain the base address and length to access the bus controller. + - interrupts: Must contain a reference to the BSC interrupt, if available. + + +Example: + + bsc: bus@fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x20000000>; + reg = <0xfec10000 0x400>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zb_clk>; + power-domains = <&pd_a4s>; + }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, - Document required properties inherited from "simple-bus", - Document required "reg" property for "renesas,bsc", - Move "ranges" before "reg" in the example, v2: - New. --- .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt new file mode 100644 index 0000000000000000..d03abf7fd8e3997a --- /dev/null +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt @@ -0,0 +1,52 @@ +Simple Power-Managed Bus +======================== + +A Simple Power-Managed Bus is a transparent bus that doesn't need a real +driver, as it's typically initialized by the boot loader. + +However, its bus controller is part of a PM domain, or under the control of a +functional clock. Hence, the bus controller's PM domain and/or clock must be +enabled for child devices connected to the bus (either on-SoC or externally) +to function. + + +Generic compatible values and properties +---------------------------------------- + +Required properties: + - compatible: Must be at least one of the vendor-specific compatible values + from a vendor-specific section below, and "simple-bus" as a + fallback. + - #address-cells, #size-cells, ranges: Must describe the mapping between + parent address and child address spaces. + +Optional platform-specific properties for clock or PM domain control (at least +one of them is required): + - clocks: Must contain a reference to the functional clock(s), + - power-domains: Must contain a reference to the PM domain. + + +Vendor-specific compatible values and properties +------------------------------------------------ + +Renesas Bus State Controller (BSC): + - compatible: Must be an SoC-specific value, and "renesas,bsc" as a fallback. + SoC-specific values can be: + "renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4) + "renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0) + - reg: Must contain the base address and length to access the bus controller. + - interrupts: Must contain a reference to the BSC interrupt, if available. + + +Example: + + bsc: bus at fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x20000000>; + reg = <0xfec10000 0x400>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zb_clk>; + power-domains = <&pd_a4s>; + }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki Cc: Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, linux-sh, linux-pm, linux-arm-kernel, linux-kernel, Geert Uytterhoeven Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, - Document required properties inherited from "simple-bus", - Document required "reg" property for "renesas,bsc", - Move "ranges" before "reg" in the example, v2: - New. --- .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt new file mode 100644 index 0000000000000000..d03abf7fd8e3997a --- /dev/null +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt @@ -0,0 +1,52 @@ +Simple Power-Managed Bus +======================== + +A Simple Power-Managed Bus is a transparent bus that doesn't need a real +driver, as it's typically initialized by the boot loader. + +However, its bus controller is part of a PM domain, or under the control of a +functional clock. Hence, the bus controller's PM domain and/or clock must be +enabled for child devices connected to the bus (either on-SoC or externally) +to function. + + +Generic compatible values and properties +---------------------------------------- + +Required properties: + - compatible: Must be at least one of the vendor-specific compatible values + from a vendor-specific section below, and "simple-bus" as a + fallback. + - #address-cells, #size-cells, ranges: Must describe the mapping between + parent address and child address spaces. + +Optional platform-specific properties for clock or PM domain control (at least +one of them is required): + - clocks: Must contain a reference to the functional clock(s), + - power-domains: Must contain a reference to the PM domain. + + +Vendor-specific compatible values and properties +------------------------------------------------ + +Renesas Bus State Controller (BSC): + - compatible: Must be an SoC-specific value, and "renesas,bsc" as a fallback. + SoC-specific values can be: + "renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4) + "renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0) + - reg: Must contain the base address and length to access the bus controller. + - interrupts: Must contain a reference to the BSC interrupt, if available. + + +Example: + + bsc: bus@fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x20000000>; + reg = <0xfec10000 0x400>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zb_clk>; + power-domains = <&pd_a4s>; + }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings 2015-01-22 9:34 ` Geert Uytterhoeven (?) @ 2015-01-22 22:42 ` Kevin Hilman -1 siblings, 0 replies; 34+ messages in thread From: Kevin Hilman @ 2015-01-22 22:42 UTC (permalink / raw) To: linux-arm-kernel Geert Uytterhoeven <geert+renesas@glider.be> writes: > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> > --- > v3: > - Add Tested-by, > - Document required properties inherited from "simple-bus", > - Document required "reg" property for "renesas,bsc", > - Move "ranges" before "reg" in the example, > > v2: > - New. > --- > .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > new file mode 100644 > index 0000000000000000..d03abf7fd8e3997a > --- /dev/null > +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > @@ -0,0 +1,52 @@ > +Simple Power-Managed Bus > +============ > + > +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > +driver, as it's typically initialized by the boot loader. > + > +However, its bus controller is part of a PM domain, or under the control of a > +functional clock. Hence, the bus controller's PM domain and/or clock must be > +enabled for child devices connected to the bus (either on-SoC or externally) > +to function. > + > + > +Generic compatible values and properties > +---------------------------------------- > + > +Required properties: > + - compatible: Must be at least one of the vendor-specific compatible values > + from a vendor-specific section below, and "simple-bus" as a > + fallback. What happened to the idea of using something like "simple-pm-bus"? There's nothing vendor-specific in the driver at all, so the vendor-specific binding seem like clutter to me and will result in continuing to add vendor-specific compatibles without any vendor-specific code. Kevin ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-22 22:42 ` Kevin Hilman 0 siblings, 0 replies; 34+ messages in thread From: Kevin Hilman @ 2015-01-22 22:42 UTC (permalink / raw) To: linux-arm-kernel Geert Uytterhoeven <geert+renesas@glider.be> writes: > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> > --- > v3: > - Add Tested-by, > - Document required properties inherited from "simple-bus", > - Document required "reg" property for "renesas,bsc", > - Move "ranges" before "reg" in the example, > > v2: > - New. > --- > .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > new file mode 100644 > index 0000000000000000..d03abf7fd8e3997a > --- /dev/null > +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > @@ -0,0 +1,52 @@ > +Simple Power-Managed Bus > +======================== > + > +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > +driver, as it's typically initialized by the boot loader. > + > +However, its bus controller is part of a PM domain, or under the control of a > +functional clock. Hence, the bus controller's PM domain and/or clock must be > +enabled for child devices connected to the bus (either on-SoC or externally) > +to function. > + > + > +Generic compatible values and properties > +---------------------------------------- > + > +Required properties: > + - compatible: Must be at least one of the vendor-specific compatible values > + from a vendor-specific section below, and "simple-bus" as a > + fallback. What happened to the idea of using something like "simple-pm-bus"? There's nothing vendor-specific in the driver at all, so the vendor-specific binding seem like clutter to me and will result in continuing to add vendor-specific compatibles without any vendor-specific code. Kevin ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-22 22:42 ` Kevin Hilman 0 siblings, 0 replies; 34+ messages in thread From: Kevin Hilman @ 2015-01-22 22:42 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, linux-sh, linux-pm, linux-arm-kernel, linux-kernel Geert Uytterhoeven <geert+renesas@glider.be> writes: > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> > --- > v3: > - Add Tested-by, > - Document required properties inherited from "simple-bus", > - Document required "reg" property for "renesas,bsc", > - Move "ranges" before "reg" in the example, > > v2: > - New. > --- > .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ > 1 file changed, 52 insertions(+) > create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > new file mode 100644 > index 0000000000000000..d03abf7fd8e3997a > --- /dev/null > +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > @@ -0,0 +1,52 @@ > +Simple Power-Managed Bus > +======================== > + > +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > +driver, as it's typically initialized by the boot loader. > + > +However, its bus controller is part of a PM domain, or under the control of a > +functional clock. Hence, the bus controller's PM domain and/or clock must be > +enabled for child devices connected to the bus (either on-SoC or externally) > +to function. > + > + > +Generic compatible values and properties > +---------------------------------------- > + > +Required properties: > + - compatible: Must be at least one of the vendor-specific compatible values > + from a vendor-specific section below, and "simple-bus" as a > + fallback. What happened to the idea of using something like "simple-pm-bus"? There's nothing vendor-specific in the driver at all, so the vendor-specific binding seem like clutter to me and will result in continuing to add vendor-specific compatibles without any vendor-specific code. Kevin ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings 2015-01-22 22:42 ` Kevin Hilman (?) (?) @ 2015-01-23 8:56 ` Geert Uytterhoeven -1 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 8:56 UTC (permalink / raw) To: linux-arm-kernel Hi Kevin, On Thu, Jan 22, 2015 at 11:42 PM, Kevin Hilman <khilman@kernel.org> wrote: > Geert Uytterhoeven <geert+renesas@glider.be> writes: > >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> >> --- >> v3: >> - Add Tested-by, >> - Document required properties inherited from "simple-bus", >> - Document required "reg" property for "renesas,bsc", >> - Move "ranges" before "reg" in the example, >> >> v2: >> - New. >> --- >> .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> new file mode 100644 >> index 0000000000000000..d03abf7fd8e3997a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> @@ -0,0 +1,52 @@ >> +Simple Power-Managed Bus >> +============ >> + >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> +driver, as it's typically initialized by the boot loader. >> + >> +However, its bus controller is part of a PM domain, or under the control of a >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> +enabled for child devices connected to the bus (either on-SoC or externally) >> +to function. >> + >> + >> +Generic compatible values and properties >> +---------------------------------------- >> + >> +Required properties: >> + - compatible: Must be at least one of the vendor-specific compatible values >> + from a vendor-specific section below, and "simple-bus" as a >> + fallback. > > What happened to the idea of using something like "simple-pm-bus"? I think that's a decision to make by the (successor of the) ePAPR committee. At least it would be nice to get some feedback from the DT review team about this. If we go that road, the vendor-specific compatible value should still be documented, else checkpatch will complain when encountering it in a DTS. Then, should it become compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", "simple-bus"; or should "simple-bus" just be added to of_default_bus_match_table[], so we can drop "simple-bus" from the list in the DTS: compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > There's nothing vendor-specific in the driver at all, so the > vendor-specific binding seem like clutter to me and will result in > continuing to add vendor-specific compatibles without any > vendor-specific code. So far not many users or other interested parties chimed in, so that's still to be seen. If/when this happens, we can remove the vendor-specific matching from the driver, and add a quirk, to add a "simple-pm-bus" compatible value where needed, to platform code, right? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 8:56 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 8:56 UTC (permalink / raw) To: linux-arm-kernel Hi Kevin, On Thu, Jan 22, 2015 at 11:42 PM, Kevin Hilman <khilman@kernel.org> wrote: > Geert Uytterhoeven <geert+renesas@glider.be> writes: > >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> >> --- >> v3: >> - Add Tested-by, >> - Document required properties inherited from "simple-bus", >> - Document required "reg" property for "renesas,bsc", >> - Move "ranges" before "reg" in the example, >> >> v2: >> - New. >> --- >> .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> new file mode 100644 >> index 0000000000000000..d03abf7fd8e3997a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> @@ -0,0 +1,52 @@ >> +Simple Power-Managed Bus >> +======================== >> + >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> +driver, as it's typically initialized by the boot loader. >> + >> +However, its bus controller is part of a PM domain, or under the control of a >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> +enabled for child devices connected to the bus (either on-SoC or externally) >> +to function. >> + >> + >> +Generic compatible values and properties >> +---------------------------------------- >> + >> +Required properties: >> + - compatible: Must be at least one of the vendor-specific compatible values >> + from a vendor-specific section below, and "simple-bus" as a >> + fallback. > > What happened to the idea of using something like "simple-pm-bus"? I think that's a decision to make by the (successor of the) ePAPR committee. At least it would be nice to get some feedback from the DT review team about this. If we go that road, the vendor-specific compatible value should still be documented, else checkpatch will complain when encountering it in a DTS. Then, should it become compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", "simple-bus"; or should "simple-bus" just be added to of_default_bus_match_table[], so we can drop "simple-bus" from the list in the DTS: compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > There's nothing vendor-specific in the driver at all, so the > vendor-specific binding seem like clutter to me and will result in > continuing to add vendor-specific compatibles without any > vendor-specific code. So far not many users or other interested parties chimed in, so that's still to be seen. If/when this happens, we can remove the vendor-specific matching from the driver, and add a quirk, to add a "simple-pm-bus" compatible value where needed, to platform code, right? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 8:56 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 8:56 UTC (permalink / raw) To: Kevin Hilman Cc: Geert Uytterhoeven, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree-u79uwXL29TY76Z2rM5mHXA, Linux-sh list, Linux PM list, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA Hi Kevin, On Thu, Jan 22, 2015 at 11:42 PM, Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> writes: > >> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> >> Tested-by: Ulrich Hecht <ulrich.hecht+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> --- >> v3: >> - Add Tested-by, >> - Document required properties inherited from "simple-bus", >> - Document required "reg" property for "renesas,bsc", >> - Move "ranges" before "reg" in the example, >> >> v2: >> - New. >> --- >> .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> new file mode 100644 >> index 0000000000000000..d03abf7fd8e3997a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> @@ -0,0 +1,52 @@ >> +Simple Power-Managed Bus >> +======================== >> + >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> +driver, as it's typically initialized by the boot loader. >> + >> +However, its bus controller is part of a PM domain, or under the control of a >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> +enabled for child devices connected to the bus (either on-SoC or externally) >> +to function. >> + >> + >> +Generic compatible values and properties >> +---------------------------------------- >> + >> +Required properties: >> + - compatible: Must be at least one of the vendor-specific compatible values >> + from a vendor-specific section below, and "simple-bus" as a >> + fallback. > > What happened to the idea of using something like "simple-pm-bus"? I think that's a decision to make by the (successor of the) ePAPR committee. At least it would be nice to get some feedback from the DT review team about this. If we go that road, the vendor-specific compatible value should still be documented, else checkpatch will complain when encountering it in a DTS. Then, should it become compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", "simple-bus"; or should "simple-bus" just be added to of_default_bus_match_table[], so we can drop "simple-bus" from the list in the DTS: compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > There's nothing vendor-specific in the driver at all, so the > vendor-specific binding seem like clutter to me and will result in > continuing to add vendor-specific compatibles without any > vendor-specific code. So far not many users or other interested parties chimed in, so that's still to be seen. If/when this happens, we can remove the vendor-specific matching from the driver, and add a quirk, to add a "simple-pm-bus" compatible value where needed, to platform code, right? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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 [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 8:56 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 8:56 UTC (permalink / raw) To: Kevin Hilman Cc: Geert Uytterhoeven, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel Hi Kevin, On Thu, Jan 22, 2015 at 11:42 PM, Kevin Hilman <khilman@kernel.org> wrote: > Geert Uytterhoeven <geert+renesas@glider.be> writes: > >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> >> --- >> v3: >> - Add Tested-by, >> - Document required properties inherited from "simple-bus", >> - Document required "reg" property for "renesas,bsc", >> - Move "ranges" before "reg" in the example, >> >> v2: >> - New. >> --- >> .../devicetree/bindings/bus/simple-pm-bus.txt | 52 ++++++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> new file mode 100644 >> index 0000000000000000..d03abf7fd8e3997a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> @@ -0,0 +1,52 @@ >> +Simple Power-Managed Bus >> +======================== >> + >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> +driver, as it's typically initialized by the boot loader. >> + >> +However, its bus controller is part of a PM domain, or under the control of a >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> +enabled for child devices connected to the bus (either on-SoC or externally) >> +to function. >> + >> + >> +Generic compatible values and properties >> +---------------------------------------- >> + >> +Required properties: >> + - compatible: Must be at least one of the vendor-specific compatible values >> + from a vendor-specific section below, and "simple-bus" as a >> + fallback. > > What happened to the idea of using something like "simple-pm-bus"? I think that's a decision to make by the (successor of the) ePAPR committee. At least it would be nice to get some feedback from the DT review team about this. If we go that road, the vendor-specific compatible value should still be documented, else checkpatch will complain when encountering it in a DTS. Then, should it become compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", "simple-bus"; or should "simple-bus" just be added to of_default_bus_match_table[], so we can drop "simple-bus" from the list in the DTS: compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > There's nothing vendor-specific in the driver at all, so the > vendor-specific binding seem like clutter to me and will result in > continuing to add vendor-specific compatibles without any > vendor-specific code. So far not many users or other interested parties chimed in, so that's still to be seen. If/when this happens, we can remove the vendor-specific matching from the driver, and add a quirk, to add a "simple-pm-bus" compatible value where needed, to platform code, right? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings 2015-01-23 8:56 ` Geert Uytterhoeven (?) (?) @ 2015-01-23 13:46 ` Arnd Bergmann -1 siblings, 0 replies; 34+ messages in thread From: Arnd Bergmann @ 2015-01-23 13:46 UTC (permalink / raw) To: linux-arm-kernel On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> new file mode 100644 > >> index 0000000000000000..d03abf7fd8e3997a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> @@ -0,0 +1,52 @@ > >> +Simple Power-Managed Bus > >> +============ > >> + > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > >> +driver, as it's typically initialized by the boot loader. > >> + > >> +However, its bus controller is part of a PM domain, or under the control of a > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > >> +enabled for child devices connected to the bus (either on-SoC or externally) > >> +to function. > >> + > >> + > >> +Generic compatible values and properties > >> +---------------------------------------- > >> + > >> +Required properties: > >> + - compatible: Must be at least one of the vendor-specific compatible values > >> + from a vendor-specific section below, and "simple-bus" as a > >> + fallback. > > > > What happened to the idea of using something like "simple-pm-bus"? > > I think that's a decision to make by the (successor of the) ePAPR committee. > At least it would be nice to get some feedback from the DT review team > about this. > > If we go that road, the vendor-specific compatible value should still be > documented, else checkpatch will complain when encountering it in a DTS. > Then, should it become > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > "simple-bus"; > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > can drop "simple-bus" from the list in the DTS: > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; I was thinking of the reverse: drop "simple-bus" bus from the list here, but not add "simple-pm-bus" to of_default_bus_match_table. This will cause child devices to no longer be probed automatically, and you will have to call of_platform_populate() from simple_pm_bus_probe(), after pm_runtime_enable(). This seems like a cleaner model to me, for two reasons: - In the binding, claiming compatibility with "simple-bus" feels wrong to me, because you have a bus that is not as simple as others - The ordering between pm_runtime_enable() and the probing of the child devices is guaranteed, which I think it is not with your current code. Does this make sense, or am I missing an important reason why there has to be a "simple-bus" compatible string here? Arnd ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 13:46 ` Arnd Bergmann 0 siblings, 0 replies; 34+ messages in thread From: Arnd Bergmann @ 2015-01-23 13:46 UTC (permalink / raw) To: linux-arm-kernel On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> new file mode 100644 > >> index 0000000000000000..d03abf7fd8e3997a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> @@ -0,0 +1,52 @@ > >> +Simple Power-Managed Bus > >> +======================== > >> + > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > >> +driver, as it's typically initialized by the boot loader. > >> + > >> +However, its bus controller is part of a PM domain, or under the control of a > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > >> +enabled for child devices connected to the bus (either on-SoC or externally) > >> +to function. > >> + > >> + > >> +Generic compatible values and properties > >> +---------------------------------------- > >> + > >> +Required properties: > >> + - compatible: Must be at least one of the vendor-specific compatible values > >> + from a vendor-specific section below, and "simple-bus" as a > >> + fallback. > > > > What happened to the idea of using something like "simple-pm-bus"? > > I think that's a decision to make by the (successor of the) ePAPR committee. > At least it would be nice to get some feedback from the DT review team > about this. > > If we go that road, the vendor-specific compatible value should still be > documented, else checkpatch will complain when encountering it in a DTS. > Then, should it become > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > "simple-bus"; > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > can drop "simple-bus" from the list in the DTS: > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; I was thinking of the reverse: drop "simple-bus" bus from the list here, but not add "simple-pm-bus" to of_default_bus_match_table. This will cause child devices to no longer be probed automatically, and you will have to call of_platform_populate() from simple_pm_bus_probe(), after pm_runtime_enable(). This seems like a cleaner model to me, for two reasons: - In the binding, claiming compatibility with "simple-bus" feels wrong to me, because you have a bus that is not as simple as others - The ordering between pm_runtime_enable() and the probing of the child devices is guaranteed, which I think it is not with your current code. Does this make sense, or am I missing an important reason why there has to be a "simple-bus" compatible string here? Arnd ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 13:46 ` Arnd Bergmann 0 siblings, 0 replies; 34+ messages in thread From: Arnd Bergmann @ 2015-01-23 13:46 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Kevin Hilman, Geert Uytterhoeven, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> new file mode 100644 > >> index 0000000000000000..d03abf7fd8e3997a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> @@ -0,0 +1,52 @@ > >> +Simple Power-Managed Bus > >> +======================== > >> + > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > >> +driver, as it's typically initialized by the boot loader. > >> + > >> +However, its bus controller is part of a PM domain, or under the control of a > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > >> +enabled for child devices connected to the bus (either on-SoC or externally) > >> +to function. > >> + > >> + > >> +Generic compatible values and properties > >> +---------------------------------------- > >> + > >> +Required properties: > >> + - compatible: Must be at least one of the vendor-specific compatible values > >> + from a vendor-specific section below, and "simple-bus" as a > >> + fallback. > > > > What happened to the idea of using something like "simple-pm-bus"? > > I think that's a decision to make by the (successor of the) ePAPR committee. > At least it would be nice to get some feedback from the DT review team > about this. > > If we go that road, the vendor-specific compatible value should still be > documented, else checkpatch will complain when encountering it in a DTS. > Then, should it become > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > "simple-bus"; > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > can drop "simple-bus" from the list in the DTS: > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; I was thinking of the reverse: drop "simple-bus" bus from the list here, but not add "simple-pm-bus" to of_default_bus_match_table. This will cause child devices to no longer be probed automatically, and you will have to call of_platform_populate() from simple_pm_bus_probe(), after pm_runtime_enable(). This seems like a cleaner model to me, for two reasons: - In the binding, claiming compatibility with "simple-bus" feels wrong to me, because you have a bus that is not as simple as others - The ordering between pm_runtime_enable() and the probing of the child devices is guaranteed, which I think it is not with your current code. Does this make sense, or am I missing an important reason why there has to be a "simple-bus" compatible string here? Arnd ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 13:46 ` Arnd Bergmann 0 siblings, 0 replies; 34+ messages in thread From: Arnd Bergmann @ 2015-01-23 13:46 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Kevin Hilman, Geert Uytterhoeven, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> new file mode 100644 > >> index 0000000000000000..d03abf7fd8e3997a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> @@ -0,0 +1,52 @@ > >> +Simple Power-Managed Bus > >> +======================== > >> + > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > >> +driver, as it's typically initialized by the boot loader. > >> + > >> +However, its bus controller is part of a PM domain, or under the control of a > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > >> +enabled for child devices connected to the bus (either on-SoC or externally) > >> +to function. > >> + > >> + > >> +Generic compatible values and properties > >> +---------------------------------------- > >> + > >> +Required properties: > >> + - compatible: Must be at least one of the vendor-specific compatible values > >> + from a vendor-specific section below, and "simple-bus" as a > >> + fallback. > > > > What happened to the idea of using something like "simple-pm-bus"? > > I think that's a decision to make by the (successor of the) ePAPR committee. > At least it would be nice to get some feedback from the DT review team > about this. > > If we go that road, the vendor-specific compatible value should still be > documented, else checkpatch will complain when encountering it in a DTS. > Then, should it become > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > "simple-bus"; > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > can drop "simple-bus" from the list in the DTS: > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; I was thinking of the reverse: drop "simple-bus" bus from the list here, but not add "simple-pm-bus" to of_default_bus_match_table. This will cause child devices to no longer be probed automatically, and you will have to call of_platform_populate() from simple_pm_bus_probe(), after pm_runtime_enable(). This seems like a cleaner model to me, for two reasons: - In the binding, claiming compatibility with "simple-bus" feels wrong to me, because you have a bus that is not as simple as others - The ordering between pm_runtime_enable() and the probing of the child devices is guaranteed, which I think it is not with your current code. Does this make sense, or am I missing an important reason why there has to be a "simple-bus" compatible string here? Arnd ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings 2015-01-23 13:46 ` Arnd Bergmann (?) (?) @ 2015-01-23 14:18 ` Geert Uytterhoeven -1 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 14:18 UTC (permalink / raw) To: linux-arm-kernel Hi Arnd, On Fri, Jan 23, 2015 at 2:46 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> new file mode 100644 >> >> index 0000000000000000..d03abf7fd8e3997a >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> @@ -0,0 +1,52 @@ >> >> +Simple Power-Managed Bus >> >> +============ >> >> + >> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> >> +driver, as it's typically initialized by the boot loader. >> >> + >> >> +However, its bus controller is part of a PM domain, or under the control of a >> >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> >> +enabled for child devices connected to the bus (either on-SoC or externally) >> >> +to function. >> >> + >> >> + >> >> +Generic compatible values and properties >> >> +---------------------------------------- >> >> + >> >> +Required properties: >> >> + - compatible: Must be at least one of the vendor-specific compatible values >> >> + from a vendor-specific section below, and "simple-bus" as a >> >> + fallback. >> > >> > What happened to the idea of using something like "simple-pm-bus"? >> >> I think that's a decision to make by the (successor of the) ePAPR committee. >> At least it would be nice to get some feedback from the DT review team >> about this. >> >> If we go that road, the vendor-specific compatible value should still be >> documented, else checkpatch will complain when encountering it in a DTS. >> Then, should it become >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", >> "simple-bus"; >> >> or should "simple-bus" just be added to of_default_bus_match_table[], so we Sorry, FTR, I meant "simple-pm-bus" here. >> can drop "simple-bus" from the list in the DTS: >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). This seems like a cleaner model to me, for two > reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others > > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. The ordering is indeed a good argument. Will update. Hence: - The DTS will claim a compatibility with "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus". - The driver will match against "simple-pm-bus". Note that if we ever have a real driver for "renesas,bsc", we'll have to be careful about binding ordering. "simple-bus" is handled by core code, and doesn't prevent a more specific driver to take precedence. "simple-pm-bus" is handled by a driver, so if it binds first, a more specific driver cannot take over. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? Yes, it makes sense. I had the "simple-bus" compatible entry there because of the "most generic first", "least generic last" rule. If you don't use the extra features (i.e. don't touch the clocks or PM domains in the SoC), it is compatible with "simple-bus". That's more or less how it was in r8a73a4-ape6evm-reference.dts before the advent of CCF and PM domains. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 14:18 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 14:18 UTC (permalink / raw) To: linux-arm-kernel Hi Arnd, On Fri, Jan 23, 2015 at 2:46 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> new file mode 100644 >> >> index 0000000000000000..d03abf7fd8e3997a >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> @@ -0,0 +1,52 @@ >> >> +Simple Power-Managed Bus >> >> +======================== >> >> + >> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> >> +driver, as it's typically initialized by the boot loader. >> >> + >> >> +However, its bus controller is part of a PM domain, or under the control of a >> >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> >> +enabled for child devices connected to the bus (either on-SoC or externally) >> >> +to function. >> >> + >> >> + >> >> +Generic compatible values and properties >> >> +---------------------------------------- >> >> + >> >> +Required properties: >> >> + - compatible: Must be at least one of the vendor-specific compatible values >> >> + from a vendor-specific section below, and "simple-bus" as a >> >> + fallback. >> > >> > What happened to the idea of using something like "simple-pm-bus"? >> >> I think that's a decision to make by the (successor of the) ePAPR committee. >> At least it would be nice to get some feedback from the DT review team >> about this. >> >> If we go that road, the vendor-specific compatible value should still be >> documented, else checkpatch will complain when encountering it in a DTS. >> Then, should it become >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", >> "simple-bus"; >> >> or should "simple-bus" just be added to of_default_bus_match_table[], so we Sorry, FTR, I meant "simple-pm-bus" here. >> can drop "simple-bus" from the list in the DTS: >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). This seems like a cleaner model to me, for two > reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others > > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. The ordering is indeed a good argument. Will update. Hence: - The DTS will claim a compatibility with "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus". - The driver will match against "simple-pm-bus". Note that if we ever have a real driver for "renesas,bsc", we'll have to be careful about binding ordering. "simple-bus" is handled by core code, and doesn't prevent a more specific driver to take precedence. "simple-pm-bus" is handled by a driver, so if it binds first, a more specific driver cannot take over. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? Yes, it makes sense. I had the "simple-bus" compatible entry there because of the "most generic first", "least generic last" rule. If you don't use the extra features (i.e. don't touch the clocks or PM domains in the SoC), it is compatible with "simple-bus". That's more or less how it was in r8a73a4-ape6evm-reference.dts before the advent of CCF and PM domains. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 14:18 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 14:18 UTC (permalink / raw) To: Arnd Bergmann Cc: Kevin Hilman, Geert Uytterhoeven, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel Hi Arnd, On Fri, Jan 23, 2015 at 2:46 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> new file mode 100644 >> >> index 0000000000000000..d03abf7fd8e3997a >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> @@ -0,0 +1,52 @@ >> >> +Simple Power-Managed Bus >> >> +======================== >> >> + >> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> >> +driver, as it's typically initialized by the boot loader. >> >> + >> >> +However, its bus controller is part of a PM domain, or under the control of a >> >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> >> +enabled for child devices connected to the bus (either on-SoC or externally) >> >> +to function. >> >> + >> >> + >> >> +Generic compatible values and properties >> >> +---------------------------------------- >> >> + >> >> +Required properties: >> >> + - compatible: Must be at least one of the vendor-specific compatible values >> >> + from a vendor-specific section below, and "simple-bus" as a >> >> + fallback. >> > >> > What happened to the idea of using something like "simple-pm-bus"? >> >> I think that's a decision to make by the (successor of the) ePAPR committee. >> At least it would be nice to get some feedback from the DT review team >> about this. >> >> If we go that road, the vendor-specific compatible value should still be >> documented, else checkpatch will complain when encountering it in a DTS. >> Then, should it become >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", >> "simple-bus"; >> >> or should "simple-bus" just be added to of_default_bus_match_table[], so we Sorry, FTR, I meant "simple-pm-bus" here. >> can drop "simple-bus" from the list in the DTS: >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). This seems like a cleaner model to me, for two > reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others > > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. The ordering is indeed a good argument. Will update. Hence: - The DTS will claim a compatibility with "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus". - The driver will match against "simple-pm-bus". Note that if we ever have a real driver for "renesas,bsc", we'll have to be careful about binding ordering. "simple-bus" is handled by core code, and doesn't prevent a more specific driver to take precedence. "simple-pm-bus" is handled by a driver, so if it binds first, a more specific driver cannot take over. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? Yes, it makes sense. I had the "simple-bus" compatible entry there because of the "most generic first", "least generic last" rule. If you don't use the extra features (i.e. don't touch the clocks or PM domains in the SoC), it is compatible with "simple-bus". That's more or less how it was in r8a73a4-ape6evm-reference.dts before the advent of CCF and PM domains. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 14:18 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-23 14:18 UTC (permalink / raw) To: Arnd Bergmann Cc: Kevin Hilman, Geert Uytterhoeven, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel Hi Arnd, On Fri, Jan 23, 2015 at 2:46 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: >> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> new file mode 100644 >> >> index 0000000000000000..d03abf7fd8e3997a >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> >> @@ -0,0 +1,52 @@ >> >> +Simple Power-Managed Bus >> >> +======================== >> >> + >> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real >> >> +driver, as it's typically initialized by the boot loader. >> >> + >> >> +However, its bus controller is part of a PM domain, or under the control of a >> >> +functional clock. Hence, the bus controller's PM domain and/or clock must be >> >> +enabled for child devices connected to the bus (either on-SoC or externally) >> >> +to function. >> >> + >> >> + >> >> +Generic compatible values and properties >> >> +---------------------------------------- >> >> + >> >> +Required properties: >> >> + - compatible: Must be at least one of the vendor-specific compatible values >> >> + from a vendor-specific section below, and "simple-bus" as a >> >> + fallback. >> > >> > What happened to the idea of using something like "simple-pm-bus"? >> >> I think that's a decision to make by the (successor of the) ePAPR committee. >> At least it would be nice to get some feedback from the DT review team >> about this. >> >> If we go that road, the vendor-specific compatible value should still be >> documented, else checkpatch will complain when encountering it in a DTS. >> Then, should it become >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", >> "simple-bus"; >> >> or should "simple-bus" just be added to of_default_bus_match_table[], so we Sorry, FTR, I meant "simple-pm-bus" here. >> can drop "simple-bus" from the list in the DTS: >> >> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). This seems like a cleaner model to me, for two > reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others > > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. The ordering is indeed a good argument. Will update. Hence: - The DTS will claim a compatibility with "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus". - The driver will match against "simple-pm-bus". Note that if we ever have a real driver for "renesas,bsc", we'll have to be careful about binding ordering. "simple-bus" is handled by core code, and doesn't prevent a more specific driver to take precedence. "simple-pm-bus" is handled by a driver, so if it binds first, a more specific driver cannot take over. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? Yes, it makes sense. I had the "simple-bus" compatible entry there because of the "most generic first", "least generic last" rule. If you don't use the extra features (i.e. don't touch the clocks or PM domains in the SoC), it is compatible with "simple-bus". That's more or less how it was in r8a73a4-ape6evm-reference.dts before the advent of CCF and PM domains. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings 2015-01-23 13:46 ` Arnd Bergmann (?) (?) @ 2015-01-23 14:34 ` Mark Rutland -1 siblings, 0 replies; 34+ messages in thread From: Mark Rutland @ 2015-01-23 14:34 UTC (permalink / raw) To: linux-arm-kernel On Fri, Jan 23, 2015 at 01:46:35PM +0000, Arnd Bergmann wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> new file mode 100644 > > >> index 0000000000000000..d03abf7fd8e3997a > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> @@ -0,0 +1,52 @@ > > >> +Simple Power-Managed Bus > > >> +============ > > >> + > > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > > >> +driver, as it's typically initialized by the boot loader. > > >> + > > >> +However, its bus controller is part of a PM domain, or under the control of a > > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > > >> +enabled for child devices connected to the bus (either on-SoC or externally) > > >> +to function. > > >> + > > >> + > > >> +Generic compatible values and properties > > >> +---------------------------------------- > > >> + > > >> +Required properties: > > >> + - compatible: Must be at least one of the vendor-specific compatible values > > >> + from a vendor-specific section below, and "simple-bus" as a > > >> + fallback. > > > > > > What happened to the idea of using something like "simple-pm-bus"? > > > > I think that's a decision to make by the (successor of the) ePAPR committee. > > At least it would be nice to get some feedback from the DT review team > > about this. > > > > If we go that road, the vendor-specific compatible value should still be > > documented, else checkpatch will complain when encountering it in a DTS. > > Then, should it become > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > > "simple-bus"; > > > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > > can drop "simple-bus" from the list in the DTS: > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). I am in complete agreement. > This seems like a cleaner model to me, for two reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others Well, it depends. If you _can_ handle it as a "simple-bus" (i.e. it's in a sane state by default and you can ignore the bus details entirely), then "simple-bus" is appropriate. However, I don't think that we can always rely on this, because the state is highly dependent on the FW, bootloader, and the rest of the kernel. We have clock/regulator/whatever controller drivers which disable unused outputs (for power saving and/or flushing out FW bugs). The dtb has no idea about all of these in-kernel details. If the kernel probes the bus as a "simple-bus" (with no pm at all), then the bus may have been inadvertently disabled already (or may become so later). If the kernel is in control of the providers of inputs, then the kernel _must_ explicitly handle those inputs (which requires the bus to be probed as "simple-pm-bus" and not "simple-bus"). > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. There's also kexec to consider. You'd need to ensure that the bus is re-initialised prior to exit from the kernel to keep the bus "simple-bus" compatible for the next user. I imagine that enabling a device prior to exit from the kernel is the opposite of what the PM code does. Just having "simple-pm-bus" (and requiring the simple-pm-bus driver to do sub-node probing _after_ initialisation of the PM'd bus) is much more robust. That way if the OS can't acquire all the necessary resources (and guarantee the bus will work), it won't start trying to probe the children and hang/explode. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? The only reason to have it would be to enable an old kernel to use a new DT. However, for the reasons above I believe that would be broken anyway, so I do not think that "simple-bus" is an appropriate compatible fallback. Thanks, Mark. ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 14:34 ` Mark Rutland 0 siblings, 0 replies; 34+ messages in thread From: Mark Rutland @ 2015-01-23 14:34 UTC (permalink / raw) To: linux-arm-kernel On Fri, Jan 23, 2015 at 01:46:35PM +0000, Arnd Bergmann wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> new file mode 100644 > > >> index 0000000000000000..d03abf7fd8e3997a > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> @@ -0,0 +1,52 @@ > > >> +Simple Power-Managed Bus > > >> +======================== > > >> + > > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > > >> +driver, as it's typically initialized by the boot loader. > > >> + > > >> +However, its bus controller is part of a PM domain, or under the control of a > > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > > >> +enabled for child devices connected to the bus (either on-SoC or externally) > > >> +to function. > > >> + > > >> + > > >> +Generic compatible values and properties > > >> +---------------------------------------- > > >> + > > >> +Required properties: > > >> + - compatible: Must be at least one of the vendor-specific compatible values > > >> + from a vendor-specific section below, and "simple-bus" as a > > >> + fallback. > > > > > > What happened to the idea of using something like "simple-pm-bus"? > > > > I think that's a decision to make by the (successor of the) ePAPR committee. > > At least it would be nice to get some feedback from the DT review team > > about this. > > > > If we go that road, the vendor-specific compatible value should still be > > documented, else checkpatch will complain when encountering it in a DTS. > > Then, should it become > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > > "simple-bus"; > > > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > > can drop "simple-bus" from the list in the DTS: > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). I am in complete agreement. > This seems like a cleaner model to me, for two reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others Well, it depends. If you _can_ handle it as a "simple-bus" (i.e. it's in a sane state by default and you can ignore the bus details entirely), then "simple-bus" is appropriate. However, I don't think that we can always rely on this, because the state is highly dependent on the FW, bootloader, and the rest of the kernel. We have clock/regulator/whatever controller drivers which disable unused outputs (for power saving and/or flushing out FW bugs). The dtb has no idea about all of these in-kernel details. If the kernel probes the bus as a "simple-bus" (with no pm at all), then the bus may have been inadvertently disabled already (or may become so later). If the kernel is in control of the providers of inputs, then the kernel _must_ explicitly handle those inputs (which requires the bus to be probed as "simple-pm-bus" and not "simple-bus"). > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. There's also kexec to consider. You'd need to ensure that the bus is re-initialised prior to exit from the kernel to keep the bus "simple-bus" compatible for the next user. I imagine that enabling a device prior to exit from the kernel is the opposite of what the PM code does. Just having "simple-pm-bus" (and requiring the simple-pm-bus driver to do sub-node probing _after_ initialisation of the PM'd bus) is much more robust. That way if the OS can't acquire all the necessary resources (and guarantee the bus will work), it won't start trying to probe the children and hang/explode. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? The only reason to have it would be to enable an old kernel to use a new DT. However, for the reasons above I believe that would be broken anyway, so I do not think that "simple-bus" is an appropriate compatible fallback. Thanks, Mark. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 14:34 ` Mark Rutland 0 siblings, 0 replies; 34+ messages in thread From: Mark Rutland @ 2015-01-23 14:34 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, Kevin Hilman, Geert Uytterhoeven, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, grant.likely, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel On Fri, Jan 23, 2015 at 01:46:35PM +0000, Arnd Bergmann wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> new file mode 100644 > > >> index 0000000000000000..d03abf7fd8e3997a > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> @@ -0,0 +1,52 @@ > > >> +Simple Power-Managed Bus > > >> +======================== > > >> + > > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > > >> +driver, as it's typically initialized by the boot loader. > > >> + > > >> +However, its bus controller is part of a PM domain, or under the control of a > > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > > >> +enabled for child devices connected to the bus (either on-SoC or externally) > > >> +to function. > > >> + > > >> + > > >> +Generic compatible values and properties > > >> +---------------------------------------- > > >> + > > >> +Required properties: > > >> + - compatible: Must be at least one of the vendor-specific compatible values > > >> + from a vendor-specific section below, and "simple-bus" as a > > >> + fallback. > > > > > > What happened to the idea of using something like "simple-pm-bus"? > > > > I think that's a decision to make by the (successor of the) ePAPR committee. > > At least it would be nice to get some feedback from the DT review team > > about this. > > > > If we go that road, the vendor-specific compatible value should still be > > documented, else checkpatch will complain when encountering it in a DTS. > > Then, should it become > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > > "simple-bus"; > > > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > > can drop "simple-bus" from the list in the DTS: > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). I am in complete agreement. > This seems like a cleaner model to me, for two reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others Well, it depends. If you _can_ handle it as a "simple-bus" (i.e. it's in a sane state by default and you can ignore the bus details entirely), then "simple-bus" is appropriate. However, I don't think that we can always rely on this, because the state is highly dependent on the FW, bootloader, and the rest of the kernel. We have clock/regulator/whatever controller drivers which disable unused outputs (for power saving and/or flushing out FW bugs). The dtb has no idea about all of these in-kernel details. If the kernel probes the bus as a "simple-bus" (with no pm at all), then the bus may have been inadvertently disabled already (or may become so later). If the kernel is in control of the providers of inputs, then the kernel _must_ explicitly handle those inputs (which requires the bus to be probed as "simple-pm-bus" and not "simple-bus"). > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. There's also kexec to consider. You'd need to ensure that the bus is re-initialised prior to exit from the kernel to keep the bus "simple-bus" compatible for the next user. I imagine that enabling a device prior to exit from the kernel is the opposite of what the PM code does. Just having "simple-pm-bus" (and requiring the simple-pm-bus driver to do sub-node probing _after_ initialisation of the PM'd bus) is much more robust. That way if the OS can't acquire all the necessary resources (and guarantee the bus will work), it won't start trying to probe the children and hang/explode. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? The only reason to have it would be to enable an old kernel to use a new DT. However, for the reasons above I believe that would be broken anyway, so I do not think that "simple-bus" is an appropriate compatible fallback. Thanks, Mark. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings @ 2015-01-23 14:34 ` Mark Rutland 0 siblings, 0 replies; 34+ messages in thread From: Mark Rutland @ 2015-01-23 14:34 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, Kevin Hilman, Geert Uytterhoeven, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala, grant.likely, Ulf Hansson, Rafael J. Wysocki, Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, Linux-sh list, Linux PM list, linux-arm-kernel, linux-kernel On Fri, Jan 23, 2015 at 01:46:35PM +0000, Arnd Bergmann wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> new file mode 100644 > > >> index 0000000000000000..d03abf7fd8e3997a > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> @@ -0,0 +1,52 @@ > > >> +Simple Power-Managed Bus > > >> +======================== > > >> + > > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > > >> +driver, as it's typically initialized by the boot loader. > > >> + > > >> +However, its bus controller is part of a PM domain, or under the control of a > > >> +functional clock. Hence, the bus controller's PM domain and/or clock must be > > >> +enabled for child devices connected to the bus (either on-SoC or externally) > > >> +to function. > > >> + > > >> + > > >> +Generic compatible values and properties > > >> +---------------------------------------- > > >> + > > >> +Required properties: > > >> + - compatible: Must be at least one of the vendor-specific compatible values > > >> + from a vendor-specific section below, and "simple-bus" as a > > >> + fallback. > > > > > > What happened to the idea of using something like "simple-pm-bus"? > > > > I think that's a decision to make by the (successor of the) ePAPR committee. > > At least it would be nice to get some feedback from the DT review team > > about this. > > > > If we go that road, the vendor-specific compatible value should still be > > documented, else checkpatch will complain when encountering it in a DTS. > > Then, should it become > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > > "simple-bus"; > > > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > > can drop "simple-bus" from the list in the DTS: > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). I am in complete agreement. > This seems like a cleaner model to me, for two reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others Well, it depends. If you _can_ handle it as a "simple-bus" (i.e. it's in a sane state by default and you can ignore the bus details entirely), then "simple-bus" is appropriate. However, I don't think that we can always rely on this, because the state is highly dependent on the FW, bootloader, and the rest of the kernel. We have clock/regulator/whatever controller drivers which disable unused outputs (for power saving and/or flushing out FW bugs). The dtb has no idea about all of these in-kernel details. If the kernel probes the bus as a "simple-bus" (with no pm at all), then the bus may have been inadvertently disabled already (or may become so later). If the kernel is in control of the providers of inputs, then the kernel _must_ explicitly handle those inputs (which requires the bus to be probed as "simple-pm-bus" and not "simple-bus"). > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. There's also kexec to consider. You'd need to ensure that the bus is re-initialised prior to exit from the kernel to keep the bus "simple-bus" compatible for the next user. I imagine that enabling a device prior to exit from the kernel is the opposite of what the PM code does. Just having "simple-pm-bus" (and requiring the simple-pm-bus driver to do sub-node probing _after_ initialisation of the PM'd bus) is much more robust. That way if the OS can't acquire all the necessary resources (and guarantee the bus will work), it won't start trying to probe the children and hang/explode. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? The only reason to have it would be to enable an old kernel to use a new DT. However, for the reasons above I believe that would be broken anyway, so I do not think that "simple-bus" is an appropriate compatible fallback. Thanks, Mark. ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3/resend 4/4] drivers: bus: Add Simple Power-Managed Bus Driver 2015-01-22 9:34 ` Geert Uytterhoeven (?) @ 2015-01-22 9:34 ` Geert Uytterhoeven -1 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Add a driver for transparent busses that don't need a real driver (think "simple-bus"), where the bus controller is part of a PM domain, or under the control of a functional clock. Typically, the bus controller's PM domain and/or clock must be enabled for child devices connected to the bus (either on-SoC or externally) to function. Hence the sole purpose of this driver is to enable its clock and PM domain (if exist(s)), which are specified in the DT and managed from platform and PM domain code. Due to the child-parent relationship with devices connected to the bus, PM domain and clock state transitions are handled in the correct order. Currently this driver handles the Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus Bridge", or "External Bus Interface") found on several Renesas ARM SoCs. Support for other bus controllers can easily be added by adding more compatible values. Note that this driver cannot just bind against "simple-bus", as that may prevent a device-specific driver from taking precedence. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - Rename from "Renesas Bus State Controller Driver" (renesas-bsc) to "Simple Power-Managed Bus Driver" (simple-pm-bus), - Change module license to GPL v2, - Change email address to geert+renesas@glider.be. --- drivers/bus/Kconfig | 13 ++++++++++++ drivers/bus/Makefile | 1 + drivers/bus/simple-pm-bus.c | 51 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+) create mode 100644 drivers/bus/simple-pm-bus.c diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 626960819e6df16c..1addb707bf8100e3 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -58,6 +58,19 @@ config OMAP_OCP2SCP OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via OCP2SCP. +config SIMPLE_PM_BUS + bool "Simple Power-Managed Bus Driver" + depends on OF && PM + depends on ARCH_SHMOBILE || COMPILE_TEST + help + Driver for transparent busses that don't need a real driver (think + "simple-bus"), where the bus controller is part of a PM domain, or + under the control of a functional clock, and thus relies on runtime + PM for managing this PM domain and/or clock. + An example of such a bus controller is the Renesas Bus State + Controller (BSC, sometimes called "LBSC within Bus Bridge", or + "External Bus Interface") as found on several Renesas ARM SoCs. + config VEXPRESS_CONFIG bool "Versatile Express configuration bus" default y if ARCH_VEXPRESS diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 3cfaf2c7f25ac4f0..e023a2bec664d900 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -14,4 +14,5 @@ obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c new file mode 100644 index 0000000000000000..e55872d2695bd551 --- /dev/null +++ b/drivers/bus/simple-pm-bus.c @@ -0,0 +1,51 @@ +/* + * Simple Power-Managed Bus Driver + * + * Copyright (C) 2014 Glider bvba + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> + + +static int simple_pm_bus_probe(struct platform_device *pdev) +{ + dev_dbg(&pdev->dev, "%s\n", __func__); + + pm_runtime_enable(&pdev->dev); + return 0; +} + +static int simple_pm_bus_remove(struct platform_device *pdev) +{ + dev_dbg(&pdev->dev, "%s\n", __func__); + + pm_runtime_disable(&pdev->dev); + return 0; +} + +static const struct of_device_id simple_pm_bus_of_match[] = { + { .compatible = "renesas,bsc", }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match); + +static struct platform_driver simple_pm_bus_driver = { + .probe = simple_pm_bus_probe, + .remove = simple_pm_bus_remove, + .driver = { + .name = "simple-pm-bus", + .of_match_table = simple_pm_bus_of_match, + }, +}; + +module_platform_driver(simple_pm_bus_driver); + +MODULE_DESCRIPTION("Simple Power-Managed Bus Driver"); +MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>"); +MODULE_LICENSE("GPL v2"); -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 4/4] drivers: bus: Add Simple Power-Managed Bus Driver @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: linux-arm-kernel Add a driver for transparent busses that don't need a real driver (think "simple-bus"), where the bus controller is part of a PM domain, or under the control of a functional clock. Typically, the bus controller's PM domain and/or clock must be enabled for child devices connected to the bus (either on-SoC or externally) to function. Hence the sole purpose of this driver is to enable its clock and PM domain (if exist(s)), which are specified in the DT and managed from platform and PM domain code. Due to the child-parent relationship with devices connected to the bus, PM domain and clock state transitions are handled in the correct order. Currently this driver handles the Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus Bridge", or "External Bus Interface") found on several Renesas ARM SoCs. Support for other bus controllers can easily be added by adding more compatible values. Note that this driver cannot just bind against "simple-bus", as that may prevent a device-specific driver from taking precedence. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - Rename from "Renesas Bus State Controller Driver" (renesas-bsc) to "Simple Power-Managed Bus Driver" (simple-pm-bus), - Change module license to GPL v2, - Change email address to geert+renesas at glider.be. --- drivers/bus/Kconfig | 13 ++++++++++++ drivers/bus/Makefile | 1 + drivers/bus/simple-pm-bus.c | 51 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+) create mode 100644 drivers/bus/simple-pm-bus.c diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 626960819e6df16c..1addb707bf8100e3 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -58,6 +58,19 @@ config OMAP_OCP2SCP OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via OCP2SCP. +config SIMPLE_PM_BUS + bool "Simple Power-Managed Bus Driver" + depends on OF && PM + depends on ARCH_SHMOBILE || COMPILE_TEST + help + Driver for transparent busses that don't need a real driver (think + "simple-bus"), where the bus controller is part of a PM domain, or + under the control of a functional clock, and thus relies on runtime + PM for managing this PM domain and/or clock. + An example of such a bus controller is the Renesas Bus State + Controller (BSC, sometimes called "LBSC within Bus Bridge", or + "External Bus Interface") as found on several Renesas ARM SoCs. + config VEXPRESS_CONFIG bool "Versatile Express configuration bus" default y if ARCH_VEXPRESS diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 3cfaf2c7f25ac4f0..e023a2bec664d900 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -14,4 +14,5 @@ obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c new file mode 100644 index 0000000000000000..e55872d2695bd551 --- /dev/null +++ b/drivers/bus/simple-pm-bus.c @@ -0,0 +1,51 @@ +/* + * Simple Power-Managed Bus Driver + * + * Copyright (C) 2014 Glider bvba + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> + + +static int simple_pm_bus_probe(struct platform_device *pdev) +{ + dev_dbg(&pdev->dev, "%s\n", __func__); + + pm_runtime_enable(&pdev->dev); + return 0; +} + +static int simple_pm_bus_remove(struct platform_device *pdev) +{ + dev_dbg(&pdev->dev, "%s\n", __func__); + + pm_runtime_disable(&pdev->dev); + return 0; +} + +static const struct of_device_id simple_pm_bus_of_match[] = { + { .compatible = "renesas,bsc", }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match); + +static struct platform_driver simple_pm_bus_driver = { + .probe = simple_pm_bus_probe, + .remove = simple_pm_bus_remove, + .driver = { + .name = "simple-pm-bus", + .of_match_table = simple_pm_bus_of_match, + }, +}; + +module_platform_driver(simple_pm_bus_driver); + +MODULE_DESCRIPTION("Simple Power-Managed Bus Driver"); +MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>"); +MODULE_LICENSE("GPL v2"); -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3/resend 4/4] drivers: bus: Add Simple Power-Managed Bus Driver @ 2015-01-22 9:34 ` Geert Uytterhoeven 0 siblings, 0 replies; 34+ messages in thread From: Geert Uytterhoeven @ 2015-01-22 9:34 UTC (permalink / raw) To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Grant Likely, Arnd Bergmann, Kevin Hilman, Ulf Hansson, Rafael J. Wysocki Cc: Olof Johansson, Simon Horman, Magnus Damm, Greg Kroah-Hartman, devicetree, linux-sh, linux-pm, linux-arm-kernel, linux-kernel, Geert Uytterhoeven Add a driver for transparent busses that don't need a real driver (think "simple-bus"), where the bus controller is part of a PM domain, or under the control of a functional clock. Typically, the bus controller's PM domain and/or clock must be enabled for child devices connected to the bus (either on-SoC or externally) to function. Hence the sole purpose of this driver is to enable its clock and PM domain (if exist(s)), which are specified in the DT and managed from platform and PM domain code. Due to the child-parent relationship with devices connected to the bus, PM domain and clock state transitions are handled in the correct order. Currently this driver handles the Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus Bridge", or "External Bus Interface") found on several Renesas ARM SoCs. Support for other bus controllers can easily be added by adding more compatible values. Note that this driver cannot just bind against "simple-bus", as that may prevent a device-specific driver from taking precedence. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> --- v3: - Add Tested-by, v2: - Rename from "Renesas Bus State Controller Driver" (renesas-bsc) to "Simple Power-Managed Bus Driver" (simple-pm-bus), - Change module license to GPL v2, - Change email address to geert+renesas@glider.be. --- drivers/bus/Kconfig | 13 ++++++++++++ drivers/bus/Makefile | 1 + drivers/bus/simple-pm-bus.c | 51 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+) create mode 100644 drivers/bus/simple-pm-bus.c diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 626960819e6df16c..1addb707bf8100e3 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -58,6 +58,19 @@ config OMAP_OCP2SCP OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via OCP2SCP. +config SIMPLE_PM_BUS + bool "Simple Power-Managed Bus Driver" + depends on OF && PM + depends on ARCH_SHMOBILE || COMPILE_TEST + help + Driver for transparent busses that don't need a real driver (think + "simple-bus"), where the bus controller is part of a PM domain, or + under the control of a functional clock, and thus relies on runtime + PM for managing this PM domain and/or clock. + An example of such a bus controller is the Renesas Bus State + Controller (BSC, sometimes called "LBSC within Bus Bridge", or + "External Bus Interface") as found on several Renesas ARM SoCs. + config VEXPRESS_CONFIG bool "Versatile Express configuration bus" default y if ARCH_VEXPRESS diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile index 3cfaf2c7f25ac4f0..e023a2bec664d900 100644 --- a/drivers/bus/Makefile +++ b/drivers/bus/Makefile @@ -14,4 +14,5 @@ obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o +obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c new file mode 100644 index 0000000000000000..e55872d2695bd551 --- /dev/null +++ b/drivers/bus/simple-pm-bus.c @@ -0,0 +1,51 @@ +/* + * Simple Power-Managed Bus Driver + * + * Copyright (C) 2014 Glider bvba + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> + + +static int simple_pm_bus_probe(struct platform_device *pdev) +{ + dev_dbg(&pdev->dev, "%s\n", __func__); + + pm_runtime_enable(&pdev->dev); + return 0; +} + +static int simple_pm_bus_remove(struct platform_device *pdev) +{ + dev_dbg(&pdev->dev, "%s\n", __func__); + + pm_runtime_disable(&pdev->dev); + return 0; +} + +static const struct of_device_id simple_pm_bus_of_match[] = { + { .compatible = "renesas,bsc", }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match); + +static struct platform_driver simple_pm_bus_driver = { + .probe = simple_pm_bus_probe, + .remove = simple_pm_bus_remove, + .driver = { + .name = "simple-pm-bus", + .of_match_table = simple_pm_bus_of_match, + }, +}; + +module_platform_driver(simple_pm_bus_driver); + +MODULE_DESCRIPTION("Simple Power-Managed Bus Driver"); +MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>"); +MODULE_LICENSE("GPL v2"); -- 1.9.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
end of thread, other threads:[~2015-01-23 14:35 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-22 9:34 [PATCH v3/resend 0/4] drivers: bus: Add Simple Power-Managed Bus Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` [PATCH v3/resend 1/4] drivers: bus: Sort Kconfig entries alphabetically Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` [PATCH v3/resend 2/4] drivers: bus: Sort Makefile " Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` [PATCH v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 22:42 ` Kevin Hilman 2015-01-22 22:42 ` Kevin Hilman 2015-01-22 22:42 ` Kevin Hilman 2015-01-23 8:56 ` Geert Uytterhoeven 2015-01-23 8:56 ` Geert Uytterhoeven 2015-01-23 8:56 ` Geert Uytterhoeven 2015-01-23 8:56 ` Geert Uytterhoeven 2015-01-23 13:46 ` Arnd Bergmann 2015-01-23 13:46 ` Arnd Bergmann 2015-01-23 13:46 ` Arnd Bergmann 2015-01-23 13:46 ` Arnd Bergmann 2015-01-23 14:18 ` Geert Uytterhoeven 2015-01-23 14:18 ` Geert Uytterhoeven 2015-01-23 14:18 ` Geert Uytterhoeven 2015-01-23 14:18 ` Geert Uytterhoeven 2015-01-23 14:34 ` Mark Rutland 2015-01-23 14:34 ` Mark Rutland 2015-01-23 14:34 ` Mark Rutland 2015-01-23 14:34 ` Mark Rutland 2015-01-22 9:34 ` [PATCH v3/resend 4/4] drivers: bus: Add Simple Power-Managed Bus Driver Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven 2015-01-22 9:34 ` Geert Uytterhoeven
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.