Am Freitag, den 13.02.2015, 17:41 +0100 schrieb Maxime Coquelin:
> 2015-02-13 17:25 GMT+01:00 Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>:
> > Hi Maxime,
> >
> > Am Freitag, den 13.02.2015, 16:59 +0100 schrieb Maxime Coquelin:
> >> Hi Philipp,
> >>
> >> 2015-02-13 12:47 GMT+01:00 Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>:
> >> > Hi Maxime,
> >> >
> >> > Am Donnerstag, den 12.02.2015, 18:46 +0100 schrieb Maxime Coquelin:
> >> > [...]
> >> >> + soc {
> >> >> + reset_ahb1: reset@40023810 {
> >> >> + #reset-cells = <1>;
> >> >> + compatible = "st,stm32-reset";
> >> >> + reg = <0x40023810 0x4>;
> >> >> + };
> >> >> +
> >> >> + reset_ahb2: reset@40023814 {
> >> >> + #reset-cells = <1>;
> >> >> + compatible = "st,stm32-reset";
> >> >> + reg = <0x40023814 0x4>;
> >> >> + };
> >> >> +
> >> >> + reset_ahb3: reset@40023818 {
> >> >> + #reset-cells = <1>;
> >> >> + compatible = "st,stm32-reset";
> >> >> + reg = <0x40023818 0x4>;
> >> >> + };
> >> >> +
> >> >> + reset_apb1: reset@40023820 {
> >> >> + #reset-cells = <1>;
> >> >> + compatible = "st,stm32-reset";
> >> >> + reg = <0x40023820 0x4>;
> >> >> + };
> >> >> +
> >> >> + reset_apb2: reset@40023824 {
> >> >> + #reset-cells = <1>;
> >> >> + compatible = "st,stm32-reset";
> >> >> + reg = <0x40023824 0x4>;
> >> >> + };
> >> >
> >> > These are mostly consecutive, single registers. I wonder if these are
> >> > part of the same IP block and thus should be grouped together into the
> >> > same reset controller node?
> >>
> >> What I could to is to have two instances. One for AHB and one for APB domain.
> >> Doing this, I will have one instance per domain, and only consecutive registers.
> >> Is it fine for you?
> >
> > Looking at
> > http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf
> > Table 34 (RCC register map and reset values), I'd say there is a single
> > "Reset and Clock Control" device at 0x40023800 - 0x40023884:
> >
> > soc {
> > rcc: rcc@40023800 {
> > #clock-cells = <1>;
> > #reset-cells = <1>;
> > compatible = "st,stm32-rcc";
> > reg = <0x40023800 0x84>;
> > };
> >
> > ...
> >
> > If you really want to describe the reset controller parts (offsets +0x10
> > to +0x24) in a separate node, I won't argue against it too long,
> > although this is a somewhat arbitrary decision.
> >
> > In any case, the whole register at offset +0x1c is reserved, so there is
> > no reason to split the reset controller. It is ok to have unused ranges
> > as is already the case with reserved bits inside the used registers.
>
> Ok. I understand your point.
> But it will be more difficult at usage, because the node referencing
> the fourth reset bit of apb2 register will have to pass 164 as
> parameter.
> It is error prone IMHO.
>
> Other solution would be to add some defines for each reset line in the
> DT-Bindings, as we do today for STi platform.
> But it is giving an unneeded constraint between DT and reset trees.
That is a bit unfortunate, but providing the named constants in
include/dt-bindings/reset/ makes for a much better readable device tree,
so I'd prefer that solution, even if it means having to coordinate pull
requests.
regards
Philipp
--
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
