aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-10-13drm/amd/display: add missing NULL check for DML2Bob Zhou1-1/+1
Recently, the driver introduce DML2 for future ASIC support. But, some ASIC's hubbub pointer is null before calling. It cause the below null pointer issue, so add null check to fix it. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:dc_create_resource_pool+0xc1/0x2c0 [amdgpu] Call Trace: <TASK> ? show_regs.cold+0x1a/0x1f ? __die_body+0x20/0x70 ? __die+0x2b/0x37 ? page_fault_oops+0x136/0x2c0 ? do_user_addr_fault+0x303/0x660 ? exc_page_fault+0x77/0x170 ? asm_exc_page_fault+0x27/0x30 ? dc_create_resource_pool+0xc1/0x2c0 [amdgpu] ? dc_create_resource_pool+0x243/0x2c0 [amdgpu] dc_create+0x23f/0x6b0 [amdgpu] ? dmi_matches+0xa3/0x200 amdgpu_dm_init+0x2bd/0x22a0 [amdgpu] Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2") Signed-off-by: Bob Zhou <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/umsch: enable doorbell for umschLang Yu2-2/+3
Program vcn_doorbell_range with vcn_ring0_1. Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Veerabadhran Gopalakrishnan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/display: make dc_set_power_state() return type `void` againMario Limonciello3-17/+8
As dc_set_power_state() no longer allocates memory, it's not necessary to have return types and check return code as it can't fail anymore. Change it back to `void`. Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/display: Destroy DC context while keeping DML and DML2Mario Limonciello2-37/+12
If there is memory pressure at suspend time then dynamically allocating a large structure as part of DC suspend code will fail. Instead re-use the same structures and clear all members except those that should be maintained. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2362 Acked-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/display: Catch errors from drm_atomic_helper_suspend()Mario Limonciello1-0/+2
drm_atomic_helper_suspend() can return PTR_ERR(), in which case the error gets stored into `dm->cached_state`. This can cause failures during resume. Catch the error during suspend and fail the suspend instead. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2362 Acked-by: Christian König <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd: Split up UVD suspend into prepare and suspend stepsMario Limonciello7-4/+49
amdgpu_uvd_suspend() allocates memory and copies objects into that allocated memory. This fails under memory pressure. Instead move majority of this code into a prepare step when swap can still be allocated. Reviewed-by: Christian König <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd: Add concept of running prepare_suspend() sequence for IP blocksMario Limonciello2-1/+12
If any IP blocks allocate memory during their hw_fini() sequence this can cause the suspend to fail under memory pressure. Introduce a new phase that IP blocks can use to allocate memory before suspend starts so that it can potentially be evicted into swap instead. Reviewed-by: Christian König <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd: Evict resources during PM ops prepare() callbackMario Limonciello3-8/+34
Linux PM core has a prepare() callback run before suspend. If the system is under high memory pressure, the resources may need to be evicted into swap instead. If the storage backing for swap is offlined during the suspend() step then such a call may fail. So move this step into prepare() to move evict majority of resources and update all non-pmops callers to call the same callback. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2362 Reviewed-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: enable GFX IP v11.5.0 CG and PG supportLi Ma3-3/+23
Add CG support for GFX/MC/HDP/ATHUB/IH/BIF. Add PG support for GFX. Signed-off-by: Li Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: add support to power up/down UMSCH by SMULang Yu2-0/+27
Power up/down UMSCH by SMU. Signed-off-by: Lang Yu <[email protected]> Acked-by: Leo Liu <[email protected]> Acked-by: Veerabadhran Gopalakrishnan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: add power up/down UMSCH ppt callbackLang Yu3-1/+24
Add ppt callback to power up/down UMSCH. v2: squash in updates (Alex) Signed-off-by: Lang Yu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: add support to powerup VPE by SMULang Yu3-0/+31
Powerup VPE by SMU. Signed-off-by: Lang Yu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/discovery: add SMU 14 supportLi Ma3-0/+12
add smu 14 into the IP discovery list. Signed-off-by: Li Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/swsmu: add smu14 ip supportKenneth Feng10-3/+3110
Add initial swSMU support for smu 14 series ASIC. v2: squash in build fixes and updates (Li Ma) fix warnings (Alex) v3: squash in updates (Alex) v4: squash in updates (Alex) v5: squash in avg/current power updates (Alex) Signed-off-by: Li Ma <[email protected]> Signed-off-by: Kenneth Feng <[email protected]> Signed-off-by: Likun Gao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/swsmu: add smu v14_0_0 pmfw if fileLi Ma1-0/+156
Add initial smu v14_0_0 pmfw if file v2: squash in updates (Alex) Signed-off-by: Li Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/swsmu: add smu v14_0_0 ppsmc fileLi Ma1-0/+142
Add initial smu v14_0_0 ppsmc file v2: squash in updates (Alex) v3: squash in updates (Alex) Signed-off-by: Li Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/swsmu: add smu v14_0_0 driver if fileLi Ma1-0/+281
Add initial smu v14_0_0 driver if file v2: squash in updates (Alex) v3: update interface (Alex) Signed-off-by: Li Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/umsch: power on/off UMSCH by DLDOLang Yu1-0/+26
VCN 4.0.5 uses DLDO. Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Veerabadhran Gopalakrishnan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/umsch: fix psp frontdoor loadingLang Yu3-88/+72
These changes are missed in rebase. Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Veerabadhran Gopalakrishnan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: Increase IP discovery region sizeLijo Lazar1-1/+1
IP discovery region has increased to > 8K on some SOCs.Maximum reserve size is upto 12K, but not used. For now increase to 10K. Signed-off-by: Lijo Lazar <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/pm: Use gpu_metrics_v1_4 for SMUv13.0.6Asad Kamal1-24/+41
Use gpu_metrics_v1_4 for SMUv13.0.6 to fill gpu metric info v3: Removed filling gpu metric instantaneous pcie bw Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/pm: Add gpu_metrics_v1_4Asad Kamal2-0/+79
Add new gpu_metrics_v1_4 to acquire XGMI data transfer, pcie bandwidth & Clock lock status v2: Add pcie error counter to gpu metric table v1_4 Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/pm: Update metric table for smu v13_0_6Asad Kamal1-1/+5
Update pmfw metric table to include xgmi transfer data and pci instantaneous bandwidth for smu v13_0_6 v2: Updated metric table version v3: Removed inst pcie bw with alignment to metrics table version 8 Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: Return -EINVAL when MMSCH init status incorrectLin.Cao1-1/+4
Return -EINVAL when MMSCH init fail which can be handle by function amdgpu_device_reset_sriov correctly. Signed-off-by: Lin.Cao <[email protected]> Reviewed-by: Jingwen Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amd/pm: wait for completion of the EnableGfxImu commandTim Huang1-2/+10
Wait for completion of sending the EnableGfxImu message when using the PSP FW loading. Signed-off-by: Tim Huang <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/vpe: fix insert_nop opsLang Yu1-4/+5
Avoid infinite loop when count is 0. This is missed in rebase. Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: Address member 'gart_placement' not described in ↵Srinivasan Shanmugam1-0/+1
'amdgpu_gmc_gart_location' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:274: warning: Function parameter or member 'gart_placement' not described in 'amdgpu_gmc_gart_location' Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/vpe: align with mcbp changesLang Yu1-1/+1
MCBP is decided by adev->gfx.mcbp now. This is missed in rebase. Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu/vpe: remove IB end boundary requirementLang Yu1-19/+1
Remove IB end boundary requirement, VPE has no such limitions, use existing amdgpu_ring_generic_pad_ib() instead. This is missed in rebase. Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/amdgpu: Improve MES responsiveness during oversubscriptionJay Cornwall1-0/+1
When MES is oversubscribed it may not frequently check for new command submissions from driver if the scheduling load is high. Response latency as high as 5 seconds has been observed. Enable a flag which adds a check for new commands between scheduling quantums. Signed-off-by: Jay Cornwall <[email protected]> Cc: Alexandru Tudor <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-13drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: switch to drm_do_get_edid()Ian Ray1-48/+9
Migrate away from custom EDID parsing and validity checks. Note: This is a follow-up to the original RFC by Jani [1]. The first submission in this series should have been marked v2. [1] https://patchwork.freedesktop.org/patch/msgid/[email protected] Co-developed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Ian Ray <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-13drm/i915/dsb: Re-instate DSB for LUT updatesVille Syrjälä1-3/+0
With all the known issues sorted out we can start to use DSB to load the LUTs. Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-13drm/i915/dsb: Correct DSB command buffer cache coherency settingsVille Syrjälä1-4/+11
The display engine does not snoop the caches so we should mark the DSB command buffer as I915_CACHE_NONE. i915_gem_object_create_internal() always gives us I915_CACHE_LLC on LLC platforms. And to make things 100% correct we should also clflush at the end, if necessary. Note that currently this is a non-issue as we always write the command buffer through a WC mapping, so a cache flush is not actually needed. But we might actually want to consider a WB mapping since we also end up reading from the command buffer (in the indexed reg write handling). Either that or we should do something else to avoid those reads (might actually be even more sensible on DGFX since we end up reading over PCIe). But we should measure the overhead first... Anyways, no real harm in adding the belts and suspenders here so that the code will work correctly regardless of how we map the buffer. If we do get a WC mapping (as we request) i915_gem_object_flush_map() will be a nop. Well, apart form a wmb() which may just flush the WC buffer a bit earlier than would otherwise happen (at the latest the mmio accesses would trigger the WC flush). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-10-13drm/i915/dsb: Allocate command buffer from local memoryVille Syrjälä1-1/+6
Using system memory for the DSB command buffer doesn't appear to work. On DG2 it seems like the hardware internally replaces the actual memory reads with zeroes, and so we end up executing a bunch of NOOPs instead of whatever commands we put in the buffer. To determine that I measured the time it takes to execute the instructions, and the results are always more or less consistent with executing a buffer full of NOOPs from local memory. Another theory I considered was some kind of cache coherency issue. Looks like i915_gem_object_pin_map_unlocked() will in fact give you a WB mapping for system memory on DGFX regardless of what mapping mode was requested (WC in case of the DSB code). But clflush did not change the behaviour at all, so that theory seems moot. On DG1 it looks like the hardware might actually be fetching data from system memory as the logs indicate that we just get underruns. But that is equally bad, so doesn't look like we can really use system memory on DG1 either. Thus always allocate the DSB command buffer from local memory on discrete GPUs. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Uma Shankar <[email protected]>
2023-10-13drm/i915/lnl: Remove watchdog timers for PSRMika Kahola1-3/+7
Watchdog timers for Lunarlake HW were removed for PSR/PSR2 The patch removes the use of these timers from the driver code. BSpec: 69895 v2: Reword commit message (Ville) Drop HPD mask from LNL (Ville) Revise masking logic (Jouni) v3: Revise commit message (Ville) Revert HPD mask removal as irrelevant for this patch (Ville) Signed-off-by: Mika Kahola <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Signed-off-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-13pwm: Manage owner assignment implicitly for driversUwe Kleine-König1-1/+0
Instead of requiring each driver to care for assigning the owner member of struct pwm_ops, handle that implicitly using a macro. Note that the owner member has to be moved to struct pwm_chip, as the ops structure usually lives in read-only memory and so cannot be modified. The upside is that new low level drivers cannot forget the assignment and save one line each. The pwm-crc driver didn't assign .owner, that's not a problem in practice though as the driver cannot be compiled as a module. Acked-by: Andy Shevchenko <[email protected]> # Intel LPSS Reviewed-by: Florian Fainelli <[email protected]> # pwm-{bcm,brcm}*.c Acked-by: Jernej Skrabec <[email protected]> # sun4i Acked-by: Andi Shyti <[email protected]> Acked-by: Nobuhiro Iwamatsu <[email protected]> # pwm-visconti Acked-by: Heiko Stuebner <[email protected]> # pwm-rockchip Acked-by: Michael Walle <[email protected]> # pwm-sl28cpld Acked-by: Neil Armstrong <[email protected]> # pwm-meson Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2023-10-13Merge tag 'amd-drm-fixes-6.6-2023-10-11' of ↵Dave Airlie3-1/+8
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.6-2023-10-11: amdgpu: - Seemless boot fix - Fix TTM BO resource check - SI fix for doorbell handling Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-13Merge tag 'drm-msm-fixes-2023-10-07' of ↵Dave Airlie5-23/+42
https://gitlab.freedesktop.org/drm/msm into drm-fixes Fixes for v6.6-rc5 - fix to not reset the PHY everytime we start link training but only do it if link training fails. Without this, the PLL unlocked interrupt fires causing "Unexpected DP AUX IRQ 0x01000000 when not busy" spam in the logs since last 2-3 cycles - correct the highest bank bit to match downstream device tree for msm8998 - skip the video mode wait if the timing engine is not enabled. This was introduced after pre_enable flag for DSI video mode panels where we would end up waiting for the video mode done interrupt even before enabling timing engine causing error spam and long bootup times. - check the correct return code of irq_of_parse_and_map() in DSI code - avoid overflow issues in the dpu bandwidth calculation . This was exposed for high resolution displays and a critical fix to avoid atomic_check failure - minor fix to add new lines in DP print messages. - Fix to fail atomic_check() if the resolution exceeds max mdp clk. This leads to underflow otherwise if we try to allow that frame. Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGv-HNxQ=VBtZ8geGzYJum9jtManEdbvhcjo_WWF_J9Ziw@mail.gmail.com
2023-10-13Merge tag 'drm-misc-fixes-2023-10-12' of ↵Dave Airlie16-61/+89
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * atomic-helper: Relax checks for unregistered connectors * dma-buf: Work around race condition when retrieving fence timestamp * gem: Avoid OOB access in BO memory range * panel: * boe-tv101wun-ml6: Fix flickering * simpledrm: Fix error output * vwmgfx: * Fix size calculation in texture-state code * Ref GEM BOs in surfaces Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231012111638.GA25037@linux-uq9g
2023-10-12drm/nouveau/disp: fix DP capable DSM connectorsKarol Herbst1-1/+13
Just special case DP DSM connectors until we properly figure out how to deal with this. This resolves user regressions on GPUs with such connectors without reverting the original fix. Cc: Lyude Paul <[email protected]> Cc: [email protected] # 6.4+ Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/255 Fixes: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts") Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simpleDouglas Anderson2-29/+35
In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") I moved a pile of panels out of panel-simple driver into the newly created panel-edp driver. One of those panels, however, shouldn't have been moved. As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in exynos5250-snow and exynos5420-peach-pit where it's clear that the panel is hooked up with LVDS. Furthermore, searching for datasheets I found one that makes it clear that this panel is LVDS. As far as I can tell, I got confused because in commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the downstream ChromeOS trees, it seems like some Mediatek boards are using a panel that they call "auo,b116xw03" that's an eDP panel. The best I can guess is that they actually have a different panel that has similar timing. If so then the proper panel should be used or they should switch to the generic "edp-panel" compatible. When moving this back to panel-edp, I wasn't sure what to use for .bus_flags and .bus_format and whether to add the extra "enable" delay from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on"). I've added formats/flags/delays based on my (inexpert) analysis of the datasheet. These are untested. NOTE: if/when this is backported to stable, we might run into some trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move panel under aux-bus") this panel was used by "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't know what to suggest for that other than someone making up a bogus panel for jacuzzi that's just for the stable channel. Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") Tested-by: Anton Bambura <[email protected]> Acked-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230925150010.1.Iff672233861bcc4cf25a7ad0a81308adc3bda8a4@changeid
2023-10-12drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary deviceStephen Boyd1-7/+7
The kernel produces a warning splat and the DSI device fails to register in this driver if the i2c driver probes, populates child auxiliary devices, and then somewhere in ti_sn_bridge_probe() a function call returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi device created by devm_mipi_dsi_device_register_full() is left registered because the devm managed device used to manage the lifetime of the DSI device is the parent i2c device, not the auxiliary device that is being probed. Associate the DSI device created and managed by this driver to the lifetime of the auxiliary device, not the i2c device, so that the DSI device is removed when the auxiliary driver unbinds. Similarly change the device pointer used for dev_err_probe() so the deferred probe errors are associated with the auxiliary device instead of the parent i2c device so we can narrow down future problems faster. Cc: Douglas Anderson <[email protected]> Cc: Maxime Ripard <[email protected]> Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)Hans de Goede1-0/+3
Add some debug logging to mipi_exec_i2c, to make debugging various issues seen with it easier. Changes in v2: - Drop unnecessary __func__ drm_dbg_kms() argument Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga ↵Hans de Goede1-0/+34
Tab 3 (v2) On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight on/off MIPI sequences: 1. The backlight on sequence has an I2C MIPI sequence element which uses bus 0, but there is a bogus I2cSerialBus resource under the GPU in the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus. 2. There is no backlight off sequence, causing the backlight to stay on. Add a DMI quirk fixing both issues. v2: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380 Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo ↵Hans de Goede1-0/+52
Yoga Tablet 2 series (v3) On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems: 1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7 which under Linux become bus 0 - 6. And the MIPI sequence reference to bus 3 is indented for I2C3 which is bus 2 under Linux. This leads to errors like these: [ 178.244049] i2c_designware 80860F41:03: controller timed out [ 178.245703] i915 0000:00:02.0: [drm] *ERROR* Failed to xfer payload of size (1) to reg (169) There are 3 timeouts when the panel is on, delaying waking up the screen on a key press by 3 seconds. Note mipi_exec_i2c() cannot just subtract 1 from the bus given in the I2C MIPI sequence element. Since on other devices the I2C bus-numbers used in the MIPI sequences do actually start at 0. 2. width_/height_mm contain a bogus 192mm x 120mm size. This is especially a problem on the 8" 830 version which uses a 10:16 portrait screen where as the bogus size is 16:10. Add a DMI quirk to override the I2C bus and the panel size with the correct values. Note both the 10" 1050 models as well as the 8" 830 models use the same mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200 landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen, so the quirk handling uses the display resolution to detect the model. v2: - Also override i2c_bus_num to fix mipi_exec_i2c() timeouts v3: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379 Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus ↵Hans de Goede1-0/+44
TF103C (v3) Vtotal is wrong in the BIOS supplied modeline for the DSI panel on the Asus TF103C leading to the last line of the display being shown as the first line. Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa Fixed: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 0xa The factory installed Android has a hardcoded modeline in its kernel, causing it to not suffer from this BIOS bug; and the Android boot-splash which uses the EFI FB which does have this bug has the last line all black causing the bug to not be visible. This commit introduces a generic DMI based quirk mechanism to vlv_dsi for doing various fixups, and uses this to correct the modeline. v2: - s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic - Add a comment with the old and new modelines to the patch and commit msg v3: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381 Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/tiny: correctly print `struct resource *` on errorJoey Gouly1-1/+1
The `res` variable is already a `struct resource *`, don't take the address of it. Fixes incorrect output: simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [??? 0xffff4be88a387d00-0xfffffefffde0a240 flags 0x0]: -16 To be correct: simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16 Signed-off-by: Joey Gouly <[email protected]> Fixes: 9a10c7e6519b ("drm/simpledrm: Add support for system memory framebuffers") Cc: Thomas Zimmermann <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: [email protected] Cc: <[email protected]> # v6.3+ Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm: Do not overrun array in drm_gem_get_pages()Matthew Wilcox (Oracle)1-2/+4
If the shared memory object is larger than the DRM object that it backs, we can overrun the page array. Limit the number of pages we install from each folio to prevent this. Signed-off-by: "Matthew Wilcox (Oracle)" <[email protected]> Reported-by: Oleksandr Natalenko <[email protected]> Tested-by: Oleksandr Natalenko <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: 3291e09a4638 ("drm: convert drm_gem_put_pages() to use a folio_batch") Cc: [email protected] # 6.5.x Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/simpledrm: Fix power domain device link validity checkThierry Reding1-1/+1
We need to check if a link is non-NULL before trying to delete it. Fixes: 61df9ca23107 ("drm/simpledrm: Add support for multiple "power-domains"") Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Cc: Janne Grunau <[email protected]> Cc: Eric Curtin <[email protected]> Cc: Neal Gompa <[email protected]> Cc: Sven Peter <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm: Replace drm_framebuffer plane size functions with its equivalentsCarlos Eduardo Gallo Filho2-61/+5
The functions drm_framebuffer_plane_{width,height} and fb_plane_{width,height} do exactly the same job of its equivalents drm_format_info_plane_{width,height} from drm_fourcc. The only reason to have these functions on drm_framebuffer would be if they would added a abstraction layer to call it just passing a drm_framebuffer pointer and the desired plane index, which is not the case, where these functions actually implements just part of it. In the actual implementation, every call to both drm_framebuffer_plane_{width,height} and fb_plane_{width,height} should pass some drm_framebuffer attribute, which is the same as calling the drm_format_info_plane_{width,height} functions. The drm_format_info_pane_{width,height} functions are much more consistent in both its implementation and its location on code. The kind of calculation that they do is intrinsically derivated from the drm_format_info struct and has not to do with drm_framebuffer, except by the potential motivation described above, which is still not a good justification to have drm_framebuffer functions to calculate it. So, replace each drm_framebuffer_plane_{width,height} and fb_plane_{width,height} call to drm_format_info_plane_{width,height} and remove them. Signed-off-by: Carlos Eduardo Gallo Filho <[email protected]> Reviewed-by: André Almeida <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.