aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-03-27drm/amd/display: Slightly optimize dm_dmub_outbox1_low_irq()Christophe JAILLET1-3/+2
A kzalloc()+memcpy() can be optimized in a single kmemdup(). This saves a few cycles because some memory doesn't need to be zeroed. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-27drm/amd/display: Remove the unused variable dppclk_delay_subtotalJiapeng Chong1-10/+0
Variable dppclk_delay_subtotal is not effectively used, so delete it. drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:1004:15: warning: variable 'dppclk_delay_subtotal' set but not used. Reported-by: Abaci Robot <[email protected]> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4584 Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-27drm/amd/display: Clean up some inconsistent indentingJiapeng Chong1-2/+2
No functional modification involved. Reported-by: Abaci Robot <[email protected]> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4585 Signed-off-by: Jiapeng Chong <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-27drm/amdgpu: skip unload tmr when tmr is not loadedTong Liu011-1/+9
[why] Skip TMR unload for Navi12 and CHIP_SIENNA_CICHLID SRIOV as TMR is not loaded at all Signed-off-by: Tong Liu01 <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-03-27drm/panel: magnachip: Prevent error pointer dereference in probeDan Carpenter1-1/+1
Don't dereference "db->dsi_dev" when it is an error pointer. Fixes: 249a4f5e663c ("drm/panel: Add Magnachip D53E6EA8966 Panel Driver") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-27drm/scheduler: Fix variable name in function descriptionCaio Novais1-1/+1
Compiling AMD GPU drivers displays two warnings: drivers/gpu/drm/scheduler/sched_main.c:738: warning: Function parameter or member 'file' not described in 'drm_sched_job_add_syncobj_dependency' drivers/gpu/drm/scheduler/sched_main.c:738: warning: Excess function parameter 'file_private' description in 'drm_sched_job_add_syncobj_dependency' Get rid of them by renaming the variable name on the function description Signed-off-by: Caio Novais <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Luben Tuikov <[email protected]> Signed-off-by: Luben Tuikov <[email protected]>
2023-03-27drm/i915/reg: use the correct register to access SAGV block timeVinod Govindapillai1-1/+1
Wrong register address is used to read the SAG block time. Fix the register address according to the bspec. Bspec: 64608 Signed-off-by: Vinod Govindapillai <[email protected]> Reviewed-by: Stanislav Lisovskiy <[email protected]> Signed-off-by: Stanislav Lisovskiy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-27drm/i915/reg: fix QGV points register access offsetsVinod Govindapillai1-2/+3
Wrong offsets are calculated to read QGV point registers. Fix it to read from the correct registers. Bspec: 64602 Reviewed-by: Stanislav Lisovskiy <[email protected]> Signed-off-by: Vinod Govindapillai <[email protected]> Signed-off-by: Stanislav Lisovskiy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-27drm/i915/perf: Drop wakeref on GuC RC errorChris Wilson2-5/+15
If we fail to adjust the GuC run-control on opening the perf stream, make sure we unwind the wakeref just taken. v2: Retain old goto label names (Ashutosh) v3: Drop bitfield boolean Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2810ac6c753d17ee2572ffb57fe2382a786a080a) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/dpt: Treat the DPT BO as a framebufferVille Syrjälä3-1/+6
Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... Cc: [email protected] Cc: Juha-Pekka Heikkila <[email protected]> Cc: Matthew Auld <[email protected]> Cc: Imre Deak <[email protected]> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]> (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/gem: Flush lmem contents after constructionChris Wilson1-1/+2
i915_gem_object_create_lmem_from_data() lacks the flush of the data written to lmem to ensure the object is marked as dirty and the writes flushed to the backing store. Once created, we can immediately release the obj->mm.mapping caching of the vmap. Fixes: 7acbbc7cf485 ("drm/i915/guc: put all guc objects in lmem when available") Cc: Matthew Auld <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Matthew Brost <[email protected]> Cc: John Harrison <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: <[email protected]> # v5.16+ Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit e2ee10474ce766686e7a7496585cdfaf79e3a1bf) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/tc: Fix the ICL PHY ownership check in TC-cold stateImre Deak1-2/+2
The commit renaming icl_tc_phy_is_in_safe_mode() to icl_tc_phy_take_ownership() didn't flip the function's return value accordingly, fix this up. This didn't cause an actual problem besides state check errors, since the function is only used during HW readout. Cc: José Roberto de Souza <[email protected]> Fixes: f53979d68a77 ("drm/i915/display/tc: Rename safe_mode functions ownership") Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f2c7959dda614d9b7c6a41510492de39d31705ec) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Disable DC states for all commitsVille Syrjälä1-3/+25
Keeping DC states enabled is incompatible with the _noarm()/_arm() split we use for writing pipe/plane registers. When DC5 and PSR are enabled, all pipe/plane registers effectively become self-arming on account of DC5 exit arming the update, and PSR exit latching it. What probably saves us most of the time is that (with PIPE_MISC[21]=0) all pipe register writes themselves trigger PSR exit, and then we don't re-enter PSR until the idle frame count has elapsed. So it may be that the PSR exit happens already before we've updated the state too much. Also the PSR1 panel (at least on this KBL) seems to discard the first frame we trasmit, presumably still scanning out from its internal framebuffer at that point. So only the second frame we transmit is actually visible. But I suppose that could also be panel specific behaviour. I haven't checked out how other PSR panels behave, nor did I bother to check what the eDP spec has to say about this. And since this really is all about DC states, let's switch from the MODESET domain to the DC_OFF domain. Functionally they are 100% identical. We should probably remove the MODESET domain... And for good measure let's toss in an assert to the place where we do the _noarm() register writes to make sure DC states are in fact off. v2: Just use intel_display_power_is_enabled() (Imre) Cc: <[email protected]> #v5.17+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Jouni Högander <[email protected]> Reviewed-by: Imre Deak <[email protected]> Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Fixes: f8a005eb8972 ("drm/i915: Optimize icl+ universal plane programming") Fixes: 890b6ec4a522 ("drm/i915: Split skl+ plane update into noarm+arm pair") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 41b4c7fe72b6105a4b49395eea9aa40cef94288d) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Workaround ICL CSC_MODE sticky armingVille Syrjälä1-1/+43
Unlike SKL/GLK the ICL CSC unit suffers from a new issue where CSC_MODE arming is sticky. That is, once armed it remains armed causing the CSC coeff/offset registers to become effectively self-arming. CSC coeff/offset registers writes no longer disarm the CSC, but fortunately register read still do. So we can use that to disarm the CSC unit once the registers for the current frame have been latched. This avoid s the self-arming behaviour from persisting into the next frame's .color_commit_noarm() call. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 92736f1b452bbb8a66bdb5b1d263ad00e04dd3b8) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Add a .color_post_update() hookVille Syrjälä3-0/+17
We're going to need stuff after the color management register latching has happened. Add a corresponding hook. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 3962ca4e080a525fc9eae87aa6b2286f1fae351d) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Move CSC load back into .color_commit_arm() when PSR is enabled on ↵Ville Syrjälä1-2/+21
skl/glk SKL/GLK CSC unit suffers from a nasty issue where a CSC coeff/offset register read or write between DC5 exit and PSR exit will undo the CSC arming performed by DMC, and then during PSR exit the hardware will latch zeroes into the active CSC registers. This causes any plane going through the CSC to output all black. We can sidestep the issue by making sure the PSR exit has already actually happened before we touch the CSC coeff/offset registers. Easiest way to guarantee that is to just move the CSC programming back into the .color_commir_arm() as we force a PSR exit (and crucially wait for it to actually happen) prior to touching the arming registers. When PSR (and thus also DC states) are disabled we don't have anything to worry about, so we can keep using the more optional _noarm() hook for writing the CSC registers. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8283 Fixes: d13dde449580 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit 80a892a4c2428b65366721599fc5fe50eaed35fd) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915: Split icl_color_commit_noarm() from skl_color_commit_noarm()Ville Syrjälä1-1/+20
We're going to want different behavior for skl/glk vs. icl in .color_commit_noarm(), so split the hook into two. Arguably we already had slightly different behaviour since csc_enable/gamma_enable are never set on icl+, so the old code was perhaps a bit confusing as well. Cc: <[email protected]> #v5.19+ Cc: Manasi Navare <[email protected]> Cc: Drew Davenport <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jouni Högander <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]> (cherry picked from commit f161eb01f50ab31f2084975b43bce54b7b671e17) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/i915/pmu: Use functions common with sysfs to read actual freqAshutosh Dixit3-26/+26
Expose intel_rps_read_actual_frequency_fw to read the actual freq without taking forcewake for use by PMU. The code is refactored to use a common set of functions across sysfs and PMU. Using common functions with sysfs in PMU solves the issues of missing support for MTL and missing support for older generations (prior to Gen6). It also future proofs the PMU where sometimes code has been updated for sysfs and PMU has been missed. v2: Remove runtime_pm_if_in_use from read_actual_frequency_fw (Tvrtko) v3: (Tvrtko) - Remove goto in __read_cagf - Unexport intel_rps_get_cagf and intel_rps_read_punit_req Fixes: 22009b6dad66 ("drm/i915/mtl: Modify CAGF functions for MTL") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8280 Signed-off-by: Ashutosh Dixit <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 44df42e66139b5fac8db49ee354be279210f9816) Signed-off-by: Jani Nikula <[email protected]>
2023-03-27drm/bridge: it6505: Add range and selector_regHsin-Yi Wang1-11/+23
There are 2 banks on it6505, and when writing to different bank, REG_BANK_SEL needs to be set to the targeted bank. The current code set this additionally, which causes a race condition when a process is writing bank 0 registers while another process set the bank to 1. Set ranges in regmap config so the regmap API would handle the bank changes. Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-25drm/msm/a6xx: Move ioremap out of hw_init pathRob Clark1-10/+8
Move the one-time RPMh setup to a6xx_gmu_init(). To get rid of the hack for one-time init vs start, add in an extra a6xx_rpmh_stop() at the end of the init sequence. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527854/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gpu: Move BO allocation out of hw_initRob Clark4-49/+57
These allocations are only done the first (successful) time through hw_init() so they won't actually happen in the job_run() path. But lockdep doesn't know this. So dis-entangle them from the hw_init() path. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527852/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gpu: Move fw loading out of hw_init() pathRob Clark1-8/+1
It is already a no-op, since we've already loaded the fw from adreno_load_gpu(), so drop the redundant call. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527849/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm: Use idr_preload()Rob Clark1-2/+6
Avoid allocation under idr_lock, to prevent deadlock against the job_free() path (which runs on same thread as job_run(), which makes it also part of the fence-signaling path. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527847/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm: Switch idr_lock to spinlockRob Clark4-11/+9
Needed to idr_preload() which returns with preemption disabled. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527846/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gem: Avoid obj lock in job_run()Rob Clark3-10/+39
Now that everything that controls which LRU an obj lives in *except* the backing pages is protected by the LRU lock, add a special path to unpin in the job_run() path, where we are assured that we already have backing pages and will not be racing against eviction (because the GEM object's dma_resv contains the fence that will be signaled when the submit/job completes). Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527845/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gem: Protect pin_count/madv by LRU lockRob Clark2-13/+44
Since the LRU lock is already acquired when moving an obj between LRUs, we can use it to protect pin_count and madv, without any significant change in locking (ie. it just expands the scope of the lock by a hand- ful of instructions). This prepares the way to decrement the pin_count in the job_run() path without needing to hold the obj lock, to avoid a potential deadlock (or rather stall) caused by the fence-signaling path (job_run()) blocking on shrinker/reclaim. (Only a stall because the wait for fence signaling wait_for_idle() is not infinite.) Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527843/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gem: Move update_lru()Rob Clark1-24/+22
Just code-motion. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527841/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/gem: Export drm_gem_lru_move_tail_locked()Rob Clark1-1/+10
Export the locked version or lru's move_tail(). Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527835/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gem: Simplify vmap vs LRU trackingRob Clark1-9/+8
vmap'ing is just pinning in disguise. So treat it as such and simplify the LRU tracking. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527837/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm: Decouple vma tracking from obj lockRob Clark3-7/+40
We need to use the inuse count to track that a BO is pinned until we have the hw_fence. But we want to remove the obj lock from the job_run() path as this could deadlock against reclaim/shrinker (because it is blocking the hw_fence from eventually being signaled). So split that tracking out into a per-vma lock with narrower scope. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527839/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm/gem: Tidy up VMA APIRob Clark5-40/+51
Stop open coding VMA construction, which will be needed in the next commit. And since the VMA already has a ptr to the adress space, stop passing that around everywhere. (Also, an aspace always has an mmu so we can drop a couple pointless NULL checks.) Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527833/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm: Move submit bo flags update from obj lockRob Clark1-1/+1
The flags are only accessed (1) when submit is constructed, before enqueuing to gpu sched (ie. when still visible to only the task calling the submit ioctl), (2) here, where we own a reference to the submit and are serialized on the gpu sched thread, and (3) after the submit is retired and last reference is dropped, which is serialized on the submit's reference count. Hence locking is unneeded here. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527830/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm/msm: Pre-allocate hw_fenceRob Clark4-5/+20
Avoid allocating memory in job_run() by pre-allocating the hw_fence. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/527832/ Link: https://lore.kernel.org/r/[email protected]
2023-03-25drm: rcar-du: Fix a NULL vs IS_ERR() bugDan Carpenter1-2/+2
The drmm_encoder_alloc() function returns error pointers. It never returns NULL. Fix the check accordingly. Fixes: 7a1adbd23990 ("drm: rcar-du: Use drmm_encoder_alloc() to manage encoder") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]>
2023-03-25drm: rcar-du: Write correct values in DORCR reserved fieldsLaurent Pinchart1-1/+9
The DORCR register controls the routing of clocks and data between DU channels within a group. For groups that contain a single channel, there's no routing option to control, and some fields of the register are then reserved. On Gen2 those reserved fields are documented as required to be set to 0, while on Gen3 and newer the PG1T, DK1S and PG1D reserved fields must be set to 1. The DU driver initializes the DORCR register in rcar_du_group_setup(), where it ignores the PG1T, DK1S and PG1D, and then configures those fields to the correct value in rcar_du_group_set_routing(). This hasn't been shown to cause any issue, but prevents certifying that the driver complies with the documentation in safety-critical use cases. As there is no reasonable change that the documentation will be updated to clarify that those reserved fields can be written to 0 temporarily before starting the hardware, make sure that the registers are always set to valid values. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm: rcar-du: Rename DORCR fields to make them 0-basedLaurent Pinchart2-17/+17
The DORCR fields were documented in the R-Car H1 datasheet with 1-based named, and then got renamed to 0-based in Gen2. The 0-based names are used for Gen3 and Gen4, making H1 an outlier. Rename the field macros to make them 0-based, in order to increase readability of the code when comparing it with the documentation. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm: rcar-du: Disable alpha blending for DU planes used with VSPLaurent Pinchart1-1/+1
When the input to a DU channel comes from a VSP, the DU doesn't perform any blending operation. Select XRGB8888 instead of ARGB8888 to ensure that the corresponding registers don't get written with invalid values. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm: rcar-du: Don't write unimplemented ESCR and OTAR registers on Gen3Laurent Pinchart1-2/+15
The ESCR and OTAR registers are not present in all DU channels on Gen3 SoCs. ESCR only exists in channels that can be routed to an LVDS or DPAD, and OTAR in channels that can be routed to a DPAD. Skip writing those registers for other channels. This replaces the DU gen check, as Gen4 doesn't have LVDS or DPAD outputs. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm: rcar-du: lvds: Fix LVDS PLL disable on D3/E3Laurent Pinchart3-59/+88
On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to the DU, regardless of whether the LVDS output is used or not. When using the DPAD (RGB) output, the DU driver thus enables and disables the LVDS PLL manually, while when using the LVDS output, it lets the LVDS bridge driver handle the PLL configuration internally as part of the atomic enable and disable operations. This causes an issue when using the LVDS output. As bridges are disabled before CRTCs, the current implementation violates the enable/disable sequences documented in the hardware datasheet, which requires the dot clock to be enabled before the CRTC is started and disabled after it gets stopped. Fix the problem by enabling/disabling the LVDS PLL manually from the DU regardless of which output is used, and skipping the PLL handling in the LVDS bridge atomic enable and disable operations. This is however not enough. Disabling the LVDS encoder while leaving the PLL on still results in a vertical blanking wait timeout when disabling the DU. Investigation showed that the culprit is the LVEN bit. For an unclear reason, clearing the bit when disabling the LVDS encoder blocks vertical blanking interrupts. We thus have to delay disabling the whole LVDS encoder, not just disabling the PLL, until the DU is disabled. We could split the LVDS disable sequence by clearing the LVRES bit in the LVDS bridge atomic disable handler, and delaying the rest of the operations, in order to disable the LVDS output at bridge atomic disable time, before stopping the CRTC. This would make the code more complex, without a clear benefit, so keep the implementation simple(r). Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm: rcar-du: lvds: Move LVDS enable code to separate code sectionLaurent Pinchart1-47/+50
To prepare for a rework of the LVDS disable code, which will need to be called from rcar_lvds_pclk_disable(), move the LVDS enable code, currently stored in the __rcar_lvds_atomic_enable() function, to a separate code section separate from bridge operations. It will be then extended with the LVDS disable code. As part of this rework the __rcar_lvds_atomic_enable() function is renamed to rcar_lvds_enable() to more clearly indicate its purpose. No functional change intended. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm: rcar-du: lvds: Call function directly instead of through pointerLaurent Pinchart1-2/+1
When disabling the companion bridge in rcar_lvds_atomic_disable(), there's no need to go through the bridge's operations to call .atomic_disable(). Call rcar_lvds_atomic_disable() on the companion directly. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2023-03-25drm/msm/a6xx: add CONFIG_PM dependencyArnd Bergmann1-0/+1
Selecting CONFIG_PM_GENERIC_DOMAINS causes a build failure when CONFIG_PM is not enabled: WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS Depends on [n]: PM [=n] Selected by [m]: - DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM [=y] || SOC_IMX5 || COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM [=y] || QCOM_OCMEM [=y]=n) && (QCOM_LLCC [=n] || QCOM_LLCC [=n]=n) && (QCOM_COMMAND_DB [=y] || QCOM_COMMAND_DB [=y]=n) && DEVFREQ_GOV_SIMPLE_ONDEMAND [=y] drivers/base/power/domain.c:654:13: error: use of undeclared identifier 'pm_wq' queue_work(pm_wq, &genpd->power_off_work); ^ drivers/base/power/domain.c:853:26: error: no member named 'ignore_children' in 'struct dev_pm_info' if (!dev || dev->power.ignore_children) ~~~~~~~~~~ ^ Fixes: c11fa1204fe9 ("drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc collapse") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/528597/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2023-03-24drm/i915/mtl: Disable C6 on MTL A0 for mediaUmesh Nerlige Ramappa1-0/+7
Earlier merge dropped an if block when applying the patch - "drm/i915/mtl: Synchronize i915/BIOS on C6 enabling". Bring back the if block as the check is required by - "drm/i915/mtl: Disable MC6 for MTL A step" to disable C6 on media for A0 stepping. Fixes: 3735040978a4 ("drm/i915/mtl: Synchronize i915/BIOS on C6 enabling") Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Vinay Belgaumkar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-25drm/i915: Add i915.enable_sagv modparamVille Syrjälä3-0/+8
Currently we have no sane way to forcibly disable SAGV, which makes debugging things a PITA. Manually poking at the pcode mailbox with it's various SAGV/QGV/PSF formats is no fun, and likely to be clobbered by the driver anyway. Let's add a modparam for this. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2023-03-25drm/i915: Move PLANE_BUG_CFG bit definitions to the correct placeVille Syrjälä1-5/+5
All other skl+ universal plane register bit definitions are next to the pipe A register definition. Move the PLANE_BUF_CFG bit definitions there as well. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2023-03-24drm/i915/dpt: Add a modparam to disable DPT via the chicken bitVille Syrjälä9-3/+46
Add i915.enable_dpt modparam to allow disabling the DPT usage in hardware via the chicken bit. Useful when debugging potential DPT issues. Quickly smoke tested on ADL. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Juha-Pekka Heikkila <[email protected]>
2023-03-24Merge tag 'drm-intel-next-2023-03-23' of ↵Daniel Vetter53-875/+2729
git://anongit.freedesktop.org/drm/drm-intel into drm-next Core Changes: - drm: Add SDP Error Detection Configuration Register (Arun) Driver Changes: - Meteor Lake enabling and fixes (RK, Jose, Madhumitha) - Lock the fbdev obj before vma pin (Tejas) - DSC fixes (Stanislav) - Fixes and clean-up on opregion code (Imre) - More wm/vblank stuff (Ville) - More general display code organization (Jani) - DP Fixes (Stanislav, Ville) - Introduce flags to ignore long HPD and link training issues \ for handling spurious issues on CI (Vinod) - Plane cleanups and extra registers (Ville) - Update audio keepalive clock values (Clint) - Rename find_section to bdb_find_section (Maarten) - DP SDP CRC16 for 128b132b link layer (Arun) - Fix various issues with noarm register writes (Ville) - Fix a few TypeC / MST issues (Imre) - Create GSC submission targeting HDCP and PXP usages on MTL+ (Suraj) - Enable HDCP2.x via GSC CS (Suraj) Signed-off-by: Daniel Vetter <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24Merge tag 'drm-misc-next-2023-03-23' of ↵Daniel Vetter41-781/+659
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.4-rc1: Core Changes: - Add unit test for xrgb8888 to mono. - Assorted small fixes to format helper selftests. - Assorted documentation updates. - Drop drm_dev_set_unique. - Always use shadow buffer in generic fbdev emulation helpers, and improve error handling. Driver Changes: - Assorted small fixes to malidp, hdlcd, gma500, lima, bridge, rockchip. - Move fbdev in gma500 to use drm_client. - Convert bridge platform callbacks to void return. - Drop leftover from vgem to shmem helper conversion. Signed-off-by: Daniel Vetter <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOSUmesh Nerlige Ramappa1-0/+31
OAM does not work with media C6 enabled on some steppings of MTL. Disable OAM if we detect that media C6 was enabled in bios. v2: (Ashutosh) - Remove drm_notice from the driver load path - Log a drm_err when opening an OAM stream on affected steppings v3: - Initialize the engine group even if mc6 is enabled (Ashutosh) - Checkpatch fix Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-24drm/i915/perf: Pass i915 object to perf revision helperUmesh Nerlige Ramappa3-3/+3
In some cases, perf revision may rely on specific steppings of a platform. To determine the platform, pass i915 object to the perf revision helper. Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.