summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2019-10-09drm/i915: Only enqueue already completed requestsChris Wilson
If we are asked to submit a completed request, just move it onto the active-list without modifying it's payload. If we try to emit the modified payload of a completed request, we risk racing with the ring->head update during retirement which may advance the head past our breadcrumb and so we generate a warning for the emission being behind the RING_HEAD. v2: Commentary for the sneaky, shared responsibility between functions. v3: Spelling mistakes and bonus assertion 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/20190923110056.15176-3-chris@chris-wilson.co.uk (cherry picked from commit c0bb487dc19fc45dbeede7dcf8f513df51a3cd33) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-09drm/i915/execlists: Drop redundant list_del_init(&rq->sched.link)Chris Wilson
Since amalgamating the queued and active lists in commit 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list"), performing a i915_request_submit() will remove the request from the execlists priority queue. References: 422d7df4f090 ("drm/i915: Replace engine->timeline with a plain list") 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/20190923110056.15176-2-chris@chris-wilson.co.uk (cherry picked from commit 3231f8c01121ee1febfd82398ee22f7ff9dc5d76) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-09drm/i915/cml: Add second PCH ID for CMPMatt Roper
The CMP PCH ID we have in the driver is correct for the CML-U machines we have in our CI system, but the CML-S and CML-H CI machines appear to use a different PCH ID, leading our driver to detect no PCH for them. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461 Signed-off-by: Matt Roper <matthew.d.roper@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/20190916233251.387-1-matthew.d.roper@intel.com Fixes: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake PCH") (cherry picked from commit 8698ba53cd7173c32320ebbef4d389d41ebb5780) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-09drm/rockchip: Round up _before_ giving to the clock frameworkDouglas Anderson
I'm embarassed to say that even though I've touched vop_crtc_mode_fixup() twice and I swear I tested it, there's still a stupid glaring bug in it. Specifically, on veyron_minnie (with all the latest display timings) we want to be setting our pixel clock to 66,666,666.67 Hz and we tell userspace that's what we set, but we're actually choosing 66,000,000 Hz. This is confirmed by looking at the clock tree. The problem is that in drm_display_mode_from_videomode() we convert from Hz to kHz with: dmode->clock = vm->pixelclock / 1000; ...and drm_display_mode_from_videomode() is called from panel-simple when we have an "override_mode" like we do on veyron_minnie. See commit 123643e5c40a ("ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings"). ...so when the device tree specifies a clock of 66666667 for the panel then DRM translates that to 66666000. The clock framework will always pick a clock that is _lower_ than the one requested, so it will refuse to pick 66666667 and we'll end up at 66000000. While we could try to fix drm_display_mode_from_videomode() to round to the nearest kHz and it would fix our problem, it wouldn't help if the clock we actually needed was 60,000,001 Hz. We could alternatively have DRM always round up, but maybe this would break someone else who already baked in the assumption that DRM rounds down. Specifically note that clock drivers are not consistent about whether they round up or round down when you call clk_set_rate(). We know how Rockchip's clock driver works, but (for instance) you can see that on most Qualcomm clocks the default is clk_rcg2_ops which rounds up. Let's solve this by just adding 999 Hz before calling clk_round_rate(). This should be safe and work everywhere. As discussed in more detail in comments in the commit, Rockchip's PLLs are configured in a way that there shouldn't be another PLL setting that is only a few kHz off so we won't get mixed up. NOTE: if this is picked to stable, it's probably easiest to first pick commit 527e4ca3b6d1 ("drm/rockchip: Base adjustments of the mode based on prev adjustments") which shouldn't hurt in stable. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191003114726.v2.1.Ib233b3e706cf6317858384264d5b0ed35657456e@changeid
2019-10-09drm/i915/gt: execlists->active is serialised by the taskletChris Wilson
The active/pending execlists is no longer protected by the engine->active.lock, but is serialised by the tasklet instead. Update the locking around the debug and stats to follow suit. v2: local_bh_disable() to prevent recursing into the tasklet in case we trigger a softirq (Tvrtko) Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009160906.16195-1-chris@chris-wilson.co.uk
2019-10-09drm/i915/execlists: Protect peeking at execlists->activeChris Wilson
Now that we dropped the engine->active.lock serialisation from around process_csb(), direct submission can run concurrently to the interrupt handler. As such execlists->active may be advanced as we dequeue, dropping the reference to the request. We need to employ our RCU request protection to ensure that the request is not freed too early. Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009100955.21477-1-chris@chris-wilson.co.uk
2019-10-09drm/panfrost: Remove commented out call to panfrost_core_dumpSteven Price
panfrost_core_dump() has never existed in mainline, so remove it and add a TODO entry that core dump support is currently lacking. Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191009094456.9704-2-steven.price@arm.com
2019-10-09drm/panfrost: Handle resetting on timeout betterSteven Price
Panfrost uses multiple schedulers (one for each slot, so 2 in reality), and on a timeout has to stop all the schedulers to safely perform a reset. However more than one scheduler can trigger a timeout at the same time. This race condition results in jobs being freed while they are still in use. When stopping other slots use cancel_delayed_work_sync() to ensure that any timeout started for that slot has completed. Also use mutex_trylock() to obtain reset_lock. This means that only one thread attempts the reset, the other threads will simply complete without doing anything (the first thread will wait for this in the call to cancel_delayed_work_sync()). While we're here and since the function is already dependent on sched_job not being NULL, let's remove the unnecessary checks. Fixes: aa20236784ab ("drm/panfrost: Prevent concurrent resets") Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191009094456.9704-1-steven.price@arm.com
2019-10-09drm/panfrost: Remove NULL check for regulatorSteven Price
devm_regulator_get() is used to populate pfdev->regulator which ensures that this cannot be NULL (a dummy regulator will be returned if necessary). So remove the check in panfrost_devfreq_target(). Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191004144413.42586-1-steven.price@arm.com
2019-10-09drm: two planes with the same zpos have undefined orderingSimon Ser
Currently the property docs don't specify whether it's okay for two planes to have the same zpos value and what user-space should expect in this case. The unspoken, legacy rule used in the past was to make user-space figure out the zpos from object IDs. However some drivers break this rule, that's why the ordering is documented as unspecified in case the zpos property is missing. User-space should rely on the zpos property only. There are some cases in which user-space might read identical zpos values for different planes. For instance, in case the property is mutable, user-space might set two planes' zpos to the same value. This is necessary to support user-space using the legacy DRM API where atomic commits are not possible: user-space needs to update the planes' zpos one by one. Because of this, user-space should handle multiple planes with the same zpos. While at it, remove the assumption that zpos is only for overlay planes. Additionally, update the drm_plane_state.zpos docs to clarify that zpos disambiguation via plane object IDs is a recommendation for drivers, not something user-space can rely on. In other words, when user-space sets the same zpos on two planes, drivers should rely on the plane object ID. v2: clarify drm_plane_state.zpos docs (Daniel) v3: zpos is for all planes (Marius, Daniel) v4: completely reword the drm_plane_state.zpos docs to make it clear the recommendation to use plane IDs is for drivers in case user-space uses duplicate zpos values (Pekka) v5: reword commit message (Pekka, James) v6: remove mention of Arm GPUs having planes which can't overlap, because this isn't uAPI yet (Daniel) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com> Cc: Marius Vlad <marius.vlad@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: James Qian Wang <james.qian.wang@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/T5nHrvXH0GKOp6ONaFHk-j2cwEb4_4C_sBz9rNw8mmPACuut-DQqC74HMAFKZH3_Q15E8a3YnmKCxap-djKA71VVZv_T-tFxaB0he13O7yA=@emersion.fr
2019-10-09drm/amdkfd: update for drmP.h removalStephen Rothwell
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-09drm/amdgpu/powerplay: fix typo in mvdd table setupAlex Deucher
Polaris and vegam use count for the value rather than level. This looks like a copy paste typo from when the code was adapted from previous asics. I'm not sure that the SMU actually uses this value, so I don't know that it actually is a bug per se. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108609 Reported-by: Robert Strube <rstrube@gmail.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-09drm/amdgpu: fix memory leakNirmoy Das
cleanup error handling code and make sure temporary info array with the handles are freed by amdgpu_bo_list_put() on idr_replace()'s failure. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-10-09drm/i915: Select DPLL's via maskMatt Roper
This slightly simplifies the EHL DPLL4 handling and also gives us more flexibility in the future in case we need to skip the use of specific PLL's (e.g., due to hardware workarounds and such). v2: - Replace GENMASK() with or'd BIT()'s to make the specific DPLLs more explicit. (Ville) - s/unsigned/unsigned long/. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008172920.11362-1-matthew.d.roper@intel.com
2019-10-09drm/vkms: Fix an undefined reference error in vkms_composer_workerzhong jiang
I hit the following error when compile the kernel. drivers/gpu/drm/vkms/vkms_composer.o: In function `vkms_composer_worker': vkms_composer.c:(.text+0x5e4): undefined reference to `crc32_le' make: *** [vmlinux] Error 1 Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1569201883-18779-1-git-send-email-zhongjiang@huawei.com
2019-10-09drm/i915/color: move check of gamma_enable to specific func/platformSwati Sharma
Moved common code to check gamma_enable to specific funcs per platform in bit_precision func. icl doesn't support that and chv has separate enable knob for CGM LUT. v2: -Simplified chv_gamma_precision() [Ville] Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009065542.27415-3-swati2.sharma@intel.com
2019-10-09drm/i915/color: fix broken gamma state-checker during bootSwati Sharma
Premature gamma lut prepration and loading which was getting reflected in first modeset causing different colors on screen during boot. Issue: In BIOS, gamma is disabled by default. However, legacy read_luts() was setting crtc_state->base.gamma_lut and gamma_lut was programmed with junk values which led to visual artifacts (different colored screens instead of usual black during boot). Fix: Calling read_luts() only when gamma is enabled which will happen after first modeset. This fix is independent from the revert 1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"") and should fix different colors on screen in legacy platforms too. v2: -Added gamma_enable checks inside read_luts() [Ville/Jani N] -Corrected gamma enable check for CHV [Ville] v3: -Added check in ilk_read_luts() [Ville] -Simplified gamma enable check for CHV [Ville] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111885 Tested-by: Jani Saarinen <jani.saarinen@intel.com> Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009065542.27415-2-swati2.sharma@intel.com
2019-10-09drm/edid: Select DMT timing if EDID's display feature not support GTFLee Shawn C
Refer to EDID 1.3 spec, display FEATURE (byte 18h) bit #0 said "If this bit is set to 1, the display supports timings based on the GTF standard using default GTF parameter values". And EDID 1.4 spec shows "If bit 0 is set to 0, then the display is noncontinuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in BASE EDID and certain EXTENSION Blocks. When display feature did not support CVT or GFT2 and monitor's EDID version greater than or equal to "1.2". DRM driver would select GTF as default for standard timing calculation. It may generated some video timing that can't display properly by external monitor. For example. When driver retrieved "0xD1 0xFC" (FHD, 120Hz) and "0xD1 0xE8" (FHD, 100Hz) from "Standard Timings". GTF formula would generate video timing like below. It already over monitor's spec to cause black screen issue. "1920x1080" 120 368881 1920 2072 2288 2656 1080 1081 1084 1157 0x0 0x6 "1920x1080" 100 301992 1920 2072 2280 2640 1080 1081 1084 1144 0x0 0x6 v2: Just confirm GTF flag and omit the revision check. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007135127.9538-1-shawn.c.lee@intel.com
2019-10-09locking/lockdep: Remove unused @nested argument from lock_release()Qian Cai
Since the following commit: b4adfe8e05f1 ("locking/lockdep: Remove unused argument in __lock_release") @nested is no longer used in lock_release(), so remove it from all lock_release() calls and friends. Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: airlied@linux.ie Cc: akpm@linux-foundation.org Cc: alexander.levin@microsoft.com Cc: daniel@iogearbox.net Cc: davem@davemloft.net Cc: dri-devel@lists.freedesktop.org Cc: duyuyang@gmail.com Cc: gregkh@linuxfoundation.org Cc: hannes@cmpxchg.org Cc: intel-gfx@lists.freedesktop.org Cc: jack@suse.com Cc: jlbec@evilplan.or Cc: joonas.lahtinen@linux.intel.com Cc: joseph.qi@linux.alibaba.com Cc: jslaby@suse.com Cc: juri.lelli@redhat.com Cc: maarten.lankhorst@linux.intel.com Cc: mark@fasheh.com Cc: mhocko@kernel.org Cc: mripard@kernel.org Cc: ocfs2-devel@oss.oracle.com Cc: rodrigo.vivi@intel.com Cc: sean@poorly.run Cc: st@kernel.org Cc: tj@kernel.org Cc: tytso@mit.edu Cc: vdavydov.dev@gmail.com Cc: vincent.guittot@linaro.org Cc: viro@zeniv.linux.org.uk Link: https://lkml.kernel.org/r/1568909380-32199-1-git-send-email-cai@lca.pw Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-10-09drm/i915/selftests: fix null pointer dereference on pointer dataColin Ian King
In the case where data fails to be allocated the error exit path is via label 'out' where data is dereferenced in a for-loop. Fix this by exiting via the label 'out_file' instead to avoid the null pointer dereference. Addresses-Coverity: ("Dereference after null check") Fixes: 50d16d44cce4 ("drm/i915/selftests: Exercise context switching in parallel") Signed-off-by: Colin Ian King <colin.king@canonical.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/20191009100024.23077-1-colin.king@canonical.com
2019-10-09drm/mediatek: add no_clk into ddp private dataCK Hu
Mutex has no clock in some SoC, so add no_clk in private data and get clock according to no_clk. Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add mutex sof register offset into ddp private dataYongqiang Niu
mutex sof register offset will be private data of ddp Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add mutex sof into ddp private dataYongqiang Niu
mutex sof will be ddp private data Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add mutex mod register offset into ddp private dataYongqiang Niu
mutex mod register offset will be private data of ddp. Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add mutex mod into ddp private dataYongqiang Niu
except mutex mod, mutex mod reg,mutex sof reg, and mutex sof id will be ddp private data Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add ovl0/ovl_2l0 usecaseYongqiang Niu
This patch add ovl0/ovl_2l0 usecase in ovl->ovl_2l0 direct link usecase: 1. the crtc support layer number will 4+2 2. ovl_2l0 background color input select ovl0 when crtc init and disable it when crtc finish 3. config ovl_2l0 layer, if crtc config layer number is bigger than ovl0 support layers(max is 4) Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: distinguish ovl and ovl_2l by layer_nrYongqiang Niu
distinguish ovl and ovl_2l by layer_nr when get comp id Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add background color input select function for ovl/ovl_2lYongqiang Niu
This patch add background color input select function for ovl/ovl_2l ovl include 4 DRAM layer and 1 background color layer ovl_2l include 4 DRAM layer and 1 background color layer DRAM layer frame buffer data from render hardware, GPU for example. backgournd color layer is embed in ovl/ovl_2l, we can only set it color, but not support DRAM frame buffer. for ovl0->ovl0_2l direct link usecase, we need set ovl0_2l background color intput select from ovl0 if render send DRAM buffer layer number <=4, all these layer read by ovl. layer0 is at the bottom of all layers. layer3 is at the top of all layers. if render send DRAM buffer layer numbfer >=4 && <=6 ovl0 read layer0~3 ovl0_2l read layer4~5 layer5 is at the top ot all these layers. the decision of how to setting ovl0/ovl0_2l read these layer data is controlled in mtk crtc, which will be another patch Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add function to background color input select for ovl/ovl_2l ↵Yongqiang Niu
direct link This patch add function to background color input select for ovl/ovl_2l direct link for ovl/ovl_2l direct link usecase, we need set background color input select for these hardware. This is preparation patch for ovl/ovl_2l usecase. Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/medaitek: add layer_nr for ovl private dataYongqiang Niu
This patch add layer_nr for ovl private data ovl_2l almost same with with ovl hardware, except the layer number for ovl_2l is 2 and ovl is 4. this patch is a preparation for ovl-2l and ovl share the same driver. Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add gmc_bits for ovl private dataYongqiang Niu
This patch add gmc_bits for ovl private data GMC register was set RDMA ultra and pre-ultra threshold. 10bit GMC register define is different with other SOC, gmc_thrshd_l not used. Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add component OVL_2L1Yongqiang Niu
This patch add component OVL_2L1 Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add component OVL_2L0Yongqiang Niu
This patch add component OVL_2L0 Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/mediatek: add component DITHERYongqiang Niu
This patch add component DITHER Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/komeda: remove redundant assignment to pointer disable_doneColin Ian King
The pointer disable_done is being initialized with a value that is never read and is being re-assigned a little later on. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004162156.325-1-colin.king@canonical.com
2019-10-09drm/mediatek: add ddp component CCORRYongqiang Niu
This patch add ddp component CCORR Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: CK Hu <ck.hu@mediatek.com>
2019-10-09drm/i915/selftests: Hold request reference over waitsChris Wilson
Take a reference on the request before submitting it to the HW and then waiting on it for selftest_workarounds. Once submitted, the request may be freed by a background worker, unless we take an extra reference for ourselves. References: https://bugs.freedesktop.org/show_bug.cgi?id=111926 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191009061759.3189-1-chris@chris-wilson.co.uk
2019-10-08drm/vkms: prime import supportOleg Vasilev
Bring dmabuf sharing through implementing prime_import_sg_table callback. This will help to validate userspace conformance in prime configurations without using any actual hardware (e.g. in the cloud). This enables kms_prime IGT testcase on vkms. V3: - Rodrigo: remove redundant vkms_gem_create_private V2: - Rodrigo: styleguide + return code check Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Simon Ser <simon.ser@intel.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Oleg Vasilev <oleg.vasilev@intel.com> Signed-off-by: Oleg Vasilev <omrigann@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190930155924.21845-1-oleg.vasilev@intel.com
2019-10-08drm/drm_vblank: Change EINVAL by the correct errnoRodrigo Siqueira
For historical reasons, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace to make detailed verification of any problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL, which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl, also returns EINVAL if vblank is not supported; this patch also changes the return value to EOPNOTSUPP in these functions. Lastly, these functions are invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined: * Drm-hwcomposer * Kwin * Sway * Wlroots * Wayland * Weston * Mutter * Xorg (67 different drivers) For each repository the verification happened in three steps: * Update the main branch * Look for any occurrence of "drmCrtcQueueSequence", "drmCrtcGetSequence", and "drmWaitVBlank" with the command git grep -n "STRING". * Look in the git history of the project with the command git log -S<STRING> None of the above projects validate the use of EINVAL when using drmWaitVBlank(), which make safe, at least for these projects, to change the return values. On the other hand, mesa and xserver project uses drmCrtcQueueSequence() and drmCrtcGetSequence(); this change is harmless for both projects. Change since V5 (Pekka Paalanen): - Check if the change also affects Mutter Change since V4 (Daniel): - Also return EOPNOTSUPP in drm_crtc_[get|queue]_sequence_ioctl Change since V3: - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) Change since V2: Daniel Vetter and Chris Wilson - Replace ENOTTY by EOPNOTSUPP - Return EINVAL if the parameters are wrong Cc: Keith Packard <keithp@keithp.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002140516.adeyj3htylimmlmg@smtp.gmail.com
2019-10-08drm/i915/gt: Give engine->kernel_context distinct timeline lock classesChris Wilson
Assign a separate lockclass to the perma-pinned timelines of the kernel_context, such that we can use them from within the user timelines should we ever need to inject GPU operations to fixup faults during request construction. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008185941.15228-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/region: support volatile objectsMatthew Auld
Volatile objects are marked as DONTNEED while pinned, therefore once unpinned the backing store can be discarded. This is limited to kernel internal objects. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: CQ Tang <cq.tang@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.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/20191008160116.18379-4-matthew.auld@intel.com
2019-10-08drm/i915/region: support contiguous allocationsMatthew Auld
Some kernel internal objects may need to be allocated as a contiguous block, also thinking ahead the various kernel io_mapping interfaces seem to expect it, although this is purely a limitation in the kernel API...so perhaps something to be improved. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Michael J Ruhl <michael.j.ruhl@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/20191008160116.18379-3-matthew.auld@intel.com
2019-10-08drm/i915: introduce intel_memory_regionMatthew Auld
Support memory regions, as defined by a given (start, end), and allow creating GEM objects which are backed by said region. The immediate goal here is to have something to represent our device memory, but later on we also want to represent every memory domain with a region, so stolen, shmem, and of course device. At some point we are probably going to want use a common struct here, such that we are better aligned with say TTM. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: 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> Link: https://patchwork.freedesktop.org/patch/msgid/20191008160116.18379-2-matthew.auld@intel.com
2019-10-08drm_dp_cec: drop use of drmP.hSam Ravnborg
drmP.h is deprecated and will be deleted. Replace use with proper header. Divide header includes in blocks while touching these. Build tested with various archtectures and configs. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Fixes: ae85b0df124f6928 ("drm_dp_cec: add connector info support.") Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Dariusz Marcinkiewicz <darekm@google.com> Cc: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007171224.1581-2-sam@ravnborg.org
2019-10-08drm/i915/gt: Flush submission tasklet before waiting/retiringChris Wilson
A common bane of ours is arbitrary delays in ksoftirqd processing our submission tasklet. Give the submission tasklet a kick before we wait to avoid those delays eating into a tight timeout. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008105655.13256-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/perf: drop list of streamsLionel Landwerlin
At some point in time there was the idea that we could have multiple stream from the same piece of HW but that never materialized and given the hard time we already have making everything work with the submission side, there is no real point having this list of 1 element around. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@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/20191008140111.5437-1-chris@chris-wilson.co.uk
2019-10-08drm/i915/selftests: Assign the intel_runtime_pm pointer for mock_uncoreChris Wilson
Couple up our mock_uncore to know about the fake global device and its runtime powermanagement. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008145045.23157-1-chris@chris-wilson.co.uk
2019-10-08drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500Wen He
Configure the display Quality of service (QoS) levels priority if the optional property node "arm,malidp-aqros-value" is defined in DTS file. QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is driven from the "RQOS" register, so needed to program the RQOS register to avoid the high resolutions flicker issue on the LS1028A platform. Signed-off-by: Wen He <wen.he_1@nxp.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910075913.17650-2-wen.he_1@nxp.com
2019-10-08drm: damage_helper: Fix race checking plane->state->fbSean Paul
Since the dirtyfb ioctl doesn't give us any hints as to which plane is scanning out the fb it's marking as damaged, we need to loop through planes to find it. Currently we just reach into plane state and check, but that can race with another commit changing the fb out from under us. This patch locks the plane before checking the fb and will release the lock if the plane is not displaying the dirty fb. Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb") Cc: Rob Clark <robdclark@gmail.com> Cc: Deepak Rawat <drawat@vmware.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.0+ Reported-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190904202938.110207-1-sean@poorly.run
2019-10-08drm/i915/selftests: Assign the mock_engine->uncore shortcutChris Wilson
Set up the engine->uncore shortcut on mock_engine creation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008071121.25088-1-chris@chris-wilson.co.uk
generated by cgit (git 2.34.1) at 2025-09-18 05:14:11 +0000