dri-devel December 2021

dri-devel@lists.freedesktop.org

310 participants
720 discussions

[PATCH v7 2/8] dt-bindings: mediatek,dp: Add Display Port binding
by Guillaume Ranquet 17 Dec '21

17 Dec '21

From: Markus Schneider-Pargmann <msp(a)baylibre.com> This controller is present on several mediatek hardware. Currently mt8195 and mt8395 have this controller without a functional difference, so only one compatible field is added. The controller can have two forms, as a normal display port and as an embedded display port. Signed-off-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Guillaume Ranquet <granquet(a)baylibre.com> Reviewed-by: Rob Herring <robh(a)kernel.org> --- .../display/mediatek/mediatek,dp.yaml | 87 +++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml new file mode 100644 index 0000000000000..068b11d766e21 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Display Port Controller + +maintainers: + - CK Hu <ck.hu(a)mediatek.com> + - Jitao shi <jitao.shi(a)mediatek.com> + +description: | + Device tree bindings for the Mediatek (embedded) Display Port controller + present on some Mediatek SoCs. + +properties: + compatible: + enum: + - mediatek,mt8195-dp-tx + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: faxi clock + + clock-names: + items: + - const: faxi + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input endpoint of the controller, usually dp_intf + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the controller + +required: + - compatible + - reg + - interrupts + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/mt8195-power.h> + edp_tx: edp_tx@1c500000 { + compatible = "mediatek,mt8195-dp-tx"; + reg = <0 0x1c500000 0 0x8000>; + interrupts = <GIC_SPI 676 IRQ_TYPE_LEVEL_HIGH 0>; + power-domains = <&spm MT8195_POWER_DOMAIN_EPD_TX>; + pinctrl-names = "default"; + pinctrl-0 = <&edp_pin>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + edp_in: endpoint { + remote-endpoint = <&dp_intf0_out>; + }; + }; + port@1 { + reg = <1>; + edp_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; -- 2.32.0

2 1

[git pull] drm fixes for 5.16-rc6
by Dave Airlie 17 Dec '21

17 Dec '21

Hi Linus, Mostly amdgpu fixes this week scattered around the driver, otherwise one i915, one ast, one simpledrm. There is a revert in the fb-helper for places userspace was using a string that we tried to change. Regards, Dave. drm-fixes-2021-12-17-1: drm fixes for 5.16-rc6 i915: - Fix a bound check in the DMC fw load. ast: - NULL ptr deref fix simpledrm: - pixel clock units fix fb-helper: - userspace regression revert amdgpu: - Fix RLC register offset - GMC fix - Properly cache SMU FW version on Yellow Carp - Fix missing callback on DCN3.1 - Reset DMCUB before HW init - Fix for GMC powergating on PCO - Fix a possible memory leak in GPU metrics table handling on RN The following changes since commit 2585cf9dfaaddf00b069673f27bb3f8530e2039c: Linux 5.16-rc5 (2021-12-12 14:53:01 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-12-17-1 for you to fetch changes up to a2fbfd517117157e99160ff1b39b171872dcba07: Merge tag 'amd-drm-fixes-5.16-2021-12-15' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-12-17 15:01:01 +1000) ---------------------------------------------------------------- drm fixes for 5.16-rc6 i915: - Fix a bound check in the DMC fw load. ast: - NULL ptr deref fix simpledrm: - pixel clock units fix fb-helper: - userspace regression revert amdgpu: - Fix RLC register offset - GMC fix - Properly cache SMU FW version on Yellow Carp - Fix missing callback on DCN3.1 - Reset DMCUB before HW init - Fix for GMC powergating on PCO - Fix a possible memory leak in GPU metrics table handling on RN ---------------------------------------------------------------- Alejandro Concepcion-Rodriguez (1): drm: simpledrm: fix wrong unit with pixel clock Dave Airlie (3): Merge tag 'drm-intel-fixes-2021-12-15' of ssh://git.freedesktop.org/git/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2021-12-16-1' of ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-5.16-2021-12-15' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Evan Quan (1): drm/amdgpu: correct the wrong cached state for GMC on PICASSO Harshit Mogalapalli (1): drm/i915/display: Fix an unsigned subtraction which can never be negative. Hawking Zhang (1): drm/amdgpu: don't override default ECO_BITs setting Javier Martinez Canillas (1): Revert "drm/fb-helper: improve DRM fbdev emulation device names" Jiasheng Jiang (1): drm/ast: potential dereference of null pointer Lang Yu (1): drm/amd/pm: fix a potential gpu_metrics_table memory leak Le Ma (1): drm/amdgpu: correct register access for RLC_JUMP_TABLE_RESTORE Mario Limonciello (1): drm/amd/pm: fix reading SMU FW version from amdgpu_firmware_info on YC Nicholas Kazlauskas (2): drm/amd/display: Set exit_optimized_pwr_state for DCN31 drm/amd/display: Reset DMCUB before HW init drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 1 - drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 1 - drivers/gpu/drm/amd/amdgpu/gfxhub_v2_1.c | 1 - drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 ++++++++ drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 9 ++++----- drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c | 1 - drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 1 - drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 1 - drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c | 2 -- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++++ drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 1 + drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 7 ++++++- drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 3 +++ drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 3 +++ drivers/gpu/drm/ast/ast_mode.c | 5 ++++- drivers/gpu/drm/drm_fb_helper.c | 8 +++++++- drivers/gpu/drm/i915/display/intel_dmc.c | 2 +- drivers/gpu/drm/tiny/simpledrm.c | 2 +- 19 files changed, 45 insertions(+), 20 deletions(-)

2 1

CFP FOSDEM22 Graphics DevRoom
by Luc Verhaegen 17 Dec '21

17 Dec '21

Hi, After a hiatus in 2021, the upcoming FOSDEM will have a graphics DevRoom again. This time round on a sunday, the 6th of February 2022. As usual, the focus of this DevRoom is: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, V4L, (direct)FB, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Low level toolkit stuff * Low level machine learning. * Colour management. * ... FOSDEM '22 is sadly a virtual event again. While a virtual FOSDEM lacks all the wonderful madness of a real life FOSDEM, it does have the advantage of not having to deal with travel and accomodation, the physics of humans trundling around a big university campus, or a booklet. Talks: ------ Time slots will be the usual 25/50 minute talk length, you are free to fill this time up as you see fit, but you might want to reserve 5 minutes for Q&A. I expect there to be 8h available for scheduling. Since there are no travel accomodations to deal with, and there are no people who physically need to get from one end of the ULB campus to the other, and there are no 5000+ booklets to be printed, there is no first come, first serve requirement this year round. But the other side of that coin is that talks can be hard dropped from the devroom managers' side until very late in the process if anything is not in order. Hard talk submission deadline: 30th of december, 23:59UTC. Further info on when a talk video should be finished to fit in the FOSDEM infrastructure will follow, but expect somewhere between january 16th and 23rd, 3-2 weeks before the event. Again, more details will follow. Talk submission and review panel: Arkadiusz Hiler (ivyl) Luc Verhaegen (libv) Martin Ruokala (mupuf) Successful submitters will receive an email with further information on the 31st, as it's not as if I will have anything better to do given that mini-me will have been stabbed only once by then ;) Pentabarf: ---------- Since FOSDEM has had to flash migrate to virtual last year, no further work was sadly done to replace or fix pentabarf, a tool originally made to create the fancy FOSDEM booklet, so its pent-up-clunkiness has to be used again, especially since it actually works :) https://penta.fosdem.org/submission/FOSDEM22 Re-use your accounts from the previous years. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password Here are the basic requirements before we consider a talk worth scheduling: On your personal page: * General: * First Name * Last Name * Nickname * Public Name * Image * Contact: * Contact email address * Biography: * Short Biography On your event page: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Persons: * Add yourself as speaker. * Abstract: * Short abstract Unlike IRL events with a booklet, you should be able to tweak this information pretty much until you are finished with your talk. That's it, hope to see your submission in penta, and your talk at FOSDEM. Luc Verhaegen.

1 0

[PATCH] drm/etnaviv: limit submit sizes
by Lucas Stach 17 Dec '21

17 Dec '21

Currently we allow rediculous ammounts of kernel memory being allocated via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put some reasonable limits in to fix this. The commandstream size is limited to 64KB, which was already a soft limit on older kernels after which the kernel only took submits on a best effort base, so there is no userspace that tries to submit commandstreams larger than this. Even if the whole commandstream is a single incrementing address load, the size limit also limits the number of potential relocs and referenced buffers to slightly under 64K, so use the same limit for those arguments. The performance monitoring infrastructure currently supports less than 50 performance counter signals, so limiting them to 128 on a single submit seems like a reasonably future-proof number for now. This number can be bumped if needed without breaking the interface. Cc: stable(a)vger.kernel.org Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c index 486259e154af..225fa5879ebd 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -469,6 +469,12 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void *data, return -EINVAL; } + if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K || + args->nr_bos > SZ_64K || args->nr_pmrs > 128) { + DRM_ERROR("submit arguments out of size limits\n"); + return -EINVAL; + } + /* * Copy the command submission and bo array to kernel space in * one go, and do this outside of any locks. -- 2.30.2

2 1

Re: [Bug Report] Desktop monitor sleep regression
by Thorsten Leemhuis 17 Dec '21

17 Dec '21

[TLDR: adding this regression to regzbot; most of this mail is compiled from a few templates paragraphs some of you might have seen already.] Hi, this is your Linux kernel regression tracker speaking. Adding the regression mailing list to the list of recipients, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html Also adding the authors and reviewers of the culprit and two appropriate mailing lists. On 07.12.21 01:21, Brandon Nielsen wrote: > Monitors no longer sleep properly on my system (dual monitor connected > via DP->DVI, amdgpu, x86_64). The monitors slept properly on 5.14, but > stopped during the 5.15 series. I have also filed this bug on the kernel > bugzilla[0] and downstream[1]. > > I have performed a bisect, first "bad" commit to master is > 55285e21f04517939480966164a33898c34b2af2[1], the same change made it > into the 5.15 branch as e3b39825ed0813f787cb3ebdc5ecaa5131623647. TWIMC: That was for 5.15.3 > I have > verified the issue exists in latest master > (a51e3ac43ddbad891c2b1a4f3aa52371d6939570). > > Steps to reproduce: > > 1. Boot system (Fedora Workstation 35 in this case) > 2. Log in > 3. Lock screen (after a few seconds, monitors will enter power save > "sleep" state with backlight off) > 4. Wait (usually no more than 30 seconds, sometimes up to a few minutes) > 5. Observe monitor leaving "sleep" state (backlight comes back on), > but nothing is displayed > > [0] - https://bugzilla.kernel.org/show_bug.cgi?id=215203 > [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2028613 To be sure this issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 55285e21f04517939480966164a33898c34b2af2 #regzbot title fbdev/efifb: Monitors no longer sleep (amdgpu dual monitor setup) #regzbot ignore-activity Reminder: when fixing the issue, please add a 'Link:' tag with the URL to the report (the parent of this mail), then regzbot will automatically mark the regression as resolved once the fix lands in the appropriate tree. For more details about regzbot see footer. Sending this to everyone that got the initial report, to make all aware of the tracking. I also hope that messages like this motivate people to directly get at least the regression mailing list and ideally even regzbot involved when dealing with regressions, as messages like this wouldn't be needed then. Don't worry, I'll send further messages wrt to this regression just to the lists (with a tag in the subject so people can filter them away), as long as they are intended just for regzbot. With a bit of luck no such messages will be needed anyway. Ciao, Thorsten, your Linux kernel regression tracker. P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activities wrt to this regression.

3 3

[PATCH v3 00/17] drm/i915: Remove short term pins from execbuf by requiring lock to unbind.
by Maarten Lankhorst 17 Dec '21

17 Dec '21

Previously, short term pinning in execbuf was required because i915_vma was effectively independent from objects, and has its own refcount, locking, lifetime rules and pinning. This series removes the separate locking, by requiring vma->obj->resv to be held when pinning and unbinding. This will also be required for VM_BIND work. With pinning required for pinning and unbinding, the lock is enough to prevent unbinding when trying to pin with the lock held, for example in execbuf. This makes binding/unbinding similar to ttm_bo_validate()'s use, which just cares that an object is in a certain place, without pinning it in place. Having the VMA part of gem bo removes a lot of the vma refcounting, and makes i915_vma more a part of the bo, instead of its own floating object that just happens to be part of a bo. This is also required to make it more compatible with TTM, and migration in general. For future work, it makes things a lot simpler and clear. We want to end up with i915_vma just being a specific mapping of the BO, just like is the case in other drivers. i915_vma->active removal is the next step there, and makes it when object is destroyed, the bindings are destroyed (after idle), instead of object being destroyed when bindings are idle. --- This is version 3, I changed the ordering of the patches slightly to be more natural, and divided up some commits in different ways. In particular, I added the ww ctx to trylock first, then converted i915_gem_evict_vm(), the shrinker, and the other eviction functions all in separate commits. Functionally the same, but easier to review and bisect. In theory, it was already reviewed, but leaving those r-b's out as they're technically different patches now. The first patches prepare for vma->obj->resv requirement, by ensuring that we unbind as needed, and take the ww lock in some places where they're required, including when freeing the object. After that we convert the shrinker, eviction functions, and then we can start requiring the object lock for i915_vma_unbind. Now that the conversion and requirement is added, we can remove ther special case of assert_object_held_shared, which was added because we didn't always require the object lock. As last step we can remove the short term pins from execbuf. We still pin when evicting the entire VM, but if it turns out to be an issue, it can be removed, and replaced with unpinning the entire VM. Maarten Lankhorst (17): drm/i915: Remove unused bits of i915_vma/active api drm/i915: Change shrink ordering to use locking around unbinding. drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v3. drm/i915: Take object lock in i915_ggtt_pin if ww is not set drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2. drm/i915: Ensure gem_contexts selftests work with unbind changes, v2. drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes. drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors drm/i915: Trylock the object when shrinking drm/i915: Require object lock when freeing pages during destruction drm/i915: Add ww ctx to i915_gem_object_trylock drm/i915: Add locking to i915_gem_evict_vm() drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind, v2. drm/i915: Remove assert_object_held_shared drm/i915: Remove support for unlocked i915_vma unbind drm/i915: Remove short-term pins from execbuf, v5. drivers/gpu/drm/i915/display/intel_dpt.c | 2 - drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 250 ++++---- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 22 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 12 +- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 44 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- .../i915/gem/selftests/i915_gem_client_blt.c | 2 +- .../drm/i915/gem/selftests/i915_gem_context.c | 59 +- .../drm/i915/gem/selftests/i915_gem_mman.c | 6 + drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 15 - drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 454 ++------------ drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 - drivers/gpu/drm/i915/gt/intel_gtt.c | 13 - drivers/gpu/drm/i915/gt/intel_gtt.h | 7 - drivers/gpu/drm/i915/gt/intel_ppgtt.c | 12 - drivers/gpu/drm/i915/gt/mock_engine.c | 2 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +- drivers/gpu/drm/i915/gvt/aperture_gm.c | 2 +- drivers/gpu/drm/i915/i915_active.c | 28 +- drivers/gpu/drm/i915/i915_active.h | 17 +- drivers/gpu/drm/i915/i915_drv.h | 12 +- drivers/gpu/drm/i915/i915_gem.c | 32 +- drivers/gpu/drm/i915/i915_gem_evict.c | 64 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +- drivers/gpu/drm/i915/i915_gem_gtt.h | 4 + drivers/gpu/drm/i915/i915_vgpu.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 579 +++++++++++++++--- drivers/gpu/drm/i915/i915_vma.h | 6 +- drivers/gpu/drm/i915/i915_vma_types.h | 1 - .../gpu/drm/i915/selftests/i915_gem_evict.c | 27 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 50 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 19 +- drivers/gpu/drm/i915/selftests/mock_gtt.c | 4 - 40 files changed, 951 insertions(+), 846 deletions(-) -- 2.34.1

2 28

KMS selects unsupported video mode, causing blank screen after boot
by Ing. Josua Mayer 17 Dec '21

17 Dec '21

Dear Maintainers and readers, I have come across what I think is a kernel bug regarding how during system boot the video-mode for the console is being selected. Inspection of logs with debugging enabled show that in my particular case kernel selects 4k resolution at 144Hz. The supported maximum of my GPU however is 4k at 60Hz only, because DisplayPort 1.4 is available, but DSC is not. I will provide hardware details and software versions below, with detailed findings at the end. If you have any ideas how to resolve this, I am happy to try a patch and report back. # Hardware Info: SolidRun HoneyComb Workstation - LX2160A (16x Cortex-A72) - 32GB DDR4-3000 memory - ACPI ADATA SX8200 NVME Radeon Pro WX2100 - DisplayPort 1.4 - 1x full-size port, 2x mini ports EVE Spectrum ES07D03 display (max. 4k 144Hz) # Software Info: openSUSE Tumbleweed Linux 5.15.7-1-vanilla aarch64 Linux 5.15.7-1-default aarch64 Linux 5.15.5-1-default aarch64 Mesa 21.3 # Work-Arounds: I *can* get to a functional plasma wayland session by forcing a supported video mode for both the console and X (because sddm doesn't do wayland): - kernel cmdline: video=DP-3:3840x2160@60 - xorg.conf.d: Section "Monitor" Identifier "DisplayPort-2" ModeLine "3840x2160__60.0" 594.00 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync Option "PreferredMode" "3840x2160__60.0" EndSection # Details The issue manifested itself first as soon as Linux takes over the graphics card from UEFI. That is both UEFI and grub menus show up fine, but then once Linux starts the display turns black - but stays on for a while. The backlight makes it shine slightly - till eventually a NO SIGNAL message shows up before it enters a standby mode. poking around /sys showed that Linux recognizes a display is connected, and that it knows what modes that one supports: cat /sys/class/drm/card0-DP-3/status connected cat /sys/class/drm/card0-DP-3/modes 3840x2160 ... 2560x1440 2560x1080 ... Then I tried to force a video-mode that I expected to work, and booted with video=DP-3:3840x2160@60 to choose what I believe is the maximum supported by this particular GPU. Now, console messages of the boot process show up properly, and after a few seconds the display switches to the 4k resolution - eventually leading to the console login prompt. --> This is where I know there is a mode that works, and Linux does not pick it by default. So I enabled debug output for the drm module by booting with amdgpu.dcdebugmask=0x4 drm.debug=0x104 <-- I figured that would be all the interesting pieces. And sure enough I can see all the modes being printed, one being picked - and a rather sane error message: [ 10.186899] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 144 1296000 3840 3888 3920 4000 2160 2168 2178 2250 0x48 0x9 [ 10.186959] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x48 0x5 [ 10.197301] [drm:drm_client_modeset_probe [drm]] desired mode 3840x2160 set on crtc 51 (0,0) [ 10.242536] [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 1296000) failed DC validation with error 10 (No DP link bandwidth) [ 10.244183] [drm:dce112_validate_bandwidth [amdgpu]] dce112_validate_bandwidth: Bandwidth validation failed! --> Clearly some subsystem knows the chosen video mode is not supported here. But it never gets around to trying another mode, e.g. the *second* mode listed in edid (which would work). I am attaching to this mail the dmesg produced with log_level=9 drm.debug=0x11F video=DP-1:d video=DP-2:d (unused ports forced disabled, and most drm debug messages enabled) I have also tried swapping the connectors on the card: I tried both DP-3 (the full-size connector) and DP-1 (one of the two mini connectors) but the behaviour is the same. Further Xorg also auto-selects the 144Hz mode according to its log-file. Finally I also attach output of the drm_info tool from https://github.com/ascent12/drm_info Yours sincerely Josua Mayer

1 0

[PATCH v7 4/8] video/hdmi: Add audio_infoframe packing for DP
by Guillaume Ranquet 17 Dec '21

17 Dec '21

From: Markus Schneider-Pargmann <msp(a)baylibre.com> Similar to HDMI, DP uses audio infoframes as well which are structured very similar to the HDMI ones. This patch adds a helper function to pack the HDMI audio infoframe for DP, called hdmi_audio_infoframe_pack_for_dp(). hdmi_audio_infoframe_pack_only() is split into two parts. One of them packs the payload only and can be used for HDMI and DP. Signed-off-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Guillaume Ranquet <granquet(a)baylibre.com> --- drivers/video/hdmi.c | 83 ++++++++++++++++++++++++++++--------- include/drm/drm_dp_helper.h | 2 + include/linux/hdmi.h | 7 +++- 3 files changed, 72 insertions(+), 20 deletions(-) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 947be761dfa40..63e74d9fd210e 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -21,6 +21,7 @@ * DEALINGS IN THE SOFTWARE. */ +#include <drm/drm_dp_helper.h> #include <linux/bitops.h> #include <linux/bug.h> #include <linux/errno.h> @@ -381,12 +382,34 @@ static int hdmi_audio_infoframe_check_only(const struct hdmi_audio_infoframe *fr * * Returns 0 on success or a negative error code on failure. */ -int hdmi_audio_infoframe_check(struct hdmi_audio_infoframe *frame) +int hdmi_audio_infoframe_check(const struct hdmi_audio_infoframe *frame) { return hdmi_audio_infoframe_check_only(frame); } EXPORT_SYMBOL(hdmi_audio_infoframe_check); +static void +hdmi_audio_infoframe_pack_payload(const struct hdmi_audio_infoframe *frame, + u8 *buffer) +{ + u8 channels; + + if (frame->channels >= 2) + channels = frame->channels - 1; + else + channels = 0; + + buffer[0] = ((frame->coding_type & 0xf) << 4) | (channels & 0x7); + buffer[1] = ((frame->sample_frequency & 0x7) << 2) | + (frame->sample_size & 0x3); + buffer[2] = frame->coding_type_ext & 0x1f; + buffer[3] = frame->channel_allocation; + buffer[4] = (frame->level_shift_value & 0xf) << 3; + + if (frame->downmix_inhibit) + buffer[4] |= BIT(7); +} + /** * hdmi_audio_infoframe_pack_only() - write HDMI audio infoframe to binary buffer * @frame: HDMI audio infoframe @@ -404,7 +427,6 @@ EXPORT_SYMBOL(hdmi_audio_infoframe_check); ssize_t hdmi_audio_infoframe_pack_only(const struct hdmi_audio_infoframe *frame, void *buffer, size_t size) { - unsigned char channels; u8 *ptr = buffer; size_t length; int ret; @@ -420,28 +442,13 @@ ssize_t hdmi_audio_infoframe_pack_only(const struct hdmi_audio_infoframe *frame, memset(buffer, 0, size); - if (frame->channels >= 2) - channels = frame->channels - 1; - else - channels = 0; - ptr[0] = frame->type; ptr[1] = frame->version; ptr[2] = frame->length; ptr[3] = 0; /* checksum */ - /* start infoframe payload */ - ptr += HDMI_INFOFRAME_HEADER_SIZE; - - ptr[0] = ((frame->coding_type & 0xf) << 4) | (channels & 0x7); - ptr[1] = ((frame->sample_frequency & 0x7) << 2) | - (frame->sample_size & 0x3); - ptr[2] = frame->coding_type_ext & 0x1f; - ptr[3] = frame->channel_allocation; - ptr[4] = (frame->level_shift_value & 0xf) << 3; - - if (frame->downmix_inhibit) - ptr[4] |= BIT(7); + hdmi_audio_infoframe_pack_payload(frame, + ptr + HDMI_INFOFRAME_HEADER_SIZE); hdmi_infoframe_set_checksum(buffer, length); @@ -479,6 +486,44 @@ ssize_t hdmi_audio_infoframe_pack(struct hdmi_audio_infoframe *frame, } EXPORT_SYMBOL(hdmi_audio_infoframe_pack); +/** + * hdmi_audio_infoframe_pack_for_dp - Pack a HDMI Audio infoframe for + * displayport + * + * @frame HDMI Audio infoframe + * @sdp secondary data packet for display port. This is filled with the + * appropriate data + * @dp_version Display Port version to be encoded in the header + * + * Packs a HDMI Audio Infoframe to be sent over Display Port. This function + * fills the secondary data packet to be used for Display Port. + * + * Return: Number of total written bytes or a negative errno on failure. + */ +ssize_t +hdmi_audio_infoframe_pack_for_dp(const struct hdmi_audio_infoframe *frame, + struct dp_sdp *sdp, u8 dp_version) +{ + int ret; + + ret = hdmi_audio_infoframe_check(frame); + if (ret) + return ret; + + memset(sdp->db, 0, sizeof(sdp->db)); + + // Secondary-data packet header + sdp->sdp_header.HB0 = 0; + sdp->sdp_header.HB1 = frame->type; + sdp->sdp_header.HB2 = DP_SDP_AUDIO_INFOFRAME_HB2; + sdp->sdp_header.HB3 = (dp_version & 0x3f) << 2; + + hdmi_audio_infoframe_pack_payload(frame, sdp->db); + + return frame->length + 4; +} +EXPORT_SYMBOL(hdmi_audio_infoframe_pack_for_dp); + /** * hdmi_vendor_infoframe_init() - initialize an HDMI vendor infoframe * @frame: HDMI vendor infoframe diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index b52df4db3e8fe..d1527175716aa 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1550,6 +1550,8 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw); #define DP_SDP_VSC_EXT_CEA 0x21 /* DP 1.4 */ /* 0x80+ CEA-861 infoframe types */ +#define DP_SDP_AUDIO_INFOFRAME_HB2 0x1b + /** * struct dp_sdp_header - DP secondary data packet header * @HB0: Secondary Data Packet ID diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index c8ec982ff4984..2f4dcc8d060e3 100644 --- a/include/linux/hdmi.h +++ b/include/linux/hdmi.h @@ -336,7 +336,12 @@ ssize_t hdmi_audio_infoframe_pack(struct hdmi_audio_infoframe *frame, void *buffer, size_t size); ssize_t hdmi_audio_infoframe_pack_only(const struct hdmi_audio_infoframe *frame, void *buffer, size_t size); -int hdmi_audio_infoframe_check(struct hdmi_audio_infoframe *frame); +int hdmi_audio_infoframe_check(const struct hdmi_audio_infoframe *frame); + +struct dp_sdp; +ssize_t +hdmi_audio_infoframe_pack_for_dp(const struct hdmi_audio_infoframe *frame, + struct dp_sdp *sdp, u8 dp_version); enum hdmi_3d_structure { HDMI_3D_STRUCTURE_INVALID = -1, -- 2.32.0

