DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tim Nordell]

Hi all -

I'm running kernel v3.19 (although I've tried v4.1-rc2's version of the 
MUSB code) on a DM3730 processor.  I'm running into an issue where if I 
enable MUSB Inventra DMA, plug in a USB Ethernet Dongle, and run iperf 
between the dongle and a PC, the MUSB driver stops working.  I get the 
following in my kernel log, twice back-to-back:

     musb_host_rx 1762: Rx interrupt with no errors or packet!

Any ideas?

The test above works in PIO mode, but I'd like to reduce the system CPU 
usage of the driver by using DMA.  I'm using a ASIX AX88772B Ethernet 
dongle, although, this shouldn't impact the error above.  I also tried 
re-reading the RXCSR register immediately after the error printout 
above, and the immediate subsequent time it contains the bit the driver 
is looking for.  I tried nesting the check so that if the bit the driver 
is looking for is set with an immediate subsequent read that it would 
continue past it, but it still keels over (albeit lasting maybe a second 
longer).

Something about this feels race conditiony too.  Depending on the kernel 
configuration options in the kernel debug menu (which slows down other 
parts of the kernel), or if I enable verbose debug message output from 
the MUSB driver, it lasts much, much longer before keeling over as a 
system.  You can restore normal behavior by unplugging/replugging in the 
device.

Thanks,
Tim

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tony Lindgren]

* Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> [150506 16:19]:
> Hi all -
> 
> I'm running kernel v3.19 (although I've tried v4.1-rc2's version of the MUSB
> code) on a DM3730 processor.  I'm running into an issue where if I enable
> MUSB Inventra DMA, plug in a USB Ethernet Dongle, and run iperf between the
> dongle and a PC, the MUSB driver stops working.  I get the following in my
> kernel log, twice back-to-back:
> 
>     musb_host_rx 1762: Rx interrupt with no errors or packet!
> 
> Any ideas?
> 
> The test above works in PIO mode, but I'd like to reduce the system CPU
> usage of the driver by using DMA.  I'm using a ASIX AX88772B Ethernet
> dongle, although, this shouldn't impact the error above.  I also tried
> re-reading the RXCSR register immediately after the error printout above,
> and the immediate subsequent time it contains the bit the driver is looking
> for.  I tried nesting the check so that if the bit the driver is looking for
> is set with an immediate subsequent read that it would continue past it, but
> it still keels over (albeit lasting maybe a second longer).
> 
> Something about this feels race conditiony too.  Depending on the kernel
> configuration options in the kernel debug menu (which slows down other parts
> of the kernel), or if I enable verbose debug message output from the MUSB
> driver, it lasts much, much longer before keeling over as a system.  You can
> restore normal behavior by unplugging/replugging in the device.

This sounds like some issue dealing with certain size transfers where
there's data remaining after a DMA transfer. You might be able to make
it easily reproducable with a variable size ping from your PC even with
debugging enabled. Something like the script below.

Regards,

Tony

8< --------------
#!/bin/bash

device=$1
size=$2

while [ 1 ]; do
	#echo "Pinging with size $size"
	if ! ping -w0 -c1 $device -s$size > /dev/null 2>&1; then
		break;
	fi
	size=$(expr $SIZE + 1)

	if [ $size -gt 8192 ]; then
		size=1
	fi
done

echo "Test ran up to $size"
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

Hi,

