From: Philipp Zabel <p.zabel@pengutronix.de> To: Arnd Bergmann <arnd@arndb.de> Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@pengutronix.de, Roger Quadros <rogerq@ti.com>, Mark Rutland <mark.rutland@arm.com>, Maxime Ripard <maxime.ripard@free-electrons.com>, Stephen Warren <swarren@wwwdotorg.org> Subject: Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation Date: Fri, 14 Feb 2014 11:20:59 +0100 [thread overview] Message-ID: <1392373259.3937.8.camel@pizza.hi.pengutronix.de> (raw) In-Reply-To: <1391701458.5008.15.camel@pizza.hi.pengutronix.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> Subject: Re: [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation Date: Fri, 14 Feb 2014 11:20:59 +0100 [thread overview] Message-ID: <1392373259.3937.8.camel@pizza.hi.pengutronix.de> (raw) In-Reply-To: <1391701458.5008.15.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-02-14 10:21 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-08 11:11 [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation Philipp Zabel 2014-01-08 11:11 ` Philipp Zabel 2014-01-08 11:11 ` [PATCH v3 2/2] reset: Add GPIO support to reset controller framework Philipp Zabel 2014-01-08 11:11 ` Philipp Zabel 2014-01-08 16:08 ` [PATCH v3 1/2] Documentation: Add GPIO reset binding to reset binding documentation Arnd Bergmann 2014-01-08 16:08 ` Arnd Bergmann 2014-01-10 11:25 ` Philipp Zabel 2014-01-10 11:25 ` Philipp Zabel 2014-02-06 15:44 ` Philipp Zabel 2014-02-06 15:44 ` Philipp Zabel 2014-02-14 10:20 ` Philipp Zabel [this message] 2014-02-14 10:20 ` Philipp Zabel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1392373259.3937.8.camel@pizza.hi.pengutronix.de \ --to=p.zabel@pengutronix.de \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=kernel@pengutronix.de \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@free-electrons.com \ --cc=rogerq@ti.com \ --cc=swarren@wwwdotorg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.