On Mon, Apr 28, 2014 at 01:55:40PM +0200, Ulf Hansson wrote:
> On 27 April 2014 15:29, Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> wrote:
> > The PMU device contains an interrupt controller, power control and
> > resets. The interrupt controller is a little sub-standard in that
> > there is no race free way to clear down pending interrupts, so we try
> > to avoid problems by reducing the window as much as possible, and
> > clearing as infrequently as possible.
> >
> > The interrupt support is implemented using an IRQ domain, and the
> > parent interrupt referenced in the standard DT way.
> >
> > The power domains and reset support is closely related - there is a
> > defined sequence for powering down a domain which is tightly coupled
> > with asserting the reset. Hence, it makes sense to group these two
> > together.
> >
> > This patch adds the core PMU driver: power domains must be defined in
> > the DT file in order to make use of them. The reset controller can
> > be referenced in the standard way for reset controllers.
>
> Hi Russell,
>
> This patch would be simplified if this was based upon the not yet
> merged patchset from Tomasz Figa, "[PATCH v3 0/3] Generic Device Tree
> based power domain look-up".
>
> For example you would likely not need to add some of the marvel
> specific DT bindings, and you wouldn’t need the bus_notifiers to add
> devices to the power domain. I guess I just though it could be useful
> input to consider while going forward, unless you already knew.
In 3.19, I notice something of an odd behaviour.
My vMeta driver has runtime PM support enabled. When I explicitly register
the PM domain in the pmu driver via a bus notifier, I see:
root@cubox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
gpu-domain on
/devices/platform/vivante/etnaviv-gpu,2d active
vpu-domain off
/devices/platform/mbus/mbus:internal-regs/f1c00000.video-decoder suspended
But when I disable that, and let the generic code do the registration,
I instead get:
root@cubox:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
----------------------------------------------------------------------
gpu-domain on
/devices/platform/vivante/etnaviv-gpu,2d active
vpu-domain on
/devices/platform/mbus/mbus:internal-regs/f1c00000.video-decoder suspended
The difference being that the vpu domain remains powered.
The only difference code-wise seems to be when genpd_dev_pm_attach() is
called. In the working case, it's before the device is considered for
probing. In the non-working case, it's just before the device is probed.
With debugging enabled in the PM domain code, with the former case I get:
Added domain provider from /mbus/internal-regs/power-management@d0000/vpu-domain
platform f1c00000.video-decoder: adding to PM domain vpu-domain
platform f1c00000.video-decoder: __pm_genpd_add_device()
With the latter non-working case:
Added domain provider from /mbus/internal-regs/power-management@d0000/vpu-domain
...
ap510-vmeta f1c00000.video-decoder: adding to PM domain vpu-domain
ap510-vmeta f1c00000.video-decoder: __pm_genpd_add_device()
vpu-domain: Power-on latency exceeded, new value 1578 ns
Neither of these debug messages provide much hint as to what the
difference is, or the cause of the PM domain code being de-sync'd
with its devices.
Maybe the PM code needs more debugging in it, and maybe the debugfs
file should always be present if debugfs support is enabled?
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
