Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 4月, 2014 3 次提交
  3. 25 4月, 2014 5 次提交
  5. 24 4月, 2014 4 次提交
  7. 23 4月, 2014 2 次提交
    • P
      drm/i915: get power domain in case the BIOS enabled eDP VDD · 63635217
      由 Paulo Zanoni 提交于 
      If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.

The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.

This regression was introduced in
commit e9cb81a2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Nov 21 13:47:23 2013 -0200

    drm/i915: get a runtime PM reference when the panel VDD is on

v2: - Rebase

Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      63635217
    • D
      drm/i915: Don't check gmch state on inherited configs · 9953599b
      由 Daniel Vetter 提交于 
      ... our current modeset code isn't good enough yet to handle this. The
scenario is:

1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.

2. We read out that state for pipe B and assign the gmch_pfit state to
it.

3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.

-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081Tested-by: Nmax <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      9953599b
  9. 22 4月, 2014 7 次提交
  11. 20 4月, 2014 2 次提交
  13. 19 4月, 2014 1 次提交
  15. 18 4月, 2014 7 次提交
    • G
      drm: bochs: drop unused struct fields · c044330b
      由 Gerd Hoffmann 提交于 
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      c044330b
    • G
      drm: bochs: add power management support · b8ccd70f
      由 Gerd Hoffmann 提交于 
      bochs kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.

Fix this by adding suspend and resume functions.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      b8ccd70f
    • G
      drm: cirrus: add power management support · 2f1e8007
      由 Gerd Hoffmann 提交于 
      cirrus kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.

Fix this by adding suspend and resume functions.
Also make the mode_set function unblank the screen.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      2f1e8007
    • D
      drm: Split out drm_probe_helper.c from drm_crtc_helper.c · 8d754544
      由 Daniel Vetter 提交于 
      This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.

The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.

It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      8d754544
    • D
      drm/plane-helper: Don't fake-implement primary plane disabling · b6ccd7b9
      由 Daniel Vetter 提交于 
      After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:

- The locking is all wrong: set_config(NULL) will also unlink encoders
  and connectors, but those links are protected with the mode_config
  mutex. In the ->disable_plane callback we only hold all modeset
  locks, but eventually we want to switch to just grabbing the
  per-crtc (and maybe per-plane) locks as needed, maybe based on
  ww_mutexes. Having a callback which absolutely needs all modeset
  locks is bad for this conversion.

  Note that the same isn't true for the provided ->update_plane since
  we've audited the crtc helpers to make sure that not encoder or
  connector links are changed.

- There's no way to re-enable the plane with an ->update_plane: The
  connectors/encoder links are lost and so we can't re-enable the
  CRTC. Even without that issue the driver might have reassigned some
  shared resources (as opposed to e.g. DPMS off, where drivers are not
  allowed to do that to make sure the CRTC can be enabled again).

- The semantics don't make much sense: Userspace asked to scan out
  black (or some other color if the driver supports a background
  color), not that the screen be disabled.

- Implementing proper primary plane support (i.e. actually disabling
  the primary plane without disabling the CRTC) is really simple, at
  least if all the hw needs is flipping a bit. The big task is
  auditing all the interactions with other ioctls when the CRTC is on
  but there's no primary plane (e.g. pageflips). And some of that work
  still needs to be done.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      b6ccd7b9
    • D
      drm/ast: fix value check in cbr_scan2 · a82049b1
      由 Dave Airlie 提交于 
      this is a typo vs the ums driver, fix to check correct value.

Found initially by Coverity.
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      a82049b1
    • S
      drm/nouveau/bios: fix a bit shift error introduced by 457e77b2 · 9a118439
      由 Sergei Antonov 提交于 
      Commit 457e77b2 added two checks applied to a
value received from nv_rd32(bios, 0x619f04). But after this new piece of code
is executed, the addr local variable does not hold the same value it used to
hold before the commit. Here is what is was assigned in the original code:
	(u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8
in the committed code it ends up with this value:
	(u64)(nv_rd32(bios, 0x619f04) >> 8) << 8
These expressions are obviously not equivalent.

My Nvidia video card does not show anything on the display when I boot a
kernel containing this commit.

The patch fixes the code so that the new checks are still done, but the
side effect of an incorrect addr value is gone.

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSergei Antonov <saproj@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      9a118439
  17. 17 4月, 2014 9 次提交