From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Houcheng Lin <houcheng@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Stephen Gallimore <stephen.gallimore@st.com>,
Srinivas KANDAGATLA <srinivas.kandagatla@st.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
sre@kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Vikas Sajjan <vikas.sajjan@samsung.com>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v3] reset: Add a defer reset object to send board specific reset
Date: Thu, 14 Aug 2014 12:47:38 +0200 [thread overview]
Message-ID: <20140814104738.GV15297@lukather> (raw)
In-Reply-To: <1408008998.4035.43.camel@paszta.hi.pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
On Thu, Aug 14, 2014 at 11:36:38AM +0200, Philipp Zabel wrote:
> Hi Maxime,
>
> Am Montag, den 11.08.2014, 19:33 +0200 schrieb Maxime Ripard:
> > > Mostly because Maxime and I seem to have a completely different opinion
> > > and nobody else argued one way or the other.
> >
> > Yep, mostly because I don't see how a generic approach can work.
> >
> > The existing reset-gpios property only provide the gpio to use, but
> > some informations are encoded in the driver, such as the reset
> > duration, or a reset sequence if any.
>
> The driver should provide the duration.
How? This used to be in the code, and reset_control_reset doesn't take
such argument.
> I'd really like to see an example where sequencing is necessary.
Well, if you have several reset lines, the sequencing between each
might be important.
> I agree that as soon as things get significantly more complicated than
> pulsing a single GPIO, the reset-gpios binding is too limited.
While the generic reset bindings are perfect for that.
> Still, I'm not happy to mandate a separate gpio reset device for each
> reset line if most devices are simple enough for it to work without.
Well, it's pretty much already the case for other subsystems, such as
regulator.
I guess we can treat this as a legacy option, but allow the reset-gpio
code to be a full driver of its own, if we need more advanced use
cases?
> What about using reset-gpios for the majority of simple cases and have a
> separate gpio-reset-sequencer driver when multiple GPIO resets have to
> be timed?
I don't know. I feel like it should be in the driver itself, rather
than in a generic layer.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2014-08-14 10:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 13:37 [RFC PATCH v3] reset: Add a defer reset object to send board specific reset Houcheng Lin
2014-06-20 9:35 ` Maxime Ripard
2014-07-07 12:38 ` Linus Walleij
2014-07-10 22:00 ` Houcheng Lin
2014-07-08 7:52 ` Linus Walleij
2014-07-08 8:05 ` Maxime Ripard
2014-07-08 9:38 ` Linus Walleij
2014-08-08 14:23 ` Philipp Zabel
2014-08-11 17:33 ` Maxime Ripard
2014-08-14 9:36 ` Philipp Zabel
2014-08-14 10:47 ` Maxime Ripard [this message]
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=20140814104738.GV15297@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=gnurou@gmail.com \
--cc=grant.likely@linaro.org \
--cc=houcheng@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=sre@kernel.org \
--cc=srinivas.kandagatla@st.com \
--cc=stephen.gallimore@st.com \
--cc=ulf.hansson@linaro.org \
--cc=vikas.sajjan@samsung.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).