From: Ira Snyder <iws@ovro.caltech.edu>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 00/11] 85xx/86xx dma updates
Date: Fri, 22 May 2009 00:29:16 -0700 [thread overview]
Message-ID: <20090522072916.GA17903@ovro.caltech.edu> (raw)
In-Reply-To: <1242938969.26746.47.camel@localhost.localdomain>
On Thu, May 21, 2009 at 03:49:29PM -0500, Peter Tyser wrote:
> On Thu, 2009-05-21 at 12:37 -0700, Ira Snyder wrote:
> > On Thu, May 21, 2009 at 12:09:58PM -0500, Peter Tyser wrote:
> > > This patch series attempts to clean up the DMA implementation for the
> > > 85xx and 86xx architectures. The changes include:
> > > - consolidate 85xx and 86xx structures and code
> > > - add defines for bitfields
> > > - use proper IO accessors
> > > - add support for arbitrarily large transfer sizes
> > > - rename dma_xfer() to dmacpy() and make dmacpy's prototype similar
> > > to memcpy()
> > >
> > > The patches are based on the mainline "next" branch.
> > >
> > > I've tested the code on MPC8572 and MPC8640-based boards.
> > >
> > > I'm not initimately familar with the 83xx platform, but at a glance
> > > it looked like the fsl_dma driver could be extended to support it
> > > with some ifdeffery.
> > >
> >
> > I've been doing some Linux work with the 83xx DMA controller. The only
> > real differences between the 83xx/85xx controller are the register
> > endianness and snoop bits. The 83xx controller's registers are all
> > little-endian, while the 85xx is all big-endian.
> >
> > Also, there are some snoop bits that need to be enabled on 83xx as well,
> > in the control register as well as in each descriptor if you're running
> > in chaining mode.
> >
> > That's everything that I've noticed that is different. I don't have an
> > 85xx/86xx to test anything with, but I'm happy to run some tests on my
> > mpc8349emds if you want to try adding support for 83xx.
>
> Thanks!
>
> I believe some of the register locations are slightly different too, for
> example the source address on the 85xx is at offset 0x114 while its at
> 0x110 on the 83xx.
>
> I don't think any 83xx boards currently use the 83xx DMA implementation
> in cpu/mpc83xx/cpu.c. Before spending any time on the 83xx, is there
> any good reason to support the 83xx in U-Boot? There would be no users
> of the updated implementation as is.
>
I think there is an option for the mpc8349emds to use the DMA controller
to initialize the RAM for ECC mode. I tried using it, and it was much
slower than using the CPU.
I'll probably end up writing a virtual network driver for U-Boot
eventually. In the Linux version, I've used the DMA controller to handle
transferring data over PCI. It is much faster than the CPU, but I'll
only be transferring a few megabytes from within U-Boot anyway.
In short, having the driver ported to 83xx would make some of my future
development easier, but there aren't any serious in-tree users at the
moment (to the best of my knowledge).
Ira
next prev parent reply other threads:[~2009-05-22 7:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 17:09 [U-Boot] [PATCH 00/11] 85xx/86xx dma updates Peter Tyser
2009-05-21 17:09 ` [U-Boot] [PATCH 01/11] fsl: Create common fsl_dma.h for 85xx and 86xx cpus Peter Tyser
2009-06-12 22:21 ` Kumar Gala
2009-05-21 17:10 ` [U-Boot] [PATCH 02/11] 85xx, 86xx: Sync up DMA code Peter Tyser
2009-06-12 22:21 ` Kumar Gala
2009-05-21 17:10 ` [U-Boot] [PATCH 03/11] 85xx, 86xx: Break out DMA code to a common file Peter Tyser
2009-06-12 14:37 ` Kumar Gala
2009-05-21 17:10 ` [U-Boot] [PATCH 04/11] fsl_dma: Add bitfield definitions for common registers Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 05/11] fsl_dma: Update to use proper I/O accessor functions Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 06/11] fsl_dma: Add support for arbitrarily large transfers Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 07/11] fsl_dma: Fix Channel Start bug in dma_check() Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 08/11] 8xxx: Rename dma_xfer() to dmacpy() Peter Tyser
2009-05-21 17:46 ` Scott Wood
2009-05-21 20:25 ` Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 09/11] fsl_dma: Move dma function prototypes to common header file Peter Tyser
2009-06-12 14:41 ` Kumar Gala
2009-06-22 23:12 ` Peter Tyser
2009-06-30 13:20 ` Kumar Gala
2009-06-30 13:24 ` Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 10/11] 85xx, 86xx: Move dma_init() call to common code Peter Tyser
2009-05-21 17:10 ` [U-Boot] [PATCH 11/11] fsl_dma: Break out common memory initialization function Peter Tyser
2009-05-21 19:37 ` [U-Boot] [PATCH 00/11] 85xx/86xx dma updates Ira Snyder
2009-05-21 20:49 ` Peter Tyser
2009-05-22 7:29 ` Ira Snyder [this message]
2009-05-27 3:40 ` Timur Tabi
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=20090522072916.GA17903@ovro.caltech.edu \
--to=iws@ovro.caltech.edu \
--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 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.