intel display struct refactor

I posted an intro set of patches to intel-gfx earlier, but I got a bit OCD and kept going here. https://cgit.freedesktop.org/~airlied/linux/log/?h=i915-display-struct-refactor Mainly looking to see if this is interesting enough refactor to get it landed, I realise it would be quite disruptive.

[PATCH] drm/i915/audio: Use BIOS provided value for RKL HDA link

Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") makes HDMI audio on Lenovo P350 disappear. So in addition to TGL, extend the logic to RKL to use BIOS provided value to fix the regression. Fixes: 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")

[PATCH] drm/i915: Free the returned object of acpi_evaluate_dsm()

As per the comment on top of acpi_evaluate_dsm(): | * Evaluate device's _DSM method with specified GUID, revision id and | * function number. Caller needs to free the returned object. We should free the returned object of acpi_evaluate_dsm() to avoid memory leakage. Otherwise the kmemleak splat

Re: [PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test

[AMD Official Use Only] From: dri-devel on behalf of Pan, Xinhui Sent: Monday, September 6, 2021 9:10 AM To: amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org Cc: Koenig, Christian ; Deucher, Alexander ; che...@uniontech.com Subject: [PATCH

Re: [PATCH v4 10/17] soc: mediatek: mmsys: Add reset controller support for MT8195 vdosys1

Hi Philipp, Thanks for the review. I will base on Enric's patchset in my next revision. Regards, Nancy On Wed, 2021-08-25 at 12:46 +0200, Philipp Zabel wrote: > Hi, > > On Wed, 2021-08-25 at 18:05 +0800, Nancy.Lin wrote: > > Among other features the mmsys driver should implement a reset > >

[PATCH v2 1/2] drm/ttm: Fix a deadlock if the target BO is not idle during swap

The ret value might be -EBUSY, caller will think lru lock is still locked but actually NOT. So return -ENOSPC instead. Otherwise we hit list corruption. ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0, caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will be

[PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test

Like vce/vcn does, visible VRAM is OK for ib test. While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for uvd_get_create/destory_msg") says VRAM is not mapped correctly in his platform which is likely an arm64. So lets change back to use VRAM on x86_64 platform. Signed-off-by: xinhui pan ---

[PATCH v2 0/2] Fix a hung during memory pressure test

A long time ago, someone reports system got hung during memory test. In recent days, I am trying to look for or understand the potential deadlock in ttm/amdgpu code. This patchset aims to fix the deadlock during ttm populate. TTM has a parameter called pages_limit, when allocated GTT memory

[PATCH v2 2/2] drm/amdpgu: Use VRAM domain in UVD IB test

[AMD Official Use Only] Like vce/vcn does, visible VRAM is OK for ib test. While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for uvd_get_create/destory_msg") says VRAM is not mapped correctly in his platform which is likely an arm64. So lets change back to use VRAM on x86_64 platform.

[PATCH v2 1/2] drm/ttm: Fix a deadlock if the target BO is not idle during swap

[AMD Official Use Only] The ret value might be -EBUSY, caller will think lru lock is still locked but actually NOT. So return -ENOSPC instead. Otherwise we hit list corruption. ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0, caller(ttm_tt_populate -> ttm_global_swapout

Subject: [PATCH v2 0/2] Fix a hung during memory pressure test

[AMD Official Use Only] A long time ago, someone reports system got hung during memory test. In recent days, I am trying to look for or understand the potential deadlock in ttm/amdgpu code. This patchset aims to fix the deadlock during ttm populate. TTM has a parameter called pages_limit, when

[PATCH 2/2] drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windows

From: Ben Skeggs Prevent NVD core channel error code 67 occuring and hanging display, managed to reproduce on GA102 while testing suspend/resume scenarios. Required extension of earlier commit to fix interactions with EFI. Fixes: e78b1b545c6c ("drm/nouveau/kms/nv50: workaround EFI GOP window

[PATCH 1/2] drm/nouveau/ga102-: support ttm buffer moves via copy engine

From: Ben Skeggs We don't currently have any kind of real acceleration on Ampere GPUs, but the TTM memcpy() fallback paths aren't really designed to handle copies between different devices, such as on Optimus systems, and result in a kernel OOPS. A few options were investigated to try and fix

Re: linux-next: build failure after merge of the drm tree

Hi all, On Thu, 2 Sep 2021 07:50:38 +1000 Stephen Rothwell wrote: > > On Fri, 20 Aug 2021 15:23:34 +0900 Masahiro Yamada > wrote: > > > > On Fri, Aug 20, 2021 at 11:33 AM Stephen Rothwell > > wrote: > > > > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > >

[PATCH v4 1/2] drm/i915/opregion: add support for mailbox #5 EDID

The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be used for the embedded display. Add support for using it via by adding the EDID to the list of available modes on the connector, and use it for eDP when available. If a panel's EDID is broken, there may be an override EDID set

[PATCH v4 2/2] drm: Add orientation quirk for GPD Win Max

Panel is 800x1280, but mounted on a laptop form factor, sideways. Signed-off-by: Anisse Astier Reviewed-by: Hans de Goede --- drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c

[PATCH v4 0/2] GPD Win Max display fixes

This patch series is for making the GPD Win Max display usable with Linux. The GPD Win Max is a small laptop, and its eDP panel does not send an EDID over DPCD; the EDID is instead available in the intel opregion, in mailbox #5 [1] The second patch is just to fix the orientation of the panel.

Re: Kernel 5.14.0 - invalid opcode: 0000 [#1] SMP NOPTI

cc'ing lists/people On Sun, Sep 5, 2021 at 11:50 AM Andrew Falcon wrote: > > Hello, > > I am encountering a kernel panic with the error in the subject line using > kernel 5.14.0 (final). Kernel 5.14.0-rc7 works without issue for me so > looking back at the last amdgpu commits for 5.14.0

Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

Hi Douglas, On Wed, Sep 01, 2021 at 01:19:18PM -0700, Douglas Anderson wrote: > The goal of this patch series is to move away from hardcoding exact > eDP panels in device tree files. As discussed in the various patches > in this series (I'm not repeating everything here), most eDP panels > are

Re: [PATCH v7 6/8] drm_print: instrument drm_debug_enabled

On Tue, Aug 31, 2021 at 2:21 PM Jim Cromie wrote: > > Duplicate drm_debug_enabled() code into both "basic" and "dyndbg" > ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg" > branch. > > Then convert the "dyndbg" branch's code to a macro, so that its > pr_debug() get its callsite

Re: [PATCH v3 10/16] drm/panel-simple: Non-eDP panels don't need "HPD" handling

On Wed, Sep 01, 2021 at 01:19:28PM -0700, Douglas Anderson wrote: > All of the "HPD" handling added to panel-simple recently was for eDP > panels. Remove it from panel-simple now that panel-simple-edp handles > eDP panels. The "prepare_to_enable" delay only makes sense in the > context of HPD, so

Re: [PATCH v3 05/16] drm/panel-simple-edp: Split eDP panels out of panel-simple

Hi Douglas, On Wed, Sep 01, 2021 at 01:19:23PM -0700, Douglas Anderson wrote: > The panel-simple driver handles way too much. Let's start trying to > get a handle on it by splitting out the eDP panels. This patch does > this: > > 1. Start by copying simple-panel verbatim over to a new driver, >

Re: [PATCH v3 03/16] drm/edid: Allow the querying/working with the panel ID from the EDID

Hi Douglas, On Wed, Sep 01, 2021 at 01:19:21PM -0700, Douglas Anderson wrote: > EDIDs have 32-bits worth of data which is intended to be used to > uniquely identify the make/model of a panel. This has historically > been used only internally in the EDID processing code to identify > quirks with

[drm-intel:drm-intel-gt-next 1/1] drivers/gpu/drm/i915/i915_query.c:439:2: warning: comparison of integers of different signs: 'int' and 'unsigned int'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next head: d5ef86b38e4c2a65d5c1d64d8d0f3fcf58aa0884 commit: d5ef86b38e4c2a65d5c1d64d8d0f3fcf58aa0884 [1/1] drm/i915: Add pci ids and uapi for DG1 config: i386-randconfig-r002-20210903 (attached as .config) compiler: clang version

Re: [PATCH] drm/panel: otm8009a: add a 60 fps mode

Hi Raphael, On Thu, Sep 02, 2021 at 03:04:34PM +, Raphael GALLAIS-POU - foss wrote: > This patch adds a 60 fps mode to the Orisetech OTM8009A panel. > The 50 fps mode is left as preferred. > > Signed-off-by: Raphael Gallais-Pou Thanks, applied to drm-misc-next. Sam

[PATCH] drm: panel-orientation-quirks: Add quirk for the Chuwi HiBook

The Chuwi HiBook uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede --- drivers/gpu/drm/drm_panel_orientation_quirks.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c

[PATCH] doc: gpu: Add document describing buffer exchange

Since there's a lot of confusion around this, document both the rules and the best practice around negotiating, allocating, importing, and using buffers when crossing context/process/device/subsystem boundaries. This ties up all of dmabuf, formats and modifiers, and their usage. Signed-off-by:

[Bug 212469] plymouth animation freezes during shutdown

https://bugzilla.kernel.org/show_bug.cgi?id=212469 --- Comment #12 from Norbert (asteri...@gmx.de) --- The plymouth git works (Ubuntu 21.10). -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.