Hi Kevin, On Thu, Apr 11, 2013 at 19:45:33, Kevin Hilman wrote: > Kevin Hilman <khil...@linaro.org> writes: > > > "Bedia, Vaibhav" <vaibhav.be...@ti.com> 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. > > OK, I think I confused things here, sorry. I was thinking runtime PM > here, but wrote system PM. The no_idle_on_suspend feature only affects > system PM, and the omap_device calls will still be called during system > PM, even without a driver. > > That being said, the commit below[1], added in v3.6 should prevent the > any automaic clock gating for devices without drivers bound. Since > there is no driver for the OCM RAM block, you shouldn't be affected by > the automatic idle on suspend anyways. > > So, my proposal is that Sourav remove that flag from the AM33xx hwmod > when he removes this feature. >
Apologies for the delayed response. I was out of office for a couple of days. I don't recall the exact kernel version in which I ended up adding this flag to keep the clock running but yes after the change mentioned below this flag is not required. I just did a sanity check by removing this flag on v3.8 kernel and things work fine across suspend. Regards, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
