Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation

[Philipp Zabel]

Am Donnerstag, den 06.02.2014, 16:44 +0100 schrieb Philipp Zabel:
> 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?

Yes? No? Maybe later?

> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/