All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Conor Dooley <conor.dooley@microchip.com>,
	Samuel Holland <samuel@sholland.org>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Chris Paterson <Chris.Paterson2@renesas.com>,
	Atish Patra <atishp@atishpatra.org>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Similar SoCs with different CPUs and interrupt bindings
Date: Wed, 21 Sep 2022 09:46:34 +0200	[thread overview]
Message-ID: <CAMuHMdUPm36RsxHdVwspR3NCAR3C507AyB6R65W42N2gXWq0ag@mail.gmail.com> (raw)

        Hi Rob, Krzysztof,

This is a topic that came up at the RISC-V BoF at Plumbers, and it was
suggested to bring it up with you.

The same SoC may be available with either RISC-V or other (e.g. ARM) CPU
cores (an example of this are the Renesas RZ/Five and RZ/G2UL SoCs).
To avoid duplication, we would like to have:
  - <riscv-soc>.dtsi includes <base-soc>.dtsi,
  - <arm-soc>.dtsi includes <base-soc>.dtsi.

Unfortunately RISC-V and ARM typically use different types of interrupt
controllers, using different bindings (e.g. 2-cell vs. 3-cell), and
possibly using different interrupt numbers.  Hence the interrupt-parent
and interrupts{-extended} properties should be different, too.

Possible solutions[1]:
  1. interrupt-map

  2. Use a SOC_PERIPHERAL_IRQ() macro in interrupts properties in
     <base-soc>.dtsi, with
       - #define SOC_PERIPHERAL_IRQ(nr, na) nr          // RISC-V
       - #define SOC_PERIPHERAL_IRQ(nr, na) GIC_SPI na  // ARM
     Note that the cpp/dtc combo does not support arithmetic, so even
     the simple case where nr = 32 + na cannot be simplified.

  3. Wrap inside RISCV() and ARM() macros, e.g.:

        RISCV(interrupts = <412 IRQ_TYPE_LEVEL_HIGH>;)
        ARM(interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>;)

     Cfr. ARM() and THUMB() in arch/arm/include/asm/unified.h, as used
     to express the same operation using plain ARM or ARM Thumb
     instructions.

Personally, I'm leaning towards the third solution, as it is the most
flexible, and allows us to extend to more than 2 interrupt controllers.

Note that this is actually not a new issue.  For years, ARM SoCs have
existed with multiple types of cores on the same die, using Cortex-A
cores for the application, and Cortex-R/SuperH/V850/... cores for
real-time and/or baseband operation.  So far this wasn't an issue, as
only the Cortex-A cores ran Linux, and we ignored the other cores (and
the related interrupt controllers and hierarchy) in DT.

What do you think?
Thanks for your comments!

[1] https://lore.kernel.org/lkml/20220815050815.22340-7-samuel@sholland.org

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

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>,
	 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Conor Dooley <conor.dooley@microchip.com>,
	 Samuel Holland <samuel@sholland.org>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	 Chris Paterson <Chris.Paterson2@renesas.com>,
	Atish Patra <atishp@atishpatra.org>,
	 "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Similar SoCs with different CPUs and interrupt bindings
Date: Wed, 21 Sep 2022 09:46:34 +0200	[thread overview]
Message-ID: <CAMuHMdUPm36RsxHdVwspR3NCAR3C507AyB6R65W42N2gXWq0ag@mail.gmail.com> (raw)

        Hi Rob, Krzysztof,

This is a topic that came up at the RISC-V BoF at Plumbers, and it was
suggested to bring it up with you.

The same SoC may be available with either RISC-V or other (e.g. ARM) CPU
cores (an example of this are the Renesas RZ/Five and RZ/G2UL SoCs).
To avoid duplication, we would like to have:
  - <riscv-soc>.dtsi includes <base-soc>.dtsi,
  - <arm-soc>.dtsi includes <base-soc>.dtsi.

