On Mon, May 13, 2024 at 02:14:51AM -0400, Deming Wang wrote:
> The mapings should be replaced by mappings.
>
> Signed-off-by: Deming Wang
Reviewed-by: Rodrigo Vivi
and pushed to drm-intel-gt-next
thanks for the patch
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |
On Fri, May 10, 2024 at 07:12:14PM +0100, Matthew Auld wrote:
> Hopefully make it clearer when to use devm vs drmm.
>
> Signed-off-by: Matthew Auld
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_managed.c | 42 +++
> 1 file
Hi Dave and Sima,
Here goes our last fixes for v6.9.
drm-intel-fixes-2024-05-08:
- Automate CCS Mode setting during engine resets (Andi)
- Fix audio time stamp programming for DP (Chaitanya)
- Fix parsing backlight BDB data (Karthikeyan)
The following changes since commit
0 ]---
> > >
> > > We defer actually closing, unbinding and destroying a VMA until next idle
> > > point, or until the object is freed in the meantime. By postponing the
> > > unbind, we allow for the VMA to be reopened by the client, avoiding the
> > > work require
hat the releasing after the unprepare sounds more logical,
but if there's no actual issue with that and it is working for
everybody, let's do that.
Reviewed-by: Rodrigo Vivi
Acked-by: Rodrigo Vivi
(to get through drm-misc with everything else if you prefer)
> - kfree(fb_helper);
> -
On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote:
> On 5/3/2024 12:34 PM, Rodrigo Vivi wrote:
> > On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
> >> "master/s
rs of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
>
> Compile tested, no functionality changes intended
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Revie
ned-off-by: Easwar Hariharan
I'm glad to see this change!
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
Hi Dave and Sima,
Here goes one extra, and really the last one targeting 6.10.
We have decided to do this extra one so we could include the
good clean-up on i915/xe's fbdev work done by Thomas Zimmermann.
And it looks like he has more work on top of that, so it would
be good to propagate this
t; Update its location with a URL matching other fd.o GitLab kernel trees.
> > >
> > > Signed-off-by: Ryszard Knop
> >
> > Acked-by: Lucas De Marchi
> >
> > Also Cc'ing maintainers
>
> Thanks,
>
> Acked-by: Tvrtko Ursulin
Acked-by: Rodr
db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload")
> Reported-by: Gnattu OC
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
Reviewed-by: Rodrigo Vivi
> ---
> Hi Gnattu,
>
> thanks ag
Hi Sima and Dave,
Here goes our last pull request towards 6.10.
drm-intel-next-2024-04-24:
Core Changes:
- Some DP/DP_MST DRM helpers (Imre)
Driver Changes (i915 Display):
- PLL refactoring (Ville)
- Limit eDP MSO pipe only for display version 20 (Luca)
- More display refactor towards
On Wed, Apr 24, 2024 at 01:49:16PM +0200, Maxime Ripard wrote:
> On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote:
> > On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
> > >
> > > On 23/04/24 02:24, Rodrigo Vivi wrote:
> > >
On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
>
> On 23/04/24 02:24, Rodrigo Vivi wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we want to
> >> rel
of introducing a
> helper (Rodrigo)
>
> v3: add kernel-doc (Maxime Ripard)
>
> Cc: Maxime Ripard
> Cc: Thomas Hellstr_m
> Cc: Rodrigo Vivi
>
please avoid these empty lines here cc, rv-b, sign-offs, links,
etc are all in the same block.
> Reviewed-by: Rodrigo
of introducing a
> helper (Rodrigo)
>
> Cc: Thomas Hellstr_m
> Cc: Rodrigo Vivi
>
> Reviewed-by: Rodrigo Vivi
Sima, Dave, or drm-misc, ack to get this through drm-xe-next?
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/d
om
drm/i915: Reuse RPLU cdclk fns for MTL+
Ravi Kumar Vodapalli (1):
drm/i915: Add new PCI IDs to DG2 platform in driver
Rodrigo Vivi (1):
Merge drm/drm-next into drm-intel-next
Shekhar Chauhan (1):
drm/i915/dp: Increase idle pattern wait timeout to 2ms
Stanislav Lis
On Thu, Apr 11, 2024 at 12:55:29PM -0400, Golani, Mitulkumar Ajitkumar wrote:
>
>
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Wednesday, April 10, 2024 9:49 PM
> > To: Golani, Mitulkumar Ajitkumar ;
> > tzimmerm...@suse.de; mrip...@kernel.org;
> >
On Tue, Apr 16, 2024 at 12:02:10PM -0700, Dixit, Ashutosh wrote:
> On Tue, 16 Apr 2024 11:55:20 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private
> > > *i915)
> >
;hwmon_dev = hwmon_dev;
> }
> @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
>
> void i915_hwmon_unregister(struct drm_i915_private *i915)
> {
> - fetch_and_zero(>hwmon);
> + struct i915_hwmon *hwmon = fetch_and_zero(>hwmon);
>
On Tue, Apr 16, 2024 at 10:09:46AM +0200, Janusz Krzysztofik wrote:
> Hi Rodrigo,
>
> On Tuesday, 16 April 2024 03:16:31 CEST Rodrigo Vivi wrote:
> > On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> > > We defer actually closing, unbinding and destroyi
On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> We defer actually closing, unbinding and destroying a VMA until next idle
> point, or until the object is freed in the meantime. By postponing the
> unbind, we allow for the VMA to be reopened by the client, avoiding the
> work
ies.
>
> Cc: Joonas Lahtinen
> Cc: Lucas De Marchi
> Cc: Oded Gabbay
> Cc: Rodrigo Vivi
> Cc: Thomas Hellström
> Cc: Tvrtko Ursulin
> Signed-off-by: Jani Nikula
> ---
> MAINTAINERS | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --g
Hi Dave and Sima,
Here goes drm-intel-fixes-2024-04-10:
Display fixes:
- Couple CDCLK programming fixes (Ville)
- HDCP related fix (Suraj)
- 4 Bigjoiner related fixes (Ville)
Core fix:
- Fix for a circular locking around GuC on reset+wedged case (John)
Thanks,
Rodrigo.
The following changes
On Fri, Apr 05, 2024 at 12:21:59PM +0530, Mitul Golani wrote:
> Correct struct member name to 'mode' instead of 'operation mode'
> in 'drm_dp_as_sdp' structure description.
>
> Fixes: 0bbb8f594e33 ("drm/dp: Add Adaptive Sync SDP logging")
Probably good to avoid this 'Fixes:' tag, and only use
> without the need to do unbind and rebind as the driver needs to
> reinitialize the device afresh post FLR.
>
> v2:
all the patches looks good to me here. feel free to use
Reviewed-by: Rodrigo Vivi
on them.
but I do have some concerns (below)
> 1. Directly expose the dev
Hi Dave and Sima,
Here goes drm-intel-fixes-2024-04-04:
Display fixes:
- A few DisplayPort related fixes (Imre, Arun, Ankit, Ville)
- eDP PSR fixes (Jouni)
Core/GT fixes:
- Remove some VM space restrictions on older platforms (Andi)
- Disable automatic load CCS load balancing (Andi)
Thanks,
AWS takes ages but this
> is not an issue with reporting, this is how AWS works.
I'm sorry for the noise. It was probably just a matter of time.
Everything looking good there.
Thanks,
Rodrigo.
>
> Regards,
> Ewelina
>
> -Original Message-
> From: Intel-gfx On Behalf Of
> Rodrigo V
Hi Dave and Sima,
Here goes our first PR of this round.
Our CI is not working as I would expect:
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html?
Well, at least it caught some build failures on runds 832 and 833.
But after I fixed those, the 834 (with v6.9-rc1) and the 835 (with
all
On Wed, Mar 20, 2024 at 04:14:25PM +0530, Aravind Iddamsetty wrote:
> In scenarios where drm_dev_put is directly called by driver we want to
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> Cc: Thomas Hellstr_m
>
> Signed-off-by: Aravind Iddamsetty
> ---
>
> without the need to do unbind and rebind as the driver needs to
> reinitialize the device afresh post FLR.
>
> Cc: Rodrigo Vivi
> Cc: Lucas De Marchi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_
s the busy wakeup. */
> - GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
> -
> if (engine->park)
> engine->park(engine);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 42aade0faf2d1..b061a0a0d6b08 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3272,6 +3272,9 @@ static void execlists_park(struct intel_engine_cs
> *engine)
> {
> cancel_timer(>execlists.timer);
> cancel_timer(>execlists.preempt);
> +
> + /* Reset upon idling, or we may delay the busy wakeup. */
> + WRITE_ONCE(engine->sched_engine->queue_priority_hint, INT_MIN);
maybe better to leave only the scheduler code touching their variables.
but no big blocker and this code seems safe and the mentioned bug,
so,
Reviewed-by: Rodrigo Vivi
> }
>
> static void add_to_engine(struct i915_request *rq)
> --
> 2.43.0
>
On Mon, Mar 11, 2024 at 07:14:09PM +0100, Janusz Krzysztofik wrote:
> On Monday, 11 March 2024 18:35:43 CET Guenter Roeck wrote:
> > On 3/11/24 09:58, Rodrigo Vivi wrote:
> > > On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> > >> In i915 hwmon
On Mon, Mar 11, 2024 at 09:06:46AM +0100, Janusz Krzysztofik wrote:
> In i915 hwmon sysfs getter path we now take a hwmon_lock, then acquire an
> rpm wakeref. That results in lock inversion:
>
> <4> [197.079335] ==
> <4> [197.085473] WARNING:
On Mon, Mar 11, 2024 at 10:35:20AM -0500, Lucas De Marchi wrote:
> On Mon, Mar 11, 2024 at 11:29:31AM -0400, Rodrigo Vivi wrote:
> > > @@ -2907,9 +2829,7 @@ engine_init_workarounds(struct intel_engine_cs
> > > *engine, struct i915_wa_list *wal
>
On Mon, Mar 11, 2024 at 10:29:45AM -0500, Lucas De Marchi wrote:
> On Mon, Mar 11, 2024 at 11:18:03AM -0400, Rodrigo Vivi wrote:
> > On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> > > With no platform declaring graphics/media IP_VER(12, 50),
> >
>
On Wed, Mar 06, 2024 at 11:36:42AM -0800, Lucas De Marchi wrote:
> PCI IDs for PVC were never added and platform always marked with
> force_probe. Drop what's not used and rename some places as needed.
>
> The registers not used anymore are also removed.
>
> Signed-off-by: Lucas De Marchi
> ---
On Wed, Mar 06, 2024 at 11:36:41AM -0800, Lucas De Marchi wrote:
> With no platform declaring graphics/media IP_VER(12, 50),
this is not true.
We still have
#define XE_HPM_FEATURES \
.__runtime.media.ip.ver = 12, \
.__runtime.media.ip.rel = 50
replace the
> checks throughout
a separate patch
to remove that for DG2 (and standalone CI run on that patch by itself):
Reviewed-by: Rodrigo Vivi
>
> Documentation/gpu/rfc/i915_vm_bind.h | 11 +--
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 40
> drivers/gpu/drm/i915/gt/intel_gsc.c
On Fri, Mar 01, 2024 at 02:42:54PM +0100, Thomas Zimmermann wrote:
> Export drm_client_dev_unregister() for use by the i915 driver. The
> driver does not use drm_dev_unregister(),
Perhaps we should make i915 to call for the drm_dev_unregister since it calls
for drm_dev_register?
> so it has to
On Wed, Mar 06, 2024 at 04:11:54PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.03.24 um 17:25 schrieb Jani Nikula:
> > On Tue, 05 Mar 2024, Rodrigo Vivi wrote:
> > > On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> > > > Unregister al
ling per engine if needed (Tvrtko).
>
> v3: Minor review comments (Tvrtko)
>
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Sushma Venkatesh Reddy
> Acked-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/ge
On Fri, Mar 01, 2024 at 02:42:55PM +0100, Thomas Zimmermann wrote:
> Unregister all in-kernel clients before unloading the i915 driver. For
> other drivers, drm_dev_unregister() does this automatically. As i915
> does not use this helper, it has to perform the call by itself. For xe,
> do the same
> > >
> > > The Mesa usage model for this flag is here -
> > > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
> > >
> > > v2: Rename flags as per review suggestions (Rodrigo, Tvrtko).
> > > Also, use flag bits in int
ld emails to point to the
> main one.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
Acked-by: Rodrigo Vivi
> ---
> .mailmap| 5 +
> MAINTAINERS | 2 +-
> 2 files c
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:
> > > >
umar
Cc: Maxime Ripard
Cc: Maarten Lankhorst
Cc: Thomas Zimmermann
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
ind
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
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
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
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
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
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
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
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 07, 2024 at 05:17:19PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
> nonexisting document 'gpu/rfc/xe'
>
>
On Mon, Feb 05, 2024 at 09:44:56AM +0100, Christian König wrote:
> Am 02.02.24 um 22:58 schrieb Rodrigo Vivi:
> > On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
> > > Am 30.01.24 um 04:04 schrieb Matthew Brost:
> > > > Rather then loop over entit
On Tue, Jan 30, 2024 at 08:05:29AM +0100, Christian König wrote:
> Am 30.01.24 um 04:04 schrieb Matthew Brost:
> > Rather then loop over entities until one with a ready job is found,
> > re-queue the run job worker when drm_sched_entity_pop_job() returns NULL.
> >
> > Fixes: 6dbd9004a55
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:
On Fri, Jan 19, 2024 at 04:29:50PM +, Matthew Auld wrote:
> On 19/01/2024 16:25, Rodrigo Vivi wrote:
> > On Tue, Jan 16, 2024 at 05:03:31PM -0500, Rodrigo Vivi wrote:
> > > The file has already been deleted as the tasks were completed.
> > > However the index
On Tue, Jan 16, 2024 at 05:03:31PM -0500, Rodrigo Vivi wrote:
> The file has already been deleted as the tasks were completed.
> However the index reference was missed behind.
Gentle ping on this one.
I should have mentioned here that this fixes a doc build warning:
Documentation/g
The file has already been deleted as the tasks were completed.
However the index reference was missed behind.
Fixes: d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
Cc: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
---
Documentation/gpu/rfc/index.rst | 4
1 file
On Wed, Jan 10, 2024 at 02:07:38PM -0600, Lucas De Marchi wrote:
> On Wed, Jan 10, 2024 at 02:04:27PM -0500, Rodrigo Vivi wrote:
> > The last TODO item here that was not marked as done was
> > the display portion, which came along with the pull-request.
> >
> > So, now
-by: Rodrigo Vivi
---
Documentation/gpu/rfc/xe.rst | 234 ---
1 file changed, 234 deletions(-)
delete mode 100644 Documentation/gpu/rfc/xe.rst
diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
deleted file mode 100644
index 97cf87578f97
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
Hi Dave and Sima,
Here goes the fixes that I had promised last week.
With these in place we should be good now with the all yes config W=1
and different compilers.
Thanks for already include that one that disables the 32-bit. I had
just noticed when I was trying to cherry-pick it to the
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 02:28:04PM -0800, Lucas De Marchi wrote:
> Add a dependency on CONFIG_64BIT since currently the xe driver doesn't
> build on 32bits. It may be enabled again after all the issues are fixed.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
>
larity
Riana Tauro (5):
drm/xe: Fix overflow in vram manager
drm/xe/guc_pc: Reorder forcewake and xe_pm_runtime calls
drm/xe: Fix GT looping for standalone media
drm/xe: add a new sysfs directory for gtidle properties
drm/xe: remove gucrc disable from suspend path
R
ndalone media
drm/xe: add a new sysfs directory for gtidle properties
drm/xe: remove gucrc disable from suspend path
Rodrigo Vivi (66):
drm/xe: Implement a local xe_mmio_wait32
drm/xe: Stop using i915's range_overflows_t macro.
drm/xe: Let's return last value read
ix GT looping for standalone media
drm/xe: add a new sysfs directory for gtidle properties
drm/xe: remove gucrc disable from suspend path
Rodrigo Vivi (66):
drm/xe: Implement a local xe_mmio_wait32
drm/xe: Stop using i915's range_overflows_t macro.
drm/xe: Let's ret
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
e media
drm/xe: add a new sysfs directory for gtidle properties
drm/xe: remove gucrc disable from suspend path
Rodrigo Vivi (65):
drm/xe: Implement a local xe_mmio_wait32
drm/xe: Stop using i915's range_overflows_t macro.
drm/xe: Let's return last value read on xe_mmio_
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
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,
from drm-intel-next branches for now.
Acked-by: Jani Nikula
Acked-by: Joonas Lahtinen
Acked-by: Tvrtko Ursulin
Acked-by: Lucas De Marchi
Acked-by: Oded Gabbay
Acked-by: Thomas Hellström
Signed-off-by: Rodrigo Vivi
---
MAINTAINERS | 29 -
1 file changed, 28
From: Luben Tuikov
Reverse run-queue priority enumeration such that the higest priority is now 0,
and for each consecutive integer the prioirty diminishes.
Run-queues correspond to priorities. To an external observer a scheduler
created with a single run-queue, and another created with
From: Luben Tuikov
Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW.
This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler priorities
in ascending order,
DRM_SCHED_PRIORITY_LOW,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH,
DRM_SCHED_PRIORITY_KERNEL.
Cc: Rob
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
Nothing else to be done on this front from Xe perspective.
Signed-off-by: Rodrigo Vivi
---
Documentation/gpu/rfc/xe.rst | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
index cfff8a59a876
in
a community consensus.
Signed-off-by: Rodrigo Vivi
---
Documentation/gpu/rfc/xe.rst | 64 ++--
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
index 87dd620aea59..cfff8a59a876 100644
Current drm-xe-next doesn't have any drm/scheduler patch that is not
already accepted in drm-misc-next. This completed this goal with
the consensus of how the drm/scheduler fits to the fw scheduling and
the relationship between drm_gpu_scheduler and drm_sched_entity.
Signed-off-by: Rodrigo Vivi
of 2 separate pull requests, one right after the other.
We're looking forward to moving our work on Xe to the mainline and continuing
to evolve drm together towards a better future.
Matthew Brost (1):
drm/doc/rfc: Mark long running workload as complete.
Rodrigo Vivi (4):
drm/doc/rfc: Mark
As already indicated in this block, the consensus was already
reached out and documented as:
The ASYNC VM_BIND document
However this was item was not moved to the completed section.
Let's move and clean up the WIP block.
Signed-off-by: Rodrigo Vivi
---
Documentation/gpu/rfc/xe.rst | 24
that to the 'Completed' section and revisit the long-running
solution as a community after Xe is integrated in DRM.
Signed-off-by: Matthew Brost
Signed-off-by: Rodrigo Vivi
---
Documentation/gpu/rfc/xe.rst | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff
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 Tue, Nov 28, 2023 at 04:51:25PM +0100, Thomas Hellström wrote:
> On Mon, 2023-11-27 at 14:36 -0500, Rodrigo Vivi wrote:
> > On Tue, Nov 21, 2023 at 11:40:46AM +0100, Thomas Hellström wrote:
> > > Add the first version of the VM_BIND locking document which is
> > > in
1 - 100 of 1072 matches
Mail list logo
