linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Dan Williams" <dan.j.williams@intel.com>
To: "Wolfgang Denk" <wd@denx.de>
Cc: linux-raid@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [PPC32] ADMA support for PPC 440SPe processors.
Date: Fri, 16 Mar 2007 11:00:30 -0700	[thread overview]
Message-ID: <e9c3a7c20703161100j70a52e5cg25ff3616a5cda8d5@mail.gmail.com> (raw)
In-Reply-To: <20070315232956.37DAB353A6C@atlas.denx.de>

Here are some additional comments/nits:

> +/*
> + *  Init DMA0/1 and XOR engines; allocate memory for DMAx FIFOs; set platform_device
> + * memory resources addresses
> + */
> +static void ppc440spe_configure_raid_devices(void)

Any reason not to move most of this function into spe_adma_probe?  The
"set resource address" section is the only piece that spe_adma_probe
should not handle.

> +++ b/drivers/dma/spe-adma.c
> @@ -0,0 +1,1071 @@
> +/*
> + * Copyright(c) 2006 DENX Engineering. All rights reserved.
> + *
> + * Author: Yuri Tikhonov <yur@emcraft.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; if not, write to the Free Software Foundation, Inc., 59
> + * Temple Place - Suite 330, Boston, MA  02111-1307, USA.
> + *
> + * The full GNU General Public License is included in this distribution in the
> + * file called COPYING.
> + */
> +
> +/*
> + *  This driver supports the asynchrounous DMA copy and RAID engines available
> + * on the AMCC PPC440SPe Processors.
> + *  Based on the Intel Xscale(R) family of I/O Processors (SPE 32x, 33x, 134x)
SPE should be IOP on this line.

../..

> +static inline void
> +spe_adma_slot_cleanup(struct spe_adma_chan *spe_chan)
> +{
> +       spin_lock_bh(&spe_chan->lock);
> +       __spe_adma_slot_cleanup(spe_chan);
> +       spin_unlock_bh(&spe_chan->lock);
> +}
> +
> +static struct spe_adma_chan *spe_adma_chan_array[3];
> +static void spe_adma0_task(unsigned long data)
> +{
> +       __spe_adma_slot_cleanup(spe_adma_chan_array[0]);
> +}
> +
> +static void spe_adma1_task(unsigned long data)
> +{
> +       __spe_adma_slot_cleanup(spe_adma_chan_array[1]);
> +}
> +
> +static void spe_adma2_task(unsigned long data)
> +{
> +       __spe_adma_slot_cleanup(spe_adma_chan_array[2]);
> +}
> +
> +DECLARE_TASKLET(spe_adma0_tasklet, spe_adma0_task, 0);
> +DECLARE_TASKLET(spe_adma1_tasklet, spe_adma1_task, 0);
> +DECLARE_TASKLET(spe_adma2_tasklet, spe_adma2_task, 0);
> +struct tasklet_struct *spe_adma_tasklet[] = {
> +       &spe_adma0_tasklet,
> +       &spe_adma1_tasklet,
> +       &spe_adma2_tasklet,
> +};
> +
This is something I am cleaning up in iop-adma by adding a struct
tasklet * to each channel.    I'll post an incremental diff of my
iop-adma changes so you can see what I have cleaned up since the
2.6.20-rc5 posting.

> +static dma_addr_t spe_adma_map_page(struct dma_chan *chan, struct page *page,
> +                                       unsigned long offset, size_t size,
> +                                       int direction)
> +{
> +       struct spe_adma_chan *spe_chan = to_spe_adma_chan(chan);
> +       return dma_map_page(&spe_chan->device->pdev->dev, page, offset, size,
> +                       direction);
> +}
> +
> +static dma_addr_t spe_adma_map_single(struct dma_chan *chan, void *cpu_addr,
> +                                       size_t size, int direction)
> +{
> +       struct spe_adma_chan *spe_chan = to_spe_adma_chan(chan);
> +       return dma_map_single(&spe_chan->device->pdev->dev, cpu_addr, size,
> +                       direction);
> +}
> +
> +static void spe_adma_unmap_page(struct dma_chan *chan, dma_addr_t handle,
> +                               size_t size, int direction)
> +{
> +       struct spe_adma_chan *spe_chan = to_spe_adma_chan(chan);
> +       dma_unmap_page(&spe_chan->device->pdev->dev, handle, size, direction);
> +}
> +
> +static void spe_adma_unmap_single(struct dma_chan *chan, dma_addr_t handle,
> +                               size_t size, int direction)
> +{
> +       struct spe_adma_chan *spe_chan = to_spe_adma_chan(chan);
> +       dma_unmap_single(&spe_chan->device->pdev->dev, handle, size, direction);
> +}
> +
...these are gone as well in the latest code.

> +static int __devinit spe_adma_probe(struct platform_device *pdev)
../..

> +       printk(KERN_INFO "Intel(R) SPE ADMA Engine found [%d]: "
Intel(R)? :-)

Regards,
Dan

  parent reply	other threads:[~2007-03-16 18:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-15 23:29 [PATCH] [PPC32] ADMA support for PPC 440SPe processors Wolfgang Denk
2007-03-16  5:27 ` Paul Mackerras
2007-03-16  5:55   ` Dan Williams
2007-03-16 10:16     ` Wolfgang Denk
2007-03-16 16:33       ` Dan Williams
2007-03-16  8:29 ` Benjamin Herrenschmidt
2007-03-16 10:23   ` Wolfgang Denk
2007-03-16 12:44   ` Stefan Roese
2007-03-16 16:57   ` Dan Williams
2007-03-16 18:00 ` Dan Williams [this message]
2007-03-17  8:09   ` Stefan Roese
2007-03-17 18:17     ` Dan Williams
2007-03-17 18:43       ` Stefan Roese
2007-03-17 19:09         ` Dan Williams
2007-03-19 16:13           ` Benjamin Herrenschmidt
2007-03-20  3:06             ` Michael Ellerman
2007-03-20  5:39               ` Stefan Roese
2007-03-21 14:10             ` Segher Boessenkool
2007-03-21 19:55               ` Benjamin Herrenschmidt
2007-03-21 20:03                 ` Segher Boessenkool
2007-03-22 11:38                   ` Christoph Hellwig
2007-03-22 12:36                     ` Segher Boessenkool
2007-03-22 13:20                       ` Geert Uytterhoeven
2007-03-22 13:38                         ` Segher Boessenkool
2007-03-17  8:57   ` Yuri Tikhonov

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=e9c3a7c20703161100j70a52e5cg25ff3616a5cda8d5@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=wd@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;
as well as URLs for NNTP newsgroup(s).