Yes, the generic PD got added in v3.18-rc1, it's better to check if we
-----Original Message----- From: Will Deacon
[mailto:will.deacon@xxxxxxx] Sent: 2014年7月4日 1:57 To: Neil Zhang
Cc: Sudeep Holla; 'linux@xxxxxxxxxxxxxxxx'; 'linux-arm-
kernel@xxxxxxxxxxxxxxxxxxx'; 'linux-kernel@xxxxxxxxxxxxxxx';
'devicetree@xxxxxxxxxxxxxxx' Subject: Re: [PATCH v4] ARM: perf:
save/restore pmu registers in pm notifier
On Mon, Jun 30, 2014 at 11:39:15AM +0100, Neil Zhang wrote:
Do you have any comments? If no, I would like to put it under PMUSorry for reply later. As I said before the under discussedI will prepare another patch to add DT description under
PMU since there is no generic power domain support for pm
notifier if no other concerns. We can change the manner if
there is generic power domain support for pm notifier
later. Thanks.
No, please don't add any DT bindings for power domains
specific to PMU node. We can't change the DT bindings once
added.
As I pointed out the DT bindings for generic power domains
are under discussion. See if you can reuse it, if not help in
extending it so that it can be used.
generic power domain is not suitable for CPU peripherals since
they are all known belong to CPU or cluster power domain. If
we want to follow the way they are discussion, we need to
register core and cluster power provider, and need vfp/gic/pmu
etc to require them.
Is it really suitable?
node.
Sudeep is a better person to comment than me, but I'd still rather
this was handled more generically as opposed to a PMU-specific
hack. I don't see a problem including GIC and VFP here, but only
when we actually need to save/restore them (i.e. what the hardware
guys went crazy with the power domains).
Long time no follow up for this loop. Sorry that I will pick it
again.
Will, I prefer to check always-on field under PMU node to checkBut how do you handle it for different idle states. e.g. if CPU is in
whether we need Save/restore them.