diff for duplicates of <1570410.dThJclhmJd@diego> diff --git a/a/1.txt b/N1/1.txt index 22d9647..e9a1b37 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,25 +1,22 @@ Hi Frank, Am Freitag, 5. August 2016, 16:34:42 schrieb Frank Wang: -> On 2016/8/5 3:10, Heiko St=FCbner wrote: +> On 2016/8/5 3:10, Heiko Stübner wrote: > > Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng: > >> Export these source clocks for usbphy. -> >>=20 +> >> > >> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> -> >=20 -> > can you please provide a rationale why you need manual control over= - that +> > +> > can you please provide a rationale why you need manual control over that > > intermediate clock? ->=20 -> Well, From below graph, you can see that 'clk_usbphyX_480m' is genera= -ted +> +> Well, From below graph, you can see that 'clk_usbphyX_480m' is generated > from usb2phy, and 'clk_usbphy_480m' which select from -> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to oth= -er +> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to other > modules. ->=20 +> > xin24m ->=20 +> > |__ clk_usb2phy0_ref > | > | |__ clk_usbphy0_480m @@ -35,61 +32,46 @@ er > |__ clk_usbphy1_480m > | > |__clk_usbphy1_480m_src -> >=20 -> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate = -the +> > +> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate the > > 480m > > clocks, but do not seem to need the clk_usbphyX_480m_src gates. ->=20 +> > Yeah, they used to be. However, the story went something like this, ->=20 -> Some PM suspend process related ehci/ohci controller are base on 480m= - +> +> Some PM suspend process related ehci/ohci controller are base on 480m > clocks, unfortunately, usb2-phy suspended earlier than ehci/ohci > (usb2-phy will be auto suspended if no devices plug-in), and the -> clk-480m provided by it was disabled if no module used. As a result, = -the +> clk-480m provided by it was disabled if no module used. As a result, the > PM suspend process was blocked when it run into ehci/ohci module. -ah, so the ehci controller needs that 480m clock as well? Do you happen= - to=20 -have example patches for the ehci/ohci side already? I'd like to peak a= -t what=20 +ah, so the ehci controller needs that 480m clock as well? Do you happen to +have example patches for the ehci/ohci side already? I'd like to peak at what you mean with "some PM suspend process related" things. -Depending on what is actually needed, you could also pull the usbphy ou= -t of=20 -autosuspend in a pm-prepare callback of the phy driver itself ... see=20= - +Depending on what is actually needed, you could also pull the usbphy out of +autosuspend in a pm-prepare callback of the phy driver itself ... see http://lxr.free-electrons.com/source/include/linux/pm.h#L86 -Like=20 +Like - in the .prepare callback make sure to unsuspend the phy and deactivate the autosuspend -- ehci/ohci will poweroff the phy in it s suspend callback (already doe= -s that) +- ehci/ohci will poweroff the phy in it s suspend callback (already does that) - suspend -> resume - ehci/ohci will poweron the phy -- in the phy's .complete callback you can reactivate the autosuspend ti= -mer +- in the phy's .complete callback you can reactivate the autosuspend timer -Because it looks more like you actually need the phy and not the clock = -alone. -So it would be nicer to use mechanisms already in place instead of crea= -ting=20 +Because it looks more like you actually need the phy and not the clock alone. +So it would be nicer to use mechanisms already in place instead of creating new dependencies. -> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/oh= -ci -> driver. Maybe you will challenge why not refer clk_usbphy_480m direct= -ly? -> because there are two ehci/ohci connected in the different usb2phy, a= -nd +> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/ohci +> driver. Maybe you will challenge why not refer clk_usbphy_480m directly? +> because there are two ehci/ohci connected in the different usb2phy, and > only one clk_usbphy_480m clock was selected in clock tree. -Nope, no argument from me as I fully understand that each phy provides = -its own=20 +Nope, no argument from me as I fully understand that each phy provides its own 480m clock :-) . diff --git a/a/content_digest b/N1/content_digest index 1977231..ebc6e6d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -23,25 +23,22 @@ "Hi Frank,\n" "\n" "Am Freitag, 5. August 2016, 16:34:42 schrieb Frank Wang:\n" - "> On 2016/8/5 3:10, Heiko St=FCbner wrote:\n" + "> On 2016/8/5 3:10, Heiko St\303\274bner wrote:\n" "> > Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng:\n" "> >> Export these source clocks for usbphy.\n" - "> >>=20\n" + "> >> \n" "> >> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>\n" - "> >=20\n" - "> > can you please provide a rationale why you need manual control over=\n" - " that\n" + "> > \n" + "> > can you please provide a rationale why you need manual control over that\n" "> > intermediate clock?\n" - ">=20\n" - "> Well, From below graph, you can see that 'clk_usbphyX_480m' is genera=\n" - "ted\n" + "> \n" + "> Well, From below graph, you can see that 'clk_usbphyX_480m' is generated\n" "> from usb2phy, and 'clk_usbphy_480m' which select from\n" - "> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to oth=\n" - "er\n" + "> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to other\n" "> modules.\n" - ">=20\n" + "> \n" "> xin24m\n" - ">=20\n" + "> \n" "> |__ clk_usb2phy0_ref\n" "> |\n" "> | |__ clk_usbphy0_480m\n" @@ -57,64 +54,49 @@ "> |__ clk_usbphy1_480m\n" "> |\n" "> |__clk_usbphy1_480m_src\n" - "> >=20\n" - "> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate =\n" - "the\n" + "> > \n" + "> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate the\n" "> > 480m\n" "> > clocks, but do not seem to need the clk_usbphyX_480m_src gates.\n" - ">=20\n" + "> \n" "> Yeah, they used to be. However, the story went something like this,\n" - ">=20\n" - "> Some PM suspend process related ehci/ohci controller are base on 480m=\n" - "\n" + "> \n" + "> Some PM suspend process related ehci/ohci controller are base on 480m\n" "> clocks, unfortunately, usb2-phy suspended earlier than ehci/ohci\n" "> (usb2-phy will be auto suspended if no devices plug-in), and the\n" - "> clk-480m provided by it was disabled if no module used. As a result, =\n" - "the\n" + "> clk-480m provided by it was disabled if no module used. As a result, the\n" "> PM suspend process was blocked when it run into ehci/ohci module.\n" "\n" - "ah, so the ehci controller needs that 480m clock as well? Do you happen=\n" - " to=20\n" - "have example patches for the ehci/ohci side already? I'd like to peak a=\n" - "t what=20\n" + "ah, so the ehci controller needs that 480m clock as well? Do you happen to \n" + "have example patches for the ehci/ohci side already? I'd like to peak at what \n" "you mean with \"some PM suspend process related\" things.\n" "\n" - "Depending on what is actually needed, you could also pull the usbphy ou=\n" - "t of=20\n" - "autosuspend in a pm-prepare callback of the phy driver itself ... see=20=\n" - "\n" + "Depending on what is actually needed, you could also pull the usbphy out of \n" + "autosuspend in a pm-prepare callback of the phy driver itself ... see \n" "http://lxr.free-electrons.com/source/include/linux/pm.h#L86\n" "\n" - "Like=20\n" + "Like \n" "- in the .prepare callback make sure to unsuspend the phy\n" " and deactivate the autosuspend\n" - "- ehci/ohci will poweroff the phy in it s suspend callback (already doe=\n" - "s that)\n" + "- ehci/ohci will poweroff the phy in it s suspend callback (already does that)\n" "- suspend -> resume\n" "- ehci/ohci will poweron the phy\n" - "- in the phy's .complete callback you can reactivate the autosuspend ti=\n" - "mer\n" + "- in the phy's .complete callback you can reactivate the autosuspend timer\n" "\n" - "Because it looks more like you actually need the phy and not the clock =\n" - "alone.\n" - "So it would be nicer to use mechanisms already in place instead of crea=\n" - "ting=20\n" + "Because it looks more like you actually need the phy and not the clock alone.\n" + "So it would be nicer to use mechanisms already in place instead of creating \n" "new dependencies.\n" "\n" "\n" - "> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/oh=\n" - "ci\n" - "> driver. Maybe you will challenge why not refer clk_usbphy_480m direct=\n" - "ly?\n" - "> because there are two ehci/ohci connected in the different usb2phy, a=\n" - "nd\n" + "> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/ohci\n" + "> driver. Maybe you will challenge why not refer clk_usbphy_480m directly?\n" + "> because there are two ehci/ohci connected in the different usb2phy, and\n" "> only one clk_usbphy_480m clock was selected in clock tree.\n" "\n" - "Nope, no argument from me as I fully understand that each phy provides =\n" - "its own=20\n" + "Nope, no argument from me as I fully understand that each phy provides its own \n" "480m clock :-) .\n" "\n" "\n" Heiko -041313800a42e5e7148ef3ed543e4267dd625ff61122301d94b63c6af5731c20 +40b6b7b82cbbd30ce601c4fadb79ba5d30c578c2dbf9a98e6aa1c95d5574e100
diff --git a/a/1.txt b/N2/1.txt index 22d9647..b04f184 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,25 +1,22 @@ Hi Frank, Am Freitag, 5. August 2016, 16:34:42 schrieb Frank Wang: -> On 2016/8/5 3:10, Heiko St=FCbner wrote: +> On 2016/8/5 3:10, Heiko St?bner wrote: > > Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng: > >> Export these source clocks for usbphy. -> >>=20 +> >> > >> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> -> >=20 -> > can you please provide a rationale why you need manual control over= - that +> > +> > can you please provide a rationale why you need manual control over that > > intermediate clock? ->=20 -> Well, From below graph, you can see that 'clk_usbphyX_480m' is genera= -ted +> +> Well, From below graph, you can see that 'clk_usbphyX_480m' is generated > from usb2phy, and 'clk_usbphy_480m' which select from -> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to oth= -er +> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to other > modules. ->=20 +> > xin24m ->=20 +> > |__ clk_usb2phy0_ref > | > | |__ clk_usbphy0_480m @@ -35,61 +32,46 @@ er > |__ clk_usbphy1_480m > | > |__clk_usbphy1_480m_src -> >=20 -> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate = -the +> > +> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate the > > 480m > > clocks, but do not seem to need the clk_usbphyX_480m_src gates. ->=20 +> > Yeah, they used to be. However, the story went something like this, ->=20 -> Some PM suspend process related ehci/ohci controller are base on 480m= - +> +> Some PM suspend process related ehci/ohci controller are base on 480m > clocks, unfortunately, usb2-phy suspended earlier than ehci/ohci > (usb2-phy will be auto suspended if no devices plug-in), and the -> clk-480m provided by it was disabled if no module used. As a result, = -the +> clk-480m provided by it was disabled if no module used. As a result, the > PM suspend process was blocked when it run into ehci/ohci module. -ah, so the ehci controller needs that 480m clock as well? Do you happen= - to=20 -have example patches for the ehci/ohci side already? I'd like to peak a= -t what=20 +ah, so the ehci controller needs that 480m clock as well? Do you happen to +have example patches for the ehci/ohci side already? I'd like to peak at what you mean with "some PM suspend process related" things. -Depending on what is actually needed, you could also pull the usbphy ou= -t of=20 -autosuspend in a pm-prepare callback of the phy driver itself ... see=20= - +Depending on what is actually needed, you could also pull the usbphy out of +autosuspend in a pm-prepare callback of the phy driver itself ... see http://lxr.free-electrons.com/source/include/linux/pm.h#L86 -Like=20 +Like - in the .prepare callback make sure to unsuspend the phy and deactivate the autosuspend -- ehci/ohci will poweroff the phy in it s suspend callback (already doe= -s that) +- ehci/ohci will poweroff the phy in it s suspend callback (already does that) - suspend -> resume - ehci/ohci will poweron the phy -- in the phy's .complete callback you can reactivate the autosuspend ti= -mer +- in the phy's .complete callback you can reactivate the autosuspend timer -Because it looks more like you actually need the phy and not the clock = -alone. -So it would be nicer to use mechanisms already in place instead of crea= -ting=20 +Because it looks more like you actually need the phy and not the clock alone. +So it would be nicer to use mechanisms already in place instead of creating new dependencies. -> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/oh= -ci -> driver. Maybe you will challenge why not refer clk_usbphy_480m direct= -ly? -> because there are two ehci/ohci connected in the different usb2phy, a= -nd +> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/ohci +> driver. Maybe you will challenge why not refer clk_usbphy_480m directly? +> because there are two ehci/ohci connected in the different usb2phy, and > only one clk_usbphy_480m clock was selected in clock tree. -Nope, no argument from me as I fully understand that each phy provides = -its own=20 +Nope, no argument from me as I fully understand that each phy provides its own 480m clock :-) . diff --git a/a/content_digest b/N2/content_digest index 1977231..7fe5ddb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,47 +1,31 @@ "ref\01470122401-31934-1-git-send-email-zhengxing@rock-chips.com\0" "ref\01918977.W0kRfKbZsD@diego\0" "ref\0cba79ba6-7f41-5398-389c-7fd3fe5e0089@rock-chips.com\0" - "From\0Heiko St\303\274bner <heiko@sntech.de>\0" - "Subject\0Re: [PATCH v3 2/7] clk: rockchip: rk3399: export 480M_SRC clock id for usbphy0/usbphy1\0" + "From\0heiko@sntech.de (Heiko St\303\274bner)\0" + "Subject\0[PATCH v3 2/7] clk: rockchip: rk3399: export 480M_SRC clock id for usbphy0/usbphy1\0" "Date\0Fri, 05 Aug 2016 18:05:51 +0200\0" - "To\0Frank Wang <frank.wang@rock-chips.com>\0" - "Cc\0Xing Zheng <zhengxing@rock-chips.com>" - linux-rockchip@lists.infradead.org - dianders@chromium.org - briannorris@chromium.org - huangtao@rock-chips.com - zhangqing@rock-chips.com - wulf@rock-chips.com - Michael Turquette <mturquette@baylibre.com> - Stephen Boyd <sboyd@codeaurora.org> - linux-clk@vger.kernel.org - linux-arm-kernel@lists.infradead.org - linux-kernel@vger.kernel.org - " daniel.meng@rock-chips.com\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Frank,\n" "\n" "Am Freitag, 5. August 2016, 16:34:42 schrieb Frank Wang:\n" - "> On 2016/8/5 3:10, Heiko St=FCbner wrote:\n" + "> On 2016/8/5 3:10, Heiko St?bner wrote:\n" "> > Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng:\n" "> >> Export these source clocks for usbphy.\n" - "> >>=20\n" + "> >> \n" "> >> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>\n" - "> >=20\n" - "> > can you please provide a rationale why you need manual control over=\n" - " that\n" + "> > \n" + "> > can you please provide a rationale why you need manual control over that\n" "> > intermediate clock?\n" - ">=20\n" - "> Well, From below graph, you can see that 'clk_usbphyX_480m' is genera=\n" - "ted\n" + "> \n" + "> Well, From below graph, you can see that 'clk_usbphyX_480m' is generated\n" "> from usb2phy, and 'clk_usbphy_480m' which select from\n" - "> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to oth=\n" - "er\n" + "> clk_usbphyX_480m_src via a gate (G13[12]) provided 480M clock to other\n" "> modules.\n" - ">=20\n" + "> \n" "> xin24m\n" - ">=20\n" + "> \n" "> |__ clk_usb2phy0_ref\n" "> |\n" "> | |__ clk_usbphy0_480m\n" @@ -57,64 +41,49 @@ "> |__ clk_usbphy1_480m\n" "> |\n" "> |__clk_usbphy1_480m_src\n" - "> >=20\n" - "> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate =\n" - "the\n" + "> > \n" + "> > The two usbphys seem to use the clk_usb2phyX_ref clocks, generate the\n" "> > 480m\n" "> > clocks, but do not seem to need the clk_usbphyX_480m_src gates.\n" - ">=20\n" + "> \n" "> Yeah, they used to be. However, the story went something like this,\n" - ">=20\n" - "> Some PM suspend process related ehci/ohci controller are base on 480m=\n" - "\n" + "> \n" + "> Some PM suspend process related ehci/ohci controller are base on 480m\n" "> clocks, unfortunately, usb2-phy suspended earlier than ehci/ohci\n" "> (usb2-phy will be auto suspended if no devices plug-in), and the\n" - "> clk-480m provided by it was disabled if no module used. As a result, =\n" - "the\n" + "> clk-480m provided by it was disabled if no module used. As a result, the\n" "> PM suspend process was blocked when it run into ehci/ohci module.\n" "\n" - "ah, so the ehci controller needs that 480m clock as well? Do you happen=\n" - " to=20\n" - "have example patches for the ehci/ohci side already? I'd like to peak a=\n" - "t what=20\n" + "ah, so the ehci controller needs that 480m clock as well? Do you happen to \n" + "have example patches for the ehci/ohci side already? I'd like to peak at what \n" "you mean with \"some PM suspend process related\" things.\n" "\n" - "Depending on what is actually needed, you could also pull the usbphy ou=\n" - "t of=20\n" - "autosuspend in a pm-prepare callback of the phy driver itself ... see=20=\n" - "\n" + "Depending on what is actually needed, you could also pull the usbphy out of \n" + "autosuspend in a pm-prepare callback of the phy driver itself ... see \n" "http://lxr.free-electrons.com/source/include/linux/pm.h#L86\n" "\n" - "Like=20\n" + "Like \n" "- in the .prepare callback make sure to unsuspend the phy\n" " and deactivate the autosuspend\n" - "- ehci/ohci will poweroff the phy in it s suspend callback (already doe=\n" - "s that)\n" + "- ehci/ohci will poweroff the phy in it s suspend callback (already does that)\n" "- suspend -> resume\n" "- ehci/ohci will poweron the phy\n" - "- in the phy's .complete callback you can reactivate the autosuspend ti=\n" - "mer\n" + "- in the phy's .complete callback you can reactivate the autosuspend timer\n" "\n" - "Because it looks more like you actually need the phy and not the clock =\n" - "alone.\n" - "So it would be nicer to use mechanisms already in place instead of crea=\n" - "ting=20\n" + "Because it looks more like you actually need the phy and not the clock alone.\n" + "So it would be nicer to use mechanisms already in place instead of creating \n" "new dependencies.\n" "\n" "\n" - "> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/oh=\n" - "ci\n" - "> driver. Maybe you will challenge why not refer clk_usbphy_480m direct=\n" - "ly?\n" - "> because there are two ehci/ohci connected in the different usb2phy, a=\n" - "nd\n" + "> Hence, we are planing to refer clk_usbphyX_480m_src into each ehci/ohci\n" + "> driver. Maybe you will challenge why not refer clk_usbphy_480m directly?\n" + "> because there are two ehci/ohci connected in the different usb2phy, and\n" "> only one clk_usbphy_480m clock was selected in clock tree.\n" "\n" - "Nope, no argument from me as I fully understand that each phy provides =\n" - "its own=20\n" + "Nope, no argument from me as I fully understand that each phy provides its own \n" "480m clock :-) .\n" "\n" "\n" Heiko -041313800a42e5e7148ef3ed543e4267dd625ff61122301d94b63c6af5731c20 +ab8439eb7f7f2f7447c43c2df2a7952f6e9706b5b2833aa59f133014c083d3a6
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.