All of lore.kernel.org
 help / color / mirror / Atom feed
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>
Subject: Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly
Date: Tue, 1 Oct 2019 09:43:51 -0700	[thread overview]
Message-ID: <20191001164351.GJ5610@atomide.com> (raw)
In-Reply-To: <CAGm1_ksg2x9USqB+XGhkMQpA-zc77Ha1-j+foPJFR7R3XPZsNg@mail.gmail.com>

* Yegor Yefremov <yegorslists@googlemail.com> [191001 09:20]:
> On Tue, Oct 1, 2019 at 10:03 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Mon, Sep 30, 2019 at 09:54:11PM +0200, Sebastian Reichel wrote:
> > > Hi,
> > >
> > > On Mon, Sep 30, 2019 at 08:23:30AM -0700, Tony Lindgren wrote:
> >
> > > > Actually playing with the cppi41 timeout might be more suitable here,
> > > > they use the same module clock from what I remember though. So
> > > > maybe increase the cppi41 autosuspend_timeout from 100 ms to 500 ms
> > > > or higher:
> > > >
> > > > # echo 500 > /sys/bus/platform/drivers/cppi41-dma-engine/47400000.dma-controller/power/autosuspend_delay_ms
> > > >
> > > > If changing the autosuspend_timeout_ms value does not help, then
> > > > try setting control to on there.
> > >
> > > I did not check the details, but from the cover-letter this might be
> > > woth looking into:
> > >
> > > https://lore.kernel.org/lkml/20190930161205.18803-1-johan@kernel.org/
> >
> > No, that one should be unrelated as it would only prevent later suspends after
> > a driver has been unbound (and rebound).
> 
> 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?

Can you check that cppi41_dma_issue_pending() really gets
called for the first request and it adds the request to the
queue by adding a printk to cppi41_dma_issue_pending()?

> [1] http://ftp.visionsystems.de/temp/serialtest.py

For me this script somehow fails to configure the ports with:

$ python2 serialtest.py -c2 /dev/ttyUSB0 /dev/ttyUSB0
Openning one of the serial ports failed
Openning one of the serial ports failed

The permissions are set properly as I have minicom working..
So still no luck reproducing.

Regards,

Tony

  reply	other threads:[~2019-10-01 16:52 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 [this message]
2019-10-01 22:03                         ` Tony Lindgren
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=20191001164351.GJ5610@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=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.