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
