Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755819AbcLUKpA (ORCPT ); Wed, 21 Dec 2016 05:45:00 -0500 Received: from regular1.263xmail.com ([211.150.99.135]:40816 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbcLUKo5 (ORCPT ); Wed, 21 Dec 2016 05:44:57 -0500 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-RL-SENDER: zhengxing@rock-chips.com X-FST-TO: xing.zheng@rock-chips.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: zhengxing@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399 To: Doug Anderson References: <1481710301-1454-1-git-send-email-zhengxing@rock-chips.com> <991221a4-3962-1bcb-7863-72f5553eba40@rock-chips.com> <2526685.VC5cUs58On@phil> <5853903D.8030605@rock-chips.com> Cc: Heiko Stuebner , Frank Wang , Brian Norris , William wu , Rob Herring , Mark Rutland , Catalin Marinas , Will Deacon , Caesar Wang , Jianqun Xu , Elaine Zhang , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Dmitry Torokhov , Tao Huang , "open list:ARM/Rockchip SoC..." , "daniel.meng" , Kever Yang , =?UTF-8?B?6YOR5YW0?= From: Xing Zheng Message-ID: <9bd49b12-a2cf-c804-ca8e-2d8e39f2a4b9@rock-chips.com> Date: Wed, 21 Dec 2016 18:44:39 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2936 Lines: 93 Hi Heiko, Doug 在 2016年12月17日 01:28, Doug Anderson 写道: > Hi, > > On Thu, Dec 15, 2016 at 10:57 PM, Xing Zheng wrote: >> Hi Heiko, Doug, >> >> On 2016年12月16日 02:18, Heiko Stuebner wrote: >> >> Am Donnerstag, 15. Dezember 2016, 08:34:09 CET schrieb Doug Anderson: >> >> >> I still need to digest all of the things that were added to this >> thread overnight, but nothing I've seen so far indicates that you need >> the post-gated clock. AKA I still think you need to redo your patch >> to replace: >> >> clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, >> <&cru SCLK_USBPHY0_480M_SRC>; >> >> with: >> >> clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, >> <&u2phy0>; >> >> Can you please comment on that? >> >> Also, with the change, the ehci will keep the clock (and thus the phy) >> always >> on. Does the phy-autosuspend even save anything now? >> >> In any case, could we make the clock-names entry sound nicer than >> usbphy0_480m >> please? bindings/usb/atmel-usb.txt calls its UTMI clock simply "usb_clk", >> but >> something like "utmi" should also work. >> While at it you could also fix up the other clock names to something like >> "host" and "arbiter" or so?. >> >> >> Heiko >> >> >> The usbphy related clock tress like this: >> >> >> Actually, at drivers/phy/phy-rockchip-inno-usb2.c, we can only >> enable/disable the master gate via GRF is PHY_PLL, not UTMI_CLK. >> >> And the naming style of the "hclk_host0" keep the name "hclk_host0" on the >> clcok tree diagram: >> >> >> Therefore, could we rename the clock name like this: >> ---- >> for usb_host0_ehci and usb_host0_ohci: >> clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>, >> <&cru SCLK_U2PHY0>; >> clock-names = "hclk_host0", "hclk_host0_arb", >> "sclk_u2phy0"; >> >> for usb_host1_ehci and usb_host1_ohci: >> clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST1_ARB>, >> <&cru SCLK_U2PHY1>; >> clock-names = "hclk_host1", "hclk_host1_arb", >> "sclk_u2phy1"; >> ---- >> >> BTW, the "arb" is an abbreviation for arbiter. > You don't specify what this new "SCLK_U2PHY0" ID is, so it's a little > hard for me to know what you're intending. > > ...however, I still don't see any reason why you can't just use the > solution I proposed. Specifying the clock as "<&u2phy0>" is the > correct thing to do. The input clock to the EHCI driver is exactly > the clock provided by the USB PHY with no gate in between (just as I > said). There is no reason to somehow buffer it by the cru. The cru > doesn't see this clock and has no reason to be involved. > > Note that there were many other comments on this thread besides mine. > Are you planning to address any of them? > > -Doug > > Done, and have resent the patch. Thanks. -- - Xing Zheng