On 20/03/2017 at 16:26:46 +0000, Chris Brandt wrote:
> Hi Geert,
>
> On Monday, March 20, 2017, Geert Uytterhoeven wrote:
> > > + 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>,
> > > + <&extal_clk> , <&rtc_x3_clk>;
> > > + clock-names = "fck", "rtc_x1", "extal", "rtc_x3";
> > > + power-domains = <&cpg_clocks>;
> > > + count-source = "rtc_x1"; <<<<<<< this would be in the
> > board dts file
> >
> > IMHO that's software policy, not hardware description, so it doesn't
> > belong in DT.
>
> Really? I'm so confused about what is and isn't the responsibility of DT.
>
>
> > However, by scanning the list of allowed clock names, and looking at clock
> > rates, the driver can find a suitable clock itself.
>
> Yes, I could make the selection automatic by looking that the clock names (and
> I will do that for this driver), but what about the case where a user needs
> to select something from a list of possible HW options? In other words, where
> does 'software option' selection stuff go if not in the DT?
>
If you want you can leave the clock selection logic out of the driver as
long as the DT binding is complete. You dont have to use everything that
is described in the DT.
Regarding the selection, I'd say take the first that is present and not
0 however, if something has already been set, you may not want to
override it. (I know, this is not helping a lot ;) )
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
