Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 6月, 2009 1 次提交
  3. 20 6月, 2009 1 次提交
  5. 17 6月, 2009 1 次提交
    • J
      mb862xxfb: restrict compliation of platform driver to PPC · 336e747e
      由 Julian Calaby 提交于 
      The OpenFirmware part of this driver is uncompilable on SPARC due to it's
dependance on several PPC specific functions.

Restricting this to PPC to prevent these build errors:
  CC      drivers/video/mb862xx/mb862xxfb.o
drivers/video/mb862xx/mb862xxfb.c: In function 'of_platform_mb862xx_probe':
drivers/video/mb862xx/mb862xxfb.c:559: error: implicit declaration of function 'of_address_to_resource'
drivers/video/mb862xx/mb862xxfb.c:575: error: 'NO_IRQ' undeclared (first use in this function)
drivers/video/mb862xx/mb862xxfb.c:575: error: (Each undeclared identifier is reported only once
drivers/video/mb862xx/mb862xxfb.c:575: error: for each function it appears in.)

This was found using randconfig builds.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NAnatolij Gustschin <agust@denx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      336e747e
  7. 13 6月, 2009 1 次提交
  9. 21 5月, 2009 1 次提交
  11. 13 5月, 2009 1 次提交
  13. 07 5月, 2009 1 次提交
  15. 07 4月, 2009 1 次提交
  17. 01 4月, 2009 3 次提交
  19. 13 3月, 2009 1 次提交
  21. 27 2月, 2009 2 次提交
  23. 19 2月, 2009 1 次提交
  25. 10 2月, 2009 1 次提交
  27. 08 2月, 2009 1 次提交
    • I
      drm/i915: select framebuffer support automatically · d2f59357
      由 Ingo Molnar 提交于 
      Migration helper.

The i915 driver recently added a 'depends on FB' rule to its
Kconfig entry - which silently turns off DRM_I915 if someone
has a working config but no CONFIG_FB selected, and upgrades
to the latest upstream kernel.

Norbert Preining reported this problem:

   Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
   Subject     : dri /dev node disappeared with 2.6.29-rc1

So change it to "select FB", which auto-selects framebuffer
support. This way the driver keeps working, regardless of
whether FB was enabled before or not.

Kconfig select's of interactive options can be problematic to
dependencies and can cause build breakages - but in this case
it's safe because it's a leaf entry with no dependencies of its
own.

( There is some minor circular dependency fallout as FB_I810
  and FB_INTEL also used 'depends on FB' constructs - update
  those to "select FB" too. )
Reported-by: NNorbert Preining <preining@logic.at>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      d2f59357
  29. 30 1月, 2009 1 次提交
  31. 22 1月, 2009 1 次提交
  33. 29 12月, 2008 1 次提交
    • 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
  35. 22 12月, 2008 3 次提交
    • M
      video: sh_mobile_lcdcfb deferred io support · 8564557a
      由 Magnus Damm 提交于 
      This patch adds sh_mobile_lcdcfb deferred io support for SYS panels.

The LCDC hardware block managed by the sh_mobile_lcdcfb driver supports
RGB or SYS panel configurations. SYS panels come with an external display
controller that is resposible for refreshing the actual LCD panel. RGB
panels are controlled directly by the LCDC and they need to be refreshed
by the LCDC hardware.

In the case of SYS panels we can save some power by configuring the LCDC
hardware block in one-shot mode. In this one-shot mode panel refresh is
managed by software. This works well together with deferred io since it
allows us to stop clocks for most of the time and only enable clocks when
we actually want to trigger an update. When there is no fbdev activity
the clocks are kept stopped which allows us to deep sleep.

The refresh rate in deferred io mode is set using platform data. The same
platform data can also be used to disable deferred io mode.

As with other deferred io frame buffers user space code should use fsync()
on the frame buffer device to trigger an update.
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      8564557a
    • M
      sh_mobile_lcdc: use FB_SYS helpers instead of FB_CFB · 2540c111
      由 Magnus Damm 提交于 
      Since the sh_mobile_lcdc hardware has the framebuffer(s) in system RAM,
use FB_SYS instead of FB_CFB. Also hook in read and write helpers.
Signed-off-by: NMagnus Damm <damm@igel.co.jp>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      2540c111
    • N
      sh: sh7760fb: Add support SH7720/SH7721 of Renesas · 5c72f303
      由 Nobuhiro Iwamatsu 提交于 
      SH7720 and 7721 has IP of Frame Buffer same as SH7760.
This driver can support these.
Signed-off-by: NNobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      5c72f303
  37. 27 11月, 2008 1 次提交
  39. 07 11月, 2008 1 次提交
  41. 17 10月, 2008 5 次提交
  43. 04 9月, 2008 1 次提交
  45. 27 8月, 2008 2 次提交
  47. 25 7月, 2008 4 次提交
  49. 14 7月, 2008 1 次提交
    • D
      drm: reorganise drm tree to be more future proof. · c0e09200
      由 Dave Airlie 提交于 
      With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach was getting very ugly and
starting to be unmanageable.

This restructures the drm along the lines of other kernel components.

It creates a drivers/gpu/drm directory and moves the hw drivers into
subdirectores. It moves the includes into an include/drm, and
sets up the unifdef for the userspace headers we should be exporting.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      c0e09200
  51. 05 7月, 2008 1 次提交
  53. 19 5月, 2008 1 次提交