Hi Vaibhav,
On Wednesday 10 April 2013 11:49 AM, Bedia, Vaibhav wrote:
Hi Sourav, Kevin,
On Wed, Apr 10, 2013 at 11:37:28, Poddar, Sourav wrote:
Hi,
On Wednesday 10 April 2013 12:37 AM, Kevin Hilman wrote:
Sourav Poddar<sourav.poddar@xxxxxx> writes:
Hi Kevin,
On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:
Sourav Poddar<sourav.poddar@xxxxxx> writes:
With dt boot, uart wakeup after suspend is non functional while using
"no_console_suspend" in the bootargs. With "no_console_suspend" used, we
should prevent the runtime suspend of the uart port which is getting used
as an console.
Cc: Santosh Shilimkar<santosh.shilimkar@xxxxxx>
Cc: Felipe Balbi<balbi@xxxxxx>
Cc: Rajendra nayak<rnayak@xxxxxx>
Tested on omap5430evm, omap4430sdp.
Signed-off-by: Sourav Poddar<sourav.poddar@xxxxxx>
Rather than make these special checks inside the driver's runtime PM
callbacks, you should just disable runtime PM (pm_runtime_disable())
Then, this should be broken into 2 patches.
1) serial core: add the '->is_console' flag. (nit on naming: don't call
it port_is_console, since the struct is already a uart_port)
2) In the OMAP UART driver's ->prepare callback, check the is_console flag
and pm_runtime_disable() accordingly (then pm_runtime_enable() in
the drivers's ->complete callback.
Kevin
I was working on your above suggestions, but realised there is not
only console
uart which has the requirement of keeping the clocks enabled while going on
suspend.
If you see arch/arm/boot/dts/am33xx.dtsi, there is a ocmcram which has
"no_idle_on_suspend" property used.
Can you please ask the AM33xx folks how (and why) this is being used?
I don't see/find a driver for this device in mainline, so without a
driver this flag will not be used.
Looping in Vaibhav Bedia for ocmcram..
[Vaibhav]:
There is a discussion going on about a cleaner way of handling
ti, no_idle_on_suspend" part (as this is a sort of hack). We got a way
around for UART ($subject) by making serial core/driver handle this
for us.
But with this, we will delete codes around "no_idle_on_suspend" flag in
omap_device file.
But, we realised that its not only UART which requires the clocks to
be active
whie going for suspend. There is a dts entry for ocmcram also.
As Kevin also pointed out, we don't see a driver for this device in
mainline, It would be
great if you can explain how its getting used?
You can find the complete discussion on v3 here:
https://lkml.org/lkml/2013/4/5/239
The flag in question is used to ensure that the clock to OCMC RAM is not
disabled by the PM code.
From the changelog which added this flag:
"Note: OCMC RAM is part of the PER power domain and supports
retention. The assembly code for low power entry/exit will
run from OCMC RAM. To ensure that the OMAP PM code does not
attempt to disable the clock to OCMC RAM as part of the
suspend process add the no_idle_on_suspend flag."
We had discussed about the usage of this flag in the RFC version
of the patch [1].
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". ?
Regards,
Vaibhav
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129510.html
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