On Thu, May 07, 2015 at 09:06:06AM -0700, Tony Lindgren wrote:
> * Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> [150506 16:19]:
> > Hi all -
> > 
> > I'm running kernel v3.19 (although I've tried v4.1-rc2's version of the MUSB
> > code) on a DM3730 processor.  I'm running into an issue where if I enable
> > MUSB Inventra DMA, plug in a USB Ethernet Dongle, and run iperf between the
> > dongle and a PC, the MUSB driver stops working.  I get the following in my
> > kernel log, twice back-to-back:
> > 
> >     musb_host_rx 1762: Rx interrupt with no errors or packet!
> > 
> > Any ideas?
> > 
> > The test above works in PIO mode, but I'd like to reduce the system CPU
> > usage of the driver by using DMA.  I'm using a ASIX AX88772B Ethernet
> > dongle, although, this shouldn't impact the error above.  I also tried
> > re-reading the RXCSR register immediately after the error printout above,
> > and the immediate subsequent time it contains the bit the driver is looking
> > for.  I tried nesting the check so that if the bit the driver is looking for
> > is set with an immediate subsequent read that it would continue past it, but
> > it still keels over (albeit lasting maybe a second longer).
> > 
> > Something about this feels race conditiony too.  Depending on the kernel
> > configuration options in the kernel debug menu (which slows down other parts
> > of the kernel), or if I enable verbose debug message output from the MUSB
> > driver, it lasts much, much longer before keeling over as a system.  You can
> > restore normal behavior by unplugging/replugging in the device.
> 
> This sounds like some issue dealing with certain size transfers where
> there's data remaining after a DMA transfer. You might be able to make
> it easily reproducable with a variable size ping from your PC even with
> debugging enabled. Something like the script below.
> 
> Regards,
> 
> Tony
> 
> 8< --------------
> #!/bin/bash
> 
> device=$1
> size=$2
> 
> while [ 1 ]; do
> 	#echo "Pinging with size $size"
> 	if ! ping -w0 -c1 $device -s$size > /dev/null 2>&1; then
> 		break;
> 	fi
> 	size=$(expr $SIZE + 1)
> 
> 	if [ $size -gt 8192 ]; then
> 		size=1
> 	fi
> done
> 
> echo "Test ran up to $size"

I'd be very much interested in getting such logs :-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tim Nordell]

Hi -

On 05/07/15 11:16, Felipe Balbi wrote:
> Hi,
>
> On Thu, May 07, 2015 at 09:06:06AM -0700, Tony Lindgren wrote:
>> * Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> [150506 16:19]:
>>> Hi all -
>>>

*snip*

>>>
>>> Something about this feels race conditiony too.  Depending on the kernel
>>> configuration options in the kernel debug menu (which slows down other parts
>>> of the kernel), or if I enable verbose debug message output from the MUSB
>>> driver, it lasts much, much longer before keeling over as a system.  You can
>>> restore normal behavior by unplugging/replugging in the device.
>>
>> This sounds like some issue dealing with certain size transfers where
>> there's data remaining after a DMA transfer. You might be able to make
>> it easily reproducable with a variable size ping from your PC even with
>> debugging enabled. Something like the script below.
>>
>> Regards,
>>
>> Tony
>>
>> 8< --------------
>> #!/bin/bash
>>
>> device=$1
>> size=$2
>>
>> while [ 1 ]; do
>> 	#echo "Pinging with size $size"
>> 	if ! ping -w0 -c1 $device -s$size > /dev/null 2>&1; then
>> 		break;
>> 	fi
>> 	size=$(expr $SIZE + 1)

(This line should have referred to $size instead of $SIZE.)

>>
>> 	if [ $size -gt 8192 ]; then
>> 		size=1
>> 	fi
>> done
>>
>> echo "Test ran up to $size"
>
> I'd be very much interested in getting such logs :-)
>

Unfortunately, the driver works with the script above (after fixing the 
one line) so it's not a "certain size" style scenario.

Using iperf I can get traffic to stop flowing within a second of usage 
so fortunately it's highly reproducible.  One thing I tried this morning 
was to simply "ignore" the fact the RXCSR register didn't have the 
expected bit and continue in the driver.  While the throughput was 
abysmal (and DMA "errors" were reported), at least the driver didn't 
die.  I could still ping after stopping iperf.  (I don't think this is 
the appropriate thing to do, but it was just a quick and dirty test.)

However, iperf does have the ability to adjust the packet size while 
still spewing out a high-rate (configurable bandwidth) of packets. 
Armed with this, I modified the ping test above to utilize iperf instead 
at various packet sizes (granted, this would get fragmented above the 
MTU size by the IP stack), leaving it at 1000 packets per second.

Doing that as an exercise with the Ethernet dongle, it first keeled over 
at 1059 byte UDP datagrams (1101 bytes on Ethernet - I don't know how 
many USB transactions this split into exactly), at 1000 packets per 
second.  However, it doesn't consistently keel over at the same bytes 
per datagram.  Another attempt keeled over at 1052 byte UDP datagrams.

Upping the ante to 1500 packets per second, and jumping at 16-byte 
intervals for the size, it lasted from 1000 to 1352 byte size packets 
and keeled over at 1368 byte sized packets.

Some of the configurations of iperf against MUSB in DMA mode causes the 
ASIX driver (the Ethernet dongle driver) to complain too, even to the 
point of doing a NULL dereference (I will dig into this dereference). 
Not seen with the MUSB in PIO mode.

Note: Same system/kernel, configured as an Ethernet gadget does not 
exhibit the issues, although, I'm not convinced it's actually using DMA 
for this.  INTC 93 does not have any activity as a gadget (INTC 92 gets 
all the traffic).  I can improve the performance (~35% improvement) in 
PIO mode of an Ethernet gadget by configuring the dynamic FIFO in the 
MUSB to utilize double buffering, but DMA mode still falls over with a 
USB ethernet dongle attached with double buffering.  I haven't tried the 
series of iperf bandwidth tests against double buffering yet.  I also 
have the idle loops in the system disabled to improve interrupt latency 
("nohlt cpuidle.off=1").

- Tim


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Chan-Taek Park]

On Thu, May 7, 2015 at 2:17 PM, Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi -
>
> On 05/07/15 11:16, Felipe Balbi wrote:
>>
>> Hi,
>>
>> On Thu, May 07, 2015 at 09:06:06AM -0700, Tony Lindgren wrote:
>>>
>>> * Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> [150506 16:19]:
>>>>
>>>> Hi all -
>>>>
>
> *snip*
>
>>>>
>>>> Something about this feels race conditiony too.  Depending on the kernel
>>>> configuration options in the kernel debug menu (which slows down other
>>>> parts
>>>> of the kernel), or if I enable verbose debug message output from the
>>>> MUSB
>>>> driver, it lasts much, much longer before keeling over as a system.  You
>>>> can
>>>> restore normal behavior by unplugging/replugging in the device.
>>>
>>>
>>> This sounds like some issue dealing with certain size transfers where
>>> there's data remaining after a DMA transfer. You might be able to make
>>> it easily reproducable with a variable size ping from your PC even with
>>> debugging enabled. Something like the script below.
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>> 8< --------------
>>> #!/bin/bash
>>>
>>> device=$1
>>> size=$2
>>>
>>> while [ 1 ]; do
>>>         #echo "Pinging with size $size"
>>>         if ! ping -w0 -c1 $device -s$size > /dev/null 2>&1; then
>>>                 break;
>>>         fi
>>>         size=$(expr $SIZE + 1)
>
>
> (This line should have referred to $size instead of $SIZE.)
>
>>>
>>>         if [ $size -gt 8192 ]; then
>>>                 size=1
>>>         fi
>>> done
>>>
>>> echo "Test ran up to $size"
>>
>>
>> I'd be very much interested in getting such logs :-)
>>
>
> Unfortunately, the driver works with the script above (after fixing the one
> line) so it's not a "certain size" style scenario.
>
> Using iperf I can get traffic to stop flowing within a second of usage so
> fortunately it's highly reproducible.  One thing I tried this morning was to
> simply "ignore" the fact the RXCSR register didn't have the expected bit and
> continue in the driver.  While the throughput was abysmal (and DMA "errors"
> were reported), at least the driver didn't die.  I could still ping after
> stopping iperf.  (I don't think this is the appropriate thing to do, but it
> was just a quick and dirty test.)
>
> However, iperf does have the ability to adjust the packet size while still
> spewing out a high-rate (configurable bandwidth) of packets. Armed with
> this, I modified the ping test above to utilize iperf instead at various
> packet sizes (granted, this would get fragmented above the MTU size by the
> IP stack), leaving it at 1000 packets per second.
>
> Doing that as an exercise with the Ethernet dongle, it first keeled over at
> 1059 byte UDP datagrams (1101 bytes on Ethernet - I don't know how many USB
> transactions this split into exactly), at 1000 packets per second.  However,
> it doesn't consistently keel over at the same bytes per datagram.  Another
> attempt keeled over at 1052 byte UDP datagrams.
>
> Upping the ante to 1500 packets per second, and jumping at 16-byte intervals
> for the size, it lasted from 1000 to 1352 byte size packets and keeled over
> at 1368 byte sized packets.
>
> Some of the configurations of iperf against MUSB in DMA mode causes the ASIX
> driver (the Ethernet dongle driver) to complain too, even to the point of
> doing a NULL dereference (I will dig into this dereference). Not seen with
> the MUSB in PIO mode.
>
> Note: Same system/kernel, configured as an Ethernet gadget does not exhibit
> the issues, although, I'm not convinced it's actually using DMA for this.
> INTC 93 does not have any activity as a gadget (INTC 92 gets all the
> traffic).  I can improve the performance (~35% improvement) in PIO mode of
> an Ethernet gadget by configuring the dynamic FIFO in the MUSB to utilize
> double buffering, but DMA mode still falls over with a USB ethernet dongle
> attached with double buffering.  I haven't tried the series of iperf
> bandwidth tests against double buffering yet.  I also have the idle loops in
> the system disabled to improve interrupt latency ("nohlt cpuidle.off=1").
>
> - Tim
>

