Hi Dmitry,
On Mon, 17 Sep 2018 10:51:31 -0700
Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> Hi Andreas,
>
> On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote:
> > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS,
> > the counter will be incremented but the resume callback not called,
> > so enumeration and charging will not start properly.
> > To avoid that happen, wait and try again later.
> >
> > Practically this happens when the device is woken up from suspend by
> > plugging in usb.
> >
> > Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
> > ---
> > drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c
> > index a44680d64f9b..1f3cf4e48383 100644
> > --- a/drivers/phy/ti/phy-twl4030-usb.c
> > +++ b/drivers/phy/ti/phy-twl4030-usb.c
> > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
> >
> > status = twl4030_usb_linkstat(twl);
> >
> > + /* we might get here too early when runtime is not ready yet
> > + * and we will get an EACCESS later, so try again later
> > + */
>
> How exactly can this happen? What disables (and later re-enables)
> runtime PM?
If the whole resume process is started by plugging in usb, the
interrupt will be triggered still in the resume process so that
runtime resume is not yet possible, pm_runtime_get_sync() returns
EACCESS
> How can we guarantee that the interrupt will be
> re-triggered?
>
The interrupt will not be re-triggered but the handler will be
called at some other places...
> > + if (!pm_runtime_enabled(twl->dev)) {
> > + cancel_delayed_work(&twl->id_workaround_work);
> > + schedule_delayed_work(&twl->id_workaround_work, HZ);
> > + return IRQ_HANDLED;
> > + }
> > +
... for example by this delayed work which is already there.
Regards,
Andreas
Attachment:
pgpkVcnOYDuXs.pgp
Description: OpenPGP digital signature
