diff for duplicates of <87aa83er84.fsf@ti.com> diff --git a/a/1.txt b/N1/1.txt index ba82e30..a02d906 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -17,7 +17,7 @@ Govindraj <govindraj.ti@gmail.com> writes: >>> 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 +>> 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. >> @@ -28,7 +28,7 @@ Govindraj <govindraj.ti@gmail.com> writes: >>> 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. +>> 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. @@ -43,8 +43,8 @@ Govindraj <govindraj.ti@gmail.com> writes: >>> 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 +>> 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, @@ -63,7 +63,3 @@ Please repost your updated series. The PRCM IRQ chaining series is not yet finalized. Kevin --- -To unsubscribe from this list: send the line "unsubscribe linux-serial" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index a31c328..419b9ec 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,19 +4,10 @@ "ref\04EB8F368.5070603@ti.com\0" "ref\087r51i1kva.fsf@ti.com\0" "ref\0CAAL8m4zLEnQE+BkK4xmLUBkREYOuqjmbBweKS0_qcEYUMo71nQ@mail.gmail.com\0" - "From\0Kevin Hilman <khilman@ti.com>\0" - "Subject\0Re: [PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos\0" + "From\0khilman@ti.com (Kevin Hilman)\0" + "Subject\0[PATCH v7 17/21] OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos\0" "Date\0Thu, 10 Nov 2011 11:02:03 -0800\0" - "To\0Govindraj <govindraj.ti@gmail.com>\0" - "Cc\0Rajendra Nayak <rnayak@ti.com>" - Govindraj.R <govindraj.raja@ti.com> - linux-omap@vger.kernel.org - Tony Lindgren <tony@atomide.com> - Partha Basak <p-basak2@ti.com> - Santosh Shilimkar <santosh.shilimkar@ti.com> - linux-serial@vger.kernel.org - Vishwanath Sripathy <vishwanath.bs@ti.com> - " linux-arm-kernel@lists.infradead.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Govindraj <govindraj.ti@gmail.com> writes:\n" @@ -38,7 +29,7 @@ ">>> Are you referring to the 'autodeps' for omap3 here, because they would\n" ">>> prevent any clock domain from idling as long as MPU or IVA are active,\n" ">>\n" - ">> No, I was thinking of HW sleepdeps. \302\240However, I looked back at the\n" + ">> No, I was thinking of HW sleepdeps. ?However, I looked back at the\n" ">> OMAP3430 TRM and see that MPU does not have a HW sleepdep on CORE like I\n" ">> thought.\n" ">>\n" @@ -49,7 +40,7 @@ ">>> the UART sluggishness, (and not MPU idling), due to higher latency,\n" ">>> which is prevented with an active UART module in CORE, but not in PER.\n" ">>\n" - ">> OK, that indeed makes sense. \302\240Thanks for correcting me.\n" + ">> OK, that indeed makes sense. ?Thanks for correcting me.\n" ">>\n" ">>> So Govind did a small experiment to prevent just CORE idling and let MPU\n" ">>> idle alone and that did not show any sluggishness.\n" @@ -64,8 +55,8 @@ ">>> latency constraints regardless, without thinking of any indirect ways\n" ">>> in which the same requirements would have already been met?\n" ">>\n" - ">> Yes, you're right. \302\240The driver should not need to know which powerdomain\n" - ">> a given UART is in. \302\240It's probably best (and most portable) to have UART\n" + ">> Yes, you're right. ?The driver should not need to know which powerdomain\n" + ">> a given UART is in. ?It's probably best (and most portable) to have UART\n" ">> always express its requirements all the time.\n" ">>\n" ">> Thanks for digging into this,\n" @@ -83,10 +74,6 @@ "\n" "The PRCM IRQ chaining series is not yet finalized.\n" "\n" - "Kevin\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-serial\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + Kevin -c267d7a16300ad46bb92e90a42808cafc28bc496a4c9c9cf86a960a1215c847c +dd26c58f87bdc12389d65491b816d8eca3ab75c32d1530bfef9030541ad7fa53
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.