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
ocmcram: ocmcram@40300000 {
compatible = "ti,am3352-ocmcram";
reg =<0x40300000 0x10000>;
ti,hwmods = "ocmcram";
ti,no_idle_on_suspend;
};
This property gets checked in omap_device file and correspondingly
od->flags is set.
Based on your above inputs, the patches which I cooked up is
inlined[1]. Though, the below
patches works fine for uart case. The patches will effect ocmcram case
and I am inling them
"just for discussion".
Could you also have a look at Russell's suggestion for getting rid of
the 'is_console' flag.
[Kevin]: Yes, will do that.
Thanks,
Kevin
~Sourav
--
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
