linux-toradex.git/drivers/video, branch tegra-10.7.1

framebuffer: tegra-fb: add 32bit frame buffer display

2010-06-18T17:20:11+00:00

tegra-fb driver didn't check whether frame buffer is 16bit or 32bit
allocated by bootloader and force to use 16bit display.

Check frame buffer color format to support 32bit ARGB frame buffer.

Bug 685731

Tested on Whistler

Change-Id: Ib545df6227c966d9a26d414687226f4a81bb16bd
Reviewed-on: http://git-master/r/2426
Reviewed-by: Gary King 
Tested-by: Gary King

framebuffer: tegra: fix compiler warning

2010-06-11T23:42:59+00:00

redefine an unsigned long variable as NvU32 to make gcc happy

Change-Id: I4f949c9f812e5834f61899a57a8c4a957b571c62
Reviewed-on: http://git-master/r/2521
Reviewed-by: Gary King 
Tested-by: Gary King

tegra framebuffer - dsi one shot support

2010-06-09T21:44:30+00:00

DSI one shot support requires register access in the tegra framebuffer to
poke the frame trigger bit (with both the trigger bit and the tearing effect
signal are high, a frame of pixels will be sent to the panel). The boot args
must also be expanded to have a "use tearing effect" flag.

tegra RM: Expanded Display clock configuration options.

Added an option for restricted Display clock synchronization with MIPI
PLL - select MIPI PLL as a pixel clock source, but preserve PLL settings.
To specify this option flag NvRmClockConfig_InternalClockForPads should
be set by RM client along with NvRmClockConfig_MipiSync flag (in the
absence of the former flag, MIPI PLL can be re-configured at RM discretion
- current behavior).

Change-Id: I495c2d76656efe8653aa5731c07180c2bfcd2fc0
Reviewed-on: http://git-master/r/2342
Tested-by: Arthur Spence 
Reviewed-by: Gary King

framebuffer: add tegra framebuffer driver

2010-05-20T01:15:32+00:00

Change-Id: I44a22bead5c7e93259fdd5f47e4878d09b1b5a12

mx3fb: some debug and initialisation fixes

2010-02-09T12:51:00+00:00

commit b3cb53721890879d7bde31f5f9eefd4edf41ab64 upstream.

Fix the kernel oops when dev_dbg is called with mx3_fbi->txd == NULL

Fix the late initialisation of mx3fb->backlight_level.  If not, in the
chain of function started by init_fb_chan(), in __blank() call
sdc_set_brightness(mx3fb, mx3fb->backlight_level) that will shut down the
CONTRAST PWM output.

Signed-off-by: Alberto Panizzo 
Acked-by: Guennadi Liakhovetski 
Cc: Sascha Hauer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

imxfb: correct location of callbacks in suspend and resume

2010-02-09T12:51:00+00:00

commit 1ec562035ba64e724652cb12b8a770b3906e9bf5 upstream.

The probe function passes a pointer to a struct fb_info to
platform_set_drvdata(), so don't interpret the return value of
platform_get_drvdata() as a pointer to struct imxfb_info.

The original imxfb_info *fbi backlight_power was NULL but in imxfb_suspend
it was 4 resulting in an oops as imxfb_suspend calls
imxfb_disable_controller(fbi) which in turn has

	if (fbi->backlight_power)
			fbi->backlight_power(0);

Signed-off-by: Uwe Kleine-König  
Acked-by: Sascha Hauer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

revert "drivers/video/s3c-fb.c: fix clock setting for Samsung SoC Framebuffer"

2010-01-22T23:17:59+00:00

commit eb29a5cc0b601c458bae9df2f6c3696d75c2d383 upstream.

Fix divide by zero and broken output.  Commit 600ce1a0fa ("fix clock
setting for Samsung SoC Framebuffer") introduced a mandatory refresh
parameter to the platform data for the S3C framebuffer but did not
introduce any validation code, causing existing platforms (none of which
have refresh set) to divide by zero whenever the framebuffer is
configured, generating warnings and unusable output.

Ben Dooks noted several problems with the patch:

 - The platform data supplies the pixclk directly and should already
   have taken care of the refresh rate.
 - The addition of a window ID parameter doesn't help since only the
   root framebuffer can control the pixclk.
 - pixclk is specified in picoseconds (rather than Hz) as the patch
   assumed.

and suggests reverting the commit so do that.  Without fixing this no
mainline user of the driver will produce output.

[akpm@linux-foundation.org: don't revert the correct bit]
Signed-off-by: Mark Brown 
Cc: InKi Dae 
Cc: Kyungmin Park 
Cc: Krzysztof Helt 
Cc: Marek Szyprowski 
Cc: Ben Dooks 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

matroxfb: fix problems with display stability

2009-12-18T22:05:32+00:00

commit 8c651311a3a08c1e4815de6933e00a760e498dae upstream.

Regression caused in 2.6.23 and then despite repeated requests never fixed
or dealt with (Petr promised to sort it in 2008 but seems to have
forgotten).

Enough is enough - remove the problem line that was added.  If it upsets
someone they've had two years to deal with it and at the very least it'll
rattle their cage and wake them up.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709

Signed-off-by: Alan Cox 
Reported-by: Damon 
Tested-by: Ruud van Melick 
Cc: Petr Vandrovec 
Cc: Pekka Enberg 
Cc: Paul A. Clarke 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

VIDEO: Correct use of request_region/request_mem_region

2009-12-02T23:58:32+00:00

request_region should be used with release_region, not request_mem_region.

Geert Uytterhoeven pointed out that in the case of drivers/video/gbefb.c,
the problem is actually the other way around; request_mem_region should be
used instead of request_region.

The semantic patch that finds/fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@r1@
expression start;
@@

request_region(start,...)

@b1@
expression r1.start;
@@

request_mem_region(start,...)

@depends on !b1@
expression r1.start;
expression E;
@@

- release_mem_region
+ release_region
  (start,E)
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Ralf Baechle

davinci: fb: fix frame buffer driver issues

2009-12-02T00:32:19+00:00

Following issues have been addressed on DA8XX/OMAP-L1XX:

a. Screen misalignment during booting when frame buffer console is
   enabled.

b. Driver was configured always in PSEUDOCOLOR mode.  This patch
   dynamically configures the driver either in PSEUDOCOLOUR or TRUECOLOR
   mode depending on bpp.

c. The RED and BLUE offsets were interchanged resulting in wrong
   bootup logo colour.

This patch has been tested on DA830/OMAP-L137 and DA850/OMAP-L138 EVMs.

Signed-off-by: Sudhakar Rajashekhara 
Cc: Steve Chen 
Cc: Pavel Kiryukhin 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds