summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2020-01-02msm:disp:dpu1: add mixer selection for display topologyKalyan Thota
mixer selection in the display topology is based on multiple factors 1) mixers available in the hw 2) interfaces to be enabled 3) merge capability change will pickup mixer as per the topology need. Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02msm:disp:dpu1: setup display datapath for SC7180 targetKalyan Thota
Add changes to setup display datapath on SC7180 target. Changes in v1: - Add changes to support ctl_active on SC7180 target. - While selecting the number of mixers in the topology consider the interface width. Changes in v2: - Spawn topology mixer selection into separate patch (Rob Clark). - Add co-developed-by tags in the commit msg (Stephen Boyd). Changes in v3: - Fix kernel checkpatch errors in v2. This patch has dependency on the below series https://patchwork.kernel.org/patch/11253747/ Co-developed-by: Shubhashree Dhar <dhar@codeaurora.org> Signed-off-by: Shubhashree Dhar <dhar@codeaurora.org> Co-developed-by: Raviteja Tamatam <travitej@codeaurora.org> Signed-off-by: Raviteja Tamatam <travitej@codeaurora.org> Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02msm:disp:dpu1: add support for display for SC7180 targetKalyan Thota
Add display hw catalog changes for SC7180 target. Changes in v1: - Configure register offsets and capabilities for the display hw blocks. Changes in v2: - mdss_irq data type has changed in the dependent patch, accommodate the necessary changes. - Add co-developed-by tags in the commit msg (Stephen Boyd). Changes in v3: - fix kernel checkpatch errors in v2 Changes in v4: - move documentation into seperate patch (Rob Herring). This patch has dependency on the below series https://patchwork.kernel.org/patch/11253647/ Co-developed-by: Shubhashree Dhar <dhar@codeaurora.org> Signed-off-by: Shubhashree Dhar <dhar@codeaurora.org> Co-developed-by: Raviteja Tamatam <travitej@codeaurora.org> Signed-off-by: Raviteja Tamatam <travitej@codeaurora.org> Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> [rebase on hw catalog const'ification, and add more const's] Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02msm: disp: dpu1: add support to access hw irqs regs depending on revisionShubhashree Dhar
Current code assumes that all the irqs registers offsets can be accessed in all the hw revisions; this is not the case for some targets that should not access some of the irq registers. This change adds the support to selectively remove the irqs that are not supported in some of the hw revisions. Changes in v1: - Add support to selectively remove the hw irqs that are not not supported. Changes in v2: - Remove unrelated changes. Changes in v3: - Remove change-id (Stephen Boyd). - Add colon in variable description to match kernel-doc (Stephen Boyd). - Change macro-y way of variable description (Jordon Crouse). - Remove unnecessary if checks (Jordon Crouse). - Remove extra blank line (Jordon Crouse). Changes in v4: - Remove checkpatch errors. Signed-off-by: Shubhashree Dhar <dhar@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/dpu: Add UBWC support for RGB8888 formatsFritz Koenig
Hardware only natively supports BGR8888 UBWC. UBWC support for RGB8888 can be had by pretending that the buffer is BGR. Signed-off-by: Fritz Koenig <frkoenig@google.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/dpu: Mark various data tables as constStephen Boyd
These structures look like a bunch of data tables that aren't going to change after boot. Let's move them to the const RO section of memory so that they can't be modified at runtime on modern machines. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/a4xx: set interconnect bandwidth voteBrian Masney
Set the two interconnect paths for the GPU to maximum speed for now to work towards getting the GPU working upstream. We can revisit a later time to optimize this for battery life. Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/a3xx: set interconnect bandwidth voteBrian Masney
Set the two interconnect paths for the GPU to maximum speed for now to work towards getting the GPU working upstream. We can revisit a later time to optimize this for battery life. Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/gpu: add support for ocmem interconnect pathBrian Masney
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core and must use the On Chip MEMory (OCMEM) in order to be functional. There's a separate interconnect path that needs to be setup to OCMEM. Add support for this second path to the GPU core. In the downstream MSM 3.4 sources, the two interconnect paths for the GPU are between: - MSM_BUS_MASTER_GRAPHICS_3D and MSM_BUS_SLAVE_EBI_CH0 - MSM_BUS_MASTER_V_OCMEM_GFX3D and MSM_BUS_SLAVE_OCMEM Signed-off-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/adreno: fix zap vs no-zap handlingRob Clark
We can have two cases, when it comes to "zap" fw. Either the fw requires zap fw to take the GPU out of secure mode at boot, or it does not and we can write RBBM_SECVID_TRUST_CNTL directly. Previously we decided based on whether zap fw load succeeded, but this is not a great plan because: 1) we could have zap fw in the filesystem on a device where it is not required 2) we could have the inverse case Instead, shift to deciding based on whether we have a 'zap-shader' node in dt. In practice, there is only one device (currently) with upstream dt that does not use zap (cheza), and it already has a /delete-node/ for the zap-shader node. Fixes: abccb9fe3267 ("drm/msm/a6xx: Add zap shader load") Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-01-02drm/msm/a6xx: restore previous freq on resumeRob Clark
Previously, if the freq were overriden (ie. via sysfs), it would get reset to max on resume. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
2020-01-02drm/msm/dpu: ignore NULL clocksRob Clark
This isn't an error. Also the clk APIs handle the NULL case, so we can just delete the check. Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Stephen Boyd <sboyd@kernel.org>
2019-12-23drm/i915: Hold reference to intel_frontbuffer as we track activityChris Wilson
Since obj->frontbuffer is no longer protected by the struct_mutex, as we are processing the execbuf, it may be removed. Mark the intel_frontbuffer as rcu protected, and so acquire a reference to the struct as we track activity upon it. Closes: https://gitlab.freedesktop.org/drm/intel/issues/827 Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218104043.3539458-1-chris@chris-wilson.co.uk (cherry picked from commit da42104f589d979bbe402703fd836cec60befae1) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-12-23drm/i915/gt: Ratelimit display power w/aChris Wilson
For very light workloads that frequently park, acquiring the display power well (required to prevent the dmc from trashing the system) takes longer than the execution. A good example is the igt_coherency selftest, which is slowed down by an order of magnitude in the worst case with powerwell cycling. To prevent frequent cycling, while keeping our fast soft-rc6, use a timer to delay release of the display powerwell. Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles") References: https://gitlab.freedesktop.org/drm/intel/issues/848 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218093504.3477048-1-chris@chris-wilson.co.uk (cherry picked from commit 81ff52b705775433a955b2746d37b87bdc89a3d0) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-12-23drm/i915/pmu: Ensure monotonic rc6Tvrtko Ursulin
Avoid rc6 counter going backward in close to 0% RC6 scenarios like: 15.005477996 114,246,613 ns i915/rc6-residency/ 16.005876662 667,657 ns i915/rc6-residency/ 17.006131417 7,286 ns i915/rc6-residency/ 18.006615031 18,446,744,073,708,914,688 ns i915/rc6-residency/ 19.007158361 18,446,744,073,709,447,168 ns i915/rc6-residency/ 20.007806498 0 ns i915/rc6-residency/ 21.008227495 1,440,403 ns i915/rc6-residency/ There are two aspects to this fix. First is not assuming rc6 value zero means GT is asleep since that can also mean GPU is fully busy and we do not want to enter the estimation path in that case. Second is ensuring monotonicity on the estimation path itself. I suspect what is happening is with extremely rapid park/unpark cycles we get no updates on the real rc6 and therefore have to careful not to unconditionally trust use last known real rc6 when creating a new estimation. v2: * Simplify logic by not tracking the estimate but last reported value. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 16ffe73c186b ("drm/i915/pmu: Use GT parked for estimating RC6 while asleep") Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191217142057.1000-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit df6a42053513846475ae1fbd224dfbdbcd0c7010) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-12-21Merge tag 'drm-intel-fixes-2019-12-19' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix to drop an unused and harmful display W/A - Fix to define EHL power wells independent of ICL - Fix for priority inversion on bonded requests - Fix in mmio offset calculation of DSB instance - Fix memory leak from get_task_pid when banning clients - Fixes to avoid dereference of uninitialized ops in dma_fence tracing and keep reference to execbuf object until submitted. - Includes gvt-fixes-2019-12-18 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191219124635.GA16068@jlahtine-desk.ger.corp.intel.com
2019-12-19drm/exynos: gsc: add missed component_delChuhong Yuan
The driver forgets to call component_del in remove to match component_add in probe. Add the missed call to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.net>
2019-12-18Merge tag 'gvt-fixes-2019-12-18' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen
drm-intel-fixes gvt-fixes-2019-12-18 - vGPU state setting locking fix (Zhenyu) - Fix vGPU display dmabuf as read-only (Zhenyu) - Properly handle vGPU display dmabuf page pin when rendering (Tina) - Fix one guest boot warning to handle guc reset state (Fred) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218051657.GA21662@zhen-hp.sh.intel.com
2019-12-18drm/i915: Fix pid leak with banned clientsTvrtko Ursulin
Get_pid_task() needs to be paired with a put_pid or we leak a pid reference every time a banned client tries to create a context. v2: * task_pid_nr helper exists! (Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-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/20191217170933.8108-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit ba16a48af797db124ac100417f9229b1650ce1fb) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-18drm/i915/gem: Keep request alive while attaching fencesChris Wilson
Since commit e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex"), the request retirement can happen outside of the struct_mutex serialised only by the timeline->mutex. We drop the timeline->mutex on submitting the request (i915_request_add) so after that point, it is liable to be freed. Make sure our local reference is kept alive until we have finished attaching it to the signalers. (Note that this erodes the argument that i915_request_add should consume the reference, but that is a slightly larger patch!) Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with timeline->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217134729.3297818-1-chris@chris-wilson.co.uk (cherry picked from commit e14177f19739d74839eb496a27f5f5d958beaa5b) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-17drm/i915: Fix WARN_ON condition for cursor plane ddb allocationVandita Kulkarni
In some cases like latency[level]==0, wm[level].res_lines>31, min_ddb_alloc can be U16_MAX, exclude it from the WARN_ON. v2: Specify the cases in which we hit U16_MAX, indentation (Ville) Fixes: 10a7e07b68b9 ("drm/i915: Make sure cursor has enough ddb for the selected wm level") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216080619.10945-1-vandita.kulkarni@intel.com (cherry picked from commit 4ba487019d1a196051feefab57f4a393815733b4) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-17drm/i915/gvt: Fix guest boot warningGao Fred
Simulate MIA core in reset status once GUC engine is reset. v2: 1. use vgpu_vreg_t() function, 2. clear MIA_IN_RESET after reading. (Zhenyu) v3: add comments. (Zhenyu) Signed-off-by: Gao Fred <fred.gao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191216160255.29499-1-fred.gao@intel.com
2019-12-16drm/i915/tgl: Drop Wa#1178Matt Roper
The TGL workaround database no longer shows Wa #1178 (or anything similar under different workaround names/numbers) so we should be able to drop it. In fact Swati just discovered that applying this workaround is the root cause of some power well enable failures we've been seeing in CI (gitlab issue 498). Once we stop applying this WA, TGL no longer utilizes any of the special handling provided by icl_combo_phy_aux_power_well_ops so we can just drop back to using the standard hsw-style power well ops instead. v3: Drop now-unused _TGL_AUX_ANAOVRD1_C definition too. (Lucas) Closes: https://gitlab.freedesktop.org/drm/intel/issues/498 Fixes: deea06b47574 ("drm/i915/tgl: apply Display WA #1178 to fix type C dongles") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213001511.678070-3-matthew.d.roper@intel.com (cherry picked from commit ab3402581d0fa58e63e36875995f43ab02b4d0a0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915/ehl: Define EHL powerwells independently of ICLMatt Roper
Outputs C and D on EHL are combo PHY outputs and thus should not be using the same TC AUX power well handlers as ICL. And even though icl_combo_phy_aux_power_well_ops works okay for EHL/JSL combo PHYs none of its special handling is actually necessary for this platform: * EHL/JSL don't actually need to program PORT_CL_DW12 * Display WA #1178 does not apply to EHL/JSL Thus we can simply drop back to using our standard "hsw-style" power well ops for EHL AUX power wells. Bspec: 4301 Fixes: f722b8c1e2a2 ("drm/i915/ehl: All EHL ports are combo phys") Cc: Jose Souza <jose.souza@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213001511.678070-2-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit e8ab8d669d046a8e9b07707d2f00b9ba3e25d0ae) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915: Set fence_work.ops before dma_fence_initChris Wilson
Since dma_fence_init may call ops (because of a meaningless trace_dma_fence), we need to set the worker ops prior to that call. Reported-by: Vince Weaver <vincent.weaver@maine.edu> Fixes: 8e458fe2ee05 ("drm/i915: Generalise the clflush dma-worker") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Vince Weaver <vincent.weaver@maine.edu> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191212154224.1631531-1-chris@chris-wilson.co.uk (cherry picked from commit 1bc9865d8df3e1c6857a27c4b2b8a9ce8f027349) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915: Copy across scheduler behaviour flags across submit fencesChris Wilson
We want the bonded request to have the same scheduler properties as its master so that it is placed at the same depth in the queue. For example, consider we have requests A, B and B', where B & B' are a bonded pair to run in parallel on two engines. A -> B \- B' B will run after A and so may be scheduled on an idle engine and wait on A using a semaphore. B' sees B being executed and so enters the queue on the same engine as A. As B' did not inherit the semaphore-chain from B, it may have higher precedence than A and so preempts execution. However, B' then sits on a semaphore waiting for B, who is waiting for A, who is blocked by B. Ergo B' needs to inherit the scheduler properties from B (i.e. the semaphore chain) so that it is scheduled with the same priority as B and will not be executed ahead of Bs dependencies. Furthermore, to prevent the priorities changing via the expose fence on B', we need to couple in the dependencies for PI. This requires us to relax our sanity-checks that dependencies are strictly in order. v2: Synchronise (B, B') execution on all platforms, regardless of using a scheduler, any no-op syncs should be elided. Fixes: ee1136908e9b ("drm/i915/execlists: Virtual engine bonding") Closes: https://gitlab.freedesktop.org/drm/intel/issues/464 Testcase: igt/gem_exec_balancer/bonded-chain Testcase: igt/gem_exec_balancer/bonded-semaphore Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210151332.3902215-1-chris@chris-wilson.co.uk (cherry picked from commit c81471f5e95c79c55687282ff6800f112b5d560b) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-16drm/i915/dsb: Fix in mmio offset calculation of DSB instanceAnimesh Manna
As the current usage is restricted to first DSB instance per pipe, so existing code could not catch the issue to calculate the mmio offset of different DSB instance per pipe. Corrected the offset calculation. Fixes: a6e58d9a2e04 ("drm/i915/dsb: Check DSB engine status.") Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205123513.22603-1-animesh.manna@intel.com (cherry picked from commit d04a661a2c7169b48782aa5e9d85d4b4383d562e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-13Merge tag 'drm-fixes-5.5-2019-12-12' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-fixes drm-fixes-5.5-2019-12-12: amdgpu: - DC fixes for renoir - Gfx8 fence flush align with mesa - Power profile fix for arcturus - Freesync fix - DC I2c over aux fix - DC aux defer fix - GPU reset fix - GPUVM invalidation semaphore fixes for PCO and SR-IOV - Golden settings updates for gfx10 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191212223211.8034-1-alexander.deucher@amd.com
2019-12-13Merge tag 'drm-intel-fixes-2019-12-12' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix user reported issue #673: GPU hang on transition to idle - Avoid corruption on the top of the screen on GLK+ by disabling FBC - Fix non-privileged access to OA on Tigerlake - Fix HDCP code not to touch global state when just computing commit - Fix CI splat by saving irqstate around virtual_context_destroy - Serialise context retirement possibly on another CPU Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191212100759.GA22260@jlahtine-desk.ger.corp.intel.com
2019-12-13Merge tag 'drm-misc-next-fixes-2019-12-12' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes -mgag200: more startadd mitigation (Thomas) -panfrost: devfreq fix + several memory fixes (Steven, Boris) Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20191212140145.GA145200@art_vandelay
2019-12-13drm/i915/gvt: Pin vgpu dma address before usingTina Zhang
Dma-buf display uses the vgpu dma address saved in the guest part GGTT table which is updated by vCPU thread. In host side, when the dma address is used by qemu ui thread, gvt-g must make sure the dma address is validated before letting it go to the HW. Invalid guest dma address will easily cause DMA fault and make GPU hang. v2: Rebase Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191212141342.3417-1-tina.zhang@intel.com
2019-12-13drm/i915/gvt: set guest display buffer as readonlyZhenyu Wang
We shouldn't allow write for exposed guest display buffer which doesn't make sense. So explicitly set read only flag for display dmabuf allocated object. Fixes: e546e281d33d ("drm/i915/gvt: Dmabuf support for GVT-g") Cc: Tina Zhang <tina.zhang@intel.com> Acked-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191212084614.1100-1-zhenyuw@linux.intel.com
2019-12-12drm/amdgpu: add invalidate semaphore limit for SRIOV in gmc10changzhu
It may fail to load guest driver in round 2 when using invalidate semaphore for SRIOV. So it needs to avoid using invalidate semaphore for SRIOV. Signed-off-by: changzhu <Changfeng.Zhu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-12drm/amdgpu: add invalidate semaphore limit for SRIOV and picasso in gmc9changzhu
It may fail to load guest driver in round 2 or cause Xstart problem when using invalidate semaphore for SRIOV or picasso. So it needs avoid using invalidate semaphore for SRIOV and picasso. Signed-off-by: changzhu <Changfeng.Zhu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-12drm/amdgpu: avoid using invalidate semaphore for picassochangzhu
It may cause timeout waiting for sem acquire in VM flush when using invalidate semaphore for picasso. So it needs to avoid using invalidate semaphore for piasso. Signed-off-by: changzhu <Changfeng.Zhu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-12Revert "drm/amdgpu: dont schedule jobs while in reset"Alex Deucher
This reverts commit f2efc6e60089c99c342a6b7da47f1037e06c4296. This was fixed properly for 5.5, but came back via 5.4 merge into drm-next, so revert it again. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-12Merge branch 'linux-5.5' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
Bunch of random nouveau fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv56Am90okV334eXgxDuK228sb9UJxMiOYjNAMShvvv4cg@mail.gmail.com
2019-12-12Merge tag 'drm-misc-fixes-2019-12-11' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes - Expand dma-buf MAINTAINER scope - Fix mode matching for drivers not using picture_aspect_ratio Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20191211212107.GA257983@art_vandelay
2019-12-11drm/amdgpu: fix license on Kconfig and MakefilesAlex Deucher
amdgpu is MIT licensed. Fixes: ec8f24b7faaf3d ("treewide: Add SPDX license identifier - Makefile/Kconfig") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-11drm/amdgpu/gfx10: update gfx golden settings for navi14Tianci.Yin
add registers: mmPA_SC_BINNER_TIMEOUT_COUNTER and mmPA_SC_ENHANCE_2 Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-11drm/amdgpu/gfx10: update gfx golden settingsTianci.Yin
add registers: mmPA_SC_BINNER_TIMEOUT_COUNTER and mmPA_SC_ENHANCE_2 Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-11drm/amdgpu/gfx10: update gfx golden settings for navi14Tianci.Yin
add registers: mmSPI_CONFIG_CNTL Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-11drm/amdgpu/gfx10: update gfx golden settingsTianci.Yin
add registers: mmSPI_CONFIG_CNTL Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-11drm/i915: Serialise with remote retirementChris Wilson
Since retirement may be running in a worker on another CPU, it may be skipped in the local intel_gt_wait_for_idle(). To ensure the state is consistent for our sanity checks upon load, serialise with the remote retirer by waiting on the timeline->mutex. Outside of this use case, e.g. on suspend or module unload, we expect the slack to be picked up by intel_gt_pm_wait_for_idle() and so prefer to put the special case serialisation with retirement in its single user, for now at least. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191121071044.97798-2-chris@chris-wilson.co.uk (cherry picked from commit 2d0fb251360ab7eccbffd99f6933a2a4de678d52) Fixes: 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree") Closes: https://gitlab.freedesktop.org/drm/intel/issues/754 Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-12-11drm/i915/gvt: use vgpu lock for active state settingZhenyu Wang
Need to align with deactivate, should only use vgpu's lock for active state setting instead of gvt lock. Fixes: f25a49ab8ab9 ("drm/i915/gvt: Use vgpu_lock to protect per vgpu access") Cc: Colin Xu <colin.xu@intel.com> Reviewed-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20191202070109.73924-2-zhenyuw@linux.intel.com
2019-12-10drm/amd/display: include linux/slab.h where neededArnd Bergmann
Calling kzalloc() and related functions requires the linux/slab.h header to be included: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function 'dcn21_ipp_create': drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:679:3: error: implicit declaration of function 'kzalloc'; did you mean 'd_alloc'? [-Werror=implicit-function-declaration] kzalloc(sizeof(struct dcn10_ipp), GFP_KERNEL); A lot of other headers also miss a direct include in this file, but this is the only one that causes a problem for now. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-10drm/amd/display: fix undefined struct member referenceArnd Bergmann
An initialization was added for two optional struct members. One of these is always present in the dcn20_resource file, but the other one depends on CONFIG_DRM_AMD_DC_DSC_SUPPORT and causes a build failure if that is missing: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:926:14: error: excess elements in struct initializer [-Werror] .num_dsc = 5, Add another #ifdef around the assignment. Fixes: c3d03c5a196f ("drm/amd/display: Include num_vmid and num_dsc within NV14's resource caps") Reviewed-by: Zhan Liu <zhan.liu@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-12-10drm/nouveau/kms/nv50-: fix panel scalingBen Skeggs
Under certain circumstances, encoder atomic_check() can be entered without adjusted_mode having been reset to the same as mode, which confuses the scaling logic and can lead to a misprogrammed display. Fix this by checking against the user-provided mode directly. Link: https://bugs.freedesktop.org/show_bug.cgi?id=108615 Link: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/464 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-12-10drm/nouveau/kms/nv50-: Limit MST BPC to 8Lyude Paul
Noticed this while working on some unrelated CRC stuff. Currently, userspace has very little support for BPCs higher than 8. While this doesn't matter for most things, on MST topologies we need to be careful about ensuring that we do our best to make any given display configuration fit within the bandwidth restraints of the topology, since otherwise less people's monitor configurations will work. Allowing for BPC settings higher than 8 dramatically increases the required bandwidth for displays in most configurations, and consequently makes it a lot less likely that said display configurations will pass the atomic check. In the future we want to fix this correctly by making it so that we adjust the bpp for each display in a topology to be as high as possible, while making sure to lower the bpp of each display in the event that we run out of bandwidth and need to rerun our atomic check. But for now, follow the behavior that both i915 and amdgpu are sticking to. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: <stable@vger.kernel.org> # v5.1+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-12-10drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atomLyude Paul
In order to be able to use bpc values that are different from what the connector reports, we want to be able to store the bpc value we decide on using for an atomic state in nv50_head_atom and refer to that instead of simply using the value that the connector reports throughout the whole atomic check phase and commit phase. This will let us (eventually) implement the max bpc connector property, and will also be needed for limiting the bpc we use on MST displays to 8 in the next commit. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: <stable@vger.kernel.org> # v5.1+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-21 23:55:52 +0000