[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B5906170F1614E41A8A28DE3B8D121433EDA7A0D@DBDE01.ent.ti.com>
Date: Mon, 15 Apr 2013 11:50:37 +0000
From: "Bedia, Vaibhav" <vaibhav.bedia@...com>
To: Kevin Hilman <khilman@...aro.org>
CC: "Poddar, Sourav" <sourav.poddar@...com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"tony@...mide.com" <tony@...mide.com>,
"rmk+kernel@....linux.org.uk" <rmk+kernel@....linux.org.uk>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
"Shilimkar, Santosh" <santosh.shilimkar@...com>,
"Balbi, Felipe" <balbi@...com>, "Nayak, Rajendra" <rnayak@...com>
Subject: RE: [PATCHv3] driver: serial: prevent UART console idle on suspend
while using "no_console_suspend"
Hi Kevin,
On Thu, Apr 11, 2013 at 19:45:33, Kevin Hilman wrote:
> Kevin Hilman <khilman@...aro.org> writes:
>
> > "Bedia, Vaibhav" <vaibhav.bedia@...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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists