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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to