1. 18 3月, 2014 2 次提交
  2. 09 10月, 2013 1 次提交
  3. 19 8月, 2013 1 次提交
  4. 16 4月, 2013 1 次提交
  5. 07 4月, 2013 1 次提交
  6. 23 2月, 2013 1 次提交
  7. 12 5月, 2012 1 次提交
  8. 07 5月, 2012 2 次提交
  9. 27 4月, 2012 2 次提交
  10. 10 3月, 2012 1 次提交
  11. 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
  12. 05 3月, 2012 1 次提交
    • A
      drm/gma500: Fix Cedarview boot failures in 3.3-rc · 91982b58
      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
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      91982b58
  13. 25 1月, 2012 2 次提交
  14. 06 12月, 2011 2 次提交
  15. 16 11月, 2011 1 次提交
  16. 27 9月, 2011 1 次提交
  17. 27 8月, 2011 1 次提交
  18. 16 7月, 2011 2 次提交
  19. 09 7月, 2011 1 次提交
  20. 05 7月, 2011 9 次提交
  21. 29 6月, 2011 4 次提交
  22. 10 6月, 2011 1 次提交
  23. 18 5月, 2011 1 次提交
    • A
      gma500: finish off the fault handler · 7ed2911c
      Alan Cox 提交于
      GEM wants to mmap the object through the GTT (which avoids aliasing) so we
      need to put the object into the GTT before we provide the fault mapping for
      it.
      
      While we are at it update the pin interface so that it digs dev out of the
      GEM object itself. This provides a rather cleaner API and call environment.
      Fix th refcount/on-off confusion in the pin API.
      
      At this point we get a bit further with modetest but if we write to the
      new GEM mapping we hang solid and as yet I don't know why.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7ed2911c