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.
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: Da
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
b/drivers/gpu
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
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 14.0.
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 pa
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,
>
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 r
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
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 99%
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 (final)
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.
Ch
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
b/drivers/gpu/dr
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 in
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)
> > >
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 th
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 ch
[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 a
[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 ->ttm
[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.
Signed-off-b
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
reach
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
---
drive
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
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
> > con
[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 v
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 w
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")
Signed-of
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. I'
[AMD Official Use Only]
> I'm fearing that just repeating what Alex said, but to make it clear
> once more: That is *not* necessary!
>
> The shared repository is owned by upstream maintainers and they are
> usually free to do restructuring work without getting acknowledge from
> every single dr
https://bugzilla.kernel.org/show_bug.cgi?id=107381
GeorgeQQHu (huqiq...@uniontech.com) changed:
What|Removed |Added
CC||huqiq...@uniontech.c
30 matches
Mail list logo
