- 04 12月, 2015 1 次提交
-
-
由 Thomas Hellstrom 提交于
A client calling drmSetMaster() using a file descriptor that was opened when another client was master would inherit the latter client's master object and all its authenticated clients. This is unwanted behaviour, and when this happens, instead allocate a brand new master object for the client calling drmSetMaster(). Fixes a BUG() throw in vmw_master_set(). Cc: <stable@vger.kernel.org> Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 12月, 2015 9 次提交
-
-
由 Imre Deak 提交于
There are platforms that don't need the full GMBUS power domain (BXT) while others do (PCH, VLV/CHV). For optimizing this we would need to add a new power domain, but it's not clear how much we would benefit given the short time we hold the reference. So for now let's keep things simple. This fixes a regression introduced in commit 237ed86c Author: Sonika Jindal <sonika.jindal@intel.com> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid v2: - fix commit message, PCH won't take any redundant power resource after this change (Ville) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [fix commit message in v2 (Imre)] [Cherry-picked from drm-intel-next-queued 29bb94bb (Imre)] Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-6-git-send-email-imre.deak@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
MISSING_CASE() would have been useful to track down a recent problem in intel_display_port_aux_power_domain(), so add it there and a few related helpers. This was also suggested by Ville in his review of the latest DMC/DC changes, we forgot to address that. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> [Cherry-picked from drm-intel-next-queued b9fec167 (Imre)] Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-5-git-send-email-imre.deak@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
Due to the current sharing of the DDI encoder between DP and HDMI connectors we can run the DP detection after the HDMI detection has already set the shared encoder's type. For now solve this keeping the current behavior and running the detection in this case too. For a proper solution Ville suggested to split the encoder into an HDMI and DP one, that can be done as a follow-up. This issue triggers the WARN in intel_display_port_aux_power_domain() and was introduced in: commit 25f78f58 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Nov 16 15:01:04 2015 +0100 drm/i915: Clean up AUX power domain handling CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> [Cherry-picked from drm-intel-next-queued 651174a4 (Imre)] Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-4-git-send-email-imre.deak@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Currently the gmbus code uses intel_aux_display_runtime_get/put in an effort to make sure the hardware is powered up sufficiently for gmbus. That function only takes the runtime PM reference which on VLV/CHV/BXT is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well 2 on BXT. So add a new power domnain for gmbus and kill off the now unused intel_aux_display_runtime_get/put. And change intel_hdmi_set_edid() to use the gmbus power domain too since that's all we need there. Also toss in a BUILD_BUG_ON() to catch problems if we run out of bits for power domains. We're already really close to the limit... [Patrik: Add gmbus string to debugfs output] Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> [Cherry-picked from drm-intel-next-queued f0ab43e6 (Imre)] Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-3-git-send-email-imre.deak@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Introduce intel_display_port_aux_power_domain() which simply returns the appropriate AUX power domain for a specific port, and then replace the intel_display_port_power_domain() with calls to the new function in the DP code. As long as we're not actually enabling the port we don't need the lane power domains, and those are handled now purely from modeset_update_crtc_power_domains(). My initial motivation for this was to see if I could keep the DPIO power wells powered down while doing AUX on CHV, but turns out I can't so this doesn't change anything for CHV at least. But I think it's still a worthwile change. v2: Add case for PORT E. Default to POWER_DOMAIN_AUX_D for now. (Ville) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> [Cherry-picked from drm-intel-next-queued 25f78f58 (Imre)] Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448643329-18675-2-git-send-email-imre.deak@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Daniel Stone 提交于
Passing -1 as the pipe for vblank events now triggers a WARN_ON, but had previously made multi-screen unusable anyway. Pass the correct pipe to the event-send function, and use the new API to make this a bit easier for us. Fixes WARN present since cc1ef118 for every pageflip event sent: [ 209.549969] ------------[ cut here ]------------ [ 209.554592] WARNING: CPU: 3 PID: 238 at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x80/0x88 [drm]() [ 209.564832] Modules linked in: [...] [ 209.612401] CPU: 3 PID: 238 Comm: irq/41-ff940000 Tainted: G W 4.3.0-rc6+ #71 [ 209.620647] Hardware name: Rockchip (Device Tree) [ 209.625348] [<c001bb80>] (unwind_backtrace) from [<c001615c>] (show_stack+0x20/0x24) [ 209.633079] [<c001615c>] (show_stack) from [<c02b2c50>] (dump_stack+0x8c/0x9c) [ 209.640289] [<c02b2c50>] (dump_stack) from [<c0052e88>] (warn_slowpath_common+0x94/0xc4) [ 209.648364] [<c0052e88>] (warn_slowpath_common) from [<c0052f74>] (warn_slowpath_null+0x2c/0x34) [ 209.657139] [<c0052f74>] (warn_slowpath_null) from [<bf17dc30>] (drm_vblank_count_and_time+0x80/0x88 [drm]) [ 209.666875] [<bf17dc30>] (drm_vblank_count_and_time [drm]) from [<bf17e484>] (drm_send_vblank_event+0x74/0x7c [drm]) [ 209.677385] [<bf17e484>] (drm_send_vblank_event [drm]) from [<bf4c1144>] (vop_win_state_complete+0x4c/0x70 [rockchip_drm_vop]) [ 209.688757] [<bf4c1144>] (vop_win_state_complete [rockchip_drm_vop]) from [<bf4c3bdc>] (vop_isr_thread+0x170/0x1d4 [rockchip_drm_vop]) [ 209.700822] [<bf4c3bdc>] (vop_isr_thread [rockchip_drm_vop]) from [<c00ab93c>] (irq_thread_fn+0x2c/0x50) [ 209.710284] [<c00ab93c>] (irq_thread_fn) from [<c00abcac>] (irq_thread+0x13c/0x188) [ 209.717927] [<c00abcac>] (irq_thread) from [<c00723c8>] (kthread+0xec/0x104) [ 209.724965] [<c00723c8>] (kthread) from [<c0011638>] (ret_from_fork+0x14/0x3c) [ 209.732171] ---[ end trace 0690bc604f5d535d ]--- Signed-off-by: NDaniel Stone <daniels@collabora.com> Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Cc: Thierry Reding <treding@nvidia.com> Cc: Heiko Stuebner <heiko@sntech.de> Tested-By: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Tested-by: NHeiko Stuebner <heiko@sntech.de> Reviewed-by: NThierry Reding <treding@nvidia.com>
-
由 Luis de Bethencourt 提交于
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
-
由 Dominik Behr 提交于
VOP_WINx_DSP_ST does not require subtracting 1 from the values written to it. It actually causes the screen to be shifted by one pixel. Signed-off-by: NMark Yao <mark.yao@rock-chips.com> Tested-by: NYakir Yang <ykk@rock-chips.com> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Tested-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NDominik Behr <dbehr@chromium.org> Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
-
由 Heiko Stuebner 提交于
Commit 371f0f08 ("ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()") introduced offset-checking for mappings, which collides with the fake-offset the drm sets for gems. Other drm-drivers set this offset to 0 before doing the mapping, so this looks like the correct way to go for rockchip as well. Fixes: 371f0f08 ("ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()") Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
-
- 01 12月, 2015 4 次提交
-
-
由 Sjoerd Simons 提交于
When doing the initial setup both the hclk and the aclk need to be enabled otherwise the board will simply hang. This only occurs when building the vop driver as a module, when its built-in the initial setup happens to run before the clock framework shuts of unused clocks (including the aclk). While there also switch to doing prepare and enable in one step rather then separate steps to reduce the amount of code required. Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Acked-by: NMark Yao <mark.yao@rock-chips.com> Tested-by: NYakir Yang <ykk@rock-chips.com> Tested-by: NRomain Perier <romain.perier@gmail.com>
-
由 Chris Wilson 提交于
We have relied upon the sole caller (wait_ioctl) validating the timeout argument. However, when waiting for multiple requests I forgot to ensure that the timeout was still positive on the later requests. This is more simply done inside __i915_wait_request. Fixes regression introduced in commit b4716185 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 27 13:41:17 2015 +0100 drm/i915: Implement inter-engine read-read optimisations The impact of the regression is 1 jiffie for each extra active ring for a wait_ioctl with a timeout -- I don't think anyone has noticed. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448544702-5594-1-git-send-email-chris@chris-wilson.co.ukSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Marc-André Lureau 提交于
Avoid the sticky preferred mode bit by using the no-merge version of the function (this allows gnome-shell to resize to lower resolutions than the default resolution) Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Luis de Bethencourt 提交于
This platform driver has a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
-
- 26 11月, 2015 1 次提交
-
-
由 Alex Deucher 提交于
"Could not force DPM to low", etc. is usually harmless and just confuses users. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 25 11月, 2015 14 次提交
-
-
由 Takashi Iwai 提交于
Currently a DDI port may register the DP hotplug handler even though it's used with HDMI, and the DP HPD handler overrides the encoder type forcibly to DP. This caused the inconsistency on a machine connected with a HDMI monitor; upon a hotplug event, the DDI port is suddenly switched to be handled as a DP although the same monitor is kept connected, and this leads to the erroneous blank output. This patch papers over the bug by excluding the previous HDMI encoder type from this override. This should be fixed more fundamentally, e.g. by moving the encoder type reset from the HPD or by having individual encoder objects for HDMI and DP. But since the bug has been present for a long time (3.17), it's better to have a quick-n-dirty fix for now, and keep working on a cleaner fix. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=955190 Fixes: 0e32b39c ('drm/i915: add DP 1.2 MST support (v0.7)') Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1447931396-19147-1-git-send-email-tiwai@suse.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Takashi Iwai 提交于
The commit [cfb23ed6: drm/i915: Allow fuzzy matching in pipe_config_compare, v2] relaxed the way to compare the pipe configurations, but one new comparison sneaked in there: it added the strict has_drrs value check. This causes a regression on many machines, typically HP laptops with a docking port, where the kernel spews warnings and eventually fails to set the mode properly like: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 1, found 0) ------------[ cut here ]------------ WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700 intel_modeset_check_state+0x5aa/0x870 [i915]() pipe state doesn't match! .... This patch just removes the check again for fixing the regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456 Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397 Fixes: cfb23ed6 ('drm/i915: Allow fuzzy matching in pipe_config_compare, v2') Cc: <stable@vger.kernel.org> # v4.3+ Reported-and-tested-by: NMax Lin <mlin@suse.com> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448461607-16868-1-git-send-email-tiwai@suse.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Russell King 提交于
ipu_crtc_handle_pageflip() was calling drm_send_vblank_event() with a pipe argument of -1. Commit cc1ef118 ("drm/irq: Make pipe unsigned and name consistent") now makes this error obvious, as we now may get a warning from: if (WARN_ON(pipe >= dev->num_crtcs)) in drm_vblank_count_and_time(). Prior to this change, we would end up making out-of-bounds array accesses via: struct drm_vblank_crtc *vblank = &dev->vblank[crtc]; and *vblanktime = vblanktimestamp(dev, pipe, cur_vblank); So, this has been broken for a very long time, and is not a result of the above commit. Since we don't care about the staging versions, I've tagged this with the earliest mainline commit where we do care, even though this commit did not introduce the bug. Fixes: 6556f7f8 ("drm: imx: Move imx-drm driver out of staging") Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
-
由 Martin Peres 提交于
Reported-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NMartin Peres <martin.peres@free.fr>
-
由 Ben Skeggs 提交于
Regression from "abi16: implement limited interoperability with usif/nvif". Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Somehow missed these two when removing dodgy void casts during the rework. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
fdo#92761 Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Each GPCCS unit was reading the mask from GPC0, which causes problems on boards where some GPCs are missing PPCs. Part of the fix for fdo#92761. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
There's a few places where we need to access a GPC register from ucode, but outside of the falcon's io address space. To do this we need to calculate the offset based on which GPC we're executing on. This used to be done manually, but we've since found a "base" offset that can be added by the hardware. To use this, an extra bit needs to be set in the register address, which is what this macro achieves. There should be no functional change from this commit. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes detection of a failed attempt at fetching the entire ROM image in one-shot (a violation of the spec, that works a lot of the time). Tested on a HP Zbook 15 G2. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
No locking is required for the traversal of this list, as it only happens during suspend/resume where nothing else can be executing. Fixes some of the issues noticed during parallel piglit runs. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
fdo#70354 - comment #88. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Karol Herbst 提交于
this is needed for my gpu Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alex Deucher 提交于
On some cards it takes a relatively long time for the change to take place. Make a timeout non-fatal. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76130Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 24 11月, 2015 7 次提交
-
-
由 Markus Elfring 提交于
The drm_fbdev_cma_restore_mode() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
-
由 Philipp Zabel 提交于
The crtc child device driver shouldn't modify the of_node of its platform device in the probe function. Instead, since the previous patch, the IPU core driver sets the of_node when the platform device is created. Drop the now unused custom imx_drm_get_port_by_id function. Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Philipp Zabel 提交于
The crtc child device driver shouldn't have to modify the of_node of its platform device in the probe function. Instead, let the IPU core driver set the of_node when the platform device is created. Also reorder the client_reg array so the elements are in port id order (CSIs first, then DIs). Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Philipp Zabel 提交于
This is not used, so remove it. Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
-
由 Philipp Zabel 提交于
Similarly to commit 5e501ed7 ("drm/imx: imx-ldb: allow to determine bus format from the connected panel"), if a panel is connected to the ldb output port via the of_graph bindings, the data mapping is determined from the display_info.bus_format field provided by the panel instead of from the optional interface_pix_fmt device tree property. Reported-by: NUlrich Ölmann <u.oelmann@pengutronix.de> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Tested-by: NGary Bisson <gary.bisson@boundarydevices.com>
-
由 Christian König 提交于
This way the driver isn't limited in the dependency handling callback. v2: remove extra check in amd_sched_entity_pop_job() Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
We only need to wait for jobs to be scheduled when the dependency is from the same scheduler. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
- 23 11月, 2015 1 次提交
-
-
由 Chris Wilson 提交于
We have varied reports of swizzling corruption on gen4 desktop, and confirmation that one at least is triggered by uneven memory banks (L-shaped memory). The implication is that the swizzling varies between the paired channels and the remainder of memory on the single channel. As the object then has unpredictable swizzling (it will vary depending on exact page allocation and may even change during the object's lifetime as the pages are replaced), we have to report to userspace that the swizzling is unknown. However, some existing userspace is buggy when it meets an unknown swizzling configuration and so we need to tell another white lie and mark the swizzling as NONE but report it as UNKNOWN through the extended get-tiling-ioctl. See commit 5eb3e5a5 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jun 28 09:19:26 2015 +0100 drm/i915: Declare the swizzling unknown for L-shaped configurations for the previous example where we found that telling the truth to userspace just ends up in a world of hurt. Also since we don't truly know what the swizzling is on the pages, we need to keep them pinned to prevent swapping as the reports also suggest that some gen4 devices have previously undetected bit17 swizzling. v2: Combine unknown + quirk patches to prevent userspace ever seeing unknown swizzling through the normal get-tiling-ioctl. Also use the same path for the existing uneven bank detection for mobile gen4. Reported-by: NMatti Hämäläinen <ccr@tnsp.org> Tested-by: NMatti Hämäläinen <ccr@tnsp.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=90725Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matti Hämäläinen <ccr@tnsp.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1447927085-31726-1-git-send-email-chris@chris-wilson.co.ukSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 21 11月, 2015 3 次提交
-
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Leo Liu 提交于
Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-