1 0

[PATCH v7 3/8] drm/edid: Add cea_sad helpers for freq/length
by Guillaume Ranquet 17 Dec '21

17 Dec '21

From: Markus Schneider-Pargmann <msp(a)baylibre.com> This patch adds two helper functions that extract the frequency and word length from a struct cea_sad. For these helper functions new defines are added that help translate the 'freq' and 'byte2' fields into real numbers. Signed-off-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Guillaume Ranquet <granquet(a)baylibre.com> --- drivers/gpu/drm/drm_edid.c | 74 ++++++++++++++++++++++++++++++++++++++ include/drm/drm_edid.h | 18 ++++++++-- 2 files changed, 90 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 12893e7be89bb..500279a82167a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4747,6 +4747,80 @@ int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb) } EXPORT_SYMBOL(drm_edid_to_speaker_allocation); +/** + * drm_cea_sad_get_sample_rate - Extract the sample rate from cea_sad + * @sad: Pointer to the cea_sad struct + * + * Extracts the cea_sad frequency field and returns the sample rate in Hz. + * + * Return: Sample rate in Hz or a negative errno if parsing failed. + */ +int drm_cea_sad_get_sample_rate(const struct cea_sad *sad) +{ + switch (sad->freq) { + case DRM_CEA_SAD_FREQ_32KHZ: + return 32000; + case DRM_CEA_SAD_FREQ_44KHZ: + return 44100; + case DRM_CEA_SAD_FREQ_48KHZ: + return 48000; + case DRM_CEA_SAD_FREQ_88KHZ: + return 88200; + case DRM_CEA_SAD_FREQ_96KHZ: + return 96000; + case DRM_CEA_SAD_FREQ_176KHZ: + return 176400; + case DRM_CEA_SAD_FREQ_192KHZ: + return 192000; + default: + return -EINVAL; + } +} +EXPORT_SYMBOL(drm_cea_sad_get_sample_rate); + +static bool drm_cea_sad_is_uncompressed(const struct cea_sad *sad) +{ + switch (sad->format) { + case HDMI_AUDIO_CODING_TYPE_STREAM: + case HDMI_AUDIO_CODING_TYPE_PCM: + return true; + default: + return false; + } +} + +/** + * drm_cea_sad_get_uncompressed_word_length - Extract word length + * @sad: Pointer to the cea_sad struct + * + * Extracts the cea_sad byte2 field and returns the word length for an + * uncompressed stream. + * + * Note: This function may only be called for uncompressed audio. + * + * Return: Word length in bits or a negative errno if parsing failed. + */ +int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad) +{ + if (!drm_cea_sad_is_uncompressed(sad)) { + DRM_WARN("Unable to get the uncompressed word length for a compressed format: %u\n", + sad->format); + return -EINVAL; + } + + switch (sad->byte2) { + case DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT: + return 16; + case DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT: + return 20; + case DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT: + return 24; + default: + return -EINVAL; + } +} +EXPORT_SYMBOL(drm_cea_sad_get_uncompressed_word_length); + /** * drm_av_sync_delay - compute the HDMI/DP sink audio-video sync delay * @connector: connector associated with the HDMI/DP sink diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 18f6c700f6d02..a30452b313979 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -361,12 +361,24 @@ struct edid { /* Short Audio Descriptor */ struct cea_sad { - u8 format; + u8 format; /* See HDMI_AUDIO_CODING_TYPE_* */ u8 channels; /* max number of channels - 1 */ - u8 freq; + u8 freq; /* See CEA_SAD_FREQ_* */ u8 byte2; /* meaning depends on format */ }; +#define DRM_CEA_SAD_FREQ_32KHZ BIT(0) +#define DRM_CEA_SAD_FREQ_44KHZ BIT(1) +#define DRM_CEA_SAD_FREQ_48KHZ BIT(2) +#define DRM_CEA_SAD_FREQ_88KHZ BIT(3) +#define DRM_CEA_SAD_FREQ_96KHZ BIT(4) +#define DRM_CEA_SAD_FREQ_176KHZ BIT(5) +#define DRM_CEA_SAD_FREQ_192KHZ BIT(6) + +#define DRM_CEA_SAD_UNCOMPRESSED_WORD_16BIT BIT(0) +#define DRM_CEA_SAD_UNCOMPRESSED_WORD_20BIT BIT(1) +#define DRM_CEA_SAD_UNCOMPRESSED_WORD_24BIT BIT(2) + struct drm_encoder; struct drm_connector; struct drm_connector_state; @@ -374,6 +386,8 @@ struct drm_display_mode; int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads); int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb); +int drm_cea_sad_get_sample_rate(const struct cea_sad *sad); +int drm_cea_sad_get_uncompressed_word_length(const struct cea_sad *sad); int drm_av_sync_delay(struct drm_connector *connector, const struct drm_display_mode *mode); -- 2.32.0

