Hi Kevin, On Wed, Nov 9, 2011 at 12:50 AM, Kevin Hilman <khilman@xxxxxx> wrote: > Rajendra Nayak <rnayak@xxxxxx> 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]. 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? -- Thanks, Govindraj.R [1]: git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime -- 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
