From: Tony Lindgren <tony@atomide.com>
To: Roger Quadros <rogerq@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>, Paul Walmsley <paul@pwsan.com>,
t-kristo@ti.com, nm@ti.com, nsekhar@ti.com,
bcousson@baylibre.com, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Date: Fri, 2 Jan 2015 09:29:35 -0800 [thread overview]
Message-ID: <20150102172935.GD3298@atomide.com> (raw)
In-Reply-To: <5493EA88.1080609@ti.com>
* Roger Quadros <rogerq@ti.com> [141219 01:08]:
> Lokesh,
>
> On 19/12/14 07:21, Lokesh Vutla wrote:
> > Hi Roger,
> > On Thursday 18 December 2014 09:22 PM, Roger Quadros wrote:
> >> Fixing up Paul's email id.
> >>
> >> cheers,
> >> -roger
> >>
> >> On 18/12/14 17:49, Roger Quadros wrote:
> >>> There are quite a few hwmods that don't have sysconfig register and so
> >>> _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
> >>> on those modules after the module is enabled.
> >>>
> >>> This can potentially cause a bus access error if the module is accessed
> >>> before the module is ready.
> >>>
> >>> Get rid of the redundant _find_mpu_rt_port() check from the _wait_target_ready()
> >>> funcion for all the SoCs. The following PRCM register access that checks the
> >>> module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port.
> > Yes, makes sense. This patch looks good to me.
> > Tested this on AM437x-gp-evm.
Roger, if the modules don't have sysconfig registers, care to check
if we actually really need hwmod for those modules then?
I know hwmod is managing runtime PM gate clocks for devices with
clkctrl_offs. But if that's all we need hwmod for in the non-sysc
cases, then it might make sense to manage the gate clocks in the
clock framework directly instead for those devices.
Of course that's more of a long term project, but at least we should
be aware of the dependencies here :)
> > May be good idea to warn every time if enabling of module is failed?
> > Unrelated to this patch though.
>
> Yes, failing to be ready is serious enough for a warning. Care to send a separate patch for that?
Yeah that sounds like a separate patch.
Regards,
Tony
next prev parent reply other threads:[~2015-01-02 17:29 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 15:49 [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc Roger Quadros
2014-12-18 15:49 ` Roger Quadros
2014-12-18 15:52 ` Roger Quadros
2014-12-18 15:52 ` Roger Quadros
2014-12-19 5:21 ` Lokesh Vutla
2014-12-19 5:21 ` Lokesh Vutla
2014-12-19 9:06 ` Roger Quadros
2014-12-19 9:06 ` Roger Quadros
2015-01-02 17:29 ` Tony Lindgren [this message]
2015-01-02 21:10 ` Paul Walmsley
2015-01-02 21:10 ` Paul Walmsley
2015-01-05 8:35 ` Lokesh Vutla
2015-01-05 8:35 ` Lokesh Vutla
2015-01-05 8:35 ` Lokesh Vutla
2015-01-05 19:53 ` Suman Anna
2015-01-05 19:53 ` Suman Anna
2015-01-05 19:53 ` Suman Anna
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:19 ` Paul Walmsley
2015-01-05 22:31 ` santosh.shilimkar
2015-01-05 22:31 ` santosh.shilimkar at oracle.com
2015-01-06 2:04 ` Paul Walmsley
2015-01-06 2:04 ` Paul Walmsley
2015-01-06 8:14 ` Lokesh Vutla
2015-01-06 8:14 ` Lokesh Vutla
2015-01-06 8:14 ` Lokesh Vutla
2015-01-06 17:14 ` Suman Anna
2015-01-06 17:14 ` Suman Anna
2015-01-06 17:14 ` Suman Anna
2015-01-06 17:27 ` Suman Anna
2015-01-06 17:27 ` Suman Anna
2015-01-06 17:27 ` Suman Anna
2015-01-06 22:10 ` Suman Anna
2015-01-06 22:10 ` Suman Anna
2015-01-06 22:10 ` Suman Anna
2015-01-13 23:45 ` Paul Walmsley
2015-01-13 23:45 ` Paul Walmsley
2015-01-13 23:29 ` Paul Walmsley
2015-01-13 23:29 ` Paul Walmsley
2015-01-14 1:56 ` Suman Anna
2015-01-14 1:56 ` Suman Anna
2015-01-14 1:56 ` Suman Anna
2015-01-07 11:20 ` Roger Quadros
2015-01-07 11:20 ` Roger Quadros
2015-01-07 11:20 ` Roger Quadros
2015-01-13 23:46 ` Paul Walmsley
2015-01-13 23:46 ` Paul Walmsley
2015-01-14 12:26 ` Roger Quadros
2015-01-14 12:26 ` Roger Quadros
2015-01-14 12:26 ` Roger Quadros
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=20150102172935.GD3298@atomide.com \
--to=tony@atomide.com \
--cc=bcousson@baylibre.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=paul@pwsan.com \
--cc=rogerq@ti.com \
--cc=t-kristo@ti.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.