Message ID | CAPM=9tytg5jd_i3z3C5Y1dii2-cgO11Gjgvaq8qoWn3CGfCreg@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [git,pull] drm for 5.18-rc1 | expand |
Hi, On Thu, Mar 24, 2022 at 12:30:02PM +1000, Dave Airlie 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. > [ ... ] > fbdev: Improve performance of cfb_imageblit() As reported as reponse to the patch submission, this patch causes crashes with qemu's mainstone, z2, and collie emulations. Reverting it fixes the problem. Unable to handle kernel paging request at virtual address e090d000 [e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte=00000000 Internal error: Oops: 807 [#1] ARM CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1 Hardware name: Sharp-Collie PC is at cfb_imageblit+0x58c/0x6e0 Guenter
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_JsqLU0m9C1OPdiBPTkofB4sfiAeUPbFHp0w8caWyP4XPOEw@mail.gmail.com/ [2] https://lore.kernel.org/all/CAL_Jsq+6k5EqouAO2Xm=GpBz3Pi-wfB-ixGwfyC+Y+qOrjUFTg@mail.gmail.com/ [3] https://lore.kernel.org/all/Yjzgf10zAhrkpYde@robh.at.kernel.org/ [4] https://lore.kernel.org/all/CAAOTY__kzL8YuGo-oKct4c_bL-Ch5rW8wBpkhOXkK+a10gNXVg@mail.gmail.com/
On Wed, Mar 23, 2022 at 7:30 PM Dave Airlie <airlied@gmail.com> wrote: > > 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. Ok, so this was annoying. I've merged it, but will note three things that I really hope get fixed / checked: (1) My merge resolution looked mostly trivial, except for an annoying conflict between commits 4ed545e7d100 ("dt-bindings: display: mediatek: disp: split each block to individual yaml") and 6d0990e6e844 ("media: dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW") where one of them splits up a file that is modified by the other. I ended up just getting rid of all the "mediatek,larb" mentions in the split-up files, despite the fact that (a) those mentions can be found elsewhere and (b) the split-up did other changes too, so maybe it's wrong. (2) As Guenter reported, the fbdev performance improvement of cfb_imageblit() is broken. I was going to just revert it, but I see that there is a two-series patch to fix it at https://lore.kernel.org/all/20220313192952.12058-1-tzimmermann@suse.de/ so I merged it in that broken form, in the hope that this set of fixes will be sent to me asap. (3) Very similarly to (2), but broken mediatek DT files. I hope my changes in (1) didn't make things worse, but there's a series of fixes as https://lore.kernel.org/all/20220309134702.9942-1-jason-jh.lin@mediatek.com/ and again I hope I'll get those fixes from the proper places asap. I considered just delaying merging this all entirely, but it seems better to get this all in, with the known problems and known fixes, and see if we hit something _else_ too. Anyway, let's hope I didn't miss anything, and that those are the only major issues. Linus
The pull request you sent on Thu, 24 Mar 2022 12:30:02 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-03-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b14ffae378aa1db993e62b01392e70d1e585fb23
Thank you!
> 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]. With the conflicts that Linus merged, can we get this rebased onto Linus merge, and submitted to him? Otherwise Linus I sent you a fix for the fbdev in a separate pull. Dave.
On Thu, Mar 24, 2022 at 10:01 PM Dave Airlie <airlied@gmail.com> wrote: > > > 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]. > > With the conflicts that Linus merged, can we get this rebased onto > Linus merge, and submitted to him? I applied the series without issue on Linus' current tree aa5b537b0ecc ("Merge tag 'riscv-for-linus-5.18-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux") and confirmed the binding errors are fixed. Must be some difference in what's in the Mediatek PR... b4 shazam -lsSt 20220309134702.9942-1-jason-jh.lin@mediatek.com Rob
I didn't notice this until now, probably because everything still _works_, but I get a new big warning splat at bootup on my main workstation these days as of the merge window changes. The full warning is attached, but it's basically the ASSERT(0) at line 938 in drivers/gpu/drm/amd/display/dc/core/dc_link.c and it looks to have been introduced by commit c282d9512cdd ("drm/amd/display: factor out dp detection link training and mst top detection"). This is the same old setup I've reported before, with some random Radeon card with two monitors attached (PCI ID 1002:67df rev e7, subsystem ID 1da2:e353). I think the card went by the name "Sapphire Pulse RX 580 8GB" in case any of that matters, but it's been working fine. It still works fine, it just has a big ugly boot-time splat. As mentioned, two 4K monitors attached, both over HDMI. If there is any particular info you want, just let me know where/how to find it, and I can provide. Linus
On Mon, Mar 28, 2022 at 9:54 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > I didn't notice this until now, probably because everything still > _works_, but I get a new big warning splat at bootup on my main > workstation these days as of the merge window changes. > > The full warning is attached, but it's basically the ASSERT(0) at line 938 in > > drivers/gpu/drm/amd/display/dc/core/dc_link.c > > and it looks to have been introduced by commit c282d9512cdd > ("drm/amd/display: factor out dp detection link training and mst top > detection"). > > This is the same old setup I've reported before, with some random > Radeon card with two monitors attached (PCI ID 1002:67df rev e7, > subsystem ID 1da2:e353). > > I think the card went by the name "Sapphire Pulse RX 580 8GB" in case > any of that matters, but it's been working fine. > > It still works fine, it just has a big ugly boot-time splat. > > As mentioned, two 4K monitors attached, both over HDMI. I think it should be fixed with this patch which is already queued up in my -fixes PR from last week: https://gitlab.freedesktop.org/agd5f/linux/-/commit/a572f7055067d95455850fd242d8b54ff5786cac Alex > > If there is any particular info you want, just let me know where/how > to find it, and I can provide. > > Linus