Age | Commit message (Collapse) | Author | Files | Lines |
|
Extend KBL platform support in GVT-g. Validation tests
are done on KBL server and KBL NUC. Both show the same
quality.
Signed-off-by: Jian Jun Chen <[email protected]>
Cc: Zhenyu Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes
misc vmwgfx fixes.
* 'drm-vmwgfx-fixes' of git://people.freedesktop.org/~syeh/repos_linux:
drm/vmwgfx: constify pci_device_id.
drm/vmwgfx: Fix gcc-7.1.1 warning
drm/vmwgfx: Fix cursor hotspot issue with Wayland on Fedora
drm/vmwgfx: Limit max desktop dimensions to 8Kx8K
drm/vmwgfx: dma-buf: Constify ttm_place structures.
drm/vmwgfx: fix comment mistake for vmw_cmd_dx_set_index_buffer()
drm/vmwgfx: Use dma_pool_zalloc
drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'
drm/vmwgfx: Fix NULL pointer comparison
|
|
These on()/off() calls should be done as a result of modesetting actions,
and as we shut down all heads already on unload/suspend, it's pointless
to call off() again.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
We don't support them on G80, but we need to add them to the mapping to
avoid triggering a WARN_ON() on GPUs where the ports are present.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Since switching the I2C-over-AUX helpers, there have been regressions on
some display combinations due to us not having support for "address only"
transactions.
This commits enables support for them for GF119 and newer.
Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
A bug that I had fixed earlier just came back, with CONFIG_EXTCON=m,
the rockchip drm driver will fail to link:
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x30): undefined reference to `extcon_get_state'
cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x6c): undefined reference to `extcon_get_property'
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_check_sink_connection':
cdn-dp-core.c:(.text.cdn_dp_check_sink_connection+0x80): undefined reference to `extcon_get_state'
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_enable':
cdn-dp-core.c:(.text.cdn_dp_enable+0x748): undefined reference to `extcon_get_property'
The problem is that that the sub-drivers are now all linked into the
main rockchip drm module, which breaks all the Kconfig dependencies
that are specified in the options for those sub-drivers.
This clarifies the dependency to ensure that we can only turn on the DP
driver when EXTCON is reachable. As the 'select' statements can now
cause additional options to become built-in when they should be
loadable modules, I'm moving those into the main driver config option.
The dependency on DRM_ROCKCHIP can be reduced into a single 'if'
statement here for brevity, but this has no functional effect.
Fixes: b6705157b2db ("drm/rockchip: add extcon dependency for DP")
Fixes: 8820b68bd378 ("drm/rockchip: Refactor the component match logic.")
Link: https://patchwork.kernel.org/patch/9648761/
Acked-by: Guenter Roeck <[email protected]>
Tested-by: Jeffy Chen <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Mark Yao <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Before we interpret drm_dp_downstream_id() as a string, make sure it is
NULL terminated, even when drm_dp_downtsream_id() fails.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101660
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Pass in the array and not a pointer to the array to drm_dp_dpcd_read().
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and
enabling DPCD backlight leads to a black screen after suspend/resume.
References: http://mid.mail-archive.com/20170706135349.6tu3lz7uehazlnnn@boom
References: http://mid.mail-archive.com/20170627132326.f2q3yn4bh5flji4q@boom
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101619
Reported-by: David Weinehall <[email protected]>
Fixes: 560a758d39c6 ("drm/i915: Add heuristic to determine better way to adjust brightness")
Cc: Jenny TC <[email protected]>
Cc: David Weinehall <[email protected]>
Cc: Puthikorn Voravootivat <[email protected]>
Cc: Dhinakaran Pandiyan <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/f49a89a05f18e90871c2eeadcdcd783ac7961cdf.1500542254.git.jani.nikula@intel.com
|
|
This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3.
The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and
enabling DPCD backlight leads to a black screen after suspend/resume.
References: http://mid.mail-archive.com/20170706135349.6tu3lz7uehazlnnn@boom
References: http://mid.mail-archive.com/20170627132326.f2q3yn4bh5flji4q@boom
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101619
Reported-by: David Weinehall <[email protected]>
Fixes: ae25eceab616 ("drm/i915: Add option to support dynamic backlight via DPCD")
Cc: Jenny TC <[email protected]>
Cc: David Weinehall <[email protected]>
Cc: Puthikorn Voravootivat <[email protected]>
Cc: Dhinakaran Pandiyan <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/051eeb592361985d2d06333c61c220dd92253b09.1500542254.git.jani.nikula@intel.com
|
|
git://git.pengutronix.de/git/pza/linux into drm-fixes
imx-drm: fix parallel display regression and typo in plane format list
- Fix a regression where the parallel-display driver would not probe
anymore if no panel is specified in the device tree, since the
introduction of drm_of_find_panel_or_bridge.
- Fix a typo in the plane format list: replace a duplicate BGRA8888 format
with BGRX8888, as originally intended.
* tag 'imx-drm-fixes-2017-07-18' of git://git.pengutronix.de/git/pza/linux:
drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failure
drm/imx: fix typo in ipu_plane_formats[]
|
|
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
Core Changes:
- fence: Introduce new fence flag to signify timestamp is populated (Chris)
- mst: Avoid processing incomplete data + fix NULL dereference (Imre)
Driver Changes:
- vc4: Avoid WARN from grabbing a ref from vblank that's not on (Boris)
Cc: Chris Wilson <[email protected]>
Cc: Boris Brezillon <[email protected]>
Cc: Imre Deak <[email protected]>
* tag 'drm-misc-fixes-2017-07-20' of git://anongit.freedesktop.org/git/drm-misc:
drm/mst: Avoid processing partially received up/down message transactions
drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()
drm/mst: Fix error handling during MST sideband message reception
drm/vc4: Fix VBLANK handling in crtc->enable() path
dma-buf/fence: Avoid use of uninitialised timestamp
|
|
The core already does this in setup_commit(). With this we can also
remove the unpin_work_count since it's the last user, and also remove
the loop since that was only used for stalling against legacy flips.
v2: Amend commit message a bit (Chris).
Cc: Maarten Lankhorst <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This gets rid of all the interactions between the legacy flip code and
the modeset code. Yay!
This highlights an ommission in the atomic paths, where we fail to
apply a boost to the pending rendering when we miss the target vblank.
But the existing code is still dead and can be removed.
v2: Note that the boosting doesn't work in atomic (Chris).
Cc: Maarten Lankhorst <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
A bit an oversight - the current code did nothing, since only
legacy flips used the unpin_work_count and assorted logic.
Cc: Maarten Lankhorst <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
All these races and things are now solved through the vblank evasion
trick, plus event handling is done using normal vblank even processing
and drm_crtc_arm_vblank_event. We can get rid of all this complexity.
Cc: Maarten Lankhorst <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Goto the right label in case of error, otherwise there is a leak.
This has been introduced by c5cf9a9147ff. In this patch a goto has not been
updated.
Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist from")
Signed-off-by: Christophe JAILLET <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
|
|
INTEL_GEN() appears to be the new way of doing these platform checks, so
convert this i915_irq.c too.
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Taking the modeset locks unconditionally isn't the greatest idea,
because atm that part is still broken and times out (and then atomic
keels over). And there's really no reason to do so, the old code
didn't do that either.
To make the patch a bit simpler let's also nuke 2 cases that are only
around for the old mmioflip paths. Atomic nonblocking workers will not
die (minus bugs) when a gpu reset happens.
And of course this doesn't fix any of the gpu reset vs. modeset
deadlock fun, but it at least stop modern CI machines from keeling
over all over the place for no reason at all.
And we still have the explicit testcases to run the fake gpu reset, so
coverage isn't that much worse.
v2: Split out additional changes on top, restrict this to purely reducing
the critical section of modeset locks.
v2: Review from Maarten
- update comments
- don't oops when state is NULL in intel_finish_reset, but try to at
least still drop locks properly. The hw is going to be toast anyway.
Fixes: 739748939974 ("drm/i915: Fix modeset handling during gpu reset, v5.")
Cc: Maarten Lankhorst <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Just a very minimal patch to nuke that code. Lots of the flip
interrupt handling stuff is still around.
Cc: Maarten Lankhorst <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
transcoders") misses some pieces, due to a problem with the patch
format, this patch adds the remaining bits.
Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
transcoders")
Signed-off-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently we may process up/down message transactions containing
uninitialized data. This can happen if there was an error during the
reception of any message in the transaction, but we happened to receive
the last message correctly with the end-of-message flag set.
To avoid this abort the reception of the transaction when the first
error is detected, rejecting any messages until a message with the
start-of-message flag is received (which will start a new transaction).
This is also what the DP 1.4 spec 2.11.8.2 calls for in this case.
In addtion this also prevents receiving bogus transactions without the
first message with the the start-of-message flag set.
v2:
- unchanged
v3:
- git add the part that actually skips messages after an error in
drm_dp_sideband_msg_build()
Cc: Dave Airlie <[email protected]>
Cc: Lyude <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Lyude <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In case of an unknown broadcast message is sent mstb will remain unset,
so check for this.
Cc: Dave Airlie <[email protected]>
Cc: Lyude <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Lyude <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Handle any error due to partial reads, timeouts etc. to avoid parsing
uninitialized data subsequently. Also bail out if the parsing itself
fails.
Cc: Dave Airlie <[email protected]>
Cc: Lyude <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Lyude <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
git://anongit.freedesktop.org/git/drm-intel into drm-next
2nd round of 4.14 features:
- prep for deferred fbdev setup
- refactor fixed 16.16 computations and skl+ wm code (Mahesh Kumar)
- more cnl paches (Rodrigo, Imre et al)
- tighten context cleanup and handling (Chris Wilson)
- fix interlaced handling on skl+ (Mahesh Kumar)
- small bits as usual
* tag 'drm-intel-next-2017-07-17' of git://anongit.freedesktop.org/git/drm-intel: (84 commits)
drm/i915: Update DRIVER_DATE to 20170717
drm/i915: Protect against deferred fbdev setup
drm/i915/fbdev: Always forward hotplug events
drm/i915/skl+: unify cpp value in WM calculation
drm/i915/skl+: WM calculation don't require height
drm/i915: Addition wrapper for fixed16.16 operation
drm/i915: cleanup fixed-point wrappers naming
drm/i915: Always perform internal fixed16 division in 64 bits
drm/i915: take-out common clamping code of fixed16 wrappers
drm/i915/cnl: Add missing type case.
drm/i915/cnl: Add max allowed Cannonlake DC.
drm/i915: Make DP-MST connector info work
drm/i915/cnl: Get DDI clock based on PLLs.
drm/i915/cnl: Inherit RPS stuff from previous platforms.
drm/i915/cnl: Gen10 render context size.
drm/i915/cnl: Don't trust VBT's alternate pin for port D for now.
drm/i915: Fix the kernel panic when using aliasing ppgtt
drm/i915/cnl: Cannonlake color init.
drm/i915/cnl: Add force wake for gen10+.
x86/gpu: CNL uses the same GMS values as SKL
...
|
|
We need to unpin the last retired context early in the shutdown sequence
so that its RCU free is done before we try to free the context ida. I
included this in a later patch ("drm/i915: Keep a recent cache of freed
contexts objects for reuse") and so missed that the selftests were broken
in the meantime.
Reported-by: Matthew Auld <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101627
Fixes: 5f09a9c8ab6b ("drm/i915: Allow contexts to be unreferenced locklessly")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Matthew Auld <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
|
|
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the cleanup part.
I originally suspected that this was broken in one of the unload
shuffles, but on closer inspection the oldest sequence I've dug out
also gets this wrong. Just not quite so badly.
I've run drv_module_reload a few hundred times and it's rock solid
compared to insta-death beforehand. This bug seems to have been
uncovered by
commit 88be58be886f1215cc73dc8c273c985eecd7385c
Author: Daniel Vetter <[email protected]>
Date: Thu Jul 6 15:00:19 2017 +0200
drm/i915/fbdev: Always forward hotplug events
But the effect of that seems to only be to increase the race window
enough to make it blow up easier. I'm not exactly clear on what's
going on there ...
v2: Fix whitespace and use fetch_and_zero (Chris).
Testcase: igt/drv_module_reload
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The legacy plane->fb pointer is refcounted by calling
drm_atomic_clean_old_fb().
In practice this isn't a real problem because:
- The caller in the i915 gpu reset code restores the original state
again, which means the plane->fb pointer won't change, hence can't
leak.
- Drivers using drm_atomic_helper_shutdown call the fbdev cleanup
first, and that usually cleans up the fb through
drm_remove_framebuffer, which does this correctly.
- Without fbdev the only framebuffers are from userspace, and those
get cleaned up (again using drm_remove_framebuffer) befor the driver
can even be unloaded.
But in i915 I've switched the cleanup sequence around so that the
_shutdown() calls happens after the drm_remove_framebuffer(), which is
how I discovered this issue.
v2: My analysis why the current code was ok for gpu reset and
suspend/resume was correct, but then I totally failed to realize that
we better keep this symmetric. Thanksfully CI noticed that for
balance, a refcounting bug must exist at 2 places if previously there
was no issue ...
v3: Don't be lazy and compute the plane_mask in
commit_duplicated_state properly too, instead of just using ~0U.
Cc: [email protected]
Cc: [email protected]
Acked-by: Dave Airlie <[email protected]> (v1)
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Supply a pm_domain and its ops for our mock GEM device so that
device runtime pm doesn't complain even though we only want to mark it
permanently active!
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Matthew Auld <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
|
|
Workers on the i915->wq may rearm themselves so for completeness we need
to replace our flush_workqueue() with a call to drain_workqueue() before
unloading the device.
v2: Reinforce the drain_workqueue with an preceding rcu_barrier() as a
few of the tasks that need to be drained may first be armed by RCU.
References: https://bugs.freedesktop.org/show_bug.cgi?id=101627
Signed-off-by: Chris Wilson <[email protected]>
Cc: Matthew Auld <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Mika Kuoppala <[email protected]>
|
|
I've found a bios with an off-by-one at the other end. There's a pnp
reservation for 0xc5400000-0xc7fffffe and we want stolen in 0xc6000000
through 0xc8000000.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99872
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98683
Cc: Martin Peres <[email protected]>
Reviewed-by: Martin Peres <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same
as ddb_allocation >= blocks_per_line, so use the latter to simplify
this.
This fixes the following compiler warning:
drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a
boolean expression with an integer other than 0 or 1.
Changes since v1:
- Rebase, was missing the changes to the macro names.
Signed-off-by: Maarten Lankhorst <[email protected]>
Fixes: d555cb5827d6 ("drm/i915/skl+: use linetime latency if ddb size is not available")
Cc: "Mahesh Kumar" <[email protected]>
Reported-by: David Binderman <[email protected]>
Cc: David Binderman <[email protected]>
Cc: <[email protected]> # v4.13-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Mahesh Kumar <[email protected]>
|
|
This adds the connector name when printing a debug message about the DP
link training result. It is useful to figure out what connector is
failing when multiple DP connectors are used.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Manasi Navare <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add HDMI CEC support to the Allwinner A10 SoC.
This SoC uses a poor-man's CEC implementation by polling the CEC pin. It is
using the CEC_PIN core implementation for such devices to do the heavy
lifting. It just provides the callbacks to read/drive the CEC pin.
Signed-off-by: Hans Verkuil <[email protected]>
Tested-by: Maxime Ripard <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Even though that function is defined in the TCON header, it's not defined
nor used anywhere. Remove the prototype.
Reviewed-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The atomic_check callback is optional, and we don't implement anything in
some parts of our drivers. Let's remove it.
Reviewed-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
|
|
The depends on relationship is obvious, and using an if statement will
propagate it to every option without the need for each and every one of
them to define it.
Reviewed-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
|
|
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.
Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.
Cc: Paul Menzel <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: Ville Syrjälä <[email protected]>
Tested-by: Paul Menzel <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Signed-off-by: Tom Lendacky <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brijesh Singh <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Konrad Rzeszutek Wilk <[email protected]>
Cc: Larry Woodman <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Toshimitsu Kani <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/a19436f30424402e01f63a09b32ab103272acced.1500319216.git.thomas.lendacky@amd.com
Signed-off-by: Ingo Molnar <[email protected]>
|
|
For modern drivers the DRM core doesn't use struct_mutex at all, which
means it's defacto a driver-private lock. But since we still need it
for legacy drivers we can't initialize it in drivers, which means all
the different instances share one lockdep key. Despite that they might
be placed in totally different places in the locking hierarchy.
This results in a lot of bogus lockdep splats when running stuff on
systems with multiple gpus. Partially remedy the situation by only
doing might_lock checks on drivers that do use struct_mutex still for
gem locking.
A more complete solution would be to do the mutex_init in the drm core
only for legacy drivers, plus add it to each modern driver that still
needs it, which would also give each its own lockdep key. Trying to do
that dynamically doesn't work, because lockdep requires it's keys to
be statically allocated.
v2: {} everywhere (Chris)
Cc: Hans de Goede <[email protected]>
Cc: Ben Skeggs <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
13765 800 20 14585 38f9 gpu/drm/vmwgfx/vmwgfx_drv.o
File size After adding 'const':
text data bss dec hex filename
13829 736 20 14585 38f9 gpu/drm/vmwgfx/vmwgfx_drv.o
Signed-off-by: Arvind Yadav <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
The current code does not look correct, and the reason for it is
probably lost. Since this now generates a compiler warning,
fix it to what makes sense.
Cc: <[email protected]>
Reported-by: Arnd Bergmann <[email protected]>
Reported-by: Linus Torvalds <[email protected]>
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
Parts of commit <8fbf9d92a7bc> (“drm/vmwgfx: Implement the
cursor_set2 callback v2”) were not moved over when we started
atomic mode set development because at that time the DRM did
not support cursor hotspots in the fb struct.
This patch fixes what was not moved over.
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Tested-by: Brian Paul <[email protected]>
|
|
This was originally chosen to be an arbitrarily large number. However,
some user mode may actually try to set a 16Kx16K mode and run into other
issues.
Since 8Kx8K is the current texture limit for Mesa LLVM driver, we will
just use this limit for now.
Cc: <[email protected]> # 4.12.x
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by <drm/ttm/ttm_placement.h> work
with const ttm_place. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
3172 796 16 3984 f90 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
File size After adding 'const':
text data bss dec hex filename
3456 512 16 3984 f90 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.o
Signed-off-by: Arvind Yadav <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
Comment fix.
Signed-off-by: Brian Paul <[email protected]>
Reviewed-by: Neha Bhende <[email protected]>
|
|
We should use dma_pool_zalloc instead of dma_pool_alloc/memset
Signed-off-by: Souptick joarder <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
Signed-off-by: Sinclair Yeh <[email protected]>
|
|
'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
Propagate the error code, instead of returning -ENOMEM unconditionally
Signed-off-by: Christophe JAILLET <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
Signed-off-by: Sinclair Yeh <[email protected]>
|