All of lore.kernel.org
 help / color / mirror / Atom feed
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, 10 Jan 2014 12:25:36 +0100	[thread overview]
Message-ID: <1389353136.5854.13.camel@pizza.hi.pengutronix.de> (raw)
In-Reply-To: <201401081708.26679.arnd@arndb.de>

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


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, 10 Jan 2014 12:25:36 +0100	[thread overview]
Message-ID: <1389353136.5854.13.camel@pizza.hi.pengutronix.de> (raw)
In-Reply-To: <201401081708.26679.arnd-r2nGTMty4D4@public.gmane.org>

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

--
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

  reply	other threads:[~2014-01-10 11:25 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 [this message]
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
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=1389353136.5854.13.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: link
Be 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.