On Sat, 15 Jan 2022 at 17:46, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: > > 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? > Yep. But patches [1,2] I sent recently should be probably applied before yours -- they belong together. Please take those in your patch series (when sending the next version). Thanks! [1] https://lkml.org/lkml/2022/1/14/861 [2] https://lkml.org/lkml/2022/1/3/680 > > 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
