Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 4月, 2015 1 次提交
  3. 07 4月, 2015 1 次提交
  5. 20 3月, 2015 2 次提交
  7. 22 1月, 2015 1 次提交
  9. 27 11月, 2014 1 次提交
  11. 05 8月, 2014 6 次提交
  13. 18 7月, 2014 1 次提交
  15. 01 7月, 2014 1 次提交
  17. 19 6月, 2014 3 次提交
  19. 10 6月, 2014 1 次提交
  21. 04 6月, 2014 2 次提交
    • D
      drm: Split connection_mutex out of mode_config.mutex (v3) · 6e9f798d
      由 Daniel Vetter 提交于 
      After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
  properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
  modeset-relevant connector state (e.g. properties which control the
  panel fitter).

The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.

Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.

The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.

For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.

Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.

I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
  sprinkle mode_config.connection_mutex over this file a bit, but
  since it already lacks mode_config.mutex this patch wont make the
  situation any worse. This is material for a follow-up patch.

- omap has a omap_framebuffer_flush function which walks the
  connector->encoder->crtc links and is called from many contexts.
  Some look like they don't acquire mode_config.mutex, so this is
  already racy. Again fixing this is material for a separate patch.

- The radeon hot_plug function to retrain DP links looks at
  connector->dpms. Currently this happens without any locking, so is
  already racy. I think radeon_hotplug_work_func should gain
  mutex_lock/unlock calls for the mode_config.connection_mutex.

- Same applies to i915's intel_dp_hot_plug. But again, this is already
  racy.

- i915 load_detect code needs to acquire this lock. Which means the
  w/w dance due to Rob's work will be nicely contained to _just_ this
  function.

I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.

v1: original (only compile tested)

v2: missing mutex_init(), etc (from Rob Clark)

v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
  get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.

Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>
      6e9f798d
    • J
      drm/radeon: replace drm_get_connector_name() with direct name field use · 72082093
      由 Jani Nikula 提交于 
      Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

[airlied: regenerated]
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      72082093
  23. 03 6月, 2014 1 次提交
  25. 02 6月, 2014 1 次提交
  27. 08 4月, 2014 1 次提交
  29. 02 4月, 2014 1 次提交
    • M
      drm: Replace crtc fb with primary plane fb (v3) · f4510a27
      由 Matt Roper 提交于 
      Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC.  Replace all references to the CRTC fb with the
primary plane's fb.

This patch was generated by the Coccinelle semantic patching tool using
the following rules:

        @@ struct drm_crtc C; @@
        -   (C).fb
        +   C.primary->fb

        @@ struct drm_crtc *C; @@
        -   (C)->fb
        +   C->primary->fb

v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
    moved to a subsequent patch.

v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration.  [Rob Clark]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
      f4510a27
  31. 25 3月, 2014 1 次提交
  33. 08 1月, 2014 1 次提交
  35. 09 11月, 2013 1 次提交
  37. 02 11月, 2013 3 次提交
  39. 19 10月, 2013 1 次提交
    • A
      drm/radeon: rework audio option · 108dc8e8
      由 Alex Deucher 提交于 
      In 3.12 I changed audio to be enabled by default,
but you still had to turn it on via xrandr.  This
was confusing to users so change it to minic the
previous behavior:

- audio option is set to -1 (auto) by default which is
  the current 3.12 behavior (audio is enabled but requires
  xrandr to turn it on).
- if audio = 1, the audio is enabled without needing
  to mess with xrandr (previous behavior)
- audio = 0 disables audio

It retains the new feature of allowing the user to enable
audio on the fly with xrandr, but turns audio on
automatically if radeon.audio=1 is set which is what
most users expect.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
      108dc8e8
  41. 16 9月, 2013 2 次提交
  43. 11 9月, 2013 1 次提交
  45. 04 1月, 2013 1 次提交
  47. 01 12月, 2012 1 次提交
  49. 01 11月, 2012 1 次提交
  51. 03 10月, 2012 1 次提交
  53. 21 9月, 2012 2 次提交