Re: [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

Re: [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> This patch adds bindings for QIXIS FPGA controller found on FSL boards.

A general comment: when you are updating the device tree bindings.
You should cc the devicetree@vger.kernel.org mailing list.

>
> Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board FPGA/CPLD
> connected to the IFC controller. The bindings specified in this patch
> cater to those on-board FPGA/CPLD controllers.

We already have the binding defined in
Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
should just move it to a more generic location.

Regards,
Leo

Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Leo Li]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> Add the documentation for compatible string "fsl,ls2080a-pcie"
> for Freescale's LS2080A platform.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> ---
>  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 6286f04..e72e68f 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>  and thus inherits all the common properties defined in designware-pcie.txt.
>
>  Required properties:
> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
> +  "fsl,ls2080a-pcie".

Make it generic like "fsl,<chip>-pcie"

- Leo

RE: [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Sharma Bhupesh]

> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com]
> Sent: Friday, September 04, 2015 10:27 PM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > This patch adds bindings for QIXIS FPGA controller found on FSL boards.
> 
> A general comment: when you are updating the device tree bindings.
> You should cc the devicetree@vger.kernel.org mailing list.
> 
> >
> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
> > FPGA/CPLD connected to the IFC controller. The bindings specified in
> > this patch cater to those on-board FPGA/CPLD controllers.
> 
> We already have the binding defined in
> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
> should just move it to a more generic location.

Consolidation of powerpc and ARM bindings is something that needs to be
targeted by a separate patch-series, perhaps in future.

There are a number of duplications that can be looked into, but I don't
think this patchset should depend on that.

Regards,
Bhupesh

RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Sharma Bhupesh]

> From: Leo Li [mailto:pku.leo@gmail.com]
> Sent: Friday, September 04, 2015 11:27 PM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > Add the documentation for compatible string "fsl,ls2080a-pcie"
> > for Freescale's LS2080A platform.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > ---
> >  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index 6286f04..e72e68f 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> > Designware PCIe IP  and thus inherits all the common properties defined
> in designware-pcie.txt.
> >
> >  Required properties:
> > -- compatible: should contain the platform identifier such as
> "fsl,ls1021a-pcie"
> > +- compatible: should contain the platform identifier such as
> > +"fsl,ls1021a-pcie",
> > +  "fsl,ls2080a-pcie".
> 
> Make it generic like "fsl,<chip>-pcie"

Minghuan, if you don't have an objection, I would like to address Leo's suggestion
in v3 of this series as I think it is a valid one.

Please share your views. 

Regards,
Bhupesh

Re: [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
<bhupesh.sharma@freescale.com> wrote:
>> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com]
>> Sent: Friday, September 04, 2015 10:27 PM
>> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
>> <bhupesh.sharma@freescale.com> wrote:
>> > This patch adds bindings for QIXIS FPGA controller found on FSL boards.
>>
>> A general comment: when you are updating the device tree bindings.
>> You should cc the devicetree@vger.kernel.org mailing list.
>>
>> >
>> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
>> > FPGA/CPLD connected to the IFC controller. The bindings specified in
>> > this patch cater to those on-board FPGA/CPLD controllers.
>>
>> We already have the binding defined in
>> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
>> should just move it to a more generic location.
>
> Consolidation of powerpc and ARM bindings is something that needs to be
> targeted by a separate patch-series, perhaps in future.
>
> There are a number of duplications that can be looked into, but I don't
> think this patchset should depend on that.

There might be some duplication, but we shouldn't be adding more.  :)
I would rather you directly updating that file than creating a new
file even though the original one was in a wrong directory.

Regards,
Leo

RE: [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Sharma Bhupesh]

> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com]
> Sent: Saturday, September 05, 2015 2:43 AM
> On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
> <bhupesh.sharma@freescale.com> wrote:
> >> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com]
> >> Sent: Friday, September 04, 2015 10:27 PM On Fri, Sep 4, 2015 at 1:57
> >> AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
> >> > This patch adds bindings for QIXIS FPGA controller found on FSL
> boards.
> >>
> >> A general comment: when you are updating the device tree bindings.
> >> You should cc the devicetree@vger.kernel.org mailing list.
> >>
> >> >
> >> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
> >> > FPGA/CPLD connected to the IFC controller. The bindings specified
> >> > in this patch cater to those on-board FPGA/CPLD controllers.
> >>
> >> We already have the binding defined in
> >> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
> >> should just move it to a more generic location.
> >
> > Consolidation of powerpc and ARM bindings is something that needs to
> > be targeted by a separate patch-series, perhaps in future.
> >
> > There are a number of duplications that can be looked into, but I
> > don't think this patchset should depend on that.
> 
> There might be some duplication, but we shouldn't be adding more.  :) I
> would rather you directly updating that file than creating a new file
> even though the original one was in a wrong directory.
> 

