On Thu, Mar 24, 2022 at 3:32 AM Dave Airlie airlied@gmail.com wrote:
Hi Linus,
This is the main drm pull request for 5.18.
The summary changelog is below, lots of work all over, Intel improving DG2 support, amdkfd CRIU support, msm new hw support, and faster fbdev support.
Conflicts: I did a merge into your tree this morning, couple of Kconfig clashes, drm_cache.c needs an ioport.h include to avoid a build fail due to other header refactoring. I think you should be able to handle it.
External interactions:
- dma-buf-map gets renamed to iosys-map
- this adds a yes/no helper to the strings helpers, and it's used in some other code.
- platform driver for chromeos privacy screen
Let me know if there are any issues.
Regards, Dave.
drm-next-2022-03-24: drm for 5.18-rc1
dma-buf:
- rename dma-buf-map to iosys-map
core:
- move buddy allocator to core
- add pci/platform init macros
- improve EDID parser deep color handling
- EDID timing type 7 support
- add GPD Win Max quirk
- add yes/no helpers to string_helpers
- flatten syncobj chains
- add nomodeset support to lots of drivers
- improve fb-helper clipping support
- add default property value interface
fbdev:
- improve fbdev ops speed
ttm:
- add a backpointer from ttm bo->ttm resource
dp:
- move displayport headers
- add a dp helper module
bridge:
- anx7625 atomic support, HDCP support
panel:
- split out panel-lvds and lvds bindings
- find panels in OF subnodes
privacy:
- add chromeos privacy screen support
fb:
- hot unplug fw fb on forced removal
simpledrm:
- request region instead of marking ioresource busy
- add panel oreintation property
udmabuf:
- fix oops with 0 pages
amdgpu:
- power management code cleanup
- Enable freesync video mode by default
- RAS code cleanup
- Improve VRAM access for debug using SDMA
- SR-IOV rework special register access and fixes
- profiling power state request ioctl
- expose IP discovery via sysfs
- Cyan skillfish updates
- GC 10.3.7, SDMA 5.2.7, DCN 3.1.6 updates
- expose benchmark tests via debugfs
- add module param to disable XGMI for testing
- GPU reset debugfs register dumping support
amdkfd:
- CRIU support
- SDMA queue fixes
radeon:
- UVD suspend fix
- iMac backlight fix
i915:
- minimal parallel submission for execlists
- DG2-G12 subplatform added
- DG2 programming workarounds
- DG2 accelerated migration support
- flat CCS and CCS engine support for XeHP
- initial small BAR support
- drop fake LMEM support
- ADL-N PCH support
- bigjoiner updates
- introduce VMA resources and async unbinding
- register definitions cleanups
- multi-FBC refactoring
- DG1 OPROM over SPI support
- ADL-N platform enabling
- opregion mailbox #5 support
- DP MST ESI improvements
- drm device based logging
- async flip optimisation for DG2
- CPU arch abstraction fixes
- improve GuC ADS init to work on aarch64
- tweak TTM LRU priority hint
- GuC 69.0.3 support
- remove short term execbuf pins
nouveau:
- higher DP/eDP bitrates
- backlight fixes
msm:
- dpu + dp support for sc8180x
- dp support for sm8350
- dpu + dsi support for qcm2290
- 10nm dsi phy tuning support
- bridge support for dp encoder
- gpu support for additional 7c3 SKUs
ingenic:
- HDMI support for JZ4780
- aux channel EDID support
ast:
- AST2600 support
- add wide screen support
- create DP/DVI connectors
omapdrm:
- fix implicit dma_buf fencing
vc4:
- add CSC + full range support
- better display firmware handoff
panfrost:
- add initial dual-core GPU support
stm:
- new revision support
- fb handover support
mediatek:
- transfer display binding document to yaml format.
- add mt8195 display device binding.
FYI, this breaks the DT bindings. The relevant patches didn't get reviewed nor run thru automated testing because their encoding was 'charset=y'[1]. (While email clients seem to just ignore that encoding, patchwork and b4 do not.) linux-next is still broken and has been since Mar 2[2]. v2 of the fixes[3] have been posted since Mar 9, and still aren't in linux-next.
It doesn't have to be fixed in this PR, but it needs to be fixed before rc1. Otherwise, no one can test their bindings using rc1. In general, there's no reason fixes need to wait until after rc1 as Chun-Kuang suggests[4].
Rob
[1] https://lore.kernel.org/all/CAL_JsqLU0m9C1OPdiBPTkofB4sfiAeUPbFHp0w8caWyP4XP... [2] https://lore.kernel.org/all/CAL_Jsq+6k5EqouAO2Xm=GpBz3Pi-wfB-ixGwfyC+Y+qOrjU... [3] https://lore.kernel.org/all/Yjzgf10zAhrkpYde@robh.at.kernel.org/ [4] https://lore.kernel.org/all/CAAOTY__kzL8YuGo-oKct4c_bL-Ch5rW8wBpkhOXkK+a10gN...