[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
(see below.)

How this all works in the AMBA context is:

- we ensure that the apb_pclk is running by getting it, preparing and
  enabling it.

- 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 mailing list