- 17 Sep, 2019 3 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2019-09-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Few fixes on GGTT and PPGTT around pin, locks, fence and vgpu. This also includes GVT fixes with two recent fixes: one for recent guest hang regression and another for guest reset fix. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911233309.GA18449@intel.com
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2019-09-06' of git://anongit.freedesktop.org/drm/drm-misc into drm-next - A significant number of panfrost fixes for runtime_pm, MMU and GEM support - A fix for DCS transfers on mcde Signed-off-by:
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
+ move msm8998 (snapdragon 835) display support + dpu fixes/cleanup + better async commit support for cursor updates (for dpu for now, I'll add mdp5 and possibly mdp4 once the movers deliver boxes full of my older hardware, so for v5.5) Signed-off-by:
-
- 06 Sep, 2019 9 commits
-
-
Chris Wilson authored
The intention is that we first try to pin the current vma into the mappable aperture only if it is already in use or it fits in the free space and will not cause contention. The first attempt was meant to be using PIN_NOEVICT to reuse the current vma if possible, following up with different eviction strategies. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111485 Fixes: 6846895f ("drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190826130750.17272-1-chris@chris-wilson.co.uk (cherry picked from commit ebfdf5cd) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Xiaolin Zhang authored
vgpu ppgtt notification was split into 2 steps, the first step is to update PVINFO's pdp register and then write PVINFO's g2v_notify register with action code to tirgger ppgtt notification to GVT side. currently these steps were not atomic operations due to no any protection, so it is easy to enter race condition state during the MTBF, stress and IGT test to cause GPU hang. the solution is to add a lock to make vgpu ppgtt notication as atomic operation. Cc: stable@vger.kernel.org Signed-off-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Acked-by:
-
Chris Wilson authored
Our fence management is lazy, very lazy. If the user marks an object as untiled, we do not immediately flush the fence but merely mark it as dirty. On the next use we have to remember to check and remove the fence, by which time we hope it is idle and we do not have to wait. v2: Throw away the old fence on the next ggtt_pin. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111468 Fixes: 1f7fd484 ("drm/i915: Replace i915_vma_put_fence()") Signed-off-by:
-
Chris Wilson authored
Sadly lockdep records when the irqs are re-enabled and then marks up the fake lock as being irq-unsafe. Our hand is forced and so we must mark up the entire fake lock critical section as irq-off. Hopefully this is the last tweak required! v2: Not quite, we need to mark the timeline spinlock as irqsafe. That was a genuine bug being hidden by the earlier lockdep splat. Fixes: d6773926 ("drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823132700.25286-2-chris@chris-wilson.co.uk (cherry picked from commit 6dcb85a0) Signed-off-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
Merge tag 'gvt-next-fixes-2019-09-06' of https://github.com/intel/gvt-linux into drm-intel-next-fixes gvt-next-fixes-2019-09-06 - Fix guest context head pointer update for hang (Xiaolin) - Fix guest context ring state for reset (Weinan) Signed-off-by:
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
single etnaviv fix for an error path. Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
drm-next-5.4-2019-08-30: amdgpu: - Add DC support for Renoir - Add some GPUVM hw bug workarounds - add support for the smu11 i2c controller - GPU reset vram lost bug fixes - Navi1x powergating fixes - Navi12 power fixes - Renoir power fixes - Misc bug fixes and cleanups Signed-off-by:
-
Weinan Li authored
The guest may use this register to identify the running state of one context. Emulate it as the value in context image as if the context runs on the GPU hardware. Signed-off-by:
Weinan Li <weinan.z.li@intel.com> Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Xiaolin Zhang authored
when creating a vGPU workload, the guest context head pointer should be updated correctly by comparing with the exsiting workload in the guest worklod queue including the current running context. in some situation, there is a running context A and then received 2 new vGPU workload context B and A. in the new workload context A, it's head pointer should be updated with the running context A's tail. v2: walk through guest workload list in backward way. Cc: stable@vger.kernel.org Signed-off-by:
-
- 04 Sep, 2019 3 commits
-
-
Linus Walleij authored
There were bugs in the DSI transfer (read and write) function as it was only tested with displays ever needing a single byte to be written. Fixed it up and tested so we can now write messages of up to 16 bytes and read up to 4 bytes from the display. Tested with a Sony ACX424AKP display: this display now self- identifies and can control backlight in command mode. Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 5fc537bf ("drm/mcde: Add new driver for ST-Ericsson MCDE") Reviewed-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190903170804.17053-1-linus.walleij@linaro.org
-
Rob Clark authored
Looks like the dma_sync calls don't do what we want on armv7 either. Fixes: Unable to handle kernel paging request at virtual address 50001000 pgd = (ptrval) [50001000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae0 #4 Hardware name: Freescale i.MX53 (Device Tree Support) PC is at v7_dma_clean_range+0x20/0x38 LR is at __dma_page_cpu_to_dev+0x28/0x90 pc : [<c011c76c>] lr : [<c01181c4>] psr: 20000013 sp : d80b5a88 ip : de96c000 fp : d840ce6c r10: 00000000 r9 : 00000001 r8 : d843e010 r7 : 00000000 r6 : 00008000 r5 : ddb6c000 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 50008000 r0 : 50001000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 70004019 DAC: 00000051 Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) Signed-off-by:
Rob Clark <robdclark@chromium.org> Fixes: 3de433c5 ("drm/msm: Use the correct dma_sync calls in msm_gem") Tested-by:
Fabio Estevam <festevam@gmail.com>
-
Denis Efremov authored
"unlikely(WARN_ON(x))" is excessive. WARN_ON() already uses unlikely() internally. Signed-off-by:
Denis Efremov <efremov@linux.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Joe Perches <joe@perches.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
- 03 Sep, 2019 25 commits
-
-
Sean Paul authored
clk_get_parent returns an error pointer upon failure, not NULL. So the checks as they exist won't catch a failure. This patch changes the checks and the return values to properly handle an error pointer. Fixes: c4d8cfe5 ("drm/msm/dsi: add implementation for helper functions") Cc: Sibi Sankar <sibis@codeaurora.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Rob Clark <robdclark@chromium.org> Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Rob Clark authored
This was useful for debugging fps drops. I suspect it will be useful again. Signed-off-by:
Sean Paul <sean@poorly.run>
-
Rob Clark authored
In addition, moving to kms->flush_commit() lets us drop the only user of kms->commit(). Signed-off-by:
-
Rob Clark authored
Now that flush/wait/complete is decoupled from the "synchronous" part of atomic commit_tail(), add support to defer flush to a timer that expires shortly before vblank for async commits. In this way, multiple atomic commits (for example, cursor updates) can be coalesced into a single flush at the end of the frame. v2: don't hold lock over ->wait_flush(), to avoid locking interaction that was causing fps drop when combining page flips or non-async atomic commits and lots of legacy cursor updates Signed-off-by: -
Rob Clark authored
With atomic commit, ->prepare_commit() and ->complete_commit() may not be evenly balanced (although ->complete_commit() will complete each crtc that had been previously prepared). So these will no longer be a good place to enable/disable clocks needed for hw access. Signed-off-by:
-
Rob Clark authored
Add ->flush_commit(crtc_mask). Currently a no-op, but kms backends should migrate writing flush registers to this hook, so we can decouple pushing updates to hardware, and flushing the updates. Once we add async commit support, the hw updates will be pushed down to the hw synchronously, but flushing the updates will be deferred until as close to vblank as possible, so that multiple updates can be combined in a single frame. Signed-off-by:
-
Rob Clark authored
Prep work for async commits, in which case this will be called after we no longer have the atomic state object. This drops some wait_for_vblanks(), but those should be unnecessary, as we call this after waiting for flush to complete. Signed-off-by:
-
Rob Clark authored
First step in re-working the atomic related internal API to prepare for async updates pending.. ->wait_flush() is intended to block until there is no in-progress flush. A crtc_mask is used, rather than an atomic state object, as this will later be used for async flush after the atomic state is destroyed. This replaces ->wait_for_crtc_commit_done() v2: update for review comments Signed-off-by: -
Rob Clark authored
Previously the callback was called from whoever called wait_for_vblank(), but that isn't a great plan when wait_for_vblank() stops getting called, and results in frame_done_timer expiring. Signed-off-by:
-
Rob Clark authored
Just waiting for next vblank isn't ideal.. we should really be looking at the hw FLUSH register value to know if there is still an in-progress flush without stalling unnecessarily when there is no pending flush. Signed-off-by:
-
Rob Clark authored
It attempted to avoid fps drops in the presence of cursor updates. But it is racing, and can result in hw updates after flush before vblank, which leads to underruns. Signed-off-by:
-
Rob Clark authored
Signed-off-by: -
Rob Clark authored
I'm sure there is plenty more to remove.. this is just some of the ones I noticed. Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Jordan Crouse authored
Remove the default for CONFIG_DRM_MSM and let the user select the driver manually as one does. Additionally select QCOM_COMMAND_DB for ARCH_QCOM targets to make sure it doesn't get missed when we need it for a6xx targets. v2: Move from default 'm' to no default Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Rob Clark authored
The extra line-break in traces was annoying me. Signed-off-by:
-
Rob Clark authored
Previously, dpu_crtc_frame_event_work() would try to aquire all the modeset locks in order to check whether it can release bandwidth. (If we only have cmd-mode display, bandwidth can be released at frame-done time.) The problem with this is that it is also responsible for signalling frame_done_comp, which dpu_crtc_commit_kickoff() waits on if there is already a frame pending. This is called in the msm_atomic_commit_tail() path.. which means that for non-nonblock commits, at least some of the modeset locks are already held. Re-work this scheme to use a reference count to track our need to have clocks enabled. It is incremented for each atomic commit, and decremented in the corresponding frame-done. Additionally, any crtc used in video mode hold an extra reference while they are enabled. The net effect is that we can determine in frame-done whether it is safe to drop bandwidth without needing to aquire any modeset locks. Signed-off-by:
Sean Paul <sean@chromium.org> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct msm_gem_submit { ... struct { ... } bos[0]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace the following form: sizeof(*submit) + ((u64)nr_bos * sizeof(submit->bos[0])) with: struct_size(submit, bos, nr_bos) This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Jordan Crouse authored
Remove the homebrewed bulk clock get function and replace it with devm_clk_bulk_get_all(). Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Jeffrey Hugo authored
Creating the msm gem address space requires a reference to the dev where the iommu is located. The driver currently assumes this is the same as the platform device, which breaks when the iommu is outside of the platform device (ie in the parent). Default to using the platform device, but check to see if that has an iommu reference, and if not, use the parent device instead. This should handle all the various iommu designs for mdp5 supported systems. Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Tested-by:
-
Brian Masney authored
The following errors show up when booting the Nexus 5: msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR* dsi_phy_regulator_init: failed to init regulator, ret=-517 msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR* dsi_phy_driver_probe: failed to init regulator dsi_phy_regulator_init() already logs the error, so no need to log the same error a second time in dsi_phy_driver_probe(). This patch also changes dsi_phy_regulator_init() to not log the error if the error code is -EPROBE_DEFER to reduce noise in dmesg. Signed-off-by:
Brian Masney <masneyb@onstation.org> Reviewed-by:
-
Rob Clark authored
For platforms that require the "zap shader" to take the GPU out of secure mode at boot, we also need the zap fw to end up in the initrd. Signed-off-by:
-
Jeffrey Hugo authored
Add support for MDP5 version v3.0 found on msm8998. Signed-off-by:
-
Rob Clark authored
Unused and the extra rpm get/put interferes with handover from bootloader (ie. happens before we have a chance to check if things are already enabled). Signed-off-by:
-
Jeffrey Hugo authored
If booting a device using EFI, efifb will likely come up and claim the console. When the msm display stack finally comes up, we want the console to move over to the msm fb, so add support to kick out any firmware based framebuffers to accomplish the console transition. Suggested-by:
-
