+ @Grabski, Mateusz please check it
Thanks,
Ewelina
-Original Message-
From: Jani Nikula
Sent: Thursday, April 18, 2024 6:41 PM
To: Patchwork ; Ville Syrjala
; LGCI Bug Filing
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: ✓ Fi.CI.BAT: success for drm/i915: BXT/GLK per-lane vswing
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 20, 2024 9:34 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 2/6] drm/i915: Reject async flips if we need to change
> DDB/watermarks
>
> From: Ville Syrjälä
>
> DDB/watermarks are
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 20, 2024 9:34 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 1/6] drm/i915: Align PLANE_SURF to 16k on ADL for async flips
>
> From: Ville Syrjälä
>
> On ADL async flips apparently
== Series Details ==
Series: drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref
(rev3)
URL : https://patchwork.freedesktop.org/series/132625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14609 -> Patchwork_132625v3
On Thu, 18 Apr 2024 14:56:58 -0700, Andi Shyti wrote:
>
> > v2: Change commit message and other minor code changes
> > v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
> > v4: Eliminate potential static analyzer warning (Rodrigo)
> > Eliminate fetch_and_zero (Jani)
> > v5: Restore
On Thu, 18 Apr 2024 15:57:49 -0700, Patchwork wrote:
>
> Project List - Patchwork
>
> Patch Details
>
> Series: drm/i915/hwmon: Get rid of devm (rev6)
> URL: https://patchwork.freedesktop.org/series/132400/
> State: failure
> Details:
>
On Thu, Apr 18, 2024 at 06:37:56PM -0400, Rodrigo Vivi wrote:
> In the past, the noresume function was used by the GEM code to ensure
> wakelocks were held and bump its usage. This is no longer the case
> and this function was totally unused until it started to be used again
> by display with
On 4/18/2024 10:10, Nirmoy Das wrote:
Currently intel_gt_reset() happens as follows:
reset_prepare() ---> Sends GDRST to GuC, GuC is in GS_MIA_IN_RESET
do_reset()
intel_gt_reset_all_engines()
*_engine_reset_prepare() -->RESET_CTL expects running GuC
Not technically correct. There is no
== Series Details ==
Series: drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref
(rev2)
URL : https://patchwork.freedesktop.org/series/132625/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14607 -> Patchwork_132625v2
On 4/18/2024 10:10, Nirmoy Das wrote:
intel_engine_reset() not only reset a engine but also
tries to recover it so give it a proper name without
any functional changes.
Not seeing what the difference is. If this was a super low level
function (with an __ prefix for example) then one might
On 4/18/2024 10:10, Nirmoy Das wrote:
__intel_gt_reset() is really for resetting engines though
the name might suggest something else. So add two helper functions
to remove confusions with no functional changes.
Technically you only added one and just moved the other :). It already
existed, it
== Series Details ==
Series: drm/i915: Convert intel_runtime_pm_get_noresume towards raw wakeref
URL : https://patchwork.freedesktop.org/series/132625/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14607 -> Patchwork_132625v1
In the past, the noresume function was used by the GEM code to ensure
wakelocks were held and bump its usage. This is no longer the case
and this function was totally unused until it started to be used again
by display with commit 77e619a82fc3 ("drm/i915/display: convert inner
wakeref get towards
On Fri, Apr 19, 2024 at 01:30:21AM +0300, Imre Deak wrote:
> On Thu, Apr 18, 2024 at 06:13:20PM -0400, Rodrigo Vivi wrote:
> > In the past, the noresume function was used by the GEM code to ensure
> > wakelocks were held and bump its usage. This is no longer the case
> > and this function was
On Thu, Apr 18, 2024 at 06:13:20PM -0400, Rodrigo Vivi wrote:
> In the past, the noresume function was used by the GEM code to ensure
> wakelocks were held and bump its usage. This is no longer the case
> and this function was totally unused until it started to be used again
> by display with
In the past, the noresume function was used by the GEM code to ensure
wakelocks were held and bump its usage. This is no longer the case
and this function was totally unused until it started to be used again
by display with commit 77e619a82fc3 ("drm/i915/display: convert inner
wakeref get towards
Hi Ashutosh,
On Wed, Apr 17, 2024 at 07:56:46AM -0700, Ashutosh Dixit wrote:
> When both hwmon and hwmon drvdata (on which hwmon depends) are device
> managed resources, the expectation, on device unbind, is that hwmon will be
> released before drvdata. However, in i915 there are two separate
== Series Details ==
Series: series starting with [1/3] drm/i915: Refactor confusing
__intel_gt_reset() (rev2)
URL : https://patchwork.freedesktop.org/series/132616/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14607 -> Patchwork_132616v2
== Series Details ==
Series: series starting with [1/3] drm/i915: Refactor confusing
__intel_gt_reset() (rev2)
URL : https://patchwork.freedesktop.org/series/132616/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
On Thu, Apr 18, 2024 at 05:44:13PM GMT, Gustavo Sousa wrote:
Quoting Jani Nikula (2024-04-18 17:09:04-03:00)
On Thu, 18 Apr 2024, Gustavo Sousa wrote:
Quoting Jani Nikula (2024-04-18 11:39:53-03:00)
The distinction between the dmc_firmware_path module param being NULL
and the empty string ""
Quoting Jani Nikula (2024-04-18 17:09:04-03:00)
>On Thu, 18 Apr 2024, Gustavo Sousa wrote:
>> Quoting Jani Nikula (2024-04-18 11:39:53-03:00)
>>>The distinction between the dmc_firmware_path module param being NULL
>>>and the empty string "" is problematic. It's not possible to set the
Quoting Jani Nikula (2024-04-18 17:03:22-03:00)
>On Thu, 18 Apr 2024, Gustavo Sousa wrote:
>> Quoting Jani Nikula (2024-04-18 11:39:51-03:00)
>>>Return failures from parse_dmc_fw() instead of relying on
>>>intel_dmc_has_payload(). Handle and error report them slightly better.
>>>
== Series Details ==
Series: series starting with [1/3] drm/i915: Refactor confusing
__intel_gt_reset()
URL : https://patchwork.freedesktop.org/series/132616/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14606 -> Patchwork_132616v1
On Thu, 18 Apr 2024, Gustavo Sousa wrote:
> Quoting Jani Nikula (2024-04-18 11:39:53-03:00)
>>The distinction between the dmc_firmware_path module param being NULL
>>and the empty string "" is problematic. It's not possible to set the
>>parameter back to NULL via sysfs or debugfs. Remove the
== Series Details ==
Series: series starting with [1/3] drm/i915: Refactor confusing
__intel_gt_reset()
URL : https://patchwork.freedesktop.org/series/132616/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
On Thu, 18 Apr 2024, Gustavo Sousa wrote:
> Quoting Jani Nikula (2024-04-18 11:39:51-03:00)
>>Return failures from parse_dmc_fw() instead of relying on
>>intel_dmc_has_payload(). Handle and error report them slightly better.
>>
>>Signed-off-by: Jani Nikula
>>---
>>
Quoting Jani Nikula (2024-04-18 16:56:06-03:00)
>On Thu, 18 Apr 2024, Gustavo Sousa wrote:
>> Quoting Jani Nikula (2024-04-18 11:39:50-03:00)
>>>Clarify request_firmware() error handling. Don't proceed to trying to
>>>parse non-existent firmware or check for payload when request_firmware()
On Thu, 18 Apr 2024, Gustavo Sousa wrote:
> Quoting Jani Nikula (2024-04-18 11:39:50-03:00)
>>Clarify request_firmware() error handling. Don't proceed to trying to
>>parse non-existent firmware or check for payload when request_firmware()
>>failed to begin with. There's no reason to
On 2024-03-07 01:29, Wayne Lin wrote:
> [Why]
> Commit:
> - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> allocation/removement")
> accidently overwrite the commit
> - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
> drm_dp_add_payload_part2")
> which cause
Quoting Jani Nikula (2024-04-18 11:39:54-03:00)
>The dmc_firmware_path parameter is clearly a display parameter. Move it
>there so it's available to both i915 and xe modules. This also cleans up
>the ugly member in struct xe_device.
>
>v2:
>- New try with the NULL/"" param value issue resolved
>
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7b4f2bc91c15fdcf948bb2d9741a9d7d54303f8d Add linux-next specific
files for 20240418
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404190103.llm8ltup-...@intel.com
Error
Quoting Jani Nikula (2024-04-18 11:39:53-03:00)
>The distinction between the dmc_firmware_path module param being NULL
>and the empty string "" is problematic. It's not possible to set the
>parameter back to NULL via sysfs or debugfs. Remove the distinction, and
>consider NULL and the empty string
Quoting Jani Nikula (2024-04-18 11:39:52-03:00)
>The big if ladder clutters intel_dmc_init(). Split it out to a separate
>function.
>
>Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
>---
> drivers/gpu/drm/i915/display/intel_dmc.c | 96 +---
> 1 file changed, 54
Quoting Jani Nikula (2024-04-18 11:39:51-03:00)
>Return failures from parse_dmc_fw() instead of relying on
>intel_dmc_has_payload(). Handle and error report them slightly better.
>
>Signed-off-by: Jani Nikula
>---
> drivers/gpu/drm/i915/display/intel_dmc.c | 39 +---
> 1 file
Quoting Jani Nikula (2024-04-18 11:39:50-03:00)
>Clarify request_firmware() error handling. Don't proceed to trying to
>parse non-existent firmware or check for payload when request_firmware()
>failed to begin with. There's no reason to release_firmware() either
>when request_firmware() failed.
>
On Wed, 17 Apr 2024, Rodrigo Vivi wrote:
> On Wed, Apr 17, 2024 at 04:02:47PM +0300, Jani Nikula wrote:
>> Now that the intel_de_ functions and DISPLAY_VER() accept struct
>> intel_display *, use it more.
>>
>> Cc: Luca Coelho
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Rodrigo Vivi
== Series Details ==
Series: drm/xe: More fb pinning optimizations.
URL : https://patchwork.freedesktop.org/series/132615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14604 -> Patchwork_132615v1
Summary
---
== Series Details ==
Series: drm/xe: More fb pinning optimizations.
URL : https://patchwork.freedesktop.org/series/132615/
State : warning
== Summary ==
Error: dim checkpatch failed
71d8eed226c3 drm/xe/display: Preparations for preallocating dpt bo
56694e3c79b6 drm/xe: Use simple xchg to
Currently intel_gt_reset() happens as follows:
reset_prepare() ---> Sends GDRST to GuC, GuC is in GS_MIA_IN_RESET
do_reset()
intel_gt_reset_all_engines()
*_engine_reset_prepare() -->RESET_CTL expects running GuC
*_reset_engines()
intel_gt_init_hw() --> GuC comes out of GS_MIA_IN_RESET
intel_engine_reset() not only reset a engine but also
tries to recover it so give it a proper name without
any functional changes.
Signed-off-by: Nirmoy Das
---
.../drm/i915/gem/selftests/i915_gem_context.c | 2 +-
.../drm/i915/gt/intel_execlists_submission.c | 2 +-
__intel_gt_reset() is really for resetting engines though
the name might suggest something else. So add two helper functions
to remove confusions with no functional changes.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
Instead of overwriting the original GGTT mapping accidentally, allocate
a new GGTT mapping above the original GGTT mapping.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/display/xe_fb_pin.c| 40 ---
drivers/gpu/drm/xe/display/xe_fb_pin.h| 20 ++
i915 has this really nice, infrastructure where everything becomes
complicated, GGTT needs eviction, etc..
Lets not do that, and make the dumbest possible interface instead.
Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel
fb.
Signed-off-by: Maarten Lankhorst
---
This reduces the latency of pinning framebuffers by
re-using the previous mapping, if available.
Additionally, DPT is preallocated when creating the FB, instead
of performing a bo allocation on every pin.
Maarten Lankhorst (5):
drm/xe/display: Preparations for preallocating dpt bo
drm/xe:
The DPT bo should not be allocated when pinning, but in advance when
creating the framebuffer. Split allocation from bo pinning and GGTT
insertion.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 159 +++--
1 file changed, 123 insertions(+), 36
This is invalid with display code when reworking DPT.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
index
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 33 +++---
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c
b/drivers/gpu/drm/xe/display/xe_fb_pin.c
index d967d00bbf9d..16a287cbebc5 100644
== Series Details ==
Series: drm/i915/gt: Refactor uabi engine class/instance list creation (rev2)
URL : https://patchwork.freedesktop.org/series/132521/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14603 -> Patchwork_132521v2
On Wed, 17 Apr 2024, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: BXT/GLK per-lane vswing and PHY reg cleanup (rev3)
> URL : https://patchwork.freedesktop.org/series/132390/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_14597 -> Patchwork_132390v3
>
== Series Details ==
Series: drm/i915/gt: Refactor uabi engine class/instance list creation (rev2)
URL : https://patchwork.freedesktop.org/series/132521/
State : warning
== Summary ==
Error: dim checkpatch failed
bf5601a7ea21 drm/i915/gt: Refactor uabi engine class/instance list creation
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, March 20, 2024 9:34 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH 3/6] drm/i915: Allow the initial async flip to change modifier
>
> From: Ville Syrjälä
>
> With Xorg+modesetting on skl+
== Series Details ==
Series: drm/i915/dmc: firmware path handling changes
URL : https://patchwork.freedesktop.org/series/132609/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14603 -> Patchwork_132609v1
Summary
---
== Series Details ==
Series: drm/i915/dmc: firmware path handling changes
URL : https://patchwork.freedesktop.org/series/132609/
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/dmc: firmware path handling changes
URL : https://patchwork.freedesktop.org/series/132609/
State : warning
== Summary ==
Error: dim checkpatch failed
11a5475a5872 drm/i915/dmc: handle request_firmware() errors separately
2a996e8e9e0b drm/i915/dmc: improve
Hi Dave and Sima,
Please pull the drm-xe-fixes for this week targeting v6.9-rc5.
thanks
Lucas De Marchi
drm-xe-fixes-2024-04-18:
- Fix bo leak on error path during fb init
- Fix use-after-free due to order vm is put and destroyed
The following changes since commit
On Thu, 18 Apr 2024, Robert Foss wrote:
> I'm seeing build errors for drivers/gpu/drm/bridge/ite-it6505.c, is
> this expected?
No, but it's possible my configs didn't catch all configs. :(
BR,
Jani.
--
Jani Nikula, Intel
On Thu, 18 Apr 2024, Chaitanya Kumar Borah
wrote:
> Intel hardware is capable of programming the Maud/Naud SDPs on its
> own based on real-time clocks. While doing so, it takes care
> of any deviations from the theoretical values. Programming the registers
> explicitly with static values can
The dmc_firmware_path parameter is clearly a display parameter. Move it
there so it's available to both i915 and xe modules. This also cleans up
the ugly member in struct xe_device.
v2:
- New try with the NULL/"" param value issue resolved
Link:
The distinction between the dmc_firmware_path module param being NULL
and the empty string "" is problematic. It's not possible to set the
parameter back to NULL via sysfs or debugfs. Remove the distinction, and
consider NULL and the empty string to be the same thing, and use the
platform default
The big if ladder clutters intel_dmc_init(). Split it out to a separate
function.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 96 +---
1 file changed, 54 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
Return failures from parse_dmc_fw() instead of relying on
intel_dmc_has_payload(). Handle and error report them slightly better.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 39 +---
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git
Clarify request_firmware() error handling. Don't proceed to trying to
parse non-existent firmware or check for payload when request_firmware()
failed to begin with. There's no reason to release_firmware() either
when request_firmware() failed.
Also move the message about DMC firmware homepage
We tried moving the dmc_firmware_path param from i915 to display params
before, so it would be present in xe as well as i915. This was commit
0d82a0d6f556 ("drm/i915/display: move dmc_firmware_path to display
params"). That failed, so I tried a quick fix, but that failed too
[1]. Revert followed
== Series Details ==
Series: drm/i915/audio: Fix audio time stamp programming for DP
URL : https://patchwork.freedesktop.org/series/132602/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14602 -> Patchwork_132602v1
Summary
Intel hardware is capable of programming the Maud/Naud SDPs on its
own based on real-time clocks. While doing so, it takes care
of any deviations from the theoretical values. Programming the registers
explicitly with static values can interfere with this logic. Therefore,
let the HW decide the
Hey Jani,
Thanks for doing this cleanup.
On Thu, Apr 18, 2024 at 12:13 PM Jani Nikula wrote:
>
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v2: Also fix ivpu and vmwgfx
>
> Reviewed-by: Andrzej Hajda
> Acked-by: Maxime Ripard
> Link:
>
On Thu, 04 Apr 2024, Luca Coelho wrote:
> 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
On 18/04/2024 10:49, Jani Nikula wrote:
On Wed, 17 Apr 2024, Lucas De Marchi wrote:
On Mon, Apr 08, 2024 at 03:54:44PM GMT, Jani Nikula wrote:
The raw register reads/writes are there as micro-optimizations to avoid
multiple pointer indirections on uncore->regs. Presumably this is useful
On Tue, Apr 09, 2024 at 06:02:49PM +0300, Dmitry Baryshkov wrote:
> On Mon, Apr 08, 2024 at 10:06:07PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier by providing a function that hands
> > out the the correct drm_vblank_crtc for a given a drm_crtc.
> >
> > Also
Surprisingly many places depend on debugfs.h to be included via
drm_print.h. Fix them.
v2: Also fix ivpu and vmwgfx
Reviewed-by: Andrzej Hajda
Acked-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908-1-jani.nik...@intel.com
Signed-off-by: Jani Nikula
On Wed, 17 Apr 2024, Lucas De Marchi wrote:
> On Mon, Apr 08, 2024 at 03:54:44PM GMT, Jani Nikula wrote:
>>The raw register reads/writes are there as micro-optimizations to avoid
>>multiple pointer indirections on uncore->regs. Presumably this is useful
>>when there are plenty of register
Hi Dave, Sima,
this is the PR for drm-misc-fixes for this week.
Best regards
Thomas
drm-misc-fixes-2024-04-18:
Short summary of fixes pull:
nouveau:
- dp: Don't probe DP ports twice
- nv04: Fix OOB access
- nv50: Disable AUX bus for disconnected DP ports
- nvkm: Fix race condition
panel:
-
Hi all,
After merging the drm-intel tree, today's linux-next build (htmldocs)
produced this warning:
drivers/gpu/drm/i915/display/intel_dmc_wl.c:1: warning: no structured comments
found
Introduced by commit
765425f598c2 ("drm/i915/display: add support for DMC wakelocks")
--
Cheers,
73 matches
Mail list logo
