| Age | Commit message (Collapse) | Author |
|---|
|
We can't just reuse pci_remove as there may be userspace still
doing things.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98638
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97980
Reviewed-by: Christian König <christian.koenig@amd.com>
Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
2 intel fixes.
* tag 'drm-intel-fixes-2016-12-01' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: drop the struct_mutex when wedged or trying to reset
drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error
|
|
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
single drm fix.
* tag 'drm-misc-fixes-2016-11-30' of git://anongit.freedesktop.org/git/drm-misc:
drm: Don't call drm_for_each_crtc with a non-KMS driver
|
|
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.
Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in display pageflips")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161128103648.9235-1-matthew.auld@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.7+
(cherry picked from commit ddbb271aea87fc6004d3c8bcdb0710e980c7ec85)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
On the DMA mapping error path, sg may be NULL (it has already been
marked as the last scatterlist entry), and we should avoid dereferencing
it again.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: e227330223a7 ("drm/i915: avoid leaking DMA mappings")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/20161114112930.2033-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
(cherry picked from commit b17993b7b29612369270567643bcff814f4b3d7f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Fixes oops if userspace calls DRM_IOCTL_GET_CAP for
DRM_CAP_PAGE_FLIP_TARGET on a non-KMS device node. (Normal userspace
doesn't do that, discovered by syzkaller)
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: f837297ad824 ("drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2")
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161130083002.1520-1-michel@daenzer.net
|
|
Thanks for pulling the previous patch for HDLCD. Unfortunately,
yesterday Robin Murphy discovered another issue while playing with
CMA allocation sizes, which he has submitted a fix for.
* 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld:
drm: hdlcd: Fix cleanup order
|
|
The ATPX method does not always exist on the dGPU, it may be located at
the iGPU. The parent device of the iGPU is the root port for which
bridge_d3 is false. This accidentally enables the legacy PM method which
conflicts with port PM and prevented the dGPU from powering on.
Ported from amdgpu commit:
drm/amdgpu: fix check for port PM availability
from Peter Wu.
Fixes: d3ac31f3b4bf9fad (drm/radeon: fix power state when port pm is unavailable (v2))
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Peter Wu <peter@lekensteyn.nl>
Cc: <stable@vger.kernel.org> # 4.8+
|
|
The ATPX method does not always exist on the dGPU, it may be located at
the iGPU. The parent device of the iGPU is the root port for which
bridge_d3 is false. This accidentally enables the legacy PM method which
conflicts with port PM and prevented the dGPU from powering on.
Fixes: 1db4496f167b ("drm/amdgpu: fix power state when port pm is unavailable")
Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org> # 4.8+
|
|
This could lead to mclk dpm problems on some boards.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Ack-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If hdlcd_drm_bind() fails at drm_fbdev_cma_init(), its cleanup will call
drm_mode_config_cleanup() as if to balance drm_mode_config_reset(). The
net result is that drm_connector_cleanup() will clean up the active
connectors long before component_unbind_all() gets called, so when the
connector later tries to clean up itself after being unbound, Bad Things
can happen:
[ 4.121888] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[ 4.129951] pgd = ffffff80091e0000
[ 4.133345] [00000000] *pgd=00000009ffffe003, *pud=00000009ffffe003,
*pmd=0000000000000000
[ 4.141613] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4.147144] Modules linked in:
[ 4.150188] CPU: 0 PID: 122 Comm: kworker/u12:2 Not tainted
4.8.0-rc2+ #989
[ 4.157097] Hardware name: ARM Juno development board (r1) (DT)
[ 4.162981] Workqueue: deferwq deferred_probe_work_func
[ 4.168173] task: ffffffc975d93200 task.stack: ffffffc975dac000
[ 4.174055] PC is at drm_connector_cleanup+0x58/0x1c0
[ 4.179074] LR is at tda998x_unbind+0x24/0x40
[ 4.183401] pc : [<ffffff80084c46f0>] lr : [<ffffff800850414c>]
pstate: 00000045
[ 4.190750] sp : ffffffc975dafa10
[ 4.194041] x29: ffffffc975dafa10 x28: ffffffc9768152a8
[ 4.199325] x27: ffffffc97ff46450 x26: ffffff8008d99000
[ 4.204608] x25: dead000000000100 x24: dead000000000200
[ 4.209891] x23: ffffffc976bf91e8 x22: 0000000000000000
[ 4.215172] x21: ffffffc976bf9170 x20: ffffffc976bf9170
[ 4.220454] x19: ffffffc976bf9018 x18: 0000000000000000
[ 4.225737] x17: 0000000074ce71ee x16: 000000008ff5d35f
[ 4.231019] x15: ffffffc97681e91c x14: ffffffffffffffff
[ 4.236301] x13: ffffffc97681e185 x12: 0000000000000038
[ 4.241583] x11: 0101010101010101 x10: 0000000000000000
[ 4.246866] x9 : 0000000040000000 x8 : 0000000000210d00
[ 4.252148] x7 : ffffffc97fea8c00 x6 : 000000000000001b
[ 4.257430] x5 : ffffff80084b7b8c x4 : 0000000000000080
[ 4.262712] x3 : ffffff8008504128 x2 : ffffffc975df3800
[ 4.267993] x1 : 0000000000000000 x0 : 0000000000000000
...
[ 4.750937] [<ffffff80084c46f0>] drm_connector_cleanup+0x58/0x1c0
[ 4.756990] [<ffffff800850414c>] tda998x_unbind+0x24/0x40
[ 4.762354] [<ffffff8008507918>] component_unbind.isra.4+0x28/0x50
[ 4.768492] [<ffffff8008507a0c>] component_unbind_all+0xcc/0xd8
[ 4.774373] [<ffffff80084d5adc>] hdlcd_drm_bind+0x234/0x418
[ 4.779909] [<ffffff8008507b58>] try_to_bring_up_master+0x140/0x1a0
[ 4.786133] [<ffffff8008507c50>] component_add+0x98/0x170
[ 4.791496] [<ffffff8008504b90>] tda998x_probe+0x18/0x20
[ 4.796774] [<ffffff80086bf914>] i2c_device_probe+0x164/0x258
[ 4.802481] [<ffffff800850d094>] driver_probe_device+0x204/0x2b0
[ 4.808447] [<ffffff800850d28c>] __device_attach_driver+0x9c/0xf8
[ 4.814498] [<ffffff800850b108>] bus_for_each_drv+0x58/0x98
[ 4.820033] [<ffffff800850cd64>] __device_attach+0xc4/0x138
[ 4.825567] [<ffffff800850d338>] device_initial_probe+0x10/0x18
[ 4.831446] [<ffffff800850c124>] bus_probe_device+0x94/0xa0
[ 4.836981] [<ffffff800850c5b0>] deferred_probe_work_func+0x78/0xb0
[ 4.843207] [<ffffff80080d2998>] process_one_work+0x118/0x378
[ 4.848914] [<ffffff80080d2c40>] worker_thread+0x48/0x498
[ 4.854276] [<ffffff80080d8918>] kthread+0xd0/0xe8
[ 4.859036] [<ffffff8008082e90>] ret_from_fork+0x10/0x40
[ 4.864314] Code: f2fbd5b9 f2fbd5b8 f8478ee0 eb17001f (f9400013)
[ 4.870472] ---[ end trace a643cfe4ce1d838b ]---
Fix this by moving the drm_mode_config_cleanup() much later such that it
correctly balances drm_mode_config_init().
Suggested-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
This branch include patches of fixing a typo, accurate dsi frame rate,
and fixing null pointer dereference.
* 'mediatek-drm-fixes-2016-11-24' of https://github.com/ckhu-mediatek/linux.git-tags:
drm/mediatek: fix null pointer dereference
drm/mediatek: fixed the calc method of data rate per lane
drm/mediatek: fix a typo of DISP_OD_CFG to OD_RELAYMODE
|
|
Free memory mapping, if hdmi_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The probe function requests the interrupt before initializing
the ddp component. Which leads to a null pointer dereference at boot.
Fix this by requesting the interrput after all components got
initialized properly.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
MT8173.")
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Change-Id: I57193a7ab554dfb37c35a455900689333adf511c
|
|
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP
mode, those signals will cause h-time larger than normal and reduce FPS.
So need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+
Ths_trail+Ths_exit)/(htotal*bpp/lane_number)
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
|
|
If we want to set the hardware OD to relay mode,
we have to set DISP_OD_CFG register rather than
OD_RELAYMODE; otherwise, the system will access
the wrong address.
Change-Id: Ifb9bb4caa63df906437d48b5d5326b6d04ea332a
Fixes: 7216436420414144646f5d8343d061355fd23483 ("drm/mediatek: set mt8173 dithering function")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
|
|
A late issue discovered by Russell King while testing his setup on Juno.
* 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld:
drm/arm: hdlcd: fix plane base address update
|
|
into drm-fixes
one small powerplay fix and one regression fix for older PX systems and d3cold
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix power state when port pm is unavailable (v2)
drm/amdgpu: fix power state when port pm is unavailable
drm/amd/powerplay: avoid out of bounds access on array ps.
|
|
When PCIe port PM is not enabled (system BIOS is pre-2015 or the
pcie_port_pm=off parameter is set), legacy ATPX PM should still be
marked as supported. Otherwise the GPU can fail to power on after
runtime suspend. This affected a Dell Inspiron 5548.
Ideally the BIOS date in the PCI core is lowered to 2013 (the first year
where hybrid graphics platforms using power resources was introduced),
but that seems more risky at this point and would not solve the
pcie_port_pm=off issue.
v2: agd: fix typo
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org> # 4.8+
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When PCIe port PM is not enabled (system BIOS is pre-2015 or the
pcie_port_pm=off parameter is set), legacy ATPX PM should still be
marked as supported. Otherwise the GPU can fail to power on after
runtime suspend. This affected a Dell Inspiron 5548.
Ideally the BIOS date in the PCI core is lowered to 2013 (the first year
where hybrid graphics platforms using power resources was introduced),
but that seems more risky at this point and would not solve the
pcie_port_pm=off issue.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505
Reported-and-tested-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org> # 4.8+
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region. (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.
This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.
Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
Further debugging shows that we try to update the controller
configuration while enabled.
Alwys ensure that the HDLCD is disabled prior to updating the
controller timings, and use drm_crtc_vblank_off()/drm_crtc_vblank_on()
so that DRM knows whether it can expect vblank interrupts.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
|
|
ssh://git.freedesktop.org/git/drm-intel into drm-fixes
i915 misc fixes.
* tag 'drm-intel-fixes-2016-11-17' of ssh://git.freedesktop.org/git/drm-intel:
drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
drm/i915: Refresh that status of MST capable connectors in ->detect()
drm/i915: Grab the rotation from the passed plane state for VLV sprites
drm/i915: Mark CPU cache as dirty when used for rendering
|
|
This reverts commit f752fff611b99f5679224f3990a1f531ea64b1ec.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This reverts commit 83ba62bc700bab710b22be3a1bf6cf973f754273.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
into drm-fixes
Just a few bug fixes for 4.9. The big one is Mario's prime fencing fix.
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu:fix vpost_needed routine
drm/amdgpu/powerplay: drop a redundant NULL check
drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)
|
|
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes
This branch include one patch to fix a typo, two patches to disable
vblank interrupt, and three patches to support HDMI 4K resolution.
* 'mediatek-drm-fixes-2016-11-11' of https://github.com/ckhu-mediatek/linux.git-tags:
drm/mediatek: modify the factor to make the pll_rate set in the 1G-2G range
drm/mediatek: enhance the HDMI driving current
drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
drm/mediatek: clear IRQ status before enable OVL interrupt
drm/mediatek: set vblank_disable_allowed to true
drm/mediatek: fix a typo of OD_CFG to OD_RELAYMODE
|
|
check array index first and then visit the array.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
specified in the VBT
My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
port information apparently didn't survive the reality of buggy VBTs.
In this particular case we have a machine with a natice HDMI port, but
the VBT tells us it's a DP++ port based on its capabilities.
The dvo_port information in VBT does claim that we're dealing with a
HDMI port though, but we have other machines which do the same even
when they actually have DP++ ports. So that piece of information alone
isn't sufficient to tell the two apart.
After staring at a bunch of VBTs from various machines, I have to
conclude that the only other semi-reliable clue we can use is the
presence of the AUX channel in the VBT. On this particular machine
AUX channel is specified as zero, whereas on some of the other machines
which listed the DP++ port as HDMI have a non-zero AUX channel.
I've also seen VBTs which have dvo_port a DP but have a zero AUX
channel. I believe those we need to treat as DP ports, so we'll limit
the AUX channel check to just the cases where dvo_port is HDMI.
If we encounter any more serious failures with this heuristic I think
we'll have to have to throw it out entirely. But that could mean that
there is a risk of type 1 DVI dongle users getting greeted by a
black screen, so I'd rather not go there unless absolutely necessary.
v2: Remove the duplicate PORT_A check (Daniel)
Fix some typos in the commit message
Cc: Daniel Otero <daniel.otero@outlook.com>
Cc: stable@vger.kernel.org
Tested-by: Daniel Otero <daniel.otero@outlook.com>
Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478884464-14251-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 7a17995a3dc8613f778a9e2fd20e870f17789544)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-fixes
sun4i-drm fixes for 4.9
A few patches to fix our error handling and our panel / bridge calls.
* tag 'sunxi-drm-fixes-for-4.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
drm/sun4i: Propagate error to the caller
drm/sun4i: Fix error handling
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/sun4i: rgb: Enable panel after controller
|
|
1,cleanup description/comments
2,for FIJI & passthrough, force post when smc fw version below 22.15
3,for other cases, follow regular rules
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Left over from an earlier rev of the patch.
Acked-by: Colin Ian King <colin.king@canonical.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Colin King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
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: Mario 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: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Once we've determined that the sink is MST capable we never end up
running through the full detect cycle again, despite getting HPDs.
Fix tht by ripping out the incorrect piece of code responsible.
This got broken when I moved the long HPD handling to the ->detect()
hook, but failed to remove the leftover code.
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Rui Tiago Matos <tiagomatos@gmail.com>
Tested-by: Rui Tiago Matos <tiagomatos@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98323
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
References: https://bugs.freedesktop.org/show_bug.cgi?id=98306
Fixes: 1015811609c0 ("drm/i915: Move long hpd handling into the hotplug work")
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477057478-29328-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 1aab956c7b8872fb6976328316bfad62c6e67cf8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Use the passed in plane_state instead of plane->state in
vlv_update_plane(). Currently the two are one and the same, but if we
start queuing up multiple plane updates they might not be.
Looks like this was rebase fail on my part.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 8d0deca8c6e0 ("drm/i915: Pass 90/270 vs. 0/180 rotation info for intel_gen4_compute_page_offset()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478550057-24864-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 11df4d95b3ad9e6a6a6e0907bb200610a4d24887)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
On LLC, or even snooped, machines rendering via the GPU ends up in the CPU
cache. This cacheline dirt also needs to be flushed to main memory when
moving to an incoherent domain, such as the display's scanout engine.
Mostly, this happens because either the object is marked as dirty from
its first use or is avoided by setting the object into the display
domain from the start.
v2: Treat WT as not requiring a clflush prior to use on the display
engine as well.
Fixes: 0f71979ab7fb ("drm/i915: Performed deferred clflush inside set-cache-level")
References: https://bugs.freedesktop.org/show_bug.cgi?id=95414
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.0+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161107165204.7008-1-chris@chris-wilson.co.uk
(cherry picked from commit 7aa6ca61ee5546d74b76610894924cdb0d4a1af0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
https://github.com/foss-for-synopsys-dwc-arc-processors/linux into drm-fixes
* 'topic-arcpgu-fixes' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux:
drm/arcpgu: Accommodate adv7511 switch to DRM bridge
|
|
ARC PGU driver starts crashing on initialization after
'commit e12c2f645557 ("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: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-fixes
Yet another small batch of fixes. Two of the patches I had prepared
since quite some time, but they did not seem to affect operation in
a visible manner so far. Until recently, when I discovered the third
issue (disable planes before disabling CRTC), which made the two
previous fixes necessary.
* 'fixes-for-v4.9-rc5' of http://git.agner.ch/git/linux-drm-fsl-dcu:
drm/fsl-dcu: disable planes before disabling CRTC
drm/fsl-dcu: update all registers on flush
drm/fsl-dcu: do not update when modifying irq registers
|
|
git://git.pengutronix.de/git/pza/linux into drm-fixes
imx-drm: fix possible hangup when disabling crtcs
- only ever disable the display controller (DC) module after all plane
IDMAC channels are stopped. This fixes a regression introduced by the
atomic modeset conversion.
* tag 'imx-drm-fixes-2016-11-10' of git://git.pengutronix.de/git/pza/linux:
drm/imx: disable planes before DC
|
|
into drm-fixes
Regression fix for powerplay on some iceland boards.
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amd/powerplay: implement get_clock_by_type for iceland.
drm/amd/powerplay/smu7: fix checks in smu7_get_evv_voltages (v2)
drm/amd/powerplay: update phm_get_voltage_evv_on_sclk for iceland
drm/amd/powerplay: propagate errors in phm_get_voltage_evv_on_sclk
|
|
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: poma <poma@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
iceland use pptable v0.
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
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=98357
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Was missing the handling for iceland.
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Missing for one case.
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
into drm-fixes
3 more amdgpu fixes.
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amd/powerplay: return false instead of -EINVAL
drm/amdgpu/powerplay/smu7: fix unintialized data usage
drm/amdgpu: fix crash in acp_hw_fini
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
i915 fixes, include Sandybridge rendering regression fix.
* tag 'drm-intel-fixes-2016-11-09' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Limit Valleyview and earlier to only using mappable scanout
drm/i915: Round tile chunks up for constructing partial VMAs
drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms
drm/i915/dp: BDW cdclk fix for DP audio
drm/i915/vlv: Prevent enabling hpd polling in late suspend
drm/i915: Respect alternate_ddc_pin for all DDI ports
|
|
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: 33f14235302f (drm/imx: atomic phase 1: Use transitional atomic
CRTC and plane helpers)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
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: Stefan Agner <stefan@agner.ch>
|
|
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: Stefan Agner <stefan@agner.ch>
|
