All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Wang <frank.wang@rock-chips.com>
To: "Heiko Stübner" <heiko@sntech.de>,
	"Xing Zheng" <zhengxing@rock-chips.com>
Cc: 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,
	frank.wang@rock-chips.com
Subject: Re: [PATCH v3 2/7] clk: rockchip: rk3399: export 480M_SRC clock id for usbphy0/usbphy1
Date: Fri, 5 Aug 2016 16:34:42 +0800	[thread overview]
Message-ID: <cba79ba6-7f41-5398-389c-7fd3fe5e0089@rock-chips.com> (raw)
In-Reply-To: <1918977.W0kRfKbZsD@diego>

Hi Heiko,

On 2016/8/5 3:10, Heiko Stübner wrote:
> Hi Xing,
>
> Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng:
>> Export these source clocks for usbphy.
>>
>> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> can you please provide a rationale why you need manual control over that
> intermediate clock?

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 other 
modules.

   xin24m
       |__ clk_usb2phy0_ref
       |                 |__ clk_usbphy0_480m
       |                                   |__clk_usbphy0_480m_src
       | |__clk_usbphy_480m
       |         |__ ... ...
       |__ clk_usb2phy1_ref
                          |__ clk_usbphy1_480m
                                          |__clk_usbphy1_480m_src

> 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.

Yeah, they used to be. However, the story went something like this,

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 
PM suspend process was blocked when it run into ehci/ohci module.

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.

BR.
Frank

> The clk_usbphyX_480m_src clocks on the other hand only lead to the
> clk_usbphy_480m mux, so I'd like some explanation on what you want to achieve
> here :-)
>
>
> Thanks
> Heiko
>

WARNING: multiple messages have this Message-ID (diff)
From: Frank Wang <frank.wang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"Xing Zheng" <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	frank.wang-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	Michael Turquette
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	daniel.meng-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v3 2/7] clk: rockchip: rk3399: export 480M_SRC clock id for usbphy0/usbphy1
Date: Fri, 5 Aug 2016 16:34:42 +0800	[thread overview]
Message-ID: <cba79ba6-7f41-5398-389c-7fd3fe5e0089@rock-chips.com> (raw)
In-Reply-To: <1918977.W0kRfKbZsD@diego>

Hi Heiko,

On 2016/8/5 3:10, Heiko Stübner wrote:
> Hi Xing,
>
> Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng:
>> Export these source clocks for usbphy.
>>
>> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> can you please provide a rationale why you need manual control over that
> intermediate clock?

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 other 
modules.

   xin24m
       |__ clk_usb2phy0_ref
       |                 |__ clk_usbphy0_480m
       |                                   |__clk_usbphy0_480m_src
       | |__clk_usbphy_480m
       |         |__ ... ...
       |__ clk_usb2phy1_ref
                          |__ clk_usbphy1_480m
                                          |__clk_usbphy1_480m_src

> 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.

Yeah, they used to be. However, the story went something like this,

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 
PM suspend process was blocked when it run into ehci/ohci module.

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.

BR.
Frank

> The clk_usbphyX_480m_src clocks on the other hand only lead to the
> clk_usbphy_480m mux, so I'd like some explanation on what you want to achieve
> here :-)
>
>
> Thanks
> Heiko
>


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: frank.wang@rock-chips.com (Frank Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/7] clk: rockchip: rk3399: export 480M_SRC clock id for usbphy0/usbphy1
Date: Fri, 5 Aug 2016 16:34:42 +0800	[thread overview]
Message-ID: <cba79ba6-7f41-5398-389c-7fd3fe5e0089@rock-chips.com> (raw)
In-Reply-To: <1918977.W0kRfKbZsD@diego>

Hi Heiko,

On 2016/8/5 3:10, Heiko St?bner wrote:
> Hi Xing,
>
> Am Dienstag, 2. August 2016, 15:19:56 schrieb Xing Zheng:
>> Export these source clocks for usbphy.
>>
>> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> can you please provide a rationale why you need manual control over that
> intermediate clock?

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 other 
modules.

   xin24m
       |__ clk_usb2phy0_ref
       |                 |__ clk_usbphy0_480m
       |                                   |__clk_usbphy0_480m_src
       | |__clk_usbphy_480m
       |         |__ ... ...
       |__ clk_usb2phy1_ref
                          |__ clk_usbphy1_480m
                                          |__clk_usbphy1_480m_src

