[U-Boot] [PATCH] mmc: omap_hsmmc: add adma support

[Tom Rini <trini@ti.com>]

On Thu, May 15, 2014 at 07:45:28PM +0530, Balaji T K wrote:
> On Monday 12 May 2014 08:20 PM, Tom Rini wrote:
> >On Mon, May 12, 2014 at 07:12:44PM +0530, Balaji T K wrote:
> >>On Monday 12 May 2014 06:58 PM, Tom Rini wrote:
> >>>On Fri, May 02, 2014 at 07:25:20PM +0530, Balaji T K wrote:
> >>>
> >>>>MMC instance 1 and 2 is capable of ADMA in omap4, omap5.
> >>>>Add support for ADMA and enable ADMA for read/write to
> >>>>improve mmc throughput.
> >>>[snip]
> >>>>@@ -44,12 +45,30 @@
> >>>>  #undef OMAP_HSMMC_USE_GPIO
> >>>>  #endif
> >>>>
> >>>>+#ifdef CONFIG_SPL_BUILD
> >>>>+#undef CONFIG_OMAP_MMC_ADMA
> >>>>+#endif
> >>>
> >>>Why?  Especially since a number of the folks interested in this for
> >>>performance want it for SPL OS mode.  Thanks!
> >>
> >>Because in SoCs like OMAP4/5 mmc1/2 adma doesn't have access to sram.
> >>So can't have descriptor or src / destination buffers (allocated on stack)
> >>given by mmc core on sram.
> >
> >And we can't malloc them?
> >
> 
> For descriptor yes, but for src / dest, I doubt since
> it would be difficult to force the upper (fs, mmc..) layers for controller limitation
> and some ARCH might require the buffers to be cache aligned
> 
> Does malloc return buffers aligned to cache boundary ?

Yes, with memalign which upper layers should also be using for such
cases.  FWIW, the ADMA patches I see in the omapzoom tree I'm fairly
certain do SPL (since that's a focus of theirs) but incorrectly don't
bother ensuring alignment with memalign.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140515/06551b04/attachment.pgp>