With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.
Signed-off-by: Jeffery Miller <jmiller@neverware.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Looking other drm drivers, there is no the restriction that framebuffer
has only one buffer in .create_handle() callback. They use just first
buffer.
If this limitation is removed, there is no reason keeping buffer count
for framebuffer, so we can remove buf_cnt from struct exynos_drm_fb.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This modifies exynos_drm_framebuffer_init() to be possible to support
multiple buffers. Then it can be used by exynos_user_fb_create().
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
It can get exynos_gem object via function argument, so no need to call
exynos_drm_fb_gem_obj() in exynos_drm_fbdev_update.
It also can get struct drm_framebuffer *fb via helper->fb, so can remove
a function argument for it.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The variable name "exynos_gem_obj" is too long, so some lines exceed 80
characters. It's simple to use "obj" instead of "exynos_gem_obj".
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The exynos_drm_fb_set_buf_cnt() is used to set buffer count only in
exynos_drm_fbdev_update(). This patch sets directly buffer count in
exynos_drm_framebuffer_init() without using exynos_drm_fb_set_buf_cnt(),
so there is no any reason to keep exynos_drm_fb_set_buf_cnt().
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The size check was incomplete. It only computed the
size of area of the drawing rectangle and checked if
the size still fit inside the buffer.
The correct check is to compute the position of the
last byte that the G2D engine is going to access and
then check if that position is still contained in the
buffer. In particular we need the stride information
to determine this.
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
commit 346add7834
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 14 18:07:30 2015 +0200
drm/i915: Use expcitly fixed type in compat32 structs
changed the type of param field in drm_i915_getparam from int to
s32. This header is exported to userspace and needs to use userspace
type __s32 instead.
This fixes userspace compilation errors like the following:
include/drm/i915_drm.h:361:2: error: unknown type name 's32'
s32 param;
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
There have been many hard to track down bugs whereby userspace forgot to
flag a write buffer and then cause graphics corruption or a hung GPU
when that buffer was later purged under memory pressure (as the buffer
appeared clean, its pages would have been evicted rather than preserved
and any changes more recent than in the backing storage would be lost).
In retrospect this is a rare optimisation against memory pressure,
already the slow path. If we always mark the buffer as dirty when
accessed by the GPU, anything not used can still be evicted cheaply
(ideal behaviour for mark-and-sweep eviction) but we do not run the risk
of corruption. For correct read serialisation, userspace still has to
notify when the GPU writes to an object. However, there are certain
situations under which userspace may wish to tell white lies to the
kernel...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Goel, Akash" <akash.goel@intel.co>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Calculate the number of retries we should do for each i2c-over-aux
message based on the time it takes to perform the i2c transfer vs. the
aux transfer. We assume the shortest possible length for the aux
transfer, and the longest possible (exluding clock stretching) for the
i2c transfer.
The DP spec has some examples on how to calculate this, but we don't
calculate things quite the same way. The spec doesn't account for the
retry interval (assumes immediate retry on defer), and doesn't assume
the best/worst case behaviour as we do.
Note that currently we assume 10 kHz speed for the i2c bus. Some real
world devices (eg. some Apple DP->VGA dongle) fails with less than 16
retries. and that would correspond to something close to 15 kHz (with
our method of calculating things) But let's just go for 10 kHz to be
on the safe side. Ideally we should query/set the i2c bus speed via
DPCD but for now this should at leaast remove the regression from the
1->16 byte trasnfer size change. And of course if the sink completes
the transfer quicker this shouldn't slow things down since we don't
change the interval between retries.
I did a few experiments with a DP->DVI dongle I have that allows you
to change the i2c bus speed. Here are the results of me changing the
actual bus speed and the assumed bus speed and seeing when we start
to fail the operation:
actual i2c khz assumed i2c khz max retries
1 1 ok -> 2 fail 211 ok -> 106 fail
5 8 ok -> 9 fail 27 ok -> 24 fail
10 17 ok -> 18 fail 13 ok -> 12 fail
100 210 ok -> 211 fail 2 ok -> 1 fail
So based on that we have a fairly decent safety margin baked into
the formula to calculate the max number of retries.
Fixes a regression with some DP dongles from:
commit 1d002fa720
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date: Tue Feb 10 18:38:08 2015 +0000
drm/dp: Use large transactions for I2C over AUX
v2: Use best case for AUX and worst case for i2c (Simon Farnsworth)
Add a define our AUX retry interval and account for it
v3: Make everything usecs to avoid confusion about units (Daniel)
Add a comment reminding people about the AUX bitrate (Daniel)
Use DIV_ROUND_UP() since we're after the "worst" case for i2c
Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Tested-by: moosotc@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91451
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently we react to native and i2c defers by waiting either 400-500 us
or 500-600 us, depending on which code path we take. Consolidate them
all to one define AUX_RETRY_INTERVAL which defines the minimum interval.
Since we've been using two different intervals pick the longer of them
and define AUX_RETRY_INTERVAL as 500 us. For the maximum just use
AUX_RETRY_INTERVAL+100 us.
I want to have a define for this so that I can use it when calculating
the estimated duration of i2c-over-aux transfers. Without a define it
would be very easy to change the sleep duration and neglect to update
the i2c-over-aux estimates.
Cc: Simon Farnsworth <simon.farnsworth@onelan.com>
Cc: moosotc@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use port_clock instead of link_bw when picking the PLL parameters for
DP. link_bw may be zero with an eDP 1.4 sink that supports
DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it
to the sink appropriately.
v2: Fix typo in commit message (Sivakumar)
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from future.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Applications like gnome-shell may try to render after dropping master
privileges. Since the driver should now be safe against this scenario,
allow those applications to use their legacy node like a render node.
v2: Add missing return statement.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Commit ec9f932ed4
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.
Changes since v1:
- Fix -EDEADLK handling of vblank events too.
- Free state last with CHECK_ONLY.
Changes since v2:
- Add comment about freeing crtc_state->event with TEST_ONLY.
(Daniel Stone)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit 92122789b2 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.
However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.
This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.
Due to 92122789b2 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.
Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).
Fix this by moving the code introduced by 92122789b2 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.
Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Fixes: 92122789b2 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jeffery Miller
Chunming Zhou
Alex Deucher
Joonyoung Shim
Tobias Jakobi
Ville Syrjälä
Artem Savkov
Chris Wilson
Ander Conselvan de Oliveira
Thomas Hellstrom
Maarten Lankhorst
Lukas Wunner