Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 12月, 2009 2 次提交
  3. 01 12月, 2009 2 次提交
  5. 12 9月, 2009 1 次提交
  7. 10 9月, 2009 2 次提交
  9. 01 7月, 2009 1 次提交
    • K
      fbdev: add mutex for fb_mmap locking · 537a1bf0
      由 Krzysztof Helt 提交于 
      Add a mutex to avoid a circular locking problem between the mm layer
semaphore and fbdev ioctl mutex through the fb_mmap() call.

Also, add mutex to all places where smem_start and smem_len fields change
so the mutex inside the fb_mmap() is actually used.  Changing of these
fields before calling the framebuffer_register() are not mutexed.

This is 2.6.31 material.  It removes one lockdep (fb_mmap() and
register_framebuffer()) but there is still another one (fb_release() and
register_framebuffer()).  It also cleans up handling of the smem_start and
smem_len fields used by mutexed section of the fb_mmap().
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      537a1bf0
  11. 22 4月, 2009 1 次提交
  13. 19 3月, 2009 1 次提交
  15. 09 3月, 2009 1 次提交
  17. 04 3月, 2009 1 次提交
    • R
      [ARM] fix lots of ARM __devexit sillyness · bdf602bd
      由 Russell King 提交于 
      `iop_adma_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o
`mv_xor_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o
`mv64xxx_i2c_unmap_regs' referenced in section `.devinit.text' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o
`mv64xxx_i2c_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o
`orion_nand_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o
`pxafb_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bdf602bd
  19. 29 12月, 2008 7 次提交
    • 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: cleanup of the timing checking code · 3f16ff60
      由 Eric Miao 提交于 
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      3f16ff60
    • E
      [ARM] pxafb: cleanup of the color format manipulation code · 878f5783
      由 Eric Miao 提交于 
      1. introduce var_to_depth() to calculate the color depth including the
   transparency bit

2. the conversion from 'fb_var_screeninfo' to LCCR3 BPP bits can be re-
   used by overlays (in OVLxC1), thus an individual pxafb_var_to_bpp()
   has been separated out.

3. pxafb_setmode() should really set the color bitfields correctly at
   begining, introduce a pxafb_set_pixfmt() for this

4. allow user apps to specify color formats within fb_var_screeninfo,
   and checking of this in pxafb_check_var() has been simplified as
   below:

   a) pxafb_var_to_bpp() should pass - which means a basically correct
      bits_per_pixel and color depth setting
   b) the RGBT bitfields are then forced into supported values by
      pxafb_set_pixfmt()
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      878f5783
    • E
      [ARM] pxafb: add palette format support for LCCR4_PAL_FOR_3 · a0427509
      由 Eric Miao 提交于 
      Add the palette format support for LCCR4_PAL_FOR_3, and fix the
issue of LCCR4 being never assigned.

Also remove the useless pxafb_set_truecolor().
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      a0427509
    • E
      [ARM] pxafb: add support for FBIOPAN_DISPLAY by dma braching · 6e354846
      由 Eric Miao 提交于 
      dma branching is enabled by extending the current setup_frame_dma()
function to allow a 2nd set of frame/palette dma descriptors to be
used.

As a result, pxafb_dma_buff.dma_desc[], pxafb_dma_buff.pal_desc[]
and pxafb_info.fdadr[] are doubled.

This allows maximum re-use of the current dma setup code, although
the pxafb_info.fdadr[xx] for FBRx register values looks a bit odd.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      6e354846
    • E
      [ARM] pxafb: allow pxafb_set_par() to start from arbitrary yoffset · 7e4b19c9
      由 Eric Miao 提交于 
      Note the var->yres_virtual is only re-calculated from the fix.smem_len
when text mode acceleration is enabled (which is default), this is due
to the issue as Russell suggested below:

Previous experience of doing this with the X server and acornfb is that
it causes all sorts of problems - it seems to force the X server into
assuming that the framebuffer should be panned no matter what settings
you ask it for.

The recommended workaround (implemented in acornfb) is to only do these
kinds of adjustments if text mode acceleration is enabled.  IIRC, the X
server should be disabling text mode acceleration when it maps the
framebuffer.  I seem to remember that there are X servers which forget
to do that though.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      7e4b19c9
    • 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
  21. 17 12月, 2008 5 次提交
  23. 02 12月, 2008 1 次提交
  25. 27 11月, 2008 1 次提交
  27. 11 11月, 2008 2 次提交
  29. 16 8月, 2008 3 次提交
  31. 07 8月, 2008 2 次提交
  33. 27 7月, 2008 1 次提交
  35. 25 7月, 2008 2 次提交
  37. 10 7月, 2008 1 次提交
  39. 07 7月, 2008 1 次提交
  41. 26 6月, 2008 1 次提交
  43. 22 6月, 2008 1 次提交