Thursday 26 November 2009 03:08:30 Paul Walmsley napisał(a): > On Wed, 25 Nov 2009, Janusz Krzysztofik wrote: > > It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c > > exports several functions that are called unconditionaly from > > drivers/video/omap/lcdc.c AND the latter is linked into the omapfb > > driver based on CONFIG_ARCH_OMAP1=y, linking in the former can't be > > limited to selected OMAP1 subarchs unless at least > > drivers/video/omap/{Kconfig,Makefile}, if not drivers/video/omap/lcdc.c > > itself either, are modified for that as well. Am I missing something? > > > > If not, I can see two options: > > 1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch > > unless CONFIG_FB_OMAP is not set. That can be cleaned up further after > > the drivers/video/omap/* stuff is ever modified. > > 2. Include drivers/video/omap/* modifications into this series. > > > > What do you suggest? > > Let's take option 1 for right now. Maybe one of the htcwizard people > might take that project up after the LCD DMA split is merged. Paul, I probably missed a third option: conditionally replacing declarations of those functions required by lcdc.c with coresponding fake static inline definitions inside an #ifdef block in lcd_dma.h. What do you think? Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html