| Message ID | 1478148731-11712-7-git-send-email-sudeep.holla@arm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi Rob, On 03/11/16 04:52, Sudeep Holla wrote: > This patch adds specific compatible to support legacy SCPI protocol. > Sorry for messing it up before, I think this version is much better. Only this patch introduces new compatible, while 5,7,8/8 are just reorganization to move the platform specific stuff out of the generic SCPI bindings. It would be good if you can have a quick look and provide ack if you are happy with these patches.
On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: > This patch adds specific compatible to support legacy SCPI protocol. > > Cc: Rob Herring <robh+dt@kernel.org> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt > index d1882c4540d0..ebd03fc93135 100644 > --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt > +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt > @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations. > > Required properties: > > -- compatible : should be "arm,scpi" > +- compatible : should be > + * "arm,scpi" : For implementations complying to SCPI v1.0 or above > + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0 I'd prefer that we explicitly enumerate the old versions. Are there many? Rob
On 10/11/16 01:22, Rob Herring wrote: > On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: >> This patch adds specific compatible to support legacy SCPI protocol. >> >> Cc: Rob Herring <robh+dt@kernel.org> >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >> --- >> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt >> index d1882c4540d0..ebd03fc93135 100644 >> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt >> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt >> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations. >> >> Required properties: >> >> -- compatible : should be "arm,scpi" >> +- compatible : should be >> + * "arm,scpi" : For implementations complying to SCPI v1.0 or above >> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0 > > I'd prefer that we explicitly enumerate the old versions. Are there > many? > I understand your concern, but this legacy SCPI protocol was not officially released. It was just WIP which vendors picked up from very early releases. Since they are not numbered, it's hard to have specific compatibles with different versions until v1.0. That's one of the reason to retain platform specific compatible so that we can add any quirks based on them if needed. I will probably add these information in the commit log so that it's clear why we can't do version based compatible.
On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 10/11/16 01:22, Rob Herring wrote: >> >> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: >>> >>> This patch adds specific compatible to support legacy SCPI protocol. >>> >>> Cc: Rob Herring <robh+dt@kernel.org> >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>> --- >>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>> index d1882c4540d0..ebd03fc93135 100644 >>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power >>> operations. >>> >>> Required properties: >>> >>> -- compatible : should be "arm,scpi" >>> +- compatible : should be >>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or >>> above >>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0 >> >> >> I'd prefer that we explicitly enumerate the old versions. Are there >> many? >> > > I understand your concern, but this legacy SCPI protocol was not > officially released. It was just WIP which vendors picked up from very > early releases. Since they are not numbered, it's hard to have specific > compatibles with different versions until v1.0. That's one of the reason > to retain platform specific compatible so that we can add any quirks > based on them if needed. > > I will probably add these information in the commit log so that it's > clear why we can't do version based compatible. This is exactly my point. By enumerate, I meant having platform specific compatibles. Having "arm,legacy-scpi" is pointless because who knows what version they followed and they may all be different. Rob
On 10/11/16 14:12, Rob Herring wrote: > On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> >> >> On 10/11/16 01:22, Rob Herring wrote: >>> >>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: >>>> >>>> This patch adds specific compatible to support legacy SCPI protocol. >>>> >>>> Cc: Rob Herring <robh+dt@kernel.org> >>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>>> --- >>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- >>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>> index d1882c4540d0..ebd03fc93135 100644 >>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power >>>> operations. >>>> >>>> Required properties: >>>> >>>> -- compatible : should be "arm,scpi" >>>> +- compatible : should be >>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or >>>> above >>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0 >>> >>> >>> I'd prefer that we explicitly enumerate the old versions. Are there >>> many? >>> >> >> I understand your concern, but this legacy SCPI protocol was not >> officially released. It was just WIP which vendors picked up from very >> early releases. Since they are not numbered, it's hard to have specific >> compatibles with different versions until v1.0. That's one of the reason >> to retain platform specific compatible so that we can add any quirks >> based on them if needed. >> >> I will probably add these information in the commit log so that it's >> clear why we can't do version based compatible. > > This is exactly my point. By enumerate, I meant having platform > specific compatibles. Having "arm,legacy-scpi" is pointless because > who knows what version they followed and they may all be different. > OK, but IIUC Olof's concern wanted a generic one along with the platform specific compatible which kind of makes sense as so far we have seen some commonality between Amlogic and Rockchip. E.g. Amlogic follows most of the legacy protocol though it deviates in couple of things which we can handle with platform specific compatible (in the following patch in the series). When another user(Rockchip ?) make use of this legacy protocol, we can start using those platform specific compatible for deviations only. Is that not acceptable ?
On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 10/11/16 14:12, Rob Herring wrote: >> >> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> >> wrote: >>> >>> >>> >>> On 10/11/16 01:22, Rob Herring wrote: >>>> >>>> >>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: >>>>> >>>>> >>>>> This patch adds specific compatible to support legacy SCPI protocol. >>>>> >>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>>>> --- >>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> index d1882c4540d0..ebd03fc93135 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power >>>>> operations. >>>>> >>>>> Required properties: >>>>> >>>>> -- compatible : should be "arm,scpi" >>>>> +- compatible : should be >>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or >>>>> above >>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI >>>>> v1.0 >>>> >>>> >>>> >>>> I'd prefer that we explicitly enumerate the old versions. Are there >>>> many? >>>> >>> >>> I understand your concern, but this legacy SCPI protocol was not >>> officially released. It was just WIP which vendors picked up from very >>> early releases. Since they are not numbered, it's hard to have specific >>> compatibles with different versions until v1.0. That's one of the reason >>> to retain platform specific compatible so that we can add any quirks >>> based on them if needed. >>> >>> I will probably add these information in the commit log so that it's >>> clear why we can't do version based compatible. >> >> >> This is exactly my point. By enumerate, I meant having platform >> specific compatibles. Having "arm,legacy-scpi" is pointless because >> who knows what version they followed and they may all be different. >> > > OK, but IIUC Olof's concern wanted a generic one along with the platform > specific compatible which kind of makes sense as so far we have seen > some commonality between Amlogic and Rockchip. > > E.g. Amlogic follows most of the legacy protocol though it deviates in > couple of things which we can handle with platform specific compatible > (in the following patch in the series). When another user(Rockchip ?) > make use of this legacy protocol, we can start using those platform > specific compatible for deviations only. > > Is that not acceptable ? If there's no shared legacy feature set, then it's probably less useful to have a shared less precise compatible value. What the main point I was trying to get across was that we shouldn't expand the generic binding with per-vendor compatible fields, instead we should have those as extensions on the side. I'm also a little apprehensive of using "legacy", it goes in the same bucket as "misc". At some point 1.0 will be legacy too, etc. -Olof
On 10/11/16 19:03, Olof Johansson wrote: > On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> >> >> On 10/11/16 14:12, Rob Herring wrote: >>> >>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> >>> wrote: >>>> >>>> >>>> >>>> On 10/11/16 01:22, Rob Herring wrote: >>>>> >>>>> >>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote: >>>>>> >>>>>> >>>>>> This patch adds specific compatible to support legacy SCPI protocol. >>>>>> >>>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>>>>> --- >>>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- >>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>>> index d1882c4540d0..ebd03fc93135 100644 >>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt >>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power >>>>>> operations. >>>>>> >>>>>> Required properties: >>>>>> >>>>>> -- compatible : should be "arm,scpi" >>>>>> +- compatible : should be >>>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or >>>>>> above >>>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI >>>>>> v1.0 >>>>> >>>>> >>>>> >>>>> I'd prefer that we explicitly enumerate the old versions. Are there >>>>> many? >>>>> >>>> >>>> I understand your concern, but this legacy SCPI protocol was not >>>> officially released. It was just WIP which vendors picked up from very >>>> early releases. Since they are not numbered, it's hard to have specific >>>> compatibles with different versions until v1.0. That's one of the reason >>>> to retain platform specific compatible so that we can add any quirks >>>> based on them if needed. >>>> >>>> I will probably add these information in the commit log so that it's >>>> clear why we can't do version based compatible. >>> >>> >>> This is exactly my point. By enumerate, I meant having platform >>> specific compatibles. Having "arm,legacy-scpi" is pointless because >>> who knows what version they followed and they may all be different. >>> >> >> OK, but IIUC Olof's concern wanted a generic one along with the platform >> specific compatible which kind of makes sense as so far we have seen >> some commonality between Amlogic and Rockchip. >> >> E.g. Amlogic follows most of the legacy protocol though it deviates in >> couple of things which we can handle with platform specific compatible >> (in the following patch in the series). When another user(Rockchip ?) >> make use of this legacy protocol, we can start using those platform >> specific compatible for deviations only. >> >> Is that not acceptable ? > > If there's no shared legacy feature set, then it's probably less > useful to have a shared less precise compatible value. > There is and will be some shared feature set for sure. At the least the standard command set will be shared. > What the main point I was trying to get across was that we shouldn't > expand the generic binding with per-vendor compatible fields, instead > we should have those as extensions on the side. > Yes I get the point. We will have per-vendor compatibles for handle the deviations but generic one to handle the shared set. > I'm also a little apprehensive of using "legacy", it goes in the same > bucket as "misc". At some point 1.0 will be legacy too, etc. > True and I agree, how about "arm,scpi-pre-1.0" instead ? -- Regards, Sudeep
On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > On 10/11/16 19:03, Olof Johansson wrote: >> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> >> wrote: [...] >>> E.g. Amlogic follows most of the legacy protocol though it deviates in >>> couple of things which we can handle with platform specific compatible >>> (in the following patch in the series). When another user(Rockchip ?) >>> make use of this legacy protocol, we can start using those platform >>> specific compatible for deviations only. >>> >>> Is that not acceptable ? >> >> >> If there's no shared legacy feature set, then it's probably less >> useful to have a shared less precise compatible value. >> > > There is and will be some shared feature set for sure. At the least the > standard command set will be shared. > >> What the main point I was trying to get across was that we shouldn't >> expand the generic binding with per-vendor compatible fields, instead >> we should have those as extensions on the side. >> > > Yes I get the point. We will have per-vendor compatibles for handle the > deviations but generic one to handle the shared set. > >> I'm also a little apprehensive of using "legacy", it goes in the same >> bucket as "misc". At some point 1.0 will be legacy too, etc. >> > > True and I agree, how about "arm,scpi-pre-1.0" instead ? That's still meaningless. Convince me that multiple implementations are identical, then we can have a common property. For example, how many releases did ARM make before 1.0. Rob
On 11/11/16 13:34, Rob Herring wrote: > On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> On 10/11/16 19:03, Olof Johansson wrote: >>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> >>> wrote: > > [...] > >>>> E.g. Amlogic follows most of the legacy protocol though it deviates in >>>> couple of things which we can handle with platform specific compatible >>>> (in the following patch in the series). When another user(Rockchip ?) >>>> make use of this legacy protocol, we can start using those platform >>>> specific compatible for deviations only. >>>> >>>> Is that not acceptable ? >>> >>> >>> If there's no shared legacy feature set, then it's probably less >>> useful to have a shared less precise compatible value. >>> >> >> There is and will be some shared feature set for sure. At the least the >> standard command set will be shared. >> >>> What the main point I was trying to get across was that we shouldn't >>> expand the generic binding with per-vendor compatible fields, instead >>> we should have those as extensions on the side. >>> >> >> Yes I get the point. We will have per-vendor compatibles for handle the >> deviations but generic one to handle the shared set. >> >>> I'm also a little apprehensive of using "legacy", it goes in the same >>> bucket as "misc". At some point 1.0 will be legacy too, etc. >>> >> >> True and I agree, how about "arm,scpi-pre-1.0" instead ? > > That's still meaningless. Convince me that multiple implementations > are identical, then we can have a common property. For example, how > many releases did ARM make before 1.0. > None officially, so I tend to agree with you on this. But so far we have seen some commonality between Rockchip and Amlogic implementations, which in fact shares some commonality with early release of SCPI from ARM (there are based on the same SCP code base, which is closed source and released to partners only). ARM improved the specification and the code base before the official release but by then it was adopted(as usual we were late ;)) IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0" and platform specific "amlogic,meson-gxbb-scpi"
On 11/11/16 14:19, Sudeep Holla wrote: > > > On 11/11/16 13:34, Rob Herring wrote: >> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> >> wrote: [...] >>> >>> True and I agree, how about "arm,scpi-pre-1.0" instead ? >> >> That's still meaningless. Convince me that multiple implementations >> are identical, then we can have a common property. For example, how >> many releases did ARM make before 1.0. >> > > None officially, so I tend to agree with you on this. > > But so far we have seen some commonality between Rockchip and Amlogic > implementations, which in fact shares some commonality with early > release of SCPI from ARM (there are based on the same SCP code base, > which is closed source and released to partners only). ARM improved the > specification and the code base before the official release but by then > it was adopted(as usual we were late ;)) > > IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0" > and platform specific "amlogic,meson-gxbb-scpi" > Rob and Olof, is it convincing enough reason to have generic compatible? Or you prefer to drop it ? I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I need to send PR as it's getting late now.
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index d1882c4540d0..ebd03fc93135 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations. Required properties: -- compatible : should be "arm,scpi" +- compatible : should be + * "arm,scpi" : For implementations complying to SCPI v1.0 or above + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0 - mboxes: List of phandle and mailbox channel specifiers All the channels reserved by remote SCP firmware for use by SCPI message protocol should be specified in any order
This patch adds specific compatible to support legacy SCPI protocol. Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)