IMO a PowerPC binding update makes no sense in a ARM machine patchset sent
on a arm specific mailing list.

I would like to wait to hear what maintainers have to say on the same.

Regards,
Bhupesh

RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Lian M.H.]

Hi Bhupesh

I agree with Leo whose suggestion is a better.

Thanks,
Minghuan 

> -----Original Message-----
> From: Sharma Bhupesh-B45370
> Sent: Saturday, September 05, 2015 4:20 AM
> To: Leo Li <pku.leo@gmail.com>; Lian Minghuan-B31939
> <Minghuan.Lian@freescale.com>
> Cc: Arnd Bergmann <arnd@arndb.de>; Mark Rutland
> <mark.rutland@arm.com>; linux-arm-kernel@lists.infradead.org;
> marc.zyngier@arm.com; linux-clk@vger.kernel.org;
> Catalin.Marinas@arm.com; will.deacon@arm.com; olof@lixom.net; Bhupesh
> SHARMA <bhupesh.linux@gmail.com>; devicetree@vger.kernel.org
> Subject: RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding
> documentation for LS2080A
> 
> > From: Leo Li [mailto:pku.leo@gmail.com]
> > Sent: Friday, September 04, 2015 11:27 PM On Fri, Sep 4, 2015 at 1:57
> > AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
> > > Add the documentation for compatible string "fsl,ls2080a-pcie"
> > > for Freescale's LS2080A platform.
> > >
> > > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > > ---
> > >  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > index 6286f04..e72e68f 100644
> > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> > > Designware PCIe IP  and thus inherits all the common properties
> > > defined
> > in designware-pcie.txt.
> > >
> > >  Required properties:
> > > -- compatible: should contain the platform identifier such as
> > "fsl,ls1021a-pcie"
> > > +- compatible: should contain the platform identifier such as
> > > +"fsl,ls1021a-pcie",
> > > +  "fsl,ls2080a-pcie".
> >
> > Make it generic like "fsl,<chip>-pcie"
> 
> Minghuan, if you don't have an objection, I would like to address Leo's
> suggestion in v3 of this series as I think it is a valid one.
> 
> Please share your views.
> 
> Regards,
> Bhupesh

RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Sharma Bhupesh]

> From: Lian Minghuan-B31939
> Sent: Sunday, September 06, 2015 7:56 AM
> Hi Bhupesh
> 
> I agree with Leo whose suggestion is a better.

Ok, thanks.

I will make this change in v3 patchset then.

Regards,
Bhupesh

> > From: Sharma Bhupesh-B45370
> > Sent: Saturday, September 05, 2015 4:20 AM
> > > From: Leo Li [mailto:pku.leo@gmail.com]
> > > Sent: Friday, September 04, 2015 11:27 PM On Fri, Sep 4, 2015 at
> > > 1:57 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
> > > > Add the documentation for compatible string "fsl,ls2080a-pcie"
> > > > for Freescale's LS2080A platform.
> > > >
> > > > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > > > ---
> > > >  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > index 6286f04..e72e68f 100644
> > > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> > > > Designware PCIe IP  and thus inherits all the common properties
> > > > defined
> > > in designware-pcie.txt.
> > > >
> > > >  Required properties:
> > > > -- compatible: should contain the platform identifier such as
> > > "fsl,ls1021a-pcie"
> > > > +- compatible: should contain the platform identifier such as
> > > > +"fsl,ls1021a-pcie",
> > > > +  "fsl,ls2080a-pcie".
> > >
> > > Make it generic like "fsl,<chip>-pcie"
> >
> > Minghuan, if you don't have an objection, I would like to address
> > Leo's suggestion in v3 of this series as I think it is a valid one.
> >
> > Please share your views.
> >
> > Regards,
> > Bhupesh

Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Li Yang]

On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
>> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>>  and thus inherits all the common properties defined in designware-pcie.txt.
>>
>>  Required properties:
>> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
>> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
>> +  "fsl,ls2080a-pcie".
>>  - reg: base addresses and lengths of the PCIe controller
>>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>>    entry for each entry in the interrupt-names property.
>>
>
> Are the two PCIe hosts mutually compatible? If they are, you should mandate
> one of the strings as the base model for identification, with the additional
> model being optional for identification of the specific SoC.

It seems that controllers on these chips are not exactly the same.
They will get different driver data by matching the compatible
strings.  Probably we could define a more generic compatible string,
such as "fsl,layerscape-pcie" or "fsl,ls-pcie".

>
> It would also be good to add a string with the specific version number of the
> designware PCIe block that is being used there.

