| Message ID | 1308566761-2850-3-git-send-email-tushar.behera@linaro.org |
|---|---|
| State | Rejected |
| Headers | show |
On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote: > Currently display support for omap2 is selected by default and > it gets built for all the configurations. > > Instead of it being a built-in feature, it's compilation should > depend on the config option CONFIG_FB_OMAP2. No, I don't think so. omap2 directory contains vram, vrfb and omapdss, all of which can be used without omapfb driver. vram and vrfb can be even used without omapdss driver. Is this patch fixing some real problem? Tomi
Hi, On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote: > On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote: >> Currently display support for omap2 is selected by default and >> it gets built for all the configurations. >> >> Instead of it being a built-in feature, it's compilation should >> depend on the config option CONFIG_FB_OMAP2. > > No, I don't think so. omap2 directory contains vram, vrfb and omapdss, > all of which can be used without omapfb driver. vram and vrfb can be > even used without omapdss driver. Even if I build the kernel with i386_defconfig, I get some compiled files within drivers/video/omap2. $ make ARCH=x86 i386_defconfig O=out_dir $ make ARCH=x86 O=out_dir $ ls out_dir/drivers/video/omap2 built-in.o displays modules.builtin modules.order IMHO, drivers/video/omap2/ should not be compiled if the kernel is not built for omap2. > > Is this patch fixing some real problem? This patch does not fix any other problem. > > Tomi > >
On Tue, 2011-06-21 at 10:18 +0530, Tushar Behera wrote: > Hi, > > On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote: > > On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote: > >> Currently display support for omap2 is selected by default and > >> it gets built for all the configurations. > >> > >> Instead of it being a built-in feature, it's compilation should > >> depend on the config option CONFIG_FB_OMAP2. > > > > No, I don't think so. omap2 directory contains vram, vrfb and omapdss, > > all of which can be used without omapfb driver. vram and vrfb can be > > even used without omapdss driver. > Even if I build the kernel with i386_defconfig, I get some compiled > files within drivers/video/omap2. > > $ make ARCH=x86 i386_defconfig O=out_dir > $ make ARCH=x86 O=out_dir > > $ ls out_dir/drivers/video/omap2 > built-in.o displays modules.builtin modules.order > > IMHO, drivers/video/omap2/ should not be compiled if the kernel is not > built for omap2. Ok. Yes, that's a known "problem". We could have a OMAPx check there, but then again, the driver is a driver for the DSS HW, which could, at least in theory, used in other SoCs. I don't think any driver should normally depend on ARCH_something or MACH_something. I think this is more of a "problem" with the build system. The same thing can be seen with, for example, drivers/video/backlight/ and drivers/video/display/ directories. In practice the created files do not affect the kernel in any way, as far as I see. Tomi
diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 8b83129..a19e44e 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -133,7 +133,7 @@ obj-$(CONFIG_FB_SH_MOBILE_HDMI) += sh_mobile_hdmi.o obj-$(CONFIG_FB_SH_MOBILE_MERAM) += sh_mobile_meram.o obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o obj-$(CONFIG_FB_OMAP) += omap/ -obj-y += omap2/ +obj-$(CONFIG_FB_OMAP2) += omap2/ obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o obj-$(CONFIG_FB_CARMINE) += carminefb.o obj-$(CONFIG_FB_MB862XX) += mb862xx/
Currently display support for omap2 is selected by default and it gets built for all the configurations. Instead of it being a built-in feature, it's compilation should depend on the config option CONFIG_FB_OMAP2. Cc: Paul Mundt <lethal@linux-sh.org> Cc: Tomi Valkeinen <tomi.valkeinen@nokia.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Tushar Behera <tushar.behera@linaro.org> --- drivers/video/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)