From: Philippe De Muyter <phdm@macqel.be>
To: Vinod Koul <vinod.koul@intel.com>
Cc: linux-kernel@vger.kernel.org, Greg Ungerer <gerg@snapgear.com>,
Stany MARCEL <smarcel@pactenovation.fr>,
Dan Williams <djbw@fb.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH resent] dma: add the freescale-provided MultiChannel DMA driver
Date: Thu, 21 Feb 2013 09:29:47 +0100 [thread overview]
Message-ID: <20130221082947.GA8799@frolo.macqel> (raw)
In-Reply-To: <20130220063147.GD23302@intel.com>
Hi Vinod,
On Wed, Feb 20, 2013 at 12:01:47PM +0530, Vinod Koul wrote:
> On Mon, Feb 04, 2013 at 06:38:23PM +0100, Philippe De Muyter wrote:
> > This patch adds the (cleaned-up) Freescale-provided MultiChannel DMA
> > driver for ColdFire M54xx and MPC8220 processors.
> >
> > This driver is needed for the ethernet FEC driver of the ColdFire
> > M547x and M548x processors.
> >
> > It is not dmaengine-enabled, but that's not needed for the above FEC driver.
> > I have however installed it in the driver/dma tree as this IP block is not
> > m68k-specific, but freescale-specific, and shared at least between powerpc
> > and coldfire parts (possibly arm-parts as well).
> >
> > The installation in drivers/dma implies a small rule change in
> > drivers/Makefile to enter drivers/dma on CONFIG_DMADEVICES instead
> > of CONFIG_DMAENGINE.
> BIG NAK
Thanks for your answer.
> 1. Please run Checkpath and reread Documentation/CodingStyle, specfically CH4.
> Avoid the CamelCase
I had run checkpatch when I made the patch, but CamelCase was not yet searched
for at that time. I will look at that.
> 2. If you are not using dmaengine APIs then drivers/dma/ is not a place for you.
What would be the place then for a multi-architecture dma driver. Freescale often
reuses the same blocks for its m68k (coldfire), powerpc and arm (iMX) product
lines. A dma driver with many similarities is already under the arch/powerpc
subtree. I would like to avoid that, because it clearly hurts reusability.
> 3. While glancing at the code, I dont see why you cant use dmaengine APIs?
lack of need (the sole current user of this dma driver is a FEC ethernet driver
which uses the current interface), time and expertise. but any help is welcome.
> 4. lastly, am blown off by your own implementation of memcpy, WHY? Kernel is
> smarter than you!
I agree, but don't shoot the messenger. I am not the original author, this is
freescale code. I only ensured that it compiles and works with current kernels,
and suppressed many checkpatch warnings.
Best regards
Philippe
next prev parent reply other threads:[~2013-02-21 8:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 17:38 Philippe De Muyter
2013-02-20 6:31 ` Vinod Koul
2013-02-21 8:29 ` Philippe De Muyter [this message]
2013-02-21 9:52 ` Vinod Koul
2013-02-21 10:37 ` Philippe De Muyter
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=20130221082947.GA8799@frolo.macqel \
--to=phdm@macqel.be \
--cc=djbw@fb.com \
--cc=gerg@snapgear.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smarcel@pactenovation.fr \
--cc=vinod.koul@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®