Re: [PATCH v2 1/2] dt-bindings: Update iProc GPIO bindings

[Ray Jui]

Hi Rob,

On 5/11/2016 7:06 AM, Rob Herring wrote:
> 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

Thanks for the clarification. I think I've got all the information I 
need. Will revise and send out PATCH v3 when I get a chance.

Thanks,

Ray