Re: [PATCH] MAINTAINERS: Move the drm-intel repo location to fd.o GitLab
On Fri, Apr 26, 2024 at 05:02:54PM +0100, Tvrtko Ursulin wrote: > > > On 26/04/2024 16:47, Lucas De Marchi wrote: > > On Wed, Apr 24, 2024 at 01:41:59PM GMT, Ryszard Knop wrote: > > > The drm-intel repo is moving from the classic fd.o git host to GitLab. > > > 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: Rodrigo Vivi > > Regards, > > Tvrtko > > > > --- > > > MAINTAINERS | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index d6327dc12cb1..fbf7371a0bb0 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -10854,7 +10854,7 @@ W: > > > https://drm.pages.freedesktop.org/intel-docs/ > > > Q: http://patchwork.freedesktop.org/project/intel-gfx/ > > > B: > > > https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html > > > C: irc://irc.oftc.net/intel-gfx > > > -T: git git://anongit.freedesktop.org/drm-intel > > > +T: git https://gitlab.freedesktop.org/drm/i915/kernel.git > > > F: Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > > F: Documentation/gpu/i915.rst > > > F: drivers/gpu/drm/ci/xfails/i915* > > > -- > > > 2.44.0 > > >
Re: [PATCH] drm/i915/gt: Automate CCS Mode setting during engine resets
On Fri, Apr 26, 2024 at 02:07:23AM +0200, Andi Shyti wrote:
> We missed setting the CCS mode during resume and engine resets.
> Create a workaround to be added in the engine's workaround list.
> This workaround sets the XEHP_CCS_MODE value at every reset.
>
> The issue can be reproduced by running:
>
> $ clpeak --kernel-latency
>
> Without resetting the CCS mode, we encounter a fence timeout:
>
> Fence expiration time out i915-:03:00.0:clpeak[2387]:2!
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10895
> Fixes: 6db31251bb26 ("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 again for reporting this issue and for your prompt
> replies on the issue. Would you give this patch a chance?
>
> Andi
>
> drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +++-
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> index 044219c5960a..99b71bb7da0a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c
> @@ -8,14 +8,14 @@
> #include "intel_gt_ccs_mode.h"
> #include "intel_gt_regs.h"
>
> -void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> +unsigned int intel_gt_apply_ccs_mode(struct intel_gt *gt)
> {
> int cslice;
> u32 mode = 0;
> int first_ccs = __ffs(CCS_MASK(gt));
>
> if (!IS_DG2(gt->i915))
> - return;
> + return 0;
>
> /* Build the value for the fixed CCS load balancing */
> for (cslice = 0; cslice < I915_MAX_CCS; cslice++) {
> @@ -35,5 +35,5 @@ void intel_gt_apply_ccs_mode(struct intel_gt *gt)
>XEHP_CCS_MODE_CSLICE_MASK);
> }
>
> - intel_uncore_write(gt->uncore, XEHP_CCS_MODE, mode);
> + return mode;
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> index 9e5549caeb26..55547f2ff426 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
> @@ -8,6 +8,6 @@
>
> struct intel_gt;
>
> -void intel_gt_apply_ccs_mode(struct intel_gt *gt);
> +unsigned int intel_gt_apply_ccs_mode(struct intel_gt *gt);
>
> #endif /* __INTEL_GT_CCS_MODE_H__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 68b6aa11bcf7..58693923bf6c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2703,6 +2703,7 @@ add_render_compute_tuning_settings(struct intel_gt *gt,
> static void ccs_engine_wa_mode(struct intel_engine_cs *engine, struct
> i915_wa_list *wal)
> {
> struct intel_gt *gt = engine->gt;
> + u32 mode;
>
> if (!IS_DG2(gt->i915))
> return;
> @@ -2719,7 +2720,8 @@ static void ccs_engine_wa_mode(struct intel_engine_cs
> *engine, struct i915_wa_li
>* After having disabled automatic load balancing we need to
>* assign all slices to a single CCS. We will call it CCS mode 1
>*/
> - intel_gt_apply_ccs_mode(gt);
> + mode = intel_gt_apply_ccs_mode(gt);
> + wa_masked_en(wal, XEHP_CCS_MODE, mode);
> }
>
> /*
> --
> 2.43.0
>
[PULL] drm-intel-next
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 independence from i915 dev_priv (Jani)
- QGV/SAGV related refactor (Stanislav)
- Few MTL/DSC and a UHBR monitor fix (Imre)
- BXT/GLK per-lane vswing and PHY reg cleanup (Ville)
The following changes since commit 700c34019555392a348f8c03237c1ebb5bf53eb4:
drm/i915/display: tie DMC wakelock to DC5/6 state transitions (2024-04-17
11:41:23 +0300)
are available in the Git repository at:
https://anongit.freedesktop.org/git/drm/drm-intel
tags/drm-intel-next-2024-04-24
for you to fetch changes up to 6068bc209ac8d07a5d04e93f168465195e22a4cc:
drm/i915/dsi: pass display to register macros instead of implicit variable
(2024-04-23 17:00:14 +0300)
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 independence from i915 dev_priv (Jani)
- QGV/SAGV related refactor (Stanislav)
- Few MTL/DSC and a UHBR monitor fix (Imre)
- BXT/GLK per-lane vswing and PHY reg cleanup (Ville)
Imre Deak (11):
drm/i915/dp: Fix DSC line buffer depth programming
drm/i915/dp_mst: Fix symbol clock when calculating the DSC DPT bpp limit
drm/i915/dp_mst: Fix BW limit check when calculating DSC DPT bpp
drm/i915/dp_mst: Account for channel coding efficiency in the DSC DPT bpp
limit
drm/i915/dp_mst: Account with the DSC DPT bpp limit on MTL
drm/i915/dp_mst: Sanitize calculating the DSC DPT bpp limit
drm/dp: Add drm_dp_128b132b_supported()
drm/dp_mst: Factor out drm_dp_mst_port_is_logical()
drm/dp_mst: Add drm_dp_mst_aux_for_parent()
drm/i915/dp_mst: Make HBLANK expansion quirk work for logical ports
drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR rates
Jani Nikula (19):
drm/i915: use system include for drm headers
drm/i915/display: add intel_display -> drm_device backpointer
drm/i915/display: add generic to_intel_display() macro
drm/i915: add generic __to_intel_display()
drm/i915/display: accept either i915 or display for feature tests
drm/i915/quirks: convert struct drm_i915_private to struct intel_display
drm/i915/display: rename __intel_wait_for_register_nowl() to indicate
intel_de_
drm/i915/dmc: convert dmc wakelock interface to struct intel_display
drm/i915/de: allow intel_display and drm_i915_private for de functions
drm/i915/dmc: use struct intel_display more
drm/i915/dmc: handle request_firmware() errors separately
drm/i915/dmc: improve firmware parse failure propagation
drm/i915/dmc: split out per-platform firmware path selection
drm/i915/dmc: change how to disable DMC firmware using module param
drm/i915/display: move dmc_firmware_path to display params
drm/i915/dsi: remove unused _MIPIA_AUTOPWG register definition
drm/i915/dsi: add VLV_ prefix to VLV only register macros
drm/i915/dsi: unify connector/encoder type and name usage
drm/i915/dsi: pass display to register macros instead of implicit variable
Luca Coelho (1):
drm/i915: limit eDP MSO pipe only for display version 20 and below
Stanislav Lisovskiy (4):
drm/i915/display: Add meaningful traces for QGV point info error handling
drm/i915/display: Extract code required to calculate max qgv/psf gv point
drm/i915/display: Disable SAGV on bw init, to force QGV point
recalculation
drm/i915/display: handle systems with duplicate psf gv points
Ville Syrjälä (26):
drm/i915: Replace hand rolled PLL state dump with
intel_dpll_dump_hw_state()
drm/i915: Use printer for the rest of PLL debugfs dump
drm/i915: Rename PLL hw_state variables/arguments
drm/i915: Introduce some local PLL state variables
drm/i915: Extract ilk_fb_cb_factor()
drm/i915: Extract ilk_dpll_compute_fp()
drm/i915: Extract i9xx_dpll_get_hw_state()
drm/i915: Pass the PLL hw_state to pll->enable()
drm/i915: Extract i965_dpll_md()
drm/i915: Extract {i9xx,i8xx,ilk,vlv,chv}_dpll()
drm/i915: Inline {i9xx,ilk}_update_pll_dividers()
drm/i915: Modernize i9xx_pll_refclk()
drm/i915: Drop pointless 'crtc' argument from *_crtc_clock_get()
drm/i915: s/pipe_config/crtc_state/ in legacy PLL code
drm/i915: Add local DPLL 'hw_state' variables
drm/i915: Carve up struct intel_dpll_hw_state
drm/i915: Unionize dpll_hw_state
drm/i915: Suck snps/cx0 PLL states into dpll_hw_state
drm/i915/dpio: Clean up bxt/glk PHY registers
drm/i915/dpio: Add
Re: [PATCH v3 1/4] drm: add devm release action
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 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 > > > >> release devm_drm_dev_init_release action associated with struct > > > >> drm_device. > > > >> > > > >> v2: Directly expose the original function, instead 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. > > > ok. > > > > > > > >> Reviewed-by: Rodrigo Vivi > > > >> Signed-off-by: Aravind Iddamsetty > > > >> --- > > > >> drivers/gpu/drm/drm_drv.c | 13 + > > > >> include/drm/drm_drv.h | 2 ++ > > > >> 2 files changed, 15 insertions(+) > > > >> > > > >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > >> index 243cacb3575c..9d0409165f1e 100644 > > > >> --- a/drivers/gpu/drm/drm_drv.c > > > >> +++ b/drivers/gpu/drm/drm_drv.c > > > >> @@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device > > > >> *parent, > > > >>devm_drm_dev_init_release, dev); > > > >> } > > > >> > > > >> +/** > > > >> + * devm_drm_dev_release_action - Call the final release action of the > > > >> device > > > > Seeing the doc here gave me a second thought > > > > > > > > the original release should be renamed to _devm_drm_dev_release > > > > and this should be called devm_drm_dev_release without the 'action' > > > > word. > > > i believe, was suggested earlier to directly expose the main function, is > > > there any reason to have a __ version ? > > > > No no, just ignore me. Just remove the '_action' and don't change the other. > > > > I don't like exposing the a function with '__'. what would '__' that mean? > > This is what I meant on the first comment. > > > > Now, I believe that we don't need the '_action'. What does the 'action' > > mean? > > > > the devm_drm_dev_release should be enough. But then I got confused and > > I thought it would conflict with the original released function name. > > But I misread it. > > I don't think devm_drm_dev_release is a good name either. Just like any > other devm_* function that cancels what a previous one has been doing > (devm_kfree, devm_backlight_device_unregister, devm_nvmem_device_put, > etc.) it should be called devm_drm_dev_put or something similar. I see what you mean, but I don't believe the 'put' is the best option, for 2 reasons: - in general, we have put paired with gets and this has not get equivalent - this bypass the regular get/put mechanism and forces the releases that would be done only after all drm_dev_put() taking ref to zero. > > Maxime
Re: [PATCH v3 1/4] drm: add devm release action
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
> >> release devm_drm_dev_init_release action associated with struct
> >> drm_device.
> >>
> >> v2: Directly expose the original function, instead 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.
> ok.
> >
> >> Reviewed-by: Rodrigo Vivi
> >> Signed-off-by: Aravind Iddamsetty
> >> ---
> >> drivers/gpu/drm/drm_drv.c | 13 +
> >> include/drm/drm_drv.h | 2 ++
> >> 2 files changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >> index 243cacb3575c..9d0409165f1e 100644
> >> --- a/drivers/gpu/drm/drm_drv.c
> >> +++ b/drivers/gpu/drm/drm_drv.c
> >> @@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device *parent,
> >>devm_drm_dev_init_release, dev);
> >> }
> >>
> >> +/**
> >> + * devm_drm_dev_release_action - Call the final release action of the
> >> device
> > Seeing the doc here gave me a second thought
> >
> > the original release should be renamed to _devm_drm_dev_release
> > and this should be called devm_drm_dev_release without the 'action' word.
> i believe, was suggested earlier to directly expose the main function, is
> there any reason to have a __ version ?
No no, just ignore me. Just remove the '_action' and don't change the other.
I don't like exposing the a function with '__'. what would '__' that mean?
This is what I meant on the first comment.
Now, I believe that we don't need the '_action'. What does the 'action' mean?
the devm_drm_dev_release should be enough. But then I got confused and
I thought it would conflict with the original released function name.
But I misread it.
This also made me ask myself if we really should use 'devm' prefix there
as well.
> >
> >> + * @dev: DRM device
> >> + *
> >> + * 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.
> > But also, this made me more confusing on why this is needed.
> > Why can't we call put and get back?
> IIUC, the ownership of drm_dev_get is with devm_drm_dev_alloc
> and the release is tied to a devm action hence we needed this.
you are right, but it is just a refcount. you are putting that one
back on behalf of the init path, to force the refcount to 0, and
then grabbing it back on init behalf after the flr. So in the
end it is the same.
Then with this flow we also can check if we are really force the
disconnection of eveybody before we are ready to put the last
ref that would call the release fn.
but well, I'm just brainstorming some thoughts on possibilities
of a clear release without forcing that... it would be good
to run some experiments to see if that is possible. if not,
then let's go with this forced one.
>
> >
> > The next needs to make it clear on why we need to release in these
> > scenarios regarless of the number of counters. But do we really
> > want this?
> in our case post tFLR we need to reprobe the device, but the previousdrm
> instance
> is not destroyed with just calling pci_remove as it is tied to PDEV lifetime
> which is not destroyed hence we need to call the last release action ourself
> so that the final release is called.
> >
> > Can we block the flr if we have users? Perhaps this is the reason
> > that on my side the flr was not that clean? beucase I had display
> > so I had clients connected?
> the display side error is due to power wells, post FLR the power wells are
> already
> disabled while we try to disable them from driver again it is throwing
> warnings.
so we probably need to tell display that we are going to be disabled.
probably the same patch that we need for d3cold:
https://lore.kernel.org/all/20240227183725.505699-3-rodrigo.v...@intel.com/
>
> Thanks,
>
> Aravind.
> >
> >> + */
> >> +void devm_drm_dev_release_action(struct drm_device *dev)
> >> +{
> >> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> >> +
Re: [PATCH v3 1/4] drm: add devm release action
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
> release devm_drm_dev_init_release action associated with struct
> drm_device.
>
> v2: Directly expose the original function, instead 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 Vivi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 13 +
> include/drm/drm_drv.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..9d0409165f1e 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,19 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +/**
> + * devm_drm_dev_release_action - Call the final release action of the device
Seeing the doc here gave me a second thought
the original release should be renamed to _devm_drm_dev_release
and this should be called devm_drm_dev_release without the 'action' word.
> + * @dev: DRM device
> + *
> + * 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.
But also, this made me more confusing on why this is needed.
Why can't we call put and get back?
The next needs to make it clear on why we need to release in these
scenarios regarless of the number of counters. But do we really
want this?
Can we block the flr if we have users? Perhaps this is the reason
that on my side the flr was not that clean? beucase I had display
so I had clients connected?
> + */
> +void devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..fa9123684874 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> --
> 2.25.1
>
Re: [PATCH v2 1/4] drm: add devm release action
On Wed, Apr 17, 2024 at 02:11:42PM +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.
>
> v2: Directly expose the original function, instead 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/drm/drm_drv.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..ba60cbb0725f 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,12 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +void devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..fa9123684874 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> --
> 2.25.1
>
[PULL] drm-intel-next
over uncore ones drm/i915: use fine grained -Woverride-init disable drm/i915/display: move dmc_firmware_path to display params Revert "drm/i915/display: move dmc_firmware_path to display params" drm/i915: use IS_JASPERLAKE()/IS_ELKHARTLAKE() instead of IS_PLATFORM() drm/i915/dmc: define firmware URL locally drm/i915: move i915_fixed.h to display/intel_fixed.h drm/xe/display: clean up a lot of cruft from compat i915_drv.h drm/xe/display: remove compat i915_gem.h drm/xe/display: clean up compat i915_vgpu.h drm/i915/gt: drop display clock info from gt debugfs drm/i915: move skl_preferred_vco_freq to display substruct drm/i915: move max_dotclk_freq to display substruct drm/i915: move vblank_enabled to display substruct drm/i915: move display_irqs_enabled to display substruct drm/i915: move de_irq_mask to display substruct drm/i915: move pipestat_irq_mask to display substruct drm/i915: use check_add_overflow() and drop local variants drm/i915/pps: move pps debugfs file to intel_pps.c Janusz Krzysztofik (1): drm/i915/hwmon: Fix locking inversion in sysfs getter Jonathon Hall (1): drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed() Joonas Lahtinen (1): drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c José Roberto de Souza (1): drm/i915: Do not print 'pxp init failed with 0' when it succeed Jouni Högander (23): drm/i915/display: Make intel_dp_aux_fw_sync_len available for PSR code drm/i915/psr: Improve fast and IO wake lines calculation drm/i915/psr: Calculate IO wake and fast wake lines for DISPLAY_VER < 12 drm/i915/display: Increase number of fast wake precharge pulses drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value drm/i915/psr: Move writing early transport pipe src drm/i915/psr: Fix intel_psr2_sel_fetch_et_alignment usage drm/i915/display: Add definition for MCURSOR_MODE_64_2B drm/i915/display: Implement Wa_16021440873 drm/i915/psr: Add missing ALPM AUX-Less register definitions drm/i915/psr: Calculate aux less wake time drm/i915/psr: Silence period and lfps half cycle drm/i915/psr: Enable ALPM on source side for eDP Panel replay drm/i915/psr: Do not write ALPM configuration for PSR1 or DP2.0 Panel Replay drm/i915/psr: Add some documentation of variables used in psr code drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as well drm/i915/psr: Intel_psr_pause/resume needs to support panel replay drm/i915/psr: Do not update phy power state in case of non-eDP panel replay drm/i915/psr: Check possible errors for panel replay as well drm/i915/psr: Do not write registers/bits not applicable for panel replay drm/i915/psr: Unify panel replay enable/disable sink drm/i915/psr: Panel replay has to be enabled before link training drm/i915/psr: Use crtc_state->port_clock instead of intel_dp->link_rate Juha-Pekka Heikkila (1): drm/i915/display: Disable AuxCCS framebuffers if built for Xe Luca Coelho (4): drm/i915/display: add support for DMC wakelocks drm/i915/display: don't allow DMC wakelock on older hardware drm/i915/display: add module parameter to enable DMC wakelock drm/i915/display: tie DMC wakelock to DC5/6 state transitions Lucas De Marchi (7): drm/i915: Drop dead code for xehpsdv drm/i915: Remove XEHP_FWRANGES() drm/i915: Stop inheriting IP_VER(12, 50) drm/i915: Update IP_VER(12, 50) drm/i915: Drop dead code for pvc drm/i915: Remove special handling for !RCS_MASK() drm/i915: Delete stray .rej file Mitul Golani (9): drm/dp: Add support to indicate if sink supports AS SDP drm/dp: Add Adaptive Sync SDP logging drm/i915/display: Add crtc state dump for Adaptive Sync SDP drm/i915/dp: Add Read/Write support for Adaptive Sync SDP drm/i915/dp: Add wrapper function to check AS SDP drm/i915/display: Compute AS SDP parameters drm/i915/display: Add state checker for Adaptive Sync SDP drm/i915/display: Compute vrr_vsync params drm/i915/display: Read/Write Adaptive Sync SDP Nirmoy Das (1): drm/i915: Add missing doc for drm_i915_reset_stats Radhakrishna Sripada (7): drm/i915: Pass size to oprom_get_vbt drm/i915: Pass size to spi_oprom_get_vbt drm/i915: Move vbt read from firmware to intel_bios.c drm/i915: Extract opregion vbt presence check drm/i915: Duplicate opregion vbt memory drm/i915: Show bios vbt when read from firmware/spi/oprom 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
Re: [PATCH] drm/dp: correct struct member name in documentation
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;
> > maarten.lankho...@linux.intel.com
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> > Nautiyal,
> > Ankit K ; Nikula, Jani ;
> > s...@canb.auug.org.au
> > Subject: Re: [PATCH] drm/dp: correct struct member name in documentation
> >
> > 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 that for real code
> > bugs.
>
> Thank you for inputs.. I understood and I will take the future note. Please
> suggest if required to update the change with new revision or we can take
> care while merge.. ?
I can remove it while merging.
I just need an ack from drm or drm-misc maintainers to merge this through
drm-intel-next.
Sima, Dave?
>
> >
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> >
> > drm-misc folks, ack to get this through drm-intel-next, where the original
> > patch
> > is?
> >
> > Thanks,
> > Rodrigo
> >
> > > Cc: Mitul Golani
> > > Cc: Ankit Nautiyal
> > > Cc: Jani Nikula
> > > Signed-off-by: Mitul Golani
> >
> > > ---
> > > include/drm/display/drm_dp_helper.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/drm/display/drm_dp_helper.h
> > > b/include/drm/display/drm_dp_helper.h
> > > index baf9949ff96f..6799f57d635c 100644
> > > --- a/include/drm/display/drm_dp_helper.h
> > > +++ b/include/drm/display/drm_dp_helper.h
> > > @@ -112,7 +112,7 @@ struct drm_dp_vsc_sdp {
> > > * @target_rr: Target Refresh
> > > * @duration_incr_ms: Successive frame duration increase
> > > * @duration_decr_ms: Successive frame duration decrease
> > > - * @operation_mode: Adaptive Sync Operation Mode
> > > + * @mode: Adaptive Sync Operation Mode
> > > */
> > > struct drm_dp_as_sdp {
> > > unsigned char sdp_type;
> > > --
> > > 2.25.1
> > >
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
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)
> > >
> > > void i915_hwmon_unregister(struct drm_i915_private *i915)
> > > {
> > > - fetch_and_zero(>hwmon);
> > > + struct i915_hwmon *hwmon = fetch_and_zero(>hwmon);
> > > + struct hwm_drvdata *ddat = >ddat;
> > > + struct intel_gt *gt;
> > > + int i;
> > > +
> > > + if (!hwmon)
> > > + return;
> >
> > "that's too late", we are going to hear from static analyzer tools.
> >
> > beter to move ddat = >ddat; after this return.
>
> Yeah, I worried a lot about it :/ But then finally decided (and verified)
> that we are never actually dereferencing the (possibly NULL) pointer.
yeap, another acceptable approach is to simply remove this check entirely.
>
> But not sure about static analyzer tools, maybe you are right, I'll move
> it.
>
> > with that,
> >
> > Reviewed-by: Rodrigo Vivi
>
> Thanks a lot :)
>
> Ashutosh
>
> >
> > > +
> > > + for_each_gt(gt, i915, i) {
> > > + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> > > +
> > > + if (ddat_gt->hwmon_dev) {
> > > + hwmon_device_unregister(ddat_gt->hwmon_dev);
> > > + ddat_gt->hwmon_dev = NULL;
> > > + }
> > > + }
> > > +
> > > + if (ddat->hwmon_dev)
> > > + hwmon_device_unregister(ddat->hwmon_dev);
> > > +
> > > + mutex_destroy(>hwmon_lock);
> > > + kfree(hwmon);
> > > }
> > > --
> > > 2.41.0
> > >
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Mon, Apr 15, 2024 at 03:36:12PM -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 code
> paths, which both release either drvdata or hwmon and either can be
> released before the other. These code paths (for device unbind) are as
> follows (see also the bug referenced below):
>
> Call Trace:
> release_nodes+0x11/0x70
> devres_release_group+0xb2/0x110
> component_unbind_all+0x8d/0xa0
> component_del+0xa5/0x140
> intel_pxp_tee_component_fini+0x29/0x40 [i915]
> intel_pxp_fini+0x33/0x80 [i915]
> i915_driver_remove+0x4c/0x120 [i915]
> i915_pci_remove+0x19/0x30 [i915]
> pci_device_remove+0x32/0xa0
> device_release_driver_internal+0x19c/0x200
> unbind_store+0x9c/0xb0
>
> and
>
> Call Trace:
> release_nodes+0x11/0x70
> devres_release_all+0x8a/0xc0
> device_unbind_cleanup+0x9/0x70
> device_release_driver_internal+0x1c1/0x200
> unbind_store+0x9c/0xb0
>
> This means that in i915, if use devm, we cannot gurantee that hwmon will
> always be released before drvdata. Which means that we have a uaf if hwmon
> sysfs is accessed when drvdata has been released but hwmon hasn't.
>
> The only way out of this seems to be do get rid of devm_ and release/free
> everything explicitly during device unbind.
>
> v2: Change commit message and other minor code changes
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 41 +++
> 1 file changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8c3f443c8347..46c24b1ee6df 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -792,7 +792,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> if (!IS_DGFX(i915))
> return;
>
> - hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
> + hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
> if (!hwmon)
> return;
>
> @@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> hwm_get_preregistration_info(i915);
>
> /* hwmon_dev points to device hwmon */
> - hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
> - ddat,
> - _chip_info,
> - hwm_groups);
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
> + ddat,
> + _chip_info,
> + hwm_groups);
> if (IS_ERR(hwmon_dev)) {
> i915->hwmon = NULL;
> return;
> @@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
> hwmon_energy_input, 0))
> continue;
>
> - hwmon_dev = devm_hwmon_device_register_with_info(dev,
> ddat_gt->name,
> - ddat_gt,
> -
> _gt_chip_info,
> - NULL);
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
> + ddat_gt,
> + _gt_chip_info,
> + NULL);
> if (!IS_ERR(hwmon_dev))
> ddat_gt->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);
> + struct hwm_drvdata *ddat = >ddat;
> + struct intel_gt *gt;
> + int i;
> +
> + if (!hwmon)
> + return;
"that's too late", we are going to hear from static analyzer tools.
beter to move ddat = >ddat; after this return.
with that,
Reviewed-by: Rodrigo Vivi
> +
> + for_each_gt(gt, i915, i) {
> + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> +
> + if (ddat_gt->hwmon_dev) {
> + hwmon_device_unregister(ddat_gt->hwmon_dev);
> + ddat_gt->hwmon_dev = NULL;
> + }
> + }
> +
> + if (ddat->hwmon_dev)
> + hwmon_device_unregister(ddat->hwmon_dev);
> +
> + mutex_destroy(>hwmon_lock);
> + kfree(hwmon);
> }
> --
> 2.41.0
>
Re: [PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
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 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 required to rebind the VMA.
> > >
> > > It was assumed that as long as a GT is held idle, no VMA would be reopened
> > > while we destroy them. That assumption is no longer true in multi-GT
> > > configurations, where a VMA we reopen may be handled by a GT different
> > > from the one that we already keep active via its engine while we set up
> > > an execbuf request.
> > >
> > > <4> [260.290809] [ cut here ]
> > > <4> [260.290988] list_del corruption. prev->next should be
> > > 888118c5d990, but was 888118c5a510. (prev=888118c5a510)
> > > <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> > > __list_del_entry_valid_or_report+0xb7/0xe0
> > > ..
> > > <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> > > ...
> > > <4> [260.291087] Call Trace:
> > > <4> [260.291089]
> > > <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> > > <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> > > <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> > > <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [260.292301]
> > > ...
> > > <4> [260.292506] ---[ end trace ]---
> > > <4> [260.292782] general protection fault, probably for non-canonical
> > > address 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> > > <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> > > ...
> > > <4> [260.428756] Call Trace:
> > > <4> [260.431192]
> > > <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> > > <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [639.411134]
> > > ...
> > > <4> [639.449979] ---[ end trace ]---
> > >
> > > As soon as we start unbinding and destroying a VMA, marked it as parked,
> > > and also keep it marked as closed for the rest of its life. When a VMA
> > > to be opened occurs closed, reopen it only if not yet parked.
> > >
> > > v3: Fix misplaced brackets.
> > > v2: Since we no longer re-init the VMA closed list link on VMA park so it
> > > looks like still on a list, don't try to delete it from the list again
> > > after the VMA has been marked as parked.
> > >
> > > Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
> >
> > what about reverting that?
>
> I didn't think of that. Why you think that might be a better approach?
well, I thought of that mainly because...
>
> Anyway, that's a 4 years old patch and a few things have changed since then,
> so simple revert won't work. Moreover, I've just checked that patch was
> supposed to fix another patch, 77853186e547 ("drm/i915: Claim vma while under
> closed_lock in i915_vma_parked()"), which in turn was supposed to fix
> aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events"), and that
> one also referenced still another, cb6c3d45f948 ("drm/i915/gem: Avoid parking
> the vma as we unbind") from December 2019, which finally wasn't a fix but an
> improvement.
... because of histories like that ^ and I was afraid of this patch here now
just put us into a different co
Re: [PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
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 required to rebind the VMA.
>
> It was assumed that as long as a GT is held idle, no VMA would be reopened
> while we destroy them. That assumption is no longer true in multi-GT
> configurations, where a VMA we reopen may be handled by a GT different
> from the one that we already keep active via its engine while we set up
> an execbuf request.
>
> <4> [260.290809] [ cut here ]
> <4> [260.290988] list_del corruption. prev->next should be 888118c5d990,
> but was 888118c5a510. (prev=888118c5a510)
> <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> __list_del_entry_valid_or_report+0xb7/0xe0
> ..
> <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
> <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> ...
> <4> [260.291087] Call Trace:
> <4> [260.291089]
> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> ...
> <4> [260.292301]
> ...
> <4> [260.292506] ---[ end trace ]---
> <4> [260.292782] general protection fault, probably for non-canonical address
> 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
> <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> ...
> <4> [260.428756] Call Trace:
> <4> [260.431192]
> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> ...
> <4> [639.411134]
> ...
> <4> [639.449979] ---[ end trace ]---
>
> As soon as we start unbinding and destroying a VMA, marked it as parked,
> and also keep it marked as closed for the rest of its life. When a VMA
> to be opened occurs closed, reopen it only if not yet parked.
>
> v3: Fix misplaced brackets.
> v2: Since we no longer re-init the VMA closed list link on VMA park so it
> looks like still on a list, don't try to delete it from the list again
> after the VMA has been marked as parked.
>
> Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
what about reverting that?
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: sta...@vger.kernel.org # v6.0+
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 --
> drivers/gpu/drm/i915/i915_vma.c | 32 +++
> drivers/gpu/drm/i915/i915_vma.h | 2 +-
> drivers/gpu/drm/i915/i915_vma_types.h | 3 ++
> 4 files changed, 37 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 42619fc05de48..97e014f94002e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -847,9 +847,12 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> if (unlikely(!lut))
> return -ENOMEM;
>
> + if (!i915_vma_open(vma)) {
> + err = -EEXIST; /* let eb_vma_lookup() retry */
> + goto err_lut_free;
> + }
> +
> i915_vma_get(vma);
> - if (!atomic_fetch_inc(>open_count))
> - i915_vma_reopen(vma);
> lut->handle = handle;
> lut->ctx = ctx;
>
> @@ -880,8 +883,9 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> return 0;
>
> err:
> - i915_vma_close(vma);
> i915_vma_put(vma);
> + i915_vma_close(vma);
> +err_lut_free:
> i915_lut_handle_free(lut);
> return err;
> }
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index d2f064d2525cc..4435c76f28c8c 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -1735,14 +1735,33 @@ static void __i915_vma_remove_closed(struct i915_vma
> *vma)
> list_del_init(>closed_link);
> }
>
> -void i915_vma_reopen(struct i915_vma *vma)
> +static struct i915_vma *i915_vma_reopen(struct i915_vma *vma)
> +{
> + if (atomic_read(>flags) & I915_VMA_PARKED)
> + return NULL;
> +
>
Re: [PATCH 11/10] MAINTAINERS: update i915 and xe entries for include/drm/intel
On Thu, Apr 11, 2024 at 06:45:03PM +0300, Jani Nikula wrote: > With all the Intel specific drm files under include/drm/intel, update > the i915, xe, and the shared display entries. Do not discriminate based > on file name pattern, just add the entire directory for all three > entries. > > 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 --git a/MAINTAINERS b/MAINTAINERS > index e7a511b443af..a71254fdbf4c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10841,6 +10841,7 @@ S:Supported > F: drivers/gpu/drm/i915/display/ > F: drivers/gpu/drm/xe/display/ > F: drivers/gpu/drm/xe/compat-i915-headers > +F: include/drm/intel/ > > INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older excluding Poulsbo, > Moorestown and derivative) > M: Jani Nikula > @@ -10858,7 +10859,7 @@ F: > Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > F: Documentation/gpu/i915.rst > F: drivers/gpu/drm/ci/xfails/i915* > F: drivers/gpu/drm/i915/ > -F: include/drm/i915* > +F: include/drm/intel/ > F: include/uapi/drm/i915_drm.h Acked-by: Rodrigo Vivi on the whole series > > INTEL DRM XE DRIVER (Lunar Lake and newer) > @@ -10875,7 +10876,7 @@ T:git > https://gitlab.freedesktop.org/drm/xe/kernel.git > F: Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon > F: Documentation/gpu/xe/ > F: drivers/gpu/drm/xe/ > -F: include/drm/xe* > +F: include/drm/intel/ > F: include/uapi/drm/xe_drm.h > > INTEL ETHERNET DRIVERS > -- > 2.39.2 >
[PULL] drm-intel-fixes
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 since commit fec50db7033ea478773b159e0e2efb135270e3b7: Linux 6.9-rc3 (2024-04-07 13:22:46 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-04-10 for you to fetch changes up to dcd8992e47f13afb5c11a61e8d9c141c35e23751: drm/i915/vrr: Disable VRR when using bigjoiner (2024-04-08 13:10:10 -0400) 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) John Harrison (1): drm/i915/guc: Fix the fix for reset lock confusion Suraj Kandpal (1): drm/i915/hdcp: Fix get remote hdcp capability function Ville Syrjälä (6): drm/i915/cdclk: Fix CDCLK programming order when pipes are active drm/i915/cdclk: Fix voltage_level programming edge case drm/i915/psr: Disable PSR when bigjoiner is used drm/i915: Disable port sync when bigjoiner is used drm/i915: Disable live M/N updates when using bigjoiner drm/i915/vrr: Disable VRR when using bigjoiner drivers/gpu/drm/i915/display/intel_cdclk.c| 42 +-- drivers/gpu/drm/i915/display/intel_cdclk.h| 3 ++ drivers/gpu/drm/i915/display/intel_ddi.c | 5 +++ drivers/gpu/drm/i915/display/intel_dp.c | 6 +++- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 5 ++- drivers/gpu/drm/i915/display/intel_psr.c | 11 ++ drivers/gpu/drm/i915/display/intel_vrr.c | 7 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 23 + drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +++ 9 files changed, 79 insertions(+), 27 deletions(-)
Re: [PATCH] drm/dp: correct struct member name in documentation
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 that
for real code bugs.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
drm-misc folks, ack to get this through drm-intel-next,
where the original patch is?
Thanks,
Rodrigo
> Cc: Mitul Golani
> Cc: Ankit Nautiyal
> Cc: Jani Nikula
> Signed-off-by: Mitul Golani
> ---
> include/drm/display/drm_dp_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index baf9949ff96f..6799f57d635c 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -112,7 +112,7 @@ struct drm_dp_vsc_sdp {
> * @target_rr: Target Refresh
> * @duration_incr_ms: Successive frame duration increase
> * @duration_decr_ms: Successive frame duration decrease
> - * @operation_mode: Adaptive Sync Operation Mode
> + * @mode: Adaptive Sync Operation Mode
> */
> struct drm_dp_as_sdp {
> unsigned char sdp_type;
> --
> 2.25.1
>
Re: [PATCH v2 0/4] drm/xe: Support PCIe FLR
On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote: > PCI subsystem provides callbacks to inform the driver about a request to > do function level reset by user, initiated by writing to sysfs entry > /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR > 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 devm_drm_dev_release_action instead of introducing > a helper (Rodrigo) > 2. separate out gt idle and pci save/restore to a separate patch (Lucas) > 3. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini On this I also had to fight to get something working on the wedged_mode=2: lore.kernel.org/all/20240403150732.102678-4-rodrigo.v...@intel.com perhaps we can unify things here. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > > dmesg snip showing FLR recovery: things came different at my DG2 here with display working and all: root@rdvivi-desk:/sys/module/xe/drivers/pci:xe/:03:00.0# echo 1 > reset Segmentation fault and many kernel warnings WARNING: CPU: 8 PID: 2389 at drivers/gpu/drm/i915/display/intel_display_power_well.c:281 hsw_wait_for_power_well_enable+0x3e7/0x570 [xe] WARNING: CPU: 9 PID: 1700 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x41/0x60 [ 117.128330] KASAN: null-ptr-deref in range [0x04e8-0x04ef] [ 117.128332] CPU: 13 PID: 2389 Comm: bash Tainted: GW 6.9.0-rc1+ #9 [ 117.135501] ? exc_invalid_op+0x13/0x40 [ 117.143626] Hardware name: iBUYPOWER INTEL/B660 DS3H AC DDR4-Y1, BIOS F5 12/17/2021 [ 117.143627] RIP: 0010:__mutex_lock+0x124/0x14a0 [ 117.143631] Code: d0 7c 08 84 d2 0f 85 62 0f 00 00 8b 0d 85 c8 8f 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 46 0f 00 00 4d 3b 7f 68 0f 85 aa 0e 00 00 bf 01 [ 117.150630] ? asm_exc_invalid_op+0x16/0x20 [ 117.156401] RSP: 0018:c90005a37690 EFLAGS: 00010202 [ 117.156403] RAX: dc00 RBX: RCX: [ 117.163571] ? drm_buddy_fini+0x181/0x220 and more issues. so it looks like we are still missing some parts of the puzzle here... > > [ 590.486336] xe :4d:00.0: enabling device (0140 -> 0142) > [ 590.506933] xe :4d:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.542355] xe :4d:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.578532] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, > 0x0020 > [ 590.578556] xe :4d:00.0: [drm] VRAM[0, 0]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.578560] xe :4d:00.0: [drm] VRAM[0, 0]: DPA range: > [0x-10], io range: > [0x2020-202fff00] > [ 590.578585] xe :4d:00.0: [drm] VRAM[1, 1]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.578589] xe :4d:00.0: [drm] VRAM[1, 1]: DPA range: > [0x0010-20], io range: > [0x2030-203fff00] > [ 590.578592] xe :4d:00.0: [drm] Total VRAM: 0x2020, > 0x0020 > [ 590.578594] xe :4d:00.0: [drm] Available VRAM: > 0x2020, 0x001ffe00 > [ 590.738899] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, > num_engines:1, num_slices:4 > [ 590.889991] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, > num_engines:1, num_slices:4 > [ 590.892835] [drm] Initialized xe 1.1.0 20201103 for :4d:00.0 on > minor 1 > [ 590.900215] xe :9a:00.0: enabling device (0140 -> 0142) > [ 590.915991] xe :9a:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.957450] xe :9a:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.989863] xe :9a:00.0: [drm] VISIBLE VRAM: 0x20e0, > 0x0020 > [ 590.989888] xe :9a:00.0: [drm] VRAM[0, 0]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.989893] xe :9a:00.0: [drm] VRAM[0, 0]: DPA range: > [0x-10], io range: > [0x20e0-20efff00] > [ 590.989918] xe :9a:00.0: [drm] VRAM[1, 1]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.989921] xe :9a:00.0
[PULL] drm-intel-fixes
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, Rodrigo. The following changes since commit 39cd87c4eb2b893354f3b850f916353f2658ae6f: Linux 6.9-rc2 (2024-03-31 14:32:39 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-04-04 for you to fetch changes up to 99f855082f228cdcecd6ab768d3b8b505e0eb028: drm/i915/mst: Reject FEC+MST on ICL (2024-04-03 14:26:11 -0400) 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) Andi Shyti (4): drm/i915/gt: Limit the reserved VM space to only the platforms that need it drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Do not generate the command streamer for all the CCS drm/i915/gt: Enable only one CCS for compute workload Ankit Nautiyal (1): drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13 Arun R Murthy (1): drm/i915/dp: Remove support for UHBR13.5 Imre Deak (1): drm/i915/dp: Fix DSC state HW readout for SST connectors Jouni Högander (3): drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value drm/i915/psr: Move writing early transport pipe src drm/i915/psr: Fix intel_psr2_sel_fetch_et_alignment usage Ville Syrjälä (2): drm/i915/mst: Limit MST+DSC to TGL+ drm/i915/mst: Reject FEC+MST on ICL drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_display.c | 9 --- .../gpu/drm/i915/display/intel_display_device.h| 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 2 + drivers/gpu/drm/i915/display/intel_dp.c| 11 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 78 -- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 + drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 9 +-- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c| 39 +++ drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h| 13 drivers/gpu/drm/i915/gt/intel_gt_regs.h| 6 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c| 30 - 15 files changed, 185 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
Re: [PULL] drm-intel-fixes
On Fri, Mar 29, 2024 at 06:23:54AM -0400, Musial, Ewelina wrote: > Hi Rodrigo, > > When I opened dashboard early morning all results were available, so I don't > think there was any issue during night. > It could be long reporting queue - reporting through 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 Vivi > Sent: Friday, March 29, 2024 2:32 AM > To: Dave Airlie ; Daniel Vetter > Cc: Jani Nikula ; Joonas Lahtinen > ; Tvrtko Ursulin ; > Vivi, Rodrigo ; Thomas Zimmermann > ; Maarten Lankhorst ; > Maxime Ripard ; Thomas Hellström > ; Oded Gabbay ; De > Marchi, Lucas ; dri-devel@lists.freedesktop.org; > intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; > dim-to...@lists.freedesktop.org > Subject: [PULL] drm-intel-fixes > > 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 these > patches here) didn't show up yet. So I have run manual validation on my > DG2+ADL here. > > Everything looking good here, and it is yet -rc1. I'm confident that we can > move ahead with those while we work to get CI back. > > Thanks, > Rodrigo > > drm-intel-fixes-2024-03-28: > > Core/GT Fixes: > - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) > - Update a MTL workaround (Tejas) > - Fix locking inversion in hwmon's sysfs (Janusz) > - Remove a bogus error message around PXP (Jose) > - Fix UAF on VMA (Janusz) > - Reset queue_priority_hint on parking (Chris) > > Display Fixes: > - Remove duplicated audio enable/disable on SDVO and DP (Ville) > - Disable AuxCCS for Xe driver (Juha-Pekka) > - Revert init order of MIPI DSI (Ville) > - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) > - VRR related fixes (Ville) > - Fix a JSL eDP corruption (Jonathon) > - Fix the cursor physical dma address (Ville) > - BIOS VBT related fix (Ville) > > Thanks, > Rodrigo. > > The following changes since commit 4cece764965020c22cff7665b18a012006359095: > > Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) > > are available in the Git repository at: > > https://anongit.freedesktop.org/git/drm/drm-intel > tags/drm-intel-fixes-2024-03-28 > > for you to fetch changes up to 32e39bab59934bfd3f37097d4dd85ac5eb0fd549: > > drm/i915/bios: Tolerate devdata==NULL in > intel_bios_encoder_supports_dp_dual_mode() (2024-03-28 12:16:17 -0400) > > > Core/GT Fixes: > - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) > - Update a MTL workaround (Tejas) > - Fix locking inversion in hwmon's sysfs (Janusz) > - Remove a bogus error message around PXP (Jose) > - Fix UAF on VMA (Janusz) > - Reset queue_priority_hint on parking (Chris) > > Display Fixes: > - Remove duplicated audio enable/disable on SDVO and DP (Ville) > - Disable AuxCCS for Xe driver (Juha-Pekka) > - Revert init order of MIPI DSI (Ville) > - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) > - VRR related fixes (Ville) > - Fix a JSL eDP corruption (Jonathon) > - Fix the cursor physical dma address (Ville) > - BIOS VBT related fix (Ville) > > > Bhanuprakash Modem (2): > drm/i915/drrs: Refactor CPU transcoder DRRS check > drm/i915/display/debugfs: Fix duplicate checks in i915_drrs_status > > Chris Wilson (1): > drm/i915/gt: Reset queue_priority_hint on parking > > Janusz Krzysztofik (2): > drm/i915/hwmon: Fix locking inversion in sysfs getter > drm/i915/vma: Fix UAF on destroy against retire race > > Jonathon Hall (1): > drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed() > > Joonas Lahtinen (1): > drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c > > José Roberto de Souza (1): > drm/i915: Do not print 'pxp init failed with 0' when it succeed > > Juha-Pekka Heikkila (1): > drm/i915/display: Disable AuxCCS framebuffers if built for Xe > > Tejas Upadhyay (1): > drm/i915/mtl: Update workaround 14018575942 > > Ville Syrjälä (6): > drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DP > drm/i915/dsi: Go
[PULL] drm-intel-fixes
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 these patches here) didn't show up yet. So I have run manual validation on my DG2+ADL here. Everything looking good here, and it is yet -rc1. I'm confident that we can move ahead with those while we work to get CI back. Thanks, Rodrigo drm-intel-fixes-2024-03-28: Core/GT Fixes: - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) - Update a MTL workaround (Tejas) - Fix locking inversion in hwmon's sysfs (Janusz) - Remove a bogus error message around PXP (Jose) - Fix UAF on VMA (Janusz) - Reset queue_priority_hint on parking (Chris) Display Fixes: - Remove duplicated audio enable/disable on SDVO and DP (Ville) - Disable AuxCCS for Xe driver (Juha-Pekka) - Revert init order of MIPI DSI (Ville) - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) - VRR related fixes (Ville) - Fix a JSL eDP corruption (Jonathon) - Fix the cursor physical dma address (Ville) - BIOS VBT related fix (Ville) Thanks, Rodrigo. The following changes since commit 4cece764965020c22cff7665b18a012006359095: Linux 6.9-rc1 (2024-03-24 14:10:05 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-03-28 for you to fetch changes up to 32e39bab59934bfd3f37097d4dd85ac5eb0fd549: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() (2024-03-28 12:16:17 -0400) Core/GT Fixes: - Fix for BUG_ON/BUILD_BUG_ON IN I915_memcpy.c (Joonas) - Update a MTL workaround (Tejas) - Fix locking inversion in hwmon's sysfs (Janusz) - Remove a bogus error message around PXP (Jose) - Fix UAF on VMA (Janusz) - Reset queue_priority_hint on parking (Chris) Display Fixes: - Remove duplicated audio enable/disable on SDVO and DP (Ville) - Disable AuxCCS for Xe driver (Juha-Pekka) - Revert init order of MIPI DSI (Ville) - DRRS debugfs fix with an extra refactor patch (Bhanuprakash) - VRR related fixes (Ville) - Fix a JSL eDP corruption (Jonathon) - Fix the cursor physical dma address (Ville) - BIOS VBT related fix (Ville) Bhanuprakash Modem (2): drm/i915/drrs: Refactor CPU transcoder DRRS check drm/i915/display/debugfs: Fix duplicate checks in i915_drrs_status Chris Wilson (1): drm/i915/gt: Reset queue_priority_hint on parking Janusz Krzysztofik (2): drm/i915/hwmon: Fix locking inversion in sysfs getter drm/i915/vma: Fix UAF on destroy against retire race Jonathon Hall (1): drm/i915: Do not match JSL in ehl_combo_pll_div_frac_wa_needed() Joonas Lahtinen (1): drm/i915: Add includes for BUG_ON/BUILD_BUG_ON in i915_memcpy.c José Roberto de Souza (1): drm/i915: Do not print 'pxp init failed with 0' when it succeed Juha-Pekka Heikkila (1): drm/i915/display: Disable AuxCCS framebuffers if built for Xe Tejas Upadhyay (1): drm/i915/mtl: Update workaround 14018575942 Ville Syrjälä (6): drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DP drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly drm/i915/vrr: Generate VRR "safe window" for DSB drm/i915/dsb: Fix DSB vblank waits when using VRR drm/i915: Pre-populate the cursor physical dma address drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() drivers/gpu/drm/i915/display/g4x_dp.c | 2 - drivers/gpu/drm/i915/display/icl_dsi.c | 3 +- drivers/gpu/drm/i915/display/intel_bios.c | 46 +--- drivers/gpu/drm/i915/display/intel_cursor.c| 4 +- drivers/gpu/drm/i915/display/intel_display_types.h | 1 + drivers/gpu/drm/i915/display/intel_dp.c| 12 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- drivers/gpu/drm/i915/display/intel_drrs.c | 14 -- drivers/gpu/drm/i915/display/intel_drrs.h | 3 ++ drivers/gpu/drm/i915/display/intel_dsb.c | 14 ++ drivers/gpu/drm/i915/display/intel_fb_pin.c| 10 + drivers/gpu/drm/i915/display/intel_sdvo.c | 4 -- drivers/gpu/drm/i915/display/intel_vrr.c | 7 +-- drivers/gpu/drm/i915/display/skl_universal_plane.c | 3 ++ drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 -- .../gpu/drm/i915/gt/intel_execlists_submission.c | 3 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c| 1 + drivers/gpu/drm/i915/i915_driver.c | 2 +- drivers/gpu/drm/i915/i915_hwmon.c | 37 drivers/gpu/drm/i915/i915_memcpy.c | 2 + drivers/gpu/drm/i915/i915_reg.h
Re: [RFC 1/2] drm: add devm release action
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
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/drm/drm_drv.h | 4
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 243cacb3575c..b23c5081812b 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -714,6 +714,12 @@ static int devm_drm_dev_init(struct device *parent,
> devm_drm_dev_init_release, dev);
> }
>
> +void __devm_drm_dev_release_action(struct drm_device *dev)
> +{
> + devm_release_action(dev->dev, devm_drm_dev_init_release, dev);
> +}
> +EXPORT_SYMBOL(__devm_drm_dev_release_action);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8878260d7529..a1d12cb72088 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -444,6 +444,8 @@ struct drm_driver {
> const struct file_operations *fops;
> };
>
> +void __devm_drm_dev_release_action(struct drm_device *dev);
> +
> void *__devm_drm_dev_alloc(struct device *parent,
> const struct drm_driver *driver,
> size_t size, size_t offset);
> @@ -477,6 +479,8 @@ void *__devm_drm_dev_alloc(struct device *parent,
> #define devm_drm_dev_alloc(parent, driver, type, member) \
> ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \
> offsetof(type, member)))
> +#define devm_drm_release_action(drm_dev) \
> + __devm_drm_dev_release_action(drm_dev)
why not simply renaming the original function?
>
> struct drm_device *drm_dev_alloc(const struct drm_driver *driver,
>struct device *parent);
> --
> 2.25.1
>
Re: [RFC 2/2] drm/xe/FLR: Support PCIe FLR
On Wed, Mar 20, 2024 at 04:14:26PM +0530, Aravind Iddamsetty wrote:
> PCI subsystem provides callbacks to inform the driver about a request to
> do function level reset by user, initiated by writing to sysfs entry
> /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR
> 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_device_types.h | 3 +
> drivers/gpu/drm/xe/xe_gt.c | 31 ++---
> drivers/gpu/drm/xe/xe_gt.h | 1 +
> drivers/gpu/drm/xe/xe_pci.c | 53 ++--
> drivers/gpu/drm/xe/xe_pci.h | 6 +-
> drivers/gpu/drm/xe/xe_pci_err.c | 94
> 7 files changed, 174 insertions(+), 15 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/xe_pci_err.c
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 3c3e67885559..1447712fec65 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -114,6 +114,7 @@ xe-y += xe_bb.o \
> xe_module.o \
> xe_pat.o \
> xe_pci.o \
> + xe_pci_err.o \
> xe_pcode.o \
> xe_pm.o \
> xe_preempt_fence.o \
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h
> b/drivers/gpu/drm/xe/xe_device_types.h
> index 9785eef2e5a4..e9b8c7cbb428 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -455,6 +455,9 @@ struct xe_device {
> /** @needs_flr_on_fini: requests function-reset on fini */
> bool needs_flr_on_fini;
>
> + /** @pci_state: PCI state of device */
> + struct pci_saved_state *pci_state;
> +
> /* private: */
>
> #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 85408e7a932b..437874a9a5a0 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -629,6 +629,26 @@ static int do_gt_restart(struct xe_gt *gt)
> return 0;
> }
>
> +/* Idle the GT */
> +int xe_idle_gt(struct xe_gt *gt)
> +{
> + int err;
> +
> + xe_gt_sanitize(gt);
> +
> + xe_uc_gucrc_disable(>uc);
> + xe_uc_stop_prepare(>uc);
> + xe_gt_pagefault_reset(gt);
> +
> + err = xe_uc_stop(>uc);
> + if (err)
> + return err;
> +
> + xe_gt_tlb_invalidation_reset(gt);
> +
> + return err;
> +}
> +
> static int gt_reset(struct xe_gt *gt)
> {
> int err;
> @@ -645,21 +665,12 @@ static int gt_reset(struct xe_gt *gt)
> }
>
> xe_pm_runtime_get(gt_to_xe(gt));
> - xe_gt_sanitize(gt);
>
> err = xe_force_wake_get(gt_to_fw(gt), XE_FORCEWAKE_ALL);
> if (err)
> goto err_msg;
>
> - xe_uc_gucrc_disable(>uc);
> - xe_uc_stop_prepare(>uc);
> - xe_gt_pagefault_reset(gt);
> -
> - err = xe_uc_stop(>uc);
> - if (err)
> - goto err_out;
> -
> - xe_gt_tlb_invalidation_reset(gt);
> + xe_idle_gt(gt);
>
> err = do_gt_reset(gt);
> if (err)
> diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
> index ed6ea8057e35..77df919199cc 100644
> --- a/drivers/gpu/drm/xe/xe_gt.h
> +++ b/drivers/gpu/drm/xe/xe_gt.h
> @@ -43,6 +43,7 @@ int xe_gt_resume(struct xe_gt *gt);
> void xe_gt_reset_async(struct xe_gt *gt);
> void xe_gt_sanitize(struct xe_gt *gt);
> void xe_gt_remove(struct xe_gt *gt);
> +int xe_idle_gt(struct xe_gt *gt);
>
> /**
> * xe_gt_any_hw_engine_by_reset_domain - scan the list of engines and return
> the
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index c401d4890386..fcd2a7f66f7b 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -383,6 +383,41 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
>
> #undef INTEL_VGA_DEVICE
>
> +static bool xe_save_pci_state(struct pci_dev *pdev)
> +{
> + struct xe_device *xe = pci_get_drvdata(pdev);
> +
> + if (pci_save_state(pdev))
> + return false;
> +
> + kfree(xe->pci_state);
> +
> + xe->pci_state = pci_store_saved_state(pdev);
> +
> + if (!xe->pci_state) {
> + drm_err(>drm, "Failed to store PCI saved state\n");
> + return false;
> + }
> +
> + return true;
> +}
> +
> +void xe_load_pci_state(struct pci_dev *pdev)
> +{
> + struct xe_device *xe = pci_get_drvdata(pdev);
> +
Re: [PATCH] drm/i915/gt: Reset queue_priority_hint on parking
f 48
> <4>[ 167.304940] RSP: 0018:c959fce0 EFLAGS: 00010246
> <4>[ 167.304942] RAX: 0200 RBX: RCX:
> 0006
> <4>[ 167.304944] RDX: RSI: RDI:
> 0009
> <4>[ 167.304946] RBP: 8881330ca1b0 R08: 0001 R09:
> 0001
> <4>[ 167.304947] R10: 0001 R11: 0001 R12:
> 8881330ca000
> <4>[ 167.304948] R13: 888110f02aa0 R14: 88812d1d0205 R15:
> 88811277d4f0
> <4>[ 167.304950] FS: () GS:88844f78()
> knlGS:
> <4>[ 167.304952] CS: 0010 DS: ES: CR0: 80050033
> <4>[ 167.304953] CR2: 7fc362200c40 CR3: 00013306e003 CR4:
> 00770ef0
> <4>[ 167.304955] PKRU: 5554
> <4>[ 167.304957] Call Trace:
> <4>[ 167.304958]
> <4>[ 167.305573] intel_wakeref_put_last+0x1d/0x80 [i915]
> <4>[ 167.305685] i915_request_retire.part.0+0x34f/0x600 [i915]
> <4>[ 167.305800] retire_requests+0x51/0x80 [i915]
> <4>[ 167.305892] intel_gt_retire_requests_timeout+0x27f/0x700 [i915]
> <4>[ 167.305985] process_scheduled_works+0x2db/0x530
> <4>[ 167.305990] worker_thread+0x18c/0x350
> <4>[ 167.305993] kthread+0xfe/0x130
> <4>[ 167.305997] ret_from_fork+0x2c/0x50
> <4>[ 167.306001] ret_from_fork_asm+0x1b/0x30
> <4>[ 167.306004]
>
> It is necessary for the queue_priority_hint to be lower than the next
> request submission upon waking up, as we rely on the hint to decide when
> to kick the tasklet to submit that first request.
>
> Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/10154
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> Cc: # v5.4+
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c| 3 ---
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 3 +++
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 96bdb93a948d1..fb7bff27b45a3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -279,9 +279,6 @@ static int __engine_park(struct intel_wakeref *wf)
> intel_engine_park_heartbeat(engine);
> intel_breadcrumbs_park(engine->breadcrumbs);
>
> - /* Must be reset upon idling, or we may miss 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
>
Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter
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 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: possible circular locking dependency detected
> > >> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not
> > >> tainted
> > >> <4> [197.098096] --
> > >> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> > >> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at:
> > >> __kmalloc+0x9a/0x350
> > >> <4> [197.116939]
> > >> but task is already holding lock:
> > >> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at:
> > >> hwm_energy+0x4b/0x100 [i915]
> > >> <4> [197.131543]
> > >> which lock already depends on the new lock.
> > >> ...
> > >> <4> [197.507922] Chain exists of:
> > >>fs_reclaim --> >reset.mutex --> >hwmon_lock
> > >> <4> [197.518528] Possible unsafe locking scenario:
> > >> <4> [197.524411]CPU0CPU1
> > >> <4> [197.528916]
> > >> <4> [197.533418] lock(>hwmon_lock);
> > >> <4> [197.537237]lock(>reset.mutex);
> > >> <4> [197.543376]lock(>hwmon_lock);
> > >> <4> [197.549682] lock(fs_reclaim);
> > >> ...
> > >> <4> [197.632548] Call Trace:
> > >> <4> [197.634990]
> > >> <4> [197.637088] dump_stack_lvl+0x64/0xb0
> > >> <4> [197.640738] check_noncircular+0x15e/0x180
> > >> <4> [197.652968] check_prev_add+0xe9/0xce0
> > >> <4> [197.656705] __lock_acquire+0x179f/0x2300
> > >> <4> [197.660694] lock_acquire+0xd8/0x2d0
> > >> <4> [197.673009] fs_reclaim_acquire+0xa1/0xd0
> > >> <4> [197.680478] __kmalloc+0x9a/0x350
> > >> <4> [197.689063] acpi_ns_internalize_name.part.0+0x4a/0xb0
> > >> <4> [197.694170] acpi_ns_get_node_unlocked+0x60/0xf0
> > >> <4> [197.720608] acpi_ns_get_node+0x3b/0x60
> > >> <4> [197.724428] acpi_get_handle+0x57/0xb0
> > >> <4> [197.728164] acpi_has_method+0x20/0x50
> > >> <4> [197.731896] acpi_pci_set_power_state+0x43/0x120
> > >> <4> [197.736485] pci_power_up+0x24/0x1c0
> > >> <4> [197.740047] pci_pm_default_resume_early+0x9/0x30
> > >> <4> [197.744725] pci_pm_runtime_resume+0x2d/0x90
> > >> <4> [197.753911] __rpm_callback+0x3c/0x110
> > >> <4> [197.762586] rpm_callback+0x58/0x70
> > >> <4> [197.766064] rpm_resume+0x51e/0x730
> > >> <4> [197.769542] rpm_resume+0x267/0x730
> > >> <4> [197.773020] rpm_resume+0x267/0x730
> > >> <4> [197.776498] rpm_resume+0x267/0x730
> > >> <4> [197.779974] __pm_runtime_resume+0x49/0x90
> > >> <4> [197.784055] __intel_runtime_pm_get+0x19/0xa0 [i915]
> > >> <4> [197.789070] hwm_energy+0x55/0x100 [i915]
> > >> <4> [197.793183] hwm_read+0x9a/0x310 [i915]
> > >> <4> [197.797124] hwmon_attr_show+0x36/0x120
> > >> <4> [197.800946] dev_attr_show+0x15/0x60
> > >> <4> [197.804509] sysfs_kf_seq_show+0xb5/0x100
> > >>
> > >> However, the lock is only intended to protect either a hwmon overflow
> > >> counter or rmw hardware operations. There is no need to hold the lock,
> > >> only the wakeref, while reading from hardware.
> > >>
> > >> Acquire the lock after hardware read under rpm wakeref.
> > >>
> > >> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> > >> Signed-off-by: Janusz Krzysztofik
> > >> Cc: # v6.2+
> > >> ---
> > >> drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> > >> 1 file changed,
Re: [PATCH] drm/i915/hwmon: Fix locking inversion in sysfs getter
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: possible circular locking dependency detected
> <4> [197.091611] 6.8.0-rc7-Patchwork_129026v7-gc4dc92fb1152+ #1 Not tainted
> <4> [197.098096] --
> <4> [197.104231] prometheus-node/839 is trying to acquire lock:
> <4> [197.109680] 82764d80 (fs_reclaim){+.+.}-{0:0}, at:
> __kmalloc+0x9a/0x350
> <4> [197.116939]
> but task is already holding lock:
> <4> [197.122730] 88811b772a40 (>hwmon_lock){+.+.}-{3:3}, at:
> hwm_energy+0x4b/0x100 [i915]
> <4> [197.131543]
> which lock already depends on the new lock.
> ...
> <4> [197.507922] Chain exists of:
> fs_reclaim --> >reset.mutex --> >hwmon_lock
> <4> [197.518528] Possible unsafe locking scenario:
> <4> [197.524411]CPU0CPU1
> <4> [197.528916]
> <4> [197.533418] lock(>hwmon_lock);
> <4> [197.537237]lock(>reset.mutex);
> <4> [197.543376]lock(>hwmon_lock);
> <4> [197.549682] lock(fs_reclaim);
> ...
> <4> [197.632548] Call Trace:
> <4> [197.634990]
> <4> [197.637088] dump_stack_lvl+0x64/0xb0
> <4> [197.640738] check_noncircular+0x15e/0x180
> <4> [197.652968] check_prev_add+0xe9/0xce0
> <4> [197.656705] __lock_acquire+0x179f/0x2300
> <4> [197.660694] lock_acquire+0xd8/0x2d0
> <4> [197.673009] fs_reclaim_acquire+0xa1/0xd0
> <4> [197.680478] __kmalloc+0x9a/0x350
> <4> [197.689063] acpi_ns_internalize_name.part.0+0x4a/0xb0
> <4> [197.694170] acpi_ns_get_node_unlocked+0x60/0xf0
> <4> [197.720608] acpi_ns_get_node+0x3b/0x60
> <4> [197.724428] acpi_get_handle+0x57/0xb0
> <4> [197.728164] acpi_has_method+0x20/0x50
> <4> [197.731896] acpi_pci_set_power_state+0x43/0x120
> <4> [197.736485] pci_power_up+0x24/0x1c0
> <4> [197.740047] pci_pm_default_resume_early+0x9/0x30
> <4> [197.744725] pci_pm_runtime_resume+0x2d/0x90
> <4> [197.753911] __rpm_callback+0x3c/0x110
> <4> [197.762586] rpm_callback+0x58/0x70
> <4> [197.766064] rpm_resume+0x51e/0x730
> <4> [197.769542] rpm_resume+0x267/0x730
> <4> [197.773020] rpm_resume+0x267/0x730
> <4> [197.776498] rpm_resume+0x267/0x730
> <4> [197.779974] __pm_runtime_resume+0x49/0x90
> <4> [197.784055] __intel_runtime_pm_get+0x19/0xa0 [i915]
> <4> [197.789070] hwm_energy+0x55/0x100 [i915]
> <4> [197.793183] hwm_read+0x9a/0x310 [i915]
> <4> [197.797124] hwmon_attr_show+0x36/0x120
> <4> [197.800946] dev_attr_show+0x15/0x60
> <4> [197.804509] sysfs_kf_seq_show+0xb5/0x100
>
> However, the lock is only intended to protect either a hwmon overflow
> counter or rmw hardware operations. There is no need to hold the lock,
> only the wakeref, while reading from hardware.
>
> Acquire the lock after hardware read under rpm wakeref.
>
> Fixes: c41b8bdcc297 ("drm/i915/hwmon: Show device level energy usage")
> Signed-off-by: Janusz Krzysztofik
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8c3f443c8347e..faf7670de6e06 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -136,11 +136,11 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
> else
> rgaddr = hwmon->rg.energy_status_all;
>
> - mutex_lock(>hwmon_lock);
> -
> with_intel_runtime_pm(uncore->rpm, wakeref)
> reg_val = intel_uncore_read(uncore, rgaddr);
>
> + mutex_lock(>hwmon_lock);
> +
This is not enough.
check hwm_locked_with_pm_intel_uncore_rmw()
It looks like we need to rethink this lock entirely here.
struct mutex hwmon_lock;/* counter overflow \
logic and rmw */
do we really need to protect the rmw?
This also shows me that we have other places with intel_uncore_rmw
without the with runtime_pm.
perhaps we need to stop using the with_rpm macro and use explicit
rpm calls before the hwmon_locks before the rmw?
perhaps we need a more granular lock?
notice that I'm just brainstorming/thinking out loud... someone need
to go there an run an deeper analisys on this lock and rpm calls
on hwmon.
> if (reg_val >= ei->reg_val_prev)
> ei->accum_energy += reg_val - ei->reg_val_prev;
> else
> --
> 2.43.0
>
Re: [PATCH 4/5] drm/i915: Drop dead code for pvc
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 > > > if (engine->flags & I915_ENGINE_FIRST_RENDER_COMPUTE) > > > general_render_compute_wa_init(engine, wal); > > > > > > - if (engine->class == COMPUTE_CLASS) > > > - ccs_engine_wa_init(engine, wal); > > > - else if (engine->class == RENDER_CLASS) > > > > I don't believe we need to remove this chunk since we are not deleting the > > ccs_engine_wa_init. > > If we want to keep that as a placeholder we should also keep the caller as > > well. > > right... I had removed it but brought it back since I noticed the > kernel-doc mentions and forgot to bring back the caller too. I will fix > this in next rev. thanks! with that: Reviewed-by: Rodrigo Vivi > > > thanks > Lucas De Marchi
Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)
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), > > > > this is not true. > > We still have > > > > #define XE_HPM_FEATURES \ > > .__runtime.media.ip.ver = 12, \ > >.__runtime.media.ip.rel = 50 > > > > > > -#define XE_HPM_FEATURES \ > > > - .__runtime.media.ip.ver = 12, \ > > > - .__runtime.media.ip.rel = 50 > > > - > > ^ being removed here since all the users, like below, are overriding it. > > > > #define DG2_FEATURES \ > > > XE_HP_FEATURES, \ > > > - XE_HPM_FEATURES, \ > > > DGFX_FEATURES, \ > > > + .__runtime.graphics.ip.ver = 12, \ > > > .__runtime.graphics.ip.rel = 55, \ > > > + .__runtime.media.ip.ver = 12, \ > > > .__runtime.media.ip.rel = 55, \ > > ^^ > > After applying until this patch: > > $ git grep -e "rel[[:space:]]*=" -- drivers/gpu/drm/i915/i915_pci.c > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 10, > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 55, \ > drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 55, \ > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 60, > drivers/gpu/drm/i915/i915_pci.c:.__runtime.media.ip.rel = 60, > drivers/gpu/drm/i915/i915_pci.c:.__runtime.graphics.ip.rel = 70, > > should I reword anything in the commit message to make my intent > clearer? doh! sorry.. I read the first line of the commit message and stopped. perhaps we could do that HPM removal in a separate patch before this one? Reviewed-by: Rodrigo Vivi on the final result, whatever you decide to split or to rephrase the msg. > > thanks > Lucas De Marchi
Re: [PATCH 4/5] drm/i915: Drop dead code for pvc
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
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 3 -
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 33
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 30 +---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 9 --
> drivers/gpu/drm/i915/gt/intel_mocs.c | 19 ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_sseu.c | 9 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 90 +--
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 -
> drivers/gpu/drm/i915/i915_debugfs.c | 12 --
> drivers/gpu/drm/i915/i915_drv.h | 9 --
> drivers/gpu/drm/i915/i915_pci.c | 36 -
> drivers/gpu/drm/i915/i915_reg.h | 1 -
> drivers/gpu/drm/i915/intel_clock_gating.c | 16 +-
> drivers/gpu/drm/i915/intel_device_info.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> drivers/gpu/drm/i915/intel_step.c | 70 +
> drivers/gpu/drm/i915/intel_uncore.c | 142 --
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 -
> .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 4 -
> 21 files changed, 12 insertions(+), 485 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 0c5cdab278b6..d3300ae3053f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -386,7 +386,7 @@ struct drm_i915_gem_object {
>* and kernel mode driver for caching policy control after GEN12.
>* In the meantime platform specific tables are created to translate
>* i915_cache_level into pat index, for more details check the macros
> - * defined i915/i915_pci.c, e.g. PVC_CACHELEVEL.
> + * defined i915/i915_pci.c, e.g. MTL_CACHELEVEL.
>* For backward compatibility, this field contains values exactly match
>* the entries of enum i915_cache_level for pre-GEN12 platforms (See
>* LEGACY_CACHELEVEL), so that the PTE encode functions for these
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 24d1c28201fa..2e27bcb52e0d 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -189,9 +189,6 @@ static bool gen12_needs_ccs_aux_inv(struct
> intel_engine_cs *engine)
> {
> i915_reg_t reg = gen12_get_aux_inv_reg(engine);
>
> - if (IS_PONTEVECCHIO(engine->i915))
> - return false;
> -
> /*
>* So far platforms supported by i915 having flat ccs do not require
>* AUX invalidation. Check also whether the engine requires it.
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 75bde8c1aa5d..396f5fe993c3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -839,38 +839,6 @@ static void engine_mask_apply_compute_fuses(struct
> intel_gt *gt)
> }
> }
>
> -static void engine_mask_apply_copy_fuses(struct intel_gt *gt)
> -{
> - struct drm_i915_private *i915 = gt->i915;
> - struct intel_gt_info *info = >info;
> - unsigned long meml3_mask;
> - unsigned long quad;
> -
> - if (!(GRAPHICS_VER_FULL(i915) >= IP_VER(12, 60) &&
> - GRAPHICS_VER_FULL(i915) < IP_VER(12, 70)))
> - return;
> -
> - meml3_mask = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
> - meml3_mask = REG_FIELD_GET(GEN12_MEML3_EN_MASK, meml3_mask);
> -
> - /*
> - * Link Copy engines may be fused off according to meml3_mask. Each
> - * bit is a quad that houses 2 Link Copy and two Sub Copy engines.
> - */
> - for_each_clear_bit(quad, _mask, GEN12_MAX_MSLICES) {
> - unsigned int instance = quad * 2 + 1;
> - intel_engine_mask_t mask = GENMASK(_BCS(instance + 1),
> -_BCS(instance));
> -
> - if (mask & info->engine_mask) {
> - gt_dbg(gt, "bcs%u fused off\n", instance);
> - gt_dbg(gt, "bcs%u fused off\n", instance + 1);
> -
> - info->engine_mask &= ~mask;
> - }
> - }
> -}
> -
> /*
> * Determine which engines are fused off in our particular hardware.
> * Note that we have a catch-22 situation where we need to be able to access
> @@ -889,7 +857,6 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
>
>
Re: [PATCH 3/5] drm/i915: Update IP_VER(12, 50)
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 the code with IP_VER(12, 55) so the code makes sense
> by itself with no additional explanation of previous baggage.
>
> The info override for the various _info is then changed so the version
> definition is clearer without pointless overrides.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 4 ++--
> .../gpu/drm/i915/gem/selftests/i915_gem_client_blt.c | 8
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 5 ++---
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 10 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_gt_mcr.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8
> drivers/gpu/drm/i915/gt/intel_migrate.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_sseu.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> drivers/gpu/drm/i915/i915_getparam.c | 4 ++--
> drivers/gpu/drm/i915/i915_gpu_error.c| 5 ++---
> drivers/gpu/drm/i915/i915_pci.c | 12
> drivers/gpu/drm/i915/i915_perf.c | 8
> drivers/gpu/drm/i915/i915_query.c| 2 +-
> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> 24 files changed, 50 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index 3ff3d8889c6c..edb54903be0a 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -713,7 +713,7 @@ static int igt_ppgtt_huge_fill(void *arg)
> {
> struct drm_i915_private *i915 = arg;
> unsigned int supported = RUNTIME_INFO(i915)->page_sizes;
> - bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50);
> + bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55);
> struct i915_address_space *vm;
> struct i915_gem_context *ctx;
> unsigned long max_pages;
> @@ -857,7 +857,7 @@ static int igt_ppgtt_huge_fill(void *arg)
> static int igt_ppgtt_64K(void *arg)
> {
> struct drm_i915_private *i915 = arg;
> - bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50);
> + bool has_pte64 = GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55);
> struct drm_i915_gem_object *obj;
> struct i915_address_space *vm;
> struct i915_gem_context *ctx;
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> index 10a7847f1b04..bac15196b4d2 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> @@ -117,7 +117,7 @@ static bool fastblit_supports_x_tiling(const struct
> drm_i915_private *i915)
> if (gen < 12)
> return true;
>
> - if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
> + if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
> return false;
>
> return HAS_DISPLAY(i915);
> @@ -166,7 +166,7 @@ static int prepare_blit(const struct tiled_blits *t,
> src_pitch = t->width; /* in dwords */
> if (src->tiling == CLIENT_TILING_Y) {
> src_tiles = XY_FAST_COPY_BLT_D0_SRC_TILE_MODE(YMAJOR);
> - if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
> IP_VER(12, 50))
> + if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
> IP_VER(12, 55))
> src_4t = XY_FAST_COPY_BLT_D1_SRC_TILE4;
> } else if (src->tiling == CLIENT_TILING_X) {
> src_tiles = XY_FAST_COPY_BLT_D0_SRC_TILE_MODE(TILE_X);
> @@ -177,7 +177,7 @@ static int prepare_blit(const struct tiled_blits *t,
> dst_pitch = t->width; /* in dwords */
> if (dst->tiling == CLIENT_TILING_Y) {
> dst_tiles = XY_FAST_COPY_BLT_D0_DST_TILE_MODE(YMAJOR);
> - if (GRAPHICS_VER_FULL(to_i915(batch->base.dev)) >=
> IP_VER(12, 50))
> +
Re: [PATCH 2/5] drm/i915: Drop dead code for xehpsdv
On Wed, Mar 06, 2024 at 11:36:40AM -0800, Lucas De Marchi wrote:
> PCI IDs for XEHPSDV were never added and platform always marked with
> force_probe. Drop what's not used and rename some places to either be
> xehp or dg2, depending on the platform/IP checks.
>
> The registers not used anymore are also removed.
>
> Signed-off-by: Lucas De Marchi
> ---
>
> Potential problem here that needs a deeper look, the changes in
> __gen12_fw_ranges. Some ranges had comments saying they were XEHPSDV so
> I removed them, but it needs to be double checked with spec and CI
> results.
I have checked the specs and your patch looks right because those
bits should be reserved for DG2.
But the main issue I see is that we were using that (wrongly?) for
DG2 so far. So it probably deserves a separate patch anyway.
With this patch only removing the comments and 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 | 15 ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 20 +---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 50 --
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 21 ++--
> drivers/gpu/drm/i915/gt/intel_lrc.c | 43 -
> drivers/gpu/drm/i915/gt/intel_migrate.c | 18 ++--
> drivers/gpu/drm/i915/gt/intel_mocs.c | 31 --
> drivers/gpu/drm/i915/gt/intel_rps.c | 2 -
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 95 ---
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
> drivers/gpu/drm/i915/i915_drv.h | 4 -
> drivers/gpu/drm/i915/i915_hwmon.c | 6 --
> drivers/gpu/drm/i915/i915_pci.c | 17
> drivers/gpu/drm/i915/i915_perf.c | 11 +--
> drivers/gpu/drm/i915/i915_reg.h | 3 +-
> drivers/gpu/drm/i915/intel_clock_gating.c | 10 --
> drivers/gpu/drm/i915/intel_device_info.c | 1 -
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> drivers/gpu/drm/i915/intel_step.c | 10 --
> drivers/gpu/drm/i915/intel_uncore.c | 15 +--
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 1 -
> .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 2 -
> 24 files changed, 51 insertions(+), 380 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> b/Documentation/gpu/rfc/i915_vm_bind.h
> index 8a8fcd4fceac..bc26dc126104 100644
> --- a/Documentation/gpu/rfc/i915_vm_bind.h
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence {
> * Multiple VA mappings can be created to the same section of the object
> * (aliasing).
> *
> - * The @start, @offset and @length must be 4K page aligned. However the DG2
> - * and XEHPSDV has 64K page size for device local memory and has compact page
> - * table. On those platforms, for binding device local-memory objects, the
> - * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix
> - * the local memory 64K page and the system memory 4K page bindings in the
> same
> - * 2M range.
> + * The @start, @offset and @length must be 4K page aligned. However the DG2
> has
> + * 64K page size for device local memory and has compact page table. On that
> + * platform, for binding device local-memory objects, the @start, @offset and
> + * @length must be 64K aligned. Also, UMDs should not mix the local memory
> 64K
> + * page and the system memory 4K page bindings in the same 2M range.
> *
> * Error code -EINVAL will be returned if @start, @offset and @length are not
> * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error
> code
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index fa46d2308b0e..1bd0e041e15c 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -500,11 +500,11 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
> }
>
> static void
> -xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
> - struct i915_vma_resource *vma_res,
> - struct sgt_dma *iter,
> - unsigned int pat_index,
> - u32 flags)
> +xehp_ppgtt_insert_huge(struct i915_address_space *vm,
> +struct i915_vma_resource *vma_res,
> +struct sgt_dma *iter,
> +unsigned int pat_index,
> +u32 flags)
> {
> const gen8_pte_t pte_encode = vm->pte_encode(
Re: [PATCH v7 1/6] drm/client: Export drm_client_dev_unregister()
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 clean up the
> in-kernel DRM clients by itself.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_client.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 9403b3f576f7b..3d4f8b77d0789 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -172,6 +172,18 @@ void drm_client_release(struct drm_client_dev *client)
> }
> EXPORT_SYMBOL(drm_client_release);
>
> +/**
> + * drm_client_dev_unregister - Unregister clients
> + * @dev: DRM device
> + *
> + * This function releases all clients by calling each client's
> + * _client_funcs.unregister callback. The callback function
> + * is responsibe for releaseing all resources including the client
> + * itself.
> + *
> + * The helper drm_dev_unregister() calls this function. Drivers
> + * that use it don't need to call this function themselves.
> + */
> void drm_client_dev_unregister(struct drm_device *dev)
> {
> struct drm_client_dev *client, *tmp;
> @@ -191,6 +203,7 @@ void drm_client_dev_unregister(struct drm_device *dev)
> }
> mutex_unlock(>clientlist_mutex);
> }
> +EXPORT_SYMBOL(drm_client_dev_unregister);
>
> /**
> * drm_client_dev_hotplug - Send hotplug event to clients
> --
> 2.43.2
>
Re: [PATCH v7 2/6] drm/i915: Unregister in-kernel clients
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 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 in xe_device_remove()
> > > >
> > > > Note that there are currently no in-kernel clients in i915 or xe. The
> > > > patch prepares the drivers for a related update of their fbdev support.
> > > >
> > > > v7:
> > > > * update xe driver
> > > >
> > > > Signed-off-by: Thomas Zimmermann
> > > > ---
> > > > drivers/gpu/drm/i915/i915_driver.c | 3 +++
> > > > drivers/gpu/drm/xe/xe_device.c | 3 +++
> > > > 2 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index 9ee902d5b72c4..97910a85e3917 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -41,6 +41,7 @@
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -852,6 +853,8 @@ void i915_driver_remove(struct drm_i915_private
> > > > *i915)
> > > > {
> > > > intel_wakeref_t wakeref;
> > > > + drm_client_dev_unregister(>drm);
> > > > +
> > > > wakeref = intel_runtime_pm_get(>runtime_pm);
> > > > i915_driver_unregister(i915);
> > > > diff --git a/drivers/gpu/drm/xe/xe_device.c
> > > > b/drivers/gpu/drm/xe/xe_device.c
> > > > index 919ad88f0495a..7f41f0ec819f0 100644
> > > > --- a/drivers/gpu/drm/xe/xe_device.c
> > > > +++ b/drivers/gpu/drm/xe/xe_device.c
> > > probably deserves a separate patch since this is one here is named
> > > 'drm/i915:'
> > Or do this for both in intel_display_driver_unregister()?
>
> Ok, sure. I'll update this. I also have to update i915 and xe in patches 5
> and 6. I don't see how I can change them individually. How would I best log
> against both of them? drm/{i915,xe}? or drm/intel?
hmmm... though one...
drm-intel is the name of the i915 repository
well, perhaps drm/{i915,xe} works
or maybe just drm/i915/display: because since display is shared, that
kind of "tag" would be an indication that xe needs it as well anyway.
>
> Best regards
> Thomas
>
> >
> > BR,
> > Jani.
> >
> >
> > > > @@ -9,6 +9,7 @@
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -614,6 +615,8 @@ void xe_device_remove(struct xe_device *xe)
> > > > struct xe_gt *gt;
> > > > u8 id;
> > > > + drm_client_dev_unregister(>drm);
> > > > +
> > > > xe_device_remove_display(xe);
> > > > xe_display_fini(xe);
> > > > --
> > > > 2.43.2
> > > >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
>
Re: [PATCH v3] drm/i915/guc: Use context hints for GT frequency
On Mon, Mar 04, 2024 at 03:34:50PM -0800, Vinay Belgaumkar wrote:
> Allow user to provide a low latency context hint. When set, KMD
> sends a hint to GuC which results in special handling for this
> context. SLPC will ramp the GT frequency aggressively every time
> it switches to this context. The down freq threshold will also be
> lower so GuC will ramp down the GT freq for this context more slowly.
> We also disable waitboost for this context as that will interfere with
> the strategy.
>
> We need to enable the use of SLPC Compute strategy during init, but
> it will apply only to contexts that set this bit during context
> creation.
>
> Userland can check whether this feature is supported using a new param-
> I915_PARAM_HAS_CONTEXT_FREQ_HINTS. This flag is true for all guc submission
> enabled platforms as they use SLPC for frequency management.
>
> 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 intel_context as it allows finer control for
> toggling 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/gem/i915_gem_context.c | 16 --
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_rps.c | 4
> .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 ++
> drivers/gpu/drm/i915/i915_getparam.c | 6 ++
> include/uapi/drm/i915_drm.h | 15 +
> 10 files changed, 86 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index dcbfe32fd30c..81f65cab1330 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> struct i915_gem_proto_context *pc,
> struct drm_i915_gem_context_param *args)
> {
> + struct drm_i915_private *i915 = fpriv->i915;
> int ret = 0;
>
> switch (args->param) {
> @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> break;
>
> + case I915_CONTEXT_PARAM_LOW_LATENCY:
> + if (intel_uc_uses_guc_submission(_gt(i915)->uc))
> + pc->user_flags |= BIT(UCONTEXT_LOW_LATENCY);
> + else
> + ret = -EINVAL;
> + break;
> +
> case I915_CONTEXT_PARAM_RECOVERABLE:
> if (args->size)
> ret = -EINVAL;
> @@ -992,6 +1000,9 @@ static int intel_context_set_gem(struct intel_context
> *ce,
> if (sseu.slice_mask && !WARN_ON(ce->engine->class != RENDER_CLASS))
> ret = intel_context_reconfigure_sseu(ce, sseu);
>
> + if (test_bit(UCONTEXT_LOW_LATENCY, >user_flags))
> + __set_bit(CONTEXT_LOW_LATENCY, >flags);
> +
> return ret;
> }
>
> @@ -1630,6 +1641,9 @@ i915_gem_create_context(struct drm_i915_private *i915,
> if (vm)
> ctx->vm = vm;
>
> + /* Assign early so intel_context_set_gem can access these flags */
> + ctx->user_flags = pc->user_flags;
> +
> mutex_init(>engines_mutex);
> if (pc->num_user_engines >= 0) {
> i915_gem_context_set_user_engines(ctx);
> @@ -1652,8 +1666,6 @@ i915_gem_create_context(struct drm_i915_private *i915,
>* is no remap info, it will be a NOP. */
> ctx->remap_slice = ALL_L3_SLICES(i915);
>
> - ctx->user_flags = pc->user_flags;
> -
> for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
> ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 03bc7f9d191b..b6d97da63d1f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/d
Re: [PATCH v7 2/6] drm/i915: Unregister in-kernel clients
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 in xe_device_remove()
>
> Note that there are currently no in-kernel clients in i915 or xe. The
> patch prepares the drivers for a related update of their fbdev support.
>
> v7:
> * update xe driver
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/i915/i915_driver.c | 3 +++
> drivers/gpu/drm/xe/xe_device.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 9ee902d5b72c4..97910a85e3917 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -41,6 +41,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -852,6 +853,8 @@ void i915_driver_remove(struct drm_i915_private *i915)
> {
> intel_wakeref_t wakeref;
>
> + drm_client_dev_unregister(>drm);
> +
> wakeref = intel_runtime_pm_get(>runtime_pm);
>
> i915_driver_unregister(i915);
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 919ad88f0495a..7f41f0ec819f0 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
probably deserves a separate patch since this is one here is named 'drm/i915:'
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -614,6 +615,8 @@ void xe_device_remove(struct xe_device *xe)
> struct xe_gt *gt;
> u8 id;
>
> + drm_client_dev_unregister(>drm);
> +
> xe_device_remove_display(xe);
>
> xe_display_fini(xe);
> --
> 2.43.2
>
Re: [PATCH v2] drm/i915/guc: Use context hints for GT freq
On Wed, Feb 28, 2024 at 11:58:06AM -0800, Belgaumkar, Vinay wrote:
>
> On 2/28/2024 4:54 AM, Tvrtko Ursulin wrote:
> >
> > On 27/02/2024 23:51, Vinay Belgaumkar wrote:
> > > Allow user to provide a low latency context hint. When set, KMD
> > > sends a hint to GuC which results in special handling for this
> > > context. SLPC will ramp the GT frequency aggressively every time
> > > it switches to this context. The down freq threshold will also be
> > > lower so GuC will ramp down the GT freq for this context more slowly.
> > > We also disable waitboost for this context as that will interfere with
> > > the strategy.
> > >
> > > We need to enable the use of SLPC Compute strategy during init, but
> > > it will apply only to contexts that set this bit during context
> > > creation.
> > >
> > > Userland can check whether this feature is supported using a new param-
> > > I915_PARAM_HAS_CONTEXT_FREQ_HINTS. This flag is true for all guc
> > > submission
> > > enabled platforms as they use SLPC for frequency management.
> > >
> > > 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 intel_context as it allows finer control for
> > > toggling per engine if needed (Tvrtko).
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Tvrtko Ursulin
> > > Cc: Sushma Venkatesh Reddy
> > > Signed-off-by: Vinay Belgaumkar
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +++--
> > > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> > > drivers/gpu/drm/i915/gt/intel_rps.c | 5 +
> > > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 ++
> > > drivers/gpu/drm/i915/i915_getparam.c | 12 +++
> > > include/uapi/drm/i915_drm.h | 15 +
> > > 10 files changed, 92 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > index dcbfe32fd30c..0799cb0b2803 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> > > drm_i915_file_private *fpriv,
> > > struct i915_gem_proto_context *pc,
> > > struct drm_i915_gem_context_param *args)
> > > {
> > > + struct drm_i915_private *i915 = fpriv->i915;
> > > int ret = 0;
> > > switch (args->param) {
> > > @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> > > drm_i915_file_private *fpriv,
> > > pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> > > break;
> > > + case I915_CONTEXT_PARAM_LOW_LATENCY:
> > > + if (intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > + pc->user_flags |= BIT(UCONTEXT_LOW_LATENCY);
> > > + else
> > > + ret = -EINVAL;
> > > + break;
> > > +
> > > case I915_CONTEXT_PARAM_RECOVERABLE:
> > > if (args->size)
> > > ret = -EINVAL;
> > > @@ -992,6 +1000,9 @@ static int intel_context_set_gem(struct
> > > intel_context *ce,
> > > if (sseu.slice_mask && !WARN_ON(ce->engine->class !=
> > > RENDER_CLASS))
> > > ret = intel_context_reconfigure_sseu(ce, sseu);
> > > + if (test_bit(UCONTEXT_LOW_LATENCY, >user_flags))
> > > + set_bit(CONTEXT_LOW_LATENCY, >flags);
> >
> > Does not need to be atomic so can use __set_bit as higher up in the
> > function.
> ok.
> >
> > > +
> > > return ret;
> > > }
> > > @@ -1630,6 +1641,8 @@ i915_gem_create_context(struct
> > > drm_i915_private *i915,
> > > if (vm)
> > > ctx->vm = vm;
> > > + ctx->user_flags = pc->user_flags;
> > > +
&
Re: [PATCH] MAINTAINERS: Update email address for Tvrtko Ursulin
On Wed, Feb 28, 2024 at 02:22:40PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > I will lose access to my @.*intel.com e-mail addresses soon so let me > adjust the maintainers entry and update the mailmap too. > > While at it consolidate a few other of my old 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 changed, 6 insertions(+), 1 deletion(-) > > diff --git a/.mailmap b/.mailmap > index b99a238ee3bd..d67e351bce8e 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -608,6 +608,11 @@ TripleX Chung > TripleX Chung > Tsuneo Yoshioka > Tudor Ambarus > +Tvrtko Ursulin > +Tvrtko Ursulin > +Tvrtko Ursulin > +Tvrtko Ursulin > +Tvrtko Ursulin > Tycho Andersen > Tzung-Bi Shih > Uwe Kleine-König > diff --git a/MAINTAINERS b/MAINTAINERS > index 19f6f8014f94..b940bfe2a692 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10734,7 +10734,7 @@ INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older > excluding Poulsbo, Moorestown > M: Jani Nikula > M: Joonas Lahtinen > M: Rodrigo Vivi > -M: Tvrtko Ursulin > +M: Tvrtko Ursulin > L: intel-...@lists.freedesktop.org > S: Supported > W: https://drm.pages.freedesktop.org/intel-docs/ > -- > 2.40.1 >
Re: i915 build error on drm-misc-next
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 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 drivers/gpu/drm/i915/display/intel_ddi.o
> > >CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
> > >CC drivers/gpu/drm/i915/display/intel_display_device.o
> > >CC drivers/gpu/drm/i915/display/intel_display_trace.o
> > >CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
> > >CC drivers/gpu/drm/i915/display/intel_dp.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_aux.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_mst.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
> > >CC drivers/gpu/drm/i915/display/intel_dvo.o
> > >CC drivers/gpu/drm/i915/display/intel_gmbus.o
> > >CC drivers/gpu/drm/i915/display/intel_hdmi.o
> > >CC drivers/gpu/drm/i915/display/intel_lspcon.o
> > >CC drivers/gpu/drm/i915/display/intel_lvds.o
> > >CC drivers/gpu/drm/i915/display/intel_panel.o
> > >CC drivers/gpu/drm/i915/display/intel_pps.o
> > > drivers/gpu/drm/i915/display/intel_dp.c: In function
> > > ‘intel_write_dp_vsc_sdp’:
> > > drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit
> > > declaration
> > > of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
> > > [-Werror=implicit-function-declaration]
> > > 4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> > >| ^
> > >| drm_dp_vsc_sdp_pack
> > >
> > > Is this a known issue?
> >
> > o.O - what a mistery!
> >
> > it looks that drm-misc-next has only part of the patch:
> > 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
> >
> > without the patch itself...
> >
> > I couldn't even trace back to understand how the declaration is
> > gone from the drm-misc-next...
> >
>
> Looks like the issue here is that the below patch which landed in
> drm-misc-next
>
> https://patchwork.freedesktop.org/patch/579128/?series=130145=1
>
> was based on top of drm-tip because the intel CI runs on drm-tip and not
> drm-misc-next.
>
> But, https://patchwork.freedesktop.org/patch/572622/ is not present in
> drm-misc-next.
>
> Hence this broke the compilation.
>
> How would you prefer to fix this? We revert
> https://patchwork.freedesktop.org/series/130145/ from drm-misc and land it
> through i915 tree and can you provide us a tag from the i915 tree to rebase
> our msm-next tree on?
The revert from drm-misc is a possibility, then you squash
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
in and merge it again.
or if drm-misc and drm maintainers are okay we can simply add
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
on top of drm-misc-next
and on any conflict later the resolution is simply deleting this line
anyway.
>
> > >
> > > -Jeff
Re: [PATCH] drm/i915/guc: Add Compute context hint
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 21/02/2024 21:28, Rodrigo Vivi wrote: > > > > > On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote: > > > > > > > > > > > > On 21/02/2024 00:14, Vinay Belgaumkar wrote: > > > > > > > Allow user to provide a context hint. When this is set, KMD will > > > > > > > send a hint to GuC which results in special handling for this > > > > > > > context. SLPC will ramp the GT frequency aggressively every time > > > > > > > it switches to this context. The down freq threshold will also be > > > > > > > lower so GuC will ramp down the GT freq for this > > > > > > > context more slowly. > > > > > > > We also disable waitboost for this context as that > > > > > > > will interfere with > > > > > > > the strategy. > > > > > > > > > > > > > > We need to enable the use of Compute strategy during SLPC init, > > > > > > > but > > > > > > > it will apply only to contexts that set this bit during context > > > > > > > creation. > > > > > > > > > > > > > > Userland can check whether this feature is supported > > > > > > > using a new param- > > > > > > > I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true > > > > > > > for all guc submission > > > > > > > enabled platforms since they use SLPC for freq management. > > > > > > > > > > > > > > The Mesa usage model for this flag is here - > > > > > > > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint > > > > > > > > > > > > This allows for setting it for the whole application, > > > > > > correct? Upsides, > > > > > > downsides? Are there any plans for per context? > > > > > > > > > > Currently there's no extension on a high level API > > > > > (Vulkan/OpenGL/OpenCL/etc) > > > > > that would allow the application to hint for > > > > > power/freq/latency. So Mesa cannot > > > > > decide when to hint. So their 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. > > > > > > > > In principle yeah I doesn't harm to have the option. I am just > > > > not sure how useful this intermediate step this is with its lack > > > > of intra-process granularity. > > > > > > > > > > > Cc: Rodrigo Vivi > > > > > > > Signed-off-by: Vinay Belgaumkar > > > > > > > --- > > > > > > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++ > > > > > > > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + > > > > > > > drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++ > > > > > > > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | > > > > > > > 21 +++ > > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | > > > > > > > 17 +++ > > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 + > > > > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++ > > > > > > > drivers/gpu/drm/i915/i915_getparam.c | 11 ++ > > > > > > > include/uapi/drm/i915_drm.h | 15 > > > > > > > + > > > > > > > 9 files changed, 89 insertions(+) > > > > > > > > > > > > > > diff --git > > > > > > > a/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > > > > > > >
[PATCH] drm/i915: convert remaining intel_dp_vsc_sdp_pack
Commit 47f419e07111 ("drm/dp: move intel_dp_vsc_sdp_pack() to generic helper")
and commit b55b88d86fec ("drm/dp: drop the size parameter from
drm_dp_vsc_sdp_pack()")
were based on top of a tree containing the
commit 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation") but
landed in a tree where this commit didn't exist, leaving behind a spurious
case calling for a removed function: intel_dp_vsc_sdp_pack()
Let's convert the remaining case here so we can port this patch to
any tree that doesn't contain
commit 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
In in kind of merge where this commit does exist, this line here will
be gone anyway and not needed any longer.
Fixes: 47f419e07111 ("drm/dp: move intel_dp_vsc_sdp_pack() to generic helper")
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
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
index 756c15791a3c..c2e73ba5b2b1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4229,7 +4229,7 @@ void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
struct dp_sdp sdp = {};
ssize_t len;
- len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
+ len = drm_dp_vsc_sdp_pack(vsc, );
if (drm_WARN_ON(_priv->drm, len < 0))
return;
--
2.43.2
Re: i915 build error on drm-misc-next
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 drivers/gpu/drm/i915/display/intel_ddi.o
> CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
> CC drivers/gpu/drm/i915/display/intel_display_device.o
> CC drivers/gpu/drm/i915/display/intel_display_trace.o
> CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
> CC drivers/gpu/drm/i915/display/intel_dp.o
> CC drivers/gpu/drm/i915/display/intel_dp_aux.o
> CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
> CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
> CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
> CC drivers/gpu/drm/i915/display/intel_dp_mst.o
> CC drivers/gpu/drm/i915/display/intel_dsi.o
> CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
> CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
> CC drivers/gpu/drm/i915/display/intel_dvo.o
> CC drivers/gpu/drm/i915/display/intel_gmbus.o
> CC drivers/gpu/drm/i915/display/intel_hdmi.o
> CC drivers/gpu/drm/i915/display/intel_lspcon.o
> CC drivers/gpu/drm/i915/display/intel_lvds.o
> CC drivers/gpu/drm/i915/display/intel_panel.o
> CC drivers/gpu/drm/i915/display/intel_pps.o
> drivers/gpu/drm/i915/display/intel_dp.c: In function
> ‘intel_write_dp_vsc_sdp’:
> drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit declaration
> of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
> [-Werror=implicit-function-declaration]
> 4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> | ^
> | drm_dp_vsc_sdp_pack
>
> Is this a known issue?
o.O - what a mistery!
it looks that drm-misc-next has only part of the patch:
31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
without the patch itself...
I couldn't even trace back to understand how the declaration is
gone from the drm-misc-next...
>
> -Jeff
Re: [PATCH 2/2] drm/i915: Support replaying GPU hangs with captured context image
On Wed, Feb 21, 2024 at 02:22:45PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> When debugging GPU hangs Mesa developers are finding it useful to replay
> the captured error state against the simulator. But due various simulator
> limitations which prevent replicating all hangs, one step further is being
> able to replay against a real GPU.
>
> This is almost doable today with the missing part being able to upload the
> captured context image into the driver state prior to executing the
> uploaded hanging batch and all the buffers.
>
> To enable this last part we add a new context parameter called
> I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU
> configuration pattern of being able to select which context to apply
> against, paired with the actual image and its size.
>
> Since this is adding a new concept of debug only uapi, we hide it behind
> a new kconfig option and also require activation with a module parameter.
> Together with a warning banner printed at driver load, all those combined
> should be sufficient to guard against inadvertently enabling the feature.
>
> In terms of implementation we allow the legacy context set param to be
> used since that removes the need to record the per context data in the
> proto context, while still allowing flexibility of specifying context
> images for any context.
>
> Mesa MR using the uapi can be seen at:
> 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 Landwerlin
> Cc: Carlos Santa
> Cc: Rodrigo Vivi
> Reviewed-by: Rodrigo Vivi # v1
still valid for v2. Thanks for splitting the patch.
> ---
> drivers/gpu/drm/i915/Kconfig.debug| 17 +++
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 113 ++
> drivers/gpu/drm/i915/gt/intel_context.c | 2 +
> drivers/gpu/drm/i915/gt/intel_context.h | 22
> drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
> drivers/gpu/drm/i915/i915_params.c| 5 +
> drivers/gpu/drm/i915/i915_params.h| 3 +-
> include/uapi/drm/i915_drm.h | 27 +
> 10 files changed, 193 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug
> b/drivers/gpu/drm/i915/Kconfig.debug
> index 5b7162076850..32e9f70e91ed 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -16,6 +16,23 @@ config DRM_I915_WERROR
>
> If in doubt, say "N".
>
> +config DRM_I915_REPLAY_GPU_HANGS_API
> + bool "Enable GPU hang replay userspace API"
> + depends on DRM_I915
> + depends on EXPERT
> + default n
> + help
> + Choose this option if you want to enable special and unstable
> + userspace API used for replaying GPU hangs on a running system.
> +
> + This API is intended to be used by userspace graphics stack developers
> + and provides no stability guarantees.
> +
> + The API needs to be activated at boot time using the
> + enable_debug_only_api module parameter.
> +
> + If in doubt, say "N".
> +
> config DRM_I915_DEBUG
> bool "Enable additional driver debugging"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index dcbfe32fd30c..481aacbc1772 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -78,6 +78,7 @@
> #include "gt/intel_engine_user.h"
> #include "gt/intel_gpu_commands.h"
> #include "gt/intel_ring.h"
> +#include "gt/shmem_utils.h"
>
> #include "pxp/intel_pxp.h"
>
> @@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct
> drm_i915_file_private *fpriv,
> case I915_CONTEXT_PARAM_NO_ZEROMAP:
> case I915_CONTEXT_PARAM_BAN_PERIOD:
> case I915_CONTEXT_PARAM_RINGSIZE:
> + case I915_CONTEXT_PARAM_CONTEXT_IMAGE:
> default:
> ret = -EINVAL;
> break;
> @@ -2092,6 +2094,95 @@ static int get_protected(struct i915_gem_context *ctx,
> return 0;
> }
>
> +static int set_context_image(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + struct i915_gem_context_pa
Re: [PATCH 1/2] drm/i915: Shadow default engine context image in the context
On Wed, Feb 21, 2024 at 02:22:44PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> To enable adding override of the default engine context image let us start
> shadowing the per engine state in the context.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Lionel Landwerlin
> 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 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index 7eccbd70d89f..b179178680a5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -99,6 +99,8 @@ struct intel_context {
> struct i915_address_space *vm;
> struct i915_gem_context __rcu *gem_context;
>
> + struct file *default_state;
> +
> /*
>* @signal_lock protects the list of requests that need signaling,
>* @signals. While there are any requests that need signaling,
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 7c367ba8d9dc..d4eb822d20ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1060,9 +1060,8 @@ void lrc_init_state(struct intel_context *ce,
>
> set_redzone(state, engine);
>
> - if (engine->default_state) {
> - shmem_read(engine->default_state, 0,
> -state, engine->context_size);
> + if (ce->default_state) {
> + shmem_read(ce->default_state, 0, state, engine->context_size);
> __set_bit(CONTEXT_VALID_BIT, >flags);
> inhibit = false;
> }
> @@ -1174,6 +1173,8 @@ int lrc_alloc(struct intel_context *ce, struct
> intel_engine_cs *engine)
>
> GEM_BUG_ON(ce->state);
>
> + ce->default_state = engine->default_state;
> +
> vma = __lrc_alloc_state(ce, engine);
> if (IS_ERR(vma))
> return PTR_ERR(vma);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 92085ffd23de..8625e88e785f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -474,8 +474,7 @@ static int ring_context_init_default_state(struct
> intel_context *ce,
> if (IS_ERR(vaddr))
> return PTR_ERR(vaddr);
>
> - shmem_read(ce->engine->default_state, 0,
> -vaddr, ce->engine->context_size);
> + shmem_read(ce->default_state, 0, vaddr, ce->engine->context_size);
>
> i915_gem_object_flush_map(obj);
> __i915_gem_object_release_map(obj);
> @@ -491,7 +490,7 @@ static int ring_context_pre_pin(struct intel_context *ce,
> struct i915_address_space *vm;
> int err = 0;
>
> - if (ce->engine->default_state &&
> + if (ce->default_state &&
> !test_bit(CONTEXT_VALID_BIT, >flags)) {
> err = ring_context_init_default_state(ce, ww);
> if (err)
> @@ -570,6 +569,8 @@ static int ring_context_alloc(struct intel_context *ce)
> {
> struct intel_engine_cs *engine = ce->engine;
>
> + ce->default_state = engine->default_state;
> +
> /* One ringbuffer to rule them all */
> GEM_BUG_ON(!engine->legacy.ring);
> ce->ring = engine->legacy.ring;
> --
> 2.40.1
>
Re: [PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
On Tue, Feb 20, 2024 at 11:53:47AM -0800, Abhinav Kumar wrote:
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav 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/display/drm_dp_helper.h | 3 +--
> 3 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 6c91f400ecb1..10ee82e34de7 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2918,19 +2918,15 @@ EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> * @vsc: vsc sdp initialized according to its purpose as defined in
> * table 2-118 - table 2-120 in DP 1.4a specification
> * @sdp: valid handle to the generic dp_sdp which will be packed
> - * @size: valid size of the passed sdp handle
> *
> * Returns length of sdp on success and error code on failure
> */
> ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size)
> + struct dp_sdp *sdp)
> {
> size_t length = sizeof(struct dp_sdp);
>
> - if (size < length)
> - return -ENOSPC;
> -
> - memset(sdp, 0, size);
> + memset(sdp, 0, sizeof(struct dp_sdp));
>
> /*
>* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a9458df475e2..e13121dc3a03 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4181,8 +4181,7 @@ static void intel_write_dp_sdp(struct intel_encoder
> *encoder,
>
> switch (type) {
> case DP_SDP_VSC:
> - len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, ,
> - sizeof(sdp));
> + len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, );
> break;
> case HDMI_PACKET_TYPE_GAMUT_METADATA:
> len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 8474504d4c88..1f41994796d3 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -812,7 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> int bpp_x16, unsigned long flags);
> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
>
> -ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size);
> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp
> *sdp);
>
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.34.1
>
Re: [PATCH v3 2/2] drm/dp: drop the size parameter from drm_dp_vsc_sdp_pack()
On Tue, Feb 20, 2024 at 11:53:47AM -0800, Abhinav Kumar wrote:
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-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/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 6c91f400ecb1..10ee82e34de7 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2918,19 +2918,15 @@ EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> * @vsc: vsc sdp initialized according to its purpose as defined in
> * table 2-118 - table 2-120 in DP 1.4a specification
> * @sdp: valid handle to the generic dp_sdp which will be packed
> - * @size: valid size of the passed sdp handle
> *
> * Returns length of sdp on success and error code on failure
> */
> ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size)
> + struct dp_sdp *sdp)
> {
> size_t length = sizeof(struct dp_sdp);
>
> - if (size < length)
> - return -ENOSPC;
> -
> - memset(sdp, 0, size);
> + memset(sdp, 0, sizeof(struct dp_sdp));
>
> /*
>* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a9458df475e2..e13121dc3a03 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4181,8 +4181,7 @@ static void intel_write_dp_sdp(struct intel_encoder
> *encoder,
>
> switch (type) {
> case DP_SDP_VSC:
> - len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, ,
> - sizeof(sdp));
> + len = drm_dp_vsc_sdp_pack(_state->infoframes.vsc, );
> break;
> case HDMI_PACKET_TYPE_GAMUT_METADATA:
> len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 8474504d4c88..1f41994796d3 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -812,7 +812,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> int bpp_x16, unsigned long flags);
> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
>
> -ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
> - struct dp_sdp *sdp, size_t size);
> +ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc, struct dp_sdp
> *sdp);
>
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.34.1
>
Re: [PATCH] drm/i915: Add missing ; to __assign_str() macros in tracepoint code
On Thu, Feb 22, 2024 at 01:43:49PM -0500, Steven Rostedt wrote:
> On Thu, 22 Feb 2024 13:30:57 -0500
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > I'm working on improving the __assign_str() and __string() macros to be
> > more efficient, and removed some unneeded semicolons. This triggered a bug
> > in the build as some of the __assign_str() macros in intel_display_trace
> > was missing a terminating semicolon.
> >
> > Fixes: 2ceea5d88048b ("drm/i915: Print plane name in fbc tracepoints")
> > Signed-off-by: Steven Rostedt (Google)
> > ---
>
> Note, I have patches that depend on this fix, so if one of the maintainers
> would like to just give me an "Acked-by", I'll take it through my tree. I
> doubt it will have any conflicts, unless you are planning 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
Re: [PATCH] drm/i915/guc: Add Compute context hint
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
>
> On 21/02/2024 00:14, Vinay Belgaumkar wrote:
> > Allow user to provide a context hint. When this is set, KMD will
> > send a hint to GuC which results in special handling for this
> > context. SLPC will ramp the GT frequency aggressively every time
> > it switches to this context. The down freq threshold will also be
> > lower so GuC will ramp down the GT freq for this context more slowly.
> > We also disable waitboost for this context as that will interfere with
> > the strategy.
> >
> > We need to enable the use of Compute strategy during SLPC init, but
> > it will apply only to contexts that set this bit during context
> > creation.
> >
> > Userland can check whether this feature is supported using a new param-
> > I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc submission
> > enabled platforms since they use SLPC for freq management.
> >
> > The Mesa usage model for this flag is here -
> > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
>
> This allows for setting it for the whole application, correct? Upsides,
> downsides? Are there any plans for per context?
Currently there's no extension on a high level API (Vulkan/OpenGL/OpenCL/etc)
that would allow the application to hint for power/freq/latency. So Mesa cannot
decide when to hint. So their 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: Vinay Belgaumkar
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
> > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
> > drivers/gpu/drm/i915/i915_getparam.c | 11 ++
> > include/uapi/drm/i915_drm.h | 15 +
> > 9 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index dcbfe32fd30c..ceab7dbe9b47 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
> > drm_i915_file_private *fpriv,
> >struct i915_gem_proto_context *pc,
> >struct drm_i915_gem_context_param *args)
> > {
> > + struct drm_i915_private *i915 = fpriv->i915;
> > int ret = 0;
> > switch (args->param) {
> > @@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
> > drm_i915_file_private *fpriv,
> > pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> > break;
> > + case I915_CONTEXT_PARAM_IS_COMPUTE:
> > + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > + ret = -EINVAL;
> > + else
> > + pc->user_flags |= BIT(UCONTEXT_COMPUTE);
> > + break;
> > +
> > case I915_CONTEXT_PARAM_RECOVERABLE:
> > if (args->size)
> > ret = -EINVAL;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > index 03bc7f9d191b..db86d6f6245f 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> > @@ -338,6 +338,7 @@ struct i915_gem_context {
> > #define UCONTEXT_BANNABLE 2
> > #define UCONTEXT_RECOVERABLE 3
> > #define UCONTEXT_PERSISTENCE 4
> > +#define UCONTEXT_COMPUTE 5
>
> What is the GuC behaviour when SLPC_CTX_FREQ_REQ_IS_COMPUTE is set for
> non-compute engines? Wondering if per intel_context is what we want instead.
> (Which could then be the i915_context_param_engines extension to mark
> individual contexts as compute strategy.)
Perhaps we should rename this? This is a freq-decision-strategy inside
GuC that is there mostly targeting compute workloads that needs lower
latency with short burst execution. But the engine itself doesn't matter.
It can
Re: [RFC] drm/i915: Support replaying GPU hangs with captured context image
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > When debugging GPU hangs Mesa developers are finding it useful to replay > the captured error state against the simulator. But due various simulator > limitations which prevent replicating all hangs, one step further is being > able to replay against a real GPU. > > This is almost doable today with the missing part being able to upload the > captured context image into the driver state prior to executing the > uploaded hanging batch and all the buffers. > > To enable this last part we add a new context parameter called > I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU > configuration pattern of being able to select which context to apply > against, paired with the actual image and its size. > > Since this is adding a new concept of debug only uapi, we hide it behind > a new kconfig option and also require activation with a module parameter. > Together with a warning banner printed at driver load, all those combined > should be sufficient to guard against inadvertently enabling the feature. > > In terms of implementation the only trivial change is shadowing of the > default state from engine to context. We also allow the legacy context > set param to be used since that removes the need to record the per context > data in the proto context, while still allowing flexibility of specifying > context images for any context. > > Mesa MR using the uapi can be seen at: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594 I just wonder if it would be better to split the default_state in a separate patch but from what I could see it looks correct. Also, I have 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 > --- > drivers/gpu/drm/i915/Kconfig.debug| 17 +++ > drivers/gpu/drm/i915/gem/i915_gem_context.c | 106 ++ > drivers/gpu/drm/i915/gt/intel_context.c | 2 + > drivers/gpu/drm/i915/gt/intel_context.h | 22 > drivers/gpu/drm/i915/gt/intel_context_types.h | 3 + > drivers/gpu/drm/i915/gt/intel_lrc.c | 8 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 8 +- > drivers/gpu/drm/i915/i915_params.c| 5 + > drivers/gpu/drm/i915/i915_params.h| 3 +- > include/uapi/drm/i915_drm.h | 27 + > 10 files changed, 194 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index 5b7162076850..32e9f70e91ed 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -16,6 +16,23 @@ config DRM_I915_WERROR > > If in doubt, say "N". > > +config DRM_I915_REPLAY_GPU_HANGS_API > + bool "Enable GPU hang replay userspace API" > + depends on DRM_I915 > + depends on EXPERT > + default n > + help > + Choose this option if you want to enable special and unstable > + userspace API used for replaying GPU hangs on a running system. > + > + This API is intended to be used by userspace graphics stack developers > + and provides no stability guarantees. > + > + The API needs to be activated at boot time using the > + enable_debug_only_api module parameter. > + > + If in doubt, say "N". > + > config DRM_I915_DEBUG > bool "Enable additional driver debugging" > depends on DRM_I915 > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > index dcbfe32fd30c..1cfd624bd978 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > @@ -78,6 +78,7 @@ > #include "gt/intel_engine_user.h" > #include "gt/intel_gpu_commands.h" > #include "gt/intel_ring.h" > +#include "gt/shmem_utils.h" > > #include "pxp/intel_pxp.h" > > @@ -949,6 +950,7 @@ static int set_proto_ctx_param(struct > drm_i915_file_private *fpriv, > case I915_CONTEXT_PARAM_NO_ZEROMAP: > case I915_CONTEXT_PARAM_BAN_PERIOD: > case I915_CONTEXT_PARAM_RINGSIZE: > + case I915_CONTEXT_PARAM_CONTEXT_IMAGE: > default: > ret = -EINVAL; > break; > @@ -2092,6 +2094,88 @@ static int get_protected(struct i915_gem_context *ctx, > return 0; > } > > +static int set_context_image(struct i915_gem_context *ctx, &g
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
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 every platform that the i915 driver
> > > supports. It is fixed on the latest platforms but they are only
> > > supported by Xe instead of i915. So just remove the platform check
> > > completely and keep the code simple.
> > Well, I was going to say that I would prefer a GMD version greater-than
> > check to be future proof. However if this code gets used in some other
> > new platform a new specific guc support would likely need to be added
> > as well right?
> There is no future for i915. That's the point. The only platforms that have
> the hardware fix are all ones that will only ever be supported by the Xe
> driver. So if such a platform were to be backported to i915 then there would
> be a lot more work than just adding a new GuC firmware platform.
>
> And going backwards, the bug affects all platforms that have a GuC. So if
> any GuC code is being executed at all, then this w/a is applicable.
>
> >
> > Perhaps at least adding a comment in the code?
> Such as this?
> /*
> * Wa_14018913170: Applicable to all platforms supported by i915.
I believe only this first line would be enough. but up to you and feel free
to put my rv-b with whatever version you get.
so
> * don't bother testing for all X/Y/Z platforms explicitly.
> */
>
> John.
>
>
> >
> > 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/intel_guc.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > index 2b450c43bbd7f..a3662edb42032 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > > @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
> > > /* Wa_14018913170 */
> > > if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> > > - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
> > > IS_PONTEVECCHIO(gt->i915))
> > > - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> > > }
> > > return flags;
> > > --
> > > 2.43.0
> > >
>
Re: [PATCH] drm/i915/tv: Fix TV mode
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:
> > > > Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed
> > > > to update all the users of the struct drm_tv_connector_state mode field,
> > > > which resulted in a build failure in i915.
> > > >
> > > > However, a subsequent commit in the same series reintroduced a mode
> > > > field in that structure, with a different semantic but the same type,
> > > > with the assumption that all previous users were updated.
> > > >
> > > > Since that didn't happen, the i915 driver now compiles, but mixes
> > > > accesses to the legacy_mode field and the newer mode field, but with the
> > > > previous semantics.
> > > >
> > > > This obviously doesn't work very well, so we need to update the accesses
> > > > that weren't in the legacy renaming commit.
> > > >
> > > > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > > > Reported-by: Ville Syrjälä
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > > > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > index 825638702ac1..5f9e748adc89 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > > > intel_sdvo *intel_sdvo,
> > > > struct intel_sdvo_tv_format format;
> > > > u32 format_map;
> > > >
> > > > - format_map = 1 << conn_state->tv.mode;
> > > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > > memset(, 0, sizeof(format));
> > > > memcpy(, _map, min(sizeof(format),
> > > > sizeof(format_map)));
> > > >
> > > > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > > > drm_connector *connector)
> > > > * Read the list of supported input resolutions for the
> > > > selected TV
> > > > * format.
> > > > */
> > > > - format_map = 1 << conn_state->tv.mode;
> > > > + format_map = 1 << conn_state->tv.legacy_mode;
> > > > memcpy(_res, _map,
> > > >min(sizeof(format_map), sizeof(struct
> > > > intel_sdvo_sdtv_resolution_request)));
> > > >
> > > > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > > > drm_connector *connector,
> > > > int i;
> > > >
> > > > for (i = 0; i <
> > > > intel_sdvo_connector->format_supported_num; i++)
> > > > - if (state->tv.mode ==
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > + if (state->tv.legacy_mode ==
> > > > intel_sdvo_connector->tv_format_supported[i]) {
> > > > *val = i;
> > > >
> > > > return 0;
> > > > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > > > drm_connector *connector,
> > > > struct intel_sdvo_connector_state *sdvo_state =
> > > > to_intel_sdvo_connector_state(state);
> > > >
> > > > if (property == intel_sdvo_connector->tv_format) {
> > > > - state->tv.mode =
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > > + state->tv.legacy_mode =
> > > > intel_sdvo_connector->tv_format_supported[val];
> > > >
> > > > if (state->crtc) {
> > > > struct drm_crtc_state *crtc_state =
> > > > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struc
Re: [PATCH] drm/i915/tv: Fix TV mode
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 resulted in a build failure in i915.
> >
> > However, a subsequent commit in the same series reintroduced a mode
> > field in that structure, with a different semantic but the same type,
> > with the assumption that all previous users were updated.
> >
> > Since that didn't happen, the i915 driver now compiles, but mixes
> > accesses to the legacy_mode field and the newer mode field, but with the
> > previous semantics.
> >
> > This obviously doesn't work very well, so we need to update the accesses
> > that weren't in the legacy renaming commit.
> >
> > Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property")
> > Reported-by: Ville Syrjälä
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/i915/display/intel_sdvo.c | 10 +-
> > drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> > 2 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > index 825638702ac1..5f9e748adc89 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct
> > intel_sdvo *intel_sdvo,
> > struct intel_sdvo_tv_format format;
> > u32 format_map;
> >
> > - format_map = 1 << conn_state->tv.mode;
> > + format_map = 1 << conn_state->tv.legacy_mode;
> > memset(, 0, sizeof(format));
> > memcpy(, _map, min(sizeof(format), sizeof(format_map)));
> >
> > @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct
> > drm_connector *connector)
> > * Read the list of supported input resolutions for the selected TV
> > * format.
> > */
> > - format_map = 1 << conn_state->tv.mode;
> > + format_map = 1 << conn_state->tv.legacy_mode;
> > memcpy(_res, _map,
> >min(sizeof(format_map), sizeof(struct
> > intel_sdvo_sdtv_resolution_request)));
> >
> > @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> > drm_connector *connector,
> > int i;
> >
> > for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> > - if (state->tv.mode ==
> > intel_sdvo_connector->tv_format_supported[i]) {
> > + if (state->tv.legacy_mode ==
> > intel_sdvo_connector->tv_format_supported[i]) {
> > *val = i;
> >
> > return 0;
> > @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> > drm_connector *connector,
> > struct intel_sdvo_connector_state *sdvo_state =
> > to_intel_sdvo_connector_state(state);
> >
> > if (property == intel_sdvo_connector->tv_format) {
> > - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> > + state->tv.legacy_mode =
> > intel_sdvo_connector->tv_format_supported[val];
> >
> > if (state->crtc) {
> > struct drm_crtc_state *crtc_state =
> > @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> > intel_sdvo *intel_sdvo,
> > drm_property_add_enum(intel_sdvo_connector->tv_format, i,
> >
> > tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
> >
> > - intel_sdvo_connector->base.base.state->tv.mode =
> > intel_sdvo_connector->tv_format_supported[0];
> > + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> > intel_sdvo_connector->tv_format_supported[0];
> > drm_object_attach_property(_sdvo_connector->base.base.base,
> >intel_sdvo_connector->tv_format, 0);
> > return true;
>
> Hmm. I didn't realize we are using this in the SDVO code as well.
> I don't *think* that one is actually broken since it has its own
> .{set,get}_property() hooks. But I suppose doing the rename
> there as well is a good idea anyway.
>
> Can you split the SDVO vs. TV into separate patches? We need to
> backport at least the TV part, and a smaller patch means less
> chance of conflicts. Or if you prefer I can chunk it up while
> pushing.
hmm ouch... I shouldn't had rushed with it, I'm sorry.
But I already merged this as is.
>
> Both parts are
> Reviewed-by: Ville Syrjälä
>
> Thanks.
>
> > diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> > b/drivers/gpu/drm/i915/display/intel_tv.c
> > index a96bcfcf90a3..2b77d399f1a1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> > @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
> >
> > static const struct tv_mode *intel_tv_mode_find(const struct
> >
Re: [PATCH] drm/i915/tv: Fix TV mode
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 resulted in a build failure in i915.
>
> However, a subsequent commit in the same series reintroduced a mode
> field in that structure, with a different semantic but the same type,
> with the assumption that all previous users were updated.
just for the record, commit 7d63cd8526f1 ("drm/connector: Add TV standard
property")
>
> Since that didn't happen, the i915 driver now compiles, but mixes
> accesses to the legacy_mode field and the newer mode field, but with the
> previous semantics.
>
> This obviously doesn't work very well, so we need to update the accesses
> that weren't in the legacy renaming commit.
>
> 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 +-
> drivers/gpu/drm/i915/display/intel_tv.c | 10 +-
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 825638702ac1..5f9e748adc89 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -1220,7 +1220,7 @@ static bool intel_sdvo_set_tv_format(struct intel_sdvo
> *intel_sdvo,
> struct intel_sdvo_tv_format format;
> u32 format_map;
>
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memset(, 0, sizeof(format));
> memcpy(, _map, min(sizeof(format), sizeof(format_map)));
>
> @@ -2323,7 +2323,7 @@ static int intel_sdvo_get_tv_modes(struct drm_connector
> *connector)
>* Read the list of supported input resolutions for the selected TV
>* format.
>*/
> - format_map = 1 << conn_state->tv.mode;
> + format_map = 1 << conn_state->tv.legacy_mode;
> memcpy(_res, _map,
> min(sizeof(format_map), sizeof(struct
> intel_sdvo_sdtv_resolution_request)));
>
> @@ -2388,7 +2388,7 @@ intel_sdvo_connector_atomic_get_property(struct
> drm_connector *connector,
> int i;
>
> for (i = 0; i < intel_sdvo_connector->format_supported_num; i++)
> - if (state->tv.mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> + if (state->tv.legacy_mode ==
> intel_sdvo_connector->tv_format_supported[i]) {
> *val = i;
>
> return 0;
> @@ -2444,7 +2444,7 @@ intel_sdvo_connector_atomic_set_property(struct
> drm_connector *connector,
> struct intel_sdvo_connector_state *sdvo_state =
> to_intel_sdvo_connector_state(state);
>
> if (property == intel_sdvo_connector->tv_format) {
> - state->tv.mode = intel_sdvo_connector->tv_format_supported[val];
> + state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[val];
>
> if (state->crtc) {
> struct drm_crtc_state *crtc_state =
> @@ -3108,7 +3108,7 @@ static bool intel_sdvo_tv_create_property(struct
> intel_sdvo *intel_sdvo,
> drm_property_add_enum(intel_sdvo_connector->tv_format, i,
>
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>
> - intel_sdvo_connector->base.base.state->tv.mode =
> intel_sdvo_connector->tv_format_supported[0];
> + intel_sdvo_connector->base.base.state->tv.legacy_mode =
> intel_sdvo_connector->tv_format_supported[0];
> drm_object_attach_property(_sdvo_connector->base.base.base,
> intel_sdvo_connector->tv_format, 0);
> return true;
> diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
> b/drivers/gpu/drm/i915/display/intel_tv.c
> index a96bcfcf90a3..2b77d399f1a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_tv.c
> +++ b/drivers/gpu/drm/i915/display/intel_tv.c
> @@ -950,7 +950,7 @@ intel_disable_tv(struct intel_atomic_state *state,
>
> static const struct tv_mode *intel_tv_mode_find(const struct
> drm_connector_state *conn_state)
> {
> - int format = conn_state->tv.mode;
> + int format = conn_state->tv.legacy_mode;
>
> return _modes[format];
> }
> @@ -1705,7 +1705,7 @@ static
Re: [PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
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 every platform that the i915 driver
> supports. It is fixed on the latest platforms but they are only
> supported by Xe instead of i915. So just remove the platform check
> completely and keep the code simple.
Well, I was going to say that I would prefer a GMD version greater-than
check to be future proof. However if this code gets used in some other
new platform a new specific guc support would likely need to be added
as well right?
Perhaps 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/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 2b450c43bbd7f..a3662edb42032 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
>
> /* Wa_14018913170 */
> if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
> - if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
> IS_PONTEVECCHIO(gt->i915))
> - flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> + flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
> }
>
> return flags;
> --
> 2.43.0
>
Re: [PATCH] drm/i915: check before removing mm notifier
On Mon, Feb 19, 2024 at 01:50:47PM +0100, Nirmoy Das wrote:
> Error in mmu_interval_notifier_insert() can leave a NULL
> notifier.mm pointer. Catch that and return early.
>
> Cc: Andi Shyti
> Cc: Shawn Lee
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 0e21ce9d3e5a..61abfb505766 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -349,6 +349,9 @@ i915_gem_userptr_release(struct drm_i915_gem_object *obj)
> {
> GEM_WARN_ON(obj->userptr.page_ref);
>
> + if (!obj->userptr.notifier.mm)
> + return;
> +
hmmm... right, it looks 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
>
Re: [PATCH] drm/i915: Fix possible null pointer dereference after drm_dbg_printer conversion
On Mon, Feb 19, 2024 at 01:14:23PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Request can be NULL if no guilty request was identified so simply use
> engine->i915 instead.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: d50892a9554c ("drm/i915: switch from 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 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 5f8d86e25993..8d4bb95f8424 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -96,8 +96,8 @@ static void heartbeat_commit(struct i915_request *rq,
> static void show_heartbeat(const struct i915_request *rq,
> struct intel_engine_cs *engine)
> {
> - struct drm_printer p = drm_dbg_printer(>i915->drm, DRM_UT_DRIVER,
> -"heartbeat");
> + struct drm_printer p =
> + drm_dbg_printer(>i915->drm, DRM_UT_DRIVER, "heartbeat");
>
> if (!rq) {
> intel_engine_dump(engine, ,
> --
> 2.40.1
>
Re: linux-next: build warning after merge of the drm tree
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'
>
> Introduced by commit
>
> d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
It should be fixed by commit 70a46e1fda3b ("drm/doc/rfc: Removing missing
reference to xe.rst")
that is part of drm-misc/drm-misc-next and drm-misc/for-linux-next
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
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 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 ("drm/sched: Drain all entities in DRM sched run job
> > > > worker")
> > First of all there's a small typo in this Fixes tag that needs to be fixed.
> > The correct one is:
> >
> > Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> > worker")
Cc: Dave Airlie
> >
> > But I couldn't apply this right now in any of our drm-tip trees because it
> > is not clear where this is coming from originally.
> >
> > likely amd tree?!
>
> No, this comes from Matthews work on the DRM scheduler.
>
> Matthews patches were most likely merged through drm-misc.
the original is not there in drm-misc-next.
it looks like Dave had taken that one directly to drm-next.
So we either need the drm-misc maintainers to have a backmerge or
Dave to take this through the drm-fixes directly.
>
> Regards,
> Christian.
>
> >
> > > > Signed-off-by: Matthew Brost
> > > Reviewed-by: Christian König
> > Christian, if this came from the amd, could you please apply it there and
> > propagate through your fixes flow?
> >
> > Thanks,
> > Rodrigo.
> >
> > > > ---
> > > >drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> > > >1 file changed, 9 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > > > b/drivers/gpu/drm/scheduler/sched_main.c
> > > > index 8acbef7ae53d..7e90c9f95611 100644
> > > > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > > > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > > > @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> > > > work_struct *w)
> > > > struct drm_sched_entity *entity;
> > > > struct dma_fence *fence;
> > > > struct drm_sched_fence *s_fence;
> > > > - struct drm_sched_job *sched_job = NULL;
> > > > + struct drm_sched_job *sched_job;
> > > > int r;
> > > > if (READ_ONCE(sched->pause_submit))
> > > > return;
> > > > /* Find entity with a ready job */
> > > > - while (!sched_job && (entity = drm_sched_select_entity(sched)))
> > > > {
> > > > - sched_job = drm_sched_entity_pop_job(entity);
> > > > - if (!sched_job)
> > > > - complete_all(>entity_idle);
> > > > - }
> > > > + entity = drm_sched_select_entity(sched);
> > > > if (!entity)
> > > > return; /* No more work */
> > > > + sched_job = drm_sched_entity_pop_job(entity);
> > > > + if (!sched_job) {
> > > > + complete_all(>entity_idle);
> > > > + drm_sched_run_job_queue(sched);
> > > > + return;
> > > > + }
> > > > +
> > > > s_fence = sched_job->s_fence;
> > > > atomic_add(sched_job->credits, >credit_count);
>
Re: [PATCH] drm/sched: Re-queue run job worker when drm_sched_entity_pop_job() returns NULL
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 ("drm/sched: Drain all entities in DRM sched run job
> > worker")
First of all there's a small typo in this Fixes tag that needs to be fixed.
The correct one is:
Fixes: 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
worker")
But I couldn't apply this right now in any of our drm-tip trees because it
is not clear where this is coming from originally.
likely amd tree?!
> > Signed-off-by: Matthew Brost
>
> Reviewed-by: Christian König
Christian, if this came from the amd, could you please apply it there and
propagate through your fixes flow?
Thanks,
Rodrigo.
>
> > ---
> > drivers/gpu/drm/scheduler/sched_main.c | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 8acbef7ae53d..7e90c9f95611 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -1178,21 +1178,24 @@ static void drm_sched_run_job_work(struct
> > work_struct *w)
> > struct drm_sched_entity *entity;
> > struct dma_fence *fence;
> > struct drm_sched_fence *s_fence;
> > - struct drm_sched_job *sched_job = NULL;
> > + struct drm_sched_job *sched_job;
> > int r;
> > if (READ_ONCE(sched->pause_submit))
> > return;
> > /* Find entity with a ready job */
> > - while (!sched_job && (entity = drm_sched_select_entity(sched))) {
> > - sched_job = drm_sched_entity_pop_job(entity);
> > - if (!sched_job)
> > - complete_all(>entity_idle);
> > - }
> > + entity = drm_sched_select_entity(sched);
> > if (!entity)
> > return; /* No more work */
> > + sched_job = drm_sched_entity_pop_job(entity);
> > + if (!sched_job) {
> > + complete_all(>entity_idle);
> > + drm_sched_run_job_queue(sched);
> > + return;
> > + }
> > +
> > s_fence = sched_job->s_fence;
> > atomic_add(sched_job->credits, >credit_count);
>
Re: [PATCH v4 1/3] drm/i915/vma: Fix UAF on destroy against retire race
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 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: > > > 88811643b958 object type: i915_active hint: > > > __i915_vma_active+0x0/0x50 [i915] > > > [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 > > > debug_print_object+0x80/0xb0 > > > ... > > > [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted > > > 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 > > > [161.360314] Hardware name: Intel Corporation Rocket Lake Client > > > Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 > > > 04/21/2022 > > > [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] > > > [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 > > > ... > > > [161.361347] debug_object_free+0xeb/0x110 > > > [161.361362] i915_active_fini+0x14/0x130 [i915] > > > [161.361866] release_references+0xfe/0x1f0 [i915] > > > [161.362543] i915_vma_parked+0x1db/0x380 [i915] > > > [161.363129] __gt_park+0x121/0x230 [i915] > > > [161.363515] intel_wakeref_put_last+0x1f/0x70 [i915] > > > > > > That has been tracked down to be happening when another thread is > > > deactivating the VMA inside __active_retire() helper, after the VMA's > > > active counter has been already decremented to 0, but before deactivation > > > of the VMA's object is reported to the object debugging tool. > > > > > > We could prevent from that race by serializing i915_active_fini() with > > > __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from > > > being used, e.g. from __i915_vma_retire() called at the end of > > > __active_retire(), after that VMA has been already freed by a concurrent > > > i915_vma_destroy() on return from the i915_active_fini(). Then, we should > > > rather fix the issue at the VMA level, not in i915_active. > > > > > > Since __i915_vma_parked() is called from __gt_park() on last put of the > > > GT's wakeref, the issue could be addressed by holding the GT wakeref long > > > enough for __active_retire() to complete before that wakeref is released > > > and the GT parked. > > > > > > A VMA associated with a request doesn't acquire a GT wakeref by itself. > > > Instead, it depends on a wakeref held directly by the request's active > > > intel_context for a GT associated with its VM, and indirectly on that > > > intel_context's engine wakeref if the engine belongs to the same GT as the > > > VMA's VM. In case of single-tile platforms, at least one of those > > > wakerefs is usually held long enough for the request's VMA to be > > > deactivated on time, before it is destroyed on last put of its VM GT > > > wakeref. However, on multi-tile platforms, a request may use a VMA from a > > > tile other than the one that hosts the request's engine, then it is > > > protected only with the intel_context's VM GT wakeref. > > > > > > There was an attempt to fix this issue on 2-tile Meteor Lake by acquiring > > > > please do not confuse the terminology here. MTL is 1-tile platform, > > with multiple GTs (1 for Render/Compute and 1 for Media). > > I didn't realize that "tile" is not the same as "GT". I can review the whole > description and replace all occurrences of "tile" with "GT". yeap, in i915 it is a 1-1 map... a tile is implemented within the intel_gt. In Xe there's a good split and a good doc picture is here: https://dri.freedesktop.org/docs/drm/gpu/driver-uapi.html#drm-xe-uapi > > > > > Also you could probably avoid mentioning the other case here when > > you are actively trying to resolve the RKL's single GT case. > > OK, but let me keep that part of commit description in the cover letter then, > because: > - historically, the issue was more frequently reproduced in CI on MTL than on > other platforms, and that was the initial scope I started working on, > - the full description as is better reflects phases of my process of > reproduction and root cause analysis of the issue, > - the MTL case was specif
Re: [PATCH v4 2/3] Manually revert "drm/i915: Fix a VMA UAF for multi-gt platform"
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 do a 'manually revert'? revert itself didn't apply?
maybe you could avoid the word 'revert' and use something like
Remove extra multi-gt pm-references... or something like that.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d3a771afb083e..cedca8fd8754d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2686,7 +2686,6 @@ static int
> eb_select_engine(struct i915_execbuffer *eb)
> {
> struct intel_context *ce, *child;
> - struct intel_gt *gt;
> unsigned int idx;
> int err;
>
> @@ -2710,17 +2709,10 @@ eb_select_engine(struct i915_execbuffer *eb)
> }
> }
> eb->num_batches = ce->parallel.number_children + 1;
> - gt = ce->engine->gt;
>
> for_each_child(ce, child)
> intel_context_get(child);
> eb->wakeref = intel_gt_pm_get(ce->engine->gt);
> - /*
> - * Keep GT0 active on MTL so that i915_vma_parked() doesn't
> - * free VMAs while execbuf ioctl is validating VMAs.
> - */
> - if (gt->info.id)
> - eb->wakeref_gt0 = intel_gt_pm_get(to_gt(gt->i915));
>
> if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
> err = intel_context_alloc_state(ce);
> @@ -2759,9 +2751,6 @@ eb_select_engine(struct i915_execbuffer *eb)
> return err;
>
> err:
> - if (gt->info.id)
> - intel_gt_pm_put(to_gt(gt->i915), eb->wakeref_gt0);
> -
> intel_gt_pm_put(ce->engine->gt, eb->wakeref);
> for_each_child(ce, child)
> intel_context_put(child);
> @@ -2775,12 +2764,6 @@ eb_put_engine(struct i915_execbuffer *eb)
> struct intel_context *child;
>
> i915_vm_put(eb->context->vm);
> - /*
> - * This works in conjunction with eb_select_engine() to prevent
> - * i915_vma_parked() from interfering while execbuf validates vmas.
> - */
> - if (eb->gt->info.id)
> - intel_gt_pm_put(to_gt(eb->gt->i915), eb->wakeref_gt0);
> intel_gt_pm_put(eb->context->engine->gt, eb->wakeref);
> for_each_child(eb->context, child)
> intel_context_put(child);
> --
> 2.43.0
>
Re: [PATCH v4 1/3] drm/i915/vma: Fix UAF on destroy against retire race
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: 88811643b958
> object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
> [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514
> debug_print_object+0x80/0xb0
> ...
> [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted
> 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1
> [161.360314] Hardware name: Intel Corporation Rocket Lake Client
> Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138
> 04/21/2022
> [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]
> [161.360592] RIP: 0010:debug_print_object+0x80/0xb0
> ...
> [161.361347] debug_object_free+0xeb/0x110
> [161.361362] i915_active_fini+0x14/0x130 [i915]
> [161.361866] release_references+0xfe/0x1f0 [i915]
> [161.362543] i915_vma_parked+0x1db/0x380 [i915]
> [161.363129] __gt_park+0x121/0x230 [i915]
> [161.363515] intel_wakeref_put_last+0x1f/0x70 [i915]
>
> That has been tracked down to be happening when another thread is
> deactivating the VMA inside __active_retire() helper, after the VMA's
> active counter has been already decremented to 0, but before deactivation
> of the VMA's object is reported to the object debugging tool.
>
> We could prevent from that race by serializing i915_active_fini() with
> __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from
> being used, e.g. from __i915_vma_retire() called at the end of
> __active_retire(), after that VMA has been already freed by a concurrent
> i915_vma_destroy() on return from the i915_active_fini(). Then, we should
> rather fix the issue at the VMA level, not in i915_active.
>
> Since __i915_vma_parked() is called from __gt_park() on last put of the
> GT's wakeref, the issue could be addressed by holding the GT wakeref long
> enough for __active_retire() to complete before that wakeref is released
> and the GT parked.
>
> A VMA associated with a request doesn't acquire a GT wakeref by itself.
> Instead, it depends on a wakeref held directly by the request's active
> intel_context for a GT associated with its VM, and indirectly on that
> intel_context's engine wakeref if the engine belongs to the same GT as the
> VMA's VM. In case of single-tile platforms, at least one of those
> wakerefs is usually held long enough for the request's VMA to be
> deactivated on time, before it is destroyed on last put of its VM GT
> wakeref. However, on multi-tile platforms, a request may use a VMA from a
> tile other than the one that hosts the request's engine, then it is
> protected only with the intel_context's VM GT wakeref.
>
> There was an attempt to fix this issue on 2-tile Meteor Lake by acquiring
please do not confuse the terminology here. MTL is 1-tile platform,
with multiple GTs (1 for Render/Compute and 1 for Media).
Also you could probably avoid mentioning the other case here when
you are actively trying to resolve the RKL's single GT case.
> an extra wakeref for a Primary GT from i915_gem_do_execbuffer() -- see
> commit f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform").
> However, it occurred insufficient -- the issue was still reported by CI.
> That wakeref was released on exit from i915_gem_do_execbuffer(), then
> potentially before completion of the request and deactivation of its
> associated VMAs.
>
> OTOH, CI reports indicate that single-tile platforms also suffer
> sporadically from the same race.
>
> I believe the issue was introduced by commit d93939730347 ("drm/i915:
> Remove the vma refcount") which moved a call to i915_active_fini() from
> a dropped i915_vma_release(), called on last put of the removed VMA kref,
> to i915_vma_parked() processing path called on last put of a GT wakeref.
> However, its visibility to the object debugging tool was suppressed by a
> bug in i915_active that was fixed two weeks later with commit e92eb246feb9
> ("drm/i915/active: Fix missing debug object activation").
>
> Fix the issue by getting a wakeref for the VMA's tile when activating it,
> and putting that wakeref only after the VMA is deactivated. However,
> exclude global GTT from that processing path, otherwise the GPU never goes
> idle. Since __i915_vma_retire() may be called from atomic contexts, use
> async variant of wakeref put.
okay, this explains the first block of the patch below, but I'm afraid
that it doesn't explain why:
- if (flags & PIN_GLOBAL)
>
> v4: Refresh on top of commit 5e4e06e4087e ("drm/i915: Track gt pm
> wakerefs") (Andi),
> - for more easy backporting, split out removal of former insufficient
> workarounds and move them to separate patches (Nirmoy).
> - clean up commit message and description a bit.
> v3: Identify root cause more precisely, and a commit to blame,
Re: [PATCH] drm/doc/rfc: Removing missing reference to xe.rst
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 reference was missed behind.
> >
> > Gentle ping on this one.
> > I should have mentioned here that this fixes a doc build warning:
> >
> > Documentation/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
> > nonexisting document 'gpu/rfc/xe'
> >
> > >
> > > Fixes: d11dc7aa98e5 ("drm/doc/rfc: Remove Xe's pre-merge plan")
> > > Cc: Lucas De Marchi
> > > Signed-off-by: Rodrigo Vivi
> Reviewed-by: Matthew Auld
Thank you for the prompt request.
pushed to drm-misc-next
Re: [PATCH] drm/doc/rfc: Removing missing reference to xe.rst
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/gpu/rfc/index.rst:35: WARNING: toctree contains reference to
nonexisting document 'gpu/rfc/xe'
>
> 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 changed, 4 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
> index e4f7b005138d..476719771eef 100644
> --- a/Documentation/gpu/rfc/index.rst
> +++ b/Documentation/gpu/rfc/index.rst
> @@ -31,7 +31,3 @@ host such documentation:
> .. toctree::
>
> i915_vm_bind.rst
> -
> -.. toctree::
> -
> - xe.rst
> --
> 2.43.0
>
[PATCH] drm/doc/rfc: Removing missing reference to xe.rst
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 changed, 4 deletions(-)
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index e4f7b005138d..476719771eef 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -31,7 +31,3 @@ host such documentation:
.. toctree::
i915_vm_bind.rst
-
-.. toctree::
-
- xe.rst
--
2.43.0
Re: [PATCH] drm/doc/rfc: Remove Xe's pre-merge plan
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 that Xe is part of drm-next and it includes the > > display portion, let's entirely kill this RFC here. > > > > Cc: Lucas De Marchi > > Cc: Thomas Hellström > > Cc: Oded Gabbay > > Signed-off-by: Rodrigo Vivi > > > Acked-by: Lucas De Marchi Thanks, pushed to drm-misc-next. > > thanks > Lucas De Marchi > > > --- > > 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.. > > --- a/Documentation/gpu/rfc/xe.rst > > +++ /dev/null > > @@ -1,234 +0,0 @@ > > -== > > -Xe – Merge Acceptance Plan > > -== > > -Xe is a new driver for Intel GPUs that supports both integrated and > > -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). > > - > > -This document aims to establish a merge plan for the Xe, by writing down > > clear > > -pre-merge goals, in order to avoid unnecessary delays. > > - > > -Xe – Overview > > -= > > -The main motivation of Xe is to have a fresh base to work from that is > > -unencumbered by older platforms, whilst also taking the opportunity to > > -rearchitect our driver to increase sharing across the drm subsystem, both > > -leveraging and allowing us to contribute more towards other shared > > components > > -like TTM and drm/scheduler. > > - > > -This is also an opportunity to start from the beginning with a clean uAPI > > that is > > -extensible by design and already aligned with the modern userspace needs. > > For > > -this reason, the memory model is solely based on GPU Virtual Address space > > -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only > > supporting > > -explicit synchronization. With persistent mapping across the execution, the > > -userspace does not need to provide a list of all required mappings during > > each > > -submission. > > - > > -The new driver leverages a lot from i915. As for display, the intent is to > > share > > -the display code with the i915 driver so that there is maximum reuse there. > > - > > -As for the power management area, the goal is to have a much-simplified > > support > > -for the system suspend states (S-states), PCI device suspend states > > (D-states), > > -GPU/Render suspend states (R-states) and frequency management. It should > > leverage > > -as much as possible all the existent PCI-subsystem infrastructure (pm and > > -runtime_pm) and underlying firmware components such PCODE and GuC for the > > power > > -states and frequency decisions. > > - > > -Repository: > > - > > -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) > > - > > -Xe – Platforms > > -== > > -Currently, Xe is already functional and has experimental support for > > multiple > > -platforms starting from Tiger Lake, with initial support in userspace > > implemented > > -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in > > NEO > > -(for OpenCL and Level0). > > - > > -During a transition period, platforms will be supported by both Xe and > > i915. > > -However, the force_probe mechanism existent in both drivers will allow > > only one > > -official and by-default probe at a given time. > > - > > -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead > > of > > -i915, the following set of parameters need to be used: > > - > > -``` > > -i915.force_probe=!5690 xe.force_probe=5690 > > -``` > > - > > -In both drivers, the ‘.require_force_probe’ protection forces the user to > > use the > > -force_probe parameter while the driver is under development. This > > protection is > > -only removed when the support for the platform and the uAPI are stable. > > Stability > > -which needs to be demonstrated by CI results. > > - > > -In order to avoid user space regressions, i915 will continue to support > > all the > > -cur
[PATCH] drm/doc/rfc: Remove Xe's pre-merge plan
The last TODO item here that was not marked as done was the display portion, which came along with the pull-request. So, now that Xe is part of drm-next and it includes the display portion, let's entirely kill this RFC here. Cc: Lucas De Marchi Cc: Thomas Hellström Cc: Oded Gabbay Signed-off-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.. --- a/Documentation/gpu/rfc/xe.rst +++ /dev/null @@ -1,234 +0,0 @@ -== -Xe – Merge Acceptance Plan -== -Xe is a new driver for Intel GPUs that supports both integrated and -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). - -This document aims to establish a merge plan for the Xe, by writing down clear -pre-merge goals, in order to avoid unnecessary delays. - -Xe – Overview -= -The main motivation of Xe is to have a fresh base to work from that is -unencumbered by older platforms, whilst also taking the opportunity to -rearchitect our driver to increase sharing across the drm subsystem, both -leveraging and allowing us to contribute more towards other shared components -like TTM and drm/scheduler. - -This is also an opportunity to start from the beginning with a clean uAPI that is -extensible by design and already aligned with the modern userspace needs. For -this reason, the memory model is solely based on GPU Virtual Address space -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting -explicit synchronization. With persistent mapping across the execution, the -userspace does not need to provide a list of all required mappings during each -submission. - -The new driver leverages a lot from i915. As for display, the intent is to share -the display code with the i915 driver so that there is maximum reuse there. - -As for the power management area, the goal is to have a much-simplified support -for the system suspend states (S-states), PCI device suspend states (D-states), -GPU/Render suspend states (R-states) and frequency management. It should leverage -as much as possible all the existent PCI-subsystem infrastructure (pm and -runtime_pm) and underlying firmware components such PCODE and GuC for the power -states and frequency decisions. - -Repository: - -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) - -Xe – Platforms -== -Currently, Xe is already functional and has experimental support for multiple -platforms starting from Tiger Lake, with initial support in userspace implemented -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO -(for OpenCL and Level0). - -During a transition period, platforms will be supported by both Xe and i915. -However, the force_probe mechanism existent in both drivers will allow only one -official and by-default probe at a given time. - -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of -i915, the following set of parameters need to be used: - -``` -i915.force_probe=!5690 xe.force_probe=5690 -``` - -In both drivers, the ‘.require_force_probe’ protection forces the user to use the -force_probe parameter while the driver is under development. This protection is -only removed when the support for the platform and the uAPI are stable. Stability -which needs to be demonstrated by CI results. - -In order to avoid user space regressions, i915 will continue to support all the -current platforms that are already out of this protection. Xe support will be -forever experimental and dependent on the usage of force_probe for these -platforms. - -When the time comes for Xe, the protection will be lifted on Xe and kept in i915. - -Xe – Pre-Merge Goals - Work-in-Progress -=== - -Display integration with i915 -- -In order to share the display code with the i915 driver so that there is maximum -reuse, the i915/display/ code is built twice, once for i915.ko and then for -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' -depending on the build target. The goal is to refactor both Xe and i915/display -code simultaneously in order to get a clean result before they land upstream, so -that display can already be part of the initial pull request towards drm-next. - -However, display code should not gate the acceptance of Xe in upstream. Xe -patches will be refactored in a way that display code can be removed, if needed, -from the first pull request of Xe towards drm-next. The expectation is that when -both drivers are part of the drm-tip, the introduction of cleaner patches will be -easier and speed up. - -Xe – uAPI high level overview -= - -...Warning: To be done in follow
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
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 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 > > > Cc: Lucas De Marchi > > > Cc: Oded Gabbay > > > Cc: daniel.vet...@ffwll.ch > > > Cc: Maarten Lankhorst > > > Cc: dim-to...@lists.freedesktop.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: intel-...@lists.freedesktop.org > > > Signed-off-by: Thomas Hellström > > > --- > > > nightly.conf | 7 +++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/nightly.conf b/nightly.conf > > > index 24126b61b797..accd3ff2cc39 100644 > > > --- a/nightly.conf > > > +++ b/nightly.conf > > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > > > https://anongit.freedesktop.org/git/drm/drm-tip > > > https://anongit.freedesktop.org/git/drm/drm-tip.git > > > " > > > +drm_tip_repos[drm-xe]=" > > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > > > +https://gitlab.freedesktop.org/drm/xe/kernel.git > > > +" > > > drm_tip_repos[drm-intel]=" > > > ssh://git.freedesktop.org/git/drm/drm-intel > > > ssh://git.freedesktop.org/git/drm-intel > > > @@ -65,14 +69,17 @@ drm_tip_config=( > > > "drmdrm-fixes" > > > "drm-misc drm-misc-fixes" > > > "drm-intel drm-intel-fixes" > > > + "drm-xe drm-xe-fixes" > > > > > > "drmdrm-next" > > > "drm-misc drm-misc-next-fixes" > > > "drm-intel drm-intel-next-fixes" > > > + "drm-xe drm-xe-next-fixes" > > > > > > "drm-misc drm-misc-next" > > > "drm-intel drm-intel-next" > > > "drm-intel drm-intel-gt-next" > > > + "drm-xe drm-xe-next b6e1b7081768" > > > > yeap, up to this commit nothing else should change, but > > then we will need an extra rebase of the rest on top of drm/drm-next. > > > > But then we need to decide where these following patches will live: > > 880277f31cc69 drm/xe/guc: define LNL FW > > 2cfc5ae1b8267 drm/xe/guc: define PVC FW > > 52383b58eb8cf mei/hdcp: Also enable for XE > > bea27d7369855 mei: gsc: add support for auxiliary device created by > > Xe driver > > fcb3410197f05 fault-inject: Include linux/types.h by default. > > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs > > > > > > Will it be the topic/core-for-CI? > > or topic/xe-extras? > > or what? > > This sounds to me like topic/core-for-CI? Or is there any drawback with > that? > > > > > Anyway, for the inclusion like this, after our CI is ready: > > Could we merge this patch already at this point, considering it will, > at least for now, only update drm-tip with our fixes? yeap, likely a good idea. Acked-by: Rodrigo Vivi But we just move the final drm-xe-next after figuring out the topic branches and the final rebases fixing the tags and the commiter's s-o-b and the fixes tags. > > Thanks, > > /Thomas > > > > > > Acked-by: Rodrigo Vivi > > > > > > > > "drm-intel topic/core-for-CI" > > > "drm-misc topic/i915-ttm" > > > -- > > > 2.42.0 > > > >
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
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: > > > > 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 > > > > Cc: Lucas De Marchi > > > > Cc: Oded Gabbay > > > > Cc: daniel.vet...@ffwll.ch > > > > Cc: Maarten Lankhorst > > > > Cc: dim-to...@lists.freedesktop.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: intel-...@lists.freedesktop.org > > > > Signed-off-by: Thomas Hellström > > > > --- > > > > nightly.conf | 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/nightly.conf b/nightly.conf > > > > index 24126b61b797..accd3ff2cc39 100644 > > > > --- a/nightly.conf > > > > +++ b/nightly.conf > > > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > > > > https://anongit.freedesktop.org/git/drm/drm-tip > > > > https://anongit.freedesktop.org/git/drm/drm-tip.git > > > > " > > > > +drm_tip_repos[drm-xe]=" > > > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > > > > +https://gitlab.freedesktop.org/drm/xe/kernel.git > > > > +" > > > > drm_tip_repos[drm-intel]=" > > > > ssh://git.freedesktop.org/git/drm/drm-intel > > > > ssh://git.freedesktop.org/git/drm-intel > > > > @@ -65,14 +69,17 @@ drm_tip_config=( > > > > "drmdrm-fixes" > > > > "drm-misc drm-misc-fixes" > > > > "drm-intel drm-intel-fixes" > > > > + "drm-xe drm-xe-fixes" > > > > > > > > "drmdrm-next" > > > > "drm-misc drm-misc-next-fixes" > > > > "drm-intel drm-intel-next-fixes" > > > > + "drm-xe drm-xe-next-fixes" > > > > > > > > "drm-misc drm-misc-next" > > > > "drm-intel drm-intel-next" > > > > "drm-intel drm-intel-gt-next" > > > > + "drm-xe drm-xe-next b6e1b7081768" > > > > > > yeap, up to this commit nothing else should change, but > > > then we will need an extra rebase of the rest on top of drm/drm-next. > > > > > > But then we need to decide where these following patches will live: > > > 880277f31cc69 drm/xe/guc: define LNL FW > > > 2cfc5ae1b8267 drm/xe/guc: define PVC FW > > > 52383b58eb8cf mei/hdcp: Also enable for XE > > > bea27d7369855 mei: gsc: add support for auxiliary device created by > > > Xe driver > > > fcb3410197f05 fault-inject: Include linux/types.h by default. > > > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs > > > > > > > > > Will it be the topic/core-for-CI? > > > or topic/xe-extras? > > > or what? > > > > This sounds to me like topic/core-for-CI? Or is there any drawback with > > that? > > I think some of them are not really a "for CI". It's more like the > workflow we are adopting e.g. with guc/huc, not sending it to linux-firmware > until we are confident on what version we will start officially > supporting. yeap, I kind of agree here, but at the same time it is our way to run our CI with the firmware blobs that we need while not final, and also this was already used for i915's MTL firmware. > > This one can't go to topic/core-for-CI neither: > fcb3410197f05 fault-inject: Include linux/types.h by default. > > what it would do would be that we would not see the build error anymore, > but everyone else would (and it's not a CI-only configuration). > Unless it's merged to another branch, we shouldn't merge it. yeap. it is sad that we were ignored there. let's just drop this then. our driver is workarounding this bug anyway already. > > "52383b58eb8cf mei/hdcp: Also enable for XE" could be material for > topic/core-for-CI and "8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs" > could either be on that branch or another xe-specific one. yeap. For the MEI we probably need to ping Greg on the original submission and ask his ack so we can put that in the final drm-xe-next for good and not even include in a topic branch. for the PVC IDs, the topic branch could be okay as well. But if we end up with an exclusive branch for xe, then it is better there. > > > > > > > > > Anyway, for the inclusion like this, after our CI is ready: > > > > Could we merge this patch already at this point, considering it will, > > at least for now, only update drm-tip with our fixes? > > ack > > Lucas De Marchi > > > > > Thanks, > > > > /Thomas > > > > > > > > > > Acked-by: Rodrigo Vivi > > > > > > > > > > > "drm-intel topic/core-for-CI" > > > > "drm-misc topic/i915-ttm" > > > > -- > > > > 2.42.0 > > > > > >
Re: [PATCH] nightly.conf: Add the xe repo to drm-tip
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 > Cc: Lucas De Marchi > Cc: Oded Gabbay > Cc: daniel.vet...@ffwll.ch > Cc: Maarten Lankhorst > Cc: dim-to...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Signed-off-by: Thomas Hellström > --- > nightly.conf | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/nightly.conf b/nightly.conf > index 24126b61b797..accd3ff2cc39 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip > https://anongit.freedesktop.org/git/drm/drm-tip.git > " > +drm_tip_repos[drm-xe]=" > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git > +https://gitlab.freedesktop.org/drm/xe/kernel.git > +" > drm_tip_repos[drm-intel]=" > ssh://git.freedesktop.org/git/drm/drm-intel > ssh://git.freedesktop.org/git/drm-intel > @@ -65,14 +69,17 @@ drm_tip_config=( > "drmdrm-fixes" > "drm-misc drm-misc-fixes" > "drm-intel drm-intel-fixes" > + "drm-xe drm-xe-fixes" > > "drmdrm-next" > "drm-misc drm-misc-next-fixes" > "drm-intel drm-intel-next-fixes" > + "drm-xe drm-xe-next-fixes" > > "drm-misc drm-misc-next" > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > + "drm-xe drm-xe-next b6e1b7081768" yeap, up to this commit nothing else should change, but then we will need an extra rebase of the rest on top of drm/drm-next. But then we need to decide where these following patches will live: 880277f31cc69 drm/xe/guc: define LNL FW 2cfc5ae1b8267 drm/xe/guc: define PVC FW 52383b58eb8cf mei/hdcp: Also enable for XE bea27d7369855 mei: gsc: add support for auxiliary device created by Xe driver fcb3410197f05 fault-inject: Include linux/types.h by default. 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs Will it be the topic/core-for-CI? or topic/xe-extras? or what? Anyway, for the inclusion like this, after our CI is ready: Acked-by: Rodrigo Vivi > > "drm-intel topic/core-for-CI" > "drm-misc topic/i915-ttm" > -- > 2.42.0 >
[PULL] drm-xe-next-fixes
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 -next-fixes branch. Thanks, Rodrigo. The following changes since commit 92242716ee92d2aa3c38c736b53d8910d443566d: Merge tag 'drm-habanalabs-next-2023-12-19' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next (2023-12-22 14:52:04 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-next-fixes-2023-12-26 for you to fetch changes up to 315acff5196f4e2f84a2a2d093000e0c6b0b4d1c: drm/xe: Fix warning on impossible condition (2023-12-26 12:53:26 -0500) - Fix couple unfined behavior cases to calm UBSAN and clang (Matt Brost, Lucas) Lucas De Marchi (1): drm/xe: Fix warning on impossible condition Matthew Brost (1): drm/xe: Fix UBSAN splat in add_preempt_fences() drivers/gpu/drm/xe/xe_vm.c | 3 +++ drivers/gpu/drm/xe/xe_wait_user_fence.c | 1 + 2 files changed, 4 insertions(+)
Re: [PATCH 4/4] drm/i915/perf: reconcile Excess struct member kernel-doc warnings
On Wed, Dec 20, 2023 at 07:20:29PM -0800, Randy Dunlap wrote:
> Document nested struct members with full names as described in
> Documentation/doc-guide/kernel-doc.rst.
>
> i915_perf_types.h:341: warning: Excess struct member 'ptr_lock' description
> in 'i915_perf_stream'
> i915_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: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: intel-...@lists.freedesktop.org
> Cc: Jonathan Corbet
> Cc: dri-devel@lists.freedesktop.org
for the series:
Reviewed-by: Rodrigo Vivi
I'm afraid patchwork was down when you sent this out.
Could you please rebase and resend? Just to ensure
our CI doesn't complain and then we push it.
Thanks,
Rodrigo.
> ---
> drivers/gpu/drm/i915/i915_perf_types.h |9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff -- a/drivers/gpu/drm/i915/i915_perf_types.h
> b/drivers/gpu/drm/i915/i915_perf_types.h
> --- a/drivers/gpu/drm/i915/i915_perf_types.h
> +++ b/drivers/gpu/drm/i915/i915_perf_types.h
> @@ -291,7 +291,8 @@ struct i915_perf_stream {
> int size_exponent;
>
> /**
> - * @ptr_lock: Locks reads and writes to all head/tail state
> + * @oa_buffer.ptr_lock: Locks reads and writes to all
> + * head/tail state
>*
>* Consider: the head and tail pointer state needs to be read
>* consistently from a hrtimer callback (atomic context) and
> @@ -313,7 +314,8 @@ struct i915_perf_stream {
> spinlock_t ptr_lock;
>
> /**
> - * @head: Although we can always read back the head pointer
> register,
> + * @oa_buffer.head: Although we can always read back
> + * the head pointer register,
>* we prefer to avoid trusting the HW state, just to avoid any
>* risk that some hardware condition could * somehow bump the
>* head pointer unpredictably and cause us to forward the wrong
> @@ -322,7 +324,8 @@ struct i915_perf_stream {
> u32 head;
>
> /**
> - * @tail: The last verified tail that can be read by userspace.
> + * @oa_buffer.tail: The last verified tail that can be
> + * read by userspace.
>*/
> u32 tail;
> } oa_buffer;
Re: [PATCH v8 2/2] drm/i915/guc: Close deregister-context race against CT-loss
On Wed, Dec 20, 2023 at 11:08:59PM +, Teres Alexis, Alan Previn wrote: > On Wed, 2023-12-13 at 16:23 -0500, Vivi, Rodrigo wrote: > > On Tue, Dec 12, 2023 at 08:57:16AM -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 flush). > alan:snip > > > > > Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_- > > > contexts if guc_lrc_desc_unpin fails due to CT send falure. > > > When unrolling, keep the context in the GuC's destroy-list so > > > it can get picked up on the next destroy worker invocation > > > (if suspend 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, patience and great work! > > > > Reviewed-by: Rodrigo Vivi > > alan: Thanks Rodrigo for the RB last week, just quick update: > > I've cant reproduce the BAT failures that seem to be intermittent > on platform and test - however, a noticable number of failures > do keep occuring on i915_selftest @live @requests where the > last test leaked a wakeref and the failing test hangs waiting > for gt to idle before starting its test. > > i have to debug this further although from code inspection > is unrelated to the patches in this series. > Hopefully its a different issue. Yeap, likely not related. Anyway, I'm sorry for not merging this sooner. Could you please send a rebased version? This on is not applying cleanly anymore.
Re: [PATCH 1/6] drm/xe: Disable 32bits build
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 > --- > drivers/gpu/drm/xe/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig > index 5b3da06e7ba3..a53b0fdc15a7 100644 > --- a/drivers/gpu/drm/xe/Kconfig > +++ b/drivers/gpu/drm/xe/Kconfig > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0-only > config DRM_XE > tristate "Intel Xe Graphics" > - depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) > + depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT > select INTERVAL_TREE > # we need shmfs for the swappable backing store, and in particular > # the shmem_readpage() which depends upon tmpfs > -- > 2.40.1 >
[PULL] drm-xe-next v4
rly and use at earlier point in probe drm/xe: Map the entire BAR0 and hold onto the initial mapping drm/xe/device: Introduce xe_device_probe_early drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity 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 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 on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB into its own struct. drm/xe: Convert GuC CT print to snapshot capture and print. drm/xe: Add GuC CT snapshot to xe_devcoredump. drm/xe: Introduce guc_submit_types.h with relevant structs. drm/xe: Convert GuC Engine print to snapshot capture and print. drm/xe: Add GuC Submit Engine snapshot to xe_devcoredump. drm/xe: Convert Xe HW Engine print to snapshot capture and print. drm/xe: Add HW Engine snapshot to xe_devcoredump. drm/xe: Limit CONFIG_DRM_XE_SIMPLE_ERROR_CAPTURE to itself. drm/xe/uapi: Remove XE_QUERY_CONFIG_FLAGS_USE_GUC drm/xe: Invert guc vs execlists parameters and info. drm/xe: Fix an invalid locking wait context bug drm/xe: Inv
[PULL] drm-xe-next v3
drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity 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 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 on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB into its own struct. drm/xe: Convert GuC CT print to snapshot capture and print. drm/xe: Add GuC CT snapshot to xe_devcoredump. drm/xe: Introduce guc_submit_types.h with relevant structs. drm/xe: Convert GuC Engine print to snapshot capture and print. drm/xe: Add GuC Submit Engine snapshot to xe_devcoredump. drm/xe: Convert Xe HW Engine print to snapshot capture and print. drm/xe: Add HW Engine snapshot to xe_devcoredump. drm/xe: Limit CONFIG_DRM_XE_SIMPLE_ERROR_CAPTURE to itself. drm/xe/uapi: Remove XE_QUERY_CONFIG_FLAGS_USE_GUC drm/xe: Invert guc vs execlists parameters and info. drm/xe: Fix an invalid locking wait context bug drm/xe: Invert mask and val in xe_mmio_wait32. drm/xe: Only set PCI d3cold_allowed when we are really allowing. drm/xe: Move d3cold_allowed decision all together.
[PULL] drm-xe-next v2
tside of MMIO setup drm/xe: Move xe_mmio_probe_tiles outside of MMIO setup drm/xe: Split xe_info_init drm/xe: Introduce xe_tile_init_early and use at earlier point in probe drm/xe: Map the entire BAR0 and hold onto the initial mapping drm/xe/device: Introduce xe_device_probe_early drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity 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 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 on xe_mmio_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB into its own struct. drm/xe: Convert GuC CT print to snapshot capture and print. drm/xe: Add GuC CT snapshot to xe_devcoredump. drm/xe: Introduce guc_submit_types.h with relevant structs. drm/xe: Convert GuC Engine print to snapshot capture and print. drm/xe: Add GuC Submit Engine snapshot to xe_devcoredump. drm/xe: Convert Xe HW Engine print to snapshot capture and print. drm/xe: Add HW Engine snapshot to xe_devcoredump. drm/xe: Limit CONFIG_DRM_XE_SIMPLE_ERROR_CAPTURE to itself. drm/xe/uapi: Remove XE_QUERY_C
[PULL] drm-intel-next
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 Lake bug (Jani) - Bigjoiner fixes (Ankit, Ville) - Cdclk/voltage_level cleanups and fixes (Ville) - DMC event stuff (Ville) - Remove dead code around intel_atomic_helper->free_list (Jouni) Thanks, Rodrigo. The following changes since commit 10690b8a49bceafb1badf0ad91842a359e796d8b: drm/i915/display: Add intel_fb_bo_framebuffer_fini (2023-12-07 17:31:02 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-12-18 for you to fetch changes up to 716c3cf21784479a1934b670ec67f320cbb5d308: drm/i915/display: Remove dead code around intel_atomic_helper->free_list (2023-12-18 13:37:01 +0200) - 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 Lake bug (Jani) - Bigjoiner fixes (Ankit, Ville) - Cdclk/voltage_level cleanups and fixes (Ville) - DMC event stuff (Ville) - Remove dead code around intel_atomic_helper->free_list (Jouni) Andrzej Hajda (1): drm/i915/display: do not use cursor size reduction on MTL Ankit Nautiyal (1): drm/i915/display: Get bigjoiner config before dsc config during readout Imre Deak (1): drm/i915/mtl: Fix HDMI/DP PLL clock selection Jani Nikula (1): drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select Jouni Högander (1): drm/i915/display: Remove dead code around intel_atomic_helper->free_list Mika Kahola (1): drm/i915/display: Wait for PHY readiness not needed for disabling sequence Radhakrishna Sripada (3): drm/i915/mtl: Use port clock compatible numbers for C20 phy drm/i915/mtl: Remove misleading "clock" field from C20 pll_state drm/i915/mtl: Rename the link_bit_rate to clock in C20 pll_state Ville Syrjälä (24): drm/i915: Fix remapped stride with CCS on ADL+ drm/i915: Fix intel_atomic_setup_scalers() plane_state handling drm/i915: Streamline intel_dsc_pps_read() drm/i915: Drop redundant NULL check drm/i915: Drop crtc NULL check from intel_crtc_active() drm/i915: Drop NULL fb check from intel_fb_uses_dpt() drm/i915: Drop redunant null check from intel_get_frame_time_us() drm/i915: s/cstate/crtc_state/ in intel_get_frame_time_us() drm/i915/tv: Drop redundant null checks drm/i915: Stop accessing crtc->state from the flip done irq drm/i915: Drop irqsave/restore for flip_done_handler() drm/i915: Reject async flips with bigjoiner drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values drm/i915/cdclk: Give the squash waveform length a name drm/i915/cdclk: Remove the assumption that cdclk divider==2 when using squashing drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables drm/i915/mtl: Fix voltage_level for cdclk==480MHz drm/i915: Split intel_ddi_compute_min_voltage_level() into platform variants drm/i915/mtl: Calculate the correct voltage level from port_clock drm/i915: Simplify intel_ddi_compute_min_voltage_level() drm/i915/dmc: Don't enable any pipe DMC events drm/i915/dmc: Also disable the flip queue event on TGL main DMC drm/i915/dmc: Also disable HRR event on TGL/ADLS main DMC drm/i915/dmc: Print out the DMC mmio register list at fw load time drivers/gpu/drm/i915/display/i9xx_wm.c | 2 +- drivers/gpu/drm/i915/display/intel_bios.c | 3 +- drivers/gpu/drm/i915/display/intel_cdclk.c | 111 ++-- drivers/gpu/drm/i915/display/intel_crtc.c | 9 +- drivers/gpu/drm/i915/display/intel_cx0_phy.c | 82 +--- drivers/gpu/drm/i915/display/intel_ddi.c | 48 +-- drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 33 ++--- drivers/gpu/drm/i915/display/intel_display_core.h | 6 - .../gpu/drm/i915/display/intel_display_device.h| 2 +- .../gpu/drm/i915/display/intel_display_driver.c| 7 - drivers/gpu/drm/i915/display/intel_display_irq.c | 15 +-- drivers/gpu/drm/i915/display/intel_display_types.h | 6 +- drivers/gpu/drm/i915/display/intel_dmc.c | 147 ++--- drivers/gpu/drm/i915/display/intel_dmc_regs.h | 1 + .../gpu/drm/i915/display/intel_dp_link_training.c | 31 +++-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +- drivers/gpu/drm/i915/display/intel_fb.c| 18 ++- drivers/gpu/drm/i915/display/intel_psr.c |
[PULL] drm-xe-next
nfig drm/xe: Introduce SR-IOV logging macros drm/xe/pf: Introduce Local Memory Translation Table drm/xe/kunit: Enable CONFIG_PCI_IOV in .kunitconfig drm/xe/kunit: Add test for LMTT operations Michał Winiarski (21): drm/xe: Fix uninitialized variables drm/xe: Fix check for platform without geometry pipeline drm/xe: Fix header guard warning drm/xe: Skip calling drm_dev_put on probe error drm/xe: Use managed pci_enable_device drm/xe/irq: Don't call pci_free_irq_vectors drm/xe: Move xe_set_dma_info outside of MMIO setup drm/xe: Move xe_mmio_probe_tiles outside of MMIO setup drm/xe: Split xe_info_init drm/xe: Introduce xe_tile_init_early and use at earlier point in probe drm/xe: Map the entire BAR0 and hold onto the initial mapping drm/xe/device: Introduce xe_device_probe_early drm/xe: Don't "peek" into GMD_ID drm/xe: Move system memory management init to earlier point in probe drm/xe: Move force_wake init to earlier point in probe drm/xe: Reorder GGTT init to earlier point in probe drm/xe: Add a helper for DRM device-lifetime BO create drm/xe/uc: Split xe_uc_fw_init drm/xe/uc: Store firmware binary in system-memory backed BO drm/xe/uc: Extract xe_uc_sanitize_reset drm/xe/guc: Split GuC params used for "hwconfig" and "post-hwconfig" Mika Kuoppala (4): drm/xe: destroy clients engine and vm xarrays on close drm/xe: Fix unreffed ptr leak on engine lookup drm/xe: Extend drm_xe_vm_bind_op drm/xe/vm: Avoid asid lookup if none allocated Niranjana Vishwanathapura (16): drm/xe/migrate: Fix number of PT structs in docbook drm/xe/tests: Use proper batch base address drm/xe/tests: Set correct expectation drm/xe: Use proper vram offset drm/xe: Fix memory use after free drm/xe: Handle -EDEADLK case in preempt worker drm/xe: Handle -EDEADLK case in exec ioctl drm/xe: Apply upper limit to sg element size drm/xe: Simplify engine class sched_props setting drm/xe: Add CONFIG_DRM_XE_PREEMPT_TIMEOUT drm/xe/pvc: Blacklist BCS_SWCTRL register drm/xe/pvc: Force even num engines to use 64B drm/xe/pvc: Use fast copy engines as migrate engine on PVC drm/xe: Enable Fixed CCS mode setting drm/xe: Allow userspace to configure CCS mode drm/xe: Avoid any races around ccs_mode update Nirmoy Das (3): drm/xe/stolen: Exclude reserved lmem portion drm/xe: Do not sleep in atomic drm/xe: Print GT info on TLB inv failure Oak Zeng (3): drm/xe: Implement HW workaround 14016763929 drm/xe: Make xe_mem_region struct drm/xe: Improve vram info debug printing Ohad Sharabi (1): drm/xe: do not register to PM if GuC is disabled Pallavi Mishra (5): drm/xe: Prevent return with locked vm drm/xe: Align size to PAGE_SIZE drm/xe: Dump CTB during TLB timeout drm/xe/tests: Fix migrate test drm/xe/uapi: Add support for CPU caching mode Paulo Zanoni (5): drm/xe: fix bounds checking for 'len' in xe_engine_create_ioctl drm/xe: properly check bounds for xe_wait_user_fence_ioctl() drm/xe/vm: print the correct 'keep' when printing gpuva ops drm/xe/vm: use list_last_entry() to fetch last_op drm/xe: fix range printing for debug messages Philippe Lecluse (4): drm/xe: enforce GSMBASE for DG1 instead of BAR2 drm/xe: fix xe_mmio_total_vram_size drm/xe: Fix Meteor Lake rsa issue on guc loading drm/xe/mocs: add MTL mocs Priyanka Dandamudi (1): drm/xe/xe_exec_queue: Add check for access counter granularity 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 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_wait32. drm/xe: Convert guc_ready to regular xe_mmio_wait32 drm/xe: Wait for success on guc done. drm/xe: Remove i915_utils dependency from xe_guc_pc. drm/xe: Stop using i915_utils in xe_wopcm. drm/xe: Let's avoid i915_utils in the xe_force_wake. drm/xe: Convert xe_mmio_wait32 to us so we can stop using wait_for_us. drm/xe: Remove i915_utils dependency from xe_pcode. drm/xe/guc_pc: Fix Meteor Lake registers. drm/xe: Remove unseless xe_force_wake_prune. drm/xe: Update comment on why d3cold is still blocked. drm/xe: Fix print of RING_EXECLIST_SQ_CONTENTS_HI drm/xe: Introduce the dev_coredump infrastructure. drm/xe: Do not take any action if our device was removed. drm/xe: Extract non mapped regions out of GuC CTB
Re: [PATCH topic/core-for-CI] perf: Fix perf_event_validate_size() lockdep splat
On Fri, Dec 15, 2023 at 08:22:17AM -0800, Lucas De Marchi wrote:
> From: Mark Rutland
>
> When lockdep is enabled, the for_each_sibling_event(sibling, event)
> macro checks that event->ctx->mutex is held. When creating a new group
> leader event, we call perf_event_validate_size() on a partially
> initialized event where event->ctx is NULL, and so when
> for_each_sibling_event() attempts to check event->ctx->mutex, we get a
> splat, as reported by Lucas De Marchi:
>
> WARNING: CPU: 8 PID: 1471 at kernel/events/core.c:1950
> __do_sys_perf_event_open+0xf37/0x1080
>
> This only happens for a new event which is its own group_leader, and in
> this case there cannot be any sibling events. Thus it's safe to skip the
> check for siblings, which avoids having to make invasive and ugly
> changes to for_each_sibling_event().
>
> Avoid the splat by bailing out early when the new event is its own
> group_leader.
>
> Fixes: 382c27f4ed28f803 ("perf: Fix perf_event_validate_size()")
> Closes:
> https://lore.kernel.org/lkml/20231214000620.3081018-1-lucas.demar...@intel.com/
> Closes: 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.com
> [ cherry pick from tip/urgent heading to 6.7-rc6 ]
> Signed-off-by: Lucas De Marchi
Acked-by: Rodrigo Vivi
> ---
> kernel/events/core.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index acfc5a569818..a64165af45c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1947,6 +1947,16 @@ static bool perf_event_validate_size(struct perf_event
> *event)
> group_leader->nr_siblings + 1) > 16*1024)
> return false;
>
> + /*
> + * When creating a new group leader, group_leader->ctx is initialized
> + * after the size has been validated, but we cannot safely use
> + * for_each_sibling_event() until group_leader->ctx is set. A new group
> + * leader cannot have any siblings yet, so we can safely skip checking
> + * the non-existent siblings.
> + */
> + if (event == group_leader)
> + return true;
> +
> for_each_sibling_event(sibling, group_leader) {
> if (__perf_event_read_size(sibling->attr.read_format,
> group_leader->nr_siblings + 1) >
> 16*1024)
> --
> 2.40.1
>
Re: [PATCH v8 2/2] drm/i915/guc: Close deregister-context race against CT-loss
On Tue, Dec 12, 2023 at 08:57:16AM -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 flush).
>
> Thus, when suspending, insert rcu_barriers at the start
> of i915_gem_suspend (part of driver's suspend prepare) and
> again in i915_gem_suspend_late so that all such cases have
> completed and context destruction list isn't missing anything.
>
> In destroyed_worker_func, close the race against CT-loss
> by checking that CT is enabled before calling into
> deregister_destroyed_contexts.
>
> Based on testing, guc_lrc_desc_unpin may still race and fail
> as we traverse the GuC's context-destroy list because the
> CT could be disabled right before calling GuC's CT send function.
>
> We've witnessed this race condition once every ~6000-8000
> suspend-resume cycles while ensuring workloads that render
> something onscreen is continuously started just before
> we suspend (and the workload is small enough to complete
> and trigger the queued engine/context free-up either very
> late in suspend or very early in resume).
>
> In such a case, we need to unroll the entire process because
> guc-lrc-unpin takes a gt wakeref which only gets released in
> the G2H IRQ reply that never comes through in this corner
> case. Without the unroll, the taken wakeref is leaked and will
> cascade into a kernel hang later at the tail end of suspend in
> this function:
>
>intel_wakeref_wait_for_idle(>wakeref)
>(called by) - intel_gt_pm_wait_for_idle
>(called by) - wait_for_suspend
>
> Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_-
> contexts if guc_lrc_desc_unpin fails due to CT send falure.
> When unrolling, keep the context in the GuC's destroy-list so
> it can get picked up on the next destroy worker invocation
> (if suspend 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, patience and great work!
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 73 +--
> 2 files changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..3b27218aabe2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private *i915)
> GEM_TRACE("%s\n", dev_name(i915->drm.dev));
>
> intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
> + /*
> + * On rare occasions, we've observed the fence completion triggers
> + * free_engines asynchronously via rcu_call. Ensure those are done.
> + * This path is only called on suspend, so it's an acceptable cost.
> + */
> + rcu_barrier();
> +
> flush_workqueue(i915->wq);
>
> /*
> @@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
>* machine in an unusable condition.
>*/
>
> + /* Like i915_gem_suspend, flush tasks staged from fence triggers */
> + rcu_barrier();
> +
> for_each_gt(gt, i915, i)
> intel_gt_suspend_late(gt);
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 9c64ae0766cc..cae637fc3ead 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -236,6 +236,13 @@ set_context_destroyed(struct intel_context *ce)
> ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
> }
>
> +static inline void
> +clr_context_destroyed(struct intel_context *ce)
> +{
> + lockdep_assert_held(>guc_state.lock);
> + ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
> +}
> +
> static inline bool context_pending_disable(struct intel_context *ce)
> {
> return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
> @@ -613,6 +620,8 @@ static int guc_submission_send_busy_loop(struct intel_guc
> *guc,
>u32 g2h_len_dw,
>bool loop)
> {
> + int ret;
> +
> /*
>* We always loop when a send requires a
[PATCH] MAINTAINERS: Updates to Intel DRM
Introduce the Maintainers of the new drm/xe driver for upcoming Intel GPUs. Since it has a shared display with drm/i915, let's also create a dedicated block to group display related files. But without any substantial change to the i915 side. The display patches will continue to flow through i915 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 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d4b46b3db022..8b5e3c27bca6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10640,7 +10640,17 @@ L: linux-ker...@vger.kernel.org S: Supported F: arch/x86/include/asm/intel-family.h -INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) +INTEL DRM DISPLAY FOR XE AND I915 DRIVERS +M: Jani Nikula +M: Rodrigo Vivi +L: intel-...@lists.freedesktop.org +L: intel...@lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/i915/display/ +F: drivers/gpu/drm/xe/display/ +F: drivers/gpu/drm/xe/compat-i915-headers + +INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older excluding Poulsbo, Moorestown and derivative) M: Jani Nikula M: Joonas Lahtinen M: Rodrigo Vivi @@ -10659,6 +10669,23 @@ F: drivers/gpu/drm/i915/ F: include/drm/i915* F: include/uapi/drm/i915_drm.h +INTEL DRM XE DRIVER (Lunar Lake and newer) +M: Lucas De Marchi +M: Oded Gabbay +M: Thomas Hellström +L: intel...@lists.freedesktop.org +S: Supported +W: https://drm.pages.freedesktop.org/intel-docs/ +Q: http://patchwork.freedesktop.org/project/intel-xe/ +B: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues +C: irc://irc.oftc.net/xe +T: git https://gitlab.freedesktop.org/drm/xe/kernel.git +F: Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon +F: Documentation/gpu/xe/ +F: drivers/gpu/drm/xe/ +F: include/drm/xe* +F: include/uapi/drm/xe_drm.h + INTEL ETHERNET DRIVERS M: Jesse Brandeburg M: Tony Nguyen -- 2.43.0
[PATCH 11/13] drm/sched: Reverse run-queue priority enumeration
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
DRM_SCHED_PRIORITY_COUNT number of run-queues, should always schedule
sched->sched_rq[0] with the same "priority", as that index run-queue exists in
both schedulers, i.e. a scheduler with one run-queue or many. This patch makes
it so.
In other words, the "priority" of sched->sched_rq[n], n >= 0, is the same for
any scheduler created with any allowable number of run-queues (priorities), 0
to DRM_SCHED_PRIORITY_COUNT.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20231124052752.6915-6-ltuiko...@gmail.com
(cherry picked from commit 38f922a563aac3148ac73e73689805917f034cb5)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 5 +++--
drivers/gpu/drm/scheduler/sched_main.c | 15 +++
include/drm/gpu_scheduler.h | 6 +++---
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 1a25931607c5..71a5cf37b472 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
+ for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index eb0c97433e5f..2bfcb222e353 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_LOW -
DRM_SCHED_PRIORITY_HIGH)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index dd2b8f777f51..3c4f5a392b06 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -82,13 +82,14 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
pr_warn("%s: called with uninitialized scheduler\n", __func__);
} else if (num_sched_list) {
/* The "priority" of an entity cannot exceed the number of
run-queues of a
-* scheduler. Protect against num_rqs being 0, by converting to
signed.
+* scheduler. Protect against num_rqs being 0, by converting to
signed. Choose
+* the lowest priority available.
*/
if (entity->priority >= sched_list[0]->num_rqs) {
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
-(s32) DRM_SCHED_PRIORITY_LOW);
+(s32)
DRM_SCHED_PRIORITY_KERNEL);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b6d7bc49ff6e..682aebe96db7 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1051,8 +1051,9 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
struct drm_sched_entity *entity;
int i;
- /* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
+ /* Start with the highest priority.
+*/
+ for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
[PATCH 10/13] drm/sched: Rename priority MIN to LOW
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 Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20231124052752.6915-5-ltuiko...@gmail.com
(cherry picked from commit fe375c74806dbd30b00ec038a80a5b7bf4653ab7)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 10 +-
include/drm/gpu_scheduler.h | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index fb050345b9f2..d46786618061 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -68,10 +68,10 @@ amdgpu_ctx_to_drm_sched_prio(int32_t ctx_prio)
return DRM_SCHED_PRIORITY_NORMAL;
case AMDGPU_CTX_PRIORITY_VERY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_NORMAL:
return DRM_SCHED_PRIORITY_NORMAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 62bb7fc7448a..1a25931607c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 4252e3839fbc..eb0c97433e5f 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_MIN)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index ee645d38e98d..dd2b8f777f51 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -88,7 +88,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
-(s32) DRM_SCHED_PRIORITY_MIN);
+(s32) DRM_SCHED_PRIORITY_LOW);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 044a8c4875ba..b6d7bc49ff6e 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1052,7 +1052,7 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
int i;
/* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
drm_sched_rq_select_entity_rr(sched,
sched->sched_rq[i]);
@@ -1291,7 +1291,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
if (!sched->sched_rq)
goto Out_free;
sched->num_rqs = num_rqs;
- for (i = DRM_SCHED_PRIORITY_MIN; i < sched->num_rqs; i++) {
+ for (i =
[PULL] drm-intel-next
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 display debug msgs and other general clean-ups (Ville, Rahuul) - PSR fixes and improvements around selective fetch (Jouni, Ville) - Remove FBC restrictions for Xe2LPD displays (Vinod) - Skip some timing checks on BXT/GLK DSI transcoders (Ville) - DP MST Fixes (Ville) - Correct the input parameter on _intel_dsb_commit (heminhong) - Fix IP version of the display WAs (Bala) - DGFX uses direct VBT pin mapping (Clint) - Proper handling of bool on PIPE_CONF_CHECK macros (Jani) - Skip state verification with TBT-ALT mod (Mika Kahona) - General organization of display code for reusage with Xe (Jouni, Luca, Jani, Maarten) - Squelch a sparse warning (Jani) - Don't use "proxy" headers (Andy Shevchenko) - Use devm_gpiod_get() for all GPIOs (Hans) - Fix ADL+ tiled plane stride (Ville) - Use octal permissions in display debugfs (Jani) Thanks, Rodrigo. The following changes since commit deac453244d309ad7a94d0501eb5e0f9d8d1f1df: drm/i915: Fix glk+ degamma LUT conversions (2023-11-23 15:11:47 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-12-07 for you to fetch changes up to 10690b8a49bceafb1badf0ad91842a359e796d8b: drm/i915/display: Add intel_fb_bo_framebuffer_fini (2023-12-07 17:31:02 +0200) - Improve display debug msgs and other general clean-ups (Ville, Rahuul) - PSR fixes and improvements around selective fetch (Jouni, Ville) - Remove FBC restrictions for Xe2LPD displays (Vinod) - Skip some timing checks on BXT/GLK DSI transcoders (Ville) - DP MST Fixes (Ville) - Correct the input parameter on _intel_dsb_commit (heminhong) - Fix IP version of the display WAs (Bala) - DGFX uses direct VBT pin mapping (Clint) - Proper handling of bool on PIPE_CONF_CHECK macros (Jani) - Skip state verification with TBT-ALT mod (Mika Kahona) - General organization of display code for reusage with Xe (Jouni, Luca, Jani, Maarten) - Squelch a sparse warning (Jani) - Don't use "proxy" headers (Andy Shevchenko) - Use devm_gpiod_get() for all GPIOs (Hans) - Fix ADL+ tiled plane stride (Ville) - Use octal permissions in display debugfs (Jani) Andy Shevchenko (1): drm/i915/display: Don't use "proxy" headers Balasubramani Vivekanandan (1): drm/i915/display: Fix IP version of the WAs Clint Taylor (1): drm/i915/dgfx: DGFX uses direct VBT pin mapping Hans de Goede (1): drm/i915/dsi: Use devm_gpiod_get() for all GPIOs Jani Nikula (7): drm/i915: use PIPE_CONF_CHECK_BOOL() for bool members drm/i915: add bool type checks in PIPE_CONF_CHECK_* drm/i915/syncmap: squelch a sparse warning drm/i915/rpm: add rpm_to_i915() helper around container_of() drm/i915: use intel_connector in intel_connector_debugfs_add() drm/i915: pass struct intel_connector to connector debugfs fops drm/i915: use octal permissions in display debugfs Jouni Högander (9): drm/i915/psr: Move plane sel fetch configuration into plane source files drm/i915/psr: Add proper handling for disabling sel fetch for planes drm/i915/display: split i915 specific code from intel_fbdev drm/i915/display: use intel_bo_to_drm_bo in intel_fbdev drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c drm/i915/display: Convert intel_fb_modifier_to_tiling as non-static drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling drm/i915/display: Split i915 specific code away from intel_fb.c drm/i915/display: Add intel_fb_bo_framebuffer_fini Luca Coelho (1): drm/i915: handle uncore spinlock when not available Maarten Lankhorst (1): drm/i915/display: Use i915_gem_object_get_dma_address to get dma address Mika Kahola (1): drm/i915/display: Skip state verification with TBT-ALT mode Rahul Rameshbabu (1): drm/i915/irq: Improve error logging for unexpected DE Misc interrupts Ville Syrjälä (8): drm/i915: Stop printing pipe name as hex drm/i915: Move the SDP split debug spew to the correct place drm/i915/psr: Include some basic PSR information in the state dump drm/i915: Skip some timing checks on BXT/GLK DSI transcoders drm/i915/mst: Fix .mode_valid_ctx() return values drm/i915/mst: Reject modes that require the bigjoiner drm/i915: Clean up some DISPLAY_VER checks drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller than the original Vinod Govindapillai (1): drm/i915/xe2lpd: remove the FBC restriction if PSR2 is enabled heminhong (1): drm/i915: correct the input
[PATCH 5/5] drm/doc/rfc: Xe is using drm_exec, so mark as completed
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..97cf87578f97 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -85,6 +85,14 @@ from the first pull request of Xe towards drm-next. The expectation is that when both drivers are part of the drm-tip, the introduction of cleaner patches will be easier and speed up. +Xe – uAPI high level overview += + +...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. + +Xe – Pre-Merge Goals - Completed + + Drm_exec Helper to make dma_resv locking for a big number of buffers is getting removed in @@ -99,14 +107,6 @@ This item ties into the GPUVA, VM_BIND, and even long-running compute support. As a key measurable result, we need to have a community consensus documented in this document and the Xe driver prepared for the changes, if necessary. -Xe – uAPI high level overview -= - -...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. - -Xe – Pre-Merge Goals - Completed - - Userptr integration and vm_bind --- Different drivers implement different ways of dealing with execution of userptr. -- 2.43.0
[PATCH 4/5] drm/doc/rfc: Move userptr integration and vm_bind to the 'completed' section
The must-have part of the documentation was already added to the existing /gpu/drm-vm-bind-async. The other extra discussion around GPUVM helpers are currently active in the community. None of those discussion should block Xe since documentation, specially around locking was completed 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 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -70,38 +70,6 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915 Xe – Pre-Merge Goals - Work-in-Progress === -Userptr integration and vm_bind -Different drivers implement different ways of dealing with execution of userptr. -With multiple drivers currently introducing support to VM_BIND, the goal is to -aim for a DRM consensus on what’s the best way to have that support. To some -extent this is already getting addressed itself with the GPUVA where likely the -userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. -However, there are more aspects around the rules for that and the usage of -mmu_notifiers, locking and other aspects. - -This task here has the goal of introducing a documentation of the basic rules. - -The documentation *needs* to first live in this document (API session below) and -then moved to another more specific document or at Xe level or at DRM level. - -Documentation should include: - - * The userptr part of the VM_BIND api. - - * Locking, including the page-faulting case. - - * O(1) complexity under VM_BIND. - -The document is now included in the drm documentation :doc:`here `. - -Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when -the second driver supporting VM_BIND+userptr appears. Details to be defined when -the time comes. - -The DRM GPUVM helpers do not yet include the userptr parts, but discussions -about implementing them are ongoing. - Display integration with i915 - In order to share the display code with the i915 driver so that there is maximum @@ -139,6 +107,38 @@ Xe – uAPI high level overview Xe – Pre-Merge Goals - Completed +Userptr integration and vm_bind +--- +Different drivers implement different ways of dealing with execution of userptr. +With multiple drivers currently introducing support to VM_BIND, the goal is to +aim for a DRM consensus on what’s the best way to have that support. To some +extent this is already getting addressed itself with the GPUVA where likely the +userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. +However, there are more aspects around the rules for that and the usage of +mmu_notifiers, locking and other aspects. + +This task here has the goal of introducing a documentation of the basic rules. + +The documentation *needs* to first live in this document (API session below) and +then moved to another more specific document or at Xe level or at DRM level. + +Documentation should include: + + * The userptr part of the VM_BIND api. + + * Locking, including the page-faulting case. + + * O(1) complexity under VM_BIND. + +The document is now included in the drm documentation :doc:`here `. + +Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when +the second driver supporting VM_BIND+userptr appears. Details to be defined when +the time comes. + +The DRM GPUVM helpers do not yet include the userptr parts, but discussions +about implementing them are ongoing. + ASYNC VM_BIND - Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -- 2.43.0
[PATCH 2/5] drm/doc/rfc: Mark drm_scheduler as completed
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 --- Documentation/gpu/rfc/xe.rst | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index 2a5132327617..9f3afab6c06a 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -70,24 +70,6 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915 Xe – Pre-Merge Goals - Work-in-Progress === -Drm_scheduler -- -Xe primarily uses Firmware based scheduling (GuC FW). However, it will use -drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to -resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is -not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and -drm_sched_entity. - -Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but -some consensus needs to be reached between Xe and other community drivers that -could also benefit from this work, for coupling FW based/assisted submission such -as the ARM’s new Mali GPU driver, and others. - -As a key measurable result, the patch series introducing Xe itself shall not -depend on any other patch touching drm_scheduler itself that was not yet merged -through drm-misc. This, by itself, already includes the reach of an agreement for -uniform 1 to 1 relationship implementation / usage across drivers. - ASYNC VM_BIND - Although having a common DRM level IOCTL for VM_BIND is not a requirement to get @@ -169,6 +151,24 @@ Xe – uAPI high level overview Xe – Pre-Merge Goals - Completed +Drm_scheduler +- +Xe primarily uses Firmware based scheduling (GuC FW). However, it will use +drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to +resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is +not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and +drm_sched_entity. + +Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but +some consensus needs to be reached between Xe and other community drivers that +could also benefit from this work, for coupling FW based/assisted submission such +as the ARM’s new Mali GPU driver, and others. + +As a key measurable result, the patch series introducing Xe itself shall not +depend on any other patch touching drm_scheduler itself that was not yet merged +through drm-misc. This, by itself, already includes the reach of an agreement for +uniform 1 to 1 relationship implementation / usage across drivers. + Long running compute: minimal data structure/scaffolding The generic scheduler code needs to include the handling of endless compute -- 2.43.0
[PATCH 0/5] Update xe.rst RFC doc
Let's move more items from the 'WIP' section to the 'Completed' one. When Xe was an initial experiment we had written down our goals and promises in this RFC with the goal to work with and contribute back to key common DRM items such as drm_scheduler, gpuvm, drm_exec, and establish documentations and community consensus around other new items like vm_bind async usage and its interaction with userptr and locking primitives and rules, as well as long-running workloads with drm_scheduler, etc. As well as other plans like devcoredump and i915 display re-usage. We are so thankful for this great community and the great discussions, reviews and cross contributions we got so far on this journey. Thank you all. Most of this checklist is already completed. We're finalizing some last minute cleanups on the uAPI and will be sharing the first pull request shortly. Meanwhile, the Display team is also working to finalize the few remaining patches to have a clean re-usage of i915 display. Please notice that this is actually a formal item in this xe.rst RFC, but also it is a non-blocking one. Hopefully we will be able to align the Display for a common pull request. But with the possibility 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 drm_scheduler as completed drm/doc/rfc: Move Xe 'ASYNC VM_BIND' to the 'completed' section drm/doc/rfc: Move userptr integration and vm_bind to the 'completed' section drm/doc/rfc: Xe is using drm_exec, so mark as completed Documentation/gpu/rfc/xe.rst | 127 +-- 1 file changed, 62 insertions(+), 65 deletions(-) -- 2.43.0
[PATCH 3/5] drm/doc/rfc: Move Xe 'ASYNC VM_BIND' to the 'completed' section
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 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index 9f3afab6c06a..87dd620aea59 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -70,18 +70,6 @@ When the time comes for Xe, the protection will be lifted on Xe and kept in i915 Xe – Pre-Merge Goals - Work-in-Progress === -ASYNC VM_BIND -- -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to have a consensus with other drivers and Mesa. -It needs to be clear how to handle async VM_BIND and interactions with userspace -memory fences. Ideally with helper support so people don't get it wrong in all -possible ways. - -As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of -various flavors, error handling and sample API suggestions are documented in -:doc:`The ASYNC VM_BIND document `. - Userptr integration and vm_bind --- Different drivers implement different ways of dealing with execution of userptr. @@ -151,6 +139,18 @@ Xe – uAPI high level overview Xe – Pre-Merge Goals - Completed +ASYNC VM_BIND +- +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get +Xe merged, it is mandatory to have a consensus with other drivers and Mesa. +It needs to be clear how to handle async VM_BIND and interactions with userspace +memory fences. Ideally with helper support so people don't get it wrong in all +possible ways. + +As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of +various flavors, error handling and sample API suggestions are documented in +:doc:`The ASYNC VM_BIND document `. + Drm_scheduler - Xe primarily uses Firmware based scheduling (GuC FW). However, it will use -- 2.43.0
[PATCH 1/5] drm/doc/rfc: Mark long running workload as complete.
From: Matthew Brost No DRM scheduler changes required, drivers just return NULL in run_job vfunc. The rough consensus is that no helper or extra scaffolding is needed around long-running jobs and no further changes to drm-scheduler. At least for now. Other drivers that currently do long-running workloads have no plat to use drm-scheduler. Besides, the current consensus is that this solution of simply returning NULL to the run_job function should work without extra code duplication or complication. On top of that, this item was already a non-blocking one for upstreaming Xe, so let's move 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 --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst index ceb21219d52e..2a5132327617 100644 --- a/Documentation/gpu/rfc/xe.rst +++ b/Documentation/gpu/rfc/xe.rst @@ -132,21 +132,6 @@ the time comes. The DRM GPUVM helpers do not yet include the userptr parts, but discussions about implementing them are ongoing. -Long running compute: minimal data structure/scaffolding - -The generic scheduler code needs to include the handling of endless compute -contexts, with the minimal scaffolding for preempt-ctx fences (probably on the -drm_sched_entity) and making sure drm_scheduler can cope with the lack of job -completion fence. - -The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with -this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any -drm driver, including Xe, could re-use and add their own individual needs on top -in a next stage. However, this should not block the initial merge. - -This is a non-blocker item since the driver without the support for the long -running compute enabled is not a showstopper. - Display integration with i915 - In order to share the display code with the i915 driver so that there is maximum @@ -184,6 +169,18 @@ Xe – uAPI high level overview Xe – Pre-Merge Goals - Completed +Long running compute: minimal data structure/scaffolding + +The generic scheduler code needs to include the handling of endless compute +contexts, with the minimal scaffolding for preempt-ctx fences (probably on the +drm_sched_entity) and making sure drm_scheduler can cope with the lack of job +completion fence. + +The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with +this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any +drm driver, including Xe, could re-use and add their own individual needs on top +in a next stage. However, this should not block the initial merge. + Dev_coredump -- 2.43.0
Re: [PATCH v7 2/2] drm/i915/guc: Close deregister-context race against CT-loss
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 flush).
>
> Thus, when suspending, insert rcu_barriers at the start
> of i915_gem_suspend (part of driver's suspend prepare) and
> again in i915_gem_suspend_late so that all such cases have
> completed and context destruction list isn't missing anything.
>
> In destroyed_worker_func, close the race against CT-loss
> by checking that CT is enabled before calling into
> deregister_destroyed_contexts.
>
> Based on testing, guc_lrc_desc_unpin may still race and fail
> as we traverse the GuC's context-destroy list because the
> CT could be disabled right before calling GuC's CT send function.
>
> We've witnessed this race condition once every ~6000-8000
> suspend-resume cycles while ensuring workloads that render
> something onscreen is continuously started just before
> we suspend (and the workload is small enough to complete
> and trigger the queued engine/context free-up either very
> late in suspend or very early in resume).
>
> In such a case, we need to unroll the entire process because
> guc-lrc-unpin takes a gt wakeref which only gets released in
> the G2H IRQ reply that never comes through in this corner
> case. Without the unroll, the taken wakeref is leaked and will
> cascade into a kernel hang later at the tail end of suspend in
> this function:
>
>intel_wakeref_wait_for_idle(>wakeref)
>(called by) - intel_gt_pm_wait_for_idle
>(called by) - wait_for_suspend
>
> Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_-
> contexts if guc_lrc_desc_unpin fails due to CT send falure.
> When unrolling, keep the context in the GuC's destroy-list so
> it can get picked up on the next destroy worker invocation
> (if suspend 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
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 73 +--
> 2 files changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..3b27218aabe2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private *i915)
> GEM_TRACE("%s\n", dev_name(i915->drm.dev));
>
> intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
> + /*
> + * On rare occasions, we've observed the fence completion triggers
> + * free_engines asynchronously via rcu_call. Ensure those are done.
> + * This path is only called on suspend, so it's an acceptable cost.
> + */
> + rcu_barrier();
> +
> flush_workqueue(i915->wq);
>
> /*
> @@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
>* machine in an unusable condition.
>*/
>
> + /* Like i915_gem_suspend, flush tasks staged from fence triggers */
> + rcu_barrier();
> +
> for_each_gt(gt, i915, i)
> intel_gt_suspend_late(gt);
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 6e3fb2fcce4f..a7228bebec39 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -236,6 +236,13 @@ set_context_destroyed(struct intel_context *ce)
> ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
> }
>
> +static inline void
> +clr_context_destroyed(struct intel_context *ce)
> +{
> + lockdep_assert_held(>guc_state.lock);
> + ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
> +}
> +
> static inline bool context_pending_disable(struct intel_context *ce)
> {
> return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
> @@ -613,6 +620,8 @@ static int guc_submission_send_busy_loop(struct intel_guc
> *guc,
>u32 g2h_len_dw,
>bool loop)
> {
> + int ret;
> +
> /*
>* We always loop when a send requires a reply (i.e. g2h_len_dw > 0),
>* so we don't handle the case where we don't get a reply because we
> @@ -623,7 +632,11 @@ static int guc_submission_send_busy_loop(struct
> intel_guc *guc,
> if (g2h_len_dw)
> atomic_inc(>outstanding_submission_g2h);
>
> - return intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
> + ret = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
> + if (ret)
> + atomic_dec(>outstanding_submission_g2h);
> +
> +
Re: [Intel-xe] [PATCH v5] Documentation/gpu: VM_BIND locking document
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 > > > intended to be part of the xe driver upstreaming agreement. > > > > > > The document describes and discuss the locking used during exec- > > > functions, evicton and for userptr gpu-vmas. Intention is to be > > > using the > > > same nomenclature as the drm-vm-bind-async.rst. > > > > > > v2: > > > - s/gvm/gpu_vm/g (Rodrigo Vivi) > > > - Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c > > > (Rodrigo Vivi) > > > - Adjust commit message accordingly. > > > - Add SPDX license header. > > > > > > v3: > > > - Large update to align with the drm_gpuvm manager locking > > > - Add "Efficient userptr gpu_vma exec function iteration" section > > > - Add "Locking at bind- and unbind time" section. > > > > > > v4: > > > - Fix tabs vs space errors by untabifying (Rodrigo Vivi) > > > - Minor style fixes and typos (Rodrigo Vivi) > > > - Clarify situations where stale GPU mappings are occurring and how > > > access through these mappings are blocked. (Rodrigo Vivi) > > > - Insert into the toctree in implementation_guidelines.rst > > > > > > v5: > > > - Add a section about recoverable page-faults. > > > - Use local references to other documentation where possible > > > (Bagas Sanjaya) > > > - General documentation fixes and typos (Danilo Krummrich and > > > Boris Brezillon) > > > - Improve the documentation around locks that need to be grabbed > > > from the > > > dm-fence critical section (Boris Brezillon) > > > - Add more references to the DRM GPUVM helpers (Danilo Krummrich > > > and > > > Boriz Brezillon) > > > - Update the rfc/xe.rst document. > > > > > > Cc: Rodrigo Vivi > > > Signed-off-by: Thomas Hellström > > > > First of all, with Bagas and Boris latest suggestions, already few > > free to use: > > > > Reviewed-by: Rodrigo Vivi > > > > But a few minor comments below. Mostly trying to address Boris > > feeling > > of long sentences. However, take them with a grain of salt since I'm > > not > > a native english speaker. :) > > Hi, Rodrigo. > > Thanks for the reviewing. I've added most but not all of the > suggestions in v6. Regarding the comment about "zapping", that's used > by the core mm for the process of unmapping page-table entries; > zap_vma_ptes() etc. Merely following that, although I'm not really > against using unmapping etc. Perfect then. No concerns from my side. Thanks, Rodrigo. > > /Thomas >
Re: [PATCH v6 2/2] drm/i915/guc: Close deregister-context race against CT-loss
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 flush).
>
> Thus, when suspending, insert rcu_barriers at the start
> of i915_gem_suspend (part of driver's suspend prepare) and
> again in i915_gem_suspend_late so that all such cases have
> completed and context destruction list isn't missing anything.
>
> In destroyed_worker_func, close the race against CT-loss
> by checking that CT is enabled before calling into
> deregister_destroyed_contexts.
>
> Based on testing, guc_lrc_desc_unpin may still race and fail
> as we traverse the GuC's context-destroy list because the
> CT could be disabled right before calling GuC's CT send function.
>
> We've witnessed this race condition once every ~6000-8000
> suspend-resume cycles while ensuring workloads that render
> something onscreen is continuously started just before
> we suspend (and the workload is small enough to complete
> and trigger the queued engine/context free-up either very
> late in suspend or very early in resume).
>
> In such a case, we need to unroll the entire process because
> guc-lrc-unpin takes a gt wakeref which only gets released in
> the G2H IRQ reply that never comes through in this corner
> case. Without the unroll, the taken wakeref is leaked and will
> cascade into a kernel hang later at the tail end of suspend in
> this function:
>
>intel_wakeref_wait_for_idle(>wakeref)
>(called by) - intel_gt_pm_wait_for_idle
>(called by) - wait_for_suspend
>
> Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_-
> contexts if guc_lrc_desc_unpin fails due to CT send falure.
> When unrolling, keep the context in the GuC's destroy-list so
> it can get picked up on the next destroy worker invocation
> (if suspend 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
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ---
> 2 files changed, 80 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 0d812f4d787d..3b27218aabe2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private *i915)
> GEM_TRACE("%s\n", dev_name(i915->drm.dev));
>
> intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
> + /*
> + * On rare occasions, we've observed the fence completion triggers
> + * free_engines asynchronously via rcu_call. Ensure those are done.
> + * This path is only called on suspend, so it's an acceptable cost.
> + */
> + rcu_barrier();
> +
> flush_workqueue(i915->wq);
>
> /*
> @@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
>* machine in an unusable condition.
>*/
>
> + /* Like i915_gem_suspend, flush tasks staged from fence triggers */
> + rcu_barrier();
> +
> for_each_gt(gt, i915, i)
> intel_gt_suspend_late(gt);
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 9d1915482898..225747115f78 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -236,6 +236,13 @@ set_context_destroyed(struct intel_context *ce)
> ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
> }
>
> +static inline void
> +clr_context_destroyed(struct intel_context *ce)
> +{
> + lockdep_assert_held(>guc_state.lock);
> + ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
> +}
> +
> static inline bool context_pending_disable(struct intel_context *ce)
> {
> return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
> @@ -613,6 +620,8 @@ static int guc_submission_send_busy_loop(struct intel_guc
> *guc,
>u32 g2h_len_dw,
>bool loop)
> {
> + int ret;
> +
> /*
>* We always loop when a send requires a reply (i.e. g2h_len_dw > 0),
>* so we don't handle the case where we don't get a reply because we
> @@ -623,7 +632,11 @@ static int guc_submission_send_busy_loop(struct
> intel_guc *guc,
> if (g2h_len_dw)
> atomic_inc(>outstanding_submission_g2h);
>
> - return intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
> + ret = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
> + if (ret)
> + atomic_dec(>outstanding_submission_g2h);
> +
> +
Re: [Intel-gfx] [PATCH v1 1/1] drm/i915/gt: Dont wait forever when idling in suspend
On Tue, Nov 14, 2023 at 08:22:27AM -0800, Alan Previn wrote:
> When suspending, add a timeout when calling
> intel_gt_pm_wait_for_idle else if we have a leaked
> wakeref (which would be indicative of a bug elsewhere
> in the driver), driver will at exit the suspend-resume
> cycle, after 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-by: Mousumi Jana
could you please rebase this on top of recent drm-tip and resend?
I got a conflict while trying to apply on drm-intel-gt-next.
As I had stated in another thread, I believe we should go further
and block the suspend and have a clean return to normal operation.
But anyway, I agree this is already a good and necessary improvement
because being in the dark if some bad case like this happens is
the worst thing. So this patch is already an improvement anyway.
again:
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 ++-
> drivers/gpu/drm/i915/gt/intel_gt_pm.h | 7 ++-
> drivers/gpu/drm/i915/intel_wakeref.c | 14 ++
> drivers/gpu/drm/i915/intel_wakeref.h | 6 --
> 5 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 40687806d22a..ffef963037f2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -686,7 +686,7 @@ void intel_engines_release(struct intel_gt *gt)
> if (!engine->release)
> continue;
>
> - intel_wakeref_wait_for_idle(>wakeref);
> + intel_wakeref_wait_for_idle(>wakeref, 0);
> GEM_BUG_ON(intel_engine_pm_is_awake(engine));
>
> engine->release(engine);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index f5899d503e23..25cb39ba9fdf 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -306,6 +306,8 @@ int intel_gt_resume(struct intel_gt *gt)
>
> static void wait_for_suspend(struct intel_gt *gt)
> {
> + int final_timeout_ms = (I915_GT_SUSPEND_IDLE_TIMEOUT * 10);
> +
> if (!intel_gt_pm_is_awake(gt))
> return;
>
> @@ -318,7 +320,10 @@ static void wait_for_suspend(struct intel_gt *gt)
> intel_gt_retire_requests(gt);
> }
>
> - intel_gt_pm_wait_for_idle(gt);
> + /* we are suspending, so we shouldn't be waiting forever */
> + if (intel_gt_pm_wait_timeout_for_idle(gt, final_timeout_ms) ==
> -ETIMEDOUT)
> + gt_warn(gt, "bailing from %s after %d milisec timeout\n",
> + __func__, final_timeout_ms);
> }
>
> void intel_gt_suspend_prepare(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> index b1eeb5b33918..1757ca4c3077 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> @@ -68,7 +68,12 @@ static inline void intel_gt_pm_might_put(struct intel_gt
> *gt)
>
> static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
> {
> - return intel_wakeref_wait_for_idle(>wakeref);
> + return intel_wakeref_wait_for_idle(>wakeref, 0);
> +}
> +
> +static inline int intel_gt_pm_wait_timeout_for_idle(struct intel_gt *gt, int
> timeout_ms)
> +{
> + return intel_wakeref_wait_for_idle(>wakeref, timeout_ms);
> }
>
> void intel_gt_pm_init_early(struct intel_gt *gt);
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
> b/drivers/gpu/drm/i915/intel_wakeref.c
> index 623a69089386..f2611c65246b 100644
> --- a/drivers/gpu/drm/i915/intel_wakeref.c
> +++ b/drivers/gpu/drm/i915/intel_wakeref.c
> @@ -113,14 +113,20 @@ void __intel_wakeref_init(struct intel_wakeref *wf,
>"wakeref.work", >work, 0);
> }
>
> -int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
> +int intel_wakeref_wait_for_idle(struct intel_wakeref *wf, int timeout_ms)
> {
> - int err;
> + int err = 0;
>
> might_sleep();
>
> - err = wait_var_event_killable(>wakeref,
> - !intel_wakeref_is_active(wf));
> + if (!timeout_ms)
> + err = wait_var_event_killable(>wakeref,
> + !intel_wakeref_is_active(wf)
Re: [PATCH v2 1/1] drm/i915/pxp: Add missing tag for Wa_14019159160
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
>for the targetted platforms (John Harrison)
>
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 7c367ba8d9dc..2959dfed2aa0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -863,11 +863,13 @@ static bool ctx_needs_runalone(const struct
> intel_context *ce)
> bool ctx_is_protected = false;
>
> /*
> - * On MTL and newer platforms, protected contexts require setting
> - * the LRC run-alone bit or else the encryption will not happen.
> + * Wa_14019159160 - Case 2: mtl
> + * On some platforms, protected contexts require setting
> + * the LRC run-alone bit or else the encryption/decryption will not
> happen.
> + * NOTE: Case 2 only applies to PXP use-case of said workaround.
>*/
hmm, interesting enough, on the wa description I read that it is incomplete for
MTL/ARL
and something about a fuse bit. We should probably chase for some clarification
in the
HSD?!
> - if (GRAPHICS_VER_FULL(ce->engine->i915) >= IP_VER(12, 70) &&
> - (ce->engine->class == COMPUTE_CLASS || ce->engine->class ==
> RENDER_CLASS)) {
> + if (IS_METEORLAKE(ce->engine->i915) && (ce->engine->class ==
> COMPUTE_CLASS ||
> + ce->engine->class ==
> RENDER_CLASS)) {
This check now excludes the ARL with the same IP, no?!
> rcu_read_lock();
> gem_ctx = rcu_dereference(ce->gem_context);
> if (gem_ctx)
>
> base-commit: 5429d55de723544dfc0630cf39d96392052b27a1
> --
> 2.39.0
>
Re: [Intel-xe] [PATCH v5] Documentation/gpu: VM_BIND locking document
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 > intended to be part of the xe driver upstreaming agreement. > > The document describes and discuss the locking used during exec- > functions, evicton and for userptr gpu-vmas. Intention is to be using the > same nomenclature as the drm-vm-bind-async.rst. > > v2: > - s/gvm/gpu_vm/g (Rodrigo Vivi) > - Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c > (Rodrigo Vivi) > - Adjust commit message accordingly. > - Add SPDX license header. > > v3: > - Large update to align with the drm_gpuvm manager locking > - Add "Efficient userptr gpu_vma exec function iteration" section > - Add "Locking at bind- and unbind time" section. > > v4: > - Fix tabs vs space errors by untabifying (Rodrigo Vivi) > - Minor style fixes and typos (Rodrigo Vivi) > - Clarify situations where stale GPU mappings are occurring and how > access through these mappings are blocked. (Rodrigo Vivi) > - Insert into the toctree in implementation_guidelines.rst > > v5: > - Add a section about recoverable page-faults. > - Use local references to other documentation where possible > (Bagas Sanjaya) > - General documentation fixes and typos (Danilo Krummrich and > Boris Brezillon) > - Improve the documentation around locks that need to be grabbed from the > dm-fence critical section (Boris Brezillon) > - Add more references to the DRM GPUVM helpers (Danilo Krummrich and > Boriz Brezillon) > - Update the rfc/xe.rst document. > > Cc: Rodrigo Vivi > Signed-off-by: Thomas Hellström First of all, with Bagas and Boris latest suggestions, already few free to use: Reviewed-by: Rodrigo Vivi But a few minor comments below. Mostly trying to address Boris feeling of long sentences. However, take them with a grain of salt since I'm not a native english speaker. :) > --- > Documentation/core-api/pin_user_pages.rst | 2 + > Documentation/gpu/drm-mm.rst | 4 + > Documentation/gpu/drm-vm-bind-locking.rst | 579 ++ > .../gpu/implementation_guidelines.rst | 1 + > Documentation/gpu/rfc/xe.rst | 5 + > 5 files changed, 591 insertions(+) > create mode 100644 Documentation/gpu/drm-vm-bind-locking.rst > > diff --git a/Documentation/core-api/pin_user_pages.rst > b/Documentation/core-api/pin_user_pages.rst > index d3c1f6d8c0e0..6b5f7e6e7155 100644 > --- a/Documentation/core-api/pin_user_pages.rst > +++ b/Documentation/core-api/pin_user_pages.rst > @@ -153,6 +153,8 @@ NOTE: Some pages, such as DAX pages, cannot be pinned > with longterm pins. That's > because DAX pages do not have a separate page cache, and so "pinning" implies > locking down file system blocks, which is not (yet) supported in that way. > > +.. _mmu-notifier-registration-case: > + > CASE 3: MMU notifier registration, with or without page faulting hardware > - > Device drivers can pin pages via get_user_pages*(), and register for mmu > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst > index acc5901ac840..d55751cad67c 100644 > --- a/Documentation/gpu/drm-mm.rst > +++ b/Documentation/gpu/drm-mm.rst > @@ -466,6 +466,8 @@ DRM MM Range Allocator Function References > .. kernel-doc:: drivers/gpu/drm/drm_mm.c > :export: > > +.. _drm_gpuvm: > + > DRM GPUVM > = > > @@ -481,6 +483,8 @@ Split and Merge > .. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c > :doc: Split and Merge > > +.. _drm_gpuvm_locking: > + > Locking > --- > > diff --git a/Documentation/gpu/drm-vm-bind-locking.rst > b/Documentation/gpu/drm-vm-bind-locking.rst > new file mode 100644 > index ..a7d08eccd50e > --- /dev/null > +++ b/Documentation/gpu/drm-vm-bind-locking.rst > @@ -0,0 +1,579 @@ > +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + > +=== > +VM_BIND locking > +=== > + > +This document attempts to describe what's needed to get VM_BIND locking > right, > +including the userptr mmu_notifier locking and it also discusses some including the userptr mmu_notifier locking. It also discusses some > +optimizations to get rid of the looping through of all userptr mappings and > +external / shared object mappings that is needed in the simplest > +implementation. In addition there is a section describing the VM_BIND locking In addition, > +required for implementing recoverable pagefaults. > + > +The DRM GPUVM set of helpers > + > + > +There is a set of help
Re: [Intel-gfx] [PATCH v3 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates
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 the correct channel coding efficiency based on
> > the link rate.
> >
> > v2:
> > - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
> > v3:
> > - Fix rounding up quotient while calculating req_slots. (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Lyude Paul
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Imre Deak
>
> Reviewed-by: Ville Syrjälä
Dave, Sima, it looks like this whole series is ready for getting merged:
https://patchwork.freedesktop.org/series/126526/
But it has these 3 drm/dp_mst here.
Ack to merge them through drm-intel?
>
> > ---
> > drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +++---
> > include/drm/display/drm_dp_helper.h | 13 +
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > index 000d05e80352a..8ca01a6bf645d 100644
> > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > @@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct
> > drm_dp_mst_topology_mgr *mgr,
> > fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr
> > *mgr,
> > int link_rate, int link_lane_count)
> > {
> > + int ch_coding_efficiency =
> > +
> > drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
> > fixed20_12 ret;
> >
> > if (link_rate == 0 || link_lane_count == 0)
> > drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d /
> > %d)\n",
> > link_rate, link_lane_count);
> >
> > - /* See DP v2.0 2.6.4.2,
> > VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> > - ret.full = dfixed_const(link_rate * link_lane_count / 54000);
> > + /* See DP v2.0 2.6.4.2, 2.7.6.3
> > VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
> > + ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
> > + ch_coding_efficiency),
> > + (100ULL * 8 * 5400) >> 12);
> >
> > return ret;
> > }
> > @@ -4342,7 +4346,7 @@ int drm_dp_atomic_find_time_slots(struct
> > drm_atomic_state *state,
> > }
> > }
> >
> > - req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));
> > + req_slots = DIV_ROUND_UP(dfixed_const(pbn),
> > topology_state->pbn_div.full);
> >
> > drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d ->
> > %d\n",
> >port->connector->base.id, port->connector->name,
> > diff --git a/include/drm/display/drm_dp_helper.h
> > b/include/drm/display/drm_dp_helper.h
> > index c5f1079acb3b1..863b2e7add29e 100644
> > --- a/include/drm/display/drm_dp_helper.h
> > +++ b/include/drm/display/drm_dp_helper.h
> > @@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8
> > edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
> > return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
> > }
> >
> > +/**
> > + * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
> > + * @link_rate: link rate in 10kbits/s units
> > + *
> > + * Determine if the provided link rate is an UHBR rate.
> > + *
> > + * Returns: %True if @link_rate is an UHBR rate.
> > + */
> > +static inline bool drm_dp_is_uhbr_rate(int link_rate)
> > +{
> > + return link_rate >= 100;
> > +}
> > +
> > /*
> > * DisplayPort AUX channel
> > */
> > --
> > 2.39.2
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
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 it to zero doesn't seem
to make that relative. And also doesn't look right.
>
> Currently, the value of `phys_base` is set to "Surface Base Address,"
> which in the case of Meter Lake is 0xfc00_.
I don't believe this is a fixed value. IIRC this comes from the register
set by video bios, where the idea is to reuse the fb that was used so
far.
With this in mind I don't understand how that could overflow. Maybe
the size of the stolen is not right? maybe the size? maybe different
memory region?
> This causes the
> function `i915_gem_object_create_region_at` to fail in line 128, when
> it attempts to verify that the range does not overflow:
>
> if (range_overflows(offset, size, resource_size(>region)))
> return ERR_PTR(-EINVAL);
>
> where:
> offset = 0xfc00
> size = 0x8ca000
> mem->region.end + 1 = 0x440
> mem->region.start = 0x80
> resource_size(>region) = 0x3c0
>
> call stack:
> i915_gem_object_create_region_at
> initial_plane_vma
> intel_alloc_initial_plane_obj
> intel_find_initial_plane_obj
> intel_crtc_initial_plane_config
>
> Looking at the flow coming next, we see that `phys_base` is only used
> once, in function `_i915_gem_object_stolen_init`, in the context of
> the offset *in* the stolen memory. Combining that with an
> examinination of the history of the file seems to indicate the
> current value set is invalid.
>
> call stack (functions using `phys_base`)
> _i915_gem_object_stolen_init
> __i915_gem_object_create_region
> i915_gem_object_create_region_at
> initial_plane_vma
> intel_alloc_initial_plane_obj
> intel_find_initial_plane_obj
> intel_crtc_initial_plane_config
>
> [drm:_i915_gem_object_stolen_init] creating preallocated stolen
> object: stolen_offset=0x, size=0x008ca000
>
> Signed-off-by: Paz Zcharya
> ---
>
> drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index a55c09cbd0e4..e696cb13756a 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -90,7 +90,7 @@ initial_plane_vma(struct drm_i915_private *i915,
> "Using phys_base=%pa, based on initial plane
> programming\n",
> _base);
> } else {
> - phys_base = base;
> + phys_base = 0;
> mem = i915->mm.stolen_region;
> }
>
> --
> 2.42.0.869.gea05f2083d-goog
>
Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending
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 Ursulin wrote: > > > > > On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote: > > alan:snip > > > > > It is not possible to wait for lost G2H in something like > > > > > intel_uc_suspend() and simply declare "bad things happened" if it > > > > > times > > > > > out there, and forcibly clean it all up? (Which would include > > > > > releasing > > > > > all the abandoned pm refs, so this patch wouldn't be needed.) > > > > > > > > > alan: I'm not sure if intel_uc_suspend should be held up by gt-level > > > > wakeref > > > > check unless huc/guc/gsc-uc are the only ones ever taking a gt wakeref. > > > > > > > > As we already know, what we do know from a uc-perspective: > > > > - ensure the outstanding guc related workers is flushed which we didnt > > > > before > > > > (addressed by patch #1). > > > > - any further late H2G-SchedDisable is not leaking wakerefs when > > > > calling H2G > > > > and not realizing it failed (addressed by patch #2). > > > > - (we already), "forcibly clean it all up" at the end of the > > > > intel_uc_suspend > > > > when we do the guc reset and cleanup all guc-ids. (pre-existing > > > > upstream code) > > > > - we previously didnt have a coherrent guarantee that "this is the end" > > > > i.e. no > > > > more new request after intel_uc_suspend. I mean by code logic, we > > > > thought we did > > > > (thats why intel_uc_suspend ends wth a guc reset), but we now know > > > > otherwise. > > > > So we that fix by adding the additional rcu_barrier (also part of patch > > > > #2). > > > > > > It is not clear to me from the above if that includes cleaning up the > > > outstanding CT replies or no. But anyway.. > > alan: Apologies, i should have made it clearer by citing the actual function > > name calling out the steps of interest: So if you look at the function > > "intel_gt_suspend_late", it calls "intel_uc_suspend" which in turn calls > > "intel_guc_suspend" which does a soft reset onto guc firmware - so after > > that > > we can assume all outstanding G2Hs are done. Going back up the stack, > > intel_gt_suspend_late finally calls gt_sanitize which calls > > "intel_uc_reset_prepare" > > which calls "intel_guc_submission_reset_prepare" which calls > > "scrub_guc_desc_for_outstanding_g2h" which does what we are looking for for > > all > > types of outstanding G2H. As per prior review comments, besides closing the > > race > > condition, we were missing an rcu_barrier (which caused new requests to > > come in way > > late). So we have resolved both in Patch #2. > > Cool, I read this as all known bugs are fixed by first two patches. > > > > > That said, patch-3 is NOT fixing a bug in guc -its about "if we ever > > > > have > > > > a future racy gt-wakeref late-leak somewhere - no matter which subsystem > > > > took it (guc is not the only subsystem taking gt wakerefs), we at > > > > least don't hang forever in this code. Ofc, based on that, even without > > > > patch-3 i am confident the issue is resolved anyway. > > > > So we could just drop patch-3 is you prefer? > > > > > > .. given this it does sound to me that if you are confident patch 3 > > > isn't fixing anything today that it should be dropped. > > alan: I won't say its NOT fixing anything - i am saying it's not fixing > > this specific bug where we have the outstanding G2H from a context > > destruction > > operation that got dropped. I am okay with dropping this patch in the next > > rev > > but shall post a separate stand alone version of Patch3 - because I believe > > all other i915 subsystems that take runtime-pm's DO NOT wait forever when > > entering > > suspend - but GT is doing this. This means if there ever was a bug > > introduced, > > it would require serial port or ramoops collection to debug. So i think > > such a > > patch, despite not fixing this specific bug will be very helpful for > > debuggability > > of future issues. After all, its better to fail our suspend when we have a > > bug > > rather than to hang the kernel forever. > > Issue I have is that I am not seeing how it fails the suspend when nothing > is passed out from *void* wait_suspend(gt). To me it looks the suspend just > carries on. And if so, it sounds dangerous to allow it to do that with any > future/unknown bugs in the suspend sequence. Existing timeout wedges the GPU > (and all that entails). New code just says "meh I'll just carry on > regardless". That's a good point. Well, current code is already bad and buggy on suspend-resume. We could get suspend stuck forever without any clue of what happened. At least the proposed patch add some gt_warn. But, yes, the right thing to do should be entirely abort the suspend in case
Re: [PATCH] drm/i915: eliminate warnings
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 variable may have an int value.
> So the dewake_scanline variable is necessary to defined as an int.
A good catch. But this patch deserves a better commit subject since
it is not just fixing 'warnings' but the behavior of this function
accounts on the -1 that is explicitly given as input in some cases.
>
> Signed-off-by: heminhong
also perhaps:
Fixes: f83b94d23770 ("drm/i915/dsb: Use DEwake to combat PkgC latency")
Cc: Ville Syrjälä
Cc: Uma Shankar
?
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 78b6fe24dcd8..7fd6280c54a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -340,7 +340,7 @@ static int intel_dsb_dewake_scanline(const struct
> intel_crtc_state *crtc_state)
> }
>
> static void _intel_dsb_commit(struct intel_dsb *dsb, u32 ctrl,
> - unsigned int dewake_scanline)
> + int dewake_scanline)
> {
> struct intel_crtc *crtc = dsb->crtc;
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> --
> 2.25.1
>
[PATCH 11/20] drm/sched: Convert the GPU scheduler to variable number of run-queues
From: Luben Tuikov
The GPU scheduler has now a variable number of run-queues, which are set up at
drm_sched_init() time. This way, each driver announces how many run-queues it
requires (supports) per each GPU scheduler it creates. Note, that run-queues
correspond to scheduler "priorities", thus if the number of run-queues is set
to 1 at drm_sched_init(), then that scheduler supports a single run-queue,
i.e. single "priority". If a driver further sets a single entity per
run-queue, then this creates a 1-to-1 correspondence between a scheduler and
a scheduled entity.
Cc: Lucas Stach
Cc: Russell King
Cc: Qiang Yu
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Boris Brezillon
Cc: Alex Deucher
Cc: Christian König
Cc: Emma Anholt
Cc: etna...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Acked-by: Christian König
Link: https://lore.kernel.org/r/20231023032251.164775-1-luben.tui...@amd.com
(cherry picked from commit 56e449603f0ac580700621a356d35d5716a62ce5)
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 4 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 1 +
drivers/gpu/drm/lima/lima_sched.c | 4 +-
drivers/gpu/drm/msm/msm_ringbuffer.c | 5 +-
drivers/gpu/drm/nouveau/nouveau_sched.c| 1 +
drivers/gpu/drm/panfrost/panfrost_job.c| 1 +
drivers/gpu/drm/scheduler/sched_entity.c | 18 +-
drivers/gpu/drm/scheduler/sched_main.c | 74 ++
drivers/gpu/drm/v3d/v3d_sched.c| 5 ++
include/drm/gpu_scheduler.h| 9 ++-
11 files changed, 98 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 30c4f5cca02c..15074232fbbd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2280,6 +2280,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
}
r = drm_sched_init(>sched, _sched_ops,
+ DRM_SCHED_PRIORITY_COUNT,
ring->num_hw_submission, 0,
timeout, adev->reset_domain->wq,
ring->sched_score, ring->name,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 78476bc75b4e..1f357198533f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,8 +325,8 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= DRM_SCHED_PRIORITY_MIN;
i--) {
- struct drm_sched_rq *rq = >sched_rq[i];
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
while ((s_job =
to_drm_sched_job(spsc_queue_pop(_entity->job_queue {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 345fec6cb1a4..9b79f218e21a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -135,6 +135,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
int ret;
ret = drm_sched_init(>sched, _sched_ops,
+DRM_SCHED_PRIORITY_COUNT,
etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
msecs_to_jiffies(500), NULL, NULL,
dev_name(gpu->dev), gpu->dev);
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index ffd91a5ee299..295f0353a02e 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -488,7 +488,9 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
const char *name)
INIT_WORK(>recover_work, lima_sched_recover_work);
- return drm_sched_init(>base, _sched_ops, 1,
+ return drm_sched_init(>base, _sched_ops,
+ DRM_SCHED_PRIORITY_COUNT,
+ 1,
lima_job_hang_limit,
msecs_to_jiffies(timeout), NULL,
NULL, name, pipe->ldev->dev);
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 40c0bc35a44c..95257ab0185d 100644
--- a/drivers/gpu/drm/ms
