diff for duplicates of <13378907.1JCOSf8QGs@diego> diff --git a/a/1.txt b/N1/1.txt index e1676ec..a041d3e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,11 +1,11 @@ Hi Stephen, Am Donnerstag, 8. Oktober 2015, 14:58:40 schrieb Stephen Boyd: -> On 10/02, Heiko St=FCbner wrote: +> On 10/02, Heiko Stübner wrote: > > Hi, -> >=20 +> > > > any comment on these 3 patches? ->=20 +> > Dong has a similar problem, but those patches conflate this with > enabling parent clocks during clk_disable_unused() which makes no > sense to me. So I'm ok with the requirement that we turn clocks @@ -14,29 +14,20 @@ Am Donnerstag, 8. Oktober 2015, 14:58:40 schrieb Stephen Boyd: > turn on the parent and/or future parent of the clock during the > rate switch. Care to elaborate on that? -As you can see in the follow-up patches, the fractional dividers on Roc= -kchip=20 -SoCs are quite strange in that they even need to have their _downstream= -_ mux=20 +As you can see in the follow-up patches, the fractional dividers on Rockchip +SoCs are quite strange in that they even need to have their _downstream_ mux point to them to actually accept rate changes. -The register value always reflects the value set by the system, but har= -dware=20 -really only accepts it if the clock is enabled and even the downstream = -mux=20 -selects the fractional divider as parent (they call it a auto-gating fe= -ature). +The register value always reflects the value set by the system, but hardware +really only accepts it if the clock is enabled and even the downstream mux +selects the fractional divider as parent (they call it a auto-gating feature). -So in the worst (and current) case, you end up with the register showin= -g the=20 -right value, but the hardware can use completely different dividers fro= -m the=20 +So in the worst (and current) case, you end up with the register showing the +right value, but the hardware can use completely different dividers from the previous setting. -That strange behaviour got quite deeply investigated between Rockchip a= -nd=20 -Google engineers who stumbled upon this in the first place, so I'm reas= -onably=20 +That strange behaviour got quite deeply investigated between Rockchip and +Google engineers who stumbled upon this in the first place, so I'm reasonably sure this is the right solution for that clock type :-) . diff --git a/a/content_digest b/N1/content_digest index 4986306..d34d331 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,11 +15,11 @@ "Hi Stephen,\n" "\n" "Am Donnerstag, 8. Oktober 2015, 14:58:40 schrieb Stephen Boyd:\n" - "> On 10/02, Heiko St=FCbner wrote:\n" + "> On 10/02, Heiko St\303\274bner wrote:\n" "> > Hi,\n" - "> >=20\n" + "> > \n" "> > any comment on these 3 patches?\n" - ">=20\n" + "> \n" "> Dong has a similar problem, but those patches conflate this with\n" "> enabling parent clocks during clk_disable_unused() which makes no\n" "> sense to me. So I'm ok with the requirement that we turn clocks\n" @@ -28,32 +28,23 @@ "> turn on the parent and/or future parent of the clock during the\n" "> rate switch. Care to elaborate on that?\n" "\n" - "As you can see in the follow-up patches, the fractional dividers on Roc=\n" - "kchip=20\n" - "SoCs are quite strange in that they even need to have their _downstream=\n" - "_ mux=20\n" + "As you can see in the follow-up patches, the fractional dividers on Rockchip \n" + "SoCs are quite strange in that they even need to have their _downstream_ mux \n" "point to them to actually accept rate changes.\n" "\n" - "The register value always reflects the value set by the system, but har=\n" - "dware=20\n" - "really only accepts it if the clock is enabled and even the downstream =\n" - "mux=20\n" - "selects the fractional divider as parent (they call it a auto-gating fe=\n" - "ature).\n" + "The register value always reflects the value set by the system, but hardware \n" + "really only accepts it if the clock is enabled and even the downstream mux \n" + "selects the fractional divider as parent (they call it a auto-gating feature).\n" "\n" - "So in the worst (and current) case, you end up with the register showin=\n" - "g the=20\n" - "right value, but the hardware can use completely different dividers fro=\n" - "m the=20\n" + "So in the worst (and current) case, you end up with the register showing the \n" + "right value, but the hardware can use completely different dividers from the \n" "previous setting.\n" "\n" - "That strange behaviour got quite deeply investigated between Rockchip a=\n" - "nd=20\n" - "Google engineers who stumbled upon this in the first place, so I'm reas=\n" - "onably=20\n" + "That strange behaviour got quite deeply investigated between Rockchip and \n" + "Google engineers who stumbled upon this in the first place, so I'm reasonably \n" "sure this is the right solution for that clock type :-) .\n" "\n" "\n" Heiko -7723070b28bbe925f257c3ffcfe37c4192887ecc71b8d2ed9fac75c1e5559548 +ed095329303dd1e766aa8f819922b8eca67eef0d12af21ba0066258920c29dad
diff --git a/a/1.txt b/N2/1.txt index e1676ec..84b2594 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,11 +1,11 @@ Hi Stephen, Am Donnerstag, 8. Oktober 2015, 14:58:40 schrieb Stephen Boyd: -> On 10/02, Heiko St=FCbner wrote: +> On 10/02, Heiko St?bner wrote: > > Hi, -> >=20 +> > > > any comment on these 3 patches? ->=20 +> > Dong has a similar problem, but those patches conflate this with > enabling parent clocks during clk_disable_unused() which makes no > sense to me. So I'm ok with the requirement that we turn clocks @@ -14,29 +14,20 @@ Am Donnerstag, 8. Oktober 2015, 14:58:40 schrieb Stephen Boyd: > turn on the parent and/or future parent of the clock during the > rate switch. Care to elaborate on that? -As you can see in the follow-up patches, the fractional dividers on Roc= -kchip=20 -SoCs are quite strange in that they even need to have their _downstream= -_ mux=20 +As you can see in the follow-up patches, the fractional dividers on Rockchip +SoCs are quite strange in that they even need to have their _downstream_ mux point to them to actually accept rate changes. -The register value always reflects the value set by the system, but har= -dware=20 -really only accepts it if the clock is enabled and even the downstream = -mux=20 -selects the fractional divider as parent (they call it a auto-gating fe= -ature). +The register value always reflects the value set by the system, but hardware +really only accepts it if the clock is enabled and even the downstream mux +selects the fractional divider as parent (they call it a auto-gating feature). -So in the worst (and current) case, you end up with the register showin= -g the=20 -right value, but the hardware can use completely different dividers fro= -m the=20 +So in the worst (and current) case, you end up with the register showing the +right value, but the hardware can use completely different dividers from the previous setting. -That strange behaviour got quite deeply investigated between Rockchip a= -nd=20 -Google engineers who stumbled upon this in the first place, so I'm reas= -onably=20 +That strange behaviour got quite deeply investigated between Rockchip and +Google engineers who stumbled upon this in the first place, so I'm reasonably sure this is the right solution for that clock type :-) . diff --git a/a/content_digest b/N2/content_digest index 4986306..9aba072 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,25 +1,20 @@ "ref\01929669.AsgMSusdJb@phil\0" "ref\03137165.kmu68gRS44@diego\0" "ref\020151008215840.GJ26883@codeaurora.org\0" - "From\0Heiko St\303\274bner <heiko@sntech.de>\0" - "Subject\0Re: [PATCH 1/3] clk: add flag for clocks that need to be enabled on rate changes\0" + "From\0heiko@sntech.de (Heiko St\303\274bner)\0" + "Subject\0[PATCH 1/3] clk: add flag for clocks that need to be enabled on rate changes\0" "Date\0Sun, 11 Oct 2015 12:41:09 +0200\0" - "To\0Stephen Boyd <sboyd@codeaurora.org>\0" - "Cc\0mturquette@baylibre.com" - linux-clk@vger.kernel.org - linux-arm-kernel@lists.infradead.org - linux-rockchip@lists.infradead.org - " sjoerd.simons@collabora.co.uk\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Stephen,\n" "\n" "Am Donnerstag, 8. Oktober 2015, 14:58:40 schrieb Stephen Boyd:\n" - "> On 10/02, Heiko St=FCbner wrote:\n" + "> On 10/02, Heiko St?bner wrote:\n" "> > Hi,\n" - "> >=20\n" + "> > \n" "> > any comment on these 3 patches?\n" - ">=20\n" + "> \n" "> Dong has a similar problem, but those patches conflate this with\n" "> enabling parent clocks during clk_disable_unused() which makes no\n" "> sense to me. So I'm ok with the requirement that we turn clocks\n" @@ -28,32 +23,23 @@ "> turn on the parent and/or future parent of the clock during the\n" "> rate switch. Care to elaborate on that?\n" "\n" - "As you can see in the follow-up patches, the fractional dividers on Roc=\n" - "kchip=20\n" - "SoCs are quite strange in that they even need to have their _downstream=\n" - "_ mux=20\n" + "As you can see in the follow-up patches, the fractional dividers on Rockchip \n" + "SoCs are quite strange in that they even need to have their _downstream_ mux \n" "point to them to actually accept rate changes.\n" "\n" - "The register value always reflects the value set by the system, but har=\n" - "dware=20\n" - "really only accepts it if the clock is enabled and even the downstream =\n" - "mux=20\n" - "selects the fractional divider as parent (they call it a auto-gating fe=\n" - "ature).\n" + "The register value always reflects the value set by the system, but hardware \n" + "really only accepts it if the clock is enabled and even the downstream mux \n" + "selects the fractional divider as parent (they call it a auto-gating feature).\n" "\n" - "So in the worst (and current) case, you end up with the register showin=\n" - "g the=20\n" - "right value, but the hardware can use completely different dividers fro=\n" - "m the=20\n" + "So in the worst (and current) case, you end up with the register showing the \n" + "right value, but the hardware can use completely different dividers from the \n" "previous setting.\n" "\n" - "That strange behaviour got quite deeply investigated between Rockchip a=\n" - "nd=20\n" - "Google engineers who stumbled upon this in the first place, so I'm reas=\n" - "onably=20\n" + "That strange behaviour got quite deeply investigated between Rockchip and \n" + "Google engineers who stumbled upon this in the first place, so I'm reasonably \n" "sure this is the right solution for that clock type :-) .\n" "\n" "\n" Heiko -7723070b28bbe925f257c3ffcfe37c4192887ecc71b8d2ed9fac75c1e5559548 +95726b1670cc973c9b12771093cc548bdfb6f17bc7af2fbc747fe773eb3f9a74
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.