[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFqNdw-6R12cUOre8UOTOnB-PpxHD5rPAMCwuS3i--Sesg@mail.gmail.com>
Date: Mon, 10 Feb 2014 13:33:50 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Mark Brown <broonie@...nel.org>
Cc: Russell King <linux@....linux.org.uk>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Alessandro Rubini <rubini@...pv.it>,
Linus Walleij <linus.walleij@...aro.org>,
Wolfram Sang <wsa@...-dreams.de>,
Chris Ball <chris@...ntf.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
linux-mmc <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH 07/17] spi: pl022: Don't ignore power domain and amba bus
at system suspend
On 4 February 2014 20:16, Mark Brown <broonie@...nel.org> wrote:
> On Tue, Feb 04, 2014 at 04:58:48PM +0100, Ulf Hansson wrote:
>
>> @@ -2328,8 +2300,23 @@ static int pl022_suspend(struct device *dev)
>> return ret;
>> }
>>
>> - pm_runtime_get_sync(dev);
>> - pl022_suspend_resources(pl022, false);
>> + pm_runtime_disable(dev);
>> +
>> + if (!pm_runtime_status_suspended(dev)) {
>> + if (dev->pm_domain && dev->pm_domain->ops.runtime_suspend)
>> + ret = dev->pm_domain->ops.runtime_suspend(dev);
>> + else
>> + ret = dev->bus->pm->runtime_suspend(dev);
>> +
>> + if (ret) {
>> + pm_runtime_enable(dev);
>> + return ret;
>> + }
>> +
>> + pm_runtime_set_suspended(dev);
>> + }
>
> This seems like a fairly hideous thing to be having to open code in an
> individual driver, it all looks generic and like something that most if
> not all devices ought to be doing and it looks very vulnerable to being
> broken by changes in the core. At the very least I would expect this to
> be done in a helper function, though it would be even nicer if the
> driver core were figuring this stuff out for us based on the device
> level callback so that drivers didn't need to worry about being in power
> domains or manually calling bus level callbacks.
>
> Putting it in a helper would at least mean that it's easier for the
> mechanics to be transferred to the core proper later on.
I agree, a helper function would be nice. I have earlier sent a patch
to the PM core, that is similar to the code above, though it was
rejected in it's current form. Let me follow up on this again.
At this point, would a way forward be to still go ahead with this
patch and then convert to, when/if, the helper function from the PM
core becomes available?
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists