[PATCH v4 0/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB

[PATCH v4 0/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB

[Guruswamy Senthilvadivu]

From: Senthilvadivu Guruswamy  <svadivu@ti.com>

Please ignore the previous v3 and consider v4.

The changelog till v4 are:
	- Address Multi-omap build issue
	- Added a check to warn the wrong usage of vrfb 
	in non-vrfb omap devices.
	- The patch subject is as per the naming conventions
	- patch 2/3 now has the changes in omap2/omapfb/Kconfig
	instead of omap2/Kconfig.  The functional effect remains
	the same, and the place of implementation is more appropriate.
	

Thanks,
Senthil

[PATCH v4 1/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB

[Guruswamy Senthilvadivu]

From: Senthilvadivu Guruswamy <svadivu@ti.com>

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 */
-- 
1.5.4.7

[PATCH v4 2/3] OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3

[Guruswamy Senthilvadivu]

config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3.

Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
 drivers/video/omap2/omapfb/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index 43496d6..65149b2 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -3,7 +3,7 @@ menuconfig FB_OMAP2
         depends on FB && OMAP2_DSS
 
 	select OMAP2_VRAM
-	select OMAP2_VRFB
+	select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
         select FB_CFB_FILLRECT
         select FB_CFB_COPYAREA
         select FB_CFB_IMAGEBLIT
-- 
1.5.4.7

[PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Guruswamy Senthilvadivu]

From: Senthilvadivu Guruswamy <svadivu@ti.com>

Force def_vrfb to 0 for non omap2, omap3 devices

Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..0f79db8 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device *pdev)
 		goto err0;
 	}
 
+	/* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
+	*	 available for OMAP2 and OMAP3
+	*/
+	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx())) {
+		def_vrfb = 0;
+		dev_warn(&pdev->dev, "VRFB is not in this device,"
+				"using DMA for rotation\n");
+	}
+
+
 	mutex_init(&fbdev->mtx);
 
 	fbdev->dev = &pdev->dev;
-- 
1.6.3.3

[PATCH v4 0/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB

[Guruswamy Senthilvadivu]

From: Senthilvadivu Guruswamy  <svadivu@ti.com>

Please ignore the previous v3 and consider v4.

The changelog till v4 are:
	- Address Multi-omap build issue
	- Added a check to warn the wrong usage of vrfb 
	in non-vrfb omap devices.
	- The patch subject is as per the naming conventions
	- patch 2/3 now has the changes in omap2/omapfb/Kconfig
	instead of omap2/Kconfig.  The functional effect remains
	the same, and the place of implementation is more appropriate.
	

Thanks,
Senthil

[PATCH v4 1/3] OMAP: DSS2: OMAPFB: Allow FB_OMAP2 to build without VRFB

[Guruswamy Senthilvadivu]

From: Senthilvadivu Guruswamy <svadivu@ti.com>

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 */
-- 
1.5.4.7

[PATCH v4 2/3] OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3

[Guruswamy Senthilvadivu]

config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3.

Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
 drivers/video/omap2/omapfb/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index 43496d6..65149b2 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -3,7 +3,7 @@ menuconfig FB_OMAP2
         depends on FB && OMAP2_DSS
 
 	select OMAP2_VRAM
-	select OMAP2_VRFB
+	select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
         select FB_CFB_FILLRECT
         select FB_CFB_COPYAREA
         select FB_CFB_IMAGEBLIT
-- 
1.5.4.7

[PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Guruswamy Senthilvadivu]

From: Senthilvadivu Guruswamy <svadivu@ti.com>

Force def_vrfb to 0 for non omap2, omap3 devices

Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..0f79db8 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device *pdev)
 		goto err0;
 	}
 
+	/* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
+	*	 available for OMAP2 and OMAP3
+	*/
+	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx())) {
+		def_vrfb = 0;
+		dev_warn(&pdev->dev, "VRFB is not in this device,"
+				"using DMA for rotation\n");
+	}
+
+
 	mutex_init(&fbdev->mtx);
 
 	fbdev->dev = &pdev->dev;
-- 
1.6.3.3

