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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 27, 2019 at 10:18 AM Yegor Yefremov
<yegorslists@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx>
> 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@xxxxxxxxxxx>
>     Signed-off-by: Vinod Koul <vinod.koul@xxxxxxxxx>
>
> :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.

Yegor



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux