On 08/16/2016 04:31 PM, Felipe Balbi wrote:
Hi,
Ayaka <ayaka@xxxxxxxxxxx> writes:
ayaka <ayaka@xxxxxxxxxxx> writes:
On 08/13/2016 01:44 AM, Greg KH wrote:
On Sat, Aug 13, 2016 at 12:38:46AM +0800, ayaka wrote:
On 08/12/2016 03:40 PM, Greg KH wrote:
On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote:
Hello all:
I recently add a support for customize am3358 board using the branch
processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with musb
at the peripheral mode.
Then you are going to have to get support from TI for this, nothing we
can do here about random vendor kernel trees, sorry.
If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we
I have tried the 4.8-rc1, I meet the same problem.
What problem is that exactly?
Sorry, the USB1 can't work at high speed gadget mode and have DMA problem.
musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
-517 is EPROBE_DEFER. Most likely DMA hasn't probed and MUSB is
deferring to try later. This does _NOT_ MUSB can't work with
DMA. Perhaps you didn't enable support for MUSB's DMA engine.
I have set the status of cppi41dma to okay in dts. And CONFIG_USB_TI_CPPI41_DMA,
CONFIG_TI_CPPI41 and CONFIG_TI_EDMA are enabled with build into kernel.
Anything else I should do?
no, that should do it. Since musb returned -EPROBE_DEFER, it will retry
probing later. Check if musb probed fine. The easiest way is to check if
you have anything in /sys/class/udc/
Yes, it has musb-hdrc.0.auto. But it doesn't mean that it fallback PIO mode?
Actually I don't care whether it use PIO or DMA, I just can't bear it
work in USB 2.0 Full Speed mode, too slow.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