RE: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Guruswamy, Senthilvadivu
> Sent: Thursday, October 07, 2010 2:39 PM
> To: tomi.valkeinen@nokia.com; Hiremath, Vaibhav; linux-
> omap@vger.kernel.org
> Cc: Guruswamy, Senthilvadivu
> Subject: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only
> for omap2,3
> 
> From: Senthilvadivu Guruswamy <svadivu@ti.com>
> 
> Force def_vrfb to 0 for non omap2, omap3 devices
> 

Can we reword the commit description to something like,

"For Non-VRFB devices/platforms (omap2, omap3 family) force it to the DMA based rotation."

> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
> ---
>  drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> b/drivers/video/omap2/omapfb/omapfb-main.c
> index 4b4506d..0f79db8 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device
> *pdev)
>  		goto err0;
>  	}
> 
> +	/* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
> +	*	 available for OMAP2 and OMAP3
> +	*/

This patch may conflict with Archit HAS_FEATURE patch sets. And if I understand correctly it has almost making it to DSS2 tree.

> +	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx())) {
[Hiremath, Vaibhav] Any way we are forcing to DMA based rotation, then why to check for def_vrfb in the above condition. It can be something

if (!cpu_is_omap24xx() && !cpu_is_omap34xx()) {
	def_vrfb = 0;
	...
}

Does it make sense to you?

Thanks,
Vaibhav

> +		def_vrfb = 0;
> +		dev_warn(&pdev->dev, "VRFB is not in this device,"
> +				"using DMA for rotation\n");
> +	}
> +
> +
>  	mutex_init(&fbdev->mtx);
> 
>  	fbdev->dev = &pdev->dev;
> --
> 1.6.3.3

RE: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Taneja, Archit]

Hi,

linux-omap-owner@vger.kernel.org wrote:
>> -----Original Message-----
>> From: Guruswamy, Senthilvadivu
>> Sent: Thursday, October 07, 2010 2:39 PM
>> To: tomi.valkeinen@nokia.com; Hiremath, Vaibhav; linux- omap@vger.kernel.org
>> Cc: Guruswamy, Senthilvadivu
>> Subject: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for
>> omap2,3 
>> 
>> From: Senthilvadivu Guruswamy <svadivu@ti.com>
>> 
>> Force def_vrfb to 0 for non omap2, omap3 devices
>> 
> 
> Can we reword the commit description to something like,
> 
> "For Non-VRFB devices/platforms (omap2, omap3 family) force
> it to the DMA based rotation."
> 
>> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> ---
>>  drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
>>  1 files changed, 10 insertions(+), 0 deletions(-)
>> 
>> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
>> b/drivers/video/omap2/omapfb/omapfb-main.c
>> index 4b4506d..0f79db8 100644
>> --- a/drivers/video/omap2/omapfb/omapfb-main.c
>> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
>> @@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device *pdev)
>>  		goto err0;
>>  	}
>> 
>> +	/* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
>> +	*	 available for OMAP2 and OMAP3
>> +	*/
> 
> This patch may conflict with Archit HAS_FEATURE patch sets.
> And if I understand correctly it has almost making it to DSS2 tree.

The dss features takes care of the stuff within the DSS block,
since vrfb comes outside it shouldn't be able to tell if an omap
family has vrfb or not. Also, the scope of all the dss_feature
functions is within video/omap2/dss/

There was a more generic HAS_FEATURE set being worked on by Nishant and
Tony. That fits better into this.

> 
>> +	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx())) {
> [Hiremath, Vaibhav] Any way we are forcing to DMA based
> rotation, then why to check for def_vrfb in the above
> condition. It can be something
> 
> if (!cpu_is_omap24xx() && !cpu_is_omap34xx()) {
> 	def_vrfb = 0;
> 	...
> }
> 
> Does it make sense to you?
> 
> Thanks,
> Vaibhav
> 
>> +		def_vrfb = 0;
>> +		dev_warn(&pdev->dev, "VRFB is not in this device,"
>> +				"using DMA for rotation\n");
>> +	}
>> +
>> +
>>  	mutex_init(&fbdev->mtx);
>> 
>>  	fbdev->dev = &pdev->dev;
>> --
>> 1.6.3.3

RE: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Guruswamy, Senthilvadivu]

