On Fri, Feb 23, 2024 at 09:47:11AM -0800, Abhinav Kumar wrote:
> CC Dmitry
>
> Hi Rodrigo
>
> On 2/23/2024 9:00 AM, Rodrigo Vivi wrote:
> > On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> > > With the x86_64_defconfig I see the followi
On Fri, Feb 23, 2024 at 10:31:41AM -0800, Belgaumkar, Vinay wrote:
>
> On 2/23/2024 12:51 AM, Tvrtko Ursulin wrote:
> >
> > On 22/02/2024 23:31, Belgaumkar, Vinay wrote:
> > >
> > > On 2/22/2024 7:32 AM, Tvrtko Ursulin wrote:
> > > >
On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> With the x86_64_defconfig I see the following when building drm-misc-next:
>
> CC drivers/gpu/drm/i915/display/intel_crt.o
> CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
> CC
ar...@intel.com/
> Signed-off-by: Cezary Rojewski
Reviewed-by: Rodrigo Vivi
> ---
> sound/hda/hdac_i915.c | 32 +---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index 36
to move from the debug helpers to the printf... we need
to keep coming back to where the printer was defined to
know what level we are printing...
well, since the printer is already there, well, let's
use
Reviewed-by: Rodrigo Vivi
but with some bad gut feeling about the whole change...
>
On Thu, Feb 15, 2024 at 06:40:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Utilize drm_printer in pipe_config_pll_mismatch() to avoid
> a bit of code duplication.
>
> To achieve this we need to plumb the printer all way to the
> dpll_mgr .dump_hw_state() functions. Those are also
the DRM_UT_KMS check and special handling for
> the loglevel. But at least we end up with a bit less copy-pasta.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 37 ++--
> 1 file changed, 19 inserti
re out which loglevel to use. And we do need to keep
> the explicit drm_debug_enabled(DRM_UT_KMS) since hdmi_infoframe_log()
> won't do it for us.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 32 +++---
_config->infoframes.name)) { \
> - pipe_config_dp_vsc_sdp_mismatch(dev_priv, fastset,
> __stringify(name), \
> + pipe_config_dp_vsc_sdp_mismatch(fastset, crtc,
> __stringify(name), \
ditto
anyway
Reviewed-by: Rodrigo Vivi
>
> _config->infoframes.name, \
> _config->infoframes.name);
> \
> ret = false; \
> --
> 2.43.0
>
,
> -bool fastset, const char *name,
> +pipe_config_infoframe_mismatch(bool fastset, const struct intel_crtc *crtc,
why not crtc, fastset? having the main struct as the first
argument seems more natural imho
anyway,
Reviewed-by: Rodrigo Vivi
> +con
tc->base.name);
looking to other patches in this same series, I wonder
if we shouldn't benefit of a crct_dbg(crtc, "message") that would print
[CRTC:%d:%s] underneath.
But anyway,
Reviewed-by: Rodrigo Vivi
> else
> new_crtc_state->uapi.mode_changed = false;
>
> --
> 2.43.0
>
On Thu, Feb 22, 2024 at 02:56:33PM +0200, Vinod Govindapillai wrote:
> From: Balasubramani Vivekanandan
>
> Load DMC for XE2LPD. The value 0x8000 is the maximum payload size for
> any xe2lpd dmc firmware.
>
> Signed-off-by: Balasubramani Vivekanandan
>
> Signed-off-by: Dnyaneshwar Bhadane
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594
>
> v2:
> * Fix whitespace alignment as per checkpatch.
> * Added warning on userspace misuse.
> * Rebase for extracting ce->default_state shadowing.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Lionel La
n
> Cc: Carlos Santa
> Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++
> drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ---
> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 7 ---
> 3 fi
On Thu, Feb 22, 2024 at 06:53:12PM +0100, Cezary Rojewski wrote:
> On 2024-02-22 6:24 PM, Ville Syrjälä wrote:
> > On Thu, Feb 22, 2024 at 06:06:11PM +0100, Cezary Rojewski wrote:
> > > Commit 78f613ba1efb ("drm/i915: finish removal of CNL") and its friends
> > > removed support for i915 for all
v Kumar
it looks indeed an unecessary check.
you can convert my ack to a
Reviewed-by: Rodrigo Vivi
and the ack to take this through drm-misc if needed
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
> include/drm/d
-by: Abhinav Kumar
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
Acked-by: Rodrigo Vivi
> include/drm/display/drm_dp_helper.h | 3 +--
> 3 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drive
lanning on changing the
> given effected events.
since it is not breaking builds on our side and the conflicts, if any, would
be minimal, feel free to take this trough your tree
Acked-by: Rodrigo Vivi
>
> -- Steve
r solution was to use .drirc and make
per-application
decision.
I would prefer a high level extension for a more granular and informative
decision. We need to work with that goal, but for now I don't see any
cons on this approach.
>
> > Cc: Rodrigo Vivi
> > Signed-off-by: Vina
On Wed, Feb 21, 2024 at 08:19:35PM +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Tuesday, February 20, 2024 11:12 PM
> > To: Manna, Animesh
> > Cc: intel-gfx@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> > Hogander,
> > Jouni ;
the empty lines (Gustavo)
Closes: https://lore.kernel.org/all/20240219161747.0e867...@canb.auug.org.au/
Fixes: 79e2ea2eaaa6 ("drm/i915/cdclk: Document CDCLK update methods")
Cc: Ville Syrjälä
Cc: Gustavo Sousa
Reported-by: Stephen Rothwell
Signed-off-by: Rodrigo Vivi
Reviewed-by: Gus
ve to say that this approach is nice, clean and well protected.
And much simpler then I imagined when I saw the idea around.
Feel free to use:
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Lionel Landwerlin
> Cc: Carlos Santa
> ---
> drive
: https://lore.kernel.org/all/20240219161747.0e867...@canb.auug.org.au/
Fixes: 79e2ea2eaaa6 ("drm/i915/cdclk: Document CDCLK update methods")
Cc: Ville Syrjälä
Cc: Gustavo Sousa
Reported-by: Stephen Rothwell
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 6
On Tue, Feb 20, 2024 at 11:52:04AM -0800, John Harrison wrote:
> On 2/19/2024 12:28, Rodrigo Vivi wrote:
> > On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > The above w/a is required for
gt; Thanks,
> Zhi.
>
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: Jani Nikula
> > > Cc: Joonas Lahtinen
> > > Cc: Rodrigo Vivi
> > > Cc: Tvrtko Ursulin
>
On Tue, Feb 20, 2024 at 08:06:01PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 12:57:06PM -0500, Rodrigo Vivi wrote:
> > On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > >
On Tue, Feb 20, 2024 at 07:52:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 02:12:51PM +0100, Maxime Ripard wrote:
> > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > to update all the users of the struct drm_tv_connector_state mode field,
> > which
ommit.
>
> Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> Reported-by: Ville Syrjälä
> Signed-off-by: Maxime Ripard
Reviewed-by: Rodrigo Vivi
and pushing to drm-intel-next soon...
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 10
On Tue, Feb 20, 2024 at 07:49:19PM +0530, Animesh Manna wrote:
> Panel Replay VSC SDP not getting sent when VRR is enabled
> and W1 and W2 are 0. So Program Set Context Latency in
> TRANS_SET_CONTEXT_LATENCY register to at least a value of 1.
>
> HSD: 14015406119
Unnecessary mark since the
ps at least adding a comment in the code?
with that
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/inte
On Sun, Feb 18, 2024 at 07:12:24PM +0100, Bas S wrote:
>I ran into an issue with the i915 driver not being able to drive a display
>
>with this specific modeline:
>
Could you please file a bug on this?
that we need this protection. But...
I mean, feel free to use
Reviewed-by: Rodrigo Vivi
for this patch,
but I believe that if this mmu insert failed we might have other
deeper problems like when checking i915_gem_object_is_userptr() ?
No?!
> mmu_interval_notifier_remove(>userptr.notifier);
> obj->userptr.notifier.mm = NULL;
> }
> --
> 2.42.0
>
drm_debug_printer() to device
> specific drm_dbg_printer()")
> Reported-by: Dan Carpenter
> Cc: Jani Nikula
> Cc: Luca Coelho
> Cc: Maxime Ripard
> Cc: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
&g
On Wed, Feb 14, 2024 at 11:56:10AM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Feb 13, 2024 at 10:33:56AM -0500, Rodrigo Vivi wrote:
> > On Tue, Feb 13, 2024 at 05:21:26PM +0200, Lisovskiy, Stanislav wrote:
> > > On Tue, Feb 13, 2024 at 05:11:37PM +0200,
On Tue, Feb 13, 2024 at 05:21:26PM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Feb 13, 2024 at 05:11:37PM +0200, Shankar, Uma wrote:
> >
> >
> > > -Original Message-----
> > > From: Rodrigo Vivi
> > > Sent: Tuesday, February 13, 2024 8:26 PM
&
On Mon, Feb 12, 2024 at 06:20:11PM +0530, Uma Shankar wrote:
> From: Stanislav Lisovskiy
>
> For validation purposes, it might be useful to be able to
> force Bigjoiner mode, even if current dotclock/resolution
> do not require that.
> Lets add such to option to debugfs.
>
> v2: - Apparently
ent it and then reuse the same file
> (without the module name). If the interfaces are not identical, then we
> should differentiate them like is done here.
>
> +i915 maintainers
>
> Are you ok with merging this through either xe or i915 trees
> instead of splitting the patch? My p
:
> - case I915_FORMAT_MOD_X_TILED:
> - return true;
> - default:
> - return false;
> - }
> + return true;
we could also simply kill this function... the compiler does the right thing,
but users navigating on the code needs to do an extra ctag/cscope inspections
to
On Tue, Jan 23, 2024 at 11:51:15AM +0100, Janusz Krzysztofik wrote:
> Hi Rodrigo,
>
> Thank you for review.
>
> On Monday, 22 January 2024 22:09:38 CET Rodrigo Vivi wrote:
> > On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote:
> > > Object deb
On Mon, Jan 22, 2024 at 03:04:43PM +0100, Janusz Krzysztofik wrote:
> This reverts changes introduced by commit f56fe3e91787, obsoleted by
> "drm/i915/vma: Fix UAF on destroy against retire race".
I believe the good chunk of the first commit message should be moved
here instead.
But why did you
On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote:
> Object debugging tools were sporadically reporting illegal attempts to
> free a still active i915 VMA object when parking a GPU tile believed to be
> idle.
>
> [161.359441] ODEBUG: free active (active state 0) object:
wait_for_rc6(fd)
Which also anyway is using the residency directly.
Then, I'm also happy with the tests that really uses this like
the accuracy and rc6_disable.
So,
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Juan Escamilla
> ---
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c |
On Fri, Jan 12, 2024 at 07:31:51AM -0500, Hogander, Jouni wrote:
> On Wed, 2024-01-10 at 15:09 -0500, Rodrigo Vivi wrote:
> > On Tue, Jan 09, 2024 at 08:40:24PM +, Souza, Jose wrote:
> > > On Mon, 2024-01-08 at 17:18 -0500, Rodrigo Vivi wrote:
> > > > On Tue, Ja
more variables and conditions into
> consideration and thus these masks are not enough for most of the modern
> hardware and it is simpley lyting to the user.
>
> Let's fix it by at least use the rc6.supported flag from intel_gt
> information.
>
> Signed-off-by: Juan Es
On Tue, Jan 09, 2024 at 08:40:24PM +, Souza, Jose wrote:
> On Mon, 2024-01-08 at 17:18 -0500, Rodrigo Vivi wrote:
> > On Tue, Jan 02, 2024 at 09:44:48PM +0200, Jani Nikula wrote:
> > > On Tue, 02 Jan 2024, Juha-Pekka Heikkila
> > > wrote:
> > > > Aux c
On Thu, Jan 04, 2024 at 05:39:16PM +, Teres Alexis, Alan Previn wrote:
> On Thu, 2024-01-04 at 10:57 +, Patchwork wrote:
> > Patch Details
> > Series: Resolve suspend-resume racing with GuC destroy-context-worker
> > (rev13)
> > URL:https://patchwork.freedesktop.org/series/121916/
> >
On Tue, Jan 02, 2024 at 09:44:48PM +0200, Jani Nikula wrote:
> On Tue, 02 Jan 2024, Juha-Pekka Heikkila wrote:
> > Aux ccs framebuffers don't work on Xe driver hence disable them
> > from plane capabilities until they are fixed. Flat ccs framebuffers
> > work and they are left enabled. Here is
On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote:
> On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote:
> > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
> > > Add the xe repo to drm-tip and the dim tools.
> > > For now use the sh
On Wed, Jan 03, 2024 at 11:59:16PM -0600, Lucas De Marchi wrote:
> On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote:
> > On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote:
> > > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
> > > &
On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
> Add the xe repo to drm-tip and the dim tools.
> For now use the sha1 of the first drm-xe-next pull request for drm-tip,
> since that branch tip is currently adapted for our CI testing.
>
> Cc: Rodrigo Vivi
> C
5_perf_types.h:341: warning: Excess struct member 'head' description in
> 'i915_perf_stream'
> i915_perf_types.h:341: warning: Excess struct member 'tail' description in
> 'i915_perf_stream'
> 3 warnings as Errors
>
> Signed-off-by: Randy Dunlap
> Cc: Jani Nikula
> Cc:
part of a GuC
> > > sanitization (end of suspend) or a reset flow.
> > >
> > > Signed-off-by: Alan Previn
> > > Signed-off-by: Anshuman Gupta
> > > Tested-by: Mousumi Jana
> > > Acked-by: Daniele Ceraolo Spurio
> >
> > Thanks for
On Thu, Dec 21, 2023 at 12:54:14PM +0200, Jani Nikula wrote:
> Remove some unused declarations probably left behind after some
> refactoring.
when you mention 'unused' I was wondering if we should move the
local functions to 'static', but then I notice they are 'inexistent'.
Reviewed-by: R
On Mon, Dec 18, 2023 at 10:51:03AM -0800, Dixit, Ashutosh wrote:
> On Mon, 18 Dec 2023 06:57:14 -0800, Thomas Hellström wrote:
> >
> >
> > On 12/18/23 15:30, Rodrigo Vivi wrote:
> > > Ideally this header could be included without the CONFIG_FAULT_INJECTION
>
Hi Dave and Sima,
Here goes our latest drm-intel-next pull-request towards 6.8.
drm-intel-next-2023-12-18:
- Drop pointless null checks and fix a scaler bug (Ville)
- Meteor Lake display fixes and clean-ups (RK, Jani, Andrzej, Mika, Imre)
- Clean-up around flip done IRQ (Ville)
- Fix eDP Meteor
be us including the linux/types.h as well, but
this creates unnecessary cases.
Reference:
https://lore.kernel.org/all/20230816134748.979231-1-himal.prasad.ghimi...@intel.com/
Cc: Himal Prasad Ghimiray
Cc: Oded Gabbay
Cc: Thomas Hellström
Cc: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
intel_encoder
> *encoder,
> struct dp_sdp sdp = {};
> int ret;
>
> - /* When PSR is enabled, VSC SDP is handled by PSR routine */
> - if (crtc_state->has_psr)
> - return;
I almost got confused by this one, but checking the patch 3 again,
it makes total sense.
Reviewed-by: Rodrigo Vivi
> -
> if ((crtc_state->infoframes.enable &
>intel_hdmi_infoframe_enable(type)) == 0)
> return;
> --
> 2.34.1
>
type == DP_SDP_VSC)
> + val |= VSC_DIP_HW_DATA_SW_HEA;
for the part of need to set this bit 26 I confess that I'm not 100% sure.
What register this is in the spec?
but if someone else check these bits, I have nothing against this patch:
Acked-by: Rodrigo Vivi
>
> - val
tting this flag is taken care by PSR code -> read back PSR configuration
> before reading VSC SDP otherwise we get pipeconfig mismatch error.
>
> Signed-off-by: Jouni Högander
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 ++--
> 1 file c
ecking the table in spec and vsc->revision = 5 inside
intel_dp_compute_vsc_colorimetry then I understood that this is for
'PSR2 without colorimetry'.
with that changed or at least clarified:
Reviewed-by: Rodrigo Vivi
> - * Prepare VSC H
ering if we were
sure if we could reach this point in the unified flow, but after
checking the compute config path and seeing that this is only true
if has_psr is also true, then I'm comfortable with this good unification.
Reviewed-by: Rodrigo Vivi
> if (intel_dp-&g
https://lore.kernel.org/lkml/zxpm6gq%2fd59jg...@xpf.sh.intel.com/
> Reported-by: Lucas De Marchi
> Reported-by: Pengfei Xu
> Signed-off-by: Mark Rutland
> Signed-off-by: Peter Zijlstra (Intel)
> Link: https://lkml.kernel.org/r/20231215112450.3972309-1-mark.rutl...@arm.co
On Thu, Dec 14, 2023 at 01:48:33PM +0200, Jouni Högander wrote:
> Colorimetry support is not really a PSR specific thing. Move it to intel_dp
> struct and use it also when preparing vsc sdp for non-PSR case.
>
> Signed-off-by: Jouni Högander
Reviewed-by: Rodrigo Vivi
> ---
>
Reviewed-by: Rodrigo Vivi
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 -
> drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --g
uspend aborted) or get fully purged as part of a GuC
> sanitization (end of suspend) or a reset flow.
>
> Signed-off-by: Alan Previn
> Signed-off-by: Anshuman Gupta
> Tested-by: Mousumi Jana
> Acked-by: Daniele Ceraolo Spurio
Thanks for all the explanations,
On Wed, Dec 13, 2023 at 02:36:40PM +0530, Nemesa Garg wrote:
> Darkscreen detection checks if all the pixels of the frame are less then
> or equal to the comparision value. The comparision value is set to 256
> i.e black. So upon getting black pixels from the pipe, the dark screen
> detect bit is
On Mon, Dec 11, 2023 at 02:42:30PM +0100, Andrzej Hajda wrote:
> On 24.11.2023 08:53, Andrzej Hajda wrote:
> > Cursor size reduction is not supported since MTL.
> >
> > Signed-off-by: Andrzej Hajda
> > ---
> > drivers/gpu/drm/i915/display/intel_display_device.h | 2 +-
> > 1 file changed, 1
Hi Dave and Daniel,
Here goes another pull-request towards 6.8.
We are likely going to send another one in 2 weeks,
but I'd like to get this in right now so we can
get a clean drm-xe-next on top of drm-next for our
first Xe pull request.
Thanks,
Rodrigo.
drm-intel-next-2023-12-07:
- Improve
On Tue, Dec 05, 2023 at 02:15:45PM +0200, Jani Nikula wrote:
> Reduce the duplication.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 24 ++--
> 1 file changed, 10 insertions(+), 14 deletions(
On Wed, Nov 29, 2023 at 04:20:13PM -0800, Alan Previn wrote:
> If we are at the end of suspend or very early in resume
> its possible an async fence signal (via rcu_call) is triggered
> to free_engines which could lead us to the execution of
> the context destruction worker (after a prior worker
On Wed, Nov 29, 2023 at 12:51:21PM -0800, Matt Atwood wrote:
> Function reg_in_range_table is useful in more places, move function to
> intel_uncore.h to make available to more places.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/i915_perf.c| 13 +
>
ns, we have a condition check and only
> > > > > actually try to lock/unlock the spinlock when I915 is defined, and
> > > > > thus uncore is available.
> > > > >
> > > > > This keeps the ifdefs contained in these new functions and all such
&
On Wed, Nov 29, 2023 at 03:24:33PM -0500, Coelho, Luciano wrote:
> On Wed, 2023-11-29 at 13:01 -0500, Rodrigo Vivi wrote:
> > On Wed, Nov 29, 2023 at 11:17:28AM +0200, Luca Coelho wrote:
> > > The uncore code may not always be available (e.g. when we build the
> > > d
On Wed, Nov 29, 2023 at 07:33:17PM +0200, Jani Nikula wrote:
> Avoid bool/int mismatches in state checker macros.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8
> 1 file changed, 8 insertions(
On Wed, Nov 29, 2023 at 07:33:16PM +0200, Jani Nikula wrote:
> Don't treat bools as integers.
>
> v2: Rebase
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8
> 1 file changed, 4 in
!' magic anyway,
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/selftests/i915_syncmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
> b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
> ind
> thus uncore is available.
>
> This keeps the ifdefs contained in these new functions and all such
> logic inside the display code.
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Ville Syrj?l?
> Signed-off-by: Luca Coelho
> ---
>
> In v2:
&g
On Tue, Nov 14, 2023 at 07:52:29AM -0800, Alan Previn wrote:
> If we are at the end of suspend or very early in resume
> its possible an async fence signal (via rcu_call) is triggered
> to free_engines which could lead us to the execution of
> the context destruction worker (after a prior worker
fter the kernel detects the held reference and
> prints a message to abort suspending instead of hanging
> in the kernel forever which then requires serial connection
> or ramoops dump to debug further.
>
> Signed-off-by: Alan Previn
> Reviewed-by: Rodrigo Vivi
> Tested
On Wed, Nov 22, 2023 at 12:30:03PM -0800, Alan Previn wrote:
> Add missing tag for "Wa_14019159160 - Case 2" (for existing
> PXP code that ensures run alone mode bit is set to allow
> PxP-decryption.
>
> v2: - Fix WA id number (John Harrison).
> - Improve comments and code to be specific
>
32b and 64b have exact same
layout (Thomas)
Do not set query's pad and reserved bits to zero since it
is redundant and already done by kzalloc (Matt)
Cc: Thomas Hellström
Cc: Francois Dugast
Cc: José Roberto de Souza
Cc: Matt Roper
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe
On Fri, Nov 17, 2023 at 06:21:07PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 05:09:27PM +0200, Imre Deak wrote:
> > The current way of calculating the pbn_div value, the link BW per each
> > MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
> > rates calculating with
On Fri, Nov 17, 2023 at 11:26:44AM +0200, Ville Syrjälä wrote:
> On Fri, Nov 17, 2023 at 10:41:43AM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 17, 2023 at 08:05:21AM +, Coelho, Luciano wrote:
> > > Thanks for your comments, Ville!
> > >
> > > On Fri, 2023-11-17 at 09:19 +0200, Ville Syrjälä
On Sun, Nov 05, 2023 at 05:27:03PM +, Paz Zcharya wrote:
> Fix the value of variable `phys_base` to be the relative offset in
> stolen memory, and not the absolute offset of the GSM.
to me it looks like the other way around. phys_base is the physical
base address for the frame_buffer. Setting
On Tue, Nov 14, 2023 at 05:27:18PM +, Tvrtko Ursulin wrote:
>
> On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
> > On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
> > > On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2023-09-28 at 13:46 +0100, Tvrtko
On Tue, Nov 14, 2023 at 05:55:28PM +0200, Jani Nikula wrote:
> Like the comment says,
>
> /* Grouping using anonymous structs. Keep sorted. */
>
> Stick to it.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> .../gpu/drm/i915/display
On Mon, Nov 13, 2023 at 11:36:13AM +0800, heminhong wrote:
> Current, the dewake_scanline variable is defined as unsigned int,
> an unsigned int variable that is always greater than or equal to 0.
> when _intel_dsb_commit function is called by intel_dsb_commit function,
> the dewake_scanline
On Fri, Nov 10, 2023 at 01:48:06PM +0200, Jani Nikula wrote:
> The 01.org page has ceased to exist, and the relevant documentation is
> now hosted at https://drm.pages.freedesktop.org/intel-docs/
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Signe
On Fri, Nov 10, 2023 at 01:48:07PM +0200, Jani Nikula wrote:
> The bug filing documentation has been moved from the gitlab wiki to
> gitlab pages at https://drm.pages.freedesktop.org/intel-docs/.
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Signe
On Wed, Nov 01, 2023 at 02:44:46PM -0700, Zhanjun Dong wrote:
> The gt wedged could be triggered by missing guc firmware file, HW not
> working, etc. Once triggered, it means all gt usage is dead, therefore we
> can't enable pxp under this fatal error condition.
>
> v2: Updated commit message.
>
On Thu, Nov 02, 2023 at 01:35:53PM -0300, Gustavo Sousa wrote:
> Quoting Radhakrishna Sripada (2023-11-02 13:06:44-03:00)
> >Experiments were conducted with different multipliers to VTD_GUARD macro
> >with multiplier of 185 we were observing occasional pipe faults when
> >running kms_cursor_legacy
On Fri, Oct 27, 2023 at 02:18:14PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> These w/a's can have signficant performance implications for any
> workload which uses both RCS and CCS. On the other hand, the hang
> itself is only seen in one or two very specific workloads.
Hi Dave and Daniel,
Here goes drm-intel-fixes-2023-10-26:
- Determine context valid in OA reports (Umesh)
- Hold GT forcewake during steering operations (Matt Roper)
- Check if PMU is closed before stopping event (Umesh)
Thanks,
Rodrigo.
The following changes since commit
Hi Dave and Daniel,
Here goes drm-intel-fixes-2023-10-19:
- Fix display issue that was blocking S0ix (Khaled)
- Retry gtt fault when out of fence registers (Ville)
Thanks,
Rodrigo.
The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb:
Linux 6.6-rc6 (2023-10-15
Hi Dave and Daniel,
This is our last pull request towards 6.7.
I'm sending this on behalf of Jani, who was covering this round.
The main reason for this extra PR is to ensure that we get MTL
force_probe removed on 6.7. The platform has a good green picture
in our BAT CI currently and is stable.
al delay as moving reset to *_read_once()
> and *_write_once() functions seem unnecessary delay
>
> Signed-off-by: Mika Kahola
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --
On Mon, Oct 16, 2023 at 09:02:38AM +0100, Tvrtko Ursulin wrote:
>
> On 13/10/2023 21:51, Rodrigo Vivi wrote:
> > On Thu, Sep 28, 2023 at 01:48:34PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 27/09/2023 20:34, Belgaumkar, Vinay wrote:
> > > >
> >
pi?
> > We have asked Carl (cc'd) to post a patch for the same.
>
> Ack.
I'm glad to see that we will have the end-to-end flow of the high-level API.
>
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: Vinay Belgaumkar
> > > > ---
> &
On Fri, Oct 13, 2023 at 09:55:32AM +0300, Mika Kahola wrote:
> Every know and then we receive the following error when running
> for example IGT test kms_flip.
>
> [drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
> [drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
>
> Since the error
On Sun, Oct 08, 2023 at 02:49:40PM -0700, Randy Dunlap wrote:
> Correct typo of "its".
> Add commas for clarity.
> Capitalize L3.
>
> Signed-off-by: Randy Dunlap
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
>
101 - 200 of 5552 matches
Mail list logo
