linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] usb: dwc3: keystone: switch to use runtime pm
Date: Fri, 31 Jan 2014 10:45:34 -0600	[thread overview]
Message-ID: <20140131164534.GL20736@saruman.home> (raw)
In-Reply-To: <52EBC650.50305@ti.com>

On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> > On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
> >> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> >>>> The Keystone PM management layer has been implemented using PM bus for
> >>>> power management clocks. As result, most of Keystone drivers don't need
> >>>> to manage clocks directly. They just need to enable runtime PM and use it
> >>>> to handle their PM state and clocks.
> >>>>
> >>>> Hence, remove clock management code and switch to use runtime PM.
> >>>>
> >>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >>>
> >>> quite a few weeks back I sent a series enabling runtime pm for all glue
> >>> layers. I'll use that version instead, sorry.
> >>>
> >> That should be fine but you need to drop clk_*() related code
> >> from that patch. I assume you will send refresh version of it then.
> > 
> > why ? it makes no difference if you enable twice and disable twice.
> > 
> Sure but why do you want to have the clock node handling code in drivers
> if it is not needed. Isn't that better ?

It might, but then way that I wanted to see it is so that I can make
assumptions about the device state. From a driver perspective, what I
would love to see is the ability to assume that when my probe gets
called the device is already enabled. So if you can make sure that
clk_enable() happens before my probe and that you call
pm_runtime_set_active() before my probe too, then I can more than
hapilly remove clk_* calls from the driver ;-)

either that or maintain the driver like so:

probe()
{
	...

	clk_get(dev, "fck");
	clk_prepare(clk);
	clk_enable(clk);
	pm_runtime_set_active(dev);
	pm_runtime_enable(dev);
	pm_runtime_get_sync(dev);
	...
}

runtime_suspend()
{
	clk_disable(dev);
}

runtime_resume()
{
	clk_enable(dev);
}

note that because of pm_runtime_set_active() that first
pm_runtime_get_sync() in probe() will simply increase the reference
counter without calling my ->runtime_resume() callback, which is exactly
what we want, as that would completely avoid situations of bad context
being restored because of that initial pm_runtime_get_sync().

Then, we can even make pm_runtime completely async easily, because
clk_prepare() was called only on probe() (or before it, for that
matter).

Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
clk_enable() and pm_runtime_set_active() will be called properly before
my probe, i'll be more than happy to comply with your request above as
that will greatly simplify my driver.

Just make, also, that if this clock is shared between dwc3-keystone
wrapper and dwc3 core, you clk_get() on both driver's probe.

cheers

-- 
balbi
-------------- 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/20140131/e709d095/attachment.sig>

  reply	other threads:[~2014-01-31 16:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-31 13:20 [PATCH] usb: dwc3: keystone: switch to use runtime pm Grygorii Strashko
2014-01-31 14:35 ` Santosh Shilimkar
2014-01-31 15:19 ` Felipe Balbi
2014-01-31 15:43   ` Santosh Shilimkar
2014-01-31 15:47     ` Felipe Balbi
2014-01-31 15:50       ` Santosh Shilimkar
2014-01-31 16:45         ` Felipe Balbi [this message]
2014-01-31 19:20           ` Santosh Shilimkar
2014-01-31 22:15             ` Felipe Balbi
2014-01-31 23:04               ` Santosh Shilimkar
2014-01-31 21:13           ` Alan Stern
2014-01-31 22:11             ` Felipe Balbi

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=20140131164534.GL20736@saruman.home \
    --to=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).