> -----Original Message-----
> From: Hiremath, Vaibhav
> 
> 
> > -----Original Message-----
> > From: Guruswamy, Senthilvadivu
> >
> > From: Senthilvadivu Guruswamy <svadivu@ti.com>
> >
> > Force def_vrfb to 0 for non omap2, omap3 devices
> >
> 
> Can we reword the commit description to something like,
> 
> "For Non-VRFB devices/platforms (omap2, omap3 family) force it to the DMA
> based rotation."
> 
[Senthil] Yes, taken.
> > Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
> > ---
> >  drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
> >  1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> > b/drivers/video/omap2/omapfb/omapfb-main.c
> > index 4b4506d..0f79db8 100644
> > --- a/drivers/video/omap2/omapfb/omapfb-main.c
> > +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> > @@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device
> > *pdev)
> >  		goto err0;
> >  	}
> >
> > +	/* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
> > +	*	 available for OMAP2 and OMAP3
> > +	*/
> 
> This patch may conflict with Archit HAS_FEATURE patch sets. And if I
> understand correctly it has almost making it to DSS2 tree.
[Senthil] As Archit replied in the other thread, HAS_FEATURE of DSS does not cover VRFB, so this would be dependant on the HAS_FEATURE OMAP once it is developed.

> 
> > +	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx())) {
> [Hiremath, Vaibhav] Any way we are forcing to DMA based rotation, then why
> to check for def_vrfb in the above condition. It can be something
> 
> if (!cpu_is_omap24xx() && !cpu_is_omap34xx()) {
> 	def_vrfb = 0;
> 	...
> }
> 
> Does it make sense to you?
[Senthil] The intention of this check is to warn the user if def_vrfb is given as bootarg by chance on wrong omap devices.  That's why the if condition is framed like this.
If this is considered as an ACK then I could generate v5 with the change in the description alone.

> Thanks,
> Vaibhav
> 
> > +		def_vrfb = 0;
> > +		dev_warn(&pdev->dev, "VRFB is not in this device,"
> > +				"using DMA for rotation\n");
> > +	}
> > +
> > +
> >  	mutex_init(&fbdev->mtx);
> >
> >  	fbdev->dev = &pdev->dev;
> > --
> > 1.6.3.3

RE: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Guruswamy, Senthilvadivu
> Sent: Thursday, October 07, 2010 3:38 PM
> To: Hiremath, Vaibhav; tomi.valkeinen@nokia.com; linux-
> omap@vger.kernel.org
> Subject: RE: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb
> only for omap2,3
> 
> 
> 
> > -----Original Message-----
> > From: Hiremath, Vaibhav
> >
> >
> > > -----Original Message-----
> > > From: Guruswamy, Senthilvadivu
> > >
> > > From: Senthilvadivu Guruswamy <svadivu@ti.com>
> > >
> > > Force def_vrfb to 0 for non omap2, omap3 devices
> > >
> >
> > Can we reword the commit description to something like,
> >
> > "For Non-VRFB devices/platforms (omap2, omap3 family) force it to the
> DMA
> > based rotation."
> >
> [Senthil] Yes, taken.
> > > Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
> > > ---
> > >  drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
> > >  1 files changed, 10 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> > > b/drivers/video/omap2/omapfb/omapfb-main.c
> > > index 4b4506d..0f79db8 100644
> > > --- a/drivers/video/omap2/omapfb/omapfb-main.c
> > > +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> > > @@ -2128,6 +2128,16 @@ static int omapfb_probe(struct platform_device
> > > *pdev)
> > >  		goto err0;
> > >  	}
> > >
> > > +	/* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
> > > +	*	 available for OMAP2 and OMAP3
> > > +	*/
> >
> > This patch may conflict with Archit HAS_FEATURE patch sets. And if I
> > understand correctly it has almost making it to DSS2 tree.
> [Senthil] As Archit replied in the other thread, HAS_FEATURE of DSS does
> not cover VRFB, so this would be dependant on the HAS_FEATURE OMAP once it
> is developed.
> 
> >
> > > +	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx())) {
> > [Hiremath, Vaibhav] Any way we are forcing to DMA based rotation, then
> why
> > to check for def_vrfb in the above condition. It can be something
> >
> > if (!cpu_is_omap24xx() && !cpu_is_omap34xx()) {
> > 	def_vrfb = 0;
> > 	...
> > }
> >
> > Does it make sense to you?
> [Senthil] The intention of this check is to warn the user if def_vrfb is
> given as bootarg by chance on wrong omap devices.  That's why the if
> condition is framed like this.

Ok, no issues.

> If this is considered as an ACK then I could generate v5 with the change
> in the description alone.
> 

Yes I think I am ok here, unless Tomi has any comments here.

Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>

Thanks,
Vaibhav


> > Thanks,
> > Vaibhav
> >
> > > +		def_vrfb = 0;
> > > +		dev_warn(&pdev->dev, "VRFB is not in this device,"
> > > +				"using DMA for rotation\n");
> > > +	}
> > > +
> > > +
> > >  	mutex_init(&fbdev->mtx);
> > >
> > >  	fbdev->dev = &pdev->dev;
> > > --
> > > 1.6.3.3