The binding has mentioned to reference the designware-pcie.txt.  But
it might be more clear to mention the designware compatible string
"snps,dw-pcie" again in the compatible part.  Currently there is no
version number defined in the designware-pcie binding.  It might be
hard to get this information for some SoCs.

Regards,
Leo

RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Sharma Bhupesh]

> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com]
> Sent: Wednesday, September 09, 2015 1:36 AM
> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> >> Designware PCIe IP  and thus inherits all the common properties
> defined in designware-pcie.txt.
> >>
> >>  Required properties:
> >> -- compatible: should contain the platform identifier such as
> "fsl,ls1021a-pcie"
> >> +- compatible: should contain the platform identifier such as
> >> +"fsl,ls1021a-pcie",
> >> +  "fsl,ls2080a-pcie".
> >>  - reg: base addresses and lengths of the PCIe controller
> >>  - interrupts: A list of interrupt outputs of the controller. Must
> contain an
> >>    entry for each entry in the interrupt-names property.
> >>
> >
> > Are the two PCIe hosts mutually compatible? If they are, you should
> > mandate one of the strings as the base model for identification, with
> > the additional model being optional for identification of the specific
> SoC.
> 
> It seems that controllers on these chips are not exactly the same.
> They will get different driver data by matching the compatible strings.
> Probably we could define a more generic compatible string, such as
> "fsl,layerscape-pcie" or "fsl,ls-pcie".

Yes, Minghaun captured the differences in the two versions in the v1 review
discussion for the DTS here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/338343.html

Regards,
Bhupesh

Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Arnd Bergmann]

On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
> >>  and thus inherits all the common properties defined in designware-pcie.txt.
> >>
> >>  Required properties:
> >> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
> >> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
> >> +  "fsl,ls2080a-pcie".
> >>  - reg: base addresses and lengths of the PCIe controller
> >>  - interrupts: A list of interrupt outputs of the controller. Must contain an
> >>    entry for each entry in the interrupt-names property.
> >>
> >
> > Are the two PCIe hosts mutually compatible? If they are, you should mandate
> > one of the strings as the base model for identification, with the additional
> > model being optional for identification of the specific SoC.
> 
> It seems that controllers on these chips are not exactly the same.
> They will get different driver data by matching the compatible
> strings.  Probably we could define a more generic compatible string,
> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
> 
> >
> > It would also be good to add a string with the specific version number of the
> > designware PCIe block that is being used there.
> 
> The binding has mentioned to reference the designware-pcie.txt.  But
> it might be more clear to mention the designware compatible string
> "snps,dw-pcie" again in the compatible part.  Currently there is no
> version number defined in the designware-pcie binding.  It might be
> hard to get this information for some SoCs.

For most of them, the information is available and then it should be
added. Obviously if you can't find it out, it's hard to guess and
you have to leave it out for that particular chip.

A lot of devices also have some internal version register that you
can read out.

	Arnd

Re: [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Sat, Sep 5, 2015 at 3:11 AM, Sharma Bhupesh
<bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> From: pku.leo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [mailto:pku.leo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>> Sent: Saturday, September 05, 2015 2:43 AM
>> On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
>> <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> >> From: pku.leo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [mailto:pku.leo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
>> >> Sent: Friday, September 04, 2015 10:27 PM On Fri, Sep 4, 2015 at 1:57
>> >> AM, Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> >> > This patch adds bindings for QIXIS FPGA controller found on FSL
>> boards.
>> >>
>> >> A general comment: when you are updating the device tree bindings.
>> >> You should cc the devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org mailing list.
>> >>
>> >> >
>> >> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
>> >> > FPGA/CPLD connected to the IFC controller. The bindings specified
>> >> > in this patch cater to those on-board FPGA/CPLD controllers.
>> >>
>> >> We already have the binding defined in
>> >> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
>> >> should just move it to a more generic location.
>> >
>> > Consolidation of powerpc and ARM bindings is something that needs to
>> > be targeted by a separate patch-series, perhaps in future.
>> >
>> > There are a number of duplications that can be looked into, but I
>> > don't think this patchset should depend on that.
>>
>> There might be some duplication, but we shouldn't be adding more.  :) I
>> would rather you directly updating that file than creating a new file
>> even though the original one was in a wrong directory.
>>
>
> IMO a PowerPC binding update makes no sense in a ARM machine patchset sent
> on a arm specific mailing list.

So the best approach is to merge the change with the original binding
and put it into a common place.  Although there were a lot of non-arch
specific bindings placed into the arch folder, we should stop adding
more now.

Regards,
Leo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Li Yang]

On Wed, Sep 9, 2015 at 4:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
>> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
>> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>> >>  and thus inherits all the common properties defined in designware-pcie.txt.
>> >>
>> >>  Required properties:
>> >> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
>> >> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
>> >> +  "fsl,ls2080a-pcie".
>> >>  - reg: base addresses and lengths of the PCIe controller
>> >>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>> >>    entry for each entry in the interrupt-names property.
>> >>
>> >
>> > Are the two PCIe hosts mutually compatible? If they are, you should mandate
>> > one of the strings as the base model for identification, with the additional
>> > model being optional for identification of the specific SoC.
>>
>> It seems that controllers on these chips are not exactly the same.
>> They will get different driver data by matching the compatible
>> strings.  Probably we could define a more generic compatible string,
>> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
>>
>> >
>> > It would also be good to add a string with the specific version number of the
>> > designware PCIe block that is being used there.
>>
>> The binding has mentioned to reference the designware-pcie.txt.  But
>> it might be more clear to mention the designware compatible string
>> "snps,dw-pcie" again in the compatible part.  Currently there is no
>> version number defined in the designware-pcie binding.  It might be
>> hard to get this information for some SoCs.
>
> For most of them, the information is available and then it should be
> added. Obviously if you can't find it out, it's hard to guess and
> you have to leave it out for that particular chip.

Actually I don't know any approach to get the version number of the
designware block used.  Maybe they are actually using the same version
of the IP block, and the differences in the driver are actually caused
by the differences in SoC integration.

>
> A lot of devices also have some internal version register that you
> can read out.

There doesn't seem to be this kind of register for the PCIe block.

Minghuan,

Please correct me if you know more. :)

Regards,
Leo

RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Lian M.H.]

