> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, May 13, 2010 9:00 PM
> To: Guruswamy, Senthilvadivu
> Cc: linux-omap@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx;
> tony@xxxxxxxxxxx; tomi.valkeinen@xxxxxxxxx; Hiremath, Vaibhav
> Subject: Re: [PATCH v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB
>
> Senthilvadivu Guruswamy had written, on 05/13/2010 10:20 AM,
> the following:
> > FB_OMAP2 can work without VRFB, but currently does not
> build. Fix this.
> >
> > Signed-off-by: Senthilvadivu Guruswamy <svadivu@xxxxxx>
> >
> > +#ifdef CONFIG_OMAP2_VRFB
> > extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
> > +#else
> > +static inline int omap_vrfb_request_ctx(struct vrfb *vrfb)
> { return 0; }
> > +static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
>
> 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--
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