I'm sorry if you are already aware of this information.
Just wanted to share my experience.

AFAIK, there is a hardware bug with MUSB Host controller.
See ARM_MPU.KERNEL.39 at
http://processors.wiki.ti.com/index.php/Sitara_SDK_6.00.00_Release_Notes
I assume it is common across AM335x and DM3730.

TI has this pre-mature TX complete interrupt issue on host controller side.
Freescale has a similar pre-mature TX interrupt issue on device controller side.

It looks like TI has a patch to work around that issue.
https://gitorious.org/opensuse/kernel/commit/a655f481d83d6d37bec0a2ddfdd24c30ff8f541f

Maybe, in your case would it be due to the 25us wait loop which is too
short (I guess)?

To me TI's approach looks complicated.

Freescale's approach looks a lot simpler.
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/usb/gadget/arcotg_udc.c?h=imx_2.6.28&id=f34bd00b7b0295e723158db1f55f28416026ad94


-chan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Bin Liu]

Hi,

On Thu, May 7, 2015 at 4:07 PM, Chan-Taek Park <park.chantaek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, May 7, 2015 at 2:17 PM, Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> wrote:
>> Hi -
>>
>> On 05/07/15 11:16, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> On Thu, May 07, 2015 at 09:06:06AM -0700, Tony Lindgren wrote:
>>>>
>>>> * Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> [150506 16:19]:
>>>>>
>>>>> Hi all -
>>>>>
>>
>> *snip*
>>
>>>>>
>>>>> Something about this feels race conditiony too.  Depending on the kernel
>>>>> configuration options in the kernel debug menu (which slows down other
>>>>> parts
>>>>> of the kernel), or if I enable verbose debug message output from the
>>>>> MUSB
>>>>> driver, it lasts much, much longer before keeling over as a system.  You
>>>>> can
>>>>> restore normal behavior by unplugging/replugging in the device.
>>>>
>>>>
>>>> This sounds like some issue dealing with certain size transfers where
>>>> there's data remaining after a DMA transfer. You might be able to make
>>>> it easily reproducable with a variable size ping from your PC even with
>>>> debugging enabled. Something like the script below.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>>>
>>>> 8< --------------
>>>> #!/bin/bash
>>>>
>>>> device=$1
>>>> size=$2
>>>>
>>>> while [ 1 ]; do
>>>>         #echo "Pinging with size $size"
>>>>         if ! ping -w0 -c1 $device -s$size > /dev/null 2>&1; then
>>>>                 break;
>>>>         fi
>>>>         size=$(expr $SIZE + 1)
>>
>>
>> (This line should have referred to $size instead of $SIZE.)
>>
>>>>
>>>>         if [ $size -gt 8192 ]; then
>>>>                 size=1
>>>>         fi
>>>> done
>>>>
>>>> echo "Test ran up to $size"
>>>
>>>
>>> I'd be very much interested in getting such logs :-)
>>>
>>
>> Unfortunately, the driver works with the script above (after fixing the one
>> line) so it's not a "certain size" style scenario.
>>
>> Using iperf I can get traffic to stop flowing within a second of usage so
>> fortunately it's highly reproducible.  One thing I tried this morning was to
>> simply "ignore" the fact the RXCSR register didn't have the expected bit and
>> continue in the driver.  While the throughput was abysmal (and DMA "errors"
>> were reported), at least the driver didn't die.  I could still ping after
>> stopping iperf.  (I don't think this is the appropriate thing to do, but it
>> was just a quick and dirty test.)
>>
>> However, iperf does have the ability to adjust the packet size while still
>> spewing out a high-rate (configurable bandwidth) of packets. Armed with
>> this, I modified the ping test above to utilize iperf instead at various
>> packet sizes (granted, this would get fragmented above the MTU size by the
>> IP stack), leaving it at 1000 packets per second.
>>
>> Doing that as an exercise with the Ethernet dongle, it first keeled over at
>> 1059 byte UDP datagrams (1101 bytes on Ethernet - I don't know how many USB
>> transactions this split into exactly), at 1000 packets per second.  However,
>> it doesn't consistently keel over at the same bytes per datagram.  Another
>> attempt keeled over at 1052 byte UDP datagrams.
>>
>> Upping the ante to 1500 packets per second, and jumping at 16-byte intervals
>> for the size, it lasted from 1000 to 1352 byte size packets and keeled over
>> at 1368 byte sized packets.
>>
>> Some of the configurations of iperf against MUSB in DMA mode causes the ASIX
>> driver (the Ethernet dongle driver) to complain too, even to the point of
>> doing a NULL dereference (I will dig into this dereference). Not seen with
>> the MUSB in PIO mode.
>>
>> Note: Same system/kernel, configured as an Ethernet gadget does not exhibit
>> the issues, although, I'm not convinced it's actually using DMA for this.
>> INTC 93 does not have any activity as a gadget (INTC 92 gets all the
>> traffic).  I can improve the performance (~35% improvement) in PIO mode of
>> an Ethernet gadget by configuring the dynamic FIFO in the MUSB to utilize
>> double buffering, but DMA mode still falls over with a USB ethernet dongle
>> attached with double buffering.  I haven't tried the series of iperf
>> bandwidth tests against double buffering yet.  I also have the idle loops in
>> the system disabled to improve interrupt latency ("nohlt cpuidle.off=1").
>>
>> - Tim
>>
>
> I'm sorry if you are already aware of this information.
> Just wanted to share my experience.
>
> AFAIK, there is a hardware bug with MUSB Host controller.
> See ARM_MPU.KERNEL.39 at
> http://processors.wiki.ti.com/index.php/Sitara_SDK_6.00.00_Release_Notes
> I assume it is common across AM335x and DM3730.

No, it is not.

>
> TI has this pre-mature TX complete interrupt issue on host controller side.

The AM335x bug does not apply to DM3730, because both use different
DMA controller.

Regards,
-Bin.

> Freescale has a similar pre-mature TX interrupt issue on device controller side.
>
> It looks like TI has a patch to work around that issue.
> https://gitorious.org/opensuse/kernel/commit/a655f481d83d6d37bec0a2ddfdd24c30ff8f541f
>
> Maybe, in your case would it be due to the 25us wait loop which is too
> short (I guess)?
>
> To me TI's approach looks complicated.
>
> Freescale's approach looks a lot simpler.
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/usb/gadget/arcotg_udc.c?h=imx_2.6.28&id=f34bd00b7b0295e723158db1f55f28416026ad94
>
>
> -chan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tim Nordell]

Hi Felipe -

On 05/07/15 16:21, Bin Liu wrote:
>> I'm sorry if you are already aware of this information.
>> Just wanted to share my experience.
>>
>> AFAIK, there is a hardware bug with MUSB Host controller.
>> See ARM_MPU.KERNEL.39 at
>> http://processors.wiki.ti.com/index.php/Sitara_SDK_6.00.00_Release_Notes
>> I assume it is common across AM335x and DM3730.
>
> No, it is not.

One thing I just found errata advisory 1.81 for the DM37x indicating 
that "USB OTG DMA May Stall Under Specific Configuration".  Does the 
MUSB driver account for this advisory?  If not, maybe all DMA requests 
for the MUSB port could be queued for the DM37x so that they're 
guaranteed to be one at a time?  If double buffering enabled in the 
FIFO, it should permit fast bursts of data in and out of the MUSB driver.

- Tim


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tim Nordell]

On 05/07/15 16:26, Tim Nordell wrote:
> Hi Felipe -
>
> On 05/07/15 16:21, Bin Liu wrote:
>>> I'm sorry if you are already aware of this information.
>>> Just wanted to share my experience.
>>>
>>> AFAIK, there is a hardware bug with MUSB Host controller.
>>> See ARM_MPU.KERNEL.39 at
>>> http://processors.wiki.ti.com/index.php/Sitara_SDK_6.00.00_Release_Notes
>>> I assume it is common across AM335x and DM3730.
>>
>> No, it is not.
>
> One thing I just found errata advisory 1.81 for the DM37x indicating
> that "USB OTG DMA May Stall Under Specific Configuration".  Does the
> MUSB driver account for this advisory?  If not, maybe all DMA requests
> for the MUSB port could be queued for the DM37x so that they're
> guaranteed to be one at a time?  If double buffering enabled in the
> FIFO, it should permit fast bursts of data in and out of the MUSB driver.
>

