All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>,
	"Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [Intel-xe] [PATCH 1/5] drm/i915: Split display locks init from i915_driver_early_probe()
Date: Tue, 04 Apr 2023 11:15:50 +0300	[thread overview]
Message-ID: <87bkk412rt.fsf@intel.com> (raw)
In-Reply-To: <ZCscKrjtYBanN1tU@intel.com>

On Mon, 03 Apr 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> On Mon, Apr 03, 2023 at 02:10:26PM -0400, Souza, Jose wrote:
>> On Mon, 2023-04-03 at 13:03 -0400, Rodrigo Vivi wrote:
>> > On Mon, Apr 03, 2023 at 09:46:11AM -0700, José Roberto de Souza wrote:
>> > > No behavior changes here, just adding a function to make clear
>> > > what locks initialized here are display related or not.
>> > > 
>> > > Cc: intel-gfx@lists.freedesktop.org
>> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_driver.c | 23 +++++++++++++++--------
>> > >  1 file changed, 15 insertions(+), 8 deletions(-)
>> > > 
>> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
>> > > index 066d79c2069c4..224cb4cb43335 100644
>> > > --- a/drivers/gpu/drm/i915/i915_driver.c
>> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
>> > > @@ -188,6 +188,20 @@ static void sanitize_gpu(struct drm_i915_private *i915)
>> > >  	}
>> > >  }
>> > >  
>> > > +static void
>> > > +i915_driver_display_early_probe(struct drm_i915_private *dev_priv)
>> > > +{
>> > > +	spin_lock_init(&dev_priv->display.fb_tracking.lock);
>> > > +	spin_lock_init(&dev_priv->display.wm.dsparb_lock);
>> > > +	mutex_init(&dev_priv->display.backlight.lock);
>> > > +
>> > > +	mutex_init(&dev_priv->display.audio.mutex);
>> > > +	mutex_init(&dev_priv->display.wm.wm_mutex);
>> > > +	mutex_init(&dev_priv->display.pps.mutex);
>> > > +	mutex_init(&dev_priv->display.hdcp.comp_mutex);
>> > > +	spin_lock_init(&dev_priv->display.dkl.phy_lock);
>> > > +}
>> > > +
>> > 
>> > hmmm... I like that, however Jani had indicated in another series [1]
>> > that he would prefer the wm mutex inside the wm code for instance...
>> > 
>> > So, should we move all of these to their own components instead of this
>> > move?
>> > 
>> > [1] https://patchwork.freedesktop.org/series/115675/
>> > 
>> > I checked and for a few components it is simple to move them to their
>> > own init functions. However for a few we would need to create new init
>> > functions and call them here.
>> > 
>> > Jani, more thoughts?
>> 
>> Forgot to CC you two in the new version: https://patchwork.freedesktop.org/series/116039/
>> 
>> display.wm.dsparb_lock is not used anywhere.
>
> it currently doesn't exist on drm-intel. Not sure how it appeared in drm-xe...
> Probably a !fixup needed on initial display patches.
>
> Please notice that my series on the link I sent earlier re-introduce it with a proper
> usage. Ville had already reviewed the code, but I hold the push because Jani
> asked about a better placement.
>
> What I tried to say earlier here is that this patch is probably not following
> Jani's vision on how to organize the initialization of these many
> locks.

That's right.

Audio init should initialize audio.mutex.

Watermark init should initialize wm.wm_mutex.

PPS init should initialize pps.mutex.

Etc.

Moreover, display.audio should only be accessed by intel_audio.c. Etc.

BR,
Jani.






>
>> Moved display.dkl.phy_lock, will leave the rest to someone to take over.
>> 
>> 
>> > 
>> > >  /**
>> > >   * i915_driver_early_probe - setup state not requiring device access
>> > >   * @dev_priv: device private
>> > > @@ -213,18 +227,11 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
>> > >  
>> > >  	spin_lock_init(&dev_priv->irq_lock);
>> > >  	spin_lock_init(&dev_priv->gpu_error.lock);
>> > > -	spin_lock_init(&dev_priv->display.fb_tracking.lock);
>> > > -	spin_lock_init(&dev_priv->display.wm.dsparb_lock);
>> > > -	mutex_init(&dev_priv->display.backlight.lock);
>> > >  
>> > >  	mutex_init(&dev_priv->sb_lock);
>> > >  	cpu_latency_qos_add_request(&dev_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
>> > >  
>> > > -	mutex_init(&dev_priv->display.audio.mutex);
>> > > -	mutex_init(&dev_priv->display.wm.wm_mutex);
>> > > -	mutex_init(&dev_priv->display.pps.mutex);
>> > > -	mutex_init(&dev_priv->display.hdcp.comp_mutex);
>> > > -	spin_lock_init(&dev_priv->display.dkl.phy_lock);
>> > > +	i915_driver_display_early_probe(dev_priv);
>> > >  
>> > >  	i915_memcpy_init_early(dev_priv);
>> > >  	intel_runtime_pm_init_early(&dev_priv->runtime_pm);
>> > > -- 
>> > > 2.40.0
>> > > 
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>,
	"Souza, Jose" <jose.souza@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH 1/5] drm/i915: Split display locks init from i915_driver_early_probe()
Date: Tue, 04 Apr 2023 11:15:50 +0300	[thread overview]
Message-ID: <87bkk412rt.fsf@intel.com> (raw)
In-Reply-To: <ZCscKrjtYBanN1tU@intel.com>

On Mon, 03 Apr 2023, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> On Mon, Apr 03, 2023 at 02:10:26PM -0400, Souza, Jose wrote:
>> On Mon, 2023-04-03 at 13:03 -0400, Rodrigo Vivi wrote:
>> > On Mon, Apr 03, 2023 at 09:46:11AM -0700, José Roberto de Souza wrote:
>> > > No behavior changes here, just adding a function to make clear
>> > > what locks initialized here are display related or not.
>> > > 
>> > > Cc: intel-gfx@lists.freedesktop.org
>> > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_driver.c | 23 +++++++++++++++--------
>> > >  1 file changed, 15 insertions(+), 8 deletions(-)
>> > > 
>> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
>> > > index 066d79c2069c4..224cb4cb43335 100644
>> > > --- a/drivers/gpu/drm/i915/i915_driver.c
>> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
>> > > @@ -188,6 +188,20 @@ static void sanitize_gpu(struct drm_i915_private *i915)
>> > >  	}
>> > >  }
>> > >  
>> > > +static void
>> > > +i915_driver_display_early_probe(struct drm_i915_private *dev_priv)
>> > > +{
>> > > +	spin_lock_init(&dev_priv->display.fb_tracking.lock);
>> > > +	spin_lock_init(&dev_priv->display.wm.dsparb_lock);
>> > > +	mutex_init(&dev_priv->display.backlight.lock);
>> > > +
>> > > +	mutex_init(&dev_priv->display.audio.mutex);
>> > > +	mutex_init(&dev_priv->display.wm.wm_mutex);
>> > > +	mutex_init(&dev_priv->display.pps.mutex);
>> > > +	mutex_init(&dev_priv->display.hdcp.comp_mutex);
>> > > +	spin_lock_init(&dev_priv->display.dkl.phy_lock);
>> > > +}
>> > > +
>> > 
>> > hmmm... I like that, however Jani had indicated in another series [1]
>> > that he would prefer the wm mutex inside the wm code for instance...
>> > 
>> > So, should we move all of these to their own components instead of this
>> > move?
>> > 
>> > [1] https://patchwork.freedesktop.org/series/115675/
>> > 
>> > I checked and for a few components it is simple to move them to their
>> > own init functions. However for a few we would need to create new init
>> > functions and call them here.
>> > 
>> > Jani, more thoughts?
>> 
>> Forgot to CC you two in the new version: https://patchwork.freedesktop.org/series/116039/
>> 
>> display.wm.dsparb_lock is not used anywhere.
>
> it currently doesn't exist on drm-intel. Not sure how it appeared in drm-xe...
> Probably a !fixup needed on initial display patches.
>
> Please notice that my series on the link I sent earlier re-introduce it with a proper
> usage. Ville had already reviewed the code, but I hold the push because Jani
> asked about a better placement.
>
> What I tried to say earlier here is that this patch is probably not following
> Jani's vision on how to organize the initialization of these many
> locks.

That's right.

Audio init should initialize audio.mutex.

Watermark init should initialize wm.wm_mutex.

PPS init should initialize pps.mutex.

Etc.

Moreover, display.audio should only be accessed by intel_audio.c. Etc.

BR,
Jani.






>
>> Moved display.dkl.phy_lock, will leave the rest to someone to take over.
>> 
>> 
>> > 
>> > >  /**
>> > >   * i915_driver_early_probe - setup state not requiring device access
>> > >   * @dev_priv: device private
>> > > @@ -213,18 +227,11 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
>> > >  
>> > >  	spin_lock_init(&dev_priv->irq_lock);
>> > >  	spin_lock_init(&dev_priv->gpu_error.lock);
>> > > -	spin_lock_init(&dev_priv->display.fb_tracking.lock);
>> > > -	spin_lock_init(&dev_priv->display.wm.dsparb_lock);
>> > > -	mutex_init(&dev_priv->display.backlight.lock);
>> > >  
>> > >  	mutex_init(&dev_priv->sb_lock);
>> > >  	cpu_latency_qos_add_request(&dev_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
>> > >  
>> > > -	mutex_init(&dev_priv->display.audio.mutex);
>> > > -	mutex_init(&dev_priv->display.wm.wm_mutex);
>> > > -	mutex_init(&dev_priv->display.pps.mutex);
>> > > -	mutex_init(&dev_priv->display.hdcp.comp_mutex);
>> > > -	spin_lock_init(&dev_priv->display.dkl.phy_lock);
>> > > +	i915_driver_display_early_probe(dev_priv);
>> > >  
>> > >  	i915_memcpy_init_early(dev_priv);
>> > >  	intel_runtime_pm_init_early(&dev_priv->runtime_pm);
>> > > -- 
>> > > 2.40.0
>> > > 
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-04-04  8:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 16:46 [Intel-gfx] [PATCH 1/5] drm/i915: Split display locks init from i915_driver_early_probe() José Roberto de Souza
2023-04-03 16:46 ` [Intel-xe] " José Roberto de Souza
2023-04-03 16:46 ` [Intel-xe] [PATCH 2/5] drm/xe: Intialize missing display locks José Roberto de Souza
2023-04-03 16:46 ` [Intel-xe] [PATCH 3/5] drm/xe/display: Enable modular fia in TGL José Roberto de Souza
2023-04-03 16:46 ` [Intel-xe] [PATCH 4/5] drm/xe/display: Disable PSR HW tracking for DG2 and MTL José Roberto de Souza
2023-04-03 16:46 ` [Intel-xe] [PATCH 5/5] drm/xe: Enable Raptorlake-P José Roberto de Souza
2023-04-03 16:49 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [1/5] drm/i915: Split display locks init from i915_driver_early_probe() Patchwork
2023-04-03 16:50 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-04-03 16:54 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-04-03 17:03 ` [Intel-gfx] [Intel-xe] [PATCH 1/5] " Rodrigo Vivi
2023-04-03 17:03   ` Rodrigo Vivi
2023-04-03 18:10   ` [Intel-gfx] " Souza, Jose
2023-04-03 18:10     ` Souza, Jose
2023-04-03 18:34     ` [Intel-gfx] " Rodrigo Vivi
2023-04-03 18:34       ` Rodrigo Vivi
2023-04-04  8:15       ` Jani Nikula [this message]
2023-04-04  8:15         ` Jani Nikula
2023-04-03 17:14 ` [Intel-xe] ○ CI.BAT: info for series starting with [1/5] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkk412rt.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jose.souza@intel.com \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.