> 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.

Yeah, they used to be. However, the story went something like this,

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 
PM suspend process was blocked when it run into ehci/ohci module.

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.

BR.
Frank

> The clk_usbphyX_480m_src clocks on the other hand only lead to the
> clk_usbphy_480m mux, so I'd like some explanation on what you want to achieve
> here :-)
>
>
> Thanks
> Heiko
>

  reply	other threads:[~2016-08-05  8:35 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02  7:19 [PATCH v3 0/7] fix and optimize some clock configuration for the RK3399 platfom Xing Zheng
2016-08-02  7:19 ` Xing Zheng
2016-08-02  7:19 ` Xing Zheng
2016-08-02  7:19 ` [PATCH v3 1/7] clk: rockchip: rk3399: export USBPHYx_480M_SRC clock IDs Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-02  7:19 ` [PATCH v3 2/7] clk: rockchip: rk3399: export 480M_SRC clock id for usbphy0/usbphy1 Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-04 19:10   ` Heiko Stübner
2016-08-04 19:10     ` Heiko Stübner
2016-08-05  8:34     ` Frank Wang [this message]
2016-08-05  8:34       ` Frank Wang
2016-08-05  8:34       ` Frank Wang
2016-08-05 16:05       ` Heiko Stübner
2016-08-05 16:05         ` Heiko Stübner
2016-08-05 16:05         ` Heiko Stübner
2016-08-08  9:55         ` Frank Wang
2016-08-08  9:55           ` Frank Wang
2016-08-16  6:34           ` Frank Wang
2016-08-16  6:34             ` Frank Wang
2016-08-02  7:19 ` [PATCH v3 3/7] clk: rockchip: rk3399: fix incorrect GATE bits for {c, g}pll_aclk_perihp_src Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-12 16:30   ` Heiko Stübner
2016-08-12 16:30     ` Heiko Stübner
2016-08-02  7:19 ` [PATCH v3 4/7] clk: rockchip: rk3399: fix incorrect aclk_emmc source gate bits Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-02  7:19   ` Xing Zheng
2016-08-12  8:05   ` Heiko Stübner
2016-08-12  8:05     ` Heiko Stübner
2016-08-12  8:05     ` Heiko Stübner
2016-08-02  7:22 ` [PATCH v3 5/7] clk: rockchip: rk3399: add 65MHz and 106.5MHz clocks for HDMI Xing Zheng
2016-08-02  7:22   ` Xing Zheng
2016-08-02  7:22   ` Xing Zheng
2016-08-04 19:05   ` Heiko Stübner
2016-08-04 19:05     ` Heiko Stübner
2016-08-02  7:22 ` [PATCH v3 6/7] clk: rockchip: rk3399: delete the CLK_IGNORE_UNUSED for aclk_pcie Xing Zheng
2016-08-02  7:22   ` Xing Zheng
2016-08-04 19:06   ` Heiko Stübner
2016-08-04 19:06     ` Heiko Stübner
2016-08-02  7:22 ` [PATCH v3 7/7] clk: rockchip: rk3399: Add support frac mode frequencies Xing Zheng
2016-08-02  7:22   ` Xing Zheng
2016-08-04 19:19   ` Heiko Stübner
2016-08-04 19:19     ` Heiko Stübner
2016-08-05  2:26     ` Xing Zheng
2016-08-05  2:26       ` Xing Zheng
2016-08-05  8:48       ` Heiko Stübner
2016-08-05  8:48         ` Heiko Stübner
2016-08-05  8:48         ` Heiko Stübner
2016-08-05 13:23         ` Xing Zheng
2016-08-05 13:23           ` Xing Zheng
2016-08-05 13:23           ` Xing Zheng
2016-08-05 13:26           ` Heiko Stübner
2016-08-05 13:26             ` Heiko Stübner
2016-08-05 13:26             ` Heiko Stübner

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=cba79ba6-7f41-5398-389c-7fd3fe5e0089@rock-chips.com \
    --to=frank.wang@rock-chips.com \
    --cc=briannorris@chromium.org \
    --cc=daniel.meng@rock-chips.com \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=huangtao@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=wulf@rock-chips.com \
    --cc=zhangqing@rock-chips.com \
    --cc=zhengxing@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.