linux-toradex.git/drivers/gpu/drm/i915, branch v3.14.15

drm/i915: Don't clobber the GTT when it's within stolen memory

2014-07-17T23:21:06+00:00

commit f1e1c2129b79cfdaf07bca37c5a10569fe021abe upstream.

On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.

v2: Deal with gen4 36 bit physical address

Signed-off-by: Ville Syrjälä 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151
Acked-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix display power sw state reporting

2014-07-09T18:18:28+00:00

commit b8c000d9bf23e7c1155ef421f595d1cbc25262da upstream.

Atm, we refcount both power domains and power wells and
intel_display_power_enabled_sw() returns the power domain refcount. What
the callers are really interested in though is the sw state of the
underlying power wells. Due to this we will report incorrectly that a
given power domain is off if its power wells were enabled via another
power domain, for example POWER_DOMAIN_INIT which enables all power
wells.

As a fix return instead the state based on the refcount of all power
wells included in the passed in power domain.

References: https://bugs.freedesktop.org/show_bug.cgi?id=79505
References: https://bugs.freedesktop.org/show_bug.cgi?id=79038
Reported-by: Chris Wilson 
Signed-off-by: Imre Deak 
Reviewed-by: Damien Lespiau 
Signed-off-by: Daniel Vetter 
Acked-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: set backlight duty cycle after backlight enable for gen4

2014-07-09T18:18:25+00:00

commit 2e7eeeb59a92d09144fdb7d2dc1af77a10a7945b upstream.

For reasons I can't claim to fully understand gen4 seems to require
backlight duty cycle setting after the backlight has been enabled, or
else black screen follows. I don't have documentation for the correct
sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.

This fixes a regression introduced by
commit b35684b8fa94e04f55fd38bf672b737741d2f9e2
Author: Jani Nikula 
Date:   Thu Nov 14 12:13:41 2013 +0200

    drm/i915: do full backlight setup at enable time

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791
Reported-and-tested-by: mcy@lm7.fr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423
Reported-and-tested-by: Marc Milgram 
Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Avoid div-by-zero when pixel_multiplier is zero

2014-07-09T18:18:25+00:00

commit 2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678 upstream.

On certain platforms pixel_multiplier is read out in
.get_pipe_config(), but it also gets used to calculate the
pixel clock in intel_sdvo_get_config(). If the pipe is disable
but some SDVO outputs are active, we may end up dividing by zero
in intel_sdvo_get_config().

To avoid the problem simply check for zero pixel_multiplier and skip
the division. Another attempt at fixing this involved populating
pixel_multiplier to 1 even for disabled pipes, but that triggered a
WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus
encoder_pixel_multiplier was left at zero and didn't match
pipe_config->pixel_multiplier.

The "divide by pixel_multiplier" operation got introduced here:
 commit 18442d08786472c63a0a80c27f92b033dffc26de
 Author: Ville SyrjÃ¤lÃ¤ 
 Date:   Fri Sep 13 16:00:08 2013 +0300

    drm/i915: Fix port_clock and adjusted_mode.clock readout all over

and it has caused a regression on certain machines since they would
hit the div-by-zero during resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520
Tested-by: Tim Richardson 
Reviewed-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: dp: fix order of dp aux i2c device cleanup

2014-06-11T18:54:14+00:00

commit 80f65de3c9b8101c1613fa82df500ba6a099a11c upstream.

Atm we set the parent of the dp i2c device to be the correspondig
connector device. During driver cleanup we first remove the connector
device through intel_modeset_cleanup()->drm_sysfs_connector_remove() and
only after that the i2c device through the encoder's destroy callback.
This order is not supported by the device core and we'll get a warning,
see the below bugzilla ticket. The proper order is to remove first any
child device and only then the parent device.

The first part of the fix changes the i2c device's parent to be the drm
device. Its logical owner is not the connector anyway, but the encoder.
Since the encoder doesn't have a device object, the next best choice is
the drm device. This is the same what we do in the case of the sdvo i2c
device and what the nouveau driver does.

