From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/3] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver
Date: Fri, 17 Oct 2014 13:02:26 +0530 [thread overview]
Message-ID: <20141017073226.GM1638@intel.com> (raw)
In-Reply-To: <20141017065357.GE2367@ldesroches-Latitude-E6320>
On Fri, Oct 17, 2014 at 08:53:57AM +0200, Ludovic Desroches wrote:
> >
> > > > For memcpy why should we need slave_config. The system memory source and
> > > > destination width could be assumed to relastic values and then burst sizes
> > > > maxed for performance. These values make more sense for periphral where we
> > > > have to match up with the periphral
> > >
> > > I don't tell I need slave_config. We have already talked about this. I don't
> > > see the problem. It is only a comment, a reminder. The only information
> > > I may need, one day, is the direction because we have to set src and dst
> > > interfaces. At the moment, all our products are done in a way nand flash
> > > and DDR are on the same interface so we don't have to care about
> > > direction.
> > > Since we don't have the direction, two solutions:
> > > - remember this limitation for next products, that's why there is this reminder,
> > > - change our nand driver in order to see nand as a peripheral instead of
> > > a memory.
> > I think treating NAND as memory may not be a right model. It should be
> > treated as periphral with incrementing and decrementing address value. That
> > way you should be able to set the right properties for it.
> >
> > The system memory copy is right model for memcpy.
>
> Ok, I'll discuss of it with the atmel nand maintener. Even if there is
> something to improve here, I hope it is not considered as a blocking point
> to get the xdmac driver included into 3.19 because at the moment we have no
> DMA on the SAMA5D4 recently introduced.
That sounds good to me, no this is non blocker here
And yes keeping the comment here is fine to warn folks.
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org,
josh.wu-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH v6 1/3] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver
Date: Fri, 17 Oct 2014 13:02:26 +0530 [thread overview]
Message-ID: <20141017073226.GM1638@intel.com> (raw)
In-Reply-To: <20141017065357.GE2367@ldesroches-Latitude-E6320>
On Fri, Oct 17, 2014 at 08:53:57AM +0200, Ludovic Desroches wrote:
> >
> > > > For memcpy why should we need slave_config. The system memory source and
> > > > destination width could be assumed to relastic values and then burst sizes
> > > > maxed for performance. These values make more sense for periphral where we
> > > > have to match up with the periphral
> > >
> > > I don't tell I need slave_config. We have already talked about this. I don't
> > > see the problem. It is only a comment, a reminder. The only information
> > > I may need, one day, is the direction because we have to set src and dst
> > > interfaces. At the moment, all our products are done in a way nand flash
> > > and DDR are on the same interface so we don't have to care about
> > > direction.
> > > Since we don't have the direction, two solutions:
> > > - remember this limitation for next products, that's why there is this reminder,
> > > - change our nand driver in order to see nand as a peripheral instead of
> > > a memory.
> > I think treating NAND as memory may not be a right model. It should be
> > treated as periphral with incrementing and decrementing address value. That
> > way you should be able to set the right properties for it.
> >
> > The system memory copy is right model for memcpy.
>
> Ok, I'll discuss of it with the atmel nand maintener. Even if there is
> something to improve here, I hope it is not considered as a blocking point
> to get the xdmac driver included into 3.19 because at the moment we have no
> DMA on the SAMA5D4 recently introduced.
That sounds good to me, no this is non blocker here
And yes keeping the comment here is fine to warn folks.
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-10-17 7:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 14:59 [PATCH v6 0/3] new Atmel DMA controller (XDMAC) Ludovic Desroches
2014-10-01 14:59 ` Ludovic Desroches
2014-10-01 14:59 ` [PATCH v6 1/3] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver Ludovic Desroches
2014-10-01 14:59 ` Ludovic Desroches
2014-10-15 13:30 ` Vinod Koul
2014-10-15 13:30 ` Vinod Koul
2014-10-16 14:10 ` Ludovic Desroches
2014-10-16 14:10 ` Ludovic Desroches
2014-10-16 16:12 ` Vinod Koul
2014-10-16 16:12 ` Vinod Koul
2014-10-17 6:53 ` Ludovic Desroches
2014-10-17 6:53 ` Ludovic Desroches
2014-10-17 7:32 ` Vinod Koul [this message]
2014-10-17 7:32 ` Vinod Koul
2014-10-20 15:08 ` Ludovic Desroches
2014-10-20 15:08 ` Ludovic Desroches
2014-10-21 10:50 ` Vinod Koul
2014-10-21 10:50 ` Vinod Koul
2014-10-01 14:59 ` [PATCH v6 2/3] ARM: dts: at_xdmac: add bindings documentation Ludovic Desroches
2014-10-01 14:59 ` Ludovic Desroches
2014-10-15 13:41 ` Vinod Koul
2014-10-15 13:41 ` Vinod Koul
2014-10-16 13:20 ` Ludovic Desroches
2014-10-16 13:20 ` Ludovic Desroches
2014-10-01 14:59 ` [PATCH v6 3/3] MAINTAINERS: add entry for Atmel XDMA driver Ludovic Desroches
2014-10-01 14:59 ` Ludovic Desroches
2014-10-15 12:14 ` [PATCH v6 0/3] new Atmel DMA controller (XDMAC) Ludovic Desroches
2014-10-15 12:14 ` Ludovic Desroches
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=20141017073226.GM1638@intel.com \
--to=vinod.koul@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.