All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>,
	<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/xe/guc: Prevent use of uninitialized mutex
Date: Tue, 2 Jul 2024 16:28:53 -0400	[thread overview]
Message-ID: <ZoRjBeJFLrAorhLR@intel.com> (raw)
In-Reply-To: <e5e80301-f68d-4301-9dd6-cf49fe441884@intel.com>

On Tue, Jul 02, 2024 at 06:54:05PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 02.07.2024 18:12, Rodrigo Vivi wrote:
> > On Mon, Jul 01, 2024 at 04:15:28PM -0700, Vinay Belgaumkar wrote:
> >> When skip_guc_pc is set and/or this is for a VF.
> >>
> >> Fixes: 3b1592fb7835 ("drm/xe/lnl: Apply Wa_22019338487")
> >> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
> >> ---
> >>  drivers/gpu/drm/xe/xe_guc_pc.c | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c b/drivers/gpu/drm/xe/xe_guc_pc.c
> >> index d88f5e960fbd..f7b468930697 100644
> >> --- a/drivers/gpu/drm/xe/xe_guc_pc.c
> >> +++ b/drivers/gpu/drm/xe/xe_guc_pc.c
> >> @@ -26,6 +26,7 @@
> >>  #include "xe_mmio.h"
> >>  #include "xe_pcode.h"
> >>  #include "xe_pm.h"
> >> +#include "xe_sriov.h"
> >>  #include "xe_wa.h"
> >>  
> >>  #define MCHBAR_MIRROR_BASE_SNB	0x140000
> >> @@ -825,6 +826,9 @@ int xe_guc_pc_restore_stashed_freq(struct xe_guc_pc *pc)
> >>  {
> >>  	int ret = 0;
> >>  
> >> +	if (IS_SRIOV_VF(pc_to_xe(pc)) 
> > 
> > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > 
> > are all the other accesses protected?
> > likely because the freq sysfs is not available in VF mode?
> 
> in the VF mode we explicitly set info.skip_guc_pc = true and this flag
> is also used by xe_gt_freq_init() which setup sysfs
> 
> [1]
> https://gitlab.freedesktop.org/drm/xe/kernel/-/commit/65336c3fa2cf7f272067be9193303d1ab7c42190
> 
> > 
> > || pc_to_xe(pc)->info.skip_guc_pc)
> >> +		return 0;
> >> +
> > 
> > I don't like this skip_guc_pc... we might revisit later
> > to find a cleaner way...
> 
> +1
> 
> also IMO it is little confusing that xe_guc_pc is still doing some stuff
> if the skip_guc_pc flag is set

indeed, this is also annoying me...

> 
> maybe we should have xe_power component that will relay stuff to
> xe_guc_pc only if GuC PC is enabled and xe_guc_pc itself will be just
> implementing the GuC protocol details ?

well, we already have the xe_pm for power management..
but also xe_gt_freq, perhaps the right place for many of the
raw freq management that is done in here...

and xe_gt_idle for the raw rc6 things...

we need to adjust this layer and leave it really only for guc_pc
interaction.

> 
> > 
> > anyway, let's move with this patch. the rest is follow up.
> > 
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> >>  	mutex_lock(&pc->freq_lock);
> >>  	ret = pc_set_max_freq(pc, pc->stashed_max_freq);
> >>  	if (!ret)
> >> -- 
> >> 2.38.1
> >>

      reply	other threads:[~2024-07-02 20:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-01 23:15 [PATCH 1/2] drm/xe/guc: Prevent use of uninitialized mutex Vinay Belgaumkar
2024-07-01 23:15 ` [PATCH 2/2] drm/xe/bmg: Apply Wa_22019338487 Vinay Belgaumkar
2024-07-01 23:21 ` ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe/guc: Prevent use of uninitialized mutex Patchwork
2024-07-01 23:22 ` ✓ CI.checkpatch: " Patchwork
2024-07-01 23:23 ` ✓ CI.KUnit: " Patchwork
2024-07-01 23:35 ` ✓ CI.Build: " Patchwork
2024-07-01 23:37 ` ✓ CI.Hooks: " Patchwork
2024-07-01 23:38 ` ✓ CI.checksparse: " Patchwork
2024-07-02  0:01 ` ✓ CI.BAT: " Patchwork
2024-07-02  0:59 ` ✗ CI.FULL: failure " Patchwork
2024-07-03  0:19   ` Belgaumkar, Vinay
2024-07-02 16:12 ` [PATCH 1/2] " Rodrigo Vivi
2024-07-02 16:54   ` Michal Wajdeczko
2024-07-02 20:28     ` Rodrigo Vivi [this message]

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=ZoRjBeJFLrAorhLR@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michal.wajdeczko@intel.com \
    --cc=vinay.belgaumkar@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.