public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] {Spam?} usage of DMA
Date: Sun, 16 Jan 2011 08:56:58 +0100	[thread overview]
Message-ID: <4D32A4CA.1070109@free.fr> (raw)
In-Reply-To: <201101112251.17510.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

Amicalement,
-- 
Albert.

  reply	other threads:[~2011-01-16  7:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-11 21:51 [U-Boot] {Spam?} usage of DMA Marcel
2011-01-16  7:56 ` Albert ARIBAUD [this message]
2011-01-17 20:48   ` [U-Boot] " Marcel
2011-01-18 13:36     ` Vitaly Kuzmichev
2011-01-18 14:06       ` Vitaly Kuzmichev
2011-01-18 18:12         ` Marcel
2011-01-18 18:11       ` Marcel
2011-01-19  9:04         ` Vitaly Kuzmichev
2011-01-19 21:33           ` Marcel
2011-01-19 22:44           ` Marcel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D32A4CA.1070109@free.fr \
    --to=albert.aribaud@free.fr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox