* Rob Herring <robh@xxxxxxxxxx> [180308 22:27]:
> On Thu, Mar 8, 2018 at 10:02 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > In PRM, there are also registers for each interconnect device
> > context lost and wake-up dependencies. We don't have a driver
> > for that yet, it's handled by the SoC init code currently.
>
> Regardless of having/needing a driver, you should take a stab at doing
> the binding at least. It doesn't make sense to do the binding of the
> child without doing the parent.
Sure, we have already partial binding documentation for
PRM at Documentation/devicetree/bindings/arm/omap/prcm.txt.
I'll take a look at updating it for the reset controller.
> > Unlike the binding for reset controller, the binding for
> > wake-up dependencies and context lost should look similar
> > binding to the clkctrl clock binding we have. That's because
> > there are tons of those registers.
> >
> >> > +
> >> > + gfx_rstctrl: rstctrl@4 {
> >> > + compatible = "ti,rstctrl";
> >> > + reg = <0x4 0x4>;
> >>
> >> Anytime I see a single register in DT I worry about scaling. How many of
> >> these in an SoC?
> >
> > There are not many instances of the reset controller. There
> > is one register per interconnect instance for external
> > accelerators, so about 3 - 10 reset controller registers
> > per SoC.
>
> Okay, seems a reasonable number.
>
> However, couldn't you just have PRM node(s) and have that register as
> a simple reset driver (along with anything else it handles).
We could have a driver for PRM, but I'm not sure if doing a
separate PRM driver helps much here. It seems like reset-simple
already does the job for most part and can be enhanced as
needed :)
The missing piece is how to get the extra pieces of information
to the consumer drivers.. That is the reset status and context
lost status of each device.
Regards,
Tony
--
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
