All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel Holland <samuel@sholland.org>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Ondrej Jirman <megous@megous.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com
Subject: Re: [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi
Date: Fri, 8 Jan 2021 09:40:09 -0600	[thread overview]
Message-ID: <e6ab1926-e69d-1e66-32d8-19870625ee17@sholland.org> (raw)
In-Reply-To: <20210108094453.7uk5lj6j6gdmydiw@gilmour>

On 1/8/21 3:44 AM, Maxime Ripard wrote:
> Hi Samuel,
> 
> Thanks a lot for working on this
> 
> I'm fine with the rest of the work, but I have a couple of questions
> 
> On Sun, Jan 03, 2021 at 04:30:52AM -0600, Samuel Holland wrote:
>> The R_INTC in the A31 and newer sun8i/sun50i SoCs has additional
>> functionality compared to the sun7i/sun9i NMI controller. Among other
>> things, it multiplexes up to 128 interrupts corresponding to (and in
>> parallel to) the first 128 GIC SPIs. This means the NMI is no longer the
>> lowest-numbered interrupt, since it is SPI 32 or 96 (depending on SoC).
>>
>> To allow access to all multiplexed IRQs, the R_INTC requires a new
>> binding where the interrupt number matches the GIC interrupt number.
>> For simplicity, copy the three-cell GIC binding; this disambiguates
>> interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
>> binding (SPI 0) by the number of cells.
> 
> It's not really clear to me what the ambiguity is between the NMI and
> the SPI 0 interrupt?

Here's the ASCII art I will include in v4:

            NMI IRQ               DIRECT IRQs          MUXED IRQs
             bit 0                 bits 1-18           bits 19-31

  +---------+                     +---------+   +---------+  +---------+
  | NMI Pad |                     |  IRQ d  |   |  IRQ m  |  | IRQ m+7 |
  +---------+                     +---------+   +---------+  +---------+
       |                            |     |        |    |      |    |
       |                            |     |        |    |......|    |
+------V------+ +-------------+     |     |        | +--V------V--+ |
|   Invert/   | |    Write    |     |     |        | |  AND with  | |
| Edge Detect | |  PENDING[0] |     |     |        | |  MUX[m/8]  | |
+-------------+ +-------------+     |     |        | +------------+ |
           |       |                |     |        |       |        |
        +--V-------V--+          +--V--+  |     +--V--+    |     +--V--+
        | Set    Reset|          | GIC |  |     | GIC |    |     | GIC |
        |    Latch    |          | SPI |  |     | SPI |... |  ...| SPI |
        +-------------+          | N+d |  |     |  m  |    |     | m+7 |
            |     |              +-----+  |     +-----+    |     +-----+
            |     |                       |                |
    +-------V-+ +-V-----------+ +---------V---+  +---------V----------+
    | GIC SPI | |   AND with  | |   AND with  |  |      AND with      |
    | N (=32) | |  ENABLE[0]  | |  ENABLE[d]  |  |   ENABLE[19+m/8]   |
    +---------+ +-------------+ +-------------+  +--------------------+
                       |               |                   |
                +------V------+ +------V------+  +---------V----------+
                |    Read     | |    Read     |  |       Read         |
                |  PENDING[0] | |  PENDING[d] |  |   PENDING[19+m/8]  |
                +-------------+ +-------------+  +--------------------+

There are two overlapping ranges of IRQs supported by the controller,
and so there are two different IRQs you could call "IRQ 0":
  - Bit 0 of PENDING/ENABLE/MASK, aka d==0, the NMI
    - This maps to bit 32 of the MUX register range (SPI 32)
    - This is what the old binding calls "IRQ 0"
  - Bit 0 of MUX, aka m==0, aka SPI 0, the UART0 IRQ
    - This maps to bit 19 of PENDING/ENABLE/MASK
    - This is what the new binding calls "IRQ 0"

You can see this insertion in the middle of the MUX range when looking
at the mask of implemented MUX bits in the A31 variant:
  0xffffffff,
  0xfff80000, <<< this gap here is for the 19 direct IRQs
  0xffffffff,
  0x0000000f,

If you call the NMI "IRQ 0", then there is no way to specify the muxed
IRQs. SPI 0 maps to bit 19, but so do SPI 1-7. So if I was to specify
"IRQ 19", you wouldn't know which of those 8 muxed SPIs I am referring to.

On the other hand, if you call the first muxed IRQ "IRQ 0", then there
is an unambiguous number for every interrupt supported by this driver.

> In general, it looks like switching to a 3-cell binding with the GIC SPI
> value looks weird to me, since the GIC isn't the parent at all of these
> interrupts.

The GIC is *a* parent of all of these interrupts, and is *the* parent of
the NMI.

> If the ambiguity is that a stacked irqchip driver needs to have the same
> interrupt number than the GIC, and that the 0 interrupt for the NMI
> controller (used by the PMIC) and is actually the 32 (or 96) GIC
> interrupt and thus breaks that requirement, can't we fix this in the
> driver based on the compatible?

No, while the NMI is direct "IRQ 0" at this irqchip, it is *also* muxed
"IRQ 32" at this same irqchip.

> Something like if the interrupt number is 0, with a A31 or newer
> compatible, then add the proper offset in sun6i_r_intc_domain_alloc?

If you translate 0 to 32, then you cannot represent muxed IRQ 0 (the
UART0 IRQ) at all.

> Maxime

Cheers,
Samuel


WARNING: multiple messages have this Message-ID (diff)
From: Samuel Holland <samuel@sholland.org>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Ondrej Jirman <megous@megous.com>,
	devicetree@vger.kernel.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Marc Zyngier <maz@kernel.org>,
	linux-sunxi@googlegroups.com,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>,
	Rob Herring <robh+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi
Date: Fri, 8 Jan 2021 09:40:09 -0600	[thread overview]
Message-ID: <e6ab1926-e69d-1e66-32d8-19870625ee17@sholland.org> (raw)
In-Reply-To: <20210108094453.7uk5lj6j6gdmydiw@gilmour>

On 1/8/21 3:44 AM, Maxime Ripard wrote:
> Hi Samuel,
> 
> Thanks a lot for working on this
> 
> I'm fine with the rest of the work, but I have a couple of questions
> 
> On Sun, Jan 03, 2021 at 04:30:52AM -0600, Samuel Holland wrote:
>> The R_INTC in the A31 and newer sun8i/sun50i SoCs has additional
>> functionality compared to the sun7i/sun9i NMI controller. Among other
>> things, it multiplexes up to 128 interrupts corresponding to (and in
>> parallel to) the first 128 GIC SPIs. This means the NMI is no longer the
>> lowest-numbered interrupt, since it is SPI 32 or 96 (depending on SoC).
>>
>> To allow access to all multiplexed IRQs, the R_INTC requires a new
>> binding where the interrupt number matches the GIC interrupt number.
>> For simplicity, copy the three-cell GIC binding; this disambiguates
>> interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
>> binding (SPI 0) by the number of cells.
> 
> It's not really clear to me what the ambiguity is between the NMI and
> the SPI 0 interrupt?

Here's the ASCII art I will include in v4:

            NMI IRQ               DIRECT IRQs          MUXED IRQs
             bit 0                 bits 1-18           bits 19-31

  +---------+                     +---------+   +---------+  +---------+
  | NMI Pad |                     |  IRQ d  |   |  IRQ m  |  | IRQ m+7 |
  +---------+                     +---------+   +---------+  +---------+
       |                            |     |        |    |      |    |
       |                            |     |        |    |......|    |
+------V------+ +-------------+     |     |        | +--V------V--+ |
|   Invert/   | |    Write    |     |     |        | |  AND with  | |
| Edge Detect | |  PENDING[0] |     |     |        | |  MUX[m/8]  | |
+-------------+ +-------------+     |     |        | +------------+ |
           |       |                |     |        |       |        |
        +--V-------V--+          +--V--+  |     +--V--+    |     +--V--+
        | Set    Reset|          | GIC |  |     | GIC |    |     | GIC |
        |    Latch    |          | SPI |  |     | SPI |... |  ...| SPI |
        +-------------+          | N+d |  |     |  m  |    |     | m+7 |
            |     |              +-----+  |     +-----+    |     +-----+
            |     |                       |                |
    +-------V-+ +-V-----------+ +---------V---+  +---------V----------+
    | GIC SPI | |   AND with  | |   AND with  |  |      AND with      |
    | N (=32) | |  ENABLE[0]  | |  ENABLE[d]  |  |   ENABLE[19+m/8]   |
    +---------+ +-------------+ +-------------+  +--------------------+
                       |               |                   |
                +------V------+ +------V------+  +---------V----------+
                |    Read     | |    Read     |  |       Read         |
                |  PENDING[0] | |  PENDING[d] |  |   PENDING[19+m/8]  |
                +-------------+ +-------------+  +--------------------+

There are two overlapping ranges of IRQs supported by the controller,
and so there are two different IRQs you could call "IRQ 0":
  - Bit 0 of PENDING/ENABLE/MASK, aka d==0, the NMI
    - This maps to bit 32 of the MUX register range (SPI 32)
    - This is what the old binding calls "IRQ 0"
  - Bit 0 of MUX, aka m==0, aka SPI 0, the UART0 IRQ
    - This maps to bit 19 of PENDING/ENABLE/MASK
    - This is what the new binding calls "IRQ 0"

You can see this insertion in the middle of the MUX range when looking
at the mask of implemented MUX bits in the A31 variant:
  0xffffffff,
  0xfff80000, <<< this gap here is for the 19 direct IRQs
  0xffffffff,
  0x0000000f,

If you call the NMI "IRQ 0", then there is no way to specify the muxed
IRQs. SPI 0 maps to bit 19, but so do SPI 1-7. So if I was to specify
"IRQ 19", you wouldn't know which of those 8 muxed SPIs I am referring to.

On the other hand, if you call the first muxed IRQ "IRQ 0", then there
is an unambiguous number for every interrupt supported by this driver.

> In general, it looks like switching to a 3-cell binding with the GIC SPI
> value looks weird to me, since the GIC isn't the parent at all of these
> interrupts.

The GIC is *a* parent of all of these interrupts, and is *the* parent of
the NMI.

> If the ambiguity is that a stacked irqchip driver needs to have the same
> interrupt number than the GIC, and that the 0 interrupt for the NMI
> controller (used by the PMIC) and is actually the 32 (or 96) GIC
> interrupt and thus breaks that requirement, can't we fix this in the
> driver based on the compatible?

No, while the NMI is direct "IRQ 0" at this irqchip, it is *also* muxed
"IRQ 32" at this same irqchip.

> Something like if the interrupt number is 0, with a A31 or newer
> compatible, then add the proper offset in sun6i_r_intc_domain_alloc?

If you translate 0 to 32, then you cannot represent muxed IRQ 0 (the
UART0 IRQ) at all.

> Maxime

Cheers,
Samuel


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

  reply	other threads:[~2021-01-08 15:40 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-03 10:30 [PATCH v3 00/10] sunxi: Support IRQ wakeup from deep sleep Samuel Holland
2021-01-03 10:30 ` Samuel Holland
2021-01-03 10:30 ` [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-08  9:44   ` Maxime Ripard
2021-01-08  9:44     ` Maxime Ripard
2021-01-08 15:40     ` Samuel Holland [this message]
2021-01-08 15:40       ` Samuel Holland
2021-01-11 22:29   ` Rob Herring
2021-01-11 22:29     ` Rob Herring
2021-01-03 10:30 ` [PATCH v3 02/10] dt-bindings: irq: sun6i-r: Add a compatible for the H3 Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-11 22:29   ` Rob Herring
2021-01-11 22:29     ` Rob Herring
2021-01-03 10:30 ` [PATCH v3 03/10] irqchip/sun6i-r: Use a stacked irqchip driver Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-03 11:27   ` Marc Zyngier
2021-01-03 11:27     ` Marc Zyngier
2021-01-03 12:08     ` Samuel Holland
2021-01-03 12:08       ` Samuel Holland
2021-01-03 13:10       ` Marc Zyngier
2021-01-03 13:10         ` Marc Zyngier
2021-01-04  3:46         ` Samuel Holland
2021-01-04  3:46           ` Samuel Holland
2021-01-04 10:03           ` Marc Zyngier
2021-01-04 10:03             ` Marc Zyngier
2021-01-03 10:30 ` [PATCH v3 04/10] irqchip/sun6i-r: Add wakeup support Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-03 10:30 ` [PATCH v3 05/10] ARM: dts: sunxi: Rename nmi_intc to r_intc Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-03 10:30 ` [PATCH v3 06/10] ARM: dts: sunxi: Use the new r_intc binding Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-03 10:30 ` [PATCH v3 07/10] ARM: dts: sunxi: h3/h5: Add r_intc node Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-03 10:30 ` [PATCH v3 08/10] ARM: dts: sunxi: Move wakeup-capable IRQs to r_intc Samuel Holland
2021-01-03 10:30   ` Samuel Holland
2021-01-03 10:31 ` [PATCH v3 09/10] arm64: dts: allwinner: Use the new r_intc binding Samuel Holland
2021-01-03 10:31   ` Samuel Holland
2021-01-03 10:31 ` [PATCH v3 10/10] arm64: dts: allwinner: Move wakeup-capable IRQs to r_intc Samuel Holland
2021-01-03 10:31   ` Samuel Holland
2021-01-03 12:16 ` [PATCH v3 00/10] sunxi: Support IRQ wakeup from deep sleep Marc Zyngier
2021-01-03 12:16   ` Marc Zyngier
2021-01-03 12:43   ` Samuel Holland
2021-01-03 12:43     ` Samuel Holland

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=e6ab1926-e69d-1e66-32d8-19870625ee17@sholland.org \
    --to=samuel@sholland.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jernej.skrabec@siol.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=linux@armlinux.org.uk \
    --cc=maxime@cerno.tech \
    --cc=maz@kernel.org \
    --cc=megous@megous.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=wens@csie.org \
    --cc=will@kernel.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.