Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1348652 > unrolled thread
| Started by | Simon Horman <horms+renesas@verge.net.au> |
|---|---|
| First post | 2016-03-03 01:40 +0100 |
| Last post | 2016-03-03 10:30 +0100 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding Simon Horman <horms+renesas@verge.net.au> - 2016-03-03 01:40 +0100
Re: [PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding Geert Uytterhoeven <geert@linux-m68k.org> - 2016-03-03 09:20 +0100
RE: [PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> - 2016-03-03 10:30 +0100
| From | Simon Horman <horms+renesas@verge.net.au> |
|---|---|
| Date | 2016-03-03 01:40 +0100 |
| Subject | [PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding |
| Message-ID | <r8pt8-7tT-21@gated-at.bofh.it> |
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme being adopted for
drivers for Renesas SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v2
* Use renesas,rcar-gen3-usb-phy rather than renesas,usb-phy-gen3 as
the new compatibility string to fit in with the preferred scheme
for new compatibility string names.
---
Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 ++++++++--
drivers/phy/phy-rcar-gen3-usb2.c | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index eaf7e9b7ce6b..86826ca2fdef 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -6,6 +6,12 @@ This file provides information on what the device node for the R-Car generation
Required properties:
- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795
SoC.
+ "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible device.
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
- reg: offset and length of the partial USB 2.0 Host register block.
- clocks: clock phandle and specifier pair(s).
- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
@@ -19,14 +25,14 @@ channel as USB OTG:
Example (R-Car H3):
usb-phy@ee080200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible = "renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";
reg = <0 0xee080200 0 0x700>;
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
};
usb-phy@ee0a0200 {
- compatible = "renesas,usb2-phy-r8a7795";
+ compatible = "renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";
reg = <0 0xee0a0200 0 0x700>;
clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
};
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index bc4f7dd821aa..257be74f93f5 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -251,6 +251,7 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void *_ch)
static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
{ .compatible = "renesas,usb2-phy-r8a7795" },
+ { .compatible = "renesas,rcar-gen3-usb2-phy" },
{ }
};
MODULE_DEVICE_TABLE(of, rcar_gen3_phy_usb2_match_table);
--
2.1.4
[toc] | [next] | [standalone]
| From | Geert Uytterhoeven <geert@linux-m68k.org> |
|---|---|
| Date | 2016-03-03 09:20 +0100 |
| Message-ID | <r8wEi-4cL-7@gated-at.bofh.it> |
| In reply to | #1348652 |
On Thu, Mar 3, 2016 at 1:38 AM, Simon Horman <horms+renesas@verge.net.au> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2
> * Use renesas,rcar-gen3-usb-phy rather than renesas,usb-phy-gen3 as
FWIW, "renesas,rcar-gen3-usb2-phy" ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[toc] | [prev] | [next] | [standalone]
| From | Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> |
|---|---|
| Date | 2016-03-03 10:30 +0100 |
| Message-ID | <r8xK2-4Sk-9@gated-at.bofh.it> |
| In reply to | #1348870 |
Hi Simon-san, > Sent: Thursday, March 03, 2016 5:13 PM > > On Thu, Mar 3, 2016 at 1:38 AM, Simon Horman <horms+renesas@verge.net.au> wrote: > > In the case of Renesas R-Car hardware we know that there are generations of > > SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the > > relationship between IP blocks might be. For example, I believe that > > r8a7790 is older than r8a7791 but that doesn't imply that the latter is a > > descendant of the former or vice versa. > > > > We can, however, by examining the documentation and behaviour of the > > hardware at run-time observe that the current driver implementation appears > > to be compatible with the IP blocks on SoCs within a given generation. > > > > For the above reasons and convenience when enabling new SoCs a > > per-generation fallback compatibility string scheme being adopted for > > drivers for Renesas SoCs. > > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Best regards, Yoshihiro Shimoda
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web