提交 · c675949ec58ca50d5a3ae3c757892f1560f6e896 · openeuler / raspberrypi-kernel

11 4月, 2014 2 次提交

drm/i915: do not setup backlight if not available according to VBT · c675949e

由 Jani Nikula 提交于 4月 09, 2014

Some machines use an external EC for controlling the backlight. Info
about this is present in the VBT. Do not setup native backlight control
if no PWM backlight is available or supported according to VBT. The
acpi_backlight interface appears to work for the EC control.

In most cases there has been no harm done, but it looks like there are
machines out there that have both an EC and our PWM line connected to
the same wire. This, obviously, does not end well.

This should fix the regression caused by
commit bc0bb9fd
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Nov 14 12:14:29 2013 +0200

    drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE

AFAICT the quirk removed by the above commit effectively resulted in
i915 not driving the backlight PWM output, thus not messing things up.

Additionally this should fix the regression caused by
commit fbc9fe1b
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Fri Oct 11 21:27:45 2013 +0800

    ACPI / video: Do not register backlight if win8 and native interface exists

which left some machines without a functioning backlight interface.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62281
CC: Aaron Lu <aaron.lu@intel.com>
CC: Eric Griffith <EGriffith92@gmail.com>
CC: Kent Baxley <kent.baxley@canonical.com>
Tested-by: NKamal Mostafa <kamal@canonical.com>
Tested-by: NMartin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

c675949e

drm/i915: check VBT for supported backlight type · 39fbc9c8

由 Jani Nikula 提交于 4月 09, 2014

The only supported types are none and PWM. Other values are obsolete or
reserved, don't add them.
Tested-by: NKamal Mostafa <kamal@canonical.com>
Tested-by: NMartin <bugs@mrvanes.com>
Tested-by: jrg.otte@gmail.com
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

39fbc9c8

10 4月, 2014 1 次提交

drm/i915: Disable self-refresh for untiled fbs on i915gm · 2ab1bc9d

由 Daniel Vetter 提交于 4月 07, 2014

Apparently it doesn't work. X-tiled self-refresh works flawlessly
otoh. Apparently X still works correctly with linear framebuffers, so
might just be an issue with the initial modeset. It's unclear whether
this just borked wm setup from our side or a hw restriction, but just
disabling gets things going.

Note that this regression was only brought to light with

commit 3f2dc5ac
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jan 10 14:06:47 2014 +0200

    drm/i915: Fix 915GM self-refresh enable/disable

before that self-refresh for i915GM didn't work at all.

Kudos to Ville for spotting a little bug in the original patch I've
attached to the bug.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103Tested-by: NKrzysztof Mazur <krzysiek@podlesie.net>
Cc: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: stable@vger.kernel.org
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: rebase on top of drm-next with primary plane support.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

2ab1bc9d

04 4月, 2014 5 次提交

Skip intel_crt_init for Dell XPS 8700 · 10b6ee4a

由 Giacomo Comes 提交于 4月 03, 2014

The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port.
The call intel_crt_init freeze the machine, so skip such call.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559
Signed-off-by: Giacomo Comes <comes at naic.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

10b6ee4a

drm/i915: vlv: fix RPS interrupt mask setting · 09c87db8

由 Imre Deak 提交于 4月 03, 2014

This typo may lead to missed RPS interrupts and as a result a too
low or too high frequency for the current workload. The interrupt mask
will be set properly at a subsequent GPU idle event, but can get
corrupted again at the next RPS up/down event.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

09c87db8

Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec" · f6d51948

由 Deepak S 提交于 4月 03, 2014

As per the inputs provided by hardware team  we still use DDR
Rates as 0,1=800, 2=1066, 3=1333.
With this change, Turbo freqs used on current machines matches.

This reverts commit f64a28a7.

commit f64a28a7
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Nov 4 16:07:00 2013 -0800

     drm/i915/vlv: fixup DDR freq detection per Punit spec

v2: Add reference to previous commit which changed this. (Daniel)
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

f6d51948

drm/i915: move power domain init earlier during system resume · 76c4b250

由 Imre Deak 提交于 4月 01, 2014

During resume the intel hda audio driver depends on the i915 driver
reinitializing the audio power domain. Since the order of calling the
i915 resume handler wrt. that of the audio driver is not guaranteed,
move the power domain reinitialization step to the resume_early
handler. This is guaranteed to run before the resume handler of any
other driver.

The power domain initialization in turn requires us to enable the i915
pci device first, so move that part earlier too.

Accordingly disabling of the i915 pci device should happen after the
audio suspend handler ran. So move the disabling later from the i915
resume handler to the resume_late handler.

v2:
- move intel_uncore_sanitize/early_sanitize earlier too, so they don't
  get reordered wrt. intel_power_domains_init_hw()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org
[danvet: Add cc: stable and loud comments that this is just a hack.]
[danvet: Fix "Should it be static?" sparse warning reported by Wu
Fengguang's kbuilder.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

76c4b250

drm: Add support for two-ended allocation, v3 · 62347f9e

由 Lauri Kasanen 提交于 4月 02, 2014

Clients like i915 need to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.

For other drivers, allocating small bos from one end and large ones
from the other helps improve the quality of fragmentation.

Based on drm_mm work by Chris Wilson.

v3: Changed to use a TTM placement flag
v2: Updated kerneldoc

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Christian König <deathsimple@vodafone.de>
Signed-off-by: NLauri Kasanen <cand@gmx.com>
Signed-off-by: NDavid Airlie <airlied@redhat.com>

62347f9e

02 4月, 2014 11 次提交

drm/i915: Fix the computation of required fb size for pipe · bc104d1f

由 Chris Wilson 提交于 3月 20, 2014

The computation of required framebuffer size in

commit d978ef14
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Mar 7 08:57:51 2014 -0800

    drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12

is too optimistic, and would rely on the invariant fb being
reconstructed to exactly fit each pipe (and probably ignore hardware
limits). Instead, we want to compute the upper bound on what the display
engine will access and ensure that is within the inherited framebuffer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

bc104d1f

drm: Replace crtc fb with primary plane fb (v3) · f4510a27

由 Matt Roper 提交于 4月 01, 2014

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

drm/i915: Restrict plane loops to only operate on overlay planes (v2) · af2b653b

由 Matt Roper 提交于 4月 01, 2014

Ensure that existing driver loops over all planes do not change behavior
when we begin adding new types of planes (primary and cursor) to the DRM
plane list in future patches.

v2: Switch to using drm_for_each_legacy_plane()

Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>

af2b653b

drm/i915: don't get/put runtime PM at the debugfs forcewake file · c8431fda