summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-04-28drm/vboxvideo: Use devm_gen_pool_createDaniel Vetter
Aside from deleting all the cleanup code we're now also setting a name for the pool Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-7-daniel.vetter@ffwll.ch
2020-04-28drm/vboxvideo: use managed pci functionsDaniel Vetter
Allows us to drop the cleanup code on the floor. Sam noticed in his review: > With this change we avoid calling pci_disable_device() > twise in case vbox_mm_init() fails. > Once in vbox_hw_fini() and once in the error path. v2: Include Sam's review remarks v3: Fix typo in commit summary (Thomas Zimmermann) Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-6-daniel.vetter@ffwll.ch
2020-04-28drm/vboxvideo: Stop using drm_device->dev_privateDaniel Vetter
We use the baseclass pattern here, so lets to the proper (and more typesafe) upcasting. Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-5-daniel.vetter@ffwll.ch
2020-04-28drm/vboxvideo: Use devm_drm_dev_allocDaniel Vetter
Straightforward conversion. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-4-daniel.vetter@ffwll.ch
2020-04-28drm/vboxvideo: drop DRM_MTRR_WC #defineDaniel Vetter
Doesn't apply to upstream kernels since a rather long time. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-3-daniel.vetter@ffwll.ch
2020-04-28drm: Add devm_drm_dev_alloc macroDaniel Vetter
Add a new macro helper to combine the usual init sequence in drivers, consisting of a kzalloc + devm_drm_dev_init + drmm_add_final_kfree triplet. This allows us to remove the rather unsightly drmm_add_final_kfree from all currently merged drivers. The kerneldoc is only added for this new function. Existing kerneldoc and examples will be udated at the very end, since once all drivers are converted over to devm_drm_dev_alloc we can unexport a lot of interim functions and make the documentation for driver authors a lot cleaner and less confusing. There will be only one true way to initialize a drm_device at the end of this, which is going to be devm_drm_dev_alloc. v2: - Actually explain what this is for in the commit message (Sam) - Fix checkpatch issues (Sam) Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-2-daniel.vetter@ffwll.ch
2020-04-28drm/omap: venc: remove unused variable 'venc_config_pal_bdghi'YueHaibing
drivers/gpu/drm/omapdrm/dss/venc.c:211:33: warning: 'venc_config_pal_bdghi' defined but not used [-Wunused-const-variable=] static const struct venc_config venc_config_pal_bdghi = { ^~~~~~~~~~~~~~~~~~~~~ It is never used, remove it. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415132105.43636-1-yuehaibing@huawei.com
2020-04-28drm/meson: Remove unneeded semicolonZheng Bin
Fixes coccicheck warning: drivers/gpu/drm/meson/meson_plane.c:226:3-4: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424074949.12309-1-zhengbin13@huawei.com
2020-04-28drm/i915/gt: fix spelling mistake "evalution" -> "evaluation"Colin Ian King
There is a spelling mistaking in a pr_notice message. Fix it. 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/20200428084920.1035125-1-colin.king@canonical.com
2020-04-27drm/dp_mst: Kill the second sideband tx slot, save the worldLyude Paul
While we support using both tx slots for sideband transmissions, it appears that DisplayPort devices in the field didn't end up doing a very good job of supporting it. From section 5.2.1 of the DP 2.0 specification: There are MST Sink/Branch devices in the field that do not handle interleaved message transactions. To facilitate message transaction handling by downstream devices, an MST Source device shall generate message transactions in an atomic manner (i.e., the MST Source device shall not concurrently interleave multiple message transactions). Therefore, an MST Source device shall clear the Message_Sequence_No value in the Sideband_MSG_Header to 0. This might come as a bit of a surprise since the vast majority of hubs will support using both tx slots even if they don't support interleaved message transactions, and we've also been using both tx slots since MST was introduced into the kernel. However, there is one device we've had trouble getting working consistently with MST for so long that we actually assumed it was just broken: the infamous Dell P2415Qb. Previously this monitor would appear to work sometimes, but in most situations would end up timing out LINK_ADDRESS messages almost at random until you power cycled the whole display. After reading section 5.2.1 in the DP 2.0 spec, some closer investigation into this infamous display revealed it was only ever timing out on sideband messages in the second TX slot. Sure enough, avoiding the second TX slot has suddenly made this monitor function perfectly for the first time in five years. And since they explicitly mention this in the specification, I doubt this is the only monitor out there with this issue. This might even explain explain the seemingly harmless garbage sideband responses we would occasionally see with MST hubs! So - rewrite our sideband TX handlers to only support one TX slot. In order to simplify our sideband handling now that we don't support transmitting to multiple MSTBs at once, we also move all state tracking for down replies from mstbs to the topology manager. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <sean@poorly.run> Cc: "Lin, Wayne" <Wayne.Lin@amd.com> Cc: <stable@vger.kernel.org> # v3.17+ Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200424181308.770749-1-lyude@redhat.com
2020-04-27drm/amd/display: remove conversion to bool in dc_link_ddc.cJason Yan
The '>' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:602:28-33: WARNING: conversion to bool not needed here Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amd/display: remove conversion to bool in dcn20_mpc.cJason Yan
The '==' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c:455:70-75: WARNING: conversion to bool not needed here Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: remove conversion to bool in amdgpu_device.cJason Yan
The '>' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3004:68-73: WARNING: conversion to bool not needed here Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: decouple EccErrCnt query and clear operationGuchun Chen
Due to hardware bug that when RSMU UMC index is disabled, clear EccErrCnt at the first UMC instance will clean up all other EccErrCnt registes from other instances at the same time. This will break the correctable error count log in EccErrCnt register once querying it. So decouple both to make error count query workable. Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: switch to SMN interface to operate RSMU index modeGuchun Chen
This makes consistent with other regsiters' access in this module. Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: drop redundant cg/pg ungate on runpm enterEvan Quan
CG/PG ungate is already performed in ip_suspend_phase1. Otherwise, the CG/PG ungate will be performed twice. That will cause gfxoff disablement is performed twice also on runpm enter while gfxoff enablemnt once on rump exit. That will put gfxoff into disabled state. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: move kfd suspend after ip_suspend_phase1Evan Quan
This sequence change should be safe as what did in ip_suspend_phase1 is to suspend DCE only. And this is a prerequisite for coming redundant cg/pg ungate dropping. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: sw pstate switch should only be for vega20Jonathan Kim
Driver steered p-state switching is designed for Vega20 only. Also simplify early return for temporary disable due to SMU FW bug. Signed-off-by: Jonathan Kim <Jonathan.Kim@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-04-27drm/amdgpu: Remove unneeded semicolonZheng Bin
Fixes coccicheck warning: drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:2534:2-3: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2020-04-27drm/rockchip: Remove unneeded semicolonZheng Bin
Fixes coccicheck warning: drivers/gpu/drm/rockchip/cdn-dp-reg.c:604:2-3: Unneeded semicolon drivers/gpu/drm/rockchip/cdn-dp-reg.c:622:2-3: Unneeded semicolon drivers/gpu/drm/rockchip/cdn-dp-reg.c:703:2-3: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200424074410.1070-1-zhengbin13@huawei.com
2020-04-27drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume staticEnric Balletbo i Serra
This fixes the following warning detected when running make with W=1 drivers/gpu/drm/rockchip//cdn-dp-core.c:1112:5: warning: no previous prototype for ‘cdn_dp_suspend’ [-Wmissing-prototypes] drivers/gpu/drm/rockchip//cdn-dp-core.c:1126:5: warning: no previous prototype for ‘cdn_dp_resume’ [-Wmissing-prototypes] Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200426161653.7710-1-enric.balletbo@collabora.com
2020-04-27drm/i915: Use proper fault mask in interrupt postinstall tooMatt Roper
The IRQ postinstall handling had open-coded pipe fault mask selection that never got updated for gen11. Switch it to use gen8_de_pipe_fault_mask() to ensure we don't miss updates for new platforms. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: d506a65d56fd ("drm/i915: Catch GTT fault errors for gen11+ planes") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424231423.4065231-1-matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2020-04-27drm/i915/gt: Fix up clock frequencyChris Wilson
The bspec lists both the clock frequency and the effective interval. The interval corresponds to observed behaviour, so adjust the frequency to match. v2: Mika rightfully asked if we could measure the clock frequency from a selftest. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200427154554.12736-1-chris@chris-wilson.co.uk
2020-04-27drm/stm: ltdc: check number of endpointsYannick Fertre
Number of endpoints could exceed the fix value MAX_ENDPOINTS(2). Instead of increase simply this value, the number of endpoint could be read from device tree. Load sequence has been a little rework to take care of several panel or bridge which can be connected/disconnected or enable/disable. Signed-off-by: Yannick Fertre <yannick.fertre@st.com> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/1582877258-1112-1-git-send-email-yannick.fertre@st.com
2020-04-27drm/i915/gt: Sanitize GT firstChris Wilson
We see that if the HW doesn't actually sleep, the HW may eat the poison we set in its write-only HWSP during sanitize: intel_gt_resume.part.8: 0000:00:02.0 __gt_unpark: 0000:00:02.0 gt_sanitize: 0000:00:02.0 force:yes process_csb: 0000:00:02.0 vcs0: cs-irq head=5, tail=90 process_csb: 0000:00:02.0 vcs0: csb[0]: status=0x5a5a5a5a:0x5a5a5a5a assert_pending_valid: Nothing pending for promotion! The CS TAIL pointer should have been reset by reset_csb_pointers(), so in this case it is likely that we have read back from the CPU cache and so we must clflush our control over that page. In doing so, push the sanitisation to the start of the GT sequence so that our poisoning is assuredly before we start talking to the HW. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1794 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/20200427084000.10999-1-chris@chris-wilson.co.uk
2020-04-27drm/i915/gt: Check cacheline is valid before acquiringChris Wilson
The hwsp_cacheline pointer from i915_request is very, very flimsy. The i915_request.timeline (and the hwsp_cacheline) are lost upon retiring (after an RCU grace). Therefore we need to confirm that once we have the right pointer for the cacheline, it is not in the process of being retired and disposed of before we attempt to acquire a reference to the cacheline. <3>[ 547.208237] BUG: KASAN: use-after-free in active_debug_hint+0x6a/0x70 [i915] <3>[ 547.208366] Read of size 8 at addr ffff88822a0d2710 by task gem_exec_parall/2536 <4>[ 547.208547] CPU: 3 PID: 2536 Comm: gem_exec_parall Tainted: G U 5.7.0-rc2-ged7a286b5d02d-kasan_117+ #1 <4>[ 547.208556] Hardware name: Dell Inc. XPS 13 9350/, BIOS 1.4.12 11/30/2016 <4>[ 547.208564] Call Trace: <4>[ 547.208579] dump_stack+0x96/0xdb <4>[ 547.208707] ? active_debug_hint+0x6a/0x70 [i915] <4>[ 547.208719] print_address_description.constprop.6+0x16/0x310 <4>[ 547.208841] ? active_debug_hint+0x6a/0x70 [i915] <4>[ 547.208963] ? active_debug_hint+0x6a/0x70 [i915] <4>[ 547.208975] __kasan_report+0x137/0x190 <4>[ 547.209106] ? active_debug_hint+0x6a/0x70 [i915] <4>[ 547.209127] kasan_report+0x32/0x50 <4>[ 547.209257] ? i915_gemfs_fini+0x40/0x40 [i915] <4>[ 547.209376] active_debug_hint+0x6a/0x70 [i915] <4>[ 547.209389] debug_print_object+0xa7/0x220 <4>[ 547.209405] ? lockdep_hardirqs_on+0x348/0x5f0 <4>[ 547.209426] debug_object_assert_init+0x297/0x430 <4>[ 547.209449] ? debug_object_free+0x360/0x360 <4>[ 547.209472] ? lock_acquire+0x1ac/0x8a0 <4>[ 547.209592] ? intel_timeline_read_hwsp+0x4f/0x840 [i915] <4>[ 547.209737] ? i915_active_acquire_if_busy+0x66/0x120 [i915] <4>[ 547.209861] i915_active_acquire_if_busy+0x66/0x120 [i915] <4>[ 547.209990] ? __live_alloc.isra.15+0xc0/0xc0 [i915] <4>[ 547.210005] ? rcu_read_lock_sched_held+0xd0/0xd0 <4>[ 547.210017] ? print_usage_bug+0x580/0x580 <4>[ 547.210153] intel_timeline_read_hwsp+0xbc/0x840 [i915] <4>[ 547.210284] __emit_semaphore_wait+0xd5/0x480 [i915] <4>[ 547.210415] ? i915_fence_get_timeline_name+0x110/0x110 [i915] <4>[ 547.210428] ? lockdep_hardirqs_on+0x348/0x5f0 <4>[ 547.210442] ? _raw_spin_unlock_irq+0x2a/0x40 <4>[ 547.210567] ? __await_execution.constprop.51+0x2e0/0x570 [i915] <4>[ 547.210706] i915_request_await_dma_fence+0x8f7/0xc70 [i915] Fixes: 85bedbf191e8 ("drm/i915/gt: Eliminate the trylock for reading a timeline's hwsp") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200427093038.29219-1-chris@chris-wilson.co.uk
2020-04-27drm/i915/execlists: Check preempt-timeout target before submit_portsChris Wilson
We evaluate *active, which is a pointer into execlists->inflight[] during dequeue to decide how long a preempt-timeout we need to apply. However, as soon as we do the submit_ports, the HW may send its ACK interrupt causing us to promote execlists->pending[] tp execlists->inflight[], overwriting the value of *active. We know *active is only stable until we submit (as we only submit when there is no pending promotion). [ 16.102328] BUG: KCSAN: data-race in execlists_dequeue+0x1449/0x1600 [i915] [ 16.102356] [ 16.102375] race at unknown origin, with read to 0xffff8881e9500488 of 8 bytes by task 429 on cpu 1: [ 16.102780] execlists_dequeue+0x1449/0x1600 [i915] [ 16.103160] __execlists_submission_tasklet+0x48/0x60 [i915] [ 16.103540] execlists_submit_request+0x38e/0x3c0 [i915] [ 16.103940] submit_notify+0x8f/0xc0 [i915] [ 16.104308] __i915_sw_fence_complete+0x61/0x420 [i915] [ 16.104683] i915_sw_fence_complete+0x58/0x80 [i915] [ 16.105054] i915_sw_fence_commit+0x16/0x20 [i915] [ 16.105457] __i915_request_queue+0x60/0x70 [i915] [ 16.105843] i915_gem_do_execbuffer+0x2d6b/0x4230 [i915] [ 16.106227] i915_gem_execbuffer2_ioctl+0x2b0/0x580 [i915] [ 16.106257] drm_ioctl_kernel+0xe9/0x130 [ 16.106279] drm_ioctl+0x27d/0x45e [ 16.106311] ksys_ioctl+0x89/0xb0 [ 16.106336] __x64_sys_ioctl+0x42/0x60 [ 16.106370] do_syscall_64+0x6e/0x2c0 [ 16.106397] entry_SYSCALL_64_after_hwframe+0x44/0xa9 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/20200426094231.21995-1-chris@chris-wilson.co.uk
2020-04-27drm/i915: re-disable -Wframe-addressNick Desaulniers
The top level Makefile disables this warning. When building an i386_defconfig with Clang, this warning is triggered a whole bunch via includes of headers from perf. Link: https://github.com/ClangBuiltLinux/continuous-integration/pull/182 Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200426214215.139435-1-ndesaulniers@google.com
2020-04-25drm/i915: Use indirect ctx bb to mend CMD_BUF_CCTLMika Kuoppala
Use indirect ctx bb to load cmd buffer control value from context image to avoid corruption. v2: add to lrc layout (Chris) v3: end to a cacheline (Chris) v4: add to lrc fixed (Chris) v5: value in offset+1 Testcase: igt/i915_selftest/gt_lrc Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20200424230632.30333-1-mika.kuoppala@linux.intel.com
2020-04-25drm/i915: Add live selftests for indirect ctx batchbuffersMika Kuoppala
Indirect ctx batchbuffers are a hw feature of which batch can be run, by hardware, during context restoration stage. Driver can setup a batchbuffer and also an offset into the context image. When context image is marshalled from memory to registers, and when the offset from the start of context register state is equal of what driver pre-determined, batch will run. So one can manipulate context restoration process at cacheline granularity, given some limitations, as you need to have rudimentaries in place before you can run a batch. Add selftest which will write the ring start register to a canary spot. This will test that hardware will run a batchbuffer for the context in question. v2: request wait fix, naming (Chris) v3: test order (Chris) v4: rebase Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20200424214841.28076-3-mika.kuoppala@linux.intel.com
2020-04-25panel: simple: Add Ivo M133NWF4 R0Bjorn Andersson
The InfoVision Optoelectronics M133NWF4 R0 panel is a 13.3" 1920x1080 eDP panel, add support for it in panel-simple. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200420215728.1927434-2-bjorn.andersson@linaro.org
2020-04-25dt-bindings: display: simple: Add IVO M133NWF4 R0Bjorn Andersson
Define the vendor prefix for InfoVision Optoelectronics and add their M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel to the compatible list of panel-simple. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Rob Herring <robh@kernel.org> [vendor-prefix] Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200420215728.1927434-1-bjorn.andersson@linaro.org
2020-04-25drm/i915: Add per ctx batchbuffer wa for timestampMika Kuoppala
Restoration of a previous timestamp can collide with updating the timestamp, causing a value corruption. Combat this issue by using indirect ctx bb to modify the context image during restoring process. We can preload value into scratch register. From which we then do the actual write with LRR. LRR is faster and thus less error prone as probability of race drops. v2: tidying (Chris) v3: lrr for all engines v4: grp v5: reg bit v6: wa_bb_offset, virtual engines (Chris) References: HSDES#16010904313 Testcase: igt/i915_selftest/gt_lrc Suggested-by: Joseph Koston <joseph.koston@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20200424230546.30271-1-mika.kuoppala@linux.intel.com
2020-04-25drm/i915: Add engine scratch register to live_lrc_fixedMika Kuoppala
General purpose registers are per engine and in a fixed location. Add to live_lrc_fixed. Signed-off-by: Mika Kuoppala <mika.kuoppala@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/20200424214841.28076-1-mika.kuoppala@linux.intel.com
2020-04-25panel: simple: Add BOE NV133FHM-N61Bjorn Andersson
The BOE NV133FHM-N61 panel is a 13.3" 1920x1080 eDP panel, add support for it in panel-simple. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [add boe_nv133fhm_n61_modes in alphabetical order] Link: https://patchwork.freedesktop.org/patch/msgid/20200420215742.1927498-2-bjorn.andersson@linaro.org
2020-04-25dt-bindings: display: simple: Add BOE NV133FHM-N61Bjorn Andersson
Add the BOE NV133FHM-N61 13.3" FHD (1920x1080) TFT LCD Panel to the compatible list of panel-simple. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200420215742.1927498-1-bjorn.andersson@linaro.org
2020-04-25video/fbdev/riva: Remove dead codeSouptick Joarder
These are dead code since 3.15. These can be removed forever if no plan to use it further. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1587407244-32574-1-git-send-email-jrdr.linux@gmail.com
2020-04-25drm/panel: remove set but not used variable 'config'YueHaibing
drivers/gpu/drm/panel/panel-truly-nt35597.c:493:31: warning: variable ‘config’ set but not used [-Wunused-but-set-variable] const struct nt35597_config *config; ^~~~~~ Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200417101401.19388-1-yuehaibing@huawei.com
2020-04-25dt-bindings: panel: Document some missing compatible stringsThierry Reding
Add missing compatible strings for the Panasonic and Chunghwa panels found on NVIDIA Dalmore and Cardhu boards. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200417065328.1578603-1-thierry.reding@gmail.com
2020-04-25drm/bridge: panel: Return always an error pointer in drm_panel_bridge_add()Enric Balletbo i Serra
Since commit 89958b7cd955 ("drm/bridge: panel: Infer connector type from panel by default"), drm_panel_bridge_add() and their variants can return NULL and an error pointer. This is fine but none of the actual users of the API are checking for the NULL value. Instead of change all the users, seems reasonable to return an error pointer instead. So change the returned value for those functions when the connector type is unknown. Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200416210654.2468805-1-enric.balletbo@collabora.com
2020-04-25drm/bridge: ps8640: Let panel to set the connector typeEnric Balletbo i Serra
The panel connector type should be set by the panel not the bridge, so remove the connector_type assignment. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200416164404.2418426-2-enric.balletbo@collabora.com
2020-04-25drm: panel: Set connector type for LP120UP1Enric Balletbo i Serra
The LP120UP1 is a eDP panel, set the connector type accordingly. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200416164404.2418426-1-enric.balletbo@collabora.com
2020-04-25drm/panel: ili9322: Remove unneeded semicolonZheng Bin
Fixes coccicheck warning: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:382:2-3: Unneeded semicolon drivers/gpu/drm/panel/panel-ilitek-ili9322.c:391:2-3: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200424080224.30763-1-zhengbin13@huawei.com
2020-04-25drm/panel: simple: Add support for AUO G121EAN01.4 panelSebastian Reichel
Add timings for the AUO G121EAN01.4 panel. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200415172725.84257-4-sebastian.reichel@collabora.com
2020-04-25drm/panel: simple: Add support for AUO G156XTN01.0 panelSebastian Reichel
Add timings for the AUO G156XTN01.0 panel. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200415172725.84257-3-sebastian.reichel@collabora.com
2020-04-25drm/panel: simple: Add support for AUO G190EAN01 panelSebastian Reichel
Add timings for the G190EAN01 dual channel LVDS panel. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200415172725.84257-2-sebastian.reichel@collabora.com
2020-04-24drm/i915: Drop rq->ring->vma peeking from error captureChris Wilson
We only hold the active spinlock while dumping the error state, and this does not prevent another thread from retiring the request -- as it is quite possible that despite us capturing the current state, the GPU has completed the request. As such, it is dangerous to dereference state below the request as it may already be freed, and the simplest way to avoid the danger is not include it in the error state. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1788 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424191410.27570-1-chris@chris-wilson.co.uk
2020-04-24drm/i915/gt: Use the RPM config register to determine clk frequenciesChris Wilson
For many configuration details within RC6 and RPS we are programming intervals for the internal clocks. From gen11, these clocks are configuration via the RPM_CONFIG and so for convenience, we would like to convert to/from more natural units (ns). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424162805.25920-2-chris@chris-wilson.co.uk
2020-04-24drm/i915/gt: Trace RPS eventsChris Wilson
Add tracek to the RPS events (interrupts, worker, enabling, threshold selection, frequency setting), so that if we have to debug reticent HW we have some traces to start from. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424162805.25920-1-chris@chris-wilson.co.uk
2020-04-24drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUTChris Wilson
The RPS DOWN_TIMEOUT interrupt is signaled after a period of rc6, and upon receipt of that interrupt we reprogram the GPU clocks down to the next idle notch [to help convserve power during rc6]. However, on execlists, we benefit from soft-rc6 immediately parking the GPU and setting idle frequencies upon idling [within a jiffie], and here the interrupt prevents us from restarting from our last frequency. In the process, we can simply opt for a static pm_events mask and rely on the enable/disable interrupts to flush the worker on parking. This will reduce the amount of oscillation observed during steady workloads with microsleeps, as each time the rc6 timeout occurs we immediately follow with a waitboost for a dropped frame. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200422001703.1697-1-chris@chris-wilson.co.uk
generated by cgit (git 2.34.1) at 2025-09-15 00:34:27 +0000