1. 06 3月, 2012 1 次提交
    • A
      drm, gma500: Fix Cedarview boot failures in 3.3-rc · 055bf38d
      Alan Cox 提交于
      Production GMA3600/3650 hardware turns out to be subtly different to the
      development platforms.  This combined with a minor driver bug is causing
      the kernel to hang on these platforms.
      
      This patch does the following
      
       - turn down a couple of messages that were meant to be debug and are
         causing much confusion
      
       - ensure the hotplug interrupt is disabled on Cedartrail systems.
      
       - fix a bug where gtt roll mode called psbfb_sync, which tries to sync
         the 2D engine. On other devices it is harmless as the 2D engine is
         present but not in use when in gtt roll mode, on Cedartrail it causes
         a hang
      
      Without these changes 3.3-rc hangs on boot on Cedartrail based systems.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      055bf38d
  2. 27 1月, 2012 1 次提交
  3. 20 12月, 2011 2 次提交
  4. 06 12月, 2011 3 次提交
  5. 30 11月, 2011 1 次提交
  6. 28 11月, 2011 1 次提交
  7. 16 11月, 2011 2 次提交
  8. 27 9月, 2011 1 次提交
  9. 27 8月, 2011 1 次提交
  10. 16 7月, 2011 4 次提交
  11. 05 7月, 2011 17 次提交
  12. 29 6月, 2011 1 次提交
    • A
      gma500: Make GTT pages uncached · fb7ff7f6
      Alan Cox 提交于
      Clean up the GTT code a bit, make the pages uncached and go via the proper
      interfaces. This avoids any aliasing problems.
      
      On the CPU side we need to access the pages via their true addresses not via
      the GTT. This is fine for GEM created fb objects for X. For the kernel fb
      when not in stolen RAM we are going to need to use vm_map_ram() and hope we
      have enough virtual address space to steal.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fb7ff7f6
  13. 08 6月, 2011 1 次提交
    • M
      staging: gma500: get control from firmware framebuffer if conflicts · aaa5c677
      Michael Chang 提交于
      Many Linux distributions would enable vesafb in order to display
      early stage boot splash. In this case, we will get garbled X
      Window screen if running X fbdev on psbfb.
      
      This is because fb0 is occupied by vesafb while psbfb is on fb1.
      They tried to drive the same pieces of hardware at the same
      time. With unmodified X start-up, it would try to use default
      fb0 framebuffer device and unfortunately it is now broken
      becaues fb1 supersedes it.
      
      We should let psbfb takeover framebuffer control from vesafb
      to get around this problem.
      
      See also commit : 4410f391Signed-off-by: NMichael Chang <mchang@novell.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      aaa5c677
  14. 18 5月, 2011 1 次提交
  15. 26 4月, 2011 3 次提交