[U-Boot] usage of DMA

[Marcel <korgull@home.nl>]

> Hi Marcel,
> 
> Le 11/01/2011 22:51, Marcel a ?crit :
> > Hi,
> > 
> > I'm implementing the USB device controller for the SAM9G45 and got to a
> > point where I've got endpoint 0 to work, so basically all descriptors
> > are received by the host.
> > I did however have an issue getting past this and found it's related to
> > the linux driver using DMA for all the other endpoints.
> > 
> > Somehow I managed to get endpoint 3 (status) to work with ether.c and got
> > the device recognised as an ethernet gadget, however endpoints 1 and 2
> > still don't work. This was using DMA.
> > 
> > I'm a little stuck with the DMA part and have some questions about it :
> > 
> > 1) I suppose this can also work work without DMA and it would make the
> > driver a whole lot simpler I guess. Is this prefered in U-boot ?
> > 
> > 2) If I want to use DMA so I can port most things from Linux, how would I
> > deal with functions like
> > dma_sync_single_for_device (doesn't seem to exist)
> > dma_map_single
> > dma_unmap_single
> > 
> > I tried to make it work without DMA and implemented the part that
> > switched off DMA for the controller. I think this code works well.
> > Unfortunately I have no idea how to read data from the endpoints in this
> > case yet. I see that data arrives (I see the out packet arrives and it
> > tries to read) but I probably don't read it correctly.
> > 
> > I guess question 1 is most important. If using DMA is not preferred I
> > will try to make it work without DMA and can forget about question 2.
> 
> As for question 1:
> 
> Generally speaking, simpler code means smaller code, which is, I think,
> the most important factor in U-boot; also, simpler code means less prone
> to bugs, which is also important for a bootloader.
> 
> In your case, I would suggest finding and thouroughly reading the device
> specifications or datasheets. Are they available?
> 
> As for question 2 :
> 
> Taking code from Linux is generally allowed. However, keep in mind that
> depending on what code you're speaking of, this may imply either pulling
> more code than you need or having to modify the code you pull.
> 
> > Best regards,
> > Marcel

Hi Albert,

I have already reduced the code quite far. Basically all dma related stuff is 
gone. 
The device is recognised by the host without errors, but there are some issues 
left as the OUT data doesn't get processed by ether.c.
I'm pulling my hair on this one, but since the data arrives in the OUT fifo and 
I can read it from the controller part I guess all end points are really up 
and running but the interfacing to the gadget system maybe isn't correct.
Perhaps that's related to the driver I'm porting which comes from a 2.6.33 
kernel.

I read quite a lot of the USB device specification for my controller and so far 
think I've done everything right regarding the registers. 
Since the host also does believe things are running correctly and sends data, 
I believe the main issue is in some other part.

A USB trace of a working at91_udc implementation would help, but I have no 
such controller at hand to try it.

Anyway, I'm slowly moving forward on this and probably port again when I have 
it working. 

Regards,
Marcel