From: Simon Horman <hidden> Date: 2016-02-24 01:56:31
Hi,
this series adds fallback bindings for R-Car Gen 1 and Gen 2 SoCs and
SoC-specific bindings for the r8a779[234] SoCs which are R-Car Gen 2 SoCs.
The aim is to provide consistent bindings for R-Car Gen 1 and Gen 2
SoCs in a maner consistent with that progressively being used
for drivers for other IP blocks used by Renesas SoCs.
For changes since v1 see individial patch changelogs.
Based on linux-can-next/master
Simon Horman (2):
CAN: rcar: add gen[12] fallback compatibility strings
CAN: rcar: add device tree support for r8a779[234]
Documentation/devicetree/bindings/net/can/rcar_can.txt | 11 ++++++++++-
drivers/net/can/rcar_can.c | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.1.4
From: Simon Horman <hidden> Date: 2016-02-24 01:56:33
Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.
By documenting these compat stings they may be used in DTSs shipped, for
example as part of ROMs. They must be used in conjunction with the Gen2
fallback compat string. At this time there are no known differences between
the r8a779[234] IP blocks and that implemented by the driver for the Gen2
fallback compat string. Thus there is no need to update the driver as the
use of the Gen2 fallback compat string will activate the correct code in
the current driver while leaving the option for r8a779[234]-specific driver
code to be activated in an updated driver should the need arise.
Signed-off-by: Simon Horman <redacted>
---
v2
* Do not update driver as per changelog
* Minor edit of changelog
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 3 +++
1 file changed, 3 insertions(+)
@@ -6,6 +6,9 @@ Required properties: "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.+ "renesas,can-r8a7792" if CAN controller is a part of R8A7792 SoC.+ "renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC.+ "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC. "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. "renesas,rcar-gen2-can" for a generic R-Car Gen2 compatible device. When compatible with the generic version, nodes must list the
From: Simon Horman <hidden> Date: 2016-02-24 01:56:44
Add fallback compatibility string for R-Car Gen 1 and Gen2.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 1 and Gen 2. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7779 is older than r8a7778 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 <redacted>
Acked-by: Rob Herring <robh@kernel.org>
--
v2
* Added Ack from Rob Herring
* Place 'can' at the end of new compatibility strings,
this is in keeping with current guidelines for compatibility string names.
* Describe use of fallback compatibility strings in conjunction with
per-SoC compatibility strings
* Enhanced changelog text
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 8 +++++++-
drivers/net/can/rcar_can.c | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
@@ -6,6 +6,12 @@ Required properties: "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC.+ "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.+ "renesas,rcar-gen2-can" for a generic R-Car Gen2 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: physical base address and size of the R-Car CAN register map. - interrupts: interrupt specifier for the sole interrupt. - clocks: phandles and clock specifiers for 3 CAN clock inputs.
On Wed, Feb 24, 2016 at 2:56 AM, Simon Horman
[off-list ref] wrote:
Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.
By documenting these compat stings they may be used in DTSs shipped, for
example as part of ROMs. They must be used in conjunction with the Gen2
fallback compat string. At this time there are no known differences between
the r8a779[234] IP blocks and that implemented by the driver for the Gen2
fallback compat string. Thus there is no need to update the driver as the
use of the Gen2 fallback compat string will activate the correct code in
the current driver while leaving the option for r8a779[234]-specific driver
code to be activated in an updated driver should the need arise.
Signed-off-by: Simon Horman <redacted>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
On Wed, Feb 24, 2016 at 2:56 AM, Simon Horman
[off-list ref] wrote:
Add fallback compatibility string for R-Car Gen 1 and Gen2.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 1 and Gen 2. But beyond that its not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7779 is older than r8a7778 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 <redacted>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2016-02-24 08:25:20
On 02/24/2016 02:56 AM, Simon Horman wrote:
this series adds fallback bindings for R-Car Gen 1 and Gen 2 SoCs and
SoC-specific bindings for the r8a779[234] SoCs which are R-Car Gen 2 SoCs.
The aim is to provide consistent bindings for R-Car Gen 1 and Gen 2
SoCs in a maner consistent with that progressively being used
for drivers for other IP blocks used by Renesas SoCs.
For changes since v1 see individial patch changelogs.
Based on linux-can-next/master
Applied to can-next.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |