From patchwork Mon Mar 26 09:14:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 10307477 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 70E1060212 for ; Mon, 26 Mar 2018 09:14:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 64564295E1 for ; Mon, 26 Mar 2018 09:14:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 581FF295E3; Mon, 26 Mar 2018 09:14:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A8DB2295E1 for ; Mon, 26 Mar 2018 09:14:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751115AbeCZJON (ORCPT ); Mon, 26 Mar 2018 05:14:13 -0400 Received: from mail-qk0-f174.google.com ([209.85.220.174]:35932 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751042AbeCZJOL (ORCPT ); Mon, 26 Mar 2018 05:14:11 -0400 Received: by mail-qk0-f174.google.com with SMTP id o205so7694769qke.3; Mon, 26 Mar 2018 02:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2em0Xr2ym8s3NlZB3WQzZIO/w9+oRhh22nMj4PI+NUI=; b=RnTWr5iPmaS3bI1p6MBExY+7f+mTHFL0tmm5uzUhk0308IlhqmMTF+wlQDFdnhPiZ+ CMi3zizpEUoain7Q1bttEp2b5gPLGhivstk1d99KA0qXv9OsrbRBCUiOi0otO8GloDEn iq/xBp2Kh7oei/4dX/+XGNmRMBzSjZfr87mKdn6gOFQROfCsBPjVbjp96Jskv9+LhiVb zFt/3mdiCaKARCwuN9BQ/SO5pi4DPsrPIdFrw9f0KoTtOm6QK7fVFRsdrhLDSiCByYIn N2waBqFO1k9/FpSUKVbDDSXaIweGUUDCDPUDvuEWJRiS9SqsxTIndT8zYgmpFiS+r4Da cawg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2em0Xr2ym8s3NlZB3WQzZIO/w9+oRhh22nMj4PI+NUI=; b=KR9BBhedOT9kl1WJMO3o3joXOMHFstvrsBEfo6xzObpQGl3pPiI1bb44sZ552+7ecl jQaw8l/z62f/R6pRYyzV78HseJ7re64lMarYYHCBZRf8VB6xbhRpaflwGtWzVbUHyvBa OdPsrGp6MZC9xbky1HpIRy3T/oJoILnKMXXD0SWvDxBBzzJNB5ZFHsQ/bcAFZAN6/Gtz 2IE+dKhk2XM7ob1enhDiaZIv947cKLtDX6ugGfcnWvffSFPgwvFcTNekmBHyrrZyULqK A0btf08p2XRW5LASGWNb8fnBQooze1Y2/GCDyq/cVPWHNvNWPhxgeYMmhssahg7+upDl v32g== X-Gm-Message-State: AElRT7HA33Yychm2YkEPuOTioo4Xygd75tC1n3LlUFvHLpV7h7ZyOieB KnC/1nlJU8JiC7ZtNxUAhdzTGUTr2hpj62rTuU0= X-Google-Smtp-Source: AG47ELtI5JlxH+UEL3N32z7oj1xQJETzwHXdtnvDa97VXZad4HQ+WsHfexgfOJyXV7+b6uhH5r97PmRSQCFWetc2gV8= X-Received: by 10.55.195.148 with SMTP id r20mr54047970qkl.173.1522055650247; Mon, 26 Mar 2018 02:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.25 with HTTP; Mon, 26 Mar 2018 02:14:09 -0700 (PDT) In-Reply-To: <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> From: Arnd Bergmann Date: Mon, 26 Mar 2018 11:14:09 +0200 X-Google-Sender-Auth: ZO0ihEx53AWDXHK9rAGjoD1BUmU Message-ID: Subject: =?UTF-8?B?UmU6IOetlOWkjTogW1BBVENIIHY4IDIvNV0gZHQtYmluZGluZ3M6IHNjc2k6IHVmczogYQ==?= =?UTF-8?B?ZGQgZG9jdW1lbnQgZm9yIGhpc2ktdWZz?= To: "liwei (CM)" Cc: Rob Herring , Mark Rutland , "xuwei (O)" , Catalin Marinas , Will Deacon , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" , Kevin Hilman , Gregory CLEMENT , Thomas Petazzoni , Masahiro Yamada , Riku Voipio , Thierry Reding , Krzysztof Kozlowski , Eric Anholt , DTML , Linux Kernel Mailing List , Linux ARM , linux-scsi , zangleigang , Gengjianfeng , Guodong Xu , Zhangfei Gao , "Fengbaopeng (kevin, Kirin Solution Dept)" , Yaniv Gardi Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Mar 23, 2018 at 3:22 AM, liwei (CM) wrote: >> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt >> b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt >> new file mode 100644 >> index 000000000000..0d21b57496cf >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt >> @@ -0,0 +1,37 @@ >> +* Hisilicon Universal Flash Storage (UFS) Host Controller >> + >> +UFS nodes are defined to describe on-chip UFS hardware macro. >> +Each UFS Host Controller should have its own node. >> + >> +Required properties: >> +- compatible : compatible list, contains one of the following - >> + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs >> + host controller present on Hi36xx chipset. >> +- reg : should contain UFS register address space & UFS SYS CTRL register address, >> +- interrupt-parent : interrupt device >> +- interrupts : interrupt number >> +- clocks : List of phandle and clock specifier pairs >> +- clock-names : List of clock input name strings sorted in the same >> + order as the clocks property. >> +"ref_clk", "phy_clk" is optional > > The clock names sound generic enough, should we have both in the generic binding? > > Do you mean that add a "phy_clk" to ufshcd-pltfrm 's bindings? > At present, it seems that in the implementation of generic code, apart from "ref_clk" may have special processing, other clk will not have special processing and simply parse and enable; > Referring to ufs-qcom binding, I think "phy_clk" can be named "iface_clk", this "iface_clk" exists in ufshcd-pltfrm bindings;If so, "ref_clk", "iface_clk" are both in the generic binding,we will remove them here. Is that okay? I'm looking at the generic binding again, and it seems we never quite managed to fix some minor problems with it. See below for a possible way to clarify it. >> +- resets : reset node register, one reset the clk and the other reset the controller >> +- reset-names : describe reset node register > > This looks incomplete. What is the name of the reset line supposed to be? > I'd also suggest you document it in the ufshcd binding instead. > > The "rst" corresponds to reset the whole UFS IP, and " arst " only reset the APB/AXI bus. Discussed with our soc colleagues that "arst" is assert by default and needs to deassert . > But I think it may be difficult to add this to common code, or it may not be necessary; > Other manufacturers may not need to do this soc init because they probably already done in the bootloader phase. Even if they need to do it, it's probably different from us. > We need to make sure that our ufs works even if not do soc init during the bootloader phase. In the suggested patch below, I have documented one "rst" line that is used to reset the ufshcd device. The second reset line as I understand now is used in a rather nonstandard way and gets asserted only while setting up the additional registers for your glue logic, so that one seems better left documented in your own binding. I've added a "jedec,ufshci-3.0" compatible string, which appears to be the latest version of the ufshci itself, and I've documented four clocks that are already used by the qualcomm variant of the platform device. Please have a look at the below, and see if we need additional changes or clarifications. With this, most of your binding can get folded into the common document, so you just need to explain the private compatible string, the larger register area, and the additional reset line. Arnd commit a945e9bc823521253c9ff5a061f22a2aa7fd335e Author: Arnd Bergmann Date: Mon Mar 26 11:07:46 2018 +0200 ufshcd: clarify some parts of the documentation Signed-off-by: Arnd Bergmann "qcom,ufshc" @@ -32,7 +34,20 @@ Optional properties: - clocks : List of phandle and clock specifier pairs - clock-names : List of clock input name strings sorted in the same - order as the clocks property. + order as the clocks property. Standard clocks include: + "core_clk" : The clock associated with the ufshcd IP block + "ref_clk" : The reference clock for the external interface to the device, + typically operating at 19.2 MHz. + "iface_clk" : The clock for the CPU-side interface to the ufshcd memory + mapped registers + "bus_clk" : The interface clock for bus master data transfers on to + main memory. + +- resets : List of specifiers of associated reset lines +- reset-names : An idenfifier for each reset line. The name "rst" should + be used for the line that resets the ufshci block during + startup. + - freq-table-hz : Array of operating frequencies stored in the same order as the clocks property. If this property is not defined or a value in the array is "0" then it is assumed @@ -63,6 +78,8 @@ Example: clocks = <&core 0>, <&ref 0>, <&iface 0>; clock-names = "core_clk", "ref_clk", "iface_clk"; + resets = <&reset 0 1>; + reset-names = "rst"; freq-table-hz = <100000000 200000000>, <0 0>, <0 0>; phys = <&ufsphy1>; phy-names = "ufsphy"; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index c39dfef76a18..bc90a7d8385b 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -4,8 +4,10 @@ UFSHC nodes are defined to describe on-chip UFS host controllers. Each UFS controller instance should have its own node. Required properties: -- compatible : must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may - also list one or more of the following: +- compatible : must contain "jedec,ufs-1.1", "jedec,ufs-2.0", + or "jedec,ufshci-3.0", and may also list one + or more of the following, as well as others + specified in derived bindings: "qcom,msm8994-ufshc" "qcom,msm8996-ufshc"