From: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
To: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: Geert Uytterhoeven
<geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
Linux-sh list <linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 4/6] [RFC] Documentation: dt: Add Renesas RSPI/QSPI bindings
Date: Mon, 30 Dec 2013 00:22:19 +0100 [thread overview]
Message-ID: <2582506.8vb3LhHISh@avalon> (raw)
In-Reply-To: <CAMuHMdXrPamASqFz8eCVxE0WKT=cdkrzxjDDT84m_AHT+1nmEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Friday 27 December 2013 20:01:53 Geert Uytterhoeven wrote:
> On Fri, Dec 27, 2013 at 5:18 PM, Laurent Pinchart wrote:
> > On Tuesday 24 December 2013 12:56:48 Geert Uytterhoeven wrote:
> >> +++ 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.
>
> > 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
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";
> >> +- reg : address start and address range size of device
> >> +- interrupts : 3 interrupts for RSPI (SPEI, SPRI, SPTI),
> >> + 1 interrupt for QSPI
> >> +- num-cs : Number of chip selects
> >> +- #address-cells : should be <1>
> >> +- #size-cells : should be <0>
> >
> > I would say "must" instead of "should".
>
> OK.
>
> >> +Example:
> >> +
> >> + spi0: spi@e800c800 {
> >> + compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
> >> + reg = <0xe800c800 0x24>;
> >> + interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 239 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 240 IRQ_TYPE_LEVEL_HIGH>;
> >
> > You're missing the interrupt-parent property.
>
> OK.
>
> But we don't need it in the spi node in the actual .dts, as we already have
> "interrupt-parent = <&gic>;" in the enclosing node, right?
That's right.
--
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
next prev parent reply other threads:[~2013-12-29 23:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-24 11:56 [PATCH 0/6] Preliminary SoC and board integration for RSPI on RZ/A1H Geert Uytterhoeven
2013-12-24 11:56 ` [PATCH 1/6] pinctrl: sh-pfc: r7s72100: Add RSPI support Geert Uytterhoeven
2014-01-07 19:03 ` Linus Walleij
2014-01-07 19:07 ` Geert Uytterhoeven
[not found] ` <1387886210-3634-1-git-send-email-geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2013-12-24 11:56 ` [PATCH 2/6] ARM: shmobile: r7s72100: Add RSPI clocks Geert Uytterhoeven
2013-12-25 0:51 ` Kuninori Morimoto
2013-12-24 11:56 ` [PATCH 3/6] ARM: shmobile: r7s72100: Add RSPI resources Geert Uytterhoeven
2013-12-24 15:41 ` Sergei Shtylyov
2013-12-24 11:56 ` [PATCH 4/6] [RFC] Documentation: dt: Add Renesas RSPI/QSPI bindings Geert Uytterhoeven
[not found] ` <1387886210-3634-5-git-send-email-geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
2013-12-27 16:18 ` Laurent Pinchart
2013-12-27 19:01 ` Geert Uytterhoeven
[not found] ` <CAMuHMdXrPamASqFz8eCVxE0WKT=cdkrzxjDDT84m_AHT+1nmEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-29 23:22 ` Laurent Pinchart [this message]
2013-12-30 9:37 ` Geert Uytterhoeven
[not found] ` <CAMuHMdUnf77Z1u=d8zFZk0vQtGJ9QhhCk6KVJsVKS-iMFSMUKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-30 15:18 ` Laurent Pinchart
2013-12-30 17:20 ` Geert Uytterhoeven
2013-12-24 11:56 ` [PATCH 6/6] [RFC] arm: shmobile: genmai reference: Add RSPI nodes Geert Uytterhoeven
2013-12-24 15:45 ` Sergei Shtylyov
2013-12-24 19:46 ` Geert Uytterhoeven
2013-12-27 16:20 ` Laurent Pinchart
2013-12-27 19:08 ` Geert Uytterhoeven
[not found] ` <CAMuHMdVH4PyhxR3JLLPX9a3fKaEgdpQpd2aa4YKL6DUD8+Pw2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-28 11:48 ` Laurent Pinchart
2013-12-24 11:56 ` [PATCH 5/6] [RFC] ARM: shmobile: r7s72100 dtsi: " Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2582506.8vb3LhHISh@avalon \
--to=laurent.pinchart-rylnwiuwjnjg/c1bvhzhaw@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).