All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Senthilvadivu Guruswamy <svadivu@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"tony@atomide.com" <tony@atomide.com>,
	"tomi.valkeinen@nokia.com" <tomi.valkeinen@nokia.com>,
	"Hiremath, Vaibhav" <hvaibhav@ti.com>
Subject: Re: [PATCH v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB
Date: Thu, 13 May 2010 15:30:13 +0000	[thread overview]
Message-ID: <4BEC1B05.3040500@ti.com> (raw)
In-Reply-To: <1273764028-25822-2-git-send-email-svadivu@ti.com>

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@ti.com>
> ---
>  arch/arm/plat-omap/include/plat/vrfb.h |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
> index d8a03ce..3792bde 100644
> --- a/arch/arm/plat-omap/include/plat/vrfb.h
> +++ b/arch/arm/plat-omap/include/plat/vrfb.h
> @@ -35,6 +35,7 @@ struct vrfb {
>  	bool yuv_mode;
>  };
>  
> +#ifdef CONFIG_OMAP2_VRFB
>  extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
>  extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
>  extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
> @@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
>  extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
>  extern void omap_vrfb_restore_context(void);
>  
> +#else
> +static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
> +static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
> +static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
> +		u8 bytespp) {}
> +static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
> +		{ return 0; }
> +static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
> +		{ return 0; }
> +static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> +		u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
> +static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
> +		{ return 0; }
> +static inline void omap_vrfb_restore_context(void) {}
> +#endif
>  #endif /* __VRFB_H */

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

WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com>
To: Senthilvadivu Guruswamy <svadivu@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"tony@atomide.com" <tony@atomide.com>,
	"tomi.valkeinen@nokia.com" <tomi.valkeinen@nokia.com>,
	"Hiremath, Vaibhav" <hvaibhav@ti.com>
Subject: Re: [PATCH v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB
Date: Thu, 13 May 2010 10:30:13 -0500	[thread overview]
Message-ID: <4BEC1B05.3040500@ti.com> (raw)
In-Reply-To: <1273764028-25822-2-git-send-email-svadivu@ti.com>

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@ti.com>
> ---
>  arch/arm/plat-omap/include/plat/vrfb.h |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
> index d8a03ce..3792bde 100644
> --- a/arch/arm/plat-omap/include/plat/vrfb.h
> +++ b/arch/arm/plat-omap/include/plat/vrfb.h
> @@ -35,6 +35,7 @@ struct vrfb {
>  	bool yuv_mode;
>  };
>  
> +#ifdef CONFIG_OMAP2_VRFB
>  extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
>  extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
>  extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
> @@ -47,4 +48,19 @@ extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
>  extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
>  extern void omap_vrfb_restore_context(void);
>  
> +#else
> +static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
> +static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
> +static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
> +		u8 bytespp) {}
> +static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
> +		{ return 0; }
> +static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
> +		{ return 0; }
> +static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> +		u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
> +static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
> +		{ return 0; }
> +static inline void omap_vrfb_restore_context(void) {}
> +#endif
>  #endif /* __VRFB_H */

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

  parent reply	other threads:[~2010-05-13 15:30 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-13 15:20 [PATCH v2 0/2] DSS2:Allow FB to build without VRFB Senthilvadivu Guruswamy
2010-05-13 15:32 ` Senthilvadivu Guruswamy
2010-05-13 15:20 ` [PATCH v2 1/2] DSS2: Allow FB_OMAP2 " Senthilvadivu Guruswamy
2010-05-13 15:32   ` Senthilvadivu Guruswamy
2010-05-13 15:20   ` [PATCH v2 2/2] DSS2: make VRFB depends on OMAP2,3 Senthilvadivu Guruswamy
2010-05-13 15:32     ` Senthilvadivu Guruswamy
2010-05-13 15:30   ` Nishanth Menon [this message]
2010-05-13 15:30     ` [PATCH v2 1/2] DSS2: Allow FB_OMAP2 to build without VRFB Nishanth Menon
2010-05-14  5:24     ` Guruswamy, Senthilvadivu
2010-05-14  5:36       ` Guruswamy, Senthilvadivu
2010-05-13 16:00   ` Koen Kooi
2010-05-13 16:00     ` Koen Kooi
2010-05-13 16:15     ` Nishanth Menon
2010-05-13 16:15       ` Nishanth Menon
2010-05-14  9:28       ` Guruswamy, Senthilvadivu
2010-05-14  9:40         ` Guruswamy, Senthilvadivu
2010-05-14  5:28     ` Guruswamy, Senthilvadivu
2010-05-14  5:40       ` Guruswamy, Senthilvadivu
2010-05-14  7:23 ` [PATCH v2 0/2] DSS2:Allow FB " Tomi Valkeinen
2010-05-14  7:23   ` Tomi Valkeinen
2010-05-14 10:03   ` Guruswamy, Senthilvadivu
2010-05-14 10:15     ` Guruswamy, Senthilvadivu
2010-05-14 10:39     ` Koen Kooi
2010-05-14 10:39       ` Koen Kooi
2010-05-14 10:58       ` Nishanth Menon
2010-05-14 11:18         ` Koen Kooi
2010-05-14 12:17           ` Nishanth Menon
2010-05-14 12:56           ` Tomi Valkeinen
2010-05-14 11:14       ` Guruswamy, Senthilvadivu
2010-05-14 13:01     ` Tomi Valkeinen
2010-05-17  5:49       ` Guruswamy, Senthilvadivu
2010-05-17  5:50         ` Guruswamy, Senthilvadivu
2010-06-03  8:31         ` Guruswamy, Senthilvadivu
2010-06-03  8:43           ` Guruswamy, Senthilvadivu
2010-06-10  5:19 ` [RFC] DSS: Movement of base addr, silicon specific data from driver to platform_device Guruswamy, Senthilvadivu
2010-06-10  5:37   ` Hiremath, Vaibhav
2010-06-16 10:52     ` [RFC] DSS2: Need to make dsi, sdi, rfbi as platform drivers instead of a library in omapdss driver Guruswamy, Senthilvadivu
2010-06-16 11:38       ` 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=4BEC1B05.3040500@ti.com \
    --to=nm@ti.com \
    --cc=hvaibhav@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=svadivu@ti.com \
    --cc=tomi.valkeinen@nokia.com \
    --cc=tony@atomide.com \
    /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.