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 --]
WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [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>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140814/36248234/attachment.sig>
next prev parent reply other threads:[~2014-08-14 10:50 UTC|newest]
Thread overview: 19+ 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 7:52 ` Linus Walleij
2014-07-08 8:05 ` Maxime Ripard
2014-07-08 8:05 ` Maxime Ripard
2014-07-08 8:05 ` Maxime Ripard
2014-07-08 9:38 ` Linus Walleij
2014-07-08 9:38 ` Linus Walleij
2014-08-08 14:23 ` Philipp Zabel
2014-08-08 14:23 ` Philipp Zabel
2014-08-11 17:33 ` Maxime Ripard
2014-08-11 17:33 ` Maxime Ripard
2014-08-14 9:36 ` Philipp Zabel
2014-08-14 9:36 ` Philipp Zabel
2014-08-14 10:47 ` Maxime Ripard [this message]
2014-08-14 10:47 ` Maxime Ripard
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 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.