Re: Re: [H2200-port] MMC/SD now works on h2200

On Monday 25 April 2005 10:30 am, Pierre TARDY wrote:
> Matthew Reimer wrote:
> > Pierre,
> >
> >Thank you for that information; it's very helpful. I won't pursue PXA DMA
> > from from SRAM.
> >
> >What transfer rates are you able to get?
>
> Well, I stop working on the ipaq a 8 month ago, so I dont remember the
> exact performance. Actually, I can look at my old perf sheet.. I was
> able to read at 1308 kbytes/s, and to write at 833 kB. The SDIO clock
> was at 44MHz and nob was 95 (I dont remember the block size). I send you
> for information the sheet. Note that I had a strange perf reduction when
> writing more than 96 blocks.
> As you can see, you can greatly improve performance if you transfer lot
> of data at time. I dont have seen what kind of requests the filesystem
> module was doiing, but you may increase performance if you program it to
> send always big transfer requests. If it is not possible, you can also
> implement some prefetch mechanism. (When several request on contiguous
> blocks are asked, you can assume that there will be more, and program a
> transfer with more blocks)

That's good to know. I'll keep that in mind.

> >I had another idea about trying to use only PXA DMA. (Caution: I'm about
> > to get in over my head here.) HAMCOP (and probably SAMCOP) are not
> > busmasters, but they can do flow-through DMA. Apparently, the HAMCOP DMA
> > controller has its own DREQ/DACK that connects to its DMA sources (e.g.
> > SD), but no DREQ that connects directly to PXA. Instead, HAMCOP's
> > interrupt controller generates DREQ to PXA when the DMA interrupt is
> > asserted (and the DREQ stuff is properly configured). But DMA interrupts
> > only happen when CURR_TC goes to 0, so if we wanted PXA DMA to get the
> > data directly from SDIDATA, we'd have to set up a small dummy HAMCOP DMA
> > transfer just to get it to trigger an interrupt, which would in turn
> > assert DREQ to the PXA. Then PXA DMA would start copying the data
> > directly from SDIDATA.
> >
> >Here's how I think it is all connected, judging from 03-int.pdf,
> > 04-dma.pdf, and the PXA 255 documentation:
> >
> > DREQ
> >PXA <--------------- HAMCOP interrupt controller
> > ^
> >
> >
> > HAMCOP
> > DMA <----- SD DREQ
> > -----> SD DACK
> >
> >But I don't know if this would work, or whether it would be worth the
> > effort. It definitely is messy.
>
> Hehe, yes, it seems. But it is not a bad idea, it may works.
> If I understand well what you are saying,
> PXA dma1 programed for a big transfer, on HC Interrupt DREQ
> PXA dma2 programmed to write into HAMCOP dma registers to launch lot of
> small transfers, on HC Interrupt DREQ
> HAMCOP DMA3 is programmed on the SDHC DREQ.
> when dma3 is finished, dma1 and dma2 are requested and the data is get
> into SDRAM by dma1 , then dma3 is reloaded by dma2.
>
> I'm sure it is fun.. but I'm not sure it will help for better throughput.
> ;)

Interesting, I hadn't thought of using DMA that way. What I had in mind was
this:

[SH]AMCOP's interrupt controller will generate DREQ when all of the following
are true: DMA interrupt && INTMASK[DMA] && DREQEN. So get the DMA interrupt
asserted, and never clear it; then we can control DREQ to PXA using DREQEN in
the interrupt controller. The way we'd use this is that we'd set up PXA DMA
to copy from SDIDATA, then set the SD registers, and then trigger the PXA DMA
by setting DREQEN.

0. Set INTMSK[DMA] to 1, and get the DMA bit set in the interrupt controller's
SRCPND register. We only need to do this once.

1. Set up PXA DMA to copy from SDIDATA.

2. Set up [SH]AMCOP's SD registers.

3. Set the interrupt controller's DREQEN bit which would then trigger the PXA
DMA to copy directly from SDIDATA.

4. Repeat steps 1-3 for every SD transfer.

I would think this should be faster since we're not copying the data a second
time. Also, we wouldn't be limited by the 32k/16k SRAM on SAMCOP/HAMCOP, so
we could stream larger transfers directly to/from SDRAM.

What do you think?

Matt
Received on Tue Apr 26 2005 - 18:46:00 EDT