Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1672558 > unrolled thread
| Started by | Bu Tao <butao@huawei.com> |
|---|---|
| First post | 2017-06-22 14:00 +0200 |
| Last post | 2017-06-23 03:20 +0200 |
| Articles | 7 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Bu Tao <butao@huawei.com> - 2017-06-22 14:00 +0200
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Arnd Bergmann <arnd@arndb.de> - 2017-06-22 14:00 +0200
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Bu Tao <butao@huawei.com> - 2017-06-22 14:10 +0200
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Arnd Bergmann <arnd@arndb.de> - 2017-06-22 14:20 +0200
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Bu Tao <butao@huawei.com> - 2017-06-22 14:40 +0200
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Subhash Jadavani <subhashj@codeaurora.org> - 2017-06-23 03:10 +0200
Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs Bu Tao <butao@huawei.com> - 2017-06-23 03:20 +0200
| From | Bu Tao <butao@huawei.com> |
|---|---|
| Date | 2017-06-22 14:00 +0200 |
| Subject | Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs |
| Message-ID | <tV8Wd-4b0-1@gated-at.bofh.it> |
在 2017/6/17 5:51, Arnd Bergmann 写道: > On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> wrote: >> add ufs node document for hi3660 >> >> Signed-off-by: Bu Tao <butao@hisilicon.com> >> --- >> .../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 000000000000..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 >
[toc] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2017-06-22 14:00 +0200 |
| Subject | Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs |
| Message-ID | <tV8We-4b0-25@gated-at.bofh.it> |
| In reply to | #1672558 |
On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao <butao@huawei.com> wrote:
> 在 2017/6/17 5:51, Arnd Bergmann 写道:
>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Bu Tao <butao@huawei.com> |
|---|---|
| Date | 2017-06-22 14:10 +0200 |
| Message-ID | <tV95U-4vV-27@gated-at.bofh.it> |
| In reply to | #1672564 |
在 2017/6/22 19:51, Arnd Bergmann 写道: > On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao <butao@huawei.com> wrote: >> 在 2017/6/17 5:51, Arnd Bergmann 写道: >>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> 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 >
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2017-06-22 14:20 +0200 |
| Subject | Re: [PATCH v2 2/5] dt-bindings: scsi: ufs: add document for hi3660-ufs |
| Message-ID | <tV9fA-4zM-19@gated-at.bofh.it> |
| In reply to | #1672571 |
On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao <butao@huawei.com> wrote:
> 在 2017/6/22 19:51, Arnd Bergmann 写道:
>> On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao <butao@huawei.com> wrote:
>>> 在 2017/6/17 5:51, Arnd Bergmann 写道:
>>>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Bu Tao <butao@huawei.com> |
|---|---|
| Date | 2017-06-22 14:40 +0200 |
| Message-ID | <tV9yV-4Hs-7@gated-at.bofh.it> |
| In reply to | #1672580 |
在 2017/6/22 20:15, Arnd Bergmann 写道: > On Thu, Jun 22, 2017 at 1:58 PM, Bu Tao <butao@huawei.com> wrote: >> 在 2017/6/22 19:51, Arnd Bergmann 写道: >>> On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao <butao@huawei.com> wrote: >>>> 在 2017/6/17 5:51, Arnd Bergmann 写道: >>>>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> 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.
[toc] | [prev] | [next] | [standalone]
| From | Subhash Jadavani <subhashj@codeaurora.org> |
|---|---|
| Date | 2017-06-23 03:10 +0200 |
| Message-ID | <tVlgL-3S1-23@gated-at.bofh.it> |
| In reply to | #1672564 |
On 2017-06-22 04:51, Arnd Bergmann wrote: > On Thu, Jun 22, 2017 at 1:44 PM, Bu Tao <butao@huawei.com> wrote: >> 在 2017/6/17 5:51, Arnd Bergmann 写道: >>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Bu Tao <butao@huawei.com> |
|---|---|
| Date | 2017-06-23 03:20 +0200 |
| Message-ID | <tVlqp-3Vc-1@gated-at.bofh.it> |
| In reply to | #1673162 |
在 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 <butao@huawei.com> wrote: >>> 在 2017/6/17 5:51, Arnd Bergmann 写道: >>>> On Fri, Jun 16, 2017 at 8:51 AM, Bu Tao <butao@hisilicon.com> 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 >
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web