== Series Details ==
Series: drm/i915: Enable XE_HP 4Tile support
URL : https://patchwork.freedesktop.org/series/112143/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12521 -> Patchwork_112143v1
Summary
---
On 22.12.2022 04:07, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* series starting with [1/2] drm/i915/display/core: use
intel_de_rmw if possible
*URL:* https://patchwork.freedesktop.org/series/112101/
*State:*failure
*Details:*
== Series Details ==
Series: drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev2)
URL : https://patchwork.freedesktop.org/series/111433/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12521 -> Patchwork_111433v2
MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands
to GSC f/w. It requires to keep hdcp display driver
agnostic to content protection f/w (ME/GSC fw) in the form of
i915_hdcp_fw_ops generic ops.
Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic
ops instead of
Add function that takes care of sending command to gsc cs. We start
of with allocation of memory for our command intel_hdcp_gsc_message that
contains gsc cs memory header as directed in specs followed by the
actual payload hdcp message that we want to send.
Spec states that we need to poll pending
It requires to move intel specific HDCP API structures to
i915_cp_fw_hdcp_interface.h from driver/misc/mei/hdcp/mei_hdcp.h
so that any content protection fw interfaces can use these
structures.
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
Need to fill wired cmd in structures at a single place as they remain
same for both gsc and mei.
--v3
-remove inline function from header [Jani]
Cc: Ankit Nautiyal
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_hdcp_interface.c |
As now we have more then one type of content protection
secrity firmware. Let change the i915_cp_fw_hdcp_interface.h
header naming convention to suit generic f/w type.
%s/MEI_/HDCP_
%s/mei_dev/hdcp_dev
As interface to CP FW can be either a non i915 component or
i915 intergral component, change
From: Anshuman Gupta
Change the include/drm/i915_mei_hdcp_interface.h to
include/drm/i915_hdcp_interface.h
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
Signed-off-by: Suraj Kandpal
Acked-by: Tomas Winkler
---
HDCP and PXP will require a common function to allow it to
submit commands to the gsc cs. Also adding the gsc mtl header
that needs to be added on to the existing payloads of HDCP
and PXP.
--v4
-Seprate gsc load and heci cmd submission into different
functions in different files for better
These patches enable HDCP2.x on machines MTL and above.
>From MTL onwards CSME is spilt into GSC and CSC and now
we use GSC CS instead of MEI to talk to firmware to start
HDCP authentication
--v2
-Fixing some checkpatch changes which I forgot before sending
out the series
--v3
-Drop cp and fw to
The dsb context should be already checked for NULL, before dsb_commit gets
called. So remove the check for dsb inside dsb_commit.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dsb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
== Series Details ==
Series: drm/i915/dmc: Make firmware loading backwards-compatible (rev2)
URL : https://patchwork.freedesktop.org/series/112116/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12521 -> Patchwork_112116v2
== Series Details ==
Series: drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index (rev2)
URL : https://patchwork.freedesktop.org/series/112108/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_112108v2_full
== Series Details ==
Series: drm/i915/dmc: Make firmware loading backwards-compatible (rev2)
URL : https://patchwork.freedesktop.org/series/112116/
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: drm/i915/display: Implement Wa_14015648006 (rev2)
URL : https://patchwork.freedesktop.org/series/103518/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12521 -> Patchwork_103518v2
Summary
== Series Details ==
Series: drm/i915/dp: wait on timeout before retry include sw delay (rev9)
URL : https://patchwork.freedesktop.org/series/111303/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_111303v9_full
Hi Lucas,
Thanks for catching the issues. For ADL-P I will send a new patch to
correct the timeout to 500usec.
Thanks & Regards,
Ankit
On 12/22/2022 5:31 AM, Lucas De Marchi wrote:
On Wed, Dec 07, 2022 at 08:24:36PM +0530, Ankit Nautiyal wrote:
For Gen12+ wait for 1ms for Combo Phy and
== Series Details ==
Series: series starting with [1/1] drm/i915/pxp: Use drm_dbg if arb session
failed due to fw version
URL : https://patchwork.freedesktop.org/series/112120/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_112120v1_full
== Series Details ==
Series: drm/i915/color: Add function to load degamma LUT in MTL
URL : https://patchwork.freedesktop.org/series/112135/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12520 -> Patchwork_112135v1
Summary
There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate
is capped to 340MHz via VBT. In such cases scrambling might be supported
by the platform and an HDMI2.0 sink for lower TMDS rates, but not
supported by the retimer, causing blankouts.
So avoid enabling scrambling, if the
== Series Details ==
Series: Fixes for intel fb helper
URL : https://patchwork.freedesktop.org/series/112133/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12520 -> Patchwork_112133v1
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/mtl: Add support of Tile4 to MTL (rev2)
URL : https://patchwork.freedesktop.org/series/112063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_112063v2_full
== Series Details ==
Series: series starting with [1/2] drm/i915/display/core: use intel_de_rmw if
possible
URL : https://patchwork.freedesktop.org/series/112101/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_112101v1_full
== Series Details ==
Series: drm/i915/ttm: remove the virtualized start hack
URL : https://patchwork.freedesktop.org/series/112100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_112100v1_full
== Series Details ==
Series: drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index (rev2)
URL : https://patchwork.freedesktop.org/series/112108/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_112108v2
== Series Details ==
Series: series starting with [1/2] drm/i915/dp_mst: log when pulling CRTCs into
atomic state (rev2)
URL : https://patchwork.freedesktop.org/series/111967/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_111967v2_full
== Series Details ==
Series: drm/i915/display: Fix a use-after-free when intel_edp_init_connector
fails
URL : https://patchwork.freedesktop.org/series/112091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_112091v1_full
== Series Details ==
Series: drm/i915/dp: wait on timeout before retry include sw delay (rev9)
URL : https://patchwork.freedesktop.org/series/111303/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_111303v9
> > >
Alan:[snip]
> > > + u8 gsc_address;
> > > +#define HECI_MEADDRESS_PXP 17
> > > +#define HECI_MEADDRESS_HDCP 18
> > > +
Alan: btw, from the internal specs, if i understand it correctly, at the heci
command packet level, this ought to be called "heci_client_id", not
"gsc_address".
== Series Details ==
Series: series starting with [1/1] drm/i915/pxp: Use drm_dbg if arb session
failed due to fw version
URL : https://patchwork.freedesktop.org/series/112120/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_112120v1
On Wed, Dec 21, 2022 at 12:26:26PM +0200, Jani Nikula wrote:
On Tue, 20 Dec 2022, Gustavo Sousa wrote:
As we do not require specific versions anymore, change the convention
for blob filenames to stop using version numbers. This simplifies code
maintenance, since we do not need to keep updating
On 20. 12. 2022. 20:34, Mirsad Todorovac wrote:
On 12/20/22 16:52, Tvrtko Ursulin wrote:
On 20/12/2022 15:22, srinivas pandruvada wrote:
+Added DRM mailing list and maintainers
On Tue, 2022-12-20 at 15:33 +0100, Mirsad Todorovac wrote:
Hi all,
I have been unsuccessful to find any
== Series Details ==
Series: drm/i915/mtl: Add support of Tile4 to MTL (rev2)
URL : https://patchwork.freedesktop.org/series/112063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_112063v2
Summary
---
== Series Details ==
Series: treewide: Convert del_timer*() to timer_shutdown*()
URL : https://patchwork.freedesktop.org/series/112115/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/112115/revisions/1/mbox/ not
applied
Applying: treewide:
On Wed, Dec 07, 2022 at 08:24:36PM +0530, Ankit Nautiyal wrote:
For Gen12+ wait for 1ms for Combo Phy and 3ms for TC Phy for
description here doesn't match the code as DG2 is also >= 12.
Maybe just mention that the values are following the updated ones in
bspec?
DDI_BUF_CTL to be active for
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/mtl: limit second scaler
vertical scaling in ver >= 14
URL : https://patchwork.freedesktop.org/series/111779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519_full -> Patchwork_111779v1_full
== Series Details ==
Series: series starting with [1/2] drm/i915/display/core: use intel_de_rmw if
possible
URL : https://patchwork.freedesktop.org/series/112101/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_112101v1
== Series Details ==
Series: drm/i915/ttm: remove the virtualized start hack
URL : https://patchwork.freedesktop.org/series/112100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_112100v1
Summary
---
== Series Details ==
Series: Possible regression in drm/i915 driver: memleak
URL : https://patchwork.freedesktop.org/series/112109/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/112109/revisions/1/mbox/ not
applied
Applying: Possible regression
== Series Details ==
Series: series starting with [1/2] drm/i915/dp_mst: log when pulling CRTCs into
atomic state (rev2)
URL : https://patchwork.freedesktop.org/series/111967/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_111967v2
== Series Details ==
Series: drm/i915/display: Fix a use-after-free when intel_edp_init_connector
fails
URL : https://patchwork.freedesktop.org/series/112091/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_112091v1
== Series Details ==
Series: series starting with [1/2] drm/i915/display/core: use intel_de_rmw if
possible
URL : https://patchwork.freedesktop.org/series/112101/
State : warning
== Summary ==
Error: dim checkpatch failed
d968db4e1183 drm/i915/display/core: use intel_de_rmw if possible
-:26:
Force PXP configs on for CI testing to trigger full subtests
in IGT's gem_pxp as opposed to the partial "unsupported hw substests".
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Kconfig | 2 +-
drivers/misc/mei/pxp/Kconfig | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no
From: Alexander Usyskin
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Signed-off-by: Alexander Usyskin
---
From: Alexander Usyskin
Async runtime resume is not possible while system is suspending.
The power management subsystem resumes device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in prepare callbacks.
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the
From: Alexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier
to ensure proper ordering of power flows.
V2: condition on absence of heci_pxp to filter out DG
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++
1 file changed, 7
A customer issue was recently discovered and in the process a
gap in i915's PXP interaction with HW+FW architecure was also
realized. This series adds those missing pieces.
This fix includes changes where i915 calls into the mei
component interface in order to submit requests to the security
Apologies for the noise, please ignore this thread - will resend.
Had unnecessary in-reply-to tag causing split in series URLs.
On Wed, 2022-12-21 at 14:54 -0800, Alan Previn wrote:
> Add missing cleanup steps for PXP global-teardown
Force PXP configs on for CI testing to trigger full subtests
in IGT's gem_pxp as opposed to the partial "unsupported hw substests".
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Kconfig | 2 +-
drivers/misc/mei/pxp/Kconfig | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a
From: Alexander Usyskin
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Signed-off-by: Alexander Usyskin
---
From: Alexander Usyskin
Async runtime resume is not possible while system is suspending.
The power management subsystem resumes device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in prepare callbacks.
A customer issue was recently discovered and in the process a
gap in i915's PXP interaction with HW+FW architecure was also
realized. This series adds those missing pieces.
This fix includes changes where i915 calls into the mei
component interface in order to submit requests to the security
From: Alexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier
to ensure proper ordering of power flows.
V2: condition on absence of heci_pxp to filter out DG
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 +++
1 file changed, 7
== Series Details ==
Series: series starting with [1/2] drm/i915/dp_mst: log when pulling CRTCs into
atomic state (rev2)
URL : https://patchwork.freedesktop.org/series/111967/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [1/2] drm/i915/dp_mst: log when pulling CRTCs into
atomic state (rev2)
URL : https://patchwork.freedesktop.org/series/111967/
State : warning
== Summary ==
Error: dim checkpatch failed
3b9a9285f15d drm/i915/dp_mst: log when pulling CRTCs into
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/mtl: limit second scaler
vertical scaling in ver >= 14
URL : https://patchwork.freedesktop.org/series/111779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12519 -> Patchwork_111779v1
== Series Details ==
Series: drm/i915/mtl: handle some MTL scaler limitations
URL : https://patchwork.freedesktop.org/series/112089/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
CC [M]
Hi Zhi,
Thanks again for your reply and clear explaination about the function.
I still have some doubt about the fix. Here is a invoke chain :
ppgtt_populate_spt
->ppgtt_populate_shadow_entry
->split_2MB_gtt_entry
As far as I'm concerned, when something error happens in DMA mapping,
which
On 20.12.2022. 20:34, Mirsad Todorovac wrote:
On 12/20/22 16:52, Tvrtko Ursulin wrote:
On 20/12/2022 15:22, srinivas pandruvada wrote:
+Added DRM mailing list and maintainers
On Tue, 2022-12-20 at 15:33 +0100, Mirsad Todorovac wrote:
Hi all,
I have been unsuccessful to find any particular
While working on a drm driver that doesn't need the i2c algobit stuff I
noticed that DRM selects this code even though only 8 drivers actually use
it. While also only some drivers use i2c, keep the select for I2C for the
next cleanup patch. Still prepare this already by also selecting I2C for
the
On 20. 12. 2022. 16:52, Tvrtko Ursulin wrote:
On 20/12/2022 15:22, srinivas pandruvada wrote:
+Added DRM mailing list and maintainers
On Tue, 2022-12-20 at 15:33 +0100, Mirsad Todorovac wrote:
Hi all,
I have been unsuccessful to find any particular Intel i915 maintainer
emails, so my best
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt. But the caller does
not notice that, it will free spt again in error path.
Fix this by undoing the mapping of DMA address and freeing sub_spt.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt. But the
caller function ppgtt_populate_spt_by_guest_entry does not notice
that, it will free spt again in its error path.
Fix this by undoing the mapping of DMA address and freeing
Steven Rostedt writes:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At least add the trivial ones
>
Wang, Zhi A 于2022年12月19日周一 16:22写道：
>
> I think it is a case-by-case thing. For example:
>
> The current scenario in this function looks like below:
>
> caller pass spt a
> function
> alloc spt b
> something error
> free spt a
> return error
>
> The problem is:
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt. But the caller does
not notice that, it will free spt again in error path.
Fix this by undoing the mapping of DMA address and freeing sub_spt.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M
On 08/12/2022 1:55 pm, Marek Marczykowski-Górecki wrote:
> Hi,
>
> There is an issue with i915 on Xen PV (dom0). The end result is a lot of
> glitches, like here: https://openqa.qubes-os.org/tests/54748#step/startup/8
> (this one is on ADL, Linux 6.1-rc7 as a Xen PV dom0). It's using Xorg
> with
One-element arrays are deprecated, and we are replacing them with
flexible array members instead. So, replace one-element array with
flexible-array member in struct gvt_firmware_header and refactor the
rest of the code accordingly.
Additionally, previous implementation was allocating 8 bytes more
On 12/20/22 16:52, Tvrtko Ursulin wrote:
On 20/12/2022 15:22, srinivas pandruvada wrote:
+Added DRM mailing list and maintainers
On Tue, 2022-12-20 at 15:33 +0100, Mirsad Todorovac wrote:
Hi all,
I have been unsuccessful to find any particular Intel i915 maintainer
emails, so my best bet is
== Series Details ==
Series: drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock >
340MHz (rev2)
URL : https://patchwork.freedesktop.org/series/111877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12518_full -> Patchwork_111877v2_full
From: John Harrison
A static analyser was complaining about not checking for null
pointers. However, the location of the complaint can only be reached
in the first place if said pointer is non-null. Basically, if we are
using a v69 GuC then the descriptor pool is guaranteed to be alocated
at
From: John Harrison
In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then release would be called again leading to a double kfree.
From: John Harrison
The CI results for the 'fast request' patch set (enables error return
codes for fire-and-forget H2G messages) hit an issue with the KMD
sending context submission requests on an invalid context. That was
caused by a fault injection probe failing the context creation of a
From: John Harrison
Fix a bunch of assorted issues with firmware loading and GuC
intialisation.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Fix missing return code checks in submission init
drm/i915/guc: Fix a static analysis warning
drm/i915/uc: Fix two issues with
On Tue, 2022-12-20 at 07:19 +, Kandpal, Suraj wrote:
> >
> > On Wed, 2022-12-14 at 14:37 +0530, Suraj Kandpal wrote:
> >
> >
> > Alan: See my review comment on patch #1 - i believe most of this function
> > above
> > (intel_hdcp_gsc_msg_send) could go into a common
> >
== Series Details ==
Series: fix RC6p related regression on Sandy Bridge
URL : https://patchwork.freedesktop.org/series/112072/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12518_full -> Patchwork_112072v1_full
Summary
== Series Details ==
Series: drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock >
340MHz (rev2)
URL : https://patchwork.freedesktop.org/series/111877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12518 -> Patchwork_111877v2
== Series Details ==
Series: drm/i915/mtl: implement wa 14015076503 (rev2)
URL : https://patchwork.freedesktop.org/series/112049/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12518_full -> Patchwork_112049v2_full
Summary
On Wed, Dec 07, 2022 at 07:50:49PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Align DDI_BUF_CTL Active timeouts with Bspec updates (rev5)
> URL : https://patchwork.freedesktop.org/series/111373/
> State : success
Thanks for the patches, pushed to drm-intel-next.
>
> ==
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually
== Series Details ==
Series: fix RC6p related regression on Sandy Bridge
URL : https://patchwork.freedesktop.org/series/112072/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12518 -> Patchwork_112072v1
Summary
---
== Series Details ==
Series: Fixes for various UC related issues
URL : https://patchwork.freedesktop.org/series/112080/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
CC [M] drivers/gpu/drm/i915/gt/uc/intel_uc_fw.o
On Wed, 2022-12-21 at 12:21 +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Alan Previn wrote:
> >
Alan:[snip]
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > @@ -298,6 +298,11 @@ int intel_pxp_tee_cmd_create_arb_session(struct
> > intel_pxp *pxp,
> >
> > if (ret)
> >
== Series Details ==
Series: drm/i915/mtl: implement wa 14015076503 (rev2)
URL : https://patchwork.freedesktop.org/series/112049/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12518 -> Patchwork_112049v2
Summary
---
On 12/20/2022 12:46 PM, Matthew Auld wrote:
We should still be able to GTT evict objects during execbuf (old
bindings can linger around), even if there is object lock contention. In
the worst case the execbuf should just wait on the contented locks.
Returning -ENOSPC smells like a regression
== Series Details ==
Series: drm/i915/display/dsi: use intel_de_rmw if possible
URL : https://patchwork.freedesktop.org/series/112062/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12517_full -> Patchwork_112062v1_full
On Wed, 2022-12-21 at 13:05 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 21.12.22 um 12:19 schrieb Jouni Högander:
> > Checking if damage clip is valid is common to all fb helpers.
> > Makes more sense to check it in higher level than adding into
> > all helpers.
>
> It was a deliberate decision
Add .has_4tile tag to XE_HP_FEATURES set.
Remove duplicate entry from DG2_FEATURES.
Signed-off-by: Jonathan Cavitt
Cc: Bommu Krishnaiah
Cc: Roper Matthew D
Cc: Kempczynski Zbigniew
Cc: Telukuntla Sreedhar
Acked-by: Matt Roper
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1
After splitting generic drm_fb_helper into it's own file it's left to
helper implementation to have fb_dirty function. Currently intel
fbdev doesn't have it. This is causing problems to features (PSR, FBC,
DRRS) relying on dirty callback.
Implement simple fb_dirty callback to deliver
On Wed, Dec 21, 2022 at 04:08:13PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 21.12.22 um 15:51 schrieb Ville Syrjälä:
> > On Wed, Dec 21, 2022 at 11:49:59AM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 29.11.22 um 13:43 schrieb Jouni Högander:
> >>> After splitting generic drm_fb_helper
On Wed, Dec 21, 2022 at 12:26:26PM +0200, Jani Nikula wrote:
> > - request_firmware(, dev_priv->display.dmc.fw_path, dev_priv->drm.dev);
> > + err = firmware_request_nowarn(, dev_priv->display.dmc.fw_path,
> > dev_priv->drm.dev);
> > +
> > + if (err == -ENOENT &&
Hi
Am 21.12.22 um 15:51 schrieb Ville Syrjälä:
On Wed, Dec 21, 2022 at 11:49:59AM +0100, Thomas Zimmermann wrote:
Hi
Am 29.11.22 um 13:43 schrieb Jouni Högander:
After splitting generic drm_fb_helper into it's own file it's left to
helper implementation to have fb_dirty function. Currently
As we do not require specific versions anymore, change the convention
for blob filenames to stop using version numbers. This simplifies code
maintenance, since we do not need to keep updating blob paths for new
DMC releases, and also makes DMC loading compatible with systems that do
not have the
1 - 100 of 120 matches
Mail list logo
