Hi Grygorii,
On Friday 19 April 2013 05:32 PM, Grygorii Strashko wrote:
On 04/18/2013 10:17 PM, Sourav Poddar wrote:
Hi Kevin,
On Thursday 18 April 2013 11:53 PM, Kevin Hilman wrote:
Hi Sourav,
Sourav Poddar<sourav.poddar@xxxxxx> writes:
Hi,
This patch series contains fixes and cleanups around the issue that
the console UART should not idled on suspend while using
"no_console_suspend"
in bootargs.
The direction of the series is right, thanks for the updated approach.
I had a comple minor comments on specific patches, but the ordering of
the series needs a little tweaking. It should be
- core/driver changes [current 1-3/6 are ok]
- remove usage from mach-omap2/serial.c (currently part of 4/6)
- remove am33x DT usage (current 5/6 is ok)
- remove entirely from omap_device (omap_device part of 4/6 and 6/6
should be combined)
Thanks a lot for your review and comments.
I have replied to your comments on the respective patches.
Will take care of the "ordering" which you mentioned above
in the next version.
Thanks
Sourav
Hi Sourav
I'd like to clarify some points regarding this series:
1) I'm not sure that removing OMAP_DEVICE_NO_IDLE_ON_SUSPEND is fine.
FYI -
review.omapzoom.org/#/q/status:open,n,zI9e21bf4432a537a4ccb217cf9c425b0e4e499ce8
"ASoC: omap-abe: Allow no idle on suspend"
The above "voice call" use case allows Audio playback while system is
in "suspend" state.
In addition HSI and SmartReflex may need to be active after
suspend_noirq stage.
By removing this flag such functionality will be broken (in case of
porting it
on newest Kernel or MainLine).
So, How it can be handled without OMAP_DEVICE_NO_IDLE_ON_SUSPEND?
Yes, if we have other use cases, we need to see if there is any way of
handling it through the
respective drivers.
2) Runtime PM vs System suspend
- The commit 88d26136a "PM: Prevent runtime suspend during system resume"
block pm_runtime_put_xx() while suspending/resuming, so if your UART
will became active
(at least one call to pm_runtime_get_xx()) while system is
suspending it will stay active
until suspend_noirq stage.
- At suspend_noirq stage OMAP device framework will finally (brutally)
disable it to reach
system suspend state (in _od_suspend_noirq).
- At resume_noirq stage OMAP device framework will re-enable device if
it was disabled in
_od_suspend_noirq() to keep device state and Runtime PM in sync.
- In addition, the commit 9f6d8f6 "PM: Move disabling/enabling runtime
PM to late suspend/early resume"
will disable Runtime PM at suspend_late and enable it resume_early
stages.
As, result:
- serial_omap_prepare()/serial_omap_complete() not needed - usually
console is active.
Or you may call pm_runtime_get_xxx() in serial_omap_prepare() to be
sure (that's all)
- removing OMAP_DEVICE_NO_IDLE_ON_SUSPEND will not help, because to
handle your use case
omap_device_idle() need to be removed from od_suspend_noirq().
!! Which, in turn, will kill OMAP suspend !! (see Kevin's comments)
Yes, I have seen kevin's comments and indeed we need to remove
"omap_device_idle"
along with prep/complete to get my issue fixed(which indeed is not correct).
Unfortunately, I see no way to avoid usage
OMAP_DEVICE_NO_IDLE_ON_SUSPEND with the current
OMAP device framework.
Regards,
-grygorii
Kevin
The approach thought of is to modify the serial core/serial driver
to bypass
runtime PM if the UART in contention is a console and we are using
"no_console_suspend"
in our bootargs.
While fixing the above issue, there are other cleanups also done as
part of
this series which are no longer required. This cleanups mainly
include getting
rid of using "omap_device_disable_idle_on_suspend" api for both dt
and non dt case
as the serial driver will be self sufficient to handle the
"no_idle_on_suspend" issue.
Serial was the only one making use of
"omap_device_disable_idle_on_suspend"
Test info (except drivers: serial: mpc52xx_uart: Remove
"uart_console" defintion):
Omap4430sdp:
- Tested wakeup from UART after suspend for dt and non dt case.
Omap5430evm:
- Tested wakeup from UART after suspend for dt case.
There were discussions about how to handle "no_idle_on_suspend"
issue and all the
discussions are as follows:
[v3]: https://lkml.org/lkml/2013/4/5/239
[v2]: https://lkml.org/lkml/2013/4/2/350
[v1]: https://lkml.org/lkml/2013/3/18/199
https://lkml.org/lkml/2013/3/18/295
Due to the amount of change in approach and other cleanups coming
around it, I am posting
this as a new series.
This patches are based on 3.9-rc3 custom tree which has
Santosh Shilimkar serial patch[1]
[1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/95828
Cc: Santosh Shilimkar<santosh.shilimkar@xxxxxx>
Cc: Felipe Balbi<balbi@xxxxxx>
Cc: Rajendra nayak<rnayak@xxxxxx>
Sourav Poddar (6):
drivers: tty: serial: Move "uart_console" def to core header file.
drivers: serial: mpc52xx_uart: Remove "uart_console" defintion
driver: serial: omap: add prepare/complete callback for
"no_console_suspend" case
arm: mach-omap2: remove "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check
arm: dts: am33xx: Remove "ti,no_idle_on_suspend" property.
arm: mach-omap2: Remove "no_console_suspend"
arch/arm/boot/dts/am33xx.dtsi | 1 -
arch/arm/mach-omap2/omap_device.c | 10 +---------
arch/arm/mach-omap2/serial.c | 7 -------
drivers/tty/serial/mpc52xx_uart.c | 10 ----------
drivers/tty/serial/omap-serial.c | 20 ++++++++++++++++++++
drivers/tty/serial/serial_core.c | 6 ------
include/linux/serial_core.h | 6 ++++++
7 files changed, 27 insertions(+), 33 deletions(-)
--
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
--
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