Hi Leo and Bergmann,

Please see my comments inline.

> -----Original Message-----
> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com] On Behalf Of Li Yang
> Sent: Thursday, September 10, 2015 7:50 AM
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Mark
> Rutland <mark.rutland@arm.com>; Sharma Bhupesh-B45370
> <bhupesh.sharma@freescale.com>; Catalin.Marinas@arm.com;
> olof@lixom.net; will.deacon@arm.com; Lian Minghuan-B31939
> <Minghuan.Lian@freescale.com>; marc.zyngier@arm.com; Bhupesh SHARMA
> <bhupesh.linux@gmail.com>; linux-clk@vger.kernel.org
> Subject: Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding
> documentation for LS2080A
> 
> On Wed, Sep 9, 2015 at 4:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
> >> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> >> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> >> >> Designware PCIe IP  and thus inherits all the common properties
> defined in designware-pcie.txt.
> >> >>
> >> >>  Required properties:
> >> >> -- compatible: should contain the platform identifier such as
> "fsl,ls1021a-pcie"
> >> >> +- compatible: should contain the platform identifier such as
> >> >> +"fsl,ls1021a-pcie",
> >> >> +  "fsl,ls2080a-pcie".
> >> >>  - reg: base addresses and lengths of the PCIe controller
> >> >>  - interrupts: A list of interrupt outputs of the controller. Must contain
> an
> >> >>    entry for each entry in the interrupt-names property.
> >> >>
> >> >
> >> > Are the two PCIe hosts mutually compatible? If they are, you should
> >> > mandate one of the strings as the base model for identification,
> >> > with the additional model being optional for identification of the specific
> SoC.
> >>
> >> It seems that controllers on these chips are not exactly the same.
> >> They will get different driver data by matching the compatible
> >> strings.  Probably we could define a more generic compatible string,
> >> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
> >>
> >> >
> >> > It would also be good to add a string with the specific version
> >> > number of the designware PCIe block that is being used there.
> >>
> >> The binding has mentioned to reference the designware-pcie.txt.  But
> >> it might be more clear to mention the designware compatible string
> >> "snps,dw-pcie" again in the compatible part.  Currently there is no
> >> version number defined in the designware-pcie binding.  It might be
> >> hard to get this information for some SoCs.
> >
> > For most of them, the information is available and then it should be
> > added. Obviously if you can't find it out, it's hard to guess and you
> > have to leave it out for that particular chip.
> 
> Actually I don't know any approach to get the version number of the
> designware block used.  Maybe they are actually using the same version of
> the IP block, and the differences in the driver are actually caused by the
> differences in SoC integration.
> 
> >
> > A lot of devices also have some internal version register that you can
> > read out.
> 
> There doesn't seem to be this kind of register for the PCIe block.
> 
[Lian Minghuan-B31939]  Yes. There is no register to show PCIe block version according to reference manual.
I agree that differences in the driver are caused by the differences in SoC integration.

> Minghuan,
> 
> Please correct me if you know more. :)
> 
> Regards,
> Leo