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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
