> -----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: > > > > > I 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. > > > > > > > > > > Sorry for reply later. > > > As I said before the under discussed 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? > > > > > Do you have any comments? > > If no, I would like to put it under PMU 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 check whether we need Save/restore them. Here is a sample for arch timer which also add under itself. What do you think? commit 82a5619410d4c4df65c04272db198eca5a867c18 Author: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> Date: Tue Apr 8 10:04:32 2014 +0100 clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue > Will Best Regards, Neil Zhang ?韬{.n?????%??檩??w?{.n????z谵{???塄}?财??j:+v??????2??璀??摺?囤??z夸z罐?+?????w棹f