aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-07-30drm/ast: astdp: Perform link training during atomic_enableThomas Zimmermann4-25/+26
The place for link training is in the encoder's atomic_enable helper. Remove all related tests from other helper ASTDP functions; especially ast_astdp_is_connected(), which tests HPD status. DP link training is controlled by the firmware. A status flag reports success or failure. The process can be fragile on Aspeed hardware. Moving the test from connector detection to the atomic_enable allows for several retries and a longer timeout. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-30drm/ast: astdp: Only test HDP state in ast_astdp_is_connected()Thomas Zimmermann2-11/+4
The overall control flow of the driver ensures that it never reads EDID or sets display state on unconnected outputs. Therefore remove all tests for Hot Plug Detection from these helpers. Also rename the register constants. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-30drm/ast: astdp: Test firmware status once during probingThomas Zimmermann5-32/+23
Test for running ASTDP firmware during probe. Do not bother testing this later. We cannot do much anyway if the firmware fails. Do not initialize the ASTDP conenctor if the test fails during device probing. Signed-off-by: Thomas Zimmermann <[email protected]> Reported-by: Shixiong Ou <[email protected]> Tested-by: Shixiong Ou <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-30MAINTAINERS: Add selftests to DMA-BUF HEAPS FRAMEWORK entryZenghui Yu1-0/+1
Include dmabuf-heaps selftests in the correct entry so that updates to it can be sent to the right place. Signed-off-by: Zenghui Yu <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-30drm: Add the missing symbol '.'Shixiong Ou1-1/+1
Signed-off-by: Shixiong Ou <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-29drm/nouveau: remove unused variable retJani Nikula1-1/+0
Fix build with CONFIG_NOUVEAU_PLATFORM_DRIVER enabled: ../drivers/gpu/drm/nouveau/nouveau_platform.c: In function ‘nouveau_platform_probe’: ../drivers/gpu/drm/nouveau/nouveau_platform.c:29:13: error: unused variable ‘ret’ [-Werror=unused-variable] 29 | int ret; | ^~~ Fixes: 961ae5f9807b ("drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common code") Cc: Ben Skeggs <[email protected]> Cc: Danilo Krummrich <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-29Merge drm/drm-next into drm-misc-nextThomas Zimmermann2694-28715/+387543
Backmerging to get a late RC of v6.10 before moving into v6.11. Signed-off-by: Thomas Zimmermann <[email protected]>
2024-07-29drm/gma500: Make I2C terminology more inclusiveEaswar Hariharan8-32/+32
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave" with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/, fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists in the specification. Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Easwar Hariharan <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/kms: remove push pointer from nv50_dmacBen Skeggs30-124/+122
The struct itself lives in nv50_dmac already, just use that. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/kms: remove a few unused struct members and fn declsBen Skeggs2-12/+0
Left-overs from the past that are completely unused now. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: remove push pointer from nouveau_channelBen Skeggs18-54/+53
The struct itself lives in nouveau_channel already, just use that. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: remove masterBen Skeggs3-31/+23
The only remaining nouveau_drm.master struct member that's being used is the mutex that protects its object tree. Move that into nouveau_drm and remove nouveau_drm.master entirely. A pending series to remove the "ioctl" layer between DRM and NVKM also removes the need for object handle lookups, and hence this mutex, but it's still required for the moment. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: remove chan->drmBen Skeggs11-38/+34
The nouveau_cli that owns the channel is now stored in nouveau_chan, and it has a pointer to the drm device already. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: remove nouveau_chan.deviceBen Skeggs2-4/+3
nouveau_chan.device is always the same as nouveau_chan.cli.device, so there's no need to store it separately. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: pass cli to nouveau_channel_new() instead of drm+deviceBen Skeggs6-16/+18
Both of these are stored in nouveau_cli already, and also allows the removal of some void casts. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: pass drm to nv50_dmac_create(), rather than device+dispBen Skeggs7-12/+10
Both of these are stored in nouveau_drm already. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: pass drm to nouveau_mem_new(), instead of cliBen Skeggs4-17/+15
The nouveau_cli pointer is only ever used to eventually access nouveau_drm, so just store it directly. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: add nvif_mmu to nouveau_drmBen Skeggs3-20/+28
This allocates a new nvif_mmu in nouveau_drm, and uses it for TTM backend memory allocations instead of nouveau_drm.master.mmu, which is removed by a later commit that removes nouveau_drm.master entirely. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: move nvxx_* definitions to nouveau_drv.hBen Skeggs20-90/+92
These are some dodgy "convenience" macros for the DRM driver to peek into NVKM state. They're still used in a few places, but don't belong in nvif/device.h in any case. Move them to nouveau_drv.h, and modify callers to pass a nouveau_drm instead of an nvif_device. v2: - use drm->nvkm pointer for nvxx_*() macros, removing some void* v3: - add some explanation of the nvxx_*() macros Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove disp chan rd/wrBen Skeggs9-178/+10
There's no good reason the ioremap() that results from nvif_object_map() should fail, so add a check that the map succeeded, and remove the rd/wr methods from display channel objects. As this was the last user of rd/wr methods, the nvif plumbing is removed at the same time. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove device rd/wrBen Skeggs5-132/+0
The previous commit ensures the device is always mapped, so these are unneeded. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: always map deviceBen Skeggs5-5/+25
The next commit removes the nvif rd/wr methods from nvif_device, which were probably a bad idea, and mostly intended as a fallback if ioremap() failed (or wasn't available, as was the case in some tools I once used). The nv04 KMS driver already mapped the device, because it's mostly been kept alive on life-support for many years and still directly bashes PRI a lot for modesetting. Post-nv50, I tried pretty hard to keep PRI accesses out of the DRM code, but there's still a few random places where we do, and those were using the rd/wr paths prior to this commit. This allocates and maps a new nvif_device (which will replace the usage of nouveau_drm.master.device later on), and replicates this pointer to all other possible users. This will be cleaned up by the end of another patch series, after it's been made safe to do so. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove device argsBen Skeggs5-53/+9
These were once used by used by userspace tools (with nvkm built as a library), to access multiple GPUs from a single nvif_client. The DRM code just uses the driver's default device, so remove the arguments. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove client finiBen Skeggs1-7/+0
Does nothing. Remove it. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove client devlistBen Skeggs4-64/+0
This was once used by userspace tools (with nvkm built as a library), but is now unused. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove client versionBen Skeggs4-40/+2
This is not, and has never, been used for anything. Remove it. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove client device argBen Skeggs6-11/+6
This was once used by userspace tools (with nvkm built as a library), as a way to select a "default device". The DRM code doesn't need this at all as clients only have access to a single device already, so inherit the value from its parent. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove driver keep/finiBen Skeggs3-8/+1
These are remnants of code long gone. Remove them. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove nvxx_client()Ben Skeggs4-10/+2
Make use of nouveau_cli.name instead of nvkm_client.name. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove nvxx_object()Ben Skeggs3-26/+19
This hasn't been used in a while. Moves io accessors from nvkm/core/os.h to nvif/os.h at the same time to fix a compile issue that results from <nvkm/core/object.h> no longer being included. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove route/tokenBen Skeggs10-38/+6
These were a cludge used to prevent userspace's nvif ioctl from accessing objects created by the kernel for the same client. That interface was removed in a previous patch, so these are no longer useful for anything. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvif: remove support for userspace backendsBen Skeggs2-28/+7
The tools that used libnvkm no longer exist. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvkm: remove nvkm_client_search()Ben Skeggs2-14/+0
Has been unused for a while now. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvkm: remove perfmonBen Skeggs23-2502/+1
This has never really been used for anything, in part due to never having reclocking stable enough in general to attempt to implement dynamic clock changes based on load, etc. To avoid having to rework its interfaces, remove it entirely. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau/nvkm: remove detect/mmio/subdev_mask from device argsBen Skeggs7-231/+209
All callers now pass "detect=true, mmio=true, subdev_mask=~0ULL", so remove the function arguments, and associated code. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: remove abi16->handlesBen Skeggs1-1/+0
Hasn't been needed since 2015... Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: remove abi16->deviceBen Skeggs2-23/+3
The previous commit removes the last remnants of userspace's own nvif instance, so this isn't needed anymore to hide the abi16 objects from userspace and we can use nouveau_cli.device instead. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: handle limited nvif ioctl in abi16Ben Skeggs7-249/+251
nouveau_usif.c was already stripped right back a couple of years ago, limiting what userspace could do with it. A follow-on series removes the nvkm side of these interfaces entirely, in order to make it less of a nightmare to add/change internal APIs in the future. Unfortunately. Userspace uses some of this. Fortunately, userspace only ever ended up using a fraction of the APIs, so those are reimplemened here in a more direct manner, and return -EINVAL to userspace for everything else. v2: - simplified struct nouveau_abi16_obj - added a couple of comments v3: - comment harder Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: add nouveau_cli to nouveau_abi16Ben Skeggs2-4/+6
Store a pointer to struct nouveau_cli in struct nouveau_abi16 to avoid some dubious void casts. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: move allocation of root client out of nouveau_cli_init()Ben Skeggs1-17/+19
drm->master isn't really a nouveau_cli, and is mostly just used to get at an nvif_mmu object to implement a hack around issues with the ioctl interface to nvkm. Later patches in this series allocate nvif_device/mmu objects in nouveau_drm directly, removing the need for master. A pending series to remove the "ioctl" layer between DRM and NVKM removes the need for the above-mentioned hack entirely. The only other member of drm->master that's needed is the nvif_client, and is a dependency of device/mmu. So the first step is to move its allocation out of code handling nouveau_cli init. v2: - modified slightly due to the addition of tegra/pci cleanup patches v3: - move nvif init below drm_dev_alloc() to avoid changing nouveau_name() Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: store nvkm_device pointer in nouveau_drmBen Skeggs2-11/+13
There's various different places in the drm code that get at the nvkm_device via various creative (and not very type-safe) means. One of those being via nvif_device.object.priv. Another patch series is going to entirely remove the ioctl-like interfaces beween the drm code and nvkm, and that field will no longer exist. This provides a safer replacement for accessing the nvkm_device, and will used more in upcoming patches to cleanup other cases. v2: - fixup printk macros to not oops if used before client ctor Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: create pci device onceBen Skeggs1-9/+2
HW isn't touched anymore (aside from detection) until the first nvif_device has been allocated, so we no longer need a separate probe-only step before kicking efifb (etc) off the HW. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: replace drm_device* with nouveau_drm* as dev drvdataBen Skeggs7-64/+58
We almost always want to cast the pointer from dev_get_drvdata() to 'struct nouveau_drm *', so just directly store that pointer instead, simplifying callers, and fixing some clumsy naming of dev/drm_dev variables at the same time. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common codeBen Skeggs2-39/+60
Unify some more of the PCI/Tegra DRM driver init, both as a general cleanup, and because a subsequent commit changes the pointer stored via dev_set_drvdata(), and this allows the change to be made in one place. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-27drm/nouveau: move nouveau_drm_device_fini() above init()Ben Skeggs1-53/+53
The next commit wants to be able to call fini() from an init() failure path to remove the need to duplicate a bunch of cleanup. Moving fini() above init() avoids the need for a forward-declaration. Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-26drm/vblank: add dynamic per-crtc vblank configuration supportHamza Mahfooz3-26/+97
We would like to be able to enable vblank_disable_immediate unconditionally, however there are a handful of cases where a small off delay is necessary (e.g. with PSR enabled). So, we would like to be able to adjust the vblank off delay and disable imminent values dynamically for a given CRTC. Since, it will allow drivers to apply static screen optimizations more quickly and consequently allow users to benefit more so from the power savings afforded by the aforementioned optimizations, while avoiding issues in cases where an off delay is still warranted. In particular, the PSR case requires a small off delay of 2 frames, otherwise display firmware isn't able to keep up with all of the requests made to amdgpu. So, introduce drm_crtc_vblank_on_config() which is like drm_crtc_vblank_on(), but it allows drivers to specify the vblank CRTC configuration before enabling vblanking support for a given CRTC. Signed-off-by: Hamza Mahfooz <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-26drm/panel-edp: Add CSW MNB601LS1-4Haikun Zhou1-0/+1
Add support for the CSW MNB601LS1-4, pleace the EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0e 77 04 11 00 00 00 00 00 22 01 04 a5 1a 0e 78 03 a1 35 9b 5e 58 91 25 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 09 1e 56 dc 50 00 28 30 30 20 36 00 00 90 10 00 00 1a 00 00 00 fd 00 28 3c 30 30 08 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43 53 4f 54 20 54 39 0a 20 20 20 20 20 00 00 00 fe 00 4d 4e 42 36 30 31 4c 53 31 2d 34 0a 20 00 20 Signed-off-by: Haikun Zhou <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240725115229.3416028-1-zhouhaikun5@huaqin.corp-partner.google.com
2024-07-26accel/qaic: Remove the description of DRM_IOCTL_QAIC_PART_DEVZenghui Yu1-6/+0
The partition device ioctl was removed during the development of the initial version of qaic driver. Remove its description from the documentation to avoid confusing readers. Signed-off-by: Zenghui Yu <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-25drm/ci: update link to Gitlab serverDeborah Brouwer1-1/+1
Before building an image, the build script looks to see if there are fixes to apply from an upstream repository. The link for the upstream repository git://anongit.freedesktop.org/drm/drm became obsolete with the move to Gitlab server in March 2024. Until recently, this obsolete link was harmless because anongit would at least respond that there were no such fixes available. In the last few days anongit has stopped responding to requests causing the build script to hang indefinitely. Update the link from anongit to the Gitlab server to prevent the build script from hanging indefinitely. Signed-off-by: Deborah Brouwer <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-07-26Merge tag 'amd-drm-fixes-6.11-2024-07-25' of ↵Dave Airlie20-17/+261
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-6.11-2024-07-25: amdgpu: - SDMA 5.2 workaround - GFX12 fixes - Uninitialized variable fix - VCN/JPEG 4.0.3 fixes - Misc display fixes - RAS fixes - VCN4/5 harvest fix - GPU reset fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]