All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matej Kupljen <matej.kupljen@norik.com>
To: geomatsi <geomatsi@gmail.com>
Cc: Jeff Garzik <jgarzik@redhat.com>,
	nicolas.ferre@atmel.com, linux-ide@vger.kernel.org
Subject: Re: DMA support for CF
Date: Wed, 19 Dec 2012 09:32:53 +0100	[thread overview]
Message-ID: <50D17BB5.1010205@norik.com> (raw)
In-Reply-To: <50D0E750.6070406@gmail.com>

Hi,

thank you for you answers, see my comments/questions below.

> In the future could you please consider sending your questions to a
> proper kernel mail list cc-ing authors/maintainers if necessary.

Sorry for that, I'll do that in the future.

> As you noted, driver pata-at91 does not have dma support. This is
> because originally it has been developed for a board based on
> at91sam9260 chip which has no dma engine. More recent at91 chips
> (including at91sam9263) do have dma engines. It should be possible to
> add dma support to pata-at91 driver and use dma transfers for CF.

I started adding this support to pata-at91 and I got to the point
where I can see that DMARQ pin from CF is getting asserted, so
the DMA could start.
Basically, I am not sure, hot to configure the DMA controller.
Should the DMARQ pin be connected to HDMAC perepherial?
What about DMACK pin? There is no DMACK signal from HDMAC.
What Handshaking Interface should I select?
Hardware handshaking, Software handshaking or Peripheral interrupt
handshaking?


> A couple of notes regarding at91sam9263:
>
> 1. DMA driver
> IIRC at91sam9263 chip has a different dma engine than all the other
> chips of at91 family. More recent chips have HDMAC:
> drivers/dma/at_hdmac.c while at91sam9263 has DWDMA: drivers/dma/dw_dmac.c

Yes, I found that after I managed to somehow support this controller
with the at_hdmac.c, since I didn't find any reference to
"Synopsys DesignWare DMA Controller" in the documentation.


> 2. Size of dma transfers
> IIRC there is a problem with dma engine on at91sam9263 chip: it has
> significantly reduced block size for transfers. This leads into a fairly
> small max transfer size in a single block transfer. As a result, it
> might not be practical to use this particular dma engine for CF.

O.K., but still. The DMA support would be beneficial for other AT91
chips, with better DMA controller, wouldn't it?

I know, that my question are basically about configuring DMA controller,
but I haven't found any answers in the documentation (I have checked
also the docs for SAM9R/RL and SAM9G) and have not found my answers.
I tried contacting the authors but didn0t get any answers.
Maybe, posting to this list would help.

Thank you once again and Regards,
Matej Kupljen


      reply	other threads:[~2012-12-19  8:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <50D0264C.1010907@norik.com>
2012-12-18 21:59 ` DMA support for CF geomatsi
2012-12-19  8:32   ` Matej Kupljen [this message]

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=50D17BB5.1010205@norik.com \
    --to=matej.kupljen@norik.com \
    --cc=geomatsi@gmail.com \
    --cc=jgarzik@redhat.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=nicolas.ferre@atmel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.