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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
