summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2019-09-17drm/nouveau: Fix ordering between TTM and GEM releaseThierry Reding2-6/+8
When the last reference to a TTM BO is dropped, ttm_bo_release() will acquire the DMA reservation object's wound/wait mutex while trying to clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is therefore essential that drm_gem_object_release() be called after the TTM BO has been uninitialized, otherwise drm_gem_object_release() has already destroyed the wound/wait mutex (via dma_resv_fini()). Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau/prime: Extend DMA reservation object lockThierry Reding1-6/+14
Prior to commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object"), the reservation object was locked across all of the buffer object creation. After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and nouveau_bo_init() functions, the reservation object is passed to the latter, so the lock needs to be held across that function as well. Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau: Fix fallout from reservation object reworkThierry Reding4-13/+17
Commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") introduced a subtle change in how the buffer allocation size is handled. Prior to that change, the size would get aligned to at least a page, whereas after that change a non-page-aligned size would get passed through unmodified. This ultimately causes a BUG_ON() to trigger in drm_gem_private_object_init() and crashes the system. Fix this by restoring the code that align the allocation size. Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Reported-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-17drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectorsLyude Paul1-1/+2
On the ThinkPad P71, we have one eDP connector exposed along with 5 DP connectors, resulting in a total of 11 TMDS encoders. Since the GPU on this system is also capable of MST, we create an additional 4 fake MST encoders for each DP port. Unfortunately, we also do this for the eDP port as well, resulting in: 1 eDP port: +1 TMDS encoder +4 DPMST encoders 5 DP ports: +2 TMDS encoders +4 DPMST encoders *5 ports == 35 encoders Which breaks things, since DRM has a hard coded limit of 32 encoders. So, fix this by not creating MSTMs for any eDP connectors. This brings us down to 31 encoders, although we can do better. This fixes driver probing for nouveau on the ThinkPad P71. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-09-16Merge branch 'x86-vmware-for-linus' of ↵Linus Torvalds2-28/+28
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 vmware updates from Ingo Molnar: "This updates the VMWARE guest driver with support for VMCALL/VMMCALL based hypercalls" * 'x86-vmware-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: input/vmmouse: Update the backdoor call with support for new instructions drm/vmwgfx: Update the backdoor call with support for new instructions x86/vmware: Add a header file for hypercall definitions x86/vmware: Update platform detection code for VMCALL/VMMCALL hypercalls
2019-09-16Merge tag 'iommu-updates-v5.4' of ↵Linus Torvalds1-8/+16
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu updates from Joerg Roedel: - batched unmap support for the IOMMU-API - support for unlocked command queueing in the ARM-SMMU driver - rework the ATS support in the ARM-SMMU driver - more refactoring in the ARM-SMMU driver to support hardware implemention specific quirks and errata - bounce buffering DMA-API implementatation in the Intel VT-d driver for untrusted devices (like Thunderbolt devices) - fixes for runtime PM support in the OMAP iommu driver - MT8183 IOMMU support in the Mediatek IOMMU driver - rework of the way the IOMMU core sets the default domain type for groups. Changing the default domain type on x86 does not require two kernel parameters anymore. - more smaller fixes and cleanups * tag 'iommu-updates-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (113 commits) iommu/vt-d: Declare Broadwell igfx dmar support snafu iommu/vt-d: Add Scalable Mode fault information iommu/vt-d: Use bounce buffer for untrusted devices iommu/vt-d: Add trace events for device dma map/unmap iommu/vt-d: Don't switch off swiotlb if bounce page is used iommu/vt-d: Check whether device requires bounce buffer swiotlb: Split size parameter to map/unmap APIs iommu/omap: Mark pm functions __maybe_unused iommu/ipmmu-vmsa: Disable cache snoop transactions on R-Car Gen3 iommu/ipmmu-vmsa: Move IMTTBCR_SL0_TWOBIT_* to restore sort order iommu: Don't use sme_active() in generic code iommu/arm-smmu-v3: Fix build error without CONFIG_PCI_ATS iommu/qcom: Use struct_size() helper iommu: Remove wrong default domain comments iommu/dma: Fix for dereferencing before null checking iommu/mediatek: Clean up struct mtk_smi_iommu memory: mtk-smi: Get rid of need_larbid iommu/mediatek: Fix VLD_PA_RNG register backup when suspend memory: mtk-smi: Add bus_sel for mt8183 memory: mtk-smi: Invoke pm runtime_callback to enable clocks ...
2019-09-14Merge tag 'drm-fixes-2019-09-13' of git://anongit.freedesktop.org/drm/drmLinus Torvalds4-8/+11
Pull drm fixes from Dave Airlie: "From the maintainer summit, just some last minute fixes for final: lima: - fix gem_wait ioctl core: - constify modes list i915: - DP MST high color depth regression - GPU hangs on vulkan compute workloads" * tag 'drm-fixes-2019-09-13' of git://anongit.freedesktop.org/drm/drm: drm/lima: fix lima_gem_wait() return value drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+ drm/i915: Limit MST to <= 8bpc once again drm/modes: Make the whitelist more const
2019-09-13Revert "drm/bridge: adv7511: Attach to DSI host at probe time"Rob Clark1-9/+3
This reverts commit 83f35bc3a852f1c3892c7474998c5cec707c7ba3. There are at least two DSI controller drivers which relies on the old behaviour of adv7511 driver. To avoid platform breakage this patch should be reverted. This is a temporary solution, as it blocks adv7511 usage with other platforms. Assumption that DSI device driver (bridge/panel) should first expose drm_bridge/drm_panel object, then look for DSI bus is just incorrect - it can work with devices controlled via i2c but it cannot work with devices controlled via DSI - they will not be able to probe. To solve the issue following steps should be performed: - rework reverted patch allowing co-operation with broken DSI controller drivers - with simple/ugly workaround, - fix controller drivers and then remove workaround. Signed-off-by: Rob Clark <robdclark@chromium.org> [a.hajda: changed commit message] Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829180836.14453-1-robdclark@gmail.com
2019-09-12Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"Chris Wilson1-9/+1
The userptr put_pages can be called from inside try_to_unmap, and so enters with the page lock held on one of the object's backing pages. We cannot take the page lock ourselves for fear of recursion. Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reported-by: Martin Wilck <Martin.Wilck@suse.com> Reported-by: Leo Kraav <leho@kraav.com> Fixes: aa56a292ce62 ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-12Merge tag 'drm-misc-fixes-2019-09-12' of ↵Dave Airlie2-2/+2
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes drm-misc-fixes for v5.3 final: - Constify modes whitelist harder. - Fix lima driver gem_wait ioctl. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/99e52e7a-d4ce-6a2c-0501-bc559a710955@linux.intel.com
2019-09-11Merge branches 'arm/omap', 'arm/exynos', 'arm/smmu', 'arm/mediatek', ↵Joerg Roedel1-8/+16
'arm/qcom', 'arm/renesas', 'x86/amd', 'x86/vt-d' and 'core' into next
2019-09-10drm/lima: fix lima_gem_wait() return valueVasily Khoruzhick1-1/+1
drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME if it timeouts, but lima driver assumed that 0 is error. Cc: stable@vger.kernel.org Fixes: a1d2a6339961e ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190908024800.23229-1-anarsoul@gmail.com
2019-09-09drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+Chris Wilson1-5/+0
This bit was fliped on for "syncing dependencies between camera and graphics". BSpec has no recollection why, and it is causing unrecoverable GPU hangs with Vulkan compute workloads. From BSpec, setting bit5 to 0 enables relaxed padding requirements for buffers, 1D and 2D non-array, non-MSAA, non-mip-mapped linear surfaces; and *must* be set to 0h on skl+ to ensure "Out of Bounds" case is suppressed. Reported-by: Jason Ekstrand <jason@jlekstrand.net> Suggested-by: Jason Ekstrand <jason@jlekstrand.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998 Fixes: 8424171e135c ("drm/i915/gen9: h/w w/a: syncing dependencies between camera and graphics") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: denys.kostin@globallogic.com Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.1+ Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190904100707.7377-1-chris@chris-wilson.co.uk (cherry picked from commit 9d7b01e93526efe79dbf75b69cc5972b5a4f7b37) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-09-09drm/i915: Limit MST to <= 8bpc once againVille Syrjälä1-1/+9
My attempt at allowing MST to use the higher color depths has regressed some configurations. Apparently people have setups where all MST streams will fit into the DP link with 8bpc but won't fit with higher color depths. What we really should be doing is reducing the bpc for all the streams on the same link until they start to fit. But that requires a bit more work, so in the meantime let's revert back closer to the old behavior and limit MST to at most 8bpc. Cc: stable@vger.kernel.org Cc: Lyude Paul <lyude@redhat.com> Tested-by: Geoffrey Bennett <gmux22@gmail.com> Fixes: f1477219869c ("drm/i915: Remove the 8bpc shackles from DP MST") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111505 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828102059.2512-1-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com> (cherry picked from commit 75427b2a2bffc083d51dec389c235722a9c69b05) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-09-07drm/radeon: guard against calling an unpaired radeon_mn_unregister()Jason Gunthorpe1-0/+3
This check was accidently deleted in the below commit. There are cases where the driver will call unregister even though it hasn't registered anything. CPU 0 Unable to handle kernel paging request at virtual address 0000001c, epc == 808de6d4, ra == 804d32ec Call Trace: [<808de6d4>] mutex_lock+0x8/0x44 [<804d32ec>] radeon_mn_unregister+0x3c/0xb0 [<8041583c>] radeon_gem_object_free+0x18/0x2c [<803a451c>] drm_gem_object_release_handle+0x74/0xac [<803a45d0>] drm_gem_handle_delete+0x7c/0x128 [<803a5bf4>] drm_ioctl_kernel+0xb0/0x108 [<803a5e74>] drm_ioctl+0x200/0x3a8 [<803e07b4>] radeon_drm_ioctl+0x54/0xc0 [<801214dc>] do_vfs_ioctl+0x4e8/0x81c [<80121864>] ksys_ioctl+0x54/0xb0 [<8001100c>] syscall_common+0x34/0x58 Link: https://lore.kernel.org/r/2fc7ef14-e89a-1f2d-381d-1c9b05da02d3@gmail.com Fixes: 534e5f84b7a9 ("drm/radeon: use mmu_notifier_get/put for struct radeon_mn") Reported-by: Petr Cvek <petrcvekcz@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-06drm/i915: Use NOEVICT for first pass on attemping to pin a GGTT mmapChris Wilson1-1/+1
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: 6846895fde05 ("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 ebfdf5cd806b3bbf1ff79e69bce6a28df8bbe39d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-09-06drm/i915: to make vgpu ppgtt notificaiton as atomic operationXiaolin Zhang3-5/+9
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 <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1566543451-13955-1-git-send-email-xiaolin.zhang@intel.com (cherry picked from commit 52988009843160c5b366b4082ed6df48041c655c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-09-06drm/i915: Flush the existing fence before GGTT read/writeChris Wilson1-0/+8
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: 1f7fd484fff1 ("drm/i915: Replace i915_vma_put_fence()") 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/20190823153944.20630-1-chris@chris-wilson.co.uk (cherry picked from commit 636e83f2f208555c3d19d8b454ebdd8d8f4652cc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-09-06drm/i915: Hold irq-off for the entire fake lock periodChris Wilson5-29/+42
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: d67739268cf0 ("drm/i915/gt: Mark up the nested engine-pm timeline lock as irqsafe") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-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 6dcb85a0ad990455ae7c596e3fc966ad9c1ba9c5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-09-06Merge tag 'gvt-next-fixes-2019-09-06' of https://github.com/intel/gvt-linux ↵Rodrigo Vivi1-13/+32
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: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190906054255.GC3458@zhen-hp.sh.intel.com
2019-09-06drm/modes: Make the whitelist more constMaxime Ripard1-1/+1
The commit 3764137906a5 ("drm/modes: Introduce a whitelist for the named modes") introduced a whitelist in the named modes lookup code in order to be a bit more robust. However, even though the char pointers were made const, the array itself was not. Let's fix that. Fixes: 3764137906a5 ("drm/modes: Introduce a whitelist for the named modes") Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190906074614.30608-1-mripard@kernel.org
2019-09-06Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into ↵Dave Airlie1-1/+3
drm-next single etnaviv fix for an error path. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/4ae00cfb47c8e6fffca5dbb45ae9370cd4e5eaf4.camel@pengutronix.de
2019-09-06Merge tag 'drm-next-5.4-2019-08-30' of ↵Dave Airlie99-140/+91412
git://people.freedesktop.org/~agd5f/linux into drm-next 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: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190830212650.5055-1-alexander.deucher@amd.com
2019-09-06Merge tag 'drm-misc-fixes-2019-09-05' of ↵Dave Airlie4-9/+187
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes drm-misc-fixes for v5.3 final: - Make ingenic panel type DPI insteado f unknown. - Fixes for command line parser modes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/606d87b2-1840-c893-eb30-d6c471c9e50a@linux.intel.com
2019-09-06Merge branch 'vmwgfx-fixes-5.3' of ↵Dave Airlie1-5/+3
git://people.freedesktop.org/~thomash/linux into drm-fixes Single vmwgfx double free fix. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-09-06drm/i915/gvt: update RING_START reg of vGPU when the context is submitted to ↵Weinan Li1-0/+17
i915 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: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-09-06drm/i915/gvt: update vgpu workload head pointer correctlyXiaolin Zhang1-13/+15
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: Xiaolin Zhang <xiaolin.zhang@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-09-05drm/vmwgfx: Fix double free in vmw_recv_msg()Dan Carpenter1-5/+3
We recently added a kfree() after the end of the loop: if (retries == RETRIES) { kfree(reply); return -EINVAL; } There are two problems. First the test is wrong and because retries equals RETRIES if we succeed on the last iteration through the loop. Second if we fail on the last iteration through the loop then the kfree is a double free. When you're reading this code, please note the break statement at the end of the while loop. This patch changes the loop so that if it's not successful then "reply" is NULL and we can test for that afterward. Cc: <stable@vger.kernel.org> Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-09-04drm/mcde: Fix DSI transfersLinus Walleij1-23/+47
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: 5fc537bfd000 ("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
2019-09-04drm/msm: Use the correct dma_sync calls harderRob Clark1-2/+2
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-g9f159ae07f07 #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: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem") Tested-by: Fabio Estevam <festevam@gmail.com>
2019-09-04drm/msm: remove unlikely() from WARN_ON() conditionsDenis Efremov2-3/+3
"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: Rob Clark <robdclark@chromium.org>
2019-09-04kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)Masahiro Yamada5-19/+15
Kbuild provides per-file compiler flag addition/removal: CFLAGS_<basetarget>.o CFLAGS_REMOVE_<basetarget>.o AFLAGS_<basetarget>.o AFLAGS_REMOVE_<basetarget>.o CPPFLAGS_<basetarget>.lds HOSTCFLAGS_<basetarget>.o HOSTCXXFLAGS_<basetarget>.o The <basetarget> is the filename of the target with its directory and suffix stripped. This syntax comes into a trouble when two files with the same basename appear in one Makefile, for example: obj-y += foo.o obj-y += dir/foo.o CFLAGS_foo.o := <some-flags> Here, the <some-flags> applies to both foo.o and dir/foo.o The real world problem is: scripts/kconfig/util.c scripts/kconfig/lxdialog/util.c Both files are compiled into scripts/kconfig/mconf, but only the latter should be given with the ncurses flags. It is more sensible to use the relative path to the Makefile, like this: obj-y += foo.o CFLAGS_foo.o := <some-flags> obj-y += dir/foo.o CFLAGS_dir/foo.o := <other-flags> At first, I attempted to replace $(basetarget) with $*. The $* variable is replaced with the stem ('%') part in a pattern rule. This works with most of cases, but does not for explicit rules. For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own explicit rules, so $* will be empty, resulting in ignoring the per-file AFLAGS. I introduced a new variable, target-stem, which can be used also from explicit rules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Marc Zyngier <maz@kernel.org>
2019-09-04dma-mapping: remove dma_{alloc,free,mmap}_writecombineChristoph Hellwig1-6/+5
We can already use DMA_ATTR_WRITE_COMBINE or the _wc prefixed version, so remove the third way of doing things. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-09-03drm/msm/dsi: Fix return value check for clk_get_parentSean Paul1-4/+4
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: c4d8cfe516dc ("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 <robdclark@chromium.org>
2019-09-03drm/msm: add atomic tracesRob Clark5-4/+136
This was useful for debugging fps drops. I suspect it will be useful again. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run>
2019-09-03drm/msm/dpu: async commit supportRob Clark6-45/+34
In addition, moving to kms->flush_commit() lets us drop the only user of kms->commit(). Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run>
2019-09-03drm/msm: async commit supportRob Clark4-1/+210
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run>
2019-09-03drm/msm: split power control from prepare/complete_commitRob Clark5-14/+54
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run>
2019-09-03drm/msm: add kms->flush_commit()Rob Clark5-4/+63
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run>
2019-09-03drm/msm: convert kms->complete_commit() to crtc_maskRob Clark7-36/+11
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run>
2019-09-03drm/msm: add kms->wait_flush()Rob Clark5-42/+54
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 <robdclark@chromium.org>
2019-09-03drm/msm/dpu: handle_frame_done() from vblank irqRob Clark2-23/+9
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm/dpu: add real wait_for_commit_done()Rob Clark1-1/+21
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm/dpu: unwind async commit handlingRob Clark6-57/+37
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 <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm/dpu: remove unused argRob Clark3-4/+3
Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm/dpu: remove some impossible error checkingRob Clark6-45/+0
I'm sure there is plenty more to remove.. this is just some of the ones I noticed. Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm/dpu: add rotation propertyRob Clark1-0/+20
Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm: Remove Kconfig defaultJordan Crouse1-1/+1
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 <robdclark@chromium.org>
2019-09-03drm/msm/dpu: remove stray "\n"Rob Clark1-1/+1
The extra line-break in traces was annoying me. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-09-03drm/msm/dpu: fix "frame done" timeoutsRob Clark4-33/+38
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: Rob Clark <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-30 08:49:42 +0000