Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Koen Kooi <koen@dominion.thruhere.net>
Cc: "Guruswamy, Senthilvadivu" <svadivu@ti.com>,
	Tomi Valkeinen <tomi.valkeinen@nokia.com>,
	"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>,
	"Hiremath, Vaibhav" <hvaibhav@ti.com>
Subject: Re: [PATCH v2 0/2] DSS2:Allow FB to build without VRFB
Date: Fri, 14 May 2010 07:17:57 -0500	[thread overview]
Message-ID: <4BED3F75.2040306@ti.com> (raw)
In-Reply-To: <5FC7083E-FFD9-4297-AC5D-522FBCBF11F0@dominion.thruhere.net>

Koen Kooi had written, on 05/14/2010 06:18 AM, the following:
> Op 14 mei 2010, om 12:58 heeft Nishanth Menon het volgende geschreven:
> 
>> 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@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:
>>>>>> From: Senthilvadivu Guruswamy  <svadivu@ti.com>
>>>>>>
>>>>>> 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?
> 
> Because (for some unknown reason) you can't toggle vrfb at runtime. If you realize
 > you need rotation you need to reboot. I guess it's because the memory 
layout for
 >vrfb is completely different, but again, I'm not a kernel hacker :)
Sorry, I am no DSS hacker myself, but looking at mainline 2.6.34-rc6 
kernel drivers/video/omap2/omapfb/omapfb-main.c, as part of late_init, 
omapfb_init gets called -> which causes probe to be called if there is a 
display around, which calls create_framebuffers and based on the 
rotation flag DMA or VRFB bootargs call to allocate goes to 
drivers/video/omap2/vrfb.c, i see request_mem_region and 
release_mem_region from a physical address mapped - so ok.. we loose 
some of our memory map..

Since this entire fuss is about being able to select the type of 
rotation... how about changing vrfb to rotation_type which defaults to 
best possible for the silicon as indicated by FEATURES as I have been 
mentioning so far..


just an idea about what I am talking about, here is an illustration patch:

diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 0af0e9e..b3df400 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -279,8 +279,11 @@ omapfb.test=<y|n>
  	- Draw test pattern to framebuffer whenever framebuffer settings change.
  	  You need to have OMAPFB debug support enabled in kernel config.

-omapfb.vrfb=<y|n>
-	- Use VRFB rotation for all framebuffers.
+omapfb.rotation_type= 0|1|2
+	 - Select rotation type on hardware
+	   0 - Default: Use Optimal rotation style for the silicon
+	   1 - Force use VRFB rotation for all framebuffers if available
+	   2 - Use DSS to rotate all framebuffers

  omapfb.rotate=<angle>
  	- Default rotation applied to all framebuffers.

diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 7514174..52aebae 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -444,6 +444,7 @@ extern u32 omap3_features;
  #define OMAP3_HAS_NEON			BIT(3)
  #define OMAP3_HAS_ISP			BIT(4)
  #define OMAP3_HAS_192MHZ_CLK		BIT(5)
+#define OMAP3_HAS_VRFB			BIT(6)

  #define OMAP3_HAS_FEATURE(feat,flag)			\
  static inline unsigned int omap3_has_ ##feat(void)	\
@@ -457,5 +458,6 @@ OMAP3_HAS_FEATURE(iva, IVA)
  OMAP3_HAS_FEATURE(neon, NEON)
  OMAP3_HAS_FEATURE(isp, ISP)
  OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK)
+OMAP3_HAS_FEATURE(vrfb, VRFB)

  #endif
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..b0cc251 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -33,6 +33,7 @@
  #include <plat/display.h>
  #include <plat/vram.h>
  #include <plat/vrfb.h>
+#include <plat/cpu.h>

  #include "omapfb.h"

@@ -43,7 +44,7 @@

  static char *def_mode;
  static char *def_vram;
-static int def_vrfb;
+static int def_rotate_type;
  static int def_rotate;
  static int def_mirror;

@@ -1872,8 +1873,14 @@ static int omapfb_create_framebuffers(struct 
omapfb2_device *fbdev)
  		ofbi->id = i;

  		/* assign these early, so that fb alloc can use them */
-		ofbi->rotation_type = def_vrfb ? OMAP_DSS_ROT_VRFB :
-			OMAP_DSS_ROT_DMA;
+
+		/* Unless forced to use otherwise, use vrfb */
+		if (omap3_has_vrfb())
+			ofbi->rotation_type = (def_rot_style == 2) ?
+				OMAP_DSS_ROT_DMA : OMAP_DSS_ROT_VRFB;
+		else
+			ofbi->rotation_type = OMAP_DSS_ROT_DMA;
+
  		ofbi->mirror = def_mirror;

  		fbdev->num_fbs++;
@@ -2272,7 +2279,7 @@ static void __exit omapfb_exit(void)
  module_param_named(mode, def_mode, charp, 0);
  module_param_named(vram, def_vram, charp, 0);
  module_param_named(rotate, def_rotate, int, 0);
-module_param_named(vrfb, def_vrfb, bool, 0);
+module_param_named(rotation_type, def_rot_style, int, 0);
  module_param_named(mirror, def_mirror, bool, 0);

  /* late_initcall to let panel/ctrl drivers loaded first.
-- 
Regards,
Nishanth Menon

  reply	other threads:[~2010-05-14 12:18 UTC|newest]

Thread overview: 24+ 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:20 ` [PATCH v2 1/2] DSS2: Allow FB_OMAP2 " Senthilvadivu Guruswamy
2010-05-13 15:20   ` [PATCH v2 2/2] DSS2: make VRFB depends on OMAP2,3 Senthilvadivu Guruswamy
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-13 16:00   ` Koen Kooi
2010-05-13 16:15     ` Nishanth Menon
2010-05-14  9:28       ` Guruswamy, Senthilvadivu
2010-05-14  5:28     ` Guruswamy, Senthilvadivu
2010-05-14  7:23 ` [PATCH v2 0/2] DSS2:Allow FB " Tomi Valkeinen
2010-05-14 10:03   ` Guruswamy, Senthilvadivu
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 [this message]
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-06-03  8:31         ` 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=4BED3F75.2040306@ti.com \
    --to=nm@ti.com \
    --cc=hvaibhav@ti.com \
    --cc=koen@dominion.thruhere.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox