DWC_OTG Issues
Hello list. I've run into a rather odd problem. I seem to have a problem with full-speed isochronous transfers across a USB2.0 Hub. I believe this was observed before with the general EHCI drivers in Linux. In the latest branch of the kernel, the EHCI driver has some "Enhanced Transaction Translation" scheduling. This would be great for me to use as it seems to directly address the issues I've seen. However, I'm not really sure on how to proceed because the DWC_OTG driver is not GPL code while the EHCI code I'd like to use is. Therefore, I don't believe that I can port the Enhanced Transaction Translation routine into the DWC_OTG driver without violating both the GPL and Synopsis's own driver. Does anyone have a suggestion on how to proceed? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DWC_OTG Issues
Well, thank you for the assurance on the Synopsis drivers not being in conflict. That makes me feel a little better. We're using Linux 2.6.30(.3)-denx. We've worked on this issue a bit before, although at the time you were doing some work for AMCC on just accessing devices across a hub in general. We've been using the driver for a few months now and it is very stable on first-use of the driver, but once we close a full-speed port and try to reopen, that's when we get error concerning not being able to allocate resources and getting -28 errors. I don't have anything precise in front of me at the moment, my test equipment is at the office. But this seems to be the issues that lead to the Enhanced Transaction Translation Scheduling changes in the main-line kernel. I'm mainly being, I believe, overly cautious about not including GPL code in the Synopsis driver simply because I'd rather be overly careful than be exposed to some liability later down the road if Synopsis decides they want to make their driver completely proprietary. While the code is available, I'm not sure if we can include code from GPL sources in the Synopsis drivers without requiring the Synopsis driver to become completely GPL. I am also not a lawyer, but I'd rather be cautious. I did do a comparison on the previous branch we are (2.6.30.3-denx) and the current stable. The only differences in the code were minor enough that I simply merged them into our existing codebase. It didn't really help our issue, but on block transfers and standard connect/disconnect the driver seemed more responsive. I believe this was mainly from Setphan's actions to put some sleeps inside of tight loops that would chew up major CPU time on a non-preemptable kernel(which we had earlier). On Sat, 2009-12-19 at 19:56 +0100, Wolfgang Denk wrote: > Dear Hunter Cobbs, > > In message <1261190115.14590.5.ca...@mobilinux> you wrote: > > Hello list. I've run into a rather odd problem. I seem to have a > > problem with full-speed isochronous transfers across a USB2.0 Hub. I > > believe this was observed before with the general EHCI drivers in Linux. > > Which exazct kernel / driver cversions are you talking about? > > > In the latest branch of the kernel, the EHCI driver has some "Enhanced > > Transaction Translation" scheduling. This would be great for me to use > > as it seems to directly address the issues I've seen. However, I'm not > > really sure on how to proceed because the DWC_OTG driver is not GPL code > > Oops? if that wa the case you could not use (and distribute) this code > in a Linux context at all. > > > while the EHCI code I'd like to use is. Therefore, I don't believe that > > I can port the Enhanced Transaction Translation routine into the DWC_OTG > > driver without violating both the GPL and Synopsis's own driver. > > What makes you think so? > > The Synopsis dwc_otg driver license does not seem to be in conflict > to the GPL, if you ask me (but then, I am not a layer). When we > worked on this, we were assured that the use of this driver source in > the context of GPLed software like the Linux kernel (or U-Boot) was > not considered an issue by Synopsis. > > > Does anyone have a suggestion on how to proceed? > > We have been doing some work on the DWC drivers in the past, fixing a > number of issues. [We never attempted to psuh any of this into > mainline as the Synopsis drivers are - in our opinion - not > avcceptable for mainline but require more or less a rewrite from > scratch. But you can find all this stuff in our linux-2.6-denx repo.] > > I recommend you give a try to our latest stable branch. > > Best regards, > > Wolfgang Denk > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "status" property checks
I think that is definitely a solution. It does centralize the testing for this particular issue. The only thing question I have is if its really better to have the upper level do the check. Shouldn't the driver itself handle the hardware and device node status? On Thu, 2010-01-07 at 15:07 -0800, Hollis Blanchard wrote: > Right now, a number of drivers honor the "status" property on device > nodes (via of_device_is_available() checks), but it's open-coded in each > driver. I'm thinking of "hiding" arbitrary devices from the kernel, and > setting this property seems like the best approach, but at the moment > that would require modifying all OF drivers to check for it. > > Wouldn't the better approach be to have of_platform_device_probe() > itself do the check, and not call the driver's probe() routine if the > device isn't available? > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem dtb file booting Kernel 2.6.32
Hi,
If you're going to attempt to use v1 dts, you might want to try to add
* option) any later version.
*/
/dts-v1/;
/ {
to your DTS file. Also, you'll want to prefix all of your hex addresses
with "0x" so, 20 = 0x20
Hope that helps,
Hunter
On Fri, 2010-01-15 at 09:30 -0500, Andres F Marquez wrote:
> Hello,
>
> I was able to boot Kernel 2.6.26.8 (using our old dts file from
> Kernel 2.6.25). However, I need to upgrade to a newer Kernel because
> I am having serious problems with the ethernet interface under heavy
> load. I am not sure if it could be a scheduling problem or the network
> driver. CPU usage is low but load average is high (more than 4).
>
> The main difference that I could find is that for newer Kernels the
> /arch/ppc was removed. I also read online that dts version changed
> from 0 to 1 somewhere around Kernel 2.6.27 or so.
>
> Following your instruction, I executed in the LTIB command shell:
>
> LTIB> dtc -I dtb -O dts ../mpc8272ads.dtb
>
> I executed that command passing as argument the old working dtb file.
> I got a dts file which I placed in the new Kernel and compiled.
> Unfortunately, I am still getting the same error.
>
> Attached you can find both dts files.
>
> Thank you.
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PPC405EX based irq flooding with USB-OTG and usbserial device
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
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 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 sub
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
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.h2008-05-07 09:13:33.0 -0500 +++ linux-2.6-denx_patched/drivers/usb/gadget/dwc_otg/ppc4xx_dma.h 2009-05-23 08:33:26.17250 -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) #definePPC4xx_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/Makefile2008-05-07 09:13:33.0 -0500 +++ linux-2.6-denx_patched/drivers/usb/gadget/dwc_otg/Makefile2009-05-23 08:38:04.18250 -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 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 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 fo
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
On Sat, May 23, 2009 at 1:14 PM, Wolfgang Denk wrote: > Dear Hunter, > > In message > you wrote: > > > > 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). > > there is a strong reason why we decided not to try to push this > driver upstream: it is not in a state that would have a chance for > being accepted for mainline. The problems you are experiencing are > probably not the only one. Please consider this driver as > unsupported. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "Ada is PL/I trying to be Smalltalk. - Codoso diBlini > Which leads me to another question. Since I should consider this unsupported, is there a better driver out there as my company is already well down the road with our design? Or would you recommend just creating our own driver for the USB-OTG? I'm developing with the Kilauea, and I guess I should ask how unstable is Linux support for this Processor. -- Hunter Cobbs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: U-boot and linux command line parameters
Have you considered using a kernel and initrd? Hunter Cobbs On May 24, 2009, at 4:38 PM, Mirek23 wrote: Dear All, I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 ) for some time. All works fine when the kernel together with initramfs is smaller than 8MB. If it is bigger than the kernel does not boot properly. First of all I would like to know how the address for the linux command line parameters is "transferred" from u-boot to linux for ppc405 (virtex4 chip)? (via some registers or is it a fixed address in the memory ie. 8MB?) Does somebody know what should be changed, in the kernel, in order to move this limitation from 8MB to let say 12MB? I would be grateful for any hint. Thanks in advance. M. -- View this message in context: http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23698384.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 405ex memory size issue
Have you modified the hardware? The default hardware specs says there is only 256MB of ram. Regardless, if you upped the ram amount, you might need to modify u-boot itself to turn on more address lines or you might consider looking at your memory management allocation (slab, slub, etc). Hunter Cobbs On May 25, 2009, at 1:15 AM, konamo wrote: any ideas? konamo wrote: Hi all, we are using AMCC 405ex kilauea eval board as a demo, not use any pci/nand function, the board configuration is below: u-boot 2009.01, linux-2.6.25-rc2, 1GB DDR2 memory(2Gbit * 4, 1 rank), AMCC powerpc 405ex, both 1G and 512MB memory works fine under u-boot, but linux boot fails in 1G memory, if we limit mem=512M, linux could boot over nfs. Could anyone pls help us how to find the root cause? thanks -- View this message in context: http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23701685.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
