From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751908AbeC2BAQ (ORCPT ); Wed, 28 Mar 2018 21:00:16 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:50782 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751043AbeC2BAO (ORCPT ); Wed, 28 Mar 2018 21:00:14 -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?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiBbUEFUQ0ggdjggMi81?= =?utf-8?B?XSBkdC1iaW5kaW5nczogc2NzaTogdWZzOiBhZGQgZG9jdW1lbnQgZm9yIGhp?= =?utf-8?Q?si-ufs?= Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogW1BBVENIIHY4IDIvNV0gZHQtYmlu?= =?utf-8?Q?dings:_scsi:_ufs:_add_document_for_hisi-ufs?= Thread-Index: AQHTpLNt7xq76dhVgkeSgBp0Vy2vQaOrAJgAgDJE6ZCABLCUgIAAkqZA//+FzQCAAJJzQIABEYQAgAGkfQCAAVCxoA== Date: Thu, 29 Mar 2018 01:00:01 +0000 Message-ID: <1699CE87DE933F49876AD744B5DC140FA58BA1@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> <1699CE87DE933F49876AD744B5DC140FA588AD@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 w2T10KZw024015 Hi, Arnd Thanks for your patiences. -----邮件原件----- 发件人: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] 代表 Arnd Bergmann 发送时间: 2018年3月28日 20:50 收件人: 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 Tue, Mar 27, 2018 at 8:15 AM, liwei (CM) wrote: > Hi, Arnd > > At present our ufs module mainly has four clocks from the outside: > hclk_ufs: main clock of ufs controller ,freq is 207.5MHz > cfg_phy_clk: configuration clock of MPHY, freq is 51.875MHz > ref_phy_clk: reference clock of MPHY from PMU, freq is 19.2MHz > ref_io_clk: reference clock for the external interface to the device, freq is 19.2MHz > > We control two clocks "ref_io_clk" and "cfg_phy_clk" in the driver > because the other two are controlled by main clock module and pmu. I'm not completely sure what you mean with "control" here. Do you mean setting the rate and disabling them during runtime power management? What does it mean for the clock to be controlled by teh "main clock module and pmu"? In the driver we only disable/enable "ref_io_clk" and "cfg_phy_clk" during runtime power management. > for this patch, cfg_phy_clk corresponds to "phy_clk", ref_io_clk corresponds to "ref_clk". I'm not sure I understand the difference between ref_phy_clk and ref_io_clk, but it sounds like we should give both of those names in the ufs-platform binding. Your hclk_ufs would appear to correspond to what qualcomm calls core_clk, so maybe use that name as well. cfg_phy_clk seems to be something that qcom would not have, but it's also generic enough to list it in the common binding. Ok, let's add a describe for phy_clk in the common binding. > So the clks in the patch you give appear to be unsuitable for describing this .And the following clks of qcom are internal clock? > We didn't describe or pay attention to the clock inside the ufs module. > > 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 Right, let's leave those for the qcom private binding. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: "liwei (CM)" Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiBbUEFUQ0ggdjggMi81?= =?utf-8?B?XSBkdC1iaW5kaW5nczogc2NzaTogdWZzOiBhZGQgZG9jdW1lbnQgZm9yIGhp?= =?utf-8?Q?si-ufs?= Date: Thu, 29 Mar 2018 01:00:01 +0000 Message-ID: <1699CE87DE933F49876AD744B5DC140FA58BA1@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> <1699CE87DE933F49876AD744B5DC140FA588AD@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 SGksIEFybmQNCg0KVGhhbmtzIGZvciB5b3VyIHBhdGllbmNlcy4NCg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBhcm5kYmVyZ21hbm5AZ21haWwuY29tIFttYWlsdG86YXJuZGJl cmdtYW5uQGdtYWlsLmNvbV0g5Luj6KGoIEFybmQgQmVyZ21hbm4NCuWPkemAgeaXtumXtDogMjAx OOW5tDPmnIgyOOaXpSAyMDo1MA0K5pS25Lu25Lq6OiBsaXdlaSAoQ00pDQrmioTpgIE6IFJvYiBI ZXJyaW5nOyBNYXJrIFJ1dGxhbmQ7IHh1d2VpIChPKTsgQ2F0YWxpbiBNYXJpbmFzOyBXaWxsIERl YWNvbjsgVmluYXlhayBIb2xpa2F0dGk7IEphbWVzIEUuSi4gQm90dG9tbGV5OyBNYXJ0aW4gSy4g UGV0ZXJzZW47IEtldmluIEhpbG1hbjsgR3JlZ29yeSBDTEVNRU5UOyBUaG9tYXMgUGV0YXp6b25p OyBNYXNhaGlybyBZYW1hZGE7IFJpa3UgVm9pcGlvOyBUaGllcnJ5IFJlZGluZzsgS3J6eXN6dG9m IEtvemxvd3NraTsgRXJpYyBBbmhvbHQ7IERUTUw7IExpbnV4IEtlcm5lbCBNYWlsaW5nIExpc3Q7 IExpbnV4IEFSTTsgbGludXgtc2NzaTsgemFuZ2xlaWdhbmc7IEdlbmdqaWFuZmVuZzsgR3VvZG9u ZyBYdTsgWmhhbmdmZWkgR2FvOyBGZW5nYmFvcGVuZyAoa2V2aW4sIEtpcmluIFNvbHV0aW9uIERl cHQpOyBZYW5pdiBHYXJkaQ0K5Li76aKYOiBSZTog562U5aSNOiDnrZTlpI06IOetlOWkjTogW1BB VENIIHY4IDIvNV0gZHQtYmluZGluZ3M6IHNjc2k6IHVmczogYWRkIGRvY3VtZW50IGZvciBoaXNp LXVmcw0KDQpPbiBUdWUsIE1hciAyNywgMjAxOCBhdCA4OjE1IEFNLCBsaXdlaSAoQ00pIDxsaXdl aTIxM0BodWF3ZWkuY29tPiB3cm90ZToNCj4gSGksIEFybmQNCj4NCj4gQXQgcHJlc2VudCBvdXIg dWZzIG1vZHVsZSBtYWlubHkgaGFzIGZvdXIgY2xvY2tzIGZyb20gdGhlIG91dHNpZGU6DQo+IGhj bGtfdWZzOiAgICAgbWFpbiBjbG9jayBvZiB1ZnMgY29udHJvbGxlciAsZnJlcSBpcyAyMDcuNU1I eg0KPiBjZmdfcGh5X2NsazogIGNvbmZpZ3VyYXRpb24gY2xvY2sgb2YgTVBIWSwgZnJlcSBpcyA1 MS44NzVNSHoNCj4gcmVmX3BoeV9jbGs6ICByZWZlcmVuY2UgY2xvY2sgb2YgTVBIWSBmcm9tIFBN VSwgZnJlcSBpcyAxOS4yTUh6DQo+IHJlZl9pb19jbGs6ICAgIHJlZmVyZW5jZSBjbG9jayBmb3Ig dGhlIGV4dGVybmFsIGludGVyZmFjZSB0byB0aGUgZGV2aWNlLCBmcmVxIGlzIDE5LjJNSHoNCj4N Cj4gV2UgY29udHJvbCB0d28gY2xvY2tzICJyZWZfaW9fY2xrIiBhbmQgImNmZ19waHlfY2xrIiBp biB0aGUgZHJpdmVyIA0KPiBiZWNhdXNlIHRoZSBvdGhlciB0d28gYXJlIGNvbnRyb2xsZWQgYnkg bWFpbiBjbG9jayBtb2R1bGUgYW5kIHBtdS4NCg0KSSdtIG5vdCBjb21wbGV0ZWx5IHN1cmUgd2hh dCB5b3UgbWVhbiB3aXRoICJjb250cm9sIiBoZXJlLiBEbyB5b3UgbWVhbiBzZXR0aW5nIHRoZSBy YXRlIGFuZCBkaXNhYmxpbmcgdGhlbSBkdXJpbmcgcnVudGltZSBwb3dlciBtYW5hZ2VtZW50PyBX aGF0IGRvZXMgaXQgbWVhbiBmb3IgdGhlIGNsb2NrIHRvIGJlIGNvbnRyb2xsZWQgYnkgdGVoICJt YWluIGNsb2NrIG1vZHVsZSBhbmQgcG11Ij8NCg0KSW4gdGhlIGRyaXZlciB3ZSBvbmx5IGRpc2Fi bGUvZW5hYmxlICJyZWZfaW9fY2xrIiBhbmQgImNmZ19waHlfY2xrIiBkdXJpbmcgcnVudGltZSBw b3dlciBtYW5hZ2VtZW50Lg0KDQo+IGZvciB0aGlzIHBhdGNoLCBjZmdfcGh5X2NsayBjb3JyZXNw b25kcyB0byAicGh5X2NsayIsIHJlZl9pb19jbGsgY29ycmVzcG9uZHMgdG8gInJlZl9jbGsiLg0K DQpJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcmVmX3Bo eV9jbGsgYW5kIHJlZl9pb19jbGssIGJ1dCBpdCBzb3VuZHMgbGlrZSB3ZSBzaG91bGQgZ2l2ZSBi b3RoIG9mIHRob3NlIG5hbWVzIGluIHRoZSB1ZnMtcGxhdGZvcm0gYmluZGluZy4NCg0KWW91ciBo Y2xrX3VmcyB3b3VsZCBhcHBlYXIgdG8gY29ycmVzcG9uZCB0byB3aGF0IHF1YWxjb21tIGNhbGxz IGNvcmVfY2xrLCBzbyBtYXliZSB1c2UgdGhhdCBuYW1lIGFzIHdlbGwuDQoNCmNmZ19waHlfY2xr IHNlZW1zIHRvIGJlIHNvbWV0aGluZyB0aGF0IHFjb20gd291bGQgbm90IGhhdmUsIGJ1dCBpdCdz IGFsc28gZ2VuZXJpYyBlbm91Z2ggdG8gbGlzdCBpdCBpbiB0aGUgY29tbW9uIGJpbmRpbmcuDQoN Ck9rLCBsZXQncyBhZGQgYSBkZXNjcmliZSBmb3IgcGh5X2NsayBpbiB0aGUgY29tbW9uIGJpbmRp bmcuDQoNCj4gU28gdGhlIGNsa3MgaW4gdGhlIHBhdGNoIHlvdSBnaXZlIGFwcGVhciB0byBiZSB1 bnN1aXRhYmxlIGZvciBkZXNjcmliaW5nIHRoaXMgLkFuZCB0aGUgZm9sbG93aW5nIGNsa3Mgb2Yg cWNvbSBhcmUgaW50ZXJuYWwgY2xvY2s/DQo+IFdlIGRpZG4ndCBkZXNjcmliZSBvciBwYXkgYXR0 ZW50aW9uIHRvIHRoZSBjbG9jayBpbnNpZGUgdGhlIHVmcyBtb2R1bGUuDQo+DQo+IFBIWSB0byBj b250cm9sbGVyIHN5bWJvbCBzeW5jaHJvbml6YXRpb24gY2xvY2tzOg0KPiAgICAgICAgICJyeF9s YW5lMF9zeW5jX2NsayIgLSBSWCBMYW5lIDANCj4gICAgICAgICAicnhfbGFuZTFfc3luY19jbGsi IC0gUlggTGFuZSAxDQo+ICAgICAgICAgInR4X2xhbmUwX3N5bmNfY2xrIiAtIFRYIExhbmUgMA0K PiAgICAgICAgICJ0eF9sYW5lMV9zeW5jX2NsayIgLSBUWCBMYW5lIDENCg0KUmlnaHQsIGxldCdz IGxlYXZlIHRob3NlIGZvciB0aGUgcWNvbSBwcml2YXRlIGJpbmRpbmcuDQoNCiAgICAgIEFybmQN Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: liwei213@huawei.com (liwei (CM)) Date: Thu, 29 Mar 2018 01:00:01 +0000 Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiBbUEFUQ0ggdjggMi81?= =?utf-8?B?XSBkdC1iaW5kaW5nczogc2NzaTogdWZzOiBhZGQgZG9jdW1lbnQgZm9yIGhp?= =?utf-8?Q?si-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> <1699CE87DE933F49876AD744B5DC140FA588AD@DGGEMM506-MBS.china.huawei.com> Message-ID: <1699CE87DE933F49876AD744B5DC140FA58BA1@DGGEMM506-MBS.china.huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd Thanks for your patiences. -----????----- ???: arndbergmann at gmail.com [mailto:arndbergmann at gmail.com] ?? Arnd Bergmann ????: 2018?3?28? 20:50 ???: 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 Tue, Mar 27, 2018 at 8:15 AM, liwei (CM) wrote: > Hi, Arnd > > At present our ufs module mainly has four clocks from the outside: > hclk_ufs: main clock of ufs controller ,freq is 207.5MHz > cfg_phy_clk: configuration clock of MPHY, freq is 51.875MHz > ref_phy_clk: reference clock of MPHY from PMU, freq is 19.2MHz > ref_io_clk: reference clock for the external interface to the device, freq is 19.2MHz > > We control two clocks "ref_io_clk" and "cfg_phy_clk" in the driver > because the other two are controlled by main clock module and pmu. I'm not completely sure what you mean with "control" here. Do you mean setting the rate and disabling them during runtime power management? What does it mean for the clock to be controlled by teh "main clock module and pmu"? In the driver we only disable/enable "ref_io_clk" and "cfg_phy_clk" during runtime power management. > for this patch, cfg_phy_clk corresponds to "phy_clk", ref_io_clk corresponds to "ref_clk". I'm not sure I understand the difference between ref_phy_clk and ref_io_clk, but it sounds like we should give both of those names in the ufs-platform binding. Your hclk_ufs would appear to correspond to what qualcomm calls core_clk, so maybe use that name as well. cfg_phy_clk seems to be something that qcom would not have, but it's also generic enough to list it in the common binding. Ok, let's add a describe for phy_clk in the common binding. > So the clks in the patch you give appear to be unsuitable for describing this .And the following clks of qcom are internal clock? > We didn't describe or pay attention to the clock inside the ufs module. > > 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 Right, let's leave those for the qcom private binding. Arnd