Koen Kooi had written, on 05/14/2010 05:39 AM, the following:
Op 14 mei 2010, om 12:03 heeft Guruswamy, Senthilvadivu het volgende geschreven:
-----Original Message-----
From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx]
Sent: Friday, May 14, 2010 12:54 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx;
tony@xxxxxxxxxxx; 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:
From: Senthilvadivu Guruswamy <svadivu@xxxxxx>
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?
[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.
But why use bootargs? We introduced FEATURES to detect if the SOC is
capable of having VRFB or not. Use the same dynamically -> the series
helps making VRFB optional - makes sense if there is an SOC without
VRFB. if user space decides to use or not use rotation etc should be
through the normal interface from userspace.. NOT through board
file(unless ofcourse your screen is mounted 90degree rotated by default,
and you turn around and ironically thank the board designer who mounted
the connector wrongly) and definitely not thru bootargs..
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,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
