[PATCH v6 10/16] OMAP2+: UART: Modify omap_uart_can_sleep function

[Govindraj]

On Thu, Oct 13, 2011 at 1:11 AM, Kevin Hilman <khilman at ti.com> wrote:
> Govindraj <govindraj.ti at gmail.com> writes:
>
>> On Tue, Oct 11, 2011 at 11:54 PM, Kevin Hilman <khilman at ti.com> wrote:
>>> "Govindraj.R" <govindraj.raja at ti.com> writes:
>>>
>>>> Modify the omap_uart_can_sleep function to check uart is active
>>>> or not to be used by pm code to enter low power states.
>>>
>>> Doesn't the driver now control when the UART clocks are gated (using
>>> runtime PM autosuspend)?
>>>
>>> IMO, this check should be completely removed and the driver should
>>> be managing this with the autosuspend timeout.
>>>
>>>> Removing this check can cause console response little sluggish.
>>>
>>> Sluggish in what way?
>>>
>>
>> response is slower like when we type something or cat debugfs/pm_count
>> see things little slower on console, there is no character loss.
>>
>> Happens even though we have not set the autosuspend timeout and uart
>> clocks are active, which basically means allowing mpu to enter
>> retention keeping uart active.
>
> OK, I see now.
>
>> this delay in response or sluggishness is not there on my 3430SDP or
>> 3630zoom board but I was able to see this behavior on a beagle
>> board(xm rev c).
>
> Here's why:
>
> The difference is the powerdomain that the console UART is on for these
> boards.  UART1,2 are in CORE, UART2/3 are in PER.   SDP uses UART1 (CORE),
> Zoom3 doesn't use OMAP UARTs at all, and Beagle uses UART3 (PER).
>
> Due to a HW sleepdep between MPU and CORE, MPU will not transition until
> CORE does, which means MPU will not transition until UART 1 & 2 are
> idle.
>
> On Beagle, the console is ttyO2 (UART3) which is in PER, and since the
> MPU is free to transition independently of PER, that is what is
> happening, resulting in slower response time on for any boards that have
> PER-UART consoles.
>
>> retaining this uart_can_sleep check in omap3_can_sleep ensures a better
>> console user experience. (not allowing mpu to enter retention
>> until uart clocks are cut)
>
> Yes, but obviously comes at the expense of power savings.  IOW, This is
> a hard-coded power vs. performance trade off that we are trying to get
> away from.
>
> So, the root of the problem is that the MPU wakeup latency is causing a
> "sluggish" console.  The solution?  request an MPU wakeup latency
> constraint.
>

Okay, Will explore this.

> This is a classic use-case for such a constraint, and the serial driver
> should have the option of requesting a constraint to prevent the sluggish
> console.  The constraint only needs to be held until the auto-suspend
> delay expires, so should be relased in the ->runtime_suspend() method of
> the driver.
>
> This constraint needs to be configurable, probably from the board file,
> so that it is optional, and so users who don't care about sluggish
> consoles (or non-console UART users who don't care about response time)
> have the option of preferring power savings over UART responsiveness.
>
> As a reference, the i2c driver is currently doing something similar
> in that it request an MPU constraint to prevent the MPU from going into
> retention/off while waiting for an i2c interrupt to arrive.
>

Thanks, will check and try to use the mpu constraints

--
Govindraj.R.