All of lore.kernel.org
 help / color / mirror / Atom feed
* [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: 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 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 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: 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 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 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: 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 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 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: 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

* [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 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: 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

* [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

* 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

* 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

* [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
  (?)
  (?)
@ 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

* 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
  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

* [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
  (?)
  (?)
@ 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

* 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

* [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
  (?)
  (?)
@ 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

* 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

* [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 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

* 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 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

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.