On Thu, Jan 21, 2016 at 04:48:57PM +0800, Zhaoyang Huang wrote: > Hi Mark,
Hi, > Do you have any suggestion on how to sync the GIC operation from > kernel and psci parallelly? Thanks! I'm not sure what you mean. What problem are you having with synchronising GIC accesses? As far as I can see, the CPU sending the IPI can simply poke the relevant register in the distributor without requiring any synchronisation. The CPU receiving the IPI is the only CPU with access to its CPU interface. Could you describe your problem in more detail? Thanks, Mark. > On 12 January 2016 at 19:51, Mark Rutland <[email protected]> wrote: > > On Tue, Jan 12, 2016 at 09:38:20AM +0000, Lorenzo Pieralisi wrote: > >> On Tue, Jan 12, 2016 at 10:17:42AM +0800, Zhaoyang Huang wrote: > >> > On 12 January 2016 at 10:05, Zhaoyang Huang <[email protected]> > >> > wrote: > >> > > In some ARM SOCs, IPI interrupt is used for hotplug in one cpu, that > >> > > is, > >> > > sending a IPI to the core in WFI and powerdown status. So Add a IPI > >> > > entry for handle this kind of cpu up interrupt > >> > > Launching the IPI can be done within PSCI, while there will be one > >> > > unknown > >> > > type of IPI as the dest core come up to the kernel world which will > >> > > bring a > >> > > warning so far.So add such type of IPI to handle the interrupt. > >> > >> You missed CC'ing ALKML for the second time and you were warned. > >> > >> You are adding a call to *send* an IPI in the kernel so the commit > >> above is misleading. > >> > >> Acknowledge and clear the IRQ in FW so that the mechanism is completely > >> implemented in FW (ie PSCI), that the CPU coming out of reset will run > >> before getting to the kernel, this patch is not needed and we already > >> explained to you why. > >> > >> Lorenzo > > > > I would also suggest that FW used the set of SGIs reserved for secure > > usage (i.e. ID8 - ID15), as these will not conflict with those the > > kernel uses. > > > > Thanks, > > Mark. >
