Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 1月, 2012 2 次提交
  3. 18 11月, 2011 1 次提交
  5. 01 11月, 2011 1 次提交
  7. 30 9月, 2011 4 次提交
  9. 08 8月, 2011 1 次提交
  11. 13 5月, 2011 2 次提交
  13. 31 3月, 2011 1 次提交
  15. 22 3月, 2011 1 次提交
  17. 11 3月, 2011 2 次提交
    • J
      omapfb: Fix linker error in drivers/video/omap/lcd_2430sdp.c · 08a0a657
      由 Jarkko Nikula 提交于 
      There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
set. This can be triggered on OMAP2 builds when OMAP3 or OMAP4 are not set.

drivers/built-in.o: In function `sdp2430_panel_disable':
drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
drivers/video/omap/lcd_2430sdp.c:124: undefined reference to `twl_i2c_write_u8'
drivers/built-in.o: In function `sdp2430_panel_enable':
drivers/video/omap/lcd_2430sdp.c:110: undefined reference to `twl_i2c_write_u8'
drivers/video/omap/lcd_2430sdp.c:112: undefined reference to `twl_i2c_write_u8'

Fix this by selecting the TWL4030_CORE for MACH_OMAP_2430SDP when building
with CONFIG_FB_OMAP as there is no own Kconfig entry for lcd_2430 and it is
compiled always when both MACH_OMAP_2430SDP and FB_OMAP are set.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      08a0a657
    • J
      OMAP: OMAPFB: Adding help for FB_OMAP_LCD_VGA option · 0897cc21
      由 Janorkar, Mayuresh 提交于 
      CONFIG_FB_OMAP_LCD_VGA option is present in drivers/video/omap
There is no explaination about what this flag does.
Lets add information about it.

FB_OMAP_LCD_VGA flag sets resolution of display to VGA (640 X 480).
The default resolution of 3430 LDP is 320 X 240.
Signed-off-by: NMayuresh Janorkar <mayur@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      0897cc21
  19. 15 12月, 2010 2 次提交
  21. 28 10月, 2010 1 次提交
  23. 23 10月, 2010 1 次提交
  25. 05 7月, 2010 1 次提交
  27. 15 6月, 2010 2 次提交
    • T
      OMAP: OMAPFB: fix rfbi.c compile error · bc092a30
      由 Tomi Valkeinen 提交于 
      The code in rfbi.c tried to get the omapdss platform_device via a static
member defined in dispc.c, leading to a compile error. The same
platform_device is available through rfbi-struct.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      bc092a30
    • J
      OMAPFB: LCDC: change update_mode to DISABLED when going suspend · 256a8042
      由 Janusz Krzysztofik 提交于 
      I was observing the following error messages on my OMAP1 based Amstrad Delta
board when first changing from text to graphics mode or vice versa after the
LCD display had been blanked:
	omapfb omapfb: timeout waiting for FRAME DONE
with a followup error message while unblanking it back:
	omapfb omapfb: resetting (status 0xffffffb2,reset count 1)
As a visible result, image pixels happened to be shifted by a few bits,
giving wrong colors.

Examining the code, I found that this problem occures when an OMAP1 internal
LCD controller is disabled from omap_lcdc_suspend() and then a subsequent
omap_lcdc_setup_plane() calls disable_controller() again. This potentially
error provoking behaviour is triggered by the lcdc.update_mode flag being kept
at OMAP_AUTO_UPDATE, regardless of the controller and panel being suspended.

This patch tries to correct the problem by replacing both omap_lcdc_suspend()
and omap_lcdc_resume() function bodies with single calls to
omap_lcdc_set_update_mode() with a respective OMAP_UPDATE_DISABLE or
OMAP_AUTO_UPDATE argument. As a result, exactly the same lower level
operations are performed, with addition of changing the lcdc.update_mode flag
to a value better suited for the controller state. This prevents any further
calls to disable_controller() from omap_lcdc_setup_plane() while the display
is suspended.

Created against linux-2.6.34-rc7.
Tested on Amstrad Delta.
Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      256a8042
  29. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      由 Tejun Heo 提交于 
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  31. 12 2月, 2010 2 次提交
    • J
      omapfb: lcd_ams_delta: add support for contrast control · e7210327
      由 Janusz Krzysztofik 提交于 
      The patch extends the Amstrad Delta LCD panel driver with optional support for
changing contrast using standard LCD class device API instead of setting it
silently to a default value at panel enable. It also allows for lowering power
consumption by turning off OMAP_PWL_CLK_ENABLE via lcd_ops.set_power callback.

Created and tested against linux-omap for-next,
commit 155a75d9725e66e5ec8a383822957dee52427057.
Signed-off-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      e7210327
    • J
      omapfb: Fix 12-bit display (RGB444 color mode) handling · 3e9ff044
      由 Janusz Krzysztofik 提交于 
      Support for RGB444 (12-bit) pixel format has been introduced into omapfb/lcdc
by Mark Underwood on 2006-05-26 (commit
f74edb6668aad9fc8e81585861b18f996c78a574) in preparation for Amstrad Delta
(E3) videophone LCD display support.

Before the Amstrad Delta LCD patch by Jonathan McDowell was applied (on
2006-08-04, commit 8d22fb2ea004cdb6379b54c1a8fd1546cfe40ed7), omapfb and lcdc
code was changed substantially (commit
e563dc81aa01bd8bbb01bc53975a15c398715f62 dated 2006-06-26) in a way that broke
Mark's 12-bit display support. Than, a patch by Jonathan, that supposed to
correct the problem, was introduced immediatelly (on 2006-08-04, commit
e10a75b49e7a57ae17c28b705153c70eba15a8ef).

As a result, the Amstrad Delta display was working correctly at boot time,
with fbset reporting:

	geometry 480 320 480 320 16
	...
	rgba 4/8,4/4,4/0,0/0

However, after first framebuffer reinitialization, colors were no longer being
displayed correctly and fbset was reporting:

        rgba 5/11,6/5,5/0,0/0

The patch tries to correct the issue by setting plane->color_mode depending on
panel->bpp, not var->bits_per_pixel.

Created and tested on Amstrad Delta against linux-2.6.33-rc3.
Signed-off-by: NJanusz Krzysztofik <jkrzysz@tis.icnet.pl>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      3e9ff044
  33. 09 2月, 2010 1 次提交
  35. 11 1月, 2010 3 次提交
  37. 17 12月, 2009 1 次提交
  39. 14 12月, 2009 2 次提交
  41. 12 12月, 2009 1 次提交
  43. 09 12月, 2009 3 次提交
  45. 23 11月, 2009 1 次提交
  47. 09 11月, 2009 1 次提交
  49. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      由 Tony Lindgren 提交于 
      Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.

This was done with:

#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"

for header in $headers; do
	old="#include <mach\/$header"
	new="#include <plat\/$header"
	for dir in $omap_dirs; do
		find $dir -type f -name \*.[chS] | \
			xargs sed -i "s/$old/$new/"
	done
	find drivers/ -type f -name \*omap*.[chS] | \
		xargs sed -i "s/$old/$new/"
	for file in $other_files; do
		sed -i "s/$old/$new/" $file
	done
done

for header in $(ls $mach_dir_old/*.h); do
	git mv $header $plat_dir_new/
done
Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  51. 20 10月, 2009 1 次提交