Comparing the errata to the code, it appears to be utilizing the 
workarounds listed in the errata.  It looks like commit c0f1f8e38f 
committed the larger burst rates, and it also checks for addresses being 
aligned to 4-bytes wide already.  So that errata probably isn't 
applicable (or at least, the given errata workarounds are definitely in 
the current kernel).

I'm going to try another test which limits the TX or RX activity to PIO 
mode only just to see what happens if I avoid the trigger listed in that 
specific errata (despite the workaround for the errata being present).

- Tim

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tim Nordell]

On 05/07/15 16:41, Tim Nordell wrote:
> I'm going to try another test which limits the TX or RX activity to PIO
> mode only just to see what happens if I avoid the trigger listed in that
> specific errata (despite the workaround for the errata being present).

The system survives this.  I'm not sure if it's just because of 
different usages of the system, or if because there is still an issue 
with TX/RX DMA at the same time despite the advisory for the hardware 
still being followed.

- Tim

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Tim Nordell]

On 05/07/15 17:12, Tim Nordell wrote:
> On 05/07/15 16:41, Tim Nordell wrote:
>> I'm going to try another test which limits the TX or RX activity to PIO
>> mode only just to see what happens if I avoid the trigger listed in that
>> specific errata (despite the workaround for the errata being present).
>
> The system survives this.  I'm not sure if it's just because of
> different usages of the system, or if because there is still an issue
> with TX/RX DMA at the same time despite the advisory for the hardware
> still being followed.
>

I was wrong about the MUSB code implementing the advisory correctly.  I 
misread the advisory as saying 32-bit aligned when in fact it says 
32-byte aligned.  The additional constraints for the DMA advisory on the 
DM37x states that for Tx DMA packets, the data should be 32-byte aligned 
(Rx can go to any alignment still).  It also has payload size 
constraints for both Rx and Tx which aren't checked in the existing MUSB 
driver.

Doing some testing, the USB networking stack isn't sending 32-byte 
aligned buffers so I can't double check to see if this completely fixes 
it or if it's just masking it by adding some additional checks.  For our 
system, we're going to leave the Tx DMAs completely disabled.

At some point a patch should be developed which follows Advisory 1.81 
for the DM3730 part.

- Tim

Re: DM3730 + MUSB host mode + DMA + USB Ethernet dongle = Fail

[Ruslan Bilovol]

On Fri, May 8, 2015 at 9:24 PM, Tim Nordell <tim.nordell-L+YfUVVR8+RBDgjK7y7TUQ@public.gmane.org> wrote:
> On 05/07/15 17:12, Tim Nordell wrote:
>>
>> On 05/07/15 16:41, Tim Nordell wrote:
>>>
>>> I'm going to try another test which limits the TX or RX activity to PIO
>>> mode only just to see what happens if I avoid the trigger listed in that
>>> specific errata (despite the workaround for the errata being present).
>>
>>
>> The system survives this.  I'm not sure if it's just because of
>> different usages of the system, or if because there is still an issue
>> with TX/RX DMA at the same time despite the advisory for the hardware
>> still being followed.
>>
>
> I was wrong about the MUSB code implementing the advisory correctly.  I
> misread the advisory as saying 32-bit aligned when in fact it says 32-byte
> aligned.  The additional constraints for the DMA advisory on the DM37x
> states that for Tx DMA packets, the data should be 32-byte aligned (Rx can
> go to any alignment still).  It also has payload size constraints for both
> Rx and Tx which aren't checked in the existing MUSB driver.
>
> Doing some testing, the USB networking stack isn't sending 32-byte aligned
> buffers so I can't double check to see if this completely fixes it or if
> it's just masking it by adding some additional checks.  For our system,
> we're going to leave the Tx DMAs completely disabled.
>
> At some point a patch should be developed which follows Advisory 1.81 for
> the DM3730 part.

Well, in MUSB driver we already have a code that prepares 4-bytes
aligned buffers
for new DMA engines. Please look at musb_host.c around
musb_{un}map_urb_for_dma()
that do that preparation.
When I was impelenting that few years ago I was aware only about OMAP4
MUSB DMA issue
so feel free to update it for DM37x as well.
Networking layer sends 2-bytes shifted buffers that's why it's failing.
Try to change MUSB_USB_DMA_ALIGN to 32 and see if it helps.

Good luck

Ruslan Bilovol
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html