- 11 11月, 2016 7 次提交
-
-
由 Mario Kleiner 提交于
External clients which import our bo's wait only for exclusive dmabuf-fences, not on shared ones, ditto for bo's which we import from external providers and write to. Therefore attach exclusive fences on prime shared buffers if our exported buffer gets imported by an external client, or if we import a buffer from an external exporter. See discussion in thread: https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html Prime export tested on Intel iGPU + AMD Tonga dGPU as DRI3/Present Prime render offload, and with the Tonga standalone as primary gpu. v2: Add a wait for all shared fences before prime export, as suggested by Christian Koenig. v3: - Mark buffer prime_exported in amdgpu_gem_prime_pin, so we only use the exclusive fence when exporting a bo to external clients like a separate iGPU, but not when exporting/importing from/to ourselves as part of regular DRI3 fd passing. - Propagate failure of reservation_object_wait_rcu back to caller. v4: - Switch to a prime_shared_count counter instead of a flag, which gets in/decremented on prime_pin/unpin, so we can switch back to shared fences if all clients detach from our exported bo. - Also switch to exclusive fence for prime imported bo's. v5: - Drop lret, instead use int ret -> long ret, as proposed by Christian. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95472 Tested-by: Mike Lothian <mike@fireburn.co.uk> (v1) Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Cc: Christian König <christian.koenig@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Eugeniy Paltsev 提交于
ARC PGU driver starts crashing on initialization after 'commit e12c2f64 ("drm/i2c: adv7511: Convert to drm_bridge")' This happenes because in "arcpgu_drm_hdmi_init" function we get pointer of "drm_i2c_encoder_driver" structure, which doesn't exist after adv7511 hdmi encoder interface changed from slave encoder to drm bridge. So, when we call "encoder_init" function from this structure driver crashes. Bootlog: ------------------------------------->8-------------------------------- [drm] Initialized drm 1.1.0 20060810 arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab arcpgu e0017000.pgu: assigned reserved memory node frame_buffer@9e000000 Path: (null) CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-00001-gb5642252fa01-dirty #8 task: 9a058000 task.stack: 9a032000 [ECR ]: 0x00220100 => Invalid Read @ 0x00000004 by insn @ 0x803934e8 [EFA ]: 0x00000004 [BLINK ]: drm_atomic_helper_connector_dpms+0xa6/0x230 [ERET ]: drm_atomic_helper_connector_dpms+0xa4/0x230 [STAT32]: 0x00000846 : K DE E2 E1 BTA: 0x8016d949 SP: 0x9a033e34 FP: 0x00000000 LPS: 0x8036f6fc LPE: 0x8036f700 LPC: 0x00000000 r00: 0x8063c118 r01: 0x805b98ac r02: 0x00000b11 r03: 0x00000000 r04: 0x9a010f54 r05: 0x00000000 r06: 0x00000001 r07: 0x00000000 r08: 0x00000028 r09: 0x00000001 r10: 0x00000007 r11: 0x00000054 r12: 0x720a3033 Stack Trace: drm_atomic_helper_connector_dpms+0xa4/0x230 arcpgu_drm_hdmi_init+0xbc/0x228 arcpgu_probe+0x168/0x244 platform_drv_probe+0x26/0x64 really_probe+0x1f0/0x32c __driver_attach+0xa8/0xd0 bus_for_each_dev+0x3c/0x74 bus_add_driver+0xc2/0x184 driver_register+0x50/0xec do_one_initcall+0x3a/0x120 kernel_init_freeable+0x108/0x1a0 ------------------------------------->8-------------------------------- Fix ARC PGU driver to be able work with drm bridge hdmi encoder interface. The hdmi connector code isn't needed anymore as we expect the adv7511 bridge driver to create/manage the connector. Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Reviewed-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
-
由 Dave Airlie 提交于
Thou shall not send control msg from the stack, does that mean I can send it from the RO memory area? and it looks like the answer is no, so here's v2 which kmemdups. Reported-by: poma Tested-by: Npoma <poma@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Rex Zhu 提交于
iceland use pptable v0. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=185681 https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Only check if the tables exist in relevant configs. This fixes a failure on V0 tables. v2: fix version check as suggested by Rex bugs: https://bugzilla.kernel.org/show_bug.cgi?id=185681 https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Was missing the handling for iceland. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=185681 https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Missing for one case. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=185681 https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 09 11月, 2016 5 次提交
-
-
由 Lucas Stach 提交于
If the DC clock is disabled before the attached IDMACs are properly stopped the IDMACs may hang the IPU or even the whole system. Make sure the IDMACs are in safe state by disabling the planes before removal of the DC clock. Also set the atomic parameter to false to stop calling the atomic_begin hook, which does nothing useful as we immediately afterwards turn off vblank interrupts and possibly send the pending vblank event. Fixes: 33f14235 (drm/imx: atomic phase 1: Use transitional atomic CRTC and plane helpers) Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
-
由 Stefan Agner 提交于
After disabling and reenabling the CRTC the DCU sometimes got stuck displaying the whole screen with a solid color. Disabling and reenabling the CRTC did not recover from the situation. This was often reproducable by just restarting the X-Server. The disabling sequence is not explicitly documented. But it turns out that disabling the planes before disabling the CRTC seems to prevent the above situation from happening. Use the callback ->atomic_disable instead of ->disable which allows to use the drm_atomic_helper_disable_planes_on_crtc() helper to disable planes before disabling the controller. Signed-off-by: NStefan Agner <stefan@agner.ch>
-
由 Stefan Agner 提交于
Use the UPDATE_MODE READREG bit to initiate a register transfer on flush. This makes sure that we flush all registers only once for all planes. Signed-off-by: NStefan Agner <stefan@agner.ch>
-
由 Stefan Agner 提交于
The IRQ status and mask registers are not "double buffered" according to the reference manual. Hence, there is no extra transfer/update write needed when modifying these registers. Signed-off-by: NStefan Agner <stefan@agner.ch>
-
由 Andrew Shadura 提交于
Returning -EINVAL from a bool-returning function phm_check_smc_update_required_for_display_configuration has an unexpected effect of returning true, which is probably not what was intended. Replace -EINVAL by false. The only place this function is called from is psm_adjust_power_state_dynamic in drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106: if (!equal || phm_check_smc_update_required_for_display_configuration(hwmgr)) { phm_apply_state_adjust_rules(hwmgr, requested, pcurrent); phm_set_power_state(hwmgr, &pcurrent->hardware, &requested->hardware); hwmgr->current_ps = requested; } It seems to expect a boolean value here. This issue has been found using the following Coccinelle semantic patch written by Peter Senna Tschudin: <smpl> @@ identifier f; constant C; typedef bool; @@ bool f (...){ <+... * return -C; ...+> } </smpl> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAndrew Shadura <andrew.shadura@collabora.co.uk> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 08 11月, 2016 8 次提交
-
-
由 Arnd Bergmann 提交于
A recent bugfix replaced an out-of-bounds access with direct use of unintialized data: drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c: In function 'smu7_patch_limits_vddc': drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddc' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2146:11: note: 'vddc' was declared here drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddci' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2146:17: note: 'vddci' was declared here uint32_t vddc, vddci; This initializes the data as before using the correct type. Fixes: 77f7f71f ("drm/amdgpu/powerplay/smu7: fix static checker warning") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
On CZ/ST systems with AZ rather than ACP audio, we need to bail early in hw_fini since there is nothing to do. bug: https://bugs.freedesktop.org/show_bug.cgi?id=98276Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Chris Wilson 提交于
Valleyview appears to be limited to only scanning out from the first 512MiB of the Global GTT. Lets presume that this behaviour was inherited from the display block copied from g4x (not Ironlake) and all earlier generations are similarly affected, though testing suggests different symptoms. For simplicity, impose that these platforms must scanout from the mappable region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this catches Cherryview which does not appear to be limited to the low aperture for its scanout.) v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about limiting this workaround to the old style of display engine. v3: Update changelog to reflect testing by Ville Syrjälä v4: Include the changes to the comments as well Reported-by: NLuis Botello <luis.botello.ortega@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036 Fixes: 2efb813d ("drm/i915: Fallback to using unmappable memory for scanout") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Akash Goel <akash.goel@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20161107110128.28762-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 767a222e) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
When we split a large object up into chunks for GTT faulting (because we can't fit the whole object into the aperture) we have to align our cuts with the fence registers. Each partial VMA must cover a complete set of tile rows or the offset into each partial VMA is not aligned with the whole image. Currently we enforce a minimum size on each partial VMA, but this minimum size itself was not aligned to the tile row causing distortion. Reported-by: NAndreas Reis <andreas.reis@gmail.com> Reported-by: NChris Clayton <chris2553@googlemail.com> Reported-by: NNorbert Preining <preining@logic.at> Tested-by: NNorbert Preining <preining@logic.at> Tested-by: NChris Clayton <chris2553@googlemail.com> Fixes: 03af84fe ("drm/i915: Choose partial chunksize based on tile row size") Fixes: a61007a8 ("drm/i915: Fix partial GGTT faulting") # enabling patch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98402 Testcase: igt/gem_mmap_gtt/medium-copy-odd Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+ Link: http://patchwork.freedesktop.org/patch/msgid/20161107105443.27855-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 0ef723cb) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Dhinakaran Pandiyan 提交于
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. Let's apply this work around to GEN9 platforms too, as it fixes the same issue. v2: Move drm_device to drm_i915_private conversion Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907 Cc: stable@vger.kernel.org Cc: Libin Yang <libin.yang@linux.intel.com> Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478117601-19122-1-git-send-email-dhinakaran.pandiyan@intel.com (cherry picked from commit 9c754024) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Dhinakaran Pandiyan 提交于
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less than 432 MHz, enabling audio leads to pipe FIFO underruns and displays cycling on/off. From BSpec: "Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)] Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may be audio corruption or screen corruption." Since, some DP configurations (e.g., MST) use port width x4 and HBR2 link rate, let's increase the cdclk to >= 432 MHz to enable audio for those cases. v4: Changed commit message v3: Combine BDW pixel rate adjustments into a function (Jani) v2: Restrict fix to BDW Retain the set cdclk across modesets (Ville) Cc: stable@vger.kernel.org Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478026080-2925-1-git-send-email-dhinakaran.pandiyan@intel.com (cherry picked from commit b30ce9e0) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lyude 提交于
One of the CI machines began to run into issues with the hpd poller suddenly waking up in the midst of the late suspend phase. It looks like this is getting caused by the fact we now deinitialize power wells in late suspend, which means that intel_hpd_poll_init() gets called in late suspend causing polling to get re-enabled. So, when deinitializing power wells on valleyview we now refrain from enabling polling in the midst of suspend. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040 Fixes: 19625e85 ("drm/i915: Enable polling when we don't have hpd") Signed-off-by: NLyude <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Cc: Petry Latvala <petri.latvala@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477499769-1966-1-git-send-email-lyude@redhat.com (cherry picked from commit b64b5409) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
The VBT provides the platform a way to mix and match the DDI ports vs. GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose has no standard GMBUS pin assignment. However, there are machines out there that use a non-standard mapping for the other ports as well. Let's start trusting the VBT on this one for all ports on DDI platforms. I've structured the code such that other platforms could easily start using this as well, by simply filling in the ddi_port_info. IIRC there may be CHV system that might actually need this. v2: Include a commit message, include a debug message during init Cc: stable@vger.kernel.org Cc: Maarten Maathuis <madman2003@gmail.com> Tested-by: NMaarten Maathuis <madman2003@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJim Bride <jim.bride@linux.intel.com> (cherry picked from commit e4ab73a1) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 04 11月, 2016 1 次提交
-
-
由 Archit Taneja 提交于
If VRAM allocation fails, the error handling path crashes in msm_drm_uninit(). The following changes are made to fix this: msm_gem_shrinker_cleanup() is fixed to unregister the shrinker only if it was init-ed in the first place. Before calling kms->funcs->destroy(), we check if kms->funcs is also non-NULL. This is needed for MDP5, since during msm_drm_int(), priv->kms becomes non-NULL early, but msm_kms_init() is called on it only later in mdp5_kms_init(). Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NAndy Gross <andy.gross@linaro.org>
-
- 03 11月, 2016 1 次提交
-
-
由 Gerd Hoffmann 提交于
virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and because of that it must be called for disabled planes too. Ask drm_atomic_helper_commit_planes to do that. v2: update to use new drm_atomic_helper_commit_planes() API. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 11月, 2016 5 次提交
-
-
由 Rob Clark 提交于
Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Looks like cut/paste error from the other device cfgs (which do support scaling on RGBn pipes). Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
If the bottom-most layer is not fullscreen, we need to use the BASE mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT). The blend_setup() code pretty much handled this already, we just had to figure this out in _atomic_check() and assign the stages appropriately. Also fix the case where there are zero enabled planes, where we also need to enable BORDER_OUT. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Archit Taneja 提交于
The DSI/HDMI PLLs in MSM require resources like interface clocks, power domains to be enabled before we can access their registers. The clock framework doesn't have a mechanism at the moment where we can tie such resources to a clock, so we make sure that the KMS driver enables these resources whenever a PLL is expected to be in use. One place where we can't ensure the resource dependencies are met is when the clock framework tries to disable unused clocks. The KMS driver doesn't know when the clock framework calls the is_enabled clk_op, and hence can't enable interface clocks/power domains beforehand. We set the CLK_IGNORE_UNUSED flag for PLL clocks for now. This needs to be revisited, since bootloaders can enable display, and we would want to disable the PLL clocks if there isn't a display driver using them. Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Acked-by: NStephen Boyd <sboyd@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Archit Taneja 提交于
The msm/dsi host drivers calls drm_helper_hpd_irq_event in the mipi_dsi_host attach/detatch callbacks. mipi_dsi_attach()/mipi_dsi_detach() from a panel/bridge driver could be called from a context where the drm_device's mode_config.mutex is already held, resulting in a deadlock. Queue it as work instead. Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 01 11月, 2016 6 次提交
-
-
由 Peter Wu 提交于
Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not). This is a workaround for a problem where ACPICA and Windows 10 differ in behavior. ACPICA does not correctly enumerate power resources within a conditional block (due to delayed execution of such blocks) and as a result power_resources is set to false even if _PR3 exists. Fixes: 692a17dc ("drm/nouveau/acpi: fix lockup with PCIe runtime PM") Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398Reported-and-tested-by: NRick Kerkhof <rick.2889@gmail.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Christian König 提交于
Just to be clean should we ever run into -ENOMEM during module init. v2: fix typo in commit message Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Some fences might be alive even after we have stopped the scheduler leading to warnings about leaked objects from the SLUB allocator. Fix this by allocating/freeing the SLUB allocator from the module init/fini functions just like we do it for hw fences. v2: make variable static, add link to bug Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97500Reported-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Grazvydas Ignotas 提交于
Otherwise callers end up using uninitialized data. Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net> Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This should only happen on boards TV connectors which do not have a ddc bus for those connectors. None of the asics supported by amdgpu support tv, so we shouldn't hit this, but check to be on the safe side (e.g., bios bug for example). Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Larry Finger 提交于
Since commit a481daa8 ("drm/radeon: always apply pci shutdown callbacks"), a Dell Latitude D600 laptop has crashed on shutdown. The PCI Identification of the graphics adapter is "VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] [1002:4c66] (rev 01)". Prior to commit b0c80bd5 ("drm/radeon: fix up dp aux tear down (v2)"), I have no idea where the panic happened as the screen was blanked before the crash. Since that more recent change, the panic has been in routine radeon_connector_unregister(), and has been shown to be due to a NULL value in the ddc_bus member of struct drm_connector. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=178421 Fixes: a481daa8 ("drm/radeon: always apply pci shutdown callbacks") Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 31 10月, 2016 2 次提交
-
-
由 Alex Deucher 提交于
If the platform does not support hybrid graphics or ATPX dGPU power control. Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
If the platform does not support hybrid graphics or ATPX dGPU power control. bug: https://bugzilla.kernel.org/show_bug.cgi?id=51381Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 29 10月, 2016 2 次提交
-
-
由 Alex Deucher 提交于
Newer iceland parts require new smc firmware. Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Newer tonga parts require new smc firmware. Reviewed-by: NHuang Rui <ray.huang@amd.com> Reviewed-by: NEric Huang <JinHuiEric.Huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 28 10月, 2016 3 次提交
-
-
由 Ville Syrjälä 提交于
Pass the framebuffer size in .16 fixed point coordinates to drm_rect_rotate() since that's what the source coordinates are as well at this stage. We used to do this part of the computation in integer coordinates, but that got changed when moving the computation to happen in the check phase of the operation. Unfortunately I forgot to shift up the fb width and height appropriately. With the bogus size we ended up with some negative fb offset, which when added to the vma offset caused out scanout to start at an offset earlier than we inteded. Eg. when testing on my SKL I saw a row of incorrect tiles at the top of my screen. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: b63a16f6 ("drm/i915: Compute display surface offset in the plane check hook for SKL+") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477325584-23679-1-git-send-email-ville.syrjala@linux.intel.comTested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit da064b47) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Tvrtko Ursulin 提交于
Objects can have multiple VMAs used for display in which case assertion that objects must not be pinned for display more times than the current VMA is incorrect. v2: Commit message update. (Chris Wilson) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 058d88c4 ("drm/i915: Track pinned VMA") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1477413635-3876-1-git-send-email-tvrtko.ursulin@linux.intel.com (cherry picked from commit 3299e7e4) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Tvrtko Ursulin 提交于
We do not need to set up a fence for the rotated view. Display does not need it and no one can access it. v2: Move code to __i915_vma_set_map_and_fenceable. (Chris Wilson) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 05a20d09 ("drm/i915: Move map-and-fenceable tracking to the VMA") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 07ee2bce) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-