1 0

[PATCH v7 1/8] dt-bindings: mediatek,dpi: Add DP_INTF compatible
by Guillaume Ranquet 17 Dec '21

17 Dec '21

From: Markus Schneider-Pargmann <msp(a)baylibre.com> DP_INTF is similar to DPI but does not have the exact same feature set or register layouts. DP_INTF is the sink of the display pipeline that is connected to the DisplayPort controller and encoder unit. It takes the same clocks as DPI. Signed-off-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Guillaume Ranquet <granquet(a)baylibre.com> Reviewed-by: Rob Herring <robh(a)kernel.org> --- .../bindings/display/mediatek/mediatek,dpi.yaml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index dd2896a40ff08..53acf9a84f7fb 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -4,16 +4,16 @@ $id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: mediatek DPI Controller Device Tree Bindings +title: mediatek DPI/DP_INTF Controller Device Tree Bindings maintainers: - CK Hu <ck.hu(a)mediatek.com> - Jitao shi <jitao.shi(a)mediatek.com> description: | - The Mediatek DPI function block is a sink of the display subsystem and - provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel - output bus. + The Mediatek DPI and DP_INTF function blocks are a sink of the display + subsystem and provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a + parallel output bus. properties: compatible: @@ -23,6 +23,7 @@ properties: - mediatek,mt8173-dpi - mediatek,mt8183-dpi - mediatek,mt8192-dpi + - mediatek,mt8195-dpintf reg: maxItems: 1 @@ -54,7 +55,7 @@ properties: $ref: /schemas/graph.yaml#/properties/port description: Output port node. This port should be connected to the input port of an - attached HDMI or LVDS encoder chip. + attached HDMI, LVDS or DisplayPort encoder chip. required: - compatible -- 2.32.0

1 0

← Newer
1
...
33
34
35
36
37
38
39
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2021