Hi Geert,

On Monday 30 December 2013 10:37:24 Geert Uytterhoeven wrote:

On Mon, Dec 30, 2013 at 12:22 AM, Laurent Pinchart wrote:

quoted

On Friday 27 December 2013 20:01:53 Geert Uytterhoeven wrote:

quoted

On Fri, Dec 27, 2013 at 5:18 PM, Laurent Pinchart wrote:

quoted

On Tuesday 24 December 2013 12:56:48 Geert Uytterhoeven wrote:

quoted

+++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt

@@ -0,0 +1,27 @@
+Device tree configuration for Renesas RSPI/QSPI driver
+
+Required properties:
+- compatible      : "renesas,rspi-<soctype>". "renesas,rspi-rz" as

fallback,
+                    or
+                    "renesas,qspi-<soctype>", "renesas,qspi-rcar" as
fallback.

I think you need to be a bit more verbose here and explain when to use
rspi and when to use qspi. I'm also wondering where we need the -rz and
-
rcar

OK.

quoted

suffixes for the generic compatible strings.

The rationale behind this is that RSPI DT would apply to RSPI on RZ/A1H.
The spi-rspi driver also supports legacy SH7757, which may not move to
DT anytime soon.
For symmetry, I did the same thing for QSPI, which applies to QSPI
on R-Car H2 and M2 (upon second look, it should be
"renesas,qspi-rcar-gen2", as E1/M1/H1 have HSPI).

Does this makes sense? Or do you still prefer plain "renesas,rspi" and
"renesas,qspi", and perhaps "renesas,rspi-sh" if we ever get DT there?

The compatible strings should define what the device is compatible with.
They should start with the most specific compability and end with the
less specific one. In this case we definitely want to list the
SoC-specific compatible string first, even if we don't need it, as
experience with Renesas SoC shows that subtle differences between
different versions of the same IP core can be discovered later. If all
RSPI cores are similar enough to be supported by a single driver
configuration, then I believe "renesas,rspi" would be a proper second
compatible string. If the RSPI cores in the SH and RZ chips are
incompatible then we need two different strings. The same is true for
QSPI.

A quick look at the driver shows that RSPI is supported without caring
whether the SoC is an SH or ARM, so I believe "renesas,rspi" should do.
The question

There are subtle register differences between RSPI on SH7757 and RZ/A1H,
cfr. what rspi_parse_platform_data() does when no platform_data is
passed[*]. RSPI on RZ/A1H seems to be an evolutionary step from RSPI on SH
towards QSPI on RCar Gen2 (but without Dual/Quad).

[*] setup-sh7757.c doesn't pass platform data, although the rspi driver and
its platform data has support for DMA on SH7757, which is not used by
setup-sh7757.c nor any other in-tree platform.

The only important difference I can see (beside the hardcoded 16-bit width 
which could be selected as the default) is that the SSH7757 RSPI has no SPL 
bits in SPDCR. I don't have access tot he SH7757 datasheet, could you please 
confirm that ?

quoted

in my opinion is whether we want to use

compatible = "renesas,rspi-r7s72100", "renesas,rspi";

or

compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz", "renesas,rspi";

So we end up with:

compatible = "renesas,sh7757", "renesas,rspi-sh" (SH legacy)
compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz" (Genmai)
compatible = "renesas,rspi-r8a7790", "renesas,qspi" (Lager)
compatible = "renesas,rspi-r8a7791", "renesas,qspi" (Koelsch)

Don't you mean "renesas,qspi-r8a7790" and "renesas,qspi-r8a7791" ?

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html