"Bedia, Vaibhav" <vaibhav.bedia@xxxxxx> writes: > Hi Sourav, > > On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote: > [...] >> Yes, had a look at that and found your situation similar to UART. >> >> But how exactly this gets used, I mean I don't see any drivers/ in mainline >> making use of this compatible string "ti,am3352-ocmcram". ? > > OCMC clock is enabled during bootup (not sure whether that's the h/w > default or ROM does it) since the initial bootloader runs from there. > By marking the corresponding hwmod with HWMOD_INIT_NO_IDLE we leave the > clock running. Right now the sram code under arch/arm/plat-omap/ is what > manages the OCMC. I guess this needs to move somewhere under drivers/ > and start managing the clocks. Even then we'll need a mechanism > to leave the clocks running as part of the kernel suspend process > since the assembly code which runs at the fag end of the suspend > process runs out of OCMC and hence we can't cut its clock. > > On AM335x, the OCMC clock is cut to have PER power domain transition > but that's done in the WKUP-M3 firmware when going down. During the > wakeup sequence, WKUP-M3 re-enables the OCMC clock so that when the > kernel resumes the h/w state is same. OK, but *today*, in *mainline*, where in the linux kernel (not the M3 firmware) is the OCMRAM clock cut during suspend? >From what I can see, there is no driver for this device, so there are no system PM calls being done for that device, and thus no omap_device calls being done for that device, so the no_idle_on_suspend has no effect. Kevin -- 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
