Hi Rob,
On Tue, Apr 4, 2017 at 4:29 PM, Rob Herring <[email protected]> wrote:
> On Wed, Mar 29, 2017 at 1:49 AM, Geert Uytterhoeven
> <[email protected]> wrote:
>> On Wed, Mar 29, 2017 at 3:24 AM, Rob Herring <[email protected]> wrote:
>>> On Wed, Mar 22, 2017 at 10:27:49AM -0400, Chris Brandt wrote:
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
>>>> +Example:
>>>> +rtc: rtc@fcff1000 {
>>>> + compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
>>>> + reg = <0xfcff1000 0x2e>;
>>>> + interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
>>>> + GIC_SPI 277 IRQ_TYPE_EDGE_RISING
>>>> + GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
>>>> + interrupt-names = "alarm", "period", "carry";
>>>> + clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
>>>> + <&rtc_x3_clk>, <&extal_clk>;
>>>> + clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
>>>> + power-domains = <&cpg_clocks>;
>>>
>>> Not documented.
>>
>> "power-domains" is a platform property.
>>
>> All hardware components need power.
>> All synchronous hardware components need a clock.
>> Most hardware components have a reset signal.
>
> And we document clocks and reset for every binding.
Then we'll have to add lots of them ;-)
Usually these are documented only if the user (the driver) cares about them,
and/or if there are multiple of the same type. E.g.
- The driver needs to know or control a clock frequency,
- The driver needs to enable/disable a clock,
- The driver needs to know or control one or more voltages,
- ...
It's not that devices without documented regulators, power-domains, or clocks
properties no longer consume power or don't run from a clock. These are just
not described in DT, as deemed unimportant. But on some platforms, they may
become important.
>> Whether these are exposed and can be controlled depends on the platform/SoC.
>> So documenting them in each and every device binding looks overkill to me.
>> I think this is something to be addressed by devicetree-specification (which
>> doesn't handle clocks, power-domains, resets yet).
>
> It's a question of validation. How do I validate power-domains is a
> valid property for a given compatible? What if it is required, but not
With platform property, I mean that it depends on the platform, not on the
compatible value of the device.
For a generic compatible value ("renesas,sh-srtc") you cannot know, as
it depends on the actual SoC the (same) RTC device is part of.
For an SoC-specific compatible value ("renesas,r7s72100-rtc"), you could know
from the compatible value (an r7s72100 SoC must have r7s72100 clocks, and the
r7s72100 clock domain, cfr.
Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt).
However. the SoC-specific compatible values exist only as a workaround
for not knowing
the exact version of the IP cores.
> present? Any node can have it? So it is valid for memory and chosen
> nodes, an i2c device, an LCD panel, etc?
It's not valid for a chosen node ;-)
It can be valid for memory (or the memory-controller; oops, the memory node is
not a child of the memory-controller node), i2c devices, LCD panels, ...
depending on the platform.
Consider e.g. i2c devices. I can add a GPIO-controlled MOSFET bank to my board,
to enable power to individual i2c devices, and abstract that as a
power-controller in DT. Suddenly I have to add power-domains properties to the
individual i2c device nodes, while the i2c devices itself haven't changed, and
thus keep the same compatible values.
Should I now document the power-domains property in the i2c devices' DT binding
documents?
On Linux, the drivers won't care, as the platform-specific things are handled
transparently by Runtime PM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
