From: Tony Lindgren <tony@atomide.com>
To: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Johan Hovold <johan@kernel.org>,
Sebastian Reichel <sre@kernel.org>,
linux-omap@vger.kernel.org, vkoul@kernel.org,
Bin Liu <b-liu@ti.com>, linux-usb <linux-usb@vger.kernel.org>,
Andrey Skvortsov <andrej.skvortzov@gmail.com>,
giulio.benetti@benettiengineering.com,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Subject: Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly
Date: Tue, 1 Oct 2019 15:03:21 -0700 [thread overview]
Message-ID: <20191001220321.GK5610@atomide.com> (raw)
In-Reply-To: <20191001164351.GJ5610@atomide.com>
Hi,
* Tony Lindgren <tony@atomide.com> [191001 16:52]:
> * Yegor Yefremov <yegorslists@googlemail.com> [191001 09:20]:
> > I've tried to increase the autosuspend_delay_ms and to set control to
> > "on" but nothing changes. Below you can see the output of my testing
> > script [1] (Py2 only). As one can see, the first cycle i.e. after the
> > port is open for the first time, fails. But the subsequent cycle is
> > successful. If you invoke the script again, everything repeats.
> >
> > I've also made printk() in cppi41_run_queue() and it looks like this
> > routine will be called from cppi41_dma_issue_pending() only in the
> > beginning of the second test cycle.
>
> So sounds like for you intially cppi41_dma_issue_pending() has
> !cdd->is_suspended and just adds the request to the queue. And
> then cppi41_run_queue() never gets called if this happens while
> we have cppi41_runtime_resume() is still running?
I got it reproducable here by adding msleep(500) to the beginning
of cppi41_runtime_resume() :) Otherwise I'm only able to trigger
the issue maybe one out of 20 tries it seems.
Turns out the first dma call done by musb_ep_program() must wait
if cppi41 is PM runtime suspended. Otherwise musb_ep_program()
continues with other PIO packets before the DMA transfer is
started.
The patch below fixes it for me with a pm_runtime_get_sync()
in device_prep_slave_sg, so adding Peter and Vinod to Cc.
The other way to fix this would be to just wake up cpp41 in
cppi41_dma_prep_slave_sg() and return NULL so that we can
have musb_ep_program() continue with PIO while cppi41 is
asleep.
Anyways, care to try it out and see if it fixes your issue?
Regards,
Tony
8< ------------------
diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
--- a/drivers/dma/ti/cppi41.c
+++ b/drivers/dma/ti/cppi41.c
@@ -586,9 +586,18 @@ static struct dma_async_tx_descriptor *cppi41_dma_prep_slave_sg(
enum dma_transfer_direction dir, unsigned long tx_flags, void *context)
{
struct cppi41_channel *c = to_cpp41_chan(chan);
+ struct cppi41_dd *cdd = c->cdd;
struct cppi41_desc *d;
struct scatterlist *sg;
unsigned int i;
+ int error;
+
+ error = pm_runtime_get_sync(cdd->ddev.dev);
+ if (error < 0) {
+ pm_runtime_put_noidle(cdd->ddev.dev);
+
+ return NULL;
+ }
d = c->desc;
for_each_sg(sgl, sg, sg_len, i) {
@@ -611,6 +620,9 @@ static struct dma_async_tx_descriptor *cppi41_dma_prep_slave_sg(
d++;
}
+ pm_runtime_mark_last_busy(cdd->ddev.dev);
+ pm_runtime_put_autosuspend(cdd->ddev.dev);
+
return &c->txd;
}
--
2.23.0
next prev parent reply other threads:[~2019-10-01 22:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 8:18 musb: cppi41: broken high speed FTDI functionality when connected to musb directly Yegor Yefremov
2019-09-27 12:30 ` Yegor Yefremov
2019-09-27 15:19 ` Tony Lindgren
2019-09-27 15:57 ` Tony Lindgren
2019-09-28 16:09 ` Yegor Yefremov
2019-09-30 6:59 ` Yegor Yefremov
2019-09-30 8:19 ` Yegor Yefremov
2019-09-30 14:57 ` Tony Lindgren
2019-09-30 15:23 ` Tony Lindgren
2019-09-30 19:54 ` Sebastian Reichel
2019-10-01 8:03 ` Johan Hovold
2019-10-01 9:19 ` Yegor Yefremov
2019-10-01 16:43 ` Tony Lindgren
2019-10-01 22:03 ` Tony Lindgren [this message]
2019-10-02 6:56 ` Yegor Yefremov
2019-10-02 16:52 ` Tony Lindgren
2019-10-03 8:39 ` Yegor Yefremov
2019-10-21 8:39 ` Yegor Yefremov
2019-10-22 14:56 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191001220321.GK5610@atomide.com \
--to=tony@atomide.com \
--cc=andrej.skvortzov@gmail.com \
--cc=b-liu@ti.com \
--cc=bigeasy@linutronix.de \
--cc=giulio.benetti@benettiengineering.com \
--cc=johan@kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=sre@kernel.org \
--cc=vkoul@kernel.org \
--cc=yegorslists@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.