Unfortunately RISC-V and ARM typically use different types of interrupt
controllers, using different bindings (e.g. 2-cell vs. 3-cell), and
possibly using different interrupt numbers.  Hence the interrupt-parent
and interrupts{-extended} properties should be different, too.

Possible solutions[1]:
  1. interrupt-map

  2. Use a SOC_PERIPHERAL_IRQ() macro in interrupts properties in
     <base-soc>.dtsi, with
       - #define SOC_PERIPHERAL_IRQ(nr, na) nr          // RISC-V
       - #define SOC_PERIPHERAL_IRQ(nr, na) GIC_SPI na  // ARM
     Note that the cpp/dtc combo does not support arithmetic, so even
     the simple case where nr = 32 + na cannot be simplified.

  3. Wrap inside RISCV() and ARM() macros, e.g.:

        RISCV(interrupts = <412 IRQ_TYPE_LEVEL_HIGH>;)
        ARM(interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>;)

     Cfr. ARM() and THUMB() in arch/arm/include/asm/unified.h, as used
     to express the same operation using plain ARM or ARM Thumb
     instructions.

Personally, I'm leaning towards the third solution, as it is the most
flexible, and allows us to extend to more than 2 interrupt controllers.

Note that this is actually not a new issue.  For years, ARM SoCs have
existed with multiple types of cores on the same die, using Cortex-A
cores for the application, and Cortex-R/SuperH/V850/... cores for
real-time and/or baseband operation.  So far this wasn't an issue, as
only the Cortex-A cores ran Linux, and we ignored the other cores (and
the related interrupt controllers and hierarchy) in DT.

What do you think?
Thanks for your comments!

[1] https://lore.kernel.org/lkml/20220815050815.22340-7-samuel@sholland.org

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh+dt@kernel.org>,
	 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Conor Dooley <conor.dooley@microchip.com>,
	 Samuel Holland <samuel@sholland.org>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	 Chris Paterson <Chris.Paterson2@renesas.com>,
	Atish Patra <atishp@atishpatra.org>,
	 "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Similar SoCs with different CPUs and interrupt bindings
Date: Wed, 21 Sep 2022 09:46:34 +0200	[thread overview]
Message-ID: <CAMuHMdUPm36RsxHdVwspR3NCAR3C507AyB6R65W42N2gXWq0ag@mail.gmail.com> (raw)

        Hi Rob, Krzysztof,

This is a topic that came up at the RISC-V BoF at Plumbers, and it was
suggested to bring it up with you.

The same SoC may be available with either RISC-V or other (e.g. ARM) CPU
cores (an example of this are the Renesas RZ/Five and RZ/G2UL SoCs).
To avoid duplication, we would like to have:
  - <riscv-soc>.dtsi includes <base-soc>.dtsi,
  - <arm-soc>.dtsi includes <base-soc>.dtsi.

Unfortunately RISC-V and ARM typically use different types of interrupt
controllers, using different bindings (e.g. 2-cell vs. 3-cell), and
possibly using different interrupt numbers.  Hence the interrupt-parent
and interrupts{-extended} properties should be different, too.

Possible solutions[1]:
  1. interrupt-map

  2. Use a SOC_PERIPHERAL_IRQ() macro in interrupts properties in
     <base-soc>.dtsi, with
       - #define SOC_PERIPHERAL_IRQ(nr, na) nr          // RISC-V
       - #define SOC_PERIPHERAL_IRQ(nr, na) GIC_SPI na  // ARM
     Note that the cpp/dtc combo does not support arithmetic, so even
     the simple case where nr = 32 + na cannot be simplified.

  3. Wrap inside RISCV() and ARM() macros, e.g.:

        RISCV(interrupts = <412 IRQ_TYPE_LEVEL_HIGH>;)
        ARM(interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>;)

     Cfr. ARM() and THUMB() in arch/arm/include/asm/unified.h, as used
     to express the same operation using plain ARM or ARM Thumb
     instructions.

Personally, I'm leaning towards the third solution, as it is the most
flexible, and allows us to extend to more than 2 interrupt controllers.