RE: [PATCH v4 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3

[Guruswamy, Senthilvadivu]

> -----Original Message-----
> From: Hiremath, Vaibhav
> 
> > -----Original Message-----
> > From: Guruswamy, Senthilvadivu
> >
> >
> >
> > > -----Original Message-----
> > > From: Hiremath, Vaibhav
> > >
> > >
> > > > -----Original Message-----
> > > > From: Guruswamy, Senthilvadivu
> > > >
> > > > From: Senthilvadivu Guruswamy <svadivu@ti.com>
> > > >
> > > > Force def_vrfb to 0 for non omap2, omap3 devices
> > > >
> > >
> > > Can we reword the commit description to something like,
> > >
> > > "For Non-VRFB devices/platforms (omap2, omap3 family) force it to the
> > DMA
> > > based rotation."
> > >
> > [Senthil] Yes, taken.
> > > > Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
> > > > ---
> > > >  drivers/video/omap2/omapfb/omapfb-main.c |   10 ++++++++++
> > > >  1 files changed, 10 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> > > > b/drivers/video/omap2/omapfb/omapfb-main.c
> > > > index 4b4506d..0f79db8 100644
> > > > --- a/drivers/video/omap2/omapfb/omapfb-main.c
> > > > +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> > > > @@ -2128,6 +2128,16 @@ static int omapfb_probe(struct
> platform_device
> > > > *pdev)
> > > >  		goto err0;
> > > >  	}
> > > >
> > > > +	/* TODO : Replace cpu check with omap_has_vrfb once
> HAS_FEATURE
> > > > +	*	 available for OMAP2 and OMAP3
> > > > +	*/
> > >
> > > This patch may conflict with Archit HAS_FEATURE patch sets. And if I
> > > understand correctly it has almost making it to DSS2 tree.
> > [Senthil] As Archit replied in the other thread, HAS_FEATURE of DSS does
> > not cover VRFB, so this would be dependant on the HAS_FEATURE OMAP once
> it
> > is developed.
> >
> > >
> > > > +	if (def_vrfb && (!cpu_is_omap24xx()) && (!cpu_is_omap34xx()))
> {
> > > [Hiremath, Vaibhav] Any way we are forcing to DMA based rotation, then
> > why
> > > to check for def_vrfb in the above condition. It can be something
> > >
> > > if (!cpu_is_omap24xx() && !cpu_is_omap34xx()) {
> > > 	def_vrfb = 0;
> > > 	...
> > > }
> > >
> > > Does it make sense to you?
> > [Senthil] The intention of this check is to warn the user if def_vrfb is
> > given as bootarg by chance on wrong omap devices.  That's why the if
> > condition is framed like this.
> 
> Ok, no issues.
> 
> > If this is considered as an ACK then I could generate v5 with the change
> > in the description alone.
> >
> 
> Yes I think I am ok here, unless Tomi has any comments here.
> 
> Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
> 
[Senthil]  Thanks, All of Tomi's comments were incorporated in v4 itself.  Will send v5 in a short while.
> Thanks,
> Vaibhav
> 
> 
> > > Thanks,
> > > Vaibhav
> > >
> > > > +		def_vrfb = 0;
> > > > +		dev_warn(&pdev->dev, "VRFB is not in this device,"
> > > > +				"using DMA for rotation\n");
> > > > +	}
> > > > +
> > > > +
> > > >  	mutex_init(&fbdev->mtx);
> > > >
> > > >  	fbdev->dev = &pdev->dev;
> > > > --
> > > > 1.6.3.3