Adrian, On Thursday 17 August 2017 01:53 PM, Adrian Hunter wrote: > On 17/08/17 10:59, Kishon Vijay Abraham I wrote: >> Hi Adrian, >> >> On Thursday 17 August 2017 12:13 PM, Adrian Hunter wrote: >>> On 17/08/17 08:57, Kishon Vijay Abraham I wrote: >>>> Hi Adrian, >>>> >>>> On Tuesday 15 August 2017 01:52 PM, Adrian Hunter wrote: >>>>> On 07/08/17 19:01, Kishon Vijay Abraham I wrote: > > <SNIP> > >>>>>> + pm_runtime_enable(dev); >>>>>> + ret = pm_runtime_get_sync(dev); >>>>> >>>>> What are you trying to do with runtime pm? There don't seem to be any pm >>>>> callbacks, so does this do anything? >>>> >>>> yeah, pm_runtime_get_sync enables the functional clock and also configures the >>>> SYSCONFIG regiters present in the controller. It gets the details for >>>> configuring those from arch/arm/mach-omap2/omap_hwmod_* >>> >>> You mean it will do those things when you add the callbacks? I would prefer >>> you leave out runtime pm until you can add the callbacks as well. >> >> No. Generally in callbacks, 'optional' functional clocks are enabled. But main >> functional clock and interface clocks are enabled in pm_runtime_get_sync. >> Without pm_runtime_get_sync, we won't be able to access controller registers. > > So that is done by the pm domain? Please add comments to the code to explain. right, it's done by omap_device_pm_domain. Invoking pm_runtime_get_sync of a platform device in OMAP platforms will eventually come to omap_hwmod_enable where main functional clock, interface clock and sysconfig are programmed. Thanks Kishon -- 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
