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
