[PATCH 27/61] ARM: imx: new Kconfig symbol and feature test macro for?DMA on mx1 and mx2

[Baruch Siach]

Hi Uwe,

On Thu, Jul 01, 2010 at 08:33:11AM +0200, Uwe Kleine-König wrote:
> On Thu, Jul 01, 2010 at 08:24:33AM +0300, Baruch Siach wrote:
> > On Thu, Jul 01, 2010 at 07:03:48AM +0200, Uwe Kleine-König wrote:
> > > On Thu, Jul 01, 2010 at 07:51:56AM +0300, Baruch Siach wrote:
> > > > On Wed, Jun 30, 2010 at 09:17:18AM +0200, Uwe Kleine-König wrote:
> > > > > On Tue, Jun 29, 2010 at 06:04:52AM +0000, Baruch Siach wrote:
> > > > > > Uwe Kleine-König <u.kleine-koenig <at> pengutronix.de> writes:
> > > > > > > This should be used instead of hard coding the corresponding platforms.
> > > > > > > The feature test macro is needed to support different SOCs in a single
> > > > > > > kernel image.  While at it rename dma-mx1-mx2 to dma-v1 as mx25 doesn't
> > > > > > > use it and so the mx2 part is wrong and move the header to
> > > > > > > arch/arm/mach-imx.
> > > > > > > 
> > > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig <at> pengutronix.de>
> > > > > > 
> > > > > > This commit breaks build of the (hopefully) soon to-be-merged mx2_camera driver.
> > > > > > This driver is for both mx25 and mx27. Since dma-mx1-mx2.h is now under the
> > > > > > non-mx25 mach-imx/ directory, mx25 build can't find this header.
> > > > > > 
> > > > > > The solution is either:
> > > > > > 
> > > > > > 1. move mx25 to mach-imx/ as well, or
> > > > > > 
> > > > > > 2. postpone the dma-mx1-mx2.h header move for now, and leave it under plat-mxc/
> > > > > 
> > > > > 3. don't include dma-mx1-mx2.h for mx25 builds.
> > > > > 
> > > > > An mx25 kernel doesn't provide the functions declared in dma-mx1-mx2.h,
> > > > > so I assume it's due to compiler optimizations that you don't get a
> > > > > build failure.
> > > > > 
> > > > > I wouldn't do 1. in the .36 merge window because I want to continue with
> > > > > some cleanups first.  I have no problems with 2 and can do it, but I
> > > > > think 3 is more correct, though it add #ifdefery to your driver, which
> > > > > is bad.  What do you think?
> > > > 
> > > > Doing (3) adds quite a few #ifdefs throughout the driver. For a temporary 
> > > > solution (until mx25 moves to mach-imx/) I think (2) is better. Since this 
> > > > driver should go via your/Shascha's tree, I'll accept your decision.
> > > You call (2) a temporary solution.  What is your long term plan here?  A
> > > unified imx dma API?  If so, please start sending patches :-)
> > 
> > I was under the impression that YOUR long term plan in to move all imx 
> > variants into mach-imx/. That's why I called this solution temporary. I would 
> > very much like to help with the mach-mx25/ -> mach-imx/ move, but I don't 
> > think that the costumer I work for is willing to sponsor this kind of work.
> Yes, my long term plan is to move all imx variants into mach-imx/ but
> the issue I pointed out remains after this is complete.  Probably my
> concern is theoretical only, still I consider it unclean.  BTW my long
> long term todo list contains such a unified dma API.

By "the issue I pointed out" you probably mean:

> An mx25 kernel doesn't provide the functions declared in dma-mx1-mx2.h, so I 
> assume it's due to compiler optimizations that you don't get a build 
> failure.

If so, than if you look into the driver code you'll see that all references to 
mx27 DMA functionality are behind 'if (cpu_is_mx27())' blocks. Currently, 
combined mx27/mx25 build is not possible, and the compiler indeed optimizes 
away the mx27 code. But in the future you should be able to build this driver 
into a single binary running on both mx25 and mx27.

> > I'll go for (3) then, and also s/MX2_VIDEO/VIDEO_MX2_HOSTSUPPORT/ as you 
> > suggested in the other thread.
> Fine.

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -