Re: Exynos850 and ExynosAuto v9 pinctrl wakeup muxed interrupt

[Krzysztof Kozlowski]

On 14/01/2022 21:32, Sam Protsenko wrote:
> On Fri, 7 Jan 2022 at 10:16, Krzysztof Kozlowski
> <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote:
>>
>> On 03/01/2022 21:59, Sam Protsenko wrote:
>>> On Thu, 30 Dec 2021 at 21:34, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote:
>>>>
>>>> Hi Chanho and Sam,
>>>>
>>>> I am slowly finishing dtschema for Samsung pinctrl drivers [1] and I
>>>> noticed that Exynos850 and Auto v9 do not define interrupt in pinctrl
>>>> node with: wakeup-interrupt-controller. This is an interrupt muxing
>>>> several external wakeup interrupts, e.g. EINT16 - EINT31.
>>>>
>>>> For Exynos5433 this looks like:
>>>> https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/exynos/exynos5433.dtsi#L857
>>>>
>>>> Missing muxed interrupt for Exynos850 and Autov9 might be fine, although
>>>> you should see in dmesg error log like:
>>>>     "irq number for muxed EINTs not found"
>>>>
>>>> Can you check that your wakeup-interrupt-controller is properly defined
>>>> in DTSI? If yes, I will need to include such differences in the dtschema.
>>>>
>>>
>>> In case of Exynos850, no muxed interrupts exist for wakeup GPIO
>>> domains. Basically, "pinctrl_alive" and "pinctrl_cmgp" domains are
>>> wake-up capable, and they have dedicated interrupt for each particular
>>> GPIO pin. All those interrupts are defined in exynos850-pinctrl.dtsi
>>> file, in next nodes:
>>>   - pinctrl_alive: gpa0..gpa4 (interrupt numbers 1..36)
>>>   - pinctrl_cmgp: gpm0..gpm7 (interrupt numbers 39..46)
>>>
>>> All mentioned interrupts are wakeup interrupts, and there are no muxed
>>> ones. So it seems like it's not possible to specify "interrupts"
>>> property in pinctrl nodes with wakeup-interrupt-controller. The PM is
>>> not enabled in Exynos850 platform yet, so I can't really test if
>>> interrupts I mentioned are able to wake up the system.
>>
>> Thanks for confirming, I'll adjust the schema.
>>
>>>
>>> After adding this patch ("arm64: dts: exynos: Add missing gpm6 and
>>> gpm7 nodes to Exynos850"), I can't see this error message anymore:
>>>
>>>     samsung-pinctrl 11c30000.pinctrl: irq number for muxed EINTs not found
>>>
>>> That's because exynos_eint_wkup_init() function exits in this check:
>>>
>>>     if (!muxed_banks) {
>>>         of_node_put(wkup_np);
>>>         return 0;
>>>     }
>>>
>>> But I actually can see another error message, printed in
>>> exynos_eint_gpio_init() function (for wake-up capable pinctrl nodes,
>>> because those nodes don't have "interrupts" property now -- you
>>> removed those in your patch):
>>>
>>>     samsung-pinctrl 11850000.pinctrl: irq number not available
>>>     samsung-pinctrl 11c30000.pinctrl: irq number not available
>>>
>>> which in turn leads to exynos_eint_gpio_init() function to exit with
>>> -EINVAL code in the very beginning, and I'm not sure if it's ok? As I
>>> said, those errors only appear after your patch ("arm64: dts: exynos:
>>> drop incorrectly placed wakeup interrupts in Exynos850").
>>
>> Yeah, I replied to this next to my patch. I think my patch was not
>> correct and you need one - exactly one - interrupt for regular GPIO
>> interrupts.
>>
> 
> I just need to remove ".eint_gpio_init" in exynos850_pin_ctrl[] for
> pinctrl_alive and pinctrl_gpmc. Those already have ".eint_wkup_init",
> which is enough to handle all interrupts (per-pin). GPIO_ALIVE and
> GPIO_GPMC lack EINT capabilities: judging from TRM, there are no EINT
> interrupts (like EINT_SVC, which is accessed in EINT ISR), and there
> are no EINT interrupts wired to GIC (like INTREQ__GPIO_ALIVE or
> INTREQ__GPIO_GPMC). With removed ".eint_gpio_init", I can see in
> "/proc/interrupts" that corresponding interrupts are still handled
> properly (because of .eint_wkup_init), and the error message is gone.

This would mean that my dts patch removing all interrupts for alive and
cmgp was correct:
https://lore.kernel.org/linux-samsung-soc/66754058-187e-ffd5-71ba-4720101f5d98@xxxxxxxxxxxxx/T/#mf0b06ebdac554d57d8230dc546c3d57d59d7bd6b
Was it?

> Will send the patch soon -- please add it to the beginning of your
> series along with my other patch I already submitted.

Sure.





Best regards,
Krzysztof