From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751204AbeCZMCJ (ORCPT ); Mon, 26 Mar 2018 08:02:09 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:46510 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751024AbeCZMCH (ORCPT ); Mon, 26 Mar 2018 08:02:07 -0400 From: "liwei (CM)" To: Arnd Bergmann 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" Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogW1BBVENIIHY4IDIvNV0gZHQtYmlu?= =?utf-8?Q?dings:_scsi:_ufs:_add_document_for_hisi-ufs?= Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IFtQQVRDSCB2OCAyLzVdIGR0LWJpbmRpbmdzOiBz?= =?utf-8?Q?csi:_ufs:_add_document_for_hisi-ufs?= Thread-Index: AQHTpLNt7xq76dhVgkeSgBp0Vy2vQaOrAJgAgDJE6ZCABLCUgIAAkqZA//+FzQCAAJJzQA== Date: Mon, 26 Mar 2018 12:01:56 +0000 Message-ID: <1699CE87DE933F49876AD744B5DC140FA587B5@DGGEMM506-MBS.china.huawei.com> References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> <1699CE87DE933F49876AD744B5DC140FA58798@DGGEMM506-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.189.155.72] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id w2QC2HmA029466 Hi, Arnd I'll ask our soc colleagues for help and give a detailed and accurate explanation aosp. Thanks! -----邮件原件----- 发件人: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] 代表 Arnd Bergmann 发送时间: 2018年3月26日 18:42 收件人: liwei (CM) 抄送: 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 主题: Re: 答复: 答复: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs On Mon, Mar 26, 2018 at 12:26 PM, liwei (CM) wrote: > 发件人: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] 代表 Arnd > Bergmann > > 主题: Re: 答复: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for > > hisi-ufs On Fri, Mar 23, 2018 at 3:22 AM, liwei (CM) wrote: > >> 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. > > phy_clk is actually given to the phy. But as previously mentioned , we > do not have a separate phy to configure ; The clks in the patch you > give appear to be unsuitable for describing this . > Here we can't describe phy_clk in the node "ufsphy1: ufsphy@fc597000" like qcom. > So can we put it here in our own binding like this? I think the concept of having a phy clk is generic enough that it's better to have that in the common part, others will surely have the same thing, and in this case, qcom would be the exception that does not use one. There are apparently a couple of things related to the phy that may or may not require a clk: - ref_clk: The reference clock on the mipi bus, this is what qcom have, this would be the 19.2 MHz clock signal. - one clock to drive the logic block for the PHY itself, if it is included within the same logical portion of an SoC as the ufshcd, but uses a separate clock. - Looking at the Android kernel as distributed by google/qualcomm, they have four separate clocks described as PHY to controller symbol synchronization clocks: "rx_lane0_sync_clk" - RX Lane 0 "rx_lane1_sync_clk" - RX Lane 1 "tx_lane0_sync_clk" - TX Lane 0 "tx_lane1_sync_clk" - TX Lane 1 Which of the above would your phy_clk refer to? Arnd [1] https://android.googlesource.com/kernel/msm/+/android-msm-bullhead-3.10-marshmallow-dr/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt?autodive=0%2F%2F%2F%2F%2F From mboxrd@z Thu Jan 1 00:00:00 1970 From: "liwei (CM)" Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogW1BBVENIIHY4IDIvNV0gZHQtYmlu?= =?utf-8?Q?dings:_scsi:_ufs:_add_document_for_hisi-ufs?= Date: Mon, 26 Mar 2018 12:01:56 +0000 Message-ID: <1699CE87DE933F49876AD744B5DC140FA587B5@DGGEMM506-MBS.china.huawei.com> References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> <1699CE87DE933F49876AD744B5DC140FA58798@DGGEMM506-MBS.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: zh-CN Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann 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 List-Id: devicetree@vger.kernel.org SGksIEFybmQNCg0KSSdsbCBhc2sgb3VyIHNvYyBjb2xsZWFndWVzIGZvciBoZWxwIGFuZCBnaXZl IGEgZGV0YWlsZWQgYW5kIGFjY3VyYXRlIGV4cGxhbmF0aW9uIGFvc3AuDQoNClRoYW5rcyENCg0K DQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGFybmRiZXJnbWFubkBnbWFpbC5j b20gW21haWx0bzphcm5kYmVyZ21hbm5AZ21haWwuY29tXSDku6PooaggQXJuZCBCZXJnbWFubg0K 5Y+R6YCB5pe26Ze0OiAyMDE45bm0M+aciDI25pelIDE4OjQyDQrmlLbku7bkuro6IGxpd2VpIChD TSkNCuaKhOmAgTogUm9iIEhlcnJpbmc7IE1hcmsgUnV0bGFuZDsgeHV3ZWkgKE8pOyBDYXRhbGlu IE1hcmluYXM7IFdpbGwgRGVhY29uOyBWaW5heWFrIEhvbGlrYXR0aTsgSmFtZXMgRS5KLiBCb3R0 b21sZXk7IE1hcnRpbiBLLiBQZXRlcnNlbjsgS2V2aW4gSGlsbWFuOyBHcmVnb3J5IENMRU1FTlQ7 IFRob21hcyBQZXRhenpvbmk7IE1hc2FoaXJvIFlhbWFkYTsgUmlrdSBWb2lwaW87IFRoaWVycnkg UmVkaW5nOyBLcnp5c3p0b2YgS296bG93c2tpOyBFcmljIEFuaG9sdDsgRFRNTDsgTGludXggS2Vy bmVsIE1haWxpbmcgTGlzdDsgTGludXggQVJNOyBsaW51eC1zY3NpOyB6YW5nbGVpZ2FuZzsgR2Vu Z2ppYW5mZW5nOyBHdW9kb25nIFh1OyBaaGFuZ2ZlaSBHYW87IEZlbmdiYW9wZW5nIChrZXZpbiwg S2lyaW4gU29sdXRpb24gRGVwdCk7IFlhbml2IEdhcmRpDQrkuLvpopg6IFJlOiDnrZTlpI06IOet lOWkjTogW1BBVENIIHY4IDIvNV0gZHQtYmluZGluZ3M6IHNjc2k6IHVmczogYWRkIGRvY3VtZW50 IGZvciBoaXNpLXVmcw0KDQpPbiBNb24sIE1hciAyNiwgMjAxOCBhdCAxMjoyNiBQTSwgbGl3ZWkg KENNKSA8bGl3ZWkyMTNAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IOWPkeS7tuS6ujogYXJuZGJlcmdt YW5uQGdtYWlsLmNvbSBbbWFpbHRvOmFybmRiZXJnbWFubkBnbWFpbC5jb21dIOS7o+ihqCBBcm5k IA0KPiBCZXJnbWFubg0KPiA+IOS4u+mimDogUmU6IOetlOWkjTogW1BBVENIIHY4IDIvNV0gZHQt YmluZGluZ3M6IHNjc2k6IHVmczogYWRkIGRvY3VtZW50IGZvciANCj4gPiBoaXNpLXVmcyBPbiBG cmksIE1hciAyMywgMjAxOCBhdCAzOjIyIEFNLCBsaXdlaSAoQ00pIDxsaXdlaTIxM0BodWF3ZWku Y29tPiB3cm90ZToNCj4gPj4gVGhlIGNsb2NrIG5hbWVzIHNvdW5kIGdlbmVyaWMgZW5vdWdoLCBz aG91bGQgd2UgaGF2ZSBib3RoIGluIHRoZSBnZW5lcmljIGJpbmRpbmc/DQo+ID4+DQo+ID4+IERv IHlvdSBtZWFuIHRoYXQgYWRkIGEgInBoeV9jbGsiIHRvIHVmc2hjZC1wbHRmcm0gJ3MgYmluZGlu Z3M/DQo+ID4+IEF0IHByZXNlbnQsIGl0IHNlZW1zIHRoYXQgaW4gdGhlIGltcGxlbWVudGF0aW9u IG9mIGdlbmVyaWMgY29kZSwgDQo+ID4+IGFwYXJ0IGZyb20gInJlZl9jbGsiIG1heSBoYXZlIHNw ZWNpYWwgcHJvY2Vzc2luZywgb3RoZXIgY2xrIHdpbGwgDQo+ID4+IG5vdCBoYXZlIHNwZWNpYWwg cHJvY2Vzc2luZyBhbmQgc2ltcGx5IHBhcnNlIGFuZCBlbmFibGU7IFJlZmVycmluZyANCj4gPj4g dG8gdWZzLXFjb20gYmluZGluZywgSSB0aGluayAicGh5X2NsayIgY2FuIGJlIG5hbWVkICJpZmFj ZV9jbGsiLCANCj4gPj4gdGhpcyAiaWZhY2VfY2xrIiBleGlzdHMgaW4gdWZzaGNkLXBsdGZybSBi aW5kaW5ncztJZiBzbywgInJlZl9jbGsiLCAiaWZhY2VfY2xrIiBhcmUgYm90aCBpbiB0aGUgZ2Vu ZXJpYyBiaW5kaW5nLHdlIHdpbGwgcmVtb3ZlIHRoZW0gaGVyZS4gSXMgdGhhdCBva2F5Pw0KPg0K PiA+IEknbSBsb29raW5nIGF0IHRoZSBnZW5lcmljIGJpbmRpbmcgYWdhaW4sIGFuZCBpdCBzZWVt cyB3ZSBuZXZlciANCj4gPiBxdWl0ZSBtYW5hZ2VkIHRvIGZpeCBzb21lIG1pbm9yIHByb2JsZW1z IHdpdGggaXQuIFNlZSBiZWxvdyBmb3IgYSBwb3NzaWJsZSB3YXkgdG8gY2xhcmlmeSBpdC4NCj4N Cj4gcGh5X2NsayBpcyBhY3R1YWxseSBnaXZlbiB0byB0aGUgcGh5LiBCdXQgYXMgcHJldmlvdXNs eSBtZW50aW9uZWQgLCB3ZSANCj4gZG8gbm90IGhhdmUgYSBzZXBhcmF0ZSBwaHkgdG8gY29uZmln dXJlIDsgVGhlIGNsa3MgaW4gdGhlIHBhdGNoIHlvdSANCj4gZ2l2ZSBhcHBlYXIgdG8gYmUgdW5z dWl0YWJsZSBmb3IgZGVzY3JpYmluZyB0aGlzIC4NCj4gSGVyZSB3ZSBjYW4ndCBkZXNjcmliZSBw aHlfY2xrIGluIHRoZSBub2RlICJ1ZnNwaHkxOiB1ZnNwaHlAZmM1OTcwMDAiIGxpa2UgcWNvbS4N Cj4gU28gY2FuIHdlIHB1dCBpdCBoZXJlIGluIG91ciBvd24gYmluZGluZyBsaWtlIHRoaXM/DQoN CkkgdGhpbmsgdGhlIGNvbmNlcHQgb2YgaGF2aW5nIGEgcGh5IGNsayBpcyBnZW5lcmljIGVub3Vn aCB0aGF0IGl0J3MgYmV0dGVyIHRvIGhhdmUgdGhhdCBpbiB0aGUgY29tbW9uIHBhcnQsIG90aGVy cyB3aWxsIHN1cmVseSBoYXZlIHRoZSBzYW1lIHRoaW5nLCBhbmQgaW4gdGhpcyBjYXNlLCBxY29t IHdvdWxkIGJlIHRoZSBleGNlcHRpb24gdGhhdCBkb2VzIG5vdCB1c2Ugb25lLg0KDQpUaGVyZSBh cmUgYXBwYXJlbnRseSBhIGNvdXBsZSBvZiB0aGluZ3MgcmVsYXRlZCB0byB0aGUgcGh5IHRoYXQg bWF5IG9yIG1heSBub3QgcmVxdWlyZSBhIGNsazoNCg0KLSByZWZfY2xrOiBUaGUgcmVmZXJlbmNl IGNsb2NrIG9uIHRoZSBtaXBpIGJ1cywgdGhpcyBpcyB3aGF0IHFjb20gaGF2ZSwgdGhpcyB3b3Vs ZA0KICBiZSB0aGUgMTkuMiBNSHogY2xvY2sgc2lnbmFsLg0KLSBvbmUgY2xvY2sgdG8gZHJpdmUg dGhlIGxvZ2ljIGJsb2NrIGZvciB0aGUgUEhZIGl0c2VsZiwgaWYgaXQgaXMgaW5jbHVkZWQgd2l0 aGluDQogIHRoZSBzYW1lIGxvZ2ljYWwgcG9ydGlvbiBvZiBhbiBTb0MgYXMgdGhlIHVmc2hjZCwg YnV0IHVzZXMgYSBzZXBhcmF0ZSBjbG9jay4NCi0gTG9va2luZyBhdCB0aGUgQW5kcm9pZCBrZXJu ZWwgYXMgZGlzdHJpYnV0ZWQgYnkgZ29vZ2xlL3F1YWxjb21tLCB0aGV5IGhhdmUNCiAgZm91ciBz ZXBhcmF0ZSBjbG9ja3MgZGVzY3JpYmVkIGFzDQoNCiAgICBQSFkgdG8gY29udHJvbGxlciBzeW1i b2wgc3luY2hyb25pemF0aW9uIGNsb2NrczoNCiAgICAgICAgInJ4X2xhbmUwX3N5bmNfY2xrIiAt IFJYIExhbmUgMA0KICAgICAgICAicnhfbGFuZTFfc3luY19jbGsiIC0gUlggTGFuZSAxDQogICAg ICAgICJ0eF9sYW5lMF9zeW5jX2NsayIgLSBUWCBMYW5lIDANCiAgICAgICAgInR4X2xhbmUxX3N5 bmNfY2xrIiAtIFRYIExhbmUgMQ0KDQpXaGljaCBvZiB0aGUgYWJvdmUgd291bGQgeW91ciBwaHlf Y2xrIHJlZmVyIHRvPw0KDQogICAgICAgQXJuZA0KDQpbMV0gaHR0cHM6Ly9hbmRyb2lkLmdvb2ds ZXNvdXJjZS5jb20va2VybmVsL21zbS8rL2FuZHJvaWQtbXNtLWJ1bGxoZWFkLTMuMTAtbWFyc2ht YWxsb3ctZHIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Vmcy91ZnNoY2QtcGx0 ZnJtLnR4dD9hdXRvZGl2ZT0wJTJGJTJGJTJGJTJGJTJGDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: liwei213@huawei.com (liwei (CM)) Date: Mon, 26 Mar 2018 12:01:56 +0000 Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogW1BBVENIIHY4IDIvNV0gZHQtYmlu?= =?utf-8?Q?dings:_scsi:_ufs:_add_document_for_hisi-ufs?= In-Reply-To: References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> <1699CE87DE933F49876AD744B5DC140FA58798@DGGEMM506-MBS.china.huawei.com> Message-ID: <1699CE87DE933F49876AD744B5DC140FA587B5@DGGEMM506-MBS.china.huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd I'll ask our soc colleagues for help and give a detailed and accurate explanation aosp. Thanks! -----????----- ???: arndbergmann at gmail.com [mailto:arndbergmann at gmail.com] ?? Arnd Bergmann ????: 2018?3?26? 18:42 ???: liwei (CM) ??: 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 ??: Re: ??: ??: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs On Mon, Mar 26, 2018 at 12:26 PM, liwei (CM) wrote: > ???: arndbergmann at gmail.com [mailto:arndbergmann at gmail.com] ?? Arnd > Bergmann > > ??: Re: ??: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for > > hisi-ufs On Fri, Mar 23, 2018 at 3:22 AM, liwei (CM) wrote: > >> 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. > > phy_clk is actually given to the phy. But as previously mentioned , we > do not have a separate phy to configure ; The clks in the patch you > give appear to be unsuitable for describing this . > Here we can't describe phy_clk in the node "ufsphy1: ufsphy at fc597000" like qcom. > So can we put it here in our own binding like this? I think the concept of having a phy clk is generic enough that it's better to have that in the common part, others will surely have the same thing, and in this case, qcom would be the exception that does not use one. There are apparently a couple of things related to the phy that may or may not require a clk: - ref_clk: The reference clock on the mipi bus, this is what qcom have, this would be the 19.2 MHz clock signal. - one clock to drive the logic block for the PHY itself, if it is included within the same logical portion of an SoC as the ufshcd, but uses a separate clock. - Looking at the Android kernel as distributed by google/qualcomm, they have four separate clocks described as PHY to controller symbol synchronization clocks: "rx_lane0_sync_clk" - RX Lane 0 "rx_lane1_sync_clk" - RX Lane 1 "tx_lane0_sync_clk" - TX Lane 0 "tx_lane1_sync_clk" - TX Lane 1 Which of the above would your phy_clk refer to? Arnd [1] https://android.googlesource.com/kernel/msm/+/android-msm-bullhead-3.10-marshmallow-dr/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt?autodive=0%2F%2F%2F%2F%2F