Note that this is actually not a new issue.  For years, ARM SoCs have
existed with multiple types of cores on the same die, using Cortex-A
cores for the application, and Cortex-R/SuperH/V850/... cores for
real-time and/or baseband operation.  So far this wasn't an issue, as
only the Cortex-A cores ran Linux, and we ignored the other cores (and
the related interrupt controllers and hierarchy) in DT.

What do you think?
Thanks for your comments!

[1] https://lore.kernel.org/lkml/20220815050815.22340-7-samuel@sholland.org

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-09-21  7:46 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21  7:46 Geert Uytterhoeven [this message]
2022-09-21  7:46 ` Similar SoCs with different CPUs and interrupt bindings Geert Uytterhoeven
2022-09-21  7:46 ` Geert Uytterhoeven
2022-09-21  8:49 ` Krzysztof Kozlowski
2022-09-21  8:49   ` Krzysztof Kozlowski
2022-09-21  8:49   ` Krzysztof Kozlowski
2022-09-21  9:20   ` Lad, Prabhakar
2022-09-21  9:20     ` Lad, Prabhakar
2022-09-21  9:20     ` Lad, Prabhakar
2022-09-21  9:26     ` Krzysztof Kozlowski
2022-09-21  9:26       ` Krzysztof Kozlowski
2022-09-21  9:26       ` Krzysztof Kozlowski
2022-09-21 10:07       ` Lad, Prabhakar
2022-09-21 10:07         ` Lad, Prabhakar
2022-09-21 10:07         ` Lad, Prabhakar
2022-09-21 10:08       ` Geert Uytterhoeven
2022-09-21 10:08         ` Geert Uytterhoeven
2022-09-21 10:08         ` Geert Uytterhoeven
2022-09-21 10:10         ` Krzysztof Kozlowski
2022-09-21 10:10           ` Krzysztof Kozlowski
2022-09-21 10:10           ` Krzysztof Kozlowski
2022-09-21 21:05         ` Conor Dooley
2022-09-21 21:05           ` Conor Dooley
2022-09-21 21:05           ` Conor Dooley
2022-09-21 10:14       ` Robin Murphy
2022-09-21 10:14         ` Robin Murphy
2022-09-21 10:14         ` Robin Murphy
2022-09-21 10:17         ` Krzysztof Kozlowski
2022-09-21 10:17           ` Krzysztof Kozlowski
2022-09-21 10:17           ` Krzysztof Kozlowski
2022-09-21 10:27           ` Robin Murphy
2022-09-21 10:27             ` Robin Murphy
2022-09-21 10:27             ` Robin Murphy
2022-09-21 10:10   ` Geert Uytterhoeven
2022-09-21 10:10     ` Geert Uytterhoeven
2022-09-21 10:10     ` Geert Uytterhoeven
2022-09-21  9:20 ` Robin Murphy
2022-09-21  9:20   ` Robin Murphy
2022-09-21  9:20   ` Robin Murphy
2022-09-21 10:13   ` Geert Uytterhoeven
2022-09-21 10:13     ` Geert Uytterhoeven
2022-09-21 10:13     ` Geert Uytterhoeven
2022-09-21 10:20     ` Krzysztof Kozlowski
2022-09-21 10:20       ` Krzysztof Kozlowski
2022-09-21 10:20       ` Krzysztof Kozlowski
2022-09-22  6:30   ` Arnd Bergmann
2022-09-22  6:30     ` Arnd Bergmann
2022-09-22  6:30     ` Arnd Bergmann
2022-09-22  6:40     ` Geert Uytterhoeven
2022-09-22  6:40       ` Geert Uytterhoeven
2022-09-22  6:40       ` 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=CAMuHMdUPm36RsxHdVwspR3NCAR3C507AyB6R65W42N2gXWq0ag@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=Chris.Paterson2@renesas.com \
    --cc=andre.przywara@arm.com \
    --cc=atishp@atishpatra.org \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=conor.dooley@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.