[PATCH] PM / Domains: Power on the PM domain right after attach completes
Russell King - ARM Linux
linux at arm.linux.org.uk
Mon Nov 17 09:07:28 PST 2014
On Mon, Nov 17, 2014 at 06:54:44PM +0200, Grygorii Strashko wrote:
> I'd be very appreciated if you would be able to clarify one point to me as
> I'm not familiar with amba hw?
> I've found at least 2 AMBA drivers where secondary clock is used
> to enable/disable device in addition to "apb_pclk":
> - drivers/mmc/host/mmci.c
> - drivers/spi/spi-pl022.c
> So, form the code point of view, the assumption that "unbound AMBA
> devices are already powered up" is not always true. And "apb_pclk"
> is just an interface clock in such cases.
Right, what we're talking about here is that the device is accessible
to the CPU - that it is powered up and the bus clock to it is running,
so that accesses to the device will not cause a bus fault.
It does not mean that the external interface to the outside world is
functional - for example, there's no suggestion that the clock to the
SD/MMC card attached to MMCI would be running, or that the SD/MMC card
itself would be powered up, and the same goes for the clocks supplied
as functional clocks. The driver is expected to manage these clocks
How this all works in the AMBA context is:
- we ensure that the apb_pclk is running by getting it, preparing and
- the bus code calls pm_runtime_get_noresume() which increments the
usage counter without calling the (as yet not bound) driver.
- if a PM domain is attached to the device, it should already be active
and powered up.
- the device is marked active (as it should now be powered and bus-clocked.)
- runtime PM is enabled.
At this point, the device must be accessible to the CPU.
- the driver probe function is called, and it can go around getting any
additional clocks it needs, and enabling or disabling them as it
requires. (For example, in the case of MMCI, a card may not be inserted
in the slot, so the driver may decide to keep the functional MMCICLK
- if the driver wishes to take part in runtime PM, it calls pm_runtime_put()
or an equivalent function. This balances the pm_runtime_get_noresume()
above, and allows the runtime PM infrastructure to consider the device
idle, and a candidate for runtime suspend.
Should the device runtime suspend, it's up to the driver to deal with the
functional clocks it is managing, because only it knows whether it kept
those clocks running, and disabling an already disabled clock is not
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
More information about the linux-arm-kernel