On Tue, 22 Jun 2021 21:05:50 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 17, 2021 at 04:22:08PM +0200, Christoph Hellwig wrote:
> > This is my alternative take on this series from Jason:
> >
> > https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
> >
> > The mdev/vfio parts are
On Tue, Jun 22, 2021 at 04:28:14PM -0700, Matt Roper wrote:
> On Tue, Jun 22, 2021 at 02:22:09PM -0700, Lucas De Marchi wrote:
> > We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
> > Instead spec says to add 3usec (as opposed to 2) to each valid level
> > when punit replies
On Tue, Jun 22, 2021 at 02:22:10PM -0700, Lucas De Marchi wrote:
> Since we are already loop through the levels to sanitize them, mark what
> is the real max_level so it can be used in subsequent loop. This makes
> it simpler to later add the adjsutement latency to "valid levels". No
Minor typo
On Tue, Jun 22, 2021 at 02:22:09PM -0700, Lucas De Marchi wrote:
> We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
> Instead spec says to add 3usec (as opposed to 2) to each valid level
> when punit replies 0 to level 0.
>
> So set wm_lv_0_adjust_needed to false for
== Series Details ==
Series: series starting with [1/2] drm/i915/display: fix level 0 adjustement on
display ver >= 12
URL : https://patchwork.freedesktop.org/series/91791/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10263_full -> Patchwork_20433_full
== Series Details ==
Series: series starting with [1/2] drm/i915/display: fix level 0 adjustement on
display ver >= 12
URL : https://patchwork.freedesktop.org/series/91791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10263 -> Patchwork_20433
This fixes the NULL pointer dereference in i915_fence_get_driver_name(),
but now it crashes in i915_fence_get_timeline with another NULL pointer
dereference. It attempts to use i915_gem_context.name, which apparently
also hasn't been initialized
static const char
Since we are already loop through the levels to sanitize them, mark what
is the real max_level so it can be used in subsequent loop. This makes
it simpler to later add the adjsutement latency to "valid levels". No
change in behavior, just makes the code easier to follow.
Signed-off-by: Lucas De
We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
Instead spec says to add 3usec (as opposed to 2) to each valid level
when punit replies 0 to level 0.
So set wm_lv_0_adjust_needed to false for DISPLAY_VER() >= 12 and set
the proper adjustement value when handling
On Tue, Jun 22, 2021 at 9:10 PM Sam Ravnborg wrote:
>
> Hi Daniel,
>
> On Tue, Jun 22, 2021 at 06:55:03PM +0200, Daniel Vetter wrote:
> > There's a bunch of atomic drivers who don't do this quite correctly,
> > luckily most of them aren't in wide use or people would have noticed
> > the tearing.
== Series Details ==
Series: ALSA: hda: Release display power reference during shutdown/reboot (rev2)
URL : https://patchwork.freedesktop.org/series/91742/
State : failure
== Summary ==
Applying: ALSA: hda: Release display power reference during shutdown/reboot
error: sha1 information is
On Tue, Jun 22, 2021 at 04:18:14PM +0200, Takashi Iwai wrote:
> On Mon, 21 Jun 2021 19:44:15 +0200,
> Imre Deak wrote:
> >
> > Make sure the HDA driver's display power reference is released during
> > shutdown/reboot.
> >
> > During the shutdown/reboot sequence the pci device core calls the
> >
On Tue, Jun 22, 2021 at 9:01 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Tue, Jun 22, 2021 at 06:54:58PM +0200, Daniel Vetter wrote:
> > Also review & update everything while we're at it.
> >
> > This is prep work to smash a ton of stuff into the kerneldoc for
> > @resv.
> >
> > Signed-off-by:
On Tue, Jun 22, 2021 at 8:50 PM Sam Ravnborg wrote:
>
> Hi Daniel,
>
> On Tue, Jun 22, 2021 at 06:54:57PM +0200, Daniel Vetter wrote:
> > Oversight from
> >
> > commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> > Author: Christian König
> > Date: Mon May 10 16:14:09 2021 +0200
>
> this is what
Hi Daniel,
On Tue, Jun 22, 2021 at 06:55:08PM +0200, Daniel Vetter wrote:
> It's tedious to review this all the time, and my audit showed that
> arcpgu actually forgot to set this.
>
> Make this the default and stop worrying.
>
> Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
== Series Details ==
Series: implicit fencing/dma-resv rules for shared buffers
URL : https://patchwork.freedesktop.org/series/91789/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10263_full -> Patchwork_20431_full
Summary
Hi Daniel,
On Tue, Jun 22, 2021 at 06:55:03PM +0200, Daniel Vetter wrote:
> There's a bunch of atomic drivers who don't do this quite correctly,
> luckily most of them aren't in wide use or people would have noticed
> the tearing.
>
> By making this the default we avoid the constant audit pain
Hi Daniel,
On Tue, Jun 22, 2021 at 06:54:57PM +0200, Daniel Vetter wrote:
> Oversight from
>
> commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> Author: Christian König
> Date: Mon May 10 16:14:09 2021 +0200
this is what we uses Fixes: ... for.
It looks wrong to hide it in the description.
Hi Daniel.
On Tue, Jun 22, 2021 at 06:54:58PM +0200, Daniel Vetter wrote:
> Also review & update everything while we're at it.
>
> This is prep work to smash a ton of stuff into the kerneldoc for
> @resv.
>
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: Alex
On Tue, Jun 22, 2021 at 12:55 PM Daniel Vetter wrote:
>
> Also review & update everything while we're at it.
>
> This is prep work to smash a ton of stuff into the kerneldoc for
> @resv.
>
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: Alex Deucher
> Cc:
On Tue, Jun 22, 2021 at 12:55 PM Daniel Vetter wrote:
>
> Oversight from
>
> commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> Author: Christian König
> Date: Mon May 10 16:14:09 2021 +0200
>
> dma-buf: rename and cleanup dma_resv_get_excl v3
>
> Signed-off-by: Daniel Vetter
> Cc: Sumit
== Series Details ==
Series: implicit fencing/dma-resv rules for shared buffers
URL : https://patchwork.freedesktop.org/series/91789/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10263 -> Patchwork_20431
Summary
---
== Series Details ==
Series: drm/i915: keep backlight_enable on until turn eDP display off (rev3)
URL : https://patchwork.freedesktop.org/series/91780/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10262_full -> Patchwork_20430_full
== Series Details ==
Series: implicit fencing/dma-resv rules for shared buffers
URL : https://patchwork.freedesktop.org/series/91789/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: implicit fencing/dma-resv rules for shared buffers
URL : https://patchwork.freedesktop.org/series/91789/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa13cbf232a0 dma-resv: Fix kerneldoc
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description
Am 19.05.21 um 11:34 schrieb Pekka Paalanen:
> On Wed, 12 May 2021 16:04:16 +0300
> Ville Syrjälä wrote:
>
>> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
>>> Hello,
>>>
>>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm
>>> properties I propose 4
WARNING: Absolutely untested beyond "gcc isn't dying in agony".
Implicit fencing done properly needs to treat the implicit fencing
slots like a funny kind of IPC mailbox. In other words it needs to be
explicitly. This is the only way it will mesh well with explicit
fencing userspace like vk, and
I guess no one ever tried running omap together with lima or panfrost,
not even sure that's possible. Anyway for consistency, fix this.
Reviewed-by: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_plane.c | 3 +++
1 file changed, 3 insertions(+)
Spotted while trying to convert panfrost to these.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3 insertions(+)
It's tedious to review this all the time, and my audit showed that
arcpgu actually forgot to set this.
Make this the default and stop worrying.
Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
strange combinations of hooks: cleanup_fb without prepare_fb doesn't
make sense, and
Goes through all the drivers and deletes the default hook since it's
the default now.
Acked-by: David Lechner
Acked-by: Noralf Trønnes
Acked-by: Oleksandr Andrushchenko
Acked-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes"
Cc: Linus
Like we have for the shadow helpers too, and roll it out to drivers.
Acked-by: Tian Tao
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Hans de Goede
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Tian Tao
Cc: Laurent Pinchart
---
No need to set it explicitly.
Acked-by: Heiko Stuebner
Acked-by: Paul Cercueil
Acked-by: Jernej Skrabec
Acked-by: Chun-Kuang Hu
Acked-by: Martin Blumenstingl
Acked-by: Tomi Valkeinen
Acked-by: Philippe Cornu
Acked-by: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Laurentiu Palcu
Cc:
All they do is refcount the fb, which the atomic helpers already do.
This is was necessary with the legacy helpers and I guess just carry
over in the conversion. drm_plane_state always has a full reference
for its ->fb pointer during its entire lifetime,
see
There's a bunch of atomic drivers who don't do this quite correctly,
luckily most of them aren't in wide use or people would have noticed
the tearing.
By making this the default we avoid the constant audit pain and can
additionally remove a ton of lines from vfuncs for a bit more clarity
in
Currently this has no practial relevance I think because there's not
many who can pull off a setup with panfrost and another gpu in the
same system. But the rules are that if you're setting an exclusive
fence, indicating a gpu write access in the implicit fencing system,
then you need to wait for
More consistency and prep work for the next patch.
Aside: I wonder whether we shouldn't just move this entire xarray
business into the scheduler so that not everyone has to reinvent the
same wheels. Cc'ing some scheduler people for this too.
v2: Correctly handle sched_lock since Lucas pointed
drm/scheduler requires a lock between _init and _push_job, but the
reservation lock dance doesn't. So shrink the critical section a
notch.
v2: Lucas pointed out how this should really work, I got it all wrong
in v1.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Rob Herring
Cc: Tomeu Vizoso
Oversight from
commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
Author: Christian König
Date: Mon May 10 16:14:09 2021 +0200
dma-buf: rename and cleanup dma_resv_get_excl v3
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc:
Docs for struct dma_resv are fairly clear:
"A reservation object can have attached one exclusive fence (normally
associated with write operations) or N shared fences (read
operations)."
https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects
Furthermore a review across
Also review & update everything while we're at it.
This is prep work to smash a ton of stuff into the kerneldoc for
@resv.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Nirmoy Das
Cc: Deepak R Varma
Cc: Chen Li
Hi all,
After many bits have been spilled on dri-devel discussion this I think
we're converging on a consensus understanding of where we are, and it's
time to resubmit patches.
This is essentially v2 of
https://lore.kernel.org/dri-devel/20210521090959.1663703-7-daniel.vet...@ffwll.ch/
but a
== Series Details ==
Series: drm/i915: keep backlight_enable on until turn eDP display off (rev3)
URL : https://patchwork.freedesktop.org/series/91780/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10262 -> Patchwork_20430
== Series Details ==
Series: drm/i915: keep backlight_enable on until turn eDP display off (rev3)
URL : https://patchwork.freedesktop.org/series/91780/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9d04638ef39d drm/i915: keep backlight_enable on until turn eDP display off
This workaround is specific for a particular panel on Google
chromebook project. When user space daemon enter idle state.
It request adjust brightness to 0, turn backlight_enable signal
off and keep eDP main link active.
On general LCD, this behavior might not be a problem.
But on this panel, its
On Tue, 22 Jun 2021, 10:18 PM, Jani Nikula wrote:
>On Tue, 22 Jun 2021, Lee Shawn C wrote:
>> This workaround is specific for a particular panel on Google
>> chromebook project. When user space daemon enter idle state.
>> It request adjust brightness to 0, turn backlight_enable signal off
>>
== Series Details ==
Series: drm/i915: keep backlight_enable on until turn eDP display off (rev2)
URL : https://patchwork.freedesktop.org/series/91780/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK
== Series Details ==
Series: drm/i915/ttm: consider all placements for the page alignment
URL : https://patchwork.freedesktop.org/series/91771/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10261_full -> Patchwork_20428_full
On Mon, 21 Jun 2021 19:44:15 +0200,
Imre Deak wrote:
>
> Make sure the HDA driver's display power reference is released during
> shutdown/reboot.
>
> During the shutdown/reboot sequence the pci device core calls the
> pm_runtime_resume handler for all devices before calling the driver's
>
On Tue, 22 Jun 2021, Lee Shawn C wrote:
> This workaround is specific for a particular panel on Google
> chromebook project. When user space daemon enter idle state.
> It request adjust brightness to 0, turn backlight_enable signal
> off and keep eDP main link active.
>
> On general LCD, this
On Mon, 21 Jun 2021, "Navare, Manasi" wrote:
> Reviewed-by: Manasi Navare
Thanks, pushed to drm-intel-next.
BR,
Jani
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev7)
URL : https://patchwork.freedesktop.org/series/90898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10261_full -> Patchwork_20426_full
This workaround is specific for a particular panel on Google
chromebook project. When user space daemon enter idle state.
It request adjust brightness to 0, turn backlight_enable signal
off and keep eDP main link active.
On general LCD, this behavior might not be a problem.
But on this panel, its
== Series Details ==
Series: drm/i915/ttm: consider all placements for the page alignment
URL : https://patchwork.freedesktop.org/series/91771/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20428
Summary
== Series Details ==
Series: drm/i915/gen11: Disable cursor clock gating in HDR mode (rev2)
URL : https://patchwork.freedesktop.org/series/91674/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20427
== Series Details ==
Series: drm/i915/dp: Fix eDP max rate for display 11+
URL : https://patchwork.freedesktop.org/series/91764/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10261_full -> Patchwork_20425_full
Summary
On 22/06/2021 13:29, Thomas Hellström wrote:
On 6/22/21 2:15 PM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
wrote:
On 6/22/21 11:58 AM, Matthew Auld wrote:
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if
On 6/22/21 2:15 PM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
wrote:
On 6/22/21 11:58 AM, Matthew Auld wrote:
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might
On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
wrote:
>
>
> On 6/22/21 11:58 AM, Matthew Auld wrote:
> > Just checking the current region is not enough, if we later migrate the
> > object somewhere else. For example if the placements are {SMEM, LMEM},
> > then we might get this wrong. Another
On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach
wrote:
> Unknown is when no monitor is connected or is when the
> connector/monitor is disabled.
I think the other connector props (link-status, non-desktop, etc) don't
have a special "unset" value, and instead the value is set to a random
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev7)
URL : https://patchwork.freedesktop.org/series/90898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20426
Summary
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev7)
URL : https://patchwork.freedesktop.org/series/90898/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/dp: Fix eDP max rate for display 11+
URL : https://patchwork.freedesktop.org/series/91764/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20425
Summary
---
On 6/22/21 12:55 PM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed,
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
>
> For discrete, use TTM for both cached and WC system memory. That means
> we currently rely on the TTM memory accounting / shrinker. For cached
> system memory we should consider remaining shmem-backed, which can be
> implemented from our
== Series Details ==
Series: Revert "drm: add a locked version of drm_is_current_master"
URL : https://patchwork.freedesktop.org/series/91758/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10259_full -> Patchwork_20424_full
== Series Details ==
Series: drm/i915/dp: Fix eDP max rate for display 11+
URL : https://patchwork.freedesktop.org/series/91764/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
acf045305774 drm/i915/dp: Fix eDP max rate for display 11+
-:20: ERROR:GIT_COMMIT_ID: Please use git
On 6/22/21 11:58 AM, Matthew Auld wrote:
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead
On 6/22/21 11:44 AM, Matthew Auld wrote:
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object,
Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead of the BO.
Signed-off-by: Matthew Auld
Cc:
Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:14 +0200
> Werner Sembach wrote:
>
>> Add "Broadcast RGB" to general drm context so that more drivers besides
>> i915 and gma500 can implement it without duplicating code.
>>
>> Userspace can use this property to tell the
Am 22.06.21 um 09:00 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:08 +0200
> Werner Sembach wrote:
>
>> Add a new general drm property "active color range" which can be used by
>> graphic drivers to report the used color range back to userspace.
>>
>> There was no way to check which
On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
wrote:
>
> After a TTM move or object init we need to update the i915 gem flags and
> caching settings to reflect the new placement. Currently caching settings
> are not changed during the lifetime of an object, although that might
> change moving
Display underrun in HDR mode when cursor is enabled.
RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h.
As per W/A 1604331009, Disable cursor clock gating in HDR mode.
Bspec : 33451
Changes since V3:
- Disable WA when not in HDR mode or cursor plane not active - Ville
-
For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very
The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned.
After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system
Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.
Patch 2 deals
== Series Details ==
Series: Revert "drm: add a locked version of drm_is_current_master"
URL : https://patchwork.freedesktop.org/series/91758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10259 -> Patchwork_20424
Summary
Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:16 +0200
> Werner Sembach wrote:
>
>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>> driver.
>>
>> Signed-off-by: Werner Sembach
>> ---
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22
== Series Details ==
Series: Revert "drm: add a locked version of drm_is_current_master"
URL : https://patchwork.freedesktop.org/series/91758/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
44a4f4b18c74 Revert "drm: add a locked version of drm_is_current_master"
-:92:
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, June 22, 2021 1:57 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Atwood, Matthew S
> ; Shankar, Uma ; Ville
> Syrjälä ; Souza, Jose
> Subject: [PATCH] drm/i915/dp: Fix eDP max rate for display 11+
>
> From:
N.b. we need to figure out what the reported TGL CI issues were that
caused this to be reverted originally. Looks like there was no
follow-up?
BR,
Jani.
On Tue, 22 Jun 2021, Jani Nikula wrote:
> From: Matt Atwood
>
> intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
>
From: Matt Atwood
intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
use before intel_encoder->type is set. This causes incorrect max source
rate to be used for display 11+. On EHL and JSL, HBR3 is used instead of
HBR2, and on the other affected platforms, HBR2 is used
On Tue, Jun 22, 2021 at 09:54:09AM +0200, Daniel Vetter wrote:
> This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.
>
> Unfortunately this inverts the locking hierarchy, so back to the
> drawing board. Full lockdep splat below:
>
>
This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.
Unfortunately this inverts the locking hierarchy, so back to the
drawing board. Full lockdep splat below:
==
WARNING: possible circular locking dependency detected
On Fri, 18 Jun 2021 11:11:16 +0200
Werner Sembach wrote:
> This commit implements the "Broadcast RGB" drm property for the AMD GPU
> driver.
>
> Signed-off-by: Werner Sembach
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
>
On Fri, 18 Jun 2021 11:11:14 +0200
Werner Sembach wrote:
> Add "Broadcast RGB" to general drm context so that more drivers besides
> i915 and gma500 can implement it without duplicating code.
>
> Userspace can use this property to tell the graphic driver to use full or
> limited color range for
On Fri, 18 Jun 2021 11:11:11 +0200
Werner Sembach wrote:
> Add a new general drm property "preferred color format" which can be used
> by userspace to tell the graphic drivers to which color format to use.
>
> Possible options are:
> - auto (default/current behaviour)
> - rgb
> -
On Fri, 18 Jun 2021 11:11:08 +0200
Werner Sembach wrote:
> Add a new general drm property "active color range" which can be used by
> graphic drivers to report the used color range back to userspace.
>
> There was no way to check which color range got actually used on a given
> monitor. To
On Fri, 18 Jun 2021 11:11:05 +0200
Werner Sembach wrote:
> Add a new general drm property "active color format" which can be used by
> graphic drivers to report the used color format back to userspace.
>
> There was no way to check which color format got actually used on a given
> monitor. To
On Fri, 18 Jun 2021 11:11:02 +0200
Werner Sembach wrote:
> Add a new general drm property "active bpc" which can be used by graphic
> drivers to report the applied bit depth per pixel back to userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
> check which
92 matches
Mail list logo
