1. 23 3月, 2014 4 次提交
  2. 22 3月, 2014 3 次提交
    • D
      drm/helper: lock all around force mode restore · 3ea87855
      Dave Airlie 提交于
      Since Daniel documented things with a sledge hammer, we got lots of
      nice backtraces in suspend/resume operations, I've check the callers
      of this and they all seems safe to me,
      
      This fixes one set of warns I reported.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3ea87855
    • D
      drm/fb-helper: improve drm_fb_helper_initial_config locking · 53f1904b
      Daniel Vetter 提交于
      The locking in drm_fb_helper_initial_config is a bit troublesome for a
      few reasons:
      
      - We can't just wrap the entire function up into modeset locks since
        the fbdev registration might call down into fbcon code, which then
        through our ->set_par implementation needs to be able to grab all
        modeset locks. So we'd have a neat deadlock.
      
      - This implies though that all current callers don't hold any modeset
        locks by necessity, so we have free reign to grab any modeset locks
        we need to grab.
      
      - The private state of the fbdev helper doesn't need any protection
        through locks, since once we have the fbdev registered it is mostly
        invariant or protected through the modeset locking in ->set_par and
        other callbacks. We can fully rely on driver having non-racy setup
        sequences here. For the initial config computation we actually may
        not grab locks since drivers which provide their own magic sauce
        (like i915) might need to grab locks themselves.
      
      - We should grab locks though when we probe outputs. Currently there's
        not much risk, but already now userspace could start poking at sysfs
        files and so probe concurrently. I expect that in the future driver
        init will be much more async, and since probing is really
        time-consuming this is a prime candidate.
      
      - We must not hold any crtc->mutex locks while calling probe functions
        since those might need to lock a crtc for e.g. load detection. i915
        is such a driver.
      
      Also it's the probing calls which hit upon piles of new locking
      asserts I've recently added in
      
      commit 62ff94a5
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 23 22:18:47 2014 +0100
      
          drm/crtc-helper: remove LOCKING from kerneldoc
      
      and
      
      commit 63951385
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 23 15:14:15 2014 +0100
      
          drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
      
      Hence the right fix is to grab the mode_config mutex, but only that
      and only right around the probe calls.
      
      It seems to be sufficient to shut up all the locking WARNINGs I see on
      i915 and nouveau in drm_fb_helper_initial_config.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      53f1904b
    • D
      drm/crtc-helper: fix locking for drm_helper_disable_unused_functions · b182cc59
      Daniel Vetter 提交于
      We have two calling contexts for thise function:
      
      - In the crtc helper code itself as part of the ->set_config
        implementation. In this calling context all modeset locks are
        already held, as they should.
      
      - In drivers not implementing fastboot before the fbdev/fbcon setup
        and initialization. This has been added for all drivers in
      
        commit 76a39dbf
        Author: Daniel Vetter <daniel.vetter@ffwll.ch>
        Date:   Sun Jan 20 23:12:54 2013 +0100
      
            drm/fb-helper: don't disable everything in initial_config
      
        In this calling context we do not hold any modeset locks since the
        immediately following call to initialize the fbev emulation grabs
        all these locks themselves.
      
      - There are two exceptions to the above rule: shmob doesn't have fbdev
        emulation support. I've manually checked the callchain up to the
        driver load function and no kms locks are held.
      
      The right fix therefore is to split this helper into an internal and
      external version and add the required locking to the function exported
      to drivers.
      
      This remedies locking inconsistencies exposed by me adding locking
      WARNs as part of the recent kerneldoc abi polishing done in
      
      commit 62ff94a5
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 23 22:18:47 2014 +0100
      
          drm/crtc-helper: remove LOCKING from kerneldoc
      
      and
      
      commit 63951385
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 23 15:14:15 2014 +0100
      
          drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
      
      v2: It helps when I actually git add the entire thing.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b182cc59
  3. 21 3月, 2014 1 次提交
    • D
      Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next · 55004938
      Dave Airlie 提交于
      Summary of what's included:
      
      - SGX MMU support
      - SGX IRQ handling (Page faults and blitter fences)
      - Minor Cedarview and Poulsbo unification
      - Work queue for ASLE interrupt work
      - Various cleanups, style fixes and removal of dead code
      
      * 'gma500-next' of git://github.com/patjak/drm-gma500:
        drm/gma500: remove stub .open/postclose
        drm/gma500: Code cleanup - inline documentation
        drm/gma500: Code cleanup - style fixes
        drm/gma500: Code cleanup - removal of centralized exiting of function
        drm/gma500/cdv: Cedarview display cleanups
        drm/gma500: Unify encoder mode fixup
        drm/gma500: Unify _get_core_freq for cdv and psb
        drm/gma500: Move asle interrupt work into a work task
        drm/gma500: Remove dead code
        drm/gma500: Add backing type and base align to psb_gem_create()
        drm/gma500: Remove unused ioctls
        drm/gma500: Always trap MMU page faults
        drm/gma500: Hook up the MMU
        drm/gma500: Add first piece of blitter code
        drm/gma500: Give MMU code it's own header file
        drm/gma500: Add support for SGX interrupts
        drm/gma500: Make SGX MMU driver actually do something
      55004938
  4. 20 3月, 2014 1 次提交
  5. 18 3月, 2014 24 次提交
  6. 17 3月, 2014 7 次提交