Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 4月, 2014 1 次提交
  3. 20 3月, 2014 1 次提交
  5. 28 2月, 2014 1 次提交
  7. 17 1月, 2014 1 次提交
  9. 28 6月, 2013 1 次提交
    • G
      lib: Move fonts from drivers/video/console/ to lib/fonts/ · ee89bd6b
      由 Geert Uytterhoeven 提交于 
      Several drivers need font support independent of CONFIG_VT, cfr. commit
9cbce8d7e1dae0744ca4f68d62aa7de18196b6f4, "console/font: Refactor font
support code selection logic").
Hence move the fonts and their support logic from drivers/video/console/ to
its own library directory lib/fonts/.
This also allows to limit processing of drivers/video/console/Makefile to
CONFIG_VT=y again.

[Kevin Hilman <khilman@linaro.org>: Update arch/arm/boot/compressed/Makefile]
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      ee89bd6b
  11. 23 6月, 2013 1 次提交
    • G
      console/font: Refactor font support code selection logic · d1e183c8
      由 Geert Uytterhoeven 提交于 
      The current Makefile rules to build font support are messy and buggy.
Replace them by Kconfig rules:
  - Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
    code,
  - Select CONFIG_FONT_SUPPORT for all drivers that use fonts,
  - Select CONFIG_FONT_8x16 for all drivers that default to the VGA8x16
    font,
  - Drop the bogus console dependency for CONFIG_VIDEO_VIVI,
  - Always process drivers/video/console/Makefile, as some drivers need
    fonts even if CONFIG_VT is not set.

This fixes (if CONFIG_SOLO6X10=y and there are no built-in console
drivers):

drivers/built-in.o: In function `solo_osd_print':
drivers/staging/media/solo6x10/solo6x10-enc.c:144: undefined reference to `.find_font'

This fixes (if CONFIG_VT=n):

drivers/built-in.o: In function `vivi_init':
vivi.c:(.init.text+0x1a3da): undefined reference to `find_font'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com> [original part]
Acked-by: Randy Dunlap <rdunlap@infradead.org> [drivers/video/Makefile]
      d1e183c8
  13. 25 5月, 2013 1 次提交
    • S
      drivers/video: implement a simple framebuffer driver · 26549c8d
      由 Stephen Warren 提交于 
      A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Examples use-cases include:

* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
  devices, and likely many other ARM or embedded systems.  These cannot
  yet be supported using a full graphics driver, since the panel control
  should be provided by the CDF (Common Display Framework), which has been
  stuck in design/review for quite some time.  One could support these
  panels using custom SoC-specific code, but there is a desire to use
  common infra-structure rather than having each SoC vendor invent their
  own code, hence the desire to wait for CDF.

* Hardware for which a full graphics driver is not yet available, and
  the path to obtain one upstream isn't yet clear.  For example, the
  Raspberry Pi.

* Any hardware in early stages of upstreaming, before a full graphics
  driver has been tackled.  This driver can provide a graphical boot
  console (even full X support) much earlier in the upstreaming process,
  thus making new SoC or board support more generally useful earlier.

[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NOlof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26549c8d
  15. 30 4月, 2013 1 次提交
  17. 12 3月, 2013 1 次提交
    • T
      videomode: simplify videomode Kconfig and Makefile · a38884f6
      由 Tomi Valkeinen 提交于 
      This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:

* Videomode helper functions are not something that should be shown in
  the kernel configuration options. The related code should just be
  included if it's needed, i.e. selected by drivers using videomode.

* There's no need to have separate Kconfig options for videomode and
  display_timing. First of all, the amount of code for both is quite
  small. Second, videomode depends on display_timing, and display_timing
  in itself is not really useful, so both would be included in any case.

* CONFIG_VIDEOMODE is a bit vague name, and CONFIG_VIDEOMODE_HELPERS
  describes better what's included.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      a38884f6
  19. 22 2月, 2013 3 次提交
  21. 24 1月, 2013 2 次提交
  23. 10 12月, 2012 1 次提交
  25. 29 9月, 2012 1 次提交
  27. 23 9月, 2012 1 次提交
  29. 30 4月, 2012 3 次提交
  31. 15 2月, 2012 1 次提交
  33. 13 2月, 2012 1 次提交
  35. 12 11月, 2011 1 次提交
  37. 06 9月, 2011 1 次提交
  39. 13 7月, 2011 1 次提交
  41. 23 5月, 2011 1 次提交
  43. 17 3月, 2011 1 次提交
  45. 08 3月, 2011 1 次提交
    • S
      video: Add i.MX23/28 framebuffer driver · f0a523b5
      由 Sascha Hauer 提交于 
      changes since v2:

- use v3 and v4 for specifying the ip version instead of i.MX23/28.
  This is a better namespace when future versions are added.
- rename mach/fb.h to mach/mxsfb.h

changes since v1:
- Add a LCDC_ prefix to the register names.
- use set/clear registers where appropriate
- protect call to mxsfb_disable_controller() in mxsfb_remove()
  with a (host->enabled) as suggested by Lothar Wassmann
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NShawn Guo <shawn.guo@freescale.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-fbdev@vger.kernel.org
      f0a523b5
  47. 16 12月, 2010 1 次提交
    • D
      video: add driver for PXA3xx 2D graphics accelerator · 364dbdf3
      由 Daniel Mack 提交于 
      This adds a driver for the the 2D graphics accelerator found on PXA3xx
processors. Only resource mapping, interrupt handling and a simple ioctl
handler is done by the kernel part, the rest of the logic is implemented
in DirectFB userspace.

Graphic applications greatly benefit for line drawing, blend, and
rectangle and triangle filling operations.

Benchmarks done on a PXA303 using the df_dok benchmarking tool follow,
where the value in square brackets show the CPU usage during that test.

Without accelerator (benchmarking 256x252 on 480x262 RGB16 (16bit)):

  Anti-aliased Text                              3.016 secs (   65.649 KChars/sec) [ 99.6%]
  Fill Rectangle                                 3.021 secs (  175.107 MPixel/sec) [ 98.0%]
  Fill Rectangle (blend)                         3.582 secs (    3.602 MPixel/sec) [ 99.7%]
  Fill Rectangles [10]                           3.177 secs (  182.753 MPixel/sec) [ 98.1%]
  Fill Rectangles [10] (blend)                  18.020 secs (    3.580 MPixel/sec) [ 98.7%]
  Fill Spans                                     3.019 secs (  145.306 MPixel/sec) [ 98.0%]
  Fill Spans (blend)                             3.616 secs (    3.568 MPixel/sec) [ 99.4%]
  Blit                                           3.074 secs (   39.874 MPixel/sec) [ 98.0%]
  Blit 180                                       3.020 secs (   32.042 MPixel/sec) [ 98.0%]
  Blit with format conversion                    3.005 secs (   19.321 MPixel/sec) [ 99.6%]
  Blit from 32bit (blend)                        4.792 secs (    2.692 MPixel/sec) [ 98.7%]

With accelerator:

  Anti-aliased Text                              3.056 secs (*  36.518 KChars/sec) [ 21.3%]
  Fill Rectangle                                 3.015 secs (* 115.543 MPixel/sec) [  8.9%]
  Fill Rectangle (blend)                         3.180 secs (*  20.286 MPixel/sec) [  1.8%]
  Fill Rectangles [10]                           3.251 secs (* 119.062 MPixel/sec) [  1.2%]
  Fill Rectangles [10] (blend)                   6.293 secs (*  20.502 MPixel/sec) [  0.3%]
  Fill Spans                                     3.051 secs (*  97.264 MPixel/sec) [ 35.7%]
  Fill Spans (blend)                             3.377 secs (*  15.282 MPixel/sec) [ 17.8%]
  Blit                                           3.046 secs (*  27.533 MPixel/sec) [  2.6%]
  Blit 180                                       3.098 secs (*  27.070 MPixel/sec) [  2.2%]
  Blit with format conversion                    3.131 secs (*  39.148 MPixel/sec) [  2.8%]
  Blit from 32bit (blend)                        3.346 secs (*  11.568 MPixel/sec) [  0.8%]
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Tested-by: NSven Neumann <s.neumann@raumfeld.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Denis Oliver Kropp <dok@directfb.org>
Cc: Sven Neumann <s.neumann@raumfeld.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      364dbdf3
  49. 26 11月, 2010 2 次提交
  51. 16 11月, 2010 1 次提交
  53. 09 11月, 2010 1 次提交
  55. 05 8月, 2010 1 次提交
  57. 04 8月, 2010 1 次提交
  59. 24 5月, 2010 1 次提交
  61. 14 3月, 2010 1 次提交
  63. 13 3月, 2010 1 次提交
  65. 16 12月, 2009 1 次提交
  67. 09 12月, 2009 1 次提交
    • T
      OMAP: Add VRAM manager · afedec18
      由 Tomi Valkeinen 提交于 
      Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:

- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations

The upcoming DSS2 uses VRAM manager.

VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
      afedec18