Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/23 9:05, Subhash Jadavani 写道:

On 2017-06-22 04:51, Arnd Bergmann wrote:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices



Some of these sound rather generic and might apply to UFS
implementations
other than hi3660, so I'd suggest adding them to the base ufs
binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual
drivers,
and then the properties that are specific to the integration work
done by
hisilicon should be prefixed with "hisilicon,", but not normally
with the
SoC name: it is quite possible that another SoC will be derived from
this
chip and it should reuse the properties.



I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".


They should not have "hi3660" in their names either way, independent
of where they are used.



Yes, i agree with Arnd that SoCs might also need these so please make
these properties generic (put them under
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt) and also move
their parsing code in generic driver (ufshcd.c or ufshcd-pltfrm.c).


Thanks for your comments. I will modify this and update soon.



(note: this is different from the value of the "compatible" property
that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


My question was about the hardware: does hi3660 implement ufshcd
or not?

  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/23 9:05, Subhash Jadavani 写道:

On 2017-06-22 04:51, Arnd Bergmann wrote:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices



Some of these sound rather generic and might apply to UFS
implementations
other than hi3660, so I'd suggest adding them to the base ufs
binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual
drivers,
and then the properties that are specific to the integration work
done by
hisilicon should be prefixed with "hisilicon,", but not normally
with the
SoC name: it is quite possible that another SoC will be derived from
this
chip and it should reuse the properties.



I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".


They should not have "hi3660" in their names either way, independent
of where they are used.



Yes, i agree with Arnd that SoCs might also need these so please make
these properties generic (put them under
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt) and also move
their parsing code in generic driver (ufshcd.c or ufshcd-pltfrm.c).


Thanks for your comments. I will modify this and update soon.



(note: this is different from the value of the "compatible" property
that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


My question was about the hardware: does hi3660 implement ufshcd
or not?

  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Subhash Jadavani]

On 2017-06-22 04:51, Arnd Bergmann wrote:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices



Some of these sound rather generic and might apply to UFS 
implementations
other than hi3660, so I'd suggest adding them to the base ufs binding 
with

a generic name instead.

Any DT properties that might be useful across multiple 
implementations

should be parsed in generic code that gets called by the individual
drivers,
and then the properties that are specific to the integration work 
done by
hisilicon should be prefixed with "hisilicon,", but not normally with 
the
SoC name: it is quite possible that another SoC will be derived from 
this

chip and it should reuse the properties.



I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".


They should not have "hi3660" in their names either way, independent
of where they are used.



Yes, i agree with Arnd that SoCs might also need these so please make 
these properties generic (put them under 
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt) and also move 
their parsing code in generic driver (ufshcd.c or ufshcd-pltfrm.c).




(note: this is different from the value of the "compatible" property 
that

is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


My question was about the hardware: does hi3660 implement ufshcd
or not?

  Arnd


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Subhash Jadavani]

On 2017-06-22 04:51, Arnd Bergmann wrote:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices



Some of these sound rather generic and might apply to UFS 
implementations
other than hi3660, so I'd suggest adding them to the base ufs binding 
with

a generic name instead.

Any DT properties that might be useful across multiple 
implementations

should be parsed in generic code that gets called by the individual
drivers,
and then the properties that are specific to the integration work 
done by
hisilicon should be prefixed with "hisilicon,", but not normally with 
the
SoC name: it is quite possible that another SoC will be derived from 
this

chip and it should reuse the properties.



I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".


They should not have "hi3660" in their names either way, independent
of where they are used.



Yes, i agree with Arnd that SoCs might also need these so please make 
these properties generic (put them under 
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt) and also move 
their parsing code in generic driver (ufshcd.c or ufshcd-pltfrm.c).




(note: this is different from the value of the "compatible" property 
that

is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


My question was about the hardware: does hi3660 implement ufshcd
or not?

  Arnd


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/22 20:15, Arnd Bergmann 写道:

On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao  wrote:

在 2017/6/22 19:51, Arnd Bergmann 写道:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:


I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".



They should not have "hi3660" in their names either way, independent
of where they are used.



Oh, change the "hi3660" to "hisilicon"?
e.g. ufs-hi3660-use-rate-B  -->  ufs-hisilicon-use-rate-B


No, just 'use-rate-B', no prefix for this.


(note: this is different from the value of the "compatible" property
that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?



No, only show how to use the dt-binding for hi3660 SoC



My question was about the hardware: does hi3660 implement ufshcd
or not?



YES


Ok, then the properties should be documented as optional in the
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt file for anything
that has a proper interpretation in the context of the generic ufshcd
driver.

  Arnd



OK I will modify this and update the patch soon.

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/22 20:15, Arnd Bergmann 写道:

On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao  wrote:

在 2017/6/22 19:51, Arnd Bergmann 写道:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:


I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".



They should not have "hi3660" in their names either way, independent
of where they are used.



Oh, change the "hi3660" to "hisilicon"?
e.g. ufs-hi3660-use-rate-B  -->  ufs-hisilicon-use-rate-B


No, just 'use-rate-B', no prefix for this.


(note: this is different from the value of the "compatible" property
that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?



No, only show how to use the dt-binding for hi3660 SoC



My question was about the hardware: does hi3660 implement ufshcd
or not?



YES


Ok, then the properties should be documented as optional in the
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt file for anything
that has a proper interpretation in the context of the generic ufshcd
driver.

  Arnd



OK I will modify this and update the patch soon.

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Arnd Bergmann]

On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao  wrote:
> 在 2017/6/22 19:51, Arnd Bergmann 写道:
>> On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:
>>> 在 2017/6/17 5:51, Arnd Bergmann 写道:
 On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:
>>>
>>> I do not know wheher other SoC need to use the optional properties as
>>> abover. So here the name of the optional properties has "hi3660".
>>
>>
>> They should not have "hi3660" in their names either way, independent
>> of where they are used.
>
>
> Oh, change the "hi3660" to "hisilicon"?
> e.g. ufs-hi3660-use-rate-B  -->  ufs-hisilicon-use-rate-B

No, just 'use-rate-B', no prefix for this.

 (note: this is different from the value of the "compatible" property
 that
 is meant to be as specific as possible".

 Also, please clarify how your binding relates to the ufshcd binding
 in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
 hi3660 implement any registers that are shared with ufshcd, or does
 it use the same physical interface with a different register set?
>>>
>>>
>>> No, only show how to use the dt-binding for hi3660 SoC
>>
>>
>> My question was about the hardware: does hi3660 implement ufshcd
>> or not?
>
>
> YES

Ok, then the properties should be documented as optional in the
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt file for anything
that has a proper interpretation in the context of the generic ufshcd
driver.

  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Arnd Bergmann]

On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao  wrote:
> 在 2017/6/22 19:51, Arnd Bergmann 写道:
>> On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:
>>> 在 2017/6/17 5:51, Arnd Bergmann 写道:
 On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:
>>>
>>> I do not know wheher other SoC need to use the optional properties as
>>> abover. So here the name of the optional properties has "hi3660".
>>
>>
>> They should not have "hi3660" in their names either way, independent
>> of where they are used.
>
>
> Oh, change the "hi3660" to "hisilicon"?
> e.g. ufs-hi3660-use-rate-B  -->  ufs-hisilicon-use-rate-B

No, just 'use-rate-B', no prefix for this.

 (note: this is different from the value of the "compatible" property
 that
 is meant to be as specific as possible".

 Also, please clarify how your binding relates to the ufshcd binding
 in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
 hi3660 implement any registers that are shared with ufshcd, or does
 it use the same physical interface with a different register set?
>>>
>>>
>>> No, only show how to use the dt-binding for hi3660 SoC
>>
>>
>> My question was about the hardware: does hi3660 implement ufshcd
>> or not?
>
>
> YES

Ok, then the properties should be documented as optional in the
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt file for anything
that has a proper interpretation in the context of the generic ufshcd
driver.

  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/22 19:51, Arnd Bergmann 写道:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices



Some of these sound rather generic and might apply to UFS implementations
other than hi3660, so I'd suggest adding them to the base ufs binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual
drivers,
and then the properties that are specific to the integration work done by
hisilicon should be prefixed with "hisilicon,", but not normally with the
SoC name: it is quite possible that another SoC will be derived from this
chip and it should reuse the properties.



I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".


They should not have "hi3660" in their names either way, independent
of where they are used.


Oh, change the "hi3660" to "hisilicon"?
e.g. ufs-hi3660-use-rate-B  -->  ufs-hisilicon-use-rate-B



(note: this is different from the value of the "compatible" property that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


My question was about the hardware: does hi3660 implement ufshcd
or not?


YES


  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/22 19:51, Arnd Bergmann 写道:

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices



Some of these sound rather generic and might apply to UFS implementations
other than hi3660, so I'd suggest adding them to the base ufs binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual
drivers,
and then the properties that are specific to the integration work done by
hisilicon should be prefixed with "hisilicon,", but not normally with the
SoC name: it is quite possible that another SoC will be derived from this
chip and it should reuse the properties.



I do not know wheher other SoC need to use the optional properties as
abover. So here the name of the optional properties has "hi3660".


They should not have "hi3660" in their names either way, independent
of where they are used.


Oh, change the "hi3660" to "hisilicon"?
e.g. ufs-hi3660-use-rate-B  -->  ufs-hisilicon-use-rate-B



(note: this is different from the value of the "compatible" property that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


My question was about the hardware: does hi3660 implement ufshcd
or not?


YES


  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

add ufs node document for hi3660

Signed-off-by: Bu Tao 
---
 .../devicetree/bindings/ufs/hi3660-ufs.txt | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ufs/hi3660-ufs.txt

diff --git a/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt 
b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
new file mode 100644
index ..461afc8ef017
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
@@ -0,0 +1,58 @@
+* 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" for hisi ufs host controller
+present on Hi3660 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. "clk_ref", "clk_phy" is 
optional
+- resets: reset node register, one reset the clk and the other 
reset the controller
+- reset-names   : describe reset node register
+
+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices


Some of these sound rather generic and might apply to UFS implementations
other than hi3660, so I'd suggest adding them to the base ufs binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual drivers,
and then the properties that are specific to the integration work done by
hisilicon should be prefixed with "hisilicon,", but not normally with the
SoC name: it is quite possible that another SoC will be derived from this
chip and it should reuse the properties.


I do not know wheher other SoC need to use the optional properties as 
abover. So here the name of the optional properties has "hi3660".


(note: this is different from the value of the "compatible" property that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


   Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Bu Tao]

在 2017/6/17 5:51, Arnd Bergmann 写道:

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:

add ufs node document for hi3660

Signed-off-by: Bu Tao 
---
 .../devicetree/bindings/ufs/hi3660-ufs.txt | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ufs/hi3660-ufs.txt

diff --git a/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt 
b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
new file mode 100644
index ..461afc8ef017
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
@@ -0,0 +1,58 @@
+* 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" for hisi ufs host controller
+present on Hi3660 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. "clk_ref", "clk_phy" is 
optional
+- resets: reset node register, one reset the clk and the other 
reset the controller
+- reset-names   : describe reset node register
+
+Optional properties for board device:
+- ufs-hi3660-use-rate-B: specifies UFS rate-B
+- ufs-hi3660-broken-fastauto   : specifies no fastauto
+- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
+- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
+- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
+- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
+- ufs-hi3660-use-one-line  : specifies UFS use one line work
+- reset-gpio   : specifies to reset devices


Some of these sound rather generic and might apply to UFS implementations
other than hi3660, so I'd suggest adding them to the base ufs binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual drivers,
and then the properties that are specific to the integration work done by
hisilicon should be prefixed with "hisilicon,", but not normally with the
SoC name: it is quite possible that another SoC will be derived from this
chip and it should reuse the properties.


I do not know wheher other SoC need to use the optional properties as 
abover. So here the name of the optional properties has "hi3660".


(note: this is different from the value of the "compatible" property that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?


No, only show how to use the dt-binding for hi3660 SoC


   Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Arnd Bergmann]

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:
> 在 2017/6/17 5:51, Arnd Bergmann 写道:
>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:
>>> +Optional properties for board device:
>>> +- ufs-hi3660-use-rate-B: specifies UFS rate-B
>>> +- ufs-hi3660-broken-fastauto   : specifies no fastauto
>>> +- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
>>> +- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
>>> +- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
>>> +- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
>>> +- ufs-hi3660-use-one-line  : specifies UFS use one line work
>>> +- reset-gpio   : specifies to reset devices
>>
>>
>> Some of these sound rather generic and might apply to UFS implementations
>> other than hi3660, so I'd suggest adding them to the base ufs binding with
>> a generic name instead.
>>
>> Any DT properties that might be useful across multiple implementations
>> should be parsed in generic code that gets called by the individual
>> drivers,
>> and then the properties that are specific to the integration work done by
>> hisilicon should be prefixed with "hisilicon,", but not normally with the
>> SoC name: it is quite possible that another SoC will be derived from this
>> chip and it should reuse the properties.
>
>
> I do not know wheher other SoC need to use the optional properties as
> abover. So here the name of the optional properties has "hi3660".

They should not have "hi3660" in their names either way, independent
of where they are used.

>> (note: this is different from the value of the "compatible" property that
>> is meant to be as specific as possible".
>>
>> Also, please clarify how your binding relates to the ufshcd binding
>> in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
>> hi3660 implement any registers that are shared with ufshcd, or does
>> it use the same physical interface with a different register set?
>
> No, only show how to use the dt-binding for hi3660 SoC

My question was about the hardware: does hi3660 implement ufshcd
or not?

  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Arnd Bergmann]

On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao  wrote:
> 在 2017/6/17 5:51, Arnd Bergmann 写道:
>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:
>>> +Optional properties for board device:
>>> +- ufs-hi3660-use-rate-B: specifies UFS rate-B
>>> +- ufs-hi3660-broken-fastauto   : specifies no fastauto
>>> +- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
>>> +- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
>>> +- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
>>> +- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
>>> +- ufs-hi3660-use-one-line  : specifies UFS use one line work
>>> +- reset-gpio   : specifies to reset devices
>>
>>
>> Some of these sound rather generic and might apply to UFS implementations
>> other than hi3660, so I'd suggest adding them to the base ufs binding with
>> a generic name instead.
>>
>> Any DT properties that might be useful across multiple implementations
>> should be parsed in generic code that gets called by the individual
>> drivers,
>> and then the properties that are specific to the integration work done by
>> hisilicon should be prefixed with "hisilicon,", but not normally with the
>> SoC name: it is quite possible that another SoC will be derived from this
>> chip and it should reuse the properties.
>
>
> I do not know wheher other SoC need to use the optional properties as
> abover. So here the name of the optional properties has "hi3660".

They should not have "hi3660" in their names either way, independent
of where they are used.

>> (note: this is different from the value of the "compatible" property that
>> is meant to be as specific as possible".
>>
>> Also, please clarify how your binding relates to the ufshcd binding
>> in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
>> hi3660 implement any registers that are shared with ufshcd, or does
>> it use the same physical interface with a different register set?
>
> No, only show how to use the dt-binding for hi3660 SoC

My question was about the hardware: does hi3660 implement ufshcd
or not?

  Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Arnd Bergmann]

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:
> add ufs node document for hi3660
>
> Signed-off-by: Bu Tao 
> ---
>  .../devicetree/bindings/ufs/hi3660-ufs.txt | 58 
> ++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
>
> diff --git a/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt 
> b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
> new file mode 100644
> index ..461afc8ef017
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
> @@ -0,0 +1,58 @@
> +* 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" for hisi ufs host controller
> +present on Hi3660 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. "clk_ref", "clk_phy" is 
> optional
> +- resets: reset node register, one reset the clk and the other 
> reset the controller
> +- reset-names   : describe reset node register
> +
> +Optional properties for board device:
> +- ufs-hi3660-use-rate-B: specifies UFS rate-B
> +- ufs-hi3660-broken-fastauto   : specifies no fastauto
> +- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
> +- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
> +- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
> +- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
> +- ufs-hi3660-use-one-line  : specifies UFS use one line work
> +- reset-gpio   : specifies to reset devices

Some of these sound rather generic and might apply to UFS implementations
other than hi3660, so I'd suggest adding them to the base ufs binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual drivers,
and then the properties that are specific to the integration work done by
hisilicon should be prefixed with "hisilicon,", but not normally with the
SoC name: it is quite possible that another SoC will be derived from this
chip and it should reuse the properties.

(note: this is different from the value of the "compatible" property that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?

   Arnd

Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs

[Arnd Bergmann]

On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao  wrote:
> add ufs node document for hi3660
>
> Signed-off-by: Bu Tao 
> ---
>  .../devicetree/bindings/ufs/hi3660-ufs.txt | 58 
> ++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
>
> diff --git a/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt 
> b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
> new file mode 100644
> index ..461afc8ef017
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/hi3660-ufs.txt
> @@ -0,0 +1,58 @@
> +* 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" for hisi ufs host controller
> +present on Hi3660 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. "clk_ref", "clk_phy" is 
> optional
> +- resets: reset node register, one reset the clk and the other 
> reset the controller
> +- reset-names   : describe reset node register
> +
> +Optional properties for board device:
> +- ufs-hi3660-use-rate-B: specifies UFS rate-B
> +- ufs-hi3660-broken-fastauto   : specifies no fastauto
> +- ufs-hi3660-use-HS-GEAR3  : specifies UFS HS-GEAR3
> +- ufs-hi3660-use-HS-GEAR2  : specifies UFS HS-GEAR2
> +- ufs-hi3660-use-HS-GEAR1  : specifies UFS HS-GEAR1
> +- ufs-hi3660-broken-clk-gate-bypass: specifies no clk-gate
> +- ufs-hi3660-use-one-line  : specifies UFS use one line work
> +- reset-gpio   : specifies to reset devices

Some of these sound rather generic and might apply to UFS implementations
other than hi3660, so I'd suggest adding them to the base ufs binding with
a generic name instead.

Any DT properties that might be useful across multiple implementations
should be parsed in generic code that gets called by the individual drivers,
and then the properties that are specific to the integration work done by
hisilicon should be prefixed with "hisilicon,", but not normally with the
SoC name: it is quite possible that another SoC will be derived from this
chip and it should reuse the properties.

(note: this is different from the value of the "compatible" property that
is meant to be as specific as possible".

Also, please clarify how your binding relates to the ufshcd binding
in Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt: does
hi3660 implement any registers that are shared with ufshcd, or does
it use the same physical interface with a different register set?

   Arnd