dma_declare_coherent_memory() again.

dma_declare_coherent_memory() again.

[Guennadi Liakhovetski]

Hi All

AFAIU, dma_declare_coherent_memory() is still present on the following 
platforms:

arch/arm/mach-mx3/mach-pcm037.c
arch/arm/mach-mx3/mach-mx31moboard.c
arch/arm/mach-shmobile/board-ap4evb.c
arch/arm/mach-shmobile/board-mackerel.c (latter 2 via 
	drivers/media/video/sh_mobile_ceu_camera.c)

and there are no pending patches to fix them for 2.6.38, is this right? If 
there are no realistic plans for proper memory reservation on ARM in 
2.6.38, shall I just submit patches to disable those calls on the above 
platforms and hope, that the user manages to get RAM without boot-time 
reservation? Or is a definite failure preferred?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

dma_declare_coherent_memory() again.

[Philippe Rétornaz]

Le lundi, 21 f?vrier 2011 16.37:00, Guennadi Liakhovetski a ?crit :
> Hi All
> 
> AFAIU, dma_declare_coherent_memory() is still present on the following
> platforms:
> 
(...)
> arch/arm/mach-mx3/mach-mx31moboard.c
(...)
> and there are no pending patches to fix them for 2.6.38, is this right? If
> there are no realistic plans for proper memory reservation on ARM in
> 2.6.38, shall I just submit patches to disable those calls on the above
> platforms and hope, that the user manages to get RAM without boot-time
> reservation? Or is a definite failure preferred?

I won't have the time to patch this before 2.6.38, but I plan to rebase my 
tree in the next couple of months. So you can either break it or just remove 
the call but AFAIK in both case it won't work as you cannot allocate a such 
big buffer without special pool.

Thanks,

Philippe

dma_declare_coherent_memory() again.

[Uwe Kleine-König]

On Mon, Feb 21, 2011 at 04:37:00PM +0100, Guennadi Liakhovetski wrote:
> Hi All
> 
> AFAIU, dma_declare_coherent_memory() is still present on the following 
> platforms:
> 
> arch/arm/mach-mx3/mach-pcm037.c
I had a patch for that one[1].  Russell considered it OK if I got him
correctly.  (I think it's OK from a platform's POV, maybe there are some
architecture problems?)

There were a few minor review nits, I can respin if there is general
agreement that the patch is fine.

> arch/arm/mach-mx3/mach-mx31moboard.c
> arch/arm/mach-shmobile/board-ap4evb.c
> arch/arm/mach-shmobile/board-mackerel.c (latter 2 via 
> 	drivers/media/video/sh_mobile_ceu_camera.c)
> 
> and there are no pending patches to fix them for 2.6.38, is this right? If 
> there are no realistic plans for proper memory reservation on ARM in 
> 2.6.38, shall I just submit patches to disable those calls on the above 
> platforms and hope, that the user manages to get RAM without boot-time 
> reservation? Or is a definite failure preferred?

Thanks
Uwe

[1] http://mid.gmane.org/1290505382-16110-1-git-send-email-u.kleine-koenig at pengutronix.de

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |