Re: [PATCH v3 00/10] sunxi: Support IRQ wakeup from deep sleep

From: Samuel Holland
Date: Sun Jan 03 2021 - 07:54:21 EST


On 1/3/21 6:16 AM, Marc Zyngier wrote:
> [dropped linux-sunxi@xxxxxxxxxxxxxxxx, which seems to be a closed ML]
>
> On Sun, 03 Jan 2021 10:30:51 +0000,
> Samuel Holland <samuel@xxxxxxxxxxxx> wrote:
>>
>> Allwinner sun6i/sun8i/sun50i SoCs (A31 and newer) have two interrupt
>> controllers: GIC and R_INTC. GIC does not support wakeup. R_INTC handles
>> the external NMI pin, and provides 32+ IRQs to the ARISC. The first 16
>> of these correspond 1:1 to a block of GIC IRQs starting with the NMI.
>> The last 13-16 multiplex the first (up to) 128 GIC SPIs.
>>
>> This series replaces the existing chained irqchip driver that could only
>> control the NMI, with a stacked irqchip driver that also provides wakeup
>> capability for those multiplexed SPI IRQs. The idea is to preconfigure
>> the ARISC's IRQ controller, and then the ARISC firmware knows to wake up
>> as soon as it receives an IRQ. It can also decide how deep it can
>> suspend based on the selected wakeup IRQs.
>
> Out of curiosity, how do you plan to communicate dynamic configuration
> of IRQs to the ARISC? We recently went through this with some TI
> stuff, and the result a bit awkward (the arm64 side configures
> interrupts that are not visible to the kernel, but only to the
> co-processors).

Assuming by "dynamic" you mean while Linux is running, I don't plan to
communicate anything. As far as I'm concerned, the driver is feature-complete
after this patch series. The ARISC firmware does not use the interrupt
controller (or any other shared peripherals) while Linux is running. It sits in
a tight loop polling its side of the mailbox, waiting for a
hotplug/suspend/poweroff/reboot command.

> I wondered whether you had other ideas...

Sorry, I guess not. We tried to avoid using the ARISC for long enough that
anything that can have a native Linux driver has one. So the ARISC firmware has
nothing to do while Linux is running. (This is in comparison to the vendor BSP,
where some peripherals are only accessed through their firmware.)

Samuel

> Thanks,
>
> M.
>