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 <[email protected]>
---
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
+ */
+ if (!pm_runtime_enabled(twl->dev)) {
+ cancel_delayed_work(&twl->id_workaround_work);
+ schedule_delayed_work(&twl->id_workaround_work, HZ);
+ return IRQ_HANDLED;
+ }
+
mutex_lock(&twl->lock);
if (status >= 0 && status != twl->linkstat) {
status_changed =
--
2.11.0
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 <[email protected]>
> ---
> 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? How can we guarantee that the interrupt will be
re-triggered?
> + if (!pm_runtime_enabled(twl->dev)) {
> + cancel_delayed_work(&twl->id_workaround_work);
> + schedule_delayed_work(&twl->id_workaround_work, HZ);
> + return IRQ_HANDLED;
> + }
> +
> mutex_lock(&twl->lock);
> if (status >= 0 && status != twl->linkstat) {
> status_changed =
> --
> 2.11.0
>
Thanks.
--
Dmitry
Hi Dmitry,
On Mon, 17 Sep 2018 10:51:31 -0700
Dmitry Torokhov <[email protected]> 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 <[email protected]>
> > ---
> > 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
On Mon, Sep 17, 2018 at 08:56:34PM +0200, Andreas Kemnade wrote:
> Hi Dmitry,
>
> On Mon, 17 Sep 2018 10:51:31 -0700
> Dmitry Torokhov <[email protected]> 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 <[email protected]>
> > > ---
> > > 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
I see. This all seems a bit wonky, to be honest. I would expect that the
driver would have a suspend routine that disables interrupt and also
configure interrupt for wakeup (enable_irq_wake) and kick bus scanning
from there instead of aborting interrupt handler...
>
> > 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.
If we decide to keep this, it should be mod_delayed_work() I think.
Thanks.
--
Dmitry
Hi,
On Mon, 17 Sep 2018 15:23:45 -0700
Dmitry Torokhov <[email protected]> wrote:
> On Mon, Sep 17, 2018 at 08:56:34PM +0200, Andreas Kemnade wrote:
> > Hi Dmitry,
> >
> > On Mon, 17 Sep 2018 10:51:31 -0700
> > Dmitry Torokhov <[email protected]> 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 <[email protected]>
> > > > ---
> > > > 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
>
> I see. This all seems a bit wonky, to be honest. I would expect that the
> driver would have a suspend routine that disables interrupt and also
> configure interrupt for wakeup (enable_irq_wake) and kick bus scanning
> from there instead of aborting interrupt handler...
>
well, that seems doable. So there will be a v2.
> >
> > > 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.
>
> If we decide to keep this, it should be mod_delayed_work() I think.
>
Well, is that valid for the other uses of id_workaround_work() (which
are clearly required)? So there should be a second, independent
cleanup patch for the existing uses?
Regards,
Andreas
On Tue, Sep 18, 2018 at 06:16:19PM +0200, Andreas Kemnade wrote:
> Hi,
>
> On Mon, 17 Sep 2018 15:23:45 -0700
> Dmitry Torokhov <[email protected]> wrote:
>
> > On Mon, Sep 17, 2018 at 08:56:34PM +0200, Andreas Kemnade wrote:
> > > Hi Dmitry,
> > >
> > > On Mon, 17 Sep 2018 10:51:31 -0700
> > > Dmitry Torokhov <[email protected]> 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 <[email protected]>
> > > > > ---
> > > > > 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
> >
> > I see. This all seems a bit wonky, to be honest. I would expect that the
> > driver would have a suspend routine that disables interrupt and also
> > configure interrupt for wakeup (enable_irq_wake) and kick bus scanning
> > from there instead of aborting interrupt handler...
> >
> well, that seems doable. So there will be a v2.
>
> > >
> > > > 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.
> >
> > If we decide to keep this, it should be mod_delayed_work() I think.
> >
> Well, is that valid for the other uses of id_workaround_work() (which
> are clearly required)? So there should be a second, independent
> cleanup patch for the existing uses?
Yes, mod_delayed_work() is replacement for cancel + reschedule. I guess
this driver was created before mod_delayed_work() was added to the
kernel.
Thanks.
--
Dmitry