All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Li Yang <leoli@freescale.com>,
	devicetree@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Bhupesh Sharma <bhupesh.sharma@freescale.com>,
	Catalin.Marinas@arm.com, olof@lixom.net, will.deacon@arm.com,
	Minghuan Lian <Minghuan.Lian@freescale.com>,
	marc.zyngier@arm.com, bhupesh.linux@gmail.com,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A
Date: Wed, 09 Sep 2015 11:07:14 +0200	[thread overview]
Message-ID: <5383634.Mln7J3sdWP@wuerfel> (raw)
In-Reply-To: <CADRPPNR-cSSQC5sLMmoqcxX46J6hdULa_V4v2BK7T8s8pcX0cg@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, bhupesh.linux@gmail.com,
	Bhupesh Sharma <bhupesh.sharma@freescale.com>,
	Catalin.Marinas@arm.com, will.deacon@arm.com,
	Minghuan Lian <Minghuan.Lian@freescale.com>,
	marc.zyngier@arm.com, olof@lixom.net,
	Li Yang <leoli@freescale.com>,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A
Date: Wed, 09 Sep 2015 11:07:14 +0200	[thread overview]
Message-ID: <5383634.Mln7J3sdWP@wuerfel> (raw)
In-Reply-To: <CADRPPNR-cSSQC5sLMmoqcxX46J6hdULa_V4v2BK7T8s8pcX0cg@mail.gmail.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A
Date: Wed, 09 Sep 2015 11:07:14 +0200	[thread overview]
Message-ID: <5383634.Mln7J3sdWP@wuerfel> (raw)
In-Reply-To: <CADRPPNR-cSSQC5sLMmoqcxX46J6hdULa_V4v2BK7T8s8pcX0cg@mail.gmail.com>

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

  parent reply	other threads:[~2015-09-09  9:07 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04  6:57 [PATCH v2 00/10] ARM64: Update support for FSL's LS2085A SoC Bhupesh Sharma
2015-09-04  6:57 ` Bhupesh Sharma
2015-09-04  6:57 ` [PATCH v2 01/10] arm64: Use generic Layerscape SoC family naming & rename LS2085A to LS2080A Bhupesh Sharma
2015-09-04  6:57   ` Bhupesh Sharma
2015-09-04 16:31   ` Li Yang
2015-09-04 16:31     ` Li Yang
2015-09-04 20:10     ` Sharma Bhupesh
2015-09-04 20:10       ` Sharma Bhupesh
2015-09-08 20:24   ` Stuart Yoder
2015-09-08 20:24     ` Stuart Yoder
2015-09-09  3:54     ` Sharma Bhupesh
2015-09-09  3:54       ` Sharma Bhupesh
2015-09-04  6:57 ` [PATCH v2 02/10] Documentation: DT: Add entry for FSL LS2080A QDS and RDB boards Bhupesh Sharma
2015-09-04  6:57   ` Bhupesh Sharma
2015-09-04  6:57 ` [PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards Bhupesh Sharma
2015-09-04  6:57   ` Bhupesh Sharma
2015-09-04 16:56   ` Li Yang
2015-09-04 16:56     ` Li Yang
2015-09-04 20:16     ` Sharma Bhupesh
2015-09-04 20:16       ` Sharma Bhupesh
2015-09-04 20:16       ` Sharma Bhupesh
2015-09-04 21:12       ` Li Yang
2015-09-04 21:12         ` Li Yang
2015-09-04 21:12         ` Li Yang
2015-09-05  8:11         ` Sharma Bhupesh
2015-09-05  8:11           ` Sharma Bhupesh
2015-09-05  8:11           ` Sharma Bhupesh
     [not found]           ` <BY1PR0301MB130339BD3B988DC938AA524482560-M1kb196zaoqj58cWwZvmNZwN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2015-09-09 23:38             ` Li Yang
2015-09-09 23:38               ` Li Yang
2015-09-09 23:38               ` Li Yang
2015-09-04  6:57 ` [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A Bhupesh Sharma
2015-09-04  6:57   ` Bhupesh Sharma
2015-09-04 17:56   ` Leo Li
2015-09-04 17:56     ` Leo Li
2015-09-04 20:20     ` Sharma Bhupesh
2015-09-04 20:20       ` Sharma Bhupesh
2015-09-04 20:20       ` Sharma Bhupesh
2015-09-06  2:25       ` Lian M.H.
2015-09-06  2:25         ` Lian M.H.
2015-09-06  2:25         ` Lian M.H.
2015-09-06 20:00         ` Sharma Bhupesh
2015-09-06 20:00           ` Sharma Bhupesh
2015-09-06 20:00           ` Sharma Bhupesh
2015-09-07 11:32   ` Arnd Bergmann
2015-09-07 11:32     ` Arnd Bergmann
2015-09-08 20:06     ` Li Yang
2015-09-08 20:06       ` Li Yang
2015-09-08 20:06       ` Li Yang
2015-09-09  3:45       ` Sharma Bhupesh
2015-09-09  3:45         ` Sharma Bhupesh
2015-09-09  3:45         ` Sharma Bhupesh
2015-09-09  9:07       ` Arnd Bergmann [this message]
2015-09-09  9:07         ` Arnd Bergmann
2015-09-09  9:07         ` Arnd Bergmann
2015-09-09 23:50         ` Li Yang
2015-09-09 23:50           ` Li Yang
2015-09-09 23:50           ` Li Yang
2015-09-10  1:52           ` Lian M.H.
2015-09-10  1:52             ` Lian M.H.
2015-09-10  1:52             ` Lian M.H.
2015-09-04  6:57 ` [PATCH v2 05/10] doc/bindings: Update clk-qoriq bindings for FSL's chassis-3.0 SoCs Bhupesh Sharma
2015-09-04  6:57   ` Bhupesh Sharma
2015-09-09 16:46   ` Scott Wood
2015-09-09 16:46     ` Scott Wood
2015-09-04  6:57 ` [PATCH v2 06/10] clk: qoriq: Add ls2080a support Bhupesh Sharma
2015-09-04  6:57   ` Bhupesh Sharma
2015-09-04 20:01   ` Li Yang
2015-09-04 20:01     ` Li Yang
2015-09-04 20:09     ` Sharma Bhupesh
2015-09-04 20:09       ` Sharma Bhupesh
2015-09-04 21:06       ` Li Yang
2015-09-04 21:06         ` Li Yang
2015-09-09 16:41         ` Scott Wood
2015-09-09 16:41           ` Scott Wood
2015-09-09 16:39   ` Scott Wood
2015-09-09 16:39     ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5383634.Mln7J3sdWP@wuerfel \
    --to=arnd@arndb.de \
    --cc=Catalin.Marinas@arm.com \
    --cc=Minghuan.Lian@freescale.com \
    --cc=bhupesh.linux@gmail.com \
    --cc=bhupesh.sharma@freescale.com \
    --cc=devicetree@vger.kernel.org \
    --cc=leoli@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=olof@lixom.net \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.