Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Tue, Mar 28, 2023 at 07:22:24PM +0300, Jani Nikula wrote:
> On Mon, 27 Mar 2023, Rodrigo Vivi wrote:
> > uncore->lock only protects the forcewake domain itself,
> > not the register accesses.
> >
> > uncore's _fw alternatives are for cases where the domains
> > are not needed because we are sure that they are already
> > awake.
> >
> > So the move towards the uncore's _fw alternatives seems
> > right, however using the uncore-lock to protect the dsparb
> > registers seems an abuse of the uncore-lock.
> >
> > Let's restore the previous individual lock and try to get
> > rid of the direct uncore accesses from the display code.
> >
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Signed-off-by: Rodrigo Vivi
> > Reviewed-by: Ville Syrjälä
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20230308165859.235520-1-rodrigo.v...@intel.com
> > ---
> > drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > drivers/gpu/drm/i915/i915_driver.c| 1 +
> > 3 files changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > index caef72d38798..8fe0b5c63d3a 100644
> > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> > intel_atomic_state *state,
> >
> > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
> >
> > - /*
> > -* uncore.lock serves a double purpose here. It allows us to
> > -* use the less expensive I915_{READ,WRITE}_FW() functions, and
> > -* it protects the DSPARB registers from getting clobbered by
> > -* parallel updates from multiple pipes.
> > -*
> > -* intel_pipe_update_start() has already disabled interrupts
> > -* for us, so a plain spin_lock() is sufficient here.
> > -*/
> > - spin_lock(>lock);
> > + spin_lock(_priv->display.wm.dsparb_lock);
> >
> > switch (crtc->pipe) {
> > case PIPE_A:
> > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> > intel_atomic_state *state,
> >
> > intel_uncore_posting_read_fw(uncore, DSPARB);
> >
> > - spin_unlock(>lock);
> > + spin_unlock(_priv->display.wm.dsparb_lock);
> > }
> >
> > #undef VLV_FIFO
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > index 0b5509f268a7..e4da8902c878 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > @@ -264,6 +264,9 @@ struct intel_wm {
> > */
> > struct mutex wm_mutex;
> >
> > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > + spinlock_t dsparb_lock;
> > +
> > bool ipc_enabled;
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index 12b5296ee744..e90a0c0403a6 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> > drm_i915_private *dev_priv)
> > mutex_init(_priv->display.pps.mutex);
> > mutex_init(_priv->display.hdcp.comp_mutex);
> > spin_lock_init(_priv->display.dkl.phy_lock);
> > + spin_lock_init(_priv->display.wm.dsparb_lock);
>
> Can we do this in i9xx_wm_init() instead?
I was going to modify it here right now, but then I noticed
the cases above and remembered why I have put it here.
All the display locks are getting set in here.
Probably better to move with this patch as is and then add
a new on top moving the various locks to its individual inits?
>
>
> >
> > i915_memcpy_init_early(dev_priv);
> > intel_runtime_pm_init_early(_priv->runtime_pm);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Mon, 27 Mar 2023, Rodrigo Vivi wrote:
> uncore->lock only protects the forcewake domain itself,
> not the register accesses.
>
> uncore's _fw alternatives are for cases where the domains
> are not needed because we are sure that they are already
> awake.
>
> So the move towards the uncore's _fw alternatives seems
> right, however using the uncore-lock to protect the dsparb
> registers seems an abuse of the uncore-lock.
>
> Let's restore the previous individual lock and try to get
> rid of the direct uncore accesses from the display code.
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: Ville Syrjälä
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20230308165859.235520-1-rodrigo.v...@intel.com
> ---
> drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> drivers/gpu/drm/i915/i915_driver.c| 1 +
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> b/drivers/gpu/drm/i915/display/i9xx_wm.c
> index caef72d38798..8fe0b5c63d3a 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> intel_atomic_state *state,
>
> trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
>
> - /*
> - * uncore.lock serves a double purpose here. It allows us to
> - * use the less expensive I915_{READ,WRITE}_FW() functions, and
> - * it protects the DSPARB registers from getting clobbered by
> - * parallel updates from multiple pipes.
> - *
> - * intel_pipe_update_start() has already disabled interrupts
> - * for us, so a plain spin_lock() is sufficient here.
> - */
> - spin_lock(>lock);
> + spin_lock(_priv->display.wm.dsparb_lock);
>
> switch (crtc->pipe) {
> case PIPE_A:
> @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> intel_atomic_state *state,
>
> intel_uncore_posting_read_fw(uncore, DSPARB);
>
> - spin_unlock(>lock);
> + spin_unlock(_priv->display.wm.dsparb_lock);
> }
>
> #undef VLV_FIFO
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index 0b5509f268a7..e4da8902c878 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -264,6 +264,9 @@ struct intel_wm {
>*/
> struct mutex wm_mutex;
>
> + /* protects DSPARB registers on pre-g4x/vlv/chv */
> + spinlock_t dsparb_lock;
> +
> bool ipc_enabled;
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 12b5296ee744..e90a0c0403a6 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> mutex_init(_priv->display.pps.mutex);
> mutex_init(_priv->display.hdcp.comp_mutex);
> spin_lock_init(_priv->display.dkl.phy_lock);
> + spin_lock_init(_priv->display.wm.dsparb_lock);
Can we do this in i9xx_wm_init() instead?
>
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(_priv->runtime_pm);
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
uncore->lock only protects the forcewake domain itself,
not the register accesses.
uncore's _fw alternatives are for cases where the domains
are not needed because we are sure that they are already
awake.
So the move towards the uncore's _fw alternatives seems
right, however using the uncore-lock to protect the dsparb
registers seems an abuse of the uncore-lock.
Let's restore the previous individual lock and try to get
rid of the direct uncore accesses from the display code.
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20230308165859.235520-1-rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
drivers/gpu/drm/i915/i915_driver.c| 1 +
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
b/drivers/gpu/drm/i915/display/i9xx_wm.c
index caef72d38798..8fe0b5c63d3a 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
- /*
-* uncore.lock serves a double purpose here. It allows us to
-* use the less expensive I915_{READ,WRITE}_FW() functions, and
-* it protects the DSPARB registers from getting clobbered by
-* parallel updates from multiple pipes.
-*
-* intel_pipe_update_start() has already disabled interrupts
-* for us, so a plain spin_lock() is sufficient here.
-*/
- spin_lock(>lock);
+ spin_lock(_priv->display.wm.dsparb_lock);
switch (crtc->pipe) {
case PIPE_A:
@@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
intel_uncore_posting_read_fw(uncore, DSPARB);
- spin_unlock(>lock);
+ spin_unlock(_priv->display.wm.dsparb_lock);
}
#undef VLV_FIFO
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 0b5509f268a7..e4da8902c878 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -264,6 +264,9 @@ struct intel_wm {
*/
struct mutex wm_mutex;
+ /* protects DSPARB registers on pre-g4x/vlv/chv */
+ spinlock_t dsparb_lock;
+
bool ipc_enabled;
};
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 12b5296ee744..e90a0c0403a6 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
mutex_init(_priv->display.pps.mutex);
mutex_init(_priv->display.hdcp.comp_mutex);
spin_lock_init(_priv->display.dkl.phy_lock);
+ spin_lock_init(_priv->display.wm.dsparb_lock);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(_priv->runtime_pm);
--
2.39.2
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Fri, Mar 10, 2023 at 06:26:54PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote:
> > On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> > > > uncore->lock only protects the forcewake domain itself,
> > > > not the register accesses.
> > > >
> > > > uncore's _fw alternatives are for cases where the domains
> > > > are not needed because we are sure that they are already
> > > > awake.
> > > >
> > > > So the move towards the uncore's _fw alternatives seems
> > > > right, however using the uncore-lock to protect the dsparb
> > > > registers seems an abuse of the uncore-lock.
> > > >
> > > > Let's restore the previous individual lock and try to get
> > > > rid of the direct uncore accesses from the display code.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Jani Nikula
> > > > Signed-off-by: Rodrigo Vivi
> > > > ---
> > > > drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> > > > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > > > drivers/gpu/drm/i915/i915_driver.c| 1 +
> > > > 3 files changed, 6 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > index caef72d38798..8fe0b5c63d3a 100644
> > > > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> > > > intel_atomic_state *state,
> > > >
> > > > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start,
> > > > fifo_size);
> > > >
> > > > - /*
> > > > -* uncore.lock serves a double purpose here. It allows us to
> > > > -* use the less expensive I915_{READ,WRITE}_FW() functions, and
> > > > -* it protects the DSPARB registers from getting clobbered by
> > > > -* parallel updates from multiple pipes.
> > > > -*
> > > > -* intel_pipe_update_start() has already disabled interrupts
> > > > -* for us, so a plain spin_lock() is sufficient here.
> > > > -*/
> > >
> > > I was wondering if we need to preserve the comment about irqs,
> > > but since this is the only place using this lock, and it's never
> > > called from an irq handler a non-irq disabling spinlock will suffice
> > > anyway.
> > >
> > > Reviewed-by: Ville Syrjälä
> >
> > thoughts on this:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-dp-1.html
>
> This code doesn't run on that platform, so unrelated.
oh! indeed.
okay, I just triggered a rerun to get the full round... luckly...
>
> >
> > maybe related to the usage of this uncore.lock in
> >
> > drivers/gpu/drm/i915/display/intel_vblank.c
> >
> > ?
> >
> > Should we create another spin lock and include both of these cases?
> > (Then the irq comment is relevant again :))
>
> We're already 4 spinlocks deep when in vblank code. Let's not add more ;)
>
> >
> > >
> > > > - spin_lock(>lock);
> > > > + spin_lock(_priv->display.wm.dsparb_lock);
> > > >
> > > > switch (crtc->pipe) {
> > > > case PIPE_A:
> > > > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> > > > intel_atomic_state *state,
> > > >
> > > > intel_uncore_posting_read_fw(uncore, DSPARB);
> > > >
> > > > - spin_unlock(>lock);
> > > > + spin_unlock(_priv->display.wm.dsparb_lock);
> > > > }
> > > >
> > > > #undef VLV_FIFO
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > index fdab7bb93a7d..68c6bfb91dbe 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > > @@ -253,6 +253,9 @@ struct intel_wm {
> > > > */
> > > > struct mutex wm_mutex;
> > > >
> > > > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > > > + spinlock_t dsparb_lock;
> > > > +
> > > > bool ipc_enabled;
> > > > };
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index a53fd339e2cc..c78e36444a12 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> > > > drm_i915_private *dev_priv)
> > > > mutex_init(_priv->display.pps.mutex);
> > > > mutex_init(_priv->display.hdcp.comp_mutex);
> > > > spin_lock_init(_priv->display.dkl.phy_lock);
> > > > + spin_lock_init(_priv->display.wm.dsparb_lock);
> > > >
> > > > i915_memcpy_init_early(dev_priv);
> > > > intel_runtime_pm_init_early(_priv->runtime_pm);
> > > > --
> > > >
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote:
> On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> > > uncore->lock only protects the forcewake domain itself,
> > > not the register accesses.
> > >
> > > uncore's _fw alternatives are for cases where the domains
> > > are not needed because we are sure that they are already
> > > awake.
> > >
> > > So the move towards the uncore's _fw alternatives seems
> > > right, however using the uncore-lock to protect the dsparb
> > > registers seems an abuse of the uncore-lock.
> > >
> > > Let's restore the previous individual lock and try to get
> > > rid of the direct uncore accesses from the display code.
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Jani Nikula
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> > > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > > drivers/gpu/drm/i915/i915_driver.c| 1 +
> > > 3 files changed, 6 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > index caef72d38798..8fe0b5c63d3a 100644
> > > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> > > intel_atomic_state *state,
> > >
> > > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
> > >
> > > - /*
> > > - * uncore.lock serves a double purpose here. It allows us to
> > > - * use the less expensive I915_{READ,WRITE}_FW() functions, and
> > > - * it protects the DSPARB registers from getting clobbered by
> > > - * parallel updates from multiple pipes.
> > > - *
> > > - * intel_pipe_update_start() has already disabled interrupts
> > > - * for us, so a plain spin_lock() is sufficient here.
> > > - */
> >
> > I was wondering if we need to preserve the comment about irqs,
> > but since this is the only place using this lock, and it's never
> > called from an irq handler a non-irq disabling spinlock will suffice
> > anyway.
> >
> > Reviewed-by: Ville Syrjälä
>
> thoughts on this:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-dp-1.html
This code doesn't run on that platform, so unrelated.
>
> maybe related to the usage of this uncore.lock in
>
> drivers/gpu/drm/i915/display/intel_vblank.c
>
> ?
>
> Should we create another spin lock and include both of these cases?
> (Then the irq comment is relevant again :))
We're already 4 spinlocks deep when in vblank code. Let's not add more ;)
>
> >
> > > - spin_lock(>lock);
> > > + spin_lock(_priv->display.wm.dsparb_lock);
> > >
> > > switch (crtc->pipe) {
> > > case PIPE_A:
> > > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> > > intel_atomic_state *state,
> > >
> > > intel_uncore_posting_read_fw(uncore, DSPARB);
> > >
> > > - spin_unlock(>lock);
> > > + spin_unlock(_priv->display.wm.dsparb_lock);
> > > }
> > >
> > > #undef VLV_FIFO
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > index fdab7bb93a7d..68c6bfb91dbe 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > @@ -253,6 +253,9 @@ struct intel_wm {
> > >*/
> > > struct mutex wm_mutex;
> > >
> > > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > > + spinlock_t dsparb_lock;
> > > +
> > > bool ipc_enabled;
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index a53fd339e2cc..c78e36444a12 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> > > drm_i915_private *dev_priv)
> > > mutex_init(_priv->display.pps.mutex);
> > > mutex_init(_priv->display.hdcp.comp_mutex);
> > > spin_lock_init(_priv->display.dkl.phy_lock);
> > > + spin_lock_init(_priv->display.wm.dsparb_lock);
> > >
> > > i915_memcpy_init_early(dev_priv);
> > > intel_runtime_pm_init_early(_priv->runtime_pm);
> > > --
> > > 2.39.2
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote:
> On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> > uncore->lock only protects the forcewake domain itself,
> > not the register accesses.
> >
> > uncore's _fw alternatives are for cases where the domains
> > are not needed because we are sure that they are already
> > awake.
> >
> > So the move towards the uncore's _fw alternatives seems
> > right, however using the uncore-lock to protect the dsparb
> > registers seems an abuse of the uncore-lock.
> >
> > Let's restore the previous individual lock and try to get
> > rid of the direct uncore accesses from the display code.
> >
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > drivers/gpu/drm/i915/i915_driver.c| 1 +
> > 3 files changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > index caef72d38798..8fe0b5c63d3a 100644
> > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> > intel_atomic_state *state,
> >
> > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
> >
> > - /*
> > -* uncore.lock serves a double purpose here. It allows us to
> > -* use the less expensive I915_{READ,WRITE}_FW() functions, and
> > -* it protects the DSPARB registers from getting clobbered by
> > -* parallel updates from multiple pipes.
> > -*
> > -* intel_pipe_update_start() has already disabled interrupts
> > -* for us, so a plain spin_lock() is sufficient here.
> > -*/
>
> I was wondering if we need to preserve the comment about irqs,
> but since this is the only place using this lock, and it's never
> called from an irq handler a non-irq disabling spinlock will suffice
> anyway.
>
> Reviewed-by: Ville Syrjälä
thoughts on this:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-b-dp-1.html
maybe related to the usage of this uncore.lock in
drivers/gpu/drm/i915/display/intel_vblank.c
?
Should we create another spin lock and include both of these cases?
(Then the irq comment is relevant again :))
>
> > - spin_lock(>lock);
> > + spin_lock(_priv->display.wm.dsparb_lock);
> >
> > switch (crtc->pipe) {
> > case PIPE_A:
> > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> > intel_atomic_state *state,
> >
> > intel_uncore_posting_read_fw(uncore, DSPARB);
> >
> > - spin_unlock(>lock);
> > + spin_unlock(_priv->display.wm.dsparb_lock);
> > }
> >
> > #undef VLV_FIFO
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> > b/drivers/gpu/drm/i915/display/intel_display_core.h
> > index fdab7bb93a7d..68c6bfb91dbe 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > @@ -253,6 +253,9 @@ struct intel_wm {
> > */
> > struct mutex wm_mutex;
> >
> > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > + spinlock_t dsparb_lock;
> > +
> > bool ipc_enabled;
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index a53fd339e2cc..c78e36444a12 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> > drm_i915_private *dev_priv)
> > mutex_init(_priv->display.pps.mutex);
> > mutex_init(_priv->display.hdcp.comp_mutex);
> > spin_lock_init(_priv->display.dkl.phy_lock);
> > + spin_lock_init(_priv->display.wm.dsparb_lock);
> >
> > i915_memcpy_init_early(dev_priv);
> > intel_runtime_pm_init_early(_priv->runtime_pm);
> > --
> > 2.39.2
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> uncore->lock only protects the forcewake domain itself,
> not the register accesses.
>
> uncore's _fw alternatives are for cases where the domains
> are not needed because we are sure that they are already
> awake.
>
> So the move towards the uncore's _fw alternatives seems
> right, however using the uncore-lock to protect the dsparb
> registers seems an abuse of the uncore-lock.
>
> Let's restore the previous individual lock and try to get
> rid of the direct uncore accesses from the display code.
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
> drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> drivers/gpu/drm/i915/i915_driver.c| 1 +
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> b/drivers/gpu/drm/i915/display/i9xx_wm.c
> index caef72d38798..8fe0b5c63d3a 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
> intel_atomic_state *state,
>
> trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
>
> - /*
> - * uncore.lock serves a double purpose here. It allows us to
> - * use the less expensive I915_{READ,WRITE}_FW() functions, and
> - * it protects the DSPARB registers from getting clobbered by
> - * parallel updates from multiple pipes.
> - *
> - * intel_pipe_update_start() has already disabled interrupts
> - * for us, so a plain spin_lock() is sufficient here.
> - */
I was wondering if we need to preserve the comment about irqs,
but since this is the only place using this lock, and it's never
called from an irq handler a non-irq disabling spinlock will suffice
anyway.
Reviewed-by: Ville Syrjälä
> - spin_lock(>lock);
> + spin_lock(_priv->display.wm.dsparb_lock);
>
> switch (crtc->pipe) {
> case PIPE_A:
> @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
> intel_atomic_state *state,
>
> intel_uncore_posting_read_fw(uncore, DSPARB);
>
> - spin_unlock(>lock);
> + spin_unlock(_priv->display.wm.dsparb_lock);
> }
>
> #undef VLV_FIFO
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index fdab7bb93a7d..68c6bfb91dbe 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -253,6 +253,9 @@ struct intel_wm {
>*/
> struct mutex wm_mutex;
>
> + /* protects DSPARB registers on pre-g4x/vlv/chv */
> + spinlock_t dsparb_lock;
> +
> bool ipc_enabled;
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index a53fd339e2cc..c78e36444a12 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> mutex_init(_priv->display.pps.mutex);
> mutex_init(_priv->display.hdcp.comp_mutex);
> spin_lock_init(_priv->display.dkl.phy_lock);
> + spin_lock_init(_priv->display.wm.dsparb_lock);
>
> i915_memcpy_init_early(dev_priv);
> intel_runtime_pm_init_early(_priv->runtime_pm);
> --
> 2.39.2
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
uncore->lock only protects the forcewake domain itself,
not the register accesses.
uncore's _fw alternatives are for cases where the domains
are not needed because we are sure that they are already
awake.
So the move towards the uncore's _fw alternatives seems
right, however using the uncore-lock to protect the dsparb
registers seems an abuse of the uncore-lock.
Let's restore the previous individual lock and try to get
rid of the direct uncore accesses from the display code.
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/i9xx_wm.c| 13 ++---
drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
drivers/gpu/drm/i915/i915_driver.c| 1 +
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
b/drivers/gpu/drm/i915/display/i9xx_wm.c
index caef72d38798..8fe0b5c63d3a 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
- /*
-* uncore.lock serves a double purpose here. It allows us to
-* use the less expensive I915_{READ,WRITE}_FW() functions, and
-* it protects the DSPARB registers from getting clobbered by
-* parallel updates from multiple pipes.
-*
-* intel_pipe_update_start() has already disabled interrupts
-* for us, so a plain spin_lock() is sufficient here.
-*/
- spin_lock(>lock);
+ spin_lock(_priv->display.wm.dsparb_lock);
switch (crtc->pipe) {
case PIPE_A:
@@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
intel_uncore_posting_read_fw(uncore, DSPARB);
- spin_unlock(>lock);
+ spin_unlock(_priv->display.wm.dsparb_lock);
}
#undef VLV_FIFO
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index fdab7bb93a7d..68c6bfb91dbe 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -253,6 +253,9 @@ struct intel_wm {
*/
struct mutex wm_mutex;
+ /* protects DSPARB registers on pre-g4x/vlv/chv */
+ spinlock_t dsparb_lock;
+
bool ipc_enabled;
};
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index a53fd339e2cc..c78e36444a12 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
mutex_init(_priv->display.pps.mutex);
mutex_init(_priv->display.hdcp.comp_mutex);
spin_lock_init(_priv->display.dkl.phy_lock);
+ spin_lock_init(_priv->display.wm.dsparb_lock);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(_priv->runtime_pm);
--
2.39.2
