Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 6月, 2009 1 次提交
  3. 07 4月, 2009 1 次提交
  5. 01 4月, 2009 1 次提交
    • K
      fbdev: remove cyblafb driver · ddb53d48
      由 Krzysztof Helt 提交于 
      A tridentfb driver has all the functionality of the cyblafb driver without
the bugs of the latter.

Changes to the tridentfb driver:

- FBINFO_READS_FAST added to the tridentfb.  The cyblafb used a blitter
  for scrolling which is faster than color expansion on Cyberblade
  chipsets.  The blitter is slower on a discrete Blade3D core.  Use the
  blitter for scrolling in the tridentfb only for integrated Blade3D
  cores.  Now, scrolling speed is about equal for the tridentfb and the
  cyblafb.

- a copyright notice addition is done on request of Jani Monoses (the
  first author of the tridentfb).

Tested on AGP Blade3D card and PCChips
M787CLR motherboard: VIA C3 cpu +
VT8601 north  bridge (aka Cyberblade/i1).
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: "Jani Monoses" <jani@ubuntu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ddb53d48
  7. 29 12月, 2008 2 次提交
    • E
      [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices · 198fc108
      由 Eric Miao 提交于 
      PXA27x and later processors support overlay1 and overlay2 on-top of the
base framebuffer (although under-neath the base is also possible). They
support palette and no-palette RGB formats, as well as YUV formats (only
available on overlay2). These overlays have dedicated DMA channels and
behave in a similar way as a framebuffer.

This heavily simplified and re-structured work is based on the original
pxafb_overlay.c (which is pending for mainline merge for a long time).

The major problems with this pxafb_overlay.c are (if you are interested
in the history):

  1. heavily redundant (the control logics for overlay1 and overlay2 are
     actually identical except for some small operations,  which are now
     abstracted into a 'pxafb_layer_ops' structure)

  2. a lot of useless and un-tested code (two workarounds which are now
     fixed on mature silicons)

  3. cursorfb is actually useless, hardware cursor should not be used
     this way, and the code was actually un-tested for a long time.

The code in this patch should be self-explanatory, I tried to add minimum
comments. As said, this is basically simplified, there are several things
still on the pending list:

  1. palette mode is un-supported and un-tested (although re-using the
     palette code of the base framebuffer is actually very easy now with
     previous clean-up patches)

  2. fb_pan_display for overlay(s) is un-supported

  3. the base framebuffer can actually be abstracted by 'pxafb_layer' as
     well, which will help further re-use of the code and keep a better
     and consistent structure. (This is the reason I named it 'pxafb_layer'
     instead of 'pxafb_overlay' or something alike)

See Documentation/fb/pxafb.txt for additional usage information.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      198fc108
    • E
      [ARM] pxafb: allow video memory size to be configurable · 77e19675
      由 Eric Miao 提交于 
      The amount of video memory size is decided according to the following
order:

1. <xres> x <yres> x <bits_per_pixel> by default, which is the backward
   compatible way

2. size specified in platform data

3. size specified in module parameter 'options' string or specified in
   kernel boot command line (see updated Documentation/fb/pxafb.txt)

And now since the memory is allocated from system memory, the pxafb_mmap
can be removed and the default fb_mmap() should be working all right.

Also, since we now have introduced the 'struct pxafb_dma_buff' for DMA
descriptors and palettes, the allocation can be separated cleanly.

NOTE: the LCD DMA actually supports chained transfer (i.e. page-based
transfers), to simplify the logic and keep the performance (with less
TLB misses when accessing from memory mapped user space), the memory
is allocated by alloc_pages_*() to ensures it's physical contiguous.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      77e19675
  9. 17 10月, 2008 3 次提交
  11. 25 7月, 2008 2 次提交
  13. 28 4月, 2008 7 次提交
  15. 20 3月, 2008 1 次提交
  17. 07 2月, 2008 1 次提交
  19. 20 10月, 2007 1 次提交
  21. 17 10月, 2007 2 次提交
  23. 12 8月, 2007 1 次提交
  25. 10 5月, 2007 2 次提交
  27. 09 5月, 2007 5 次提交
  29. 13 2月, 2007 1 次提交
  31. 04 10月, 2006 6 次提交
  33. 03 10月, 2006 2 次提交
  35. 22 8月, 2006 1 次提交