On Wed, May 04, 2016 at 09:29:04AM -0700, Ray Jui wrote: > Hi Rob, > > On 5/4/2016 6:20 AM, Rob Herring wrote: > >On Mon, May 02, 2016 at 01:51:47PM -0700, Ray Jui wrote: > >>Update the iProc GPIO binding document to add new compatible strings > >>"brcm,iproc-gpio-v2" and "brcm,iproc-gpio-v3" for the 2nd and 3rd > >>generation of the iProc GPIO controllers > >> > >>Signed-off-by: Ray Jui <ray.jui@xxxxxxxxxxxx> > >>--- > >> Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt | 11 ++++++++++- > >> 1 file changed, 10 insertions(+), 1 deletion(-) > >> > >>diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt > >>index e427792..3a56649 100644 > >>--- a/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt > >>+++ b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt > >>@@ -4,7 +4,16 @@ Required properties: > >> > >> - compatible: > >> Must be "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", > >>- "brcm,cygnus-crmu-gpio" or "brcm,iproc-gpio" > >>+ or "brcm,cygnus-crmu-gpio" for Cygnus SoCs > >>+ > >>+ "brcm,iproc-gpio" for the first generation of the GPIO controller that > >>+ supports full-featured pinctrl and GPIO functions used in iProc based SoCs > >>+ > >>+ "brcm,iproc-gpio-v2" for the second generation of the GPIO controller that > >>+ has the drive strength pinctrl support disabled, e.g., in the iProc NSP SoC > >>+ > >>+ "brcm,iproc-gpio-v3" for the third generation of the GPIO controller that > >>+ has the general pinctrl support completely disabled > > > >You can have these for driver matching, but you still need SoC specific > >compatible strings. > > > >Rob > > > > I think I'm missing something and hope you can help to clarify here. It > looks like the notion of v2, v3 should only be used if there's an indeed an > revision update on the controller IP itself, correct? Yes, but only if v2, v3 is actually a meaningful number rather than something made up. You have to have a well defined process of IP revisions which I have not seen during my time in chip companies, so I'm generally suspicious of version numbers. The exception is FPGA IP blocks. > In our case, if the same revision of GPIO controller is used but instead > synthesized differently with different SoCs, then you are suggesting here > that it should be dealt with SoC specific compatible string, correct? Yes, that and/or integration differences is why you need SoC specific compatible strings. A block could be "identical" but have different max frequency for example. > For example, for the GPIO controller on NSP where drive strength is > disabled, the compatible string in DT should look like this? > > compatible = "brcm,iproc-gpio", "brcm,iproc-gpio-nsp"; Yes, but reverse the order. Most specific to least specific. > > For the GPIO controller on Stingray where pinconf is completely disabled, > the compatible string in DT should look like: > > compatible = "brcm,iproc-gpio", "brcm,iproc-gpio-stingray"; > > Is that correct? > > Thanks, > > Ray -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
