On Thu, 26 Nov 2009, Janusz Krzysztofik wrote:
> 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.
>
> 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?
Just took a quick look at that lcdc.c file; I think we'd better leave
those functions in, since they are so tightly integrated to the code.
Hopefully one of the OMAP730/750/850 people can tease them out, since
they've got a platform to test on. Sound reasonable? Less work for us,
anyway :-)
- Paul
