[#4099] USB_DMA_INTERRUPT value?

Submitted By: Greg Semeraro

Open Date

2008-05-12 13:44:46 Close Date

2008-06-11 03:19:11

Priority:

Medium Assignee:

Bryan Wu

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

2.6.22.16-ADI-2008R2-pre-svn60

Category:

N/A Board:

N/A

Processor:

BF527 Silicon Revision:

any

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

4.1.2 (ADI svn)

App binary format:

N/A

Summary: USB_DMA_INTERRUPT value?

Details:

Line 599 of mach-bf527/defBF527.h defines the MMR address for USB_DMA_INTERRUPT (which is the basis for all other register accesses within the musb_host driver) given below:

#define USB_DMA_INTERRUPT 0xffc03c00 /* Indicates pending interrupts for the DMA channels */

The problem is that the "ADSP-BF52x Blackfin Processor Hardware Reference" on page 26-66 defines USB_DMA_INTERRUPT to be 0xffc04000.

So, does anyone know which is correct? I'm seeing terrible performance from an 802.11n USB device (less than 20mbps when it should be well over 100mbps) which is why I started looking at this.

Greg Semeraro

Follow-ups

--- Greg Semeraro 2008-05-12 14:49:49

I misspoke....My final application is with a BF527 but the USB does not work on

the available 527s (silicon bug) so I am using boards populated with BF526

processors. The 526s are supposed to have fully functioning USB silicon.

--- Greg Semeraro 2008-05-12 15:22:57

In u-boot-1.1.6/include/asm-blackfin/mach-bf527 USB_DMA_INTERRUPT is defined as

0xffc04000 (line 330).

--- Greg Semeraro 2008-05-12 15:30:30

But all the USB DMA control registers (USB_DMAx_CONTROL, USB_DMAx_ADDRLOW,

USB_DMAx_ADDRHIGH, USB_DMAx_COUNTLOW, USB_DMAx_COUNTHIGH) are defined relative

to 0xffc03c00 in the uboot def file so if USB_DMA_INTERRUPT is correct in uboot

(and I suspect that it is) then all of those definitions are wrong.

Has anyone successfully used a USB device with DMA on the 526 processor?

--- Greg Semeraro 2008-05-13 16:13:54

I have tried all of the register location combinations that I have seen

documented and none of them work. In short, if CONFIG_MUSB_PIO_ONLY is not set

(that is, if DMA is turned on) with the "Inventra Highspeed Dual Role

Controller (TI, ADI, ...) ; Blackfin BF54x, BF525 and BF527 high speed USB

support; Driver Mode (USB Host)" configuration does not work.

Depending on the value used for USB_DMA_INTERRUPT and USB_DMA_BASE the DMA

either halts or fails. I have not been able to get the musb_host driver to

operate in DMA mode at all. PIO works, but painfully slow (18.7mbps with an

802.11n device which can get greater than 135mbps on a PC).

--- Robin Getz 2008-05-13 16:34:16

Greg:

I think this is covered in the todo list:

blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3786

USB/DMA isn't working yet. This is known/understood and is being worked on -

but we need to clean up some other USB functionality issues before we get to the

performance issues.

-Robin

--- Greg Semeraro 2008-05-13 16:58:00

I suppose, but I wasn't really referring to the performance of the DMA, just the

existence of DMA. We were under the assumption that the 548 had a DMA problem

with the silicon which limited USB performance but that the 526 didn't have that

DMA problem. Am I correct to assume that DMA hasn't been characterized on the

526 because that effort hasn't been done yet? I guess what I am asking is if I

should expect USB DMA to work at all now, from what I have observed it doesn't

work.

Thanks,

Greg

--- Bryan Wu 2008-05-18 23:12:02

Currently, the DMA for USB is simply a busy wait method for copy from or copy to

USB FIFO. We do not enable DMA mode 2 for bulk transfer yet.

Because some critical USB bugs was not fixed, we should fix them then add some

performance improvement method, such as DMA mode 2.

Thanks

-Bryan

--- Bryan Wu 2008-05-19 00:23:55

Sorry for the typo, I mead DMA mode 1. There is no DMA mode 2 at all.

Thanks

-Bryan

--- Bryan Wu 2008-06-05 05:46:51

DMA mode 0 and 1 are all enabled in 08R1 branch kernel now.

For 526, I still failed to make the board work on my side.

For this uboot bug, we don't enable USB in uboot yet. But Mike may have some

idea about this.

-Bryan

--- Greg Semeraro 2008-06-05 07:36:21

This is *not* a bug against uboot. I mentioned uboot only in the context of

highlighting the confusion over the correct value of USB_DMA_INTERRUPT. This is

a bug against the musb_host driver in Linux.

Just to be clear, DMA Mode 0 and 1 for USB are working in 08R1? Or are they

now integrated into that release but not yet working? Have they been tested on

the 548?

Greg

--- Greg Semeraro 2008-06-05 07:58:19

Can you please explain how this code (the change referenced as "DMA mode 0

and 1 are all enabled in 08R1 branch kernel" above in

drivers/usb/musb/blackfin.c) in any way supports DMA?

void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src)

{

void __iomem *fifo = hw_ep->fifo;

void __iomem *epio = hw_ep->regs;

prefetch((u8 *)src);

musb_writew(epio, MUSB_FIFOSIZE, len);

DBG(4, "TX ep%d fifo %p count %d buf %p, epio %p\n",

hw_ep->epnum, fifo, len, src, epio);

dump_fifo_data(src, len);

if (unlikely((unsigned long)src & 0x01))

outsw_8(fifo, src, len & 0x01 ? (len >> 1) + 1 : len >> 1);

else

outsw(fifo, src, len & 0x01 ? (len >> 1) + 1 : len >> 1);

}

This is pure PIO for all platforms. The musb_read_fifo() function has been

similarly changed to be only PIO for non-52x platforms. insw() and outsw() are

PIO functions. There are dma_insw() and dma_outsw() that use the MDMA channels

(not the USB DMA controller), I tried changing it to use those weeks ago and

nothing worked.

Greg

--- Mike Frysinger 2008-06-05 10:22:54

u-boot operates in poll mode all the time. it only uses DMA when it has no

choice.

--- Bryan Wu 2008-06-05 11:01:54

Hi Greg,

DMA Mode 0 and 1 is ok in 08R1 only for BF548. Please refer to the code

drivers/usb/musb/musbhsdma.c. After fully testing, it will be integrated into

the 08R1.x release this yeaer. I tested it on BF548.

musb_read_fifo and musb_write_fifo is used for Endpoint 0 transfer and BF527.

Because of some silicon anomaly, BF527 can not fully use the musbhsdma code.

-Bryan

--- Greg Semeraro 2008-06-05 11:03:51

The file that I refer to (drivers/usb/musb/blackfin.c) is linux kernel code, not

uboot code.

Greg

--- Greg Semeraro 2008-06-05 11:24:09

Thanks for clarifying that. Has it been tested on the 526? The 526 does not

have the silicon anomaly that the 527 has.

Greg

--- Bryan Wu 2008-06-05 22:43:02

I am trying to test it on 526. But currently 526 board on does not work on my

side, kernel and uboot will crash. No chance to verify this USB bug before we

fix the crash issues.

-Bryan

--- Bryan Wu 2008-06-11 03:19:10

I tested the 08r1 branch on both bf526-ezkit and bf527-ezkit. it works.

So I'll close this bug tracker.

-Bryan

Files

Changes

Commits

Dependencies

Duplicates

Associations