[PATCH] arm64: dts: rockchip: Add power button for RK3399 Puma

[Heiko Stübner]

Am Montag, 30. September 2024, 11:11:56 CEST schrieb Quentin Schulz:
> Hi Heiko,
> 
> On 9/30/24 10:49 AM, Heiko Stübner wrote:
> > Hey Quentin, Daniel,
> > 
> > Am Donnerstag, 26. September 2024, 14:34:30 CEST schrieb Quentin Schulz:
> >> On 9/25/24 9:28 AM, Daniel Semkowicz wrote:
> >>> There is a PWRBTN# input pin exposed on a Q7 connector. The pin
> >>> is routed to a GPIO0_A1 through a diode. Q7 specification describes
> >>> the PWRBTN# pin as a Power Button signal.
> >>> Configure the pin as KEY_POWER, so it can function as power button and
> >>> trigger device shutdown.
> >>> Add the pin definition to RK3399 Puma dts, so it can be reused
> >>> by derived platforms, but keep it disabled by default.
> >>>
> >>> Enable the power button input on Haikou development board.
> >>>
> >>> Signed-off-by: Daniel Semkowicz <dse at thaumatec.com>
> >>
> >> This works, thanks.
> >>
> >> Tested-by: Quentin Schulz <quentin.schulz at cherry.de>
> >>
> >> Now I have some questions I wasn't able to answer myself, maybe someone
> >> can provide some feedback on those :)
> >>
> >> We already have a gpio-keys for buttons on Haikou, c.f.
> >> https://elixir.bootlin.com/linux/v6.11/source/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts#L22.
> >> Those signals are directly routed to the SoM and follow the Qseven standard.
> >>
> >> The same applies to PWRBTN# signal.
> >>
> >> However, here we have one gpio-keys for PWRBTN# in Puma DTSI and one
> >> gpio-keys for the buttons and sliders on Haikou devkit in Haikou DTS.
> >>
> >> I'm a bit undecided on where this should go.
> >>
> >> Having all button/slider signals following the Qseven standard in Puma
> >> DTSI and enable the gpio-keys only in the devkit would make sense to me,
> >> so that other baseboards could easily make use of it. However, things
> >> get complicated if the baseboard manufacturer decides to only implement
> >> **some** of the signals, for which we then need to remove some nodes
> >> from gpio-keys (and pinctrl entries) since gpio-keys doesn't check the
> >> "status" property in its child nodes (though that could be fixed). At
> >> which point, it's not entirely clear if having it in Puma DTSI is
> >> actually beneficial.
> >>
> >> Someone has an opinion/recommendation on that?
> > 
> > I guess from a platform perspective nobody really cares, so as that is
> > "your" board, it comes down to a policy decision on your part ;-) .
> > 
> > While pins follow the q7 standard, there may very well be some lax
> > handling of that standard in some places, and I guess gpio lines could
> > be re-used for something else if needed, as something like the lid-switch
> > is probably non-essential.
> > 
> > Also a gpio-key input does not create that much code-overhead if
> > replicated, so personally I'd just stick the power-button with the other
> > buttons in the haikou dts.
> > 
> > Which is also a way better thing than having multiple gpio-keys instances
> > that userspace then has to handle.
> > 
> 
> Yes, but this also means "code" duplication for whoever needs this for 
> their baseboard, instead of just having to add a &gpio_keys { status = 
> "okay"; }.

Yes :-) .

gpio-keys is special in a way in that you could end up with a different set
of enabled keys per baseboard - dependent on how closely it follows the
standard.

So if someone repurposed the lid-switch only, you'd start changing the
core node again. Hence for the gpio-keys it's probably easier to define
the set of keys in the baseboard.

It's of course different for regulator-infrastructure and such.

> I don't think there's a good solution here, so I would suggest we go 
> with everything in Haikou's gpio-keys as Heiko suggested then, @Daniel 
> if you agree can you send a v2 for that?

I'll wait for v2 then.

Heiko