Hi Arnd,
Am Freitag, den 10.01.2014, 12:25 +0100 schrieb Philipp Zabel:
> Hi Arnd,
>
> Am Mittwoch, den 08.01.2014, 17:08 +0100 schrieb Arnd Bergmann:
> > On Wednesday 08 January 2014, Philipp Zabel wrote:
> > > += GPIO Reset consumers =
> > > +
> > > +For the common case of reset lines controlled by GPIOs, the GPIO binding
> > > +documented in devicetree/bindings/gpio/gpio.txt should be used:
> > > +
> > > +Required properties:
> > > +reset-gpios or Reset GPIO using standard GPIO bindings,
> > > +<name>-reset-gpios: optionally named to specify the reset line
> > > +
> > > +Optional properties:
> > > +reset-boot-asserted or Boolean. If set, the corresponding reset is
> > > +<name>-reset-boot-asserted: initially asserted and should be kept that way
> > > + until released by the driver.
> >
> > I don't get this one. Why would you use a different reset binding for the case
> > where the reset line is connected to the gpio controller rather than a
> > specialized reset controller?
> >
> > I was expecting to see the definition of a generic reset controller that
> > in turn uses gpio lines, like
> >
> >
> > reset {
> > compatible = "gpio-reset";
> > /* provides three reset lines through these GPIOs */
> > gpios = <&gpioA 1 &gpioB 7 <gpioD 17>;
> > #reset-cells = <1>;
> > };
> >
> > foo {
> > ...
> > resets = <&reset 0>; /* uses first reset line of the gpio-reset controller */
> > };
>
> That is what I initially proposed...
>
> > I realize it would be a little more verbose, but it also seems more
> > regular and wouldn't stand out from the rest of the reset interfaces.
>
> ... but it can also be argued that GPIO resets shouldn't stand out from
> other GPIOs.
>
> Mark Rutland spoke out against having a 'GPIO reset device' node in the
> device tree:
>
> http://comments.gmane.org/gmane.linux.drivers.devicetree/41596
>
> and I see his point. Using different bindings for reset controller IPs
> and for single GPIOs better describes the actual hardware and it is less
> Linux specific: it still allows an OS without gpio-reset framework to
> let each driver handle the GPIO itself.
>
> Also Stephen Warren pointed out that we'll have to support the existing
> GPIO bindings anyway: in the meantime there are a lot of GPIO resets in
> various device trees that use the GPIO bindings.
>
> regards
> Philipp
do you have further comments on this?
I'd like to request a pull of the changes in
http://git.pengutronix.de/?p=pza/linux.git;a=shortlog;h=refs/heads/reset/for_v3.15
and I wonder whether I should submit that now without the GPIO patches
or hold it back a bit and add them on top.
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
