From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Rob Herring <robh+dt@kernel.org>,
Laurent <laurent.pinchart@ideasonboard.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Magnus <magnus.damm@gmail.com>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux-DT <devicetree@vger.kernel.org>,
"(Renesas) shimoda" <yoshihiro.shimoda.uh@renesas.com>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP device nodes
Date: Thu, 10 Sep 2020 13:09:12 +0200 [thread overview]
Message-ID: <CAMuHMdVGFOaBFCejGDgzf8AUbHFis0TOM-DDJ3h9k0+fuu=umQ@mail.gmail.com> (raw)
In-Reply-To: <f1ed4b08-59eb-986e-4036-820887993f00@ideasonboard.com>
Hi Kieran,
On Thu, Sep 10, 2020 at 12:34 PM Kieran Bingham
<kieran.bingham+renesas@ideasonboard.com> wrote:
> On 10/09/2020 10:44, Geert Uytterhoeven wrote:
> > On Mon, Sep 7, 2020 at 5:55 PM Kieran Bingham
> > <kieran.bingham+renesas@ideasonboard.com> wrote:
> >> On 07/09/2020 03:59, Kuninori Morimoto wrote:
> >>> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>>
> >>> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> >>> This patch is test on R-Car M3-W+ Salvator-XS board.
> >>>
> >>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>> ---
> >>> arch/arm64/boot/dts/renesas/r8a77961.dtsi | 55 +++++++++++++++++++++++
> >>> 1 file changed, 55 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> >>> index fe0db11b9cb9..c2a6918ed5e6 100644
> >>> --- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> >>> +++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
> >>> @@ -2056,6 +2056,61 @@ fcpvd2: fcp@fea37000 {
> >>> iommus = <&ipmmu_vi0 10>;
> >>> };
> >>
> >> The FCP's added are:
> >>
> >> fcpf0: fcp@fe950000 {
> >> fcpf1: fcp@fe951000 {
> >> fcpvb0: fcp@fe96f000 {
> >> fcpvb1: fcp@fe92f000 {
> >> fcpvi0: fcp@fe9af000 {
> >> fcpvi1: fcp@fe9bf000 {
> >> fcpvd0: fcp@fea27000 {
> >> fcpvd1: fcp@fea2f000 {
> >> fcpvd2: fcp@fea37000 {
> >>
> >> So indeed, the first fcpf0 comes before fe960000.
> >>
> >> Do we keep the items grouped by the first occurrence? or sort the nodes
> >> based on address?
> >>
> >> for some reason I thought we were ordering based on address, but I see
> >> other situations where we group too - so I'm confused (and wishing there
> >> was an automatic tool to get the sorting correct without fuss).
> >>
> >> Is there a set policy?
> >
> > For nodes with a unit-address, we usually[*] sort by unit-address, but we keep
> > similar nodes grouped. Hence I prefer this v1 over v2.
>
> I assume then the groups are sorted by the first entry,
>
> I.e. hypothetically:
>
> fdp@0
> fcp@1
> vsp@2
> fdp@3
> fcp@4
> vsp@5
> cmm@6
> cmm@7
>
> would become
>
> fdp@0
> fdp@3
> fcp@1
> fcp@4
> vsp@2
> vsp@5
> cmm@6
> cmm@7
Exactly. That's how we (Reneas SoCs) have been (trying to) doing it.
I am aware there are some deviations (e.g. do you keep all 4 possible
SCIF types together (they're all serial@), or do you group them per
type? And some nodes (ipmmu) may be sorted alphabetically by label).
> Has anyone already created any scripting/validation to automate the
> sorting requirements?
Not yet, AFAIK. I've been thinking about doing that several times,
though ;-)
> > [*] Seems like FCP/VSP are interleaved in r8a77990.dsi, doh.
> >
>
> Personally I prefer that - but my opinion doesn't matter here - so as
> long as the rules are defined (or even better, automatically
> enforceable) that's fine.
Indeed.
Perhaps creating rules is something to be handled at a higher level
(i.e. common for all DTS files)?
Summarizing "our" rules:
1. Nodes without unit-address are sorted alphabetically, by node name,
2. Nodes with unit-address are sorted numerically, by unit-address,
a. Nodes of the same type are grouped together, i.e. the whole
group is sorted w.r.t. to other nodes/groups based on the
unit-address of the first member of the group.
3. Anchors are sorted alphabetically, but anchor name.
Do they make sense?
> >>> + vspb: vsp@fe960000 {
> >>> + compatible = "renesas,vsp2";
> >>> + reg = <0 0xfe960000 0 0x8000>;
> >>> + interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
> >>> + clocks = <&cpg CPG_MOD 626>;
> >>> + power-domains = <&sysc R8A77961_PD_A3VC>;
> >>> + resets = <&cpg 626>;
> >>> +
> >>> + renesas,fcp = <&fcpvb0>;
> >>> + };
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
next prev parent reply other threads:[~2020-09-10 11:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 2:58 [PATCH 0/9] arm64: renesas: enable HDMI Display/Sound on R-Car M3-W+ Salvator-XS Kuninori Morimoto
2020-09-07 2:58 ` [PATCH 1/9] dt-bindings: display: renesas: du: Document the r8a77961 bindings Kuninori Morimoto
2020-09-07 14:50 ` Geert Uytterhoeven
2020-09-07 23:15 ` Kuninori Morimoto
2020-09-07 2:58 ` [PATCH 2/9] dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support Kuninori Morimoto
2020-09-07 14:52 ` Geert Uytterhoeven
2020-09-07 2:58 ` [PATCH 3/9] drm: rcar-du: Add r8a77961 support Kuninori Morimoto
2020-09-07 2:58 ` [PATCH 4/9] arm64: dts: renesas: r8a77961: Add FCP device nodes Kuninori Morimoto
2020-09-07 8:11 ` Sergei Shtylyov
2020-09-07 2:59 ` [PATCH 5/9] arm64: dts: renesas: r8a77961: Add VSP " Kuninori Morimoto
2020-09-07 8:08 ` Sergei Shtylyov
2020-09-07 8:10 ` Sergei Shtylyov
2020-09-07 15:55 ` Kieran Bingham
2020-09-07 23:21 ` Kuninori Morimoto
2020-09-10 9:44 ` Geert Uytterhoeven
2020-09-10 10:34 ` Kieran Bingham
2020-09-10 11:09 ` Geert Uytterhoeven [this message]
2020-09-11 7:37 ` Geert Uytterhoeven
2020-09-10 9:41 ` Geert Uytterhoeven
2020-09-07 2:59 ` [PATCH 6/9] arm64: dts: renesas: r8a77961: Add DU " Kuninori Morimoto
2020-09-07 2:59 ` [PATCH 7/9] arm64: dts: renesas: r8a77961: Add HDMI " Kuninori Morimoto
2020-09-07 2:59 ` [PATCH 8/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Display support Kuninori Morimoto
2020-09-07 8:06 ` Sergei Shtylyov
2020-09-07 2:59 ` [PATCH 9/9] arm64: dts: renesas: r8a77961-salvator-xs: add HDMI Sound support Kuninori Morimoto
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='CAMuHMdVGFOaBFCejGDgzf8AUbHFis0TOM-DDJ3h9k0+fuu=umQ@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=robh+dt@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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).