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

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

 



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?

Thanks.

Best regards,
Yegor



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux