Hi Geert, > -----Original Message----- > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> > Sent: Monday, December 11, 2023 8:53 AM > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 defconfig > > Hi Biju, > > On Mon, Dec 11, 2023 at 9:32 AM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > wrote: > > > -----Original Message----- > > > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> > > > Sent: Monday, December 11, 2023 8:20 AM > > > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 > > > defconfig > > > > > > On Sun, Dec 10, 2023 at 10:50 AM Biju Das > > > <biju.das.jz@xxxxxxxxxxxxxx> > > > wrote: > > > > > -----Original Message----- > > > > > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> > > > > > Sent: Friday, December 1, 2023 3:42 PM > > > > > Subject: Re: [PATCH 6/6] arm64: defconfig: Enable Renesas DA9062 > > > > > defconfig > > > > > > > > > > On Fri, Dec 1, 2023 at 4:02 PM Biju Das > > > > > <biju.das.jz@xxxxxxxxxxxxxx> > > > > > wrote: > > > > > > > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> On Fri, Dec > > > > > > > 1, > > > > > > > 2023 at 12:09 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > > > > > > wrote: > > > > > > > > Enable the config for the Renesas DA9062 PMIC and RTC, as > > > > > > > > it is populated on RZ/G2UL SMARC EVK. > > > > > > > > > > > > > > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > > > > > > > > > > > > > Thanks for your patch! > > > > > > > > > > > > > > LGTM, but I would have expected (at least) > > > > > > > > > > > > > > CONFIG_INPUT_DA9063_ONKEY=m > > > > > > > > > > > > > > too, cfr. my comments on patch 5/6. > > > > > > > > > > > > I have tested this, but I get "da9063-onkey da9062-onkey: > > > > > > error - > > > ENXIO: > > > > > IRQ ONKEY not found" > > > > > > So, I won't be able to test onkey events. So plaaning to > > > > > > disable this > > > > > node. > > > > > > > > > > Indeed, currently drivers/input/misc/da9063_onkey.c requires an > > > > > interrupt to function. I wonder if it can be made to work using > > > > > a timer and pure polling... > > > > > > > > Yes, that is possible by either adding a debugfs to enable polling > > > > for > > > testing. > > > > > > > > Or > > > > > > > > a device tree property for adding poll delay, so that one can have > > > polling support to test onkey driver. > > > > > > I would go for the latter, cfr. poll-interval in > > > Documentation/devicetree/bindings/input/gpio-keys.yaml. > > > > > > > Basically, on a production system we should avoid polling as it > > > unnecessarily wakeup the system. > > > > > > Wouldn't polling (by Linux) only happen when the system is already > awake? > > > > IIUC, That is an overhead. If there is no load, system goes to suspend > > mode and the timer for the polling (SCAN keys) will wakeup the system > > and same process repeats. If we have a PMIC IRQ, this won't happen. > > Ah, you mean idle. Yes, that does incur a (small) overhead (I guess there > are other timers running, too). Yes. > I don't think any timer runs when the system is suspended. I guess, If we are controlling PM through CPU idle states, this will have an effect. We schedule timers for poll intervals from onkey driver, when it expires it will wakeup the system and again based on idle state, it enters into some retention state and goes on. Cheers, BIju
