Re-reproted.
-Original Message-
From: Roper, Matthew D
Sent: Tuesday, July 12, 2022 8:55 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/dg2:
Add Wa_15010599737
On Sat, Jul 09, 2022 at
== Series Details ==
Series: drm/i915: Correct ss -> steering calculation for pre-Xe_HP platforms
URL : https://patchwork.freedesktop.org/series/106269/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11877_full -> Patchwork_106269v1_full
live_rps_control is failing in BAT on a TGL. Increase the
time we wait for actual frequency to change, and see if this
is just a matter of slowness.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/1759
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 3 ++-
1
== Series Details ==
Series: drm/i915/guc: Don't use pr_err when not necessary
URL : https://patchwork.freedesktop.org/series/106275/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11877 -> Patchwork_106275v1
Summary
From: John Harrison
A bunch of code was copy/pasted using pr_err as the default way to
report errors. However, drm_err is significantly more useful in
identifying where the error came from. So update the code to use that
instead.
Signed-off-by: John Harrison
---
On Tue, Jul 12, 2022 at 04:31:31PM -0700, john.c.harri...@intel.com wrote:
> From: Michał Winiarski
>
> Since we're going to use semaphores in selftests (and eventually in
> regular GuC submission), let's route semaphores to GuC.
I don't think this comment isn't correct, we have no plans to use
On Tue, Jul 12, 2022 at 04:31:33PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> It is no longer guaranteed that there will always be an RCS engine.
> So, use the helper function for finding the first available engine that
> can be used for general purpose selftets.
>
>
On Tue, Jul 12, 2022 at 04:31:36PM -0700, john.c.harri...@intel.com wrote:
> From: Alan Previn
>
> Add a helper to get GuC log buffer size.
>
> Signed-off-by: Alan Previn
John - you need to add a Signed-off-by since you posted.
Patch LGTM:
Reviewed-by: Matthew Brost
> ---
>
== Series Details ==
Series: Random assortment of (mostly) GuC related patches
URL : https://patchwork.freedesktop.org/series/106272/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/106272/revisions/1/mbox/ not
found
== Series Details ==
Series: drm/i915: Correct ss -> steering calculation for pre-Xe_HP platforms
URL : https://patchwork.freedesktop.org/series/106269/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11877 -> Patchwork_106269v1
== Series Details ==
Series: series starting with [1/2] drm/i915/dg2: Add Wa_15010599737
URL : https://patchwork.freedesktop.org/series/106130/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11862_full -> Patchwork_106130v1_full
From: John Harrison
It is useful to be able to match GuC events to kernel events when
looking at the GuC log. That requires being able to convert GuC
timestamps to kernel time. So, when dumping error captures and/or GuC
logs, include a stamp in both time zones plus the clock frequency.
From: Michał Winiarski
Since we're going to use semaphores in selftests (and eventually in
regular GuC submission), let's route semaphores to GuC.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h| 4
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
From: John Harrison
It is no longer guaranteed that there will always be an RCS engine.
So, use the helper function for finding the first available engine that
can be used for general purpose selftets.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 12
From: John Harrison
When the KMD sends a CLIENT_RESET request to GuC (as part of the
suspend sequence), GuC will mark the CTB buffer as 'UNUSED'. If the
KMD then checked the CTB queue, it would see a non-zero status value
and report the buffer as corrupted.
Technically, no G2H messages should
From: Matthew Brost
The GuC needs a copy of a golden context for implementing watchdog
resets (aka media resets). This context is larger on newer platforms.
So adjust the size being allocated/copied accordingly.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10
From: Matthew Brost
Having semaphores results in different behavior when a dependent request
is cancelled. In the case of semaphores the request could be on the HW
and complete successfully while without the request is held in the
driver and the error from the dependent request is propagated.
From: Chris Wilson
Use a temporary page and mempy_from_wc to reduce the time it takes to
dump the guc log to debugfs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 --
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git
From: Alan Previn
Add a helper to get GuC log buffer size.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 49 --
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
From: Matthew Brost
Remove bogus GEM_BUG_ON which compared kernel context timeline seqno to
seqno in memory on engine PM unpark. If a GT reset occurred these values
might not match as a kernel context could be skipped. This bug was
hidden by always switching to a kernel context on park
From: Rahul Kumar Singh
Add a test to check that the hangcheck will recover from a submission
hang in the GuC.
Signed-off-by: Rahul Kumar Singh
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 159 ++
From: John Harrison
When debugging GuC communication issues, it is useful to have the CTB
info available. So add the state and buffer contents to the error
capture log.
Also, add a sub-structure for the GuC specific error capture info as
it is now becoming numerous.
Signed-off-by: John
From: John Harrison
Pushing a bunch of patches which had gotten forgotten about.
Signed-off-by: John Harrison
Alan Previn (1):
drm/i915/guc: Add a helper for log buffer size
Chris Wilson (1):
drm/i915/guc: Use streaming loads to speed up dumping the guc log
John Harrison (4):
From: Matthew Brost
The engine registers really shouldn't be touched during GuC submission
as the GuC owns the registers. Don't call ring_is_idle and tie
intel_engine_is_idle strictly to the engine pm.
Because intel_engine_is_idle tied to the engine pm, retire requests
before checking
== Series Details ==
Series: drm/i915/ttm: fix 32b build
URL : https://patchwork.freedesktop.org/series/106260/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11877_full -> Patchwork_106260v1_full
Summary
---
On Mon, Jul 11, 2022 at 01:20:21PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's one gvt fix for 5.19, from Dan for shmem_pin_map() return check bug.
>
> Thanks!
> ---
>
> The following changes since commit d72d69abfdb6e0375981cfdda8eb45143f12c77d:
>
> drm/i915/gvt: Make DRM_I915_GVT depend
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev7)
URL : https://patchwork.freedesktop.org/series/105167/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11877_full -> Patchwork_105167v7_full
Accidental use of a "SLICE" macro where a "SUBSLICE" macro was intended
causes the group ID for steering to be calculated incorrectly on
pre-Xe_HP platforms.
Fixes: 9a92732f040a ("drm/i915/gt: Add general DSS steering iterator to
intel_gt_mcr")
Signed-off-by: Matt Roper
---
On Tue, Jul 12, 2022 at 08:29:32AM +0200, Karolina Drobnik wrote:
> Hi Rodrigo,
>
> Many thanks for taking another look at the patches.
>
> On 08.07.2022 16:40, Rodrigo Vivi wrote:
> > On Fri, Jul 08, 2022 at 04:20:13PM +0200, Karolina Drobnik wrote:
> > > From: Chris Wilson
> > >
> > > One
On Tue, Jul 12, 2022 at 04:21:33PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Avoid trying to invalidate the TLB in the middle of performing an
> engine reset, as this may result in the reset timing out. Currently,
> the TLB invalidate is only serialised by its own mutex,
On Mon, Jul 04, 2022 at 09:31:55AM +0100, Tvrtko Ursulin wrote:
On 01/07/2022 15:54, Summers, Stuart wrote:
On Fri, 2022-07-01 at 09:37 +0100, Tvrtko Ursulin wrote:
On 01/07/2022 01:11, Umesh Nerlige Ramappa wrote:
On Thu, Jun 30, 2022 at 09:00:28PM +, Stuart Summers wrote:
In the
== Series Details ==
Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a
single display (rev2)
URL : https://patchwork.freedesktop.org/series/104084/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11877 -> Patchwork_104084v2
== Series Details ==
Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a
single display (rev2)
URL : https://patchwork.freedesktop.org/series/104084/
State : warning
== Summary ==
Error: dim checkpatch failed
710cf204aa62 ACPI: video: Add
On Thu, 16 Jun 2022 21:50:55 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 16 Jun 2022 15:01:59 -0700, Zhanjun Dong wrote:
> >
> > We are seeing error message of "No response for request". Some cases
> > happened while waiting for response and reset/suspend action was triggered.
> > In this case, no
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.
The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdego...@redhat.com/
Signed-off-by: Hans de Goede
---
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is
Remove this check from the asus-wmi backlight handling:
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight,
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.
So remove the handling for this from the apple-gmux driver.
Signed-off-by: Hans de Goede
---
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Signed-off-by: Hans
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Signed-off-by: Hans de Goede
---
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.
This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step towards this is to deal with some existing technical debt
in backlight handling on
== Series Details ==
Series: drm/i915/ttm: fix 32b build
URL : https://patchwork.freedesktop.org/series/106260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11877 -> Patchwork_106260v1
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/ttm: fix 32b build
URL : https://patchwork.freedesktop.org/series/106260/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev7)
URL : https://patchwork.freedesktop.org/series/105167/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11877 -> Patchwork_105167v7
Summary
---
== Series Details ==
Series: Fix TLB invalidate issues with Broadwell (rev7)
URL : https://patchwork.freedesktop.org/series/105167/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: dma-buf: revert "return only unsignaled fences in
dma_fence_unwrap_for_each v3"
URL : https://patchwork.freedesktop.org/series/106241/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11876_full -> Patchwork_106241v1_full
Since segment_pages is no longer a compile time constant, it looks the
DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest
is just to use the ULL variant, but really we should need not need more
than u32 for the page alignment (also we are limited by that due to the
sg->length
== Series Details ==
Series: drm/i915/display: Ensure PSR gets disabled if no encoders in new state
(rev3)
URL : https://patchwork.freedesktop.org/series/106168/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11870_full -> Patchwork_106168v3_full
On Sat, Jul 09, 2022 at 07:41:45AM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/dg2: Add Wa_15010599737
> URL : https://patchwork.freedesktop.org/series/106130/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from
From: Chris Wilson
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the
i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:
http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4
When such test runs, the only output is:
[ 68.811639] i915: Performing live
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that
== Series Details ==
Series: series starting with [1/3] drm/i915: audit bo->resource usage
URL : https://patchwork.freedesktop.org/series/106247/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11876 -> Patchwork_106247v1
== Series Details ==
Series: series starting with [1/3] drm/i915: audit bo->resource usage
URL : https://patchwork.freedesktop.org/series/106247/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [1/3] drm/i915: audit bo->resource usage
URL : https://patchwork.freedesktop.org/series/106247/
State : warning
== Summary ==
Error: dim checkpatch failed
8590bed72c4c drm/i915: audit bo->resource usage
-:49: WARNING:FROM_SIGN_OFF_MISMATCH:
== Series Details ==
Series: dma-buf: revert "return only unsignaled fences in
dma_fence_unwrap_for_each v3"
URL : https://patchwork.freedesktop.org/series/106241/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11876 -> Patchwork_106241v1
== Series Details ==
Series: dma-buf: revert "return only unsignaled fences in
dma_fence_unwrap_for_each v3"
URL : https://patchwork.freedesktop.org/series/106241/
State : warning
== Summary ==
Error: dim checkpatch failed
c41b1c62aaaf dma-buf: revert "return only unsignaled fences in
On Tue, Jul 12, 2022 at 8:06 AM Christian König
wrote:
>
> Hi Karolina,
>
> Am 12.07.22 um 14:04 schrieb Karolina Drobnik:
> > Hi Christian,
> >
> > On 12.07.2022 12:28, Christian König wrote:
> >> This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
> >>
> >> It turned out that this is
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Saturday, July 9, 2022 3:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915/dg2: Add Wa_15010599737
>
> This workaround may need to be extended to other platforms soon, but for
>
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Saturday, July 9, 2022 3:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/2] drm/i915: Add Wa_14016291713
>
> We already disable FBC when PSR2 is enabled on display version 12 and
> above;
Hi Christian,
On 12.07.2022 12:28, Christian König wrote:
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
It turned out that this is not correct. Especially the sync_file info
IOCTL needs to see even signaled fences to correctly report back their
status to userspace.
Instead add
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
Make sure we can at least move and alloc TT objects without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git
On 7/6/22 8:05 PM, Mauro Carvalho Chehab wrote:
On Wed, 6 Jul 2022 18:04:20 +0300
Gwan-gyeong Mun wrote:
On 7/5/22 5:23 PM, Mauro Carvalho Chehab wrote:
On Tue, 5 Jul 2022 15:24:49 +0300
Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into drm util header from
On 7/6/22 8:10 PM, Mauro Carvalho Chehab wrote:
On Wed, 6 Jul 2022 19:33:22 +0300
Gwan-gyeong Mun wrote:
On 7/5/22 5:35 PM, Mauro Carvalho Chehab wrote:
On Tue, 5 Jul 2022 15:24:50 +0300
Gwan-gyeong Mun wrote:
From: Chris Wilson
We need to check that we avoid integer overflows
This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83.
It turned out that this is not correct. Especially the sync_file info
IOCTL needs to see even signaled fences to correctly report back their
status to userspace.
Instead add the filter in the merge function again where it makes sense.
Hi Karolina,
> One impact of commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove
> dma_resv workaround") is that it stores many, many more fences. Whereas
> adding an exclusive fence used to remove the shared fence list, that
> list is now preserved and the write fences included into the list. Not
== Series Details ==
Series: drm/i915/display: Ensure PSR gets disabled if no encoders in new state
(rev3)
URL : https://patchwork.freedesktop.org/series/106168/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11870_full -> Patchwork_106168v3_full
Hi Rodrigo,
Many thanks for taking another look at the patches.
On 08.07.2022 16:40, Rodrigo Vivi wrote:
On Fri, Jul 08, 2022 at 04:20:13PM +0200, Karolina Drobnik wrote:
From: Chris Wilson
One impact of commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove
dma_resv workaround") is that it
93 matches
Mail list logo
