On 07 January 2020 08:09, Marco Felsch wrote:
> Hi Adam, Dmitry,
>
> On 19-12-12 10:08, Adam Thomson wrote:
> > On 10 December 2019 08:28, Marco Felsch wrote:
> >
> > > Hi Adam,
> > >
> > > On 19-12-02 12:15, Adam Thomson wrote:
> > > > On 27 November 2019 13:23, Marco Felsch wrote:
> > > >
> > > > > There was a bug within the driver since commit f889beaaab1c ("Input:
> > > > > da9063 - report KEY_POWER instead of KEY_SLEEP during power
> > > > > key-press"). Since we fixed the bug the KEY_POWER will be reported
> > > > > always so we need to adapt the dt-bindings too. Make the description
> > > > > more precise while on it.
> > > > >
> > > > > Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
> > > > > ---
> > > > > v2:
> > > > > - change description according Dmitry's suggestion.
> > > > >
> > > > > Documentation/devicetree/bindings/input/da9062-onkey.txt | 5 ++---
> > > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> > > > > b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> > > > > index 0005b2bdcdd7..9f895454179d 100644
> > > > > --- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> > > > > +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> > > > > @@ -15,9 +15,8 @@ Required properties:
> > > > >
> > > > > Optional properties:
> > > > >
> > > > > -- dlg,disable-key-power : Disable power-down using a long key-press. If
> this
> > > > > - entry exists the OnKey driver will remove support for the KEY_POWER
> key
> > > > > - press when triggered using a long press of the OnKey.
> > > > > +- dlg,disable-key-power : If this property is present, the host will not be
> > > > > + issuing shutdown command over I2C in response to a long key-press.
> > > >
> > > > This also changes behaviour of button press reporting as the driver will not
> > > > report a longer press (i.e. a button hold where the driver polls for release).
> > > > It will only report a short key press to user-space with this property
> provided.
> > > >
> > > > The question here is do we still want to support long press reporting but
> > > > without the I2C sequence for shutdown? If so the driver needs to be
> updated
> > > to
> > > > work this way as right now it doesn't.
> > >
> > > Good point. I checked the driver and the documentation for the
> > > da9062/3 again and it seems that we interrupt the pmic hw by doing the
> > > shutdown by itself. As the documentation says:
> > >
> > > DA9063:
> > > If the hardware reset was initiated by a (debounced) press of nONKEY (or
> > > GPIO14 and GPIO15 together) longer than SD_DELAY, the DA9063 initially
> > > only asserts control bit KEY_RESET in the fault register and signals a
> > > non-maskable interrupt allowing the host to clear the armed reset
> > > sequence within 1 s. If the host does not clear KEY_RESET then a
> > > shutdown to RESET mode is executed. KEY_SD_MODE determines if normal
> > > power sequence timing or a fast shutdown is implemented.
> > >
> > > DA9062:
> > > If the reset was initiated by a user’s long press of nONKEY, initially
> > > only KEY_RESET is set and the nIRQ port will be asserted. KEY_RESET
> > > signals the host that a shutdown sequence is started. If the host does
> > > not then clear KEY_RESET within 1 s by writing a 1 to the related bit in
> > > register FAULT_LOG, the shutdown sequence will complete. When the reset
> > > condition has disappeared, DA9062 requires a supply (VSYS >
> > > VDD_FAULT_UPPER) that provides enough power to start-up from the
> > > POWERDOWN mode.
> > >
> > > So we don't need to check for the KEY_RESET? This would cleanup the code
> > > a bit.
> >
> > We could remove that but I think the intention originally was to have this code
> > there in case there was some way to more gracefully shutdown the system in
> this
> > scenario. Right now that's not the case as the code simply calls to shutdown
> > the pmic via a manual register call, but maybe in the future this could be made
> > more gracful. Another slight advantage of leaving that code in is that we're
> > not waiting for another second delay for the PMIC to pull the plug.
> >
> > With regards to this patch and the subsequent one to update the OnKey driver,
> I
> > think we should deprecate this property. The OnKey mode binding you added
> in
> > a different patch will configure the OnKey according to how you want it to
> > behave in hardware so I don't think this property makes much sense anymore.
> We
> > can then remove the need for 'key_power' usage in the driver.
>
> Is it okay for you both to drop this patch from this series and open a
> new 'rework' series?
I have no issues with this.
