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: Tue, 08 Nov 2011 11:20:57 -0800 [thread overview]
Message-ID: <87r51i1kva.fsf@ti.com> (raw)
In-Reply-To: <4EB8F368.5070603@ti.com> (Rajendra Nayak's message of "Tue, 08 Nov 2011 14:46:24 +0530")
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,
Kevin
next prev parent reply other threads:[~2011-11-08 19:20 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 [this message]
2011-11-10 12:00 ` Govindraj
2011-11-10 19:02 ` Kevin Hilman
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=87r51i1kva.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