From: khilman@ti•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
Date: Thu, 10 Nov 2011 11:02:03 -0800 [thread overview]
Message-ID: <87aa83er84.fsf@ti.com> (raw)
In-Reply-To: <CAAL8m4zLEnQE+BkK4xmLUBkREYOuqjmbBweKS0_qcEYUMo71nQ@mail.gmail.com> (Govindraj's message of "Thu, 10 Nov 2011 17:30:05 +0530")
Govindraj <govindraj.ti@gmail•com> writes:
> Hi Kevin,
>
> On Wed, Nov 9, 2011 at 12:50 AM, Kevin Hilman <khilman@ti•com> wrote:
>> Rajendra Nayak <rnayak@ti•com> writes:
>>
>>> Hi Kevin,
>>>
>>> On Saturday 05 November 2011 04:12 AM, Kevin Hilman wrote:
>>>> However, as mentioned previously[1], due to a HW sleepdep between MPU
>>>> and CORE, this constraint isn't actually needed for CORE UARTs, so it's
>>>> a bit wasteful to go through all the constraint setting for no reason.
>>>
>>> I had a short chat with Govind on this and was trying to understand
>>> this better.
>>> Are you referring to the 'autodeps' for omap3 here, because they would
>>> prevent any clock domain from idling as long as MPU or IVA are active,
>>
>> No, I was thinking of HW sleepdeps. ?However, I looked back at the
>> OMAP3430 TRM and see that MPU does not have a HW sleepdep on CORE like I
>> thought.
>>
>>> but not the other way round. Which means MPU can still idle, while CORE
>>> does not.
>>>
>>> My guess was, its probably the CORE domain idling itself thats causing
>>> the UART sluggishness, (and not MPU idling), due to higher latency,
>>> which is prevented with an active UART module in CORE, but not in PER.
>>
>> OK, that indeed makes sense. ?Thanks for correcting me.
>>
>>> So Govind did a small experiment to prevent just CORE idling and let MPU
>>> idle alone and that did not show any sluggishness.
>>
>> OK, good.
>>
>>> Now, putting a pm-qos constraint for a UART in CORE still looks
>>> redundant because the latency requirement that UART has is in
>>> some way *indirectly* met (because the active UART in CORE prevents
>>> CORE transitions in idle).
>>> But don't you think the UART driver should express its
>>> latency constraints regardless, without thinking of any indirect ways
>>> in which the same requirements would have already been met?
>>
>> Yes, you're right. ?The driver should not need to know which powerdomain
>> a given UART is in. ?It's probably best (and most portable) to have UART
>> always express its requirements all the time.
>>
>> Thanks for digging into this,
>>
>
> I have fixed this and other uart_v7 comments and have re-based the
> patch series on top
> of 3.2-rc1 along with Tero's v9 irq chaining patches and tested the same.
> Available here [1].
Please repost your updated series.
> Can this patches series be added to a test branch for upstreaming or do you
> think there are still some outstanding comments that needs to be discussed?
The PRCM IRQ chaining series is not yet finalized.
Kevin
next prev parent reply other threads:[~2011-11-10 19:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 15:35 [PATCH v7 15/21] OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART Govindraj.R
2011-10-18 15:35 ` [PATCH v7 16/21] OMAP2+: UART: Remove custom activate funcs and use generic funcs Govindraj.R
2011-11-04 22:00 ` Kevin Hilman
2011-11-07 8:39 ` Govindraj
2011-10-18 15:35 ` [PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos Govindraj.R
2011-11-04 22:42 ` Kevin Hilman
2011-11-08 9:16 ` Rajendra Nayak
2011-11-08 19:20 ` Kevin Hilman
2011-11-10 12:00 ` Govindraj
2011-11-10 19:02 ` Kevin Hilman [this message]
2011-11-11 10:17 ` Govindraj
2011-10-18 15:35 ` [PATCH v7 18/21] OMAP2+: UART: remove temporary variable used to count uart instance Govindraj.R
2011-10-18 15:35 ` [PATCH v7 19/21] OMAP2+: UART: Use custom activate func for console uart Govindraj.R
2011-11-04 23:00 ` Kevin Hilman
2011-11-07 8:42 ` Govindraj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87aa83er84.fsf@ti.com \
--to=khilman@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox