[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPLW+4kEQYrTvMwodbha4SV9mDS36sjxdsiCwVQptmoShb_5hQ@mail.gmail.com>
Date: Sat, 15 Jan 2022 22:38:36 +0200
From: Sam Protsenko <semen.protsenko@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc: Chanho Park <chanho61.park@...sung.com>,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Tomasz Figa <tomasz.figa@...il.com>
Subject: Re: Exynos850 and ExynosAuto v9 pinctrl wakeup muxed interrupt
On Sat, 15 Jan 2022 at 17:46, Krzysztof Kozlowski
<krzysztof.kozlowski@...onical.com> wrote:
>
> On 14/01/2022 21:32, Sam Protsenko wrote:
> > On Fri, 7 Jan 2022 at 10:16, Krzysztof Kozlowski
> > <krzysztof.kozlowski@...onical.com> wrote:
> >>
> >> On 03/01/2022 21:59, Sam Protsenko wrote:
> >>> On Thu, 30 Dec 2021 at 21:34, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@...onical.com> 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@canonical.com/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
Powered by blists - more mailing lists