From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752103AbcGMDkh (ORCPT ); Tue, 12 Jul 2016 23:40:37 -0400 Received: from regular1.263xmail.com ([211.150.99.138]:40761 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750923AbcGMDk3 (ORCPT ); Tue, 12 Jul 2016 23:40:29 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: william.wu@rock-chips.com X-FST-TO: devicetree@vger.kernel.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: william.wu@rock-chips.com X-UNIQUE-TAG: <41ddfbcfa7226fe78cd98d7456b05a7c> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk To: Rob Herring , Heiko Stuebner References: <1467860066-15142-1-git-send-email-william.wu@rock-chips.com> <1467860066-15142-4-git-send-email-william.wu@rock-chips.com> <2213342.0Nx5tnEW8p@phil> <20160711145447.GA16636@rob-hp-laptop> Cc: gregkh@linuxfoundation.org, balbi@kernel.org, linux-rockchip@lists.infradead.org, briannorris@google.com, dianders@google.com, kever.yang@rock-chips.com, huangtao@rock-chips.com, frank.wang@rock-chips.com, eddie.cai@rock-chips.com, John.Youn@synopsys.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, sergei.shtylyov@cogentembedded.com, mark.rutland@arm.com, devicetree@vger.kernel.org From: "William.wu" Message-ID: <77a15788-a460-7f59-cb52-88ce012f9eca@rock-chips.com> Date: Wed, 13 Jul 2016 11:39:16 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160711145447.GA16636@rob-hp-laptop> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Rob, On 2016/7/11 22:54, Rob Herring wrote: > On Fri, Jul 08, 2016 at 02:33:09PM +0200, Heiko Stuebner wrote: >> Hi William, >> >> Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu: >>> Add a quirk to configure the core to support the >>> UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY >>> interface is hardware property, and it's platform >>> dependent. Normall, the PHYIf can be configured >>> during coreconsultant. But for some specific usb >>> cores(e.g. rk3399 soc dwc3), the default PHYIf >>> configuration value is fault, so we need to >>> reconfigure it by software. >>> >>> And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM >>> must be set to the corresponding value according to >>> the UTMI+ PHY interface. >>> >>> Signed-off-by: William Wu >>> --- >> [...] >>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt >>> b/Documentation/devicetree/bindings/usb/dwc3.txt index 020b0e9..8d7317d >>> 100644 >>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt >>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt >>> @@ -42,6 +42,10 @@ Optional properties: >>> - snps,dis-u2-freeclk-exists-quirk: when set, clear the >>> u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't provide >>> a free-running PHY clock. >>> + - snps,phyif-utmi-quirk: when set core will set phyif UTMI+ interface. >>> + - snps,phyif-utmi: the value to configure the core to support a UTMI+ >>> PHY + with an 8- or 16-bit interface. Value 0 select 8-bit >>> + interface, value 1 select 16-bit interface. >> maybe >> snps,phyif-utmi-width = <8> or <16>; > Seems like this could be common. Any other bindings have something > similar already? If not "utmi-width" is fine. It seems that there's not any dwc3 binding similar to this. So I prefer to use “utmi-width”. :-) > >> devicetree is about describing the hardware, not the things that get written >> to registers :-) . The conversion from the described width to the register >> value can easily be done in the driver. >> >> >> Also I don't think you need two properties for this. If the snps,phyif-utmi >> property is specified it indicates that you want to manually set the width >> and if it is absent you want to use the IC default. All functions reading >> property-values indicate if the property is missing. > Agreed. > > Rob > > >