> -----Original Message----- > From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > Sent: Tuesday, January 25, 2011 6:27 PM > To: Santosh Shilimkar > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; catalin.marinas@xxxxxxx; > ccross@xxxxxxxxxxx; linus.ml.walleij@xxxxxxxxx; linux- > omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header > file > > On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote: > > Ok. I missed some information my last email. > > The SCU power status programming is used to take CPU in/out > > of coherency as an alternative to SMP bit. We don't > > have an access to SMP bit on OMAP4. ARM has already > > confirmed SCU programming is same as SMP bit enable/disable. > > > > I don't know how safe is to use spin lock when one CPU is > > goes out of coherency after programming the power state. The > > spin lock release may not even be visible to other CPU. > > Erm, I do hope that's not the case, as that means it is unsafe for > CPUs in > a SMP system to write to this register without them potentially > trampling > over each other. > > If it is the case, then the solutions are either: > 1. Fix the hardware so that coherency requests only yet turned off > when entering the WFI state. > 2. Fix the hardware such that each CPU has a separate register. > > I can't see a software solution to this as we can't use ldrex/strex > anything > but memory regions, and memory regions without coherency won't work. > Maybe ARM Support can help by suggesting how a 4-CPU system is > supposed > to safely read/modify/write the SCU power control register... On system wide suspend scenario's this is already handled because CPU's are taken down always sequentially. In CPU ILDE because of some other hardware restrictions we have it sequenced in 2 CPU system. CPU1 needs to be in OFF mode before any power management can be done on system along with master core. And that's how it is working without any races on OMAP Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
