OK, here are the patches... one for ppc4xx_dma.h and one for the Makefile
----------- ppc4xx_dma.h snip -------- --- linux-2.6-denx/drivers/usb/gadget/dwc_otg/ppc4xx_dma.h 2008-05-07 09:13:33.000000000 -0500 +++ linux-2.6-denx_patched/drivers/usb/gadget/dwc_otg/ppc4xx_dma.h 2009-05-23 08:33:26.172500000 -0500 @@ -84,8 +84,13 @@ * DMA Channel Control Registers */ -#if defined(CONFIG_44x) || defined(CONFIG_405EX) || defined(CONFIG_405EXr) +/* The PPC44x series has a 64Bit DMA */ +#if defined(CONFIG_44x) #define PPC4xx_DMA_64BIT +#endif + +/* The PPC44x and PPC405EX/r have a reserved bit in DMA control register*/ +#if defined(CONFIG_44x) || defined(CONFIG_405EX) || defined(CONFIG_405EXr) #define DMA_CR_OFFSET 1 #else #define DMA_CR_OFFSET 0 ------------- end snip ----------- --------- Makefile snip ---------- --- linux-2.6-denx/drivers/usb/gadget/dwc_otg/Makefile 2008-05-07 09:13:33.000000000 -0500 +++ linux-2.6-denx_patched/drivers/usb/gadget/dwc_otg/Makefile 2009-05-23 08:38:04.182500000 -0500 @@ -22,7 +22,7 @@ #KBUILD_CPPFLAGS += -DOTG_EXT_CHG_PUMP # PLB DMA mode -KBUILD_CPPFLAGS += -Dlinux -DDWC_SLAVE -DOTG_PLB_DMA -DOTG_PLB_DMA_TASKLET #-DDWC_DEVICE_ONLY # -DDWC_HS_ELECT_TST -DDWC_SLAVE -DDWC_HOST_ONLY +KBUILD_CPPFLAGS += -Dlinux -DOTG_PLB_DMA -DOTG_PLB_DMA_TASKLET endif ifeq ($(CONFIG_460EX),y) ------------- end snip ----------- On Sat, May 23, 2009 at 7:44 AM, Hunter Cobbs <hunter.co...@gmail.com>wrote: > Egads! Forgot to respond to the list! > > My git checkout failed last night, so I'm downloading the resource cd, but > I can tell you what I did before I get the actual patch done, and you can > tell me if my logic is sound. > > First thing I thought when I saw this is WHY use IRQ based methods to > access a USB controller with internal DMA transfers? I tried in vain to > enable this with the driver module parameters(which I dug up how to specify > module parameters to built-in drivers from an old 2.2-series kernel > discussion). So, then I put on my boots and started slogging throught the > driver. > > Getting frustrated with that line of execution, I turned up the verbosity > on the kernel compile and noticed a warning in the dwc_otg compilation. > Specifically that a left and right shift go out of bounds of the variables > used. The only place this occurs is in a section of code that is wrapped > with DMA_64BIT. Which made absolutely no sense because the DMA controller > on the 405EX is only 32 bits wide. On tracking this define down, I come to > find out that someone made the assumption that the 44x and the 405EX/r all > have the same DMA controller. Which is incorrect, they both have the same > control register definitions(the offset of 1 due to the MSBit being reserved > and the register being in Big Endian mode); however, the 44x is 64bits and > the 405 is 32bits. So, I broke the DMA control down into two areas, > data-width and control register offsets. > > When this still didn't fix the problem, I found yet another section that > can force you to operate in slave(irq) mode only wrapped in yet another > define. When I search out that define (DWC_SLAVE I believe), I find it in > the dwc_otg Makefile. > > Correcting both of these has enabled full DMA access to the USB, and I'm > doing much better with my sierra wireless dev kit. > > On Sat, May 23, 2009 at 7:11 AM, Chuck Meade <chuckme...@mindspring.com>wrote: > >> Hunter Cobbs wrote: >> > Hello everyone, >> > >> > This is my first post to the PPC dev list as my company has just started >> > developing a new project based on Linux. The good news is, this post is >> > not debug-related as much as it is an introduction and query while I >> > download the latest DENX kernel(only place I know that has the DWC_OTG >> > driver). >> > >> > I've been working with a Kilauea dev board and have had lots of trouble >> > when I plug in a sierra-wireless modem dev kit on the USB. It goes fine >> > untill I actually try to communicate(pppd or minicom) with the little >> > bugger and then my IRQs go through the roof. And they only calm back >> > down after I shut down my communicaiton channel. >> > >> > I've solved this issue with our board, and was wondering if it has since >> > been fixed (I'm running 2.6.25-DENX). I don't want to waste the board's >> > time with a patch that is no longer necesarry. >> > >> > -- >> > Hunter Cobbs >> >> Hello Hunter, >> >> It would absolutely *not* be a waste of anyone's time. I for one would >> like >> to see how you solved this. I am dealing with the same problem, with the >> same >> setup. >> >> The underlying cause for this problem is the PPC405EX CPU's erratum >> USBO_9. >> The USB 2.0 PING protocol is supposed to handle a PING transaction in >> the hardware -- note that in USB 2.0, a PING is the method used by the >> sender to >> determine if it can send. If I remember correctly, erratum USBO_9 is >> caused when >> a NAK response from the PING transaction is handled not in hardware, but >> instead >> as an interrupt in software, and that NAK leads to a lot of processing. >> In the >> 2.6.25 Denx Linux tree that I used, that processing ends up trying to >> restart the >> channel, restart the send, which leads to yet another PING/NAK sequence, >> yet another >> interrupt... >> >> The end result is that you get over 100,000 interrupts (with significant >> interrupt >> handling logic) per second, and the target can't do anything else. I was >> able >> to get this interrupt count by looking at /proc/interrupts, then causing >> this problem >> for 20 seconds, then pulling out the USB modem physically (mine is on a >> Express card) >> to stop the interrupt storm, then checking /proc/interrupts again. >> Averaged over >> 100,000 ints/sec. >> >> In contact with AMCC, they told us they are not respinning the CPU (at >> least not >> at this time) to fix this erratum. >> >> I have tried to solve the problem as suggested by the erratum, by not >> allowing the >> NAK interrupt handling to *directly* cause a retry of the send, but rather >> to wait >> until the next SOF interrupt (start of microframe, which happens 8,000 >> times per sec) >> to restart it. "Breaking the chain" like this does allow the board to >> proceed, but >> I think it is suboptimal, or at least unfortunate. >> >> One painful side effect of this workaround is that you cannot disable the >> 8,000 SOF >> interrupts/second, or at least some of them, since they are being used now >> for another >> purpose -- recovery from the erratum. >> >> The 8000 SOF ints being handled per second do cause a measurable drain on >> the >> CPU. In some cursory testing we see a 10% slowdown of certain >> transactions in >> lmbench. >> >> So please send me your patch for the dwc_otg driver. I am very interested >> in what >> you did, and if it perhaps is a better solution for the problem we both >> are seeing >> than what I implemented. >> >> Thanks in advance, >> Chuck >> >> > > > -- > Hunter Cobbs > -- Hunter Cobbs
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
