RE: [PATCHv3] driver: serial: prevent UART console idle on suspendwhile using "no_console_suspend"

[Bedia, Vaibhav]

Hi Kevin,

On Thu, Apr 11, 2013 at 19:45:33, Kevin Hilman wrote:
> Kevin Hilman <khilman@xxxxxxxxxx> writes:
> 
> > "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.
> 
> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/