Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly

From: Tony Lindgren <tony@atomide.com>
To: Yegor Yefremov <yegorslists@googlemail.com>
Cc: linux-omap@vger.kernel.org, vkoul@kernel.org,
	Bin Liu <b-liu@ti.com>, linux-usb <linux-usb@vger.kernel.org>
Subject: Re: musb: cppi41: broken high speed FTDI functionality when connected to musb directly
Date: Fri, 27 Sep 2019 08:19:35 -0700	[thread overview]
Message-ID: <20190927151935.GD5610@atomide.com> (raw)
In-Reply-To: <CAGm1_kuQTtyrdwXAV9NCHnvj3f5d7TixmqCPw=Cxd2A=jKSYmg@mail.gmail.com>

* Yegor Yefremov <yegorslists@googlemail.com> [190927 12:31]:
> On Fri, Sep 27, 2019 at 10:18 AM Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
> >
> > I was porting my system from 3.18/4.2 to 5.3. During this process I
> > noticed that FT4232 that is attached directly to musb is not working
> > correctly when opened for the first time: tx is working but nothing
> > can be received. On the second opening everything is working fine.
> > When the same chip is connected via a USB hub - everything is working
> > from the very beginning.
> >
> > I could reproduce this issue using BeagleBone Black with omap2plus_defconfig.
> >
> > # lsusb -t
> > +/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> >     |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
> >     |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
> >     |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
> >     |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
> >
> > git bisect revealed the following:
> >
> > fdea2d09b997ba4c86e7a707a5fac87c305f2131 is the first bad commit
> > commit fdea2d09b997ba4c86e7a707a5fac87c305f2131
> > Author: Tony Lindgren <tony@atomide.com>
> > Date:   Wed Aug 31 07:19:59 2016 -0700
> >
> >     dmaengine: cppi41: Add basic PM runtime support
> >
> >     Let's keep the device enabled between cppi41_dma_issue_pending()
> >     and dmaengine_desc_get_callback_invoke() and rely on the PM runtime
> >     autoidle timeout elsewhere.
> >
> >     As the PM runtime is for whole device, not for each channel,
> >     we need to queue pending transfers if the device is PM runtime
> >     suspended. Then we start the pending transfers in PM runtime
> >     resume.
> >
> >     Signed-off-by: Tony Lindgren <tony@atomide.com>
> >     Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> >
> > :040000 040000 8cf92c09083541dfdee01cc2973e73ef520f4fb1
> > a03c1a7ba8e723f7b503733c46edaa4141483265 M      drivers
> >
> > Any idea?
> 
> The problems can be reproduced with other FTDI chips like FT232R.
> 
> Invoking "minicom -D /dev/ttyUSB0" and typing some characters is
> enough to reproduce the issue (just in case, hw flow control should be
> disabled).
> 
> cp210x based converter is working without an issue. So only FTDI chips
> are affected so far.

Hmm OK. Maybe this could be an issue where the FTDI chip takes
longer to enumerate and cppi41 is already suspended by then?

At least we had a similar issue with commit ae4a3e028bb8
("dmaengine: cppi41: Fix runtime PM timeouts with USB mass
storage").

Regards,

Tony