From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] video: omap2: Compile omap2 support only when
Date: Tue, 21 Jun 2011 05:24:53 +0000 [thread overview]
Message-ID: <1308633893.1850.11.camel@deskari> (raw)
In-Reply-To: <4E0022B5.9000500@linaro.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
To: Tushar Behera <tushar.behera-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lethal-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org,
Tomi Valkeinen
<tomi.valkeinen-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>,
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/2] video: omap2: Compile omap2 support only when needed
Date: Tue, 21 Jun 2011 08:24:53 +0300 [thread overview]
Message-ID: <1308633893.1850.11.camel@deskari> (raw)
In-Reply-To: <4E0022B5.9000500-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] video: omap2: Compile omap2 support only when needed
Date: Tue, 21 Jun 2011 08:24:53 +0300 [thread overview]
Message-ID: <1308633893.1850.11.camel@deskari> (raw)
In-Reply-To: <4E0022B5.9000500@linaro.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Tushar Behera <tushar.behera@linaro.org>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
linux@arm.linux.org.uk, tony@atomide.com, lethal@linux-sh.org,
linaro-dev@lists.linaro.org, patches@linaro.org,
Tomi Valkeinen <tomi.valkeinen@nokia.com>
Subject: Re: [PATCH 2/2] video: omap2: Compile omap2 support only when needed
Date: Tue, 21 Jun 2011 08:24:53 +0300 [thread overview]
Message-ID: <1308633893.1850.11.camel@deskari> (raw)
In-Reply-To: <4E0022B5.9000500@linaro.org>
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
next prev parent reply other threads:[~2011-06-21 5:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 10:45 [PATCH 0/2] video: Make omap2 support conditional Tushar Behera
2011-06-20 10:57 ` Tushar Behera
2011-06-20 10:45 ` Tushar Behera
2011-06-20 10:46 ` [PATCH 1/2] config: omap2+: force fb and dss support as built-in Tushar Behera
2011-06-20 10:58 ` Tushar Behera
2011-06-20 10:46 ` Tushar Behera
2011-06-20 12:07 ` Premi, Sanjeev
2011-06-20 12:19 ` Premi, Sanjeev
2011-06-20 12:07 ` Premi, Sanjeev
2011-06-20 12:20 ` [PATCH 1/2] config: omap2+: force fb and dss support as Russell King - ARM Linux
2011-06-20 12:20 ` [PATCH 1/2] config: omap2+: force fb and dss support as built-in Russell King - ARM Linux
2011-06-20 12:20 ` Russell King - ARM Linux
2011-06-20 12:24 ` Premi, Sanjeev
2011-06-20 12:36 ` Premi, Sanjeev
2011-06-20 12:24 ` Premi, Sanjeev
2011-06-20 12:07 ` Premi, Sanjeev
2011-06-20 13:04 ` [PATCH 1/2] config: omap2+: force fb and dss support as Tomi Valkeinen
2011-06-20 13:04 ` [PATCH 1/2] config: omap2+: force fb and dss support as built-in Tomi Valkeinen
2011-06-20 13:04 ` Tomi Valkeinen
2011-06-21 5:00 ` Tushar Behera
2011-06-21 5:12 ` Tushar Behera
2011-06-21 5:00 ` Tushar Behera
2011-06-20 10:46 ` [PATCH 2/2] video: omap2: Compile omap2 support only when needed Tushar Behera
2011-06-20 10:58 ` Tushar Behera
2011-06-20 10:46 ` Tushar Behera
2011-06-20 13:06 ` [PATCH 2/2] video: omap2: Compile omap2 support only when Tomi Valkeinen
2011-06-20 13:06 ` [PATCH 2/2] video: omap2: Compile omap2 support only when needed Tomi Valkeinen
2011-06-20 13:06 ` Tomi Valkeinen
2011-06-21 4:48 ` Tushar Behera
2011-06-21 4:49 ` Tushar Behera
2011-06-21 4:48 ` Tushar Behera
2011-06-21 5:24 ` Tomi Valkeinen [this message]
2011-06-21 5:24 ` Tomi Valkeinen
2011-06-21 5:24 ` Tomi Valkeinen
2011-06-21 5:24 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1308633893.1850.11.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.