From: Senthilvadivu Guruswamy <redacted>
Hi all,
This patch series replaces the patch
"DSS2 Include VRFB into omap2-3build only"
Thanks for the review comments.
The intent of this series is to split the patch into 2 logical
patches and also to incorporate the comments on multi-omap build.
In this series, Kconfig is changed to have
OMAP2_VRFB depend on ARCH_OMAP2 and ARCH_OMAP3.
This change takes care of the multi-omap builds.
This patch would allow successful build of omap_4430sdp_defconfig
when OMAP2_DSS and FB_OMAP2 is enabled from menuconfig.
For verification: Generated the .config on omap3_defconfig with DSS
and FB enabled. Generated .config is same with and without the patch.
List of Changed Files:
arch/arm/plat-omap/include/plat/vrfb.h
drivers/video/omap2/Kconfig
drivers/video/omap2/omapfb/Kconfig
Thanks,
Senthil
Senthilvadivu Guruswamy had written, on 05/13/2010 10:20 AM, the following:
quoted hunk
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy <redacted>
---
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+), 0 deletions(-)
the core of the problem not solved: How do we handle the same kernel
bootup on OMAP3(vrfb) and OMAP4(tiler) if it is compile time decided?
--
Regards,
Nishanth Menon
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy <redacted>
---
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+), 0 deletions(-)
Op 13 mei 2010, om 17:20 heeft Senthilvadivu Guruswamy het volgende geschreven:
quoted hunk
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy <redacted>
---
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+), 0 deletions(-)
Koen Kooi had written, on 05/13/2010 11:00 AM, the following:
Op 13 mei 2010, om 17:20 heeft Senthilvadivu Guruswamy het volgende geschreven:
quoted
FB_OMAP2 can work without VRFB, but currently does not build. Fix this.
Signed-off-by: Senthilvadivu Guruswamy <redacted>
---
arch/arm/plat-omap/include/plat/vrfb.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+), 0 deletions(-)
That is still a compiletime option, not a runtime check. You need something like if(is_omap3()), not #ifdef
having VRFB or tiler is a SOC feature - ideal detection should be in
id.c using the FEATURES framework.
and the actual rotation handling should be handled with function
pointers to use VRFB apis OR use tiler APIs (once it is available) to
runtime use the right rotation/other features functions runtime..
--
Regards,
Nishanth Menon
the core of the problem not solved: How do we handle the same kernel
bootup on OMAP3(vrfb) and OMAP4(tiler) if it is compile time decided?
[Senthil] Compile time decision would come into picture only for
build with omap_4430sdp_defconfig. Kernel is built with
omap3_defconfig will have CONFIG_OMAP2_VRFB=y in it.
In runtime, VRFB APIs will not get called in OMAP4 since these
calls are already within runtime check "if(rotation.type = VRFB)".
This patch is for omap_4430sdp_defconfig to build.
Reason:
VRFB functions make calls to "sms_..." functions in sdrc.c
which is applicable to omap2-3-common and gets compiled only with
ARCH_OMAP2, ARCH_OMAP3. omap_4430sdp_defconfig has only ARCH_OMAP4
defined in it, so sdrc.c is not included in the build leading
to unresolved symbols "sms...". So empty the VRFB functions for
non omap2-3 builds.
Regards,
Senthil
-----Original Message-----
From: Koen Kooi [mailto:koen@dominion.thruhere.net]
Sent: Thursday, May 13, 2010 9:30 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; linux-fbdev@vger.kernel.org;
tony@atomide.com; tomi.valkeinen@nokia.com; Hiremath, Vaibhav
Subject: Re: [PATCH v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB
Op 13 mei 2010, om 17:20 heeft Senthilvadivu Guruswamy het
volgende geschreven:
quoted
FB_OMAP2 can work without VRFB, but currently does not
That is still a compiletime option, not a runtime check. You
need something like if(is_omap3()), not #ifdef
[Senthil] Runtime check for calling VRFB functions are already
taken care in FB driver omapfb-main.c with
"if(rotation.type = VRFB). This compile time option is only for
omap_4430sdp_defconfig to build, where sdrc functions are called
from VRFB.c. Sdrc.c is not included in omap_4430sdp_defconfig build.
From: Tomi Valkeinen <hidden> Date: 2010-05-14 07:23:34
Hi,
On Thu, 2010-05-13 at 17:20 +0200, ext Senthilvadivu Guruswamy wrote:
From: Senthilvadivu Guruswamy <redacted>
Hi all,
This patch series replaces the patch
"DSS2 Include VRFB into omap2-3build only"
Thanks for the review comments.
The intent of this series is to split the patch into 2 logical
patches and also to incorporate the comments on multi-omap build.
In this series, Kconfig is changed to have
OMAP2_VRFB depend on ARCH_OMAP2 and ARCH_OMAP3.
This change takes care of the multi-omap builds.
This patch would allow successful build of omap_4430sdp_defconfig
when OMAP2_DSS and FB_OMAP2 is enabled from menuconfig.
For verification: Generated the .config on omap3_defconfig with DSS
and FB enabled. Generated .config is same with and without the patch.
List of Changed Files:
arch/arm/plat-omap/include/plat/vrfb.h
drivers/video/omap2/Kconfig
drivers/video/omap2/omapfb/Kconfig
The patch set makes VRFB optional. What happens if VRFB is turned off,
and the user uses VRFB for a framebuffer?
Tomi
That is still a compiletime option, not a runtime check.
You need something like if(is_omap3()), not #ifdef
quoted
having VRFB or tiler is a SOC feature - ideal detection should be in
id.c using the FEATURES framework.
and the actual rotation handling should be handled with function
pointers to use VRFB apis OR use tiler APIs (once it is available) to
runtime use the right rotation/other features functions runtime..
[Senthil] Yes, its good to have function pointers to call VRFB/Tiler APIs.
We will consider FnPtrs for VRFB/Tiler when we plugin Tiler APIs in FB driver.
ie "if (rotation.type = VRFB)" could be replaced with FnPtrs later.
Even to introduce FnPtrs for VRFB, compiletime dependency of sdrc.c-vrfb.c
has to be resolved first (this patch address this) in case of omap
platforms without ARCH_OMAP2 and ARCH_OMAP3
(ie omap_4430sdp_defconfig, omap_panda_defconfig).
Currently these omap4_defconfig is not compilable since sdrc.c is included
as $(omap2-3-common) = sdrc.o.
Regards,
Senthil
-----Original Message-----
From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
Sent: Friday, May 14, 2010 12:54 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; linux-fbdev@vger.kernel.org;
tony@atomide.com; Hiremath, Vaibhav
Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB
Hi,
On Thu, 2010-05-13 at 17:20 +0200, ext Senthilvadivu Guruswamy wrote:
quoted
From: Senthilvadivu Guruswamy <redacted>
Hi all,
This patch series replaces the patch
"DSS2 Include VRFB into omap2-3build only"
Thanks for the review comments.
The intent of this series is to split the patch into 2 logical
patches and also to incorporate the comments on multi-omap build.
In this series, Kconfig is changed to have
OMAP2_VRFB depend on ARCH_OMAP2 and ARCH_OMAP3.
This change takes care of the multi-omap builds.
This patch would allow successful build of omap_4430sdp_defconfig
when OMAP2_DSS and FB_OMAP2 is enabled from menuconfig.
For verification: Generated the .config on omap3_defconfig with DSS
and FB enabled. Generated .config is same with and without
the patch.
quoted
List of Changed Files:
arch/arm/plat-omap/include/plat/vrfb.h
drivers/video/omap2/Kconfig
drivers/video/omap2/omapfb/Kconfig
The patch set makes VRFB optional. What happens if VRFB is turned off,
and the user uses VRFB for a framebuffer?
[Senthil] This patch keeps VRFB=y for ARCH_OMAP2 and ARCH_OMAP3.
User would have got an option to turn it OFF if it had appeared in
the menuconfig selections. I did not give that option in menuconfig
explicitly.
ie config OMAP2_VRFB
bool <No name given here>
Suppose on a build the user deliberately gives "CONFIG_OMAP2_VRFB not set",
then VRFB functions are made as empty functions by the compiler.
This is fine as long as the user does not say omapfb.vrfb=1.
But if the user sets omapfb.vrfb=1, then it is a wrong usage of the bootargs
as he has already deliberately changed the defconfig to say "VRFB not set".
The result of his experiment: No bootup on the board as the vaddr of VRFB
is populated nor of the normal RAM buffer.
Tomi
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ¥Šwÿº{.nÇ+‰·¥Š{±ıöİzÿâ�Ø^n‡r¡ö¦zË�ëh™¨èÚ&£ûàz¿äz¹Ş—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿï�êÿ‘êçz_è®æj:+v‰¨ş)ߣøm
Op 14 mei 2010, om 12:03 heeft Guruswamy, Senthilvadivu het volgende geschreven:
quoted
-----Original Message-----
From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
Sent: Friday, May 14, 2010 12:54 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; linux-fbdev@vger.kernel.org;
tony@atomide.com; Hiremath, Vaibhav
Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB
Hi,
On Thu, 2010-05-13 at 17:20 +0200, ext Senthilvadivu Guruswamy wrote:
quoted
From: Senthilvadivu Guruswamy <redacted>
Hi all,
This patch series replaces the patch
"DSS2 Include VRFB into omap2-3build only"
Thanks for the review comments.
The intent of this series is to split the patch into 2 logical
patches and also to incorporate the comments on multi-omap build.
In this series, Kconfig is changed to have
OMAP2_VRFB depend on ARCH_OMAP2 and ARCH_OMAP3.
This change takes care of the multi-omap builds.
This patch would allow successful build of omap_4430sdp_defconfig
when OMAP2_DSS and FB_OMAP2 is enabled from menuconfig.
For verification: Generated the .config on omap3_defconfig with DSS
and FB enabled. Generated .config is same with and without
the patch.
quoted
List of Changed Files:
arch/arm/plat-omap/include/plat/vrfb.h
drivers/video/omap2/Kconfig
drivers/video/omap2/omapfb/Kconfig
The patch set makes VRFB optional. What happens if VRFB is turned off,
and the user uses VRFB for a framebuffer?
[Senthil] This patch keeps VRFB=y for ARCH_OMAP2 and ARCH_OMAP3.
User would have got an option to turn it OFF if it had appeared in
the menuconfig selections. I did not give that option in menuconfig
explicitly.
ie config OMAP2_VRFB
bool <No name given here>
Suppose on a build the user deliberately gives "CONFIG_OMAP2_VRFB not set",
then VRFB functions are made as empty functions by the compiler.
This is fine as long as the user does not say omapfb.vrfb=1.
But if the user sets omapfb.vrfb=1, then it is a wrong usage of the bootargs
as he has already deliberately changed the defconfig to say "VRFB not set".
The result of his experiment: No bootup on the board as the vaddr of VRFB
is populated nor of the normal RAM buffer.
And that is unacceptable when working with customers (or users in the open source world). Instead of the kernel hacker spending an hour or 2 on a proper solution we now need to waste a whole lot more time supporting customers who pass vrfb in bootargs without knowing that it's turned off in the kernel.
I suspect my viewpoint is skewed since I work in the field with customers, instead of in the factory doing kernel work (to use TI parlance).
regards,
Koen