From: Afzal Mohammed <afzal@ti.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Paul Walmsley <paul@pwsan.com>,
Russell King <linux@arm.linux.org.uk>,
Ian Campbell <ian.campbell@citrix.com>,
Pawel Moll <pawel.moll@arm.com>,
linux-doc@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
Pavel Machek <pavel@ucw.cz>,
Stephen Warren <swarren@wwwdotorg.org>,
linux-kernel@vger.kernel.org,
Rob Herring <rob.herring@calxeda.com>,
Rob Landley <rob@landley.net>,
Benoit Cousson <bcousson@baylibre.com>,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Date: Thu, 12 Sep 2013 17:39:34 +0530 [thread overview]
Message-ID: <5231AEFE.5000206@ti.com> (raw)
In-Reply-To: <1378717612.4151.6.camel@pizza.hi.pengutronix.de>
Hi Philipp,
On Monday 09 September 2013 02:36 PM, Philipp Zabel wrote:
> So if I understand correctly, the only problem is that on OMAP the clock
> needs to be enabled to deassert the reset, but as long as the clock
> domain is in hardware supervised mode, it won't be enabled?
Yes, enabling clock with reset deassertion might not reset the module if
the clock domain is in hardware supervised mode.
> Would it be possible to create an internal API to switch the clock
> domain to software supervised mode, which can be used both by the code
> behind pm_runtime_get_sync and reset_control_deassert?
I will see if that is acceptable.
Another option that would have to be explored is invoking device_reset()
(taking care of clear, deassert & status checking as you suggested)
midway through pm_run_time_get_sync(), when the clockdomain is in
software supervised mode with reset driver taking care of any particular
sequence in the case of multiple reset signals, instead of the IP driver
requiring to take care of it.
Regards
Afzal
WARNING: multiple messages have this Message-ID (diff)
From: afzal@ti.com (Afzal Mohammed)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Date: Thu, 12 Sep 2013 17:39:34 +0530 [thread overview]
Message-ID: <5231AEFE.5000206@ti.com> (raw)
In-Reply-To: <1378717612.4151.6.camel@pizza.hi.pengutronix.de>
Hi Philipp,
On Monday 09 September 2013 02:36 PM, Philipp Zabel wrote:
> So if I understand correctly, the only problem is that on OMAP the clock
> needs to be enabled to deassert the reset, but as long as the clock
> domain is in hardware supervised mode, it won't be enabled?
Yes, enabling clock with reset deassertion might not reset the module if
the clock domain is in hardware supervised mode.
> Would it be possible to create an internal API to switch the clock
> domain to software supervised mode, which can be used both by the code
> behind pm_runtime_get_sync and reset_control_deassert?
I will see if that is acceptable.
Another option that would have to be explored is invoking device_reset()
(taking care of clear, deassert & status checking as you suggested)
midway through pm_run_time_get_sync(), when the clockdomain is in
software supervised mode with reset driver taking care of any particular
sequence in the case of multiple reset signals, instead of the IP driver
requiring to take care of it.
Regards
Afzal
WARNING: multiple messages have this Message-ID (diff)
From: Afzal Mohammed <afzal@ti.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: <linux-omap@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<devicetree@vger.kernel.org>, Tony Lindgren <tony@atomide.com>,
Paul Walmsley <paul@pwsan.com>,
Benoit Cousson <bcousson@baylibre.com>,
Russell King <linux@arm.linux.org.uk>,
Ian Campbell <ian.campbell@citrix.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Mark Rutland <mark.rutland@arm.com>,
Pawel Moll <pawel.moll@arm.com>,
Rob Herring <rob.herring@calxeda.com>,
Rob Landley <rob@landley.net>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Date: Thu, 12 Sep 2013 17:39:34 +0530 [thread overview]
Message-ID: <5231AEFE.5000206@ti.com> (raw)
In-Reply-To: <1378717612.4151.6.camel@pizza.hi.pengutronix.de>
Hi Philipp,
On Monday 09 September 2013 02:36 PM, Philipp Zabel wrote:
> So if I understand correctly, the only problem is that on OMAP the clock
> needs to be enabled to deassert the reset, but as long as the clock
> domain is in hardware supervised mode, it won't be enabled?
Yes, enabling clock with reset deassertion might not reset the module if
the clock domain is in hardware supervised mode.
> Would it be possible to create an internal API to switch the clock
> domain to software supervised mode, which can be used both by the code
> behind pm_runtime_get_sync and reset_control_deassert?
I will see if that is acceptable.
Another option that would have to be explored is invoking device_reset()
(taking care of clear, deassert & status checking as you suggested)
midway through pm_run_time_get_sync(), when the clockdomain is in
software supervised mode with reset driver taking care of any particular
sequence in the case of multiple reset signals, instead of the IP driver
requiring to take care of it.
Regards
Afzal
next prev parent reply other threads:[~2013-09-12 12:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 14:11 [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver Afzal Mohammed
2013-09-02 14:11 ` Afzal Mohammed
2013-09-02 14:11 ` Afzal Mohammed
2013-09-02 14:15 ` [PATCH RFC 1/6] reset: is_reset and clear_reset api's Afzal Mohammed
2013-09-02 14:15 ` Afzal Mohammed
2013-09-02 14:15 ` Afzal Mohammed
2013-09-02 14:16 ` [PATCH RFC 2/6] doc: dt: binding: omap: am43x/am335x prcm reset Afzal Mohammed
2013-09-02 14:16 ` Afzal Mohammed
2013-09-02 14:16 ` Afzal Mohammed
2013-09-02 14:18 ` [PATCH RFC 3/6] reset: am43x/am335x support Afzal Mohammed
2013-09-02 14:18 ` Afzal Mohammed
2013-09-02 14:18 ` Afzal Mohammed
2013-09-02 14:20 ` [PATCH RFC 4/6] ARM: OMAP2+: AM43x/AM335x: have reset controller Afzal Mohammed
2013-09-02 14:20 ` Afzal Mohammed
2013-09-02 14:20 ` Afzal Mohammed
2013-10-08 18:17 ` Tony Lindgren
2013-10-08 18:17 ` Tony Lindgren
2013-09-02 14:22 ` [PATCH RFC 5/6] ARM: dts: AM335x: prcm node (for reset) Afzal Mohammed
2013-09-02 14:22 ` Afzal Mohammed
2013-09-02 14:22 ` Afzal Mohammed
[not found] ` <00675d65eef61eb4222e6a461ef479ebbd1d4787.1378129416.git.afzal-l0cyMroinI0@public.gmane.org>
2013-10-08 18:18 ` Tony Lindgren
2013-10-08 18:18 ` Tony Lindgren
2013-10-08 18:18 ` Tony Lindgren
2013-09-02 14:22 ` [PATCH RFC 6/6] ARM: dts: AM4372: " Afzal Mohammed
2013-09-02 14:22 ` Afzal Mohammed
2013-09-02 14:22 ` Afzal Mohammed
2013-09-05 10:07 ` [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver Philipp Zabel
2013-09-05 10:07 ` Philipp Zabel
2013-09-05 15:56 ` Afzal Mohammed
2013-09-05 15:56 ` Afzal Mohammed
2013-09-05 15:56 ` Afzal Mohammed
2013-09-09 9:06 ` Philipp Zabel
2013-09-09 9:06 ` Philipp Zabel
2013-09-12 12:09 ` Afzal Mohammed [this message]
2013-09-12 12:09 ` Afzal Mohammed
2013-09-12 12:09 ` Afzal Mohammed
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=5231AEFE.5000206@ti.com \
--to=afzal@ti.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=ian.campbell@citrix.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=paul@pwsan.com \
--cc=pavel@ucw.cz \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=swarren@wwwdotorg.org \
--cc=tony@atomide.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.