| Message ID | 1422288977-20353-4-git-send-email-geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
On Mon, Jan 26, 2015 at 04:16:15PM +0000, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > Tested-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com> > --- > v4: > - Replace "simple-bus" by "simple-pm-bus", > - Remove the "renesas,bsc" bindings. They will be specified in a > separate document. > > 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 | 41 ++++++++++++++++++++++ > 1 file changed, 41 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..0415e93a816c5ac0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > @@ -0,0 +1,41 @@ > +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. > + > +The bindings for the Simple Power-Managed Bus extend the bindings for > +"simple-bus", as specified in ePAPR. I would note that "simple-pm-bus" follows the "simple-bus" set of properties, but is not an extension of "simple-bus". For the reasons I mentioned previously, I don't think that any "simple-pm-bus" should be "simple-bus" compatible (and I believe we should document that requirement below). > + > + > +Required properties: > + - compatible: Must contain at least "simple-pm-bus". > + It's recommended to let this be preceded by one or more > + vendor-specific compatible values. > + - #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), I'm a little worried about the clocks. What are the expectations on their configuration? I don't see how we can generally rely on the clock configuration being correct unless the input clocks only have on/off controls, and the OS doesn't see any of the parent clock tree it could potentially change the configuration of (beyond on/off). Otherwise we're relying on implicit behaviour elsewhere in Linux (which _will_ break over time), and this ends up not being usable by anything else. I'm coming to the opinion that while we might be able to have common driver in Linux, we can't have a common "simple-pm-bus" binding because it implicitly assumes too much about the OS behaviour. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mark, On Tue, Jan 27, 2015 at 7:17 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt >> @@ -0,0 +1,41 @@ >> +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. >> + >> +The bindings for the Simple Power-Managed Bus extend the bindings for >> +"simple-bus", as specified in ePAPR. > > I would note that "simple-pm-bus" follows the "simple-bus" set of > properties, but is not an extension of "simple-bus". OK. > For the reasons I mentioned previously, I don't think that any > "simple-pm-bus" should be "simple-bus" compatible (and I believe we > should document that requirement below). >> +Required properties: >> + - compatible: Must contain at least "simple-pm-bus". So you think I should add 'and must not contain "simple-bus"'? >> + It's recommended to let this be preceded by one or more >> + vendor-specific compatible values. >> + - #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), > > I'm a little worried about the clocks. What are the expectations on > their configuration? The clocks are highly platform-dependent. Hence the exact expectations belong in the binding documentation for the clock provider (and possibly the PM domain provider, too). > I don't see how we can generally rely on the clock configuration being > correct unless the input clocks only have on/off controls, and the OS > doesn't see any of the parent clock tree it could potentially change the > configuration of (beyond on/off). This is indeed not about generic programmable clock generators, but about clocks that are used solely to start/stop a hardware module by (un)gating a functional clock. > Otherwise we're relying on implicit behaviour elsewhere in Linux (which > _will_ break over time), and this ends up not being usable by anything > else. > > I'm coming to the opinion that while we might be able to have common > driver in Linux, we can't have a common "simple-pm-bus" binding because > it implicitly assumes too much about the OS behaviour. If the bus controller is clocked from a generic programmable clock generator, it would need its own driver to configure e.g. the clock frequency, which could need more information from DT. This is not covered by "simple-pm-bus". Thanks for your comments! 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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..0415e93a816c5ac0 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt @@ -0,0 +1,41 @@ +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. + +The bindings for the Simple Power-Managed Bus extend the bindings for +"simple-bus", as specified in ePAPR. + + +Required properties: + - compatible: Must contain at least "simple-pm-bus". + It's recommended to let this be preceded by one or more + vendor-specific compatible values. + - #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. + + +Example: + + bsc: bus@fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", + "simple-pm-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>; + };