== Series Details ==
Series: drm/i915/display: Initalizalize capability variables
URL : https://patchwork.freedesktop.org/series/131615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14482 -> Patchwork_131615v1
Summary
Initialize HDCP capability variables to false to avoid UBSAN
warning in boolean value.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced these warnings:
include/uapi/drm/panthor_drm.h:344: warning: Function parameter or struct
member 'core_features' not described in 'drm_panthor_gpu_info'
include/uapi/drm/panthor_drm.h:344: warning: Function
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/ABI/testing/sysfs-driver-panfrost-profiling:2: ERROR: Unexpected
indentation.
Introduced by commit
b12f3ea7c188 ("drm/panfrost: Replace fdinfo's profiling debugfs knob with
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Monday, March 25, 2024 11:28 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Borislav Petkov
> Subject: [PATCH] drm/i915: Pre-populate the cursor physical dma address
>
> From: Ville
On 3/25/2024 8:48 PM, Jani Nikula wrote:
On Fri, 22 Mar 2024, Ankit Nautiyal wrote:
Currently we probe for lspcon, inside lspcon init. Which does 2 things:
probe the lspcon and set the expected LS/PCON mode.
If there is no lspcon connected, the probe expectedly fails and
results in error
On 3/25/2024 8:47 PM, Jani Nikula wrote:
On Fri, 22 Mar 2024, Ankit Nautiyal wrote:
LSPCON can be configured to LS or PCON mode.
Separate the function to set the expected mode from the lspcon probe
function during lspcon init.
Signed-off-by: Ankit Nautiyal
---
== Series Details ==
Series: drm/i915: Pre-populate the cursor physical dma address
URL : https://patchwork.freedesktop.org/series/131598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14482 -> Patchwork_131598v1
Summary
== Series Details ==
Series: drm/i915: Pre-populate the cursor physical dma address
URL : https://patchwork.freedesktop.org/series/131598/
State : warning
== Summary ==
Error: dim checkpatch failed
ea1a24509867 drm/i915: Pre-populate the cursor physical dma address
-:27:
== Series Details ==
Series: drm/i915: Delete stray .rej file
URL : https://patchwork.freedesktop.org/series/131587/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14482 -> Patchwork_131587v1
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: Delete stray .rej file
URL : https://patchwork.freedesktop.org/series/131587/
State : warning
== Summary ==
Error: dim checkpatch failed
eac6c895807a drm/i915: Delete stray .rej file
-:17: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
== Series Details ==
Series: drm/i915/gem: Calculate object page offset for partial memory mapping
URL : https://patchwork.freedesktop.org/series/131582/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14482 -> Patchwork_131582v1
== Series Details ==
Series: drm/i915/gem: Calculate object page offset for partial memory mapping
URL : https://patchwork.freedesktop.org/series/131582/
State : warning
== Summary ==
Error: dim checkpatch failed
54dc7dc5eb50 drm/i915/gem: Calculate object page offset for partial memory
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
MAINTAINERS
between commits:
35df039b26ac ("dt-bindings: gpu: Rename img,powervr to img,powervr-rogue")
796da8ca7e05 ("dt-bindings: gpu: Add PowerVR Series5 SGX GPUs")
from Linus' tree and commit:
3f9ba0c01125
Hi Andi,
I have too many questions :) I think the patch makes sense but need more
context, see below:
On 3/25/2024 2:40 PM, Andi Shyti wrote:
To enable partial memory mapping of GPU virtual memory, it's
necessary to introduce an offset to the object's memory
(obj->mm.pages) scatterlist. This
Quoting Jani Nikula (2024-03-20 13:01:23-03:00)
>Prefer the intel_de_wait*() functions over the uncore interface.
>
>Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
>---
> drivers/gpu/drm/i915/display/intel_dpio_phy.c | 7 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 6 +++---
Quoting Jani Nikula (2024-03-20 13:01:22-03:00)
>Do some renames on the register wait functions for clarity and brevity:
>
>intel_de_wait_for_register-> intel_de_wait
>intel_de_wait_for_register_fw-> intel_de_wait_fw
>__intel_de_wait_for_register-> intel_de_wait_custom
>
On Mon, Mar 25, 2024 at 08:43:10PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 08:29:56PM +0200, Lisovskiy, Stanislav wrote:
> > On Mon, Mar 25, 2024 at 07:11:21PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 25, 2024 at 07:01:03PM +0200, Lisovskiy, Stanislav wrote:
> > > > On Mon, Mar
On Mon, Mar 25, 2024 at 08:22:41PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 08:16:55PM +0200, Lisovskiy, Stanislav wrote:
> > On Mon, Mar 25, 2024 at 07:01:48PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 25, 2024 at 06:55:21PM +0200, Lisovskiy, Stanislav wrote:
> > > > On Mon, Mar
On Mon, Mar 25, 2024 at 08:29:56PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 25, 2024 at 07:11:21PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 25, 2024 at 07:01:03PM +0200, Lisovskiy, Stanislav wrote:
> > > On Mon, Mar 25, 2024 at 04:45:49PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Mar
On Mon, Mar 25, 2024 at 07:11:21PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 07:01:03PM +0200, Lisovskiy, Stanislav wrote:
> > On Mon, Mar 25, 2024 at 04:45:49PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 25, 2024 at 01:23:26PM +0200, Stanislav Lisovskiy wrote:
> > > > According to
On Mon, Mar 25, 2024 at 08:16:55PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 25, 2024 at 07:01:48PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 25, 2024 at 06:55:21PM +0200, Lisovskiy, Stanislav wrote:
> > > On Mon, Mar 25, 2024 at 04:30:14PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Mar
On Mon, Mar 25, 2024 at 07:57:38PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Calling i915_gem_object_get_dma_address() from the vblank
> evade critical section triggers might_sleep().
>
> While we know that we've already pinned the framebuffer
> and thus
On Mon, Mar 25, 2024 at 07:01:48PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 06:55:21PM +0200, Lisovskiy, Stanislav wrote:
> > On Mon, Mar 25, 2024 at 04:30:14PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 25, 2024 at 01:23:27PM +0200, Stanislav Lisovskiy wrote:
> > > > In order to
From: Ville Syrjälä
Calling i915_gem_object_get_dma_address() from the vblank
evade critical section triggers might_sleep().
While we know that we've already pinned the framebuffer
and thus i915_gem_object_get_dma_address() will in fact
not sleep in this case, it seems reasonable to keep the
On Mon, Mar 25, 2024 at 06:54:44PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 05:33:42PM +0100, Borislav Petkov wrote:
> > On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> > > Let's see what Ville says, but in the end bisection might be the
> > > quickest way to find the
Hi Janusz,
On 2024-03-18 at 11:13:31 +0100, Janusz Krzysztofik wrote:
> A new helper has been introduced recently, used for fetching KTAP results
> of a single test case. Since that helper is called for that purpose
> only after the test module is loaded with all other test cases filtered
> out,
On Mon, Mar 25, 2024 at 07:01:03PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 25, 2024 at 04:45:49PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 25, 2024 at 01:23:26PM +0200, Stanislav Lisovskiy wrote:
> > > According to BSpec we need to do correspondent MBUS updates before
> > > or after
Hi Janusz,
On 2024-03-18 at 11:13:30 +0100, Janusz Krzysztofik wrote:
> Up to now we were loading a KUnit test module in test execution mode only
> once per subtest, in background, and then, in parallel with execution of
> test cases while the module was loading, we were looking through dmesg for
On Mon, Mar 25, 2024 at 06:55:21PM +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 25, 2024 at 04:30:14PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 25, 2024 at 01:23:27PM +0200, Stanislav Lisovskiy wrote:
> > > In order to make sure we are not breaking the proper sequence
> > > lets to updates
On Mon, Mar 25, 2024 at 04:45:49PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 01:23:26PM +0200, Stanislav Lisovskiy wrote:
> > According to BSpec we need to do correspondent MBUS updates before
> > or after DBUF reallocation, depending on whether we are enabling
> > or disabling mbus
On Mon, Mar 25, 2024 at 04:30:14PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 01:23:27PM +0200, Stanislav Lisovskiy wrote:
> > In order to make sure we are not breaking the proper sequence
> > lets to updates step by step and don't change MBUS join value
> > during MDCLK/CDCLK
On Mon, Mar 25, 2024 at 05:33:42PM +0100, Borislav Petkov wrote:
> On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> > Let's see what Ville says, but in the end bisection might be the
> > quickest way to find the regression. Though I understand it can be
> > tedious for you
On Tue, Feb 27, 2024 at 12:58:08PM +0200, Jani Nikula wrote:
> Let's see what Ville says, but in the end bisection might be the
> quickest way to find the regression. Though I understand it can be
> tedious for you personally.
That still fires with 6.-9-rc1. Does Ville have any suggestions or
On Mon, Mar 25, 2024 at 04:11:27PM +, Govindapillai, Vinod wrote:
> Hi Ville,
>
> On Mon, 2024-03-25 at 17:03 +0200, Ville Syrjälä wrote:
> > On Mon, Mar 25, 2024 at 03:01:56PM +0200, Vinod Govindapillai wrote:
> > > From: Stanislav Lisovskiy
> > >
> > > There could be multiple qgv and psf
Hi Ville,
On Mon, 2024-03-25 at 17:03 +0200, Ville Syrjälä wrote:
> On Mon, Mar 25, 2024 at 03:01:56PM +0200, Vinod Govindapillai wrote:
> > From: Stanislav Lisovskiy
> >
> > There could be multiple qgv and psf gv points with similar values
> > In case if we need to set one such QGV or psf gv
== Series Details ==
Series: QGV/SAGV related fixes (rev8)
URL : https://patchwork.freedesktop.org/series/126962/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14478 -> Patchwork_126962v8
Summary
---
**FAILURE**
== Series Details ==
Series: QGV/SAGV related fixes (rev8)
URL : https://patchwork.freedesktop.org/series/126962/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1:
== Series Details ==
Series: QGV/SAGV related fixes (rev8)
URL : https://patchwork.freedesktop.org/series/126962/
State : warning
== Summary ==
Error: dim checkpatch failed
c4243da90814 drm/i915: Add meaningful traces for QGV point info error handling
3418442208ab drm/i915: Extract code
== Series Details ==
Series: Enable fastset for mbus_join state change (rev4)
URL : https://patchwork.freedesktop.org/series/130480/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14478 -> Patchwork_130480v4
Summary
---
On Fri, 22 Mar 2024, Ankit Nautiyal wrote:
> Currently we probe for lspcon, inside lspcon init. Which does 2 things:
> probe the lspcon and set the expected LS/PCON mode.
>
> If there is no lspcon connected, the probe expectedly fails and
> results in error message. This inturn gets propogated to
On Fri, 22 Mar 2024, Ankit Nautiyal wrote:
> LSPCON can be configured to LS or PCON mode.
> Separate the function to set the expected mode from the lspcon probe
> function during lspcon init.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 47
== Series Details ==
Series: drm/ttm: remove unused paramter
URL : https://patchwork.freedesktop.org/series/131576/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/131576/revisions/1/mbox/ not
applied
Applying: drm/ttm: remove unused paramter
On Mon, 25 Mar 2024, Lucas De Marchi wrote:
> drivers/gpu/drm/i915/gt/intel_workarounds.c.rej was incorrectly added to
> the tree after solving a conflict. Remove it.
>
> Fixes: 326e30e4624c ("drm/i915: Drop dead code for pvc")
> Reported-by: Stephen Rothwell
> Closes:
== Series Details ==
Series: Enable fastset for mbus_join state change (rev4)
URL : https://patchwork.freedesktop.org/series/130480/
State : warning
== Summary ==
Error: dim checkpatch failed
bfc7f71c18ac drm/i915: Update mbus in intel_dbuf_mbus_update and do it properly
-:12:
On Mon, Mar 25, 2024 at 03:01:56PM +0200, Vinod Govindapillai wrote:
> From: Stanislav Lisovskiy
>
> There could be multiple qgv and psf gv points with similar values
> In case if we need to set one such QGV or psf gv point where there
> could be duplicate entries, we would have to select all
On Mon, Mar 25, 2024 at 11:44:59AM -0300, Gustavo Sousa wrote:
> Quoting Ville Syrjälä (2024-03-22 14:45:29-03:00)
> >On Fri, Mar 22, 2024 at 01:40:44PM +0200, Stanislav Lisovskiy wrote:
> >> In order to make sure we are not breaking the proper sequence
> >> lets to updates step by step and don't
drivers/gpu/drm/i915/gt/intel_workarounds.c.rej was incorrectly added to
the tree after solving a conflict. Remove it.
Fixes: 326e30e4624c ("drm/i915: Drop dead code for pvc")
Reported-by: Stephen Rothwell
Closes: https://lore.kernel.org/r/20240325083435.4f970...@canb.auug.org.au
Cc: Jani Nikula
Quoting Ville Syrjälä (2024-03-22 14:45:29-03:00)
>On Fri, Mar 22, 2024 at 01:40:44PM +0200, Stanislav Lisovskiy wrote:
>> In order to make sure we are not breaking the proper sequence
>> lets to updates step by step and don't change MBUS join value
>> during MDCLK/CDCLK programming stage.
>> MBUS
On Mon, Mar 25, 2024 at 01:23:26PM +0200, Stanislav Lisovskiy wrote:
> According to BSpec we need to do correspondent MBUS updates before
> or after DBUF reallocation, depending on whether we are enabling
> or disabling mbus joining(typical scenario is swithing between
> multiple and single
== Series Details ==
Series: drm/i915: limit eDP MSO pipe only for display version 20 and below
(rev2)
URL : https://patchwork.freedesktop.org/series/129123/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14478 -> Patchwork_129123v2
On Mon, Mar 25, 2024 at 01:23:27PM +0200, Stanislav Lisovskiy wrote:
> In order to make sure we are not breaking the proper sequence
> lets to updates step by step and don't change MBUS join value
> during MDCLK/CDCLK programming stage.
> MBUS join programming would be taken care by pre/post ddb
Hi,
On Sat, Mar 23, 2024 at 10:15 AM kernel test robot wrote:
>
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 657dd8fcd2f1d1205c6f98fdb8b60915228991d1
> commit: 0885186926a13c697d78f5af03f32445414b6ad5 [4/11] Merge remote-tracking
> branch 'drm-misc/drm-misc-next' into
To enable partial memory mapping of GPU virtual memory, it's
necessary to introduce an offset to the object's memory
(obj->mm.pages) scatterlist. This adjustment compensates for
instances when userspace mappings do not start from the beginning
of the object.
Based on a patch by Chris Wilson
.
On Mon, 25 Mar 2024, Lucas De Marchi wrote:
> On Mon, Mar 25, 2024 at 11:56:51AM +0200, Jani Nikula wrote:
>>On Tue, 19 Mar 2024, Lucas De Marchi wrote:
>>> .../gpu/drm/i915/gt/intel_workarounds.c.rej | 18 +
>>> create mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
>>
>>Whoops.
On Mon, Mar 25, 2024 at 11:56:51AM +0200, Jani Nikula wrote:
On Tue, 19 Mar 2024, Lucas De Marchi wrote:
.../gpu/drm/i915/gt/intel_workarounds.c.rej | 18 +
create mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
Whoops. [1]
argh... sorry about that. Should I just amend the
From: Stanislav Lisovskiy
There could be multiple qgv and psf gv points with similar values
In case if we need to set one such QGV or psf gv point where there
could be duplicate entries, we would have to select all those
points. Otherwise pcode might reject the GV configuration. We do
handle
From: Stanislav Lisovskiy
Problem is that on some platforms, we do get QGV point mask in wrong
state on boot. However driver assumes it is set to 0
(i.e all points allowed), however in reality we might get them all
restricted, causing issues.
Lets disable SAGV initially to force proper QGV point
From: Stanislav Lisovskiy
We need that in order to force disable SAGV in next patch.
Also it is beneficial to separate that code, as in majority cases,
when SAGV is enabled, we don't even need those calculations.
Also we probably need to determine max PSF GV point as well, however
currently we
From: Stanislav Lisovskiy
For debug purposes we need those - error path won't flood the log,
however there has been already numerous cases, when due to lack
of debugs, we couldn't immediately tell what was the problem on
customer machine, which slowed down the investigation, requiring
to get
We have couple of customer issues, related to SAGV/QGV point
calculation. Those patches contain fixes plus some additional
debugs for those issues.
Stanislav Lisovskiy (4):
drm/i915: Add meaningful traces for QGV point info error handling
drm/i915: Extract code required to calculate max
remove the unsed the paramter in the function
ttm_bo_bounce_temp_buffer and ttm_bo_add_move_fence.
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
Hi, I want to confirm the status of this patch and whether need any
additional information.
Currently we can't change MBUS join status without doing a modeset,
because we are lacking mechanism to synchronize those with vblank.
However then this means that we can't do a fastset, if there is a need
to change MBUS join state. Fix that by implementing such change.
We already call
We need to loop through all active pipes, not just the ones, that
are in current state, because disabling and enabling even a particular
pipe affects credits in another one.
Reviewed-by: Ville Syrjälä
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/skl_watermark.c | 7
In order to make sure we are not breaking the proper sequence
lets to updates step by step and don't change MBUS join value
during MDCLK/CDCLK programming stage.
MBUS join programming would be taken care by pre/post ddb hooks.
v2: - Reworded comment about using old mbus_join value in
According to BSpec we need to do correspondent MBUS updates before
or after DBUF reallocation, depending on whether we are enabling
or disabling mbus joining(typical scenario is swithing between
multiple and single displays).
Also we need to be able to update dbuf min tracker and mdclk ratio
Currently fastset is not supported, if mbus join state changes,
so whenever we have to switch mbus state, we have to force a full
modeset. This patch series makes fastset possible from MBUS state
point of view.
Stanislav Lisovskiy (4):
drm/i915: Update mbus in intel_dbuf_mbus_update and do it
The pipes that can be used for eDP MSO are limited to pipe A (and
sometimes also pipe B) only for display version 20 and below.
Modify the function that returns the pipe mask for eDP MSO so that
these limitations only apply to version 20 and below, enabling all
pipes otherwise.
Bspec: 68923
Cc:
On Tue, 19 Mar 2024, Ville Syrjälä wrote:
> On Tue, Mar 19, 2024 at 11:29:14AM +0200, Jani Nikula wrote:
>> On Tue, 19 Mar 2024, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > If we have no VBT, or the VBT didn't declare the encoder
>> > in question, we won't have the 'devdata' for the
On Fri, 22 Mar 2024, Ville Syrjälä wrote:
> On Fri, Mar 22, 2024 at 07:54:03PM +0100, Janusz Krzysztofik wrote:
>> Hwmon is registered as a managed resource of i915. Its functionality
>> depends of availability of i915 uncore.
>
> Instead of polluting all code with this junk I think
> either
On Tue, 19 Mar 2024, Lucas De Marchi wrote:
> .../gpu/drm/i915/gt/intel_workarounds.c.rej | 18 +
> create mode 100644 drivers/gpu/drm/i915/gt/intel_workarounds.c.rej
Whoops. [1]
BR,
Jani.
[1] https://lore.kernel.org/r/20240325083435.4f970...@canb.auug.org.au
--
Jani Nikula, Intel
Currently we can't change MBUS join status without doing a modeset,
because we are lacking mechanism to synchronize those with vblank.
However then this means that we can't do a fastset, if there is a need
to change MBUS join state. Fix that by implementing such change.
We already call
On Fri, Mar 22, 2024 at 08:06:46PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 22, 2024 at 01:40:46PM +0200, Stanislav Lisovskiy wrote:
> > Currently we can't change MBUS join status without doing a modeset,
> > because we are lacking mechanism to synchronize those with vblank.
> > However then this
Thank you Stan. Rev 14 works.
Tested-by: Vidya Srinivas
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Wednesday, March 20, 2024 8:45 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lisovskiy, Stanislav ; Saarinen, Jani
> ; ville.syrj...@linux.intel.com; Srinivas, Vidya
>
>
75 matches
Mail list logo