The second part creates a symlink in the connector's sysfs directory
pointing to the i2c device. This is so, that we keep the current ABI,
which also makes sense in case someone wants to look up the i2c device
belonging to a specific connector.

Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038782.html
Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-February/039427.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak 
Reviewed-by: Antti Koskipää 
Signed-off-by: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: add unregister callback to connector

2014-06-11T18:54:14+00:00

commit 4932e2c3c716067f3580e1a9687bed9d751549e3 upstream.

Since

commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6
Author: Paulo Zanoni 
Date:   Thu Sep 26 20:05:59 2013 -0300

it became clear that we need to separate the unload sequence into two
parts:

1. remove all interfaces through which new operations on some object
   (crtc, encoder, connector) can be started and make sure all pending
   operations are completed
2. do the actual tear down of the internal representation of the above
   objects

The above commit achieved this separation for connectors by splitting
out the sysfs removal part from the connector's destroy callback and
doing this removal before calling drm_mode_config_cleanup() which does
the actual tear-down of all the drm objects.

Since we'll have to customize the interface removal part for different
types of connectors in the upcoming patches, add a new unregister
callback and move the interface removal part to it.

No functional change.

Signed-off-by: Imre Deak 
Reviewed-by: Antti Koskipää 
Signed-off-by: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Only copy back the modified fields to userspace from execbuffer

2014-06-11T18:54:11+00:00

commit 9aab8bff7aa3bee567213ad3c1fdfb217bb980a2 upstream.

We only want to modifiy a single field in the userspace view of the
execbuffer command buffer, so explicitly change that rather than copy
everything back again.

This serves two purposes:

1. The single fields are much cheaper to copy (constant size so the
copy uses special case code) and much smaller than the whole array.

2. We modify the array for internal use that need to be masked from
the user.

Note: We need this backported since without it the next bugfix will
blow up when userspace recycles batchbuffers and relocations.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: quirk invert brightness for Acer Aspire 5336

2014-06-07T17:28:25+00:00

This is commit 0f540c3a7cfb91c9d7a19eb0c95c24 upstream.

Since
commit ee1452d7458451a7508e0663553ce88d63958157
Author: Jani Nikula 
Date:   Fri Sep 20 15:05:30 2013 +0300

    drm/i915: assume all GM45 Acer laptops use inverted backlight PWM

failed and was later reverted in
commit be505f643925e257087247b996cd8ece787c12af
Author: Alexander van Heukelum 
Date:   Sat Dec 28 21:00:39 2013 +0100

    Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"

fix the individual broken machine instead.

Note to backporters:

http://patchwork.freedesktop.org/patch/17837/

is the patch you want for 3.13 and older.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl
Signed-off-by: Jani Nikula 
Reviewed-by: Ville Syrjälä 
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: Daniel Vetter

drm/i915: Fix unsafe loop iteration over vma whilst unbinding them

2014-06-07T17:28:25+00:00

This is commit df6f783a4ef6790780a67c491897ac upstream.

On non-LLC platforms, when changing the cache level of an object, we may
need to unbind it so that prefetching across page boundaries does not
cross into a different memory domain. This requires us to unbind
conflicting vma, but we did so iterating over the objects vma in an
unsafe manner (as the list was being modified as we iterated).

The regression was introduced in
commit 3089c6f239d7d2c4cb2dd5c353e8984cf79af1d7
Author: Ben Widawsky 
Date:   Wed Jul 31 17:00:03 2013 -0700

    drm/i915: make caching operate on all address spaces
apparently as far back as v3.12-rc1, but it has only just begun to
trigger real world bug reports.

Reported-and-tested-by: Nikolay Martynov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384
Signed-off-by: Chris Wilson 
Cc: Ben Widawsky 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

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

2014-06-07T17:28:25+00:00

This is commit 76c4b250080fff6e4befaa36199424 upstream.

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=76152
Signed-off-by: Imre Deak 
Reviewed-by: Takashi Iwai 
[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: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman