From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's
Date: Fri, 29 Apr 2022 07:46:05 -0700 [thread overview]
Message-ID: <87zgk43q36.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <Ymvg7T5dLEeITS1x@intel.com>
On Fri, 29 Apr 2022 05:58:21 -0700, Rodrigo Vivi wrote:
>
> > @@ -1251,7 +1251,7 @@ static int i915_drm_resume(struct drm_device *dev)
> >
> > disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> >
> > - ret = intel_pcode_init(dev_priv);
> > + ret = intel_gt_pcode_init(dev_priv);
>
> I didn't like we have this indirection i915 -> gt -> i915...
> At the same time I understand you don't want to duplicate the for_each with
> the error msg and all in here.
>
> So, what about having in this file a
> static int __init_pcode(dev_priv)
> ?!
Sure, will fix.
> > diff --git a/drivers/gpu/drm/i915/intel_pcode.c b/drivers/gpu/drm/i915/intel_pcode.c
> > index ac727546868e..66020b2e461f 100644
> > --- a/drivers/gpu/drm/i915/intel_pcode.c
> > +++ b/drivers/gpu/drm/i915/intel_pcode.c
> > @@ -52,14 +52,12 @@ static int gen7_check_mailbox_status(u32 mbox)
> > }
> > }
> >
> > -static int __snb_pcode_rw(struct drm_i915_private *i915, u32 mbox,
> > +static int intel_pcode_rw(struct intel_uncore *uncore, u32 mbox,
>
> I'm not sure if I like the idea of the renaming here...
> I mean, it looks nicer indeed, but at the same time the "intel_"
> make it looks it is exported one.
Sure, will fix.
> > --- a/drivers/gpu/drm/i915/intel_pcode.h
> > +++ b/drivers/gpu/drm/i915/intel_pcode.h
> > @@ -8,17 +8,32 @@
> >
> > #include <linux/types.h>
> >
> > +struct intel_uncore;
> > struct drm_i915_private;
> >
> > -int snb_pcode_read(struct drm_i915_private *i915, u32 mbox, u32 *val, u32 *val1);
> > -int snb_pcode_write_timeout(struct drm_i915_private *i915, u32 mbox, u32 val,
> > - int fast_timeout_us, int slow_timeout_ms);
> > -#define snb_pcode_write(i915, mbox, val) \
> > +int intel_pcode_read(struct intel_uncore *uncore, u32 mbox, u32 *val, u32 *val1);
> > +
> > +int intel_pcode_write_timeout(struct intel_uncore *uncore, u32 mbox, u32 val,
> > + int fast_timeout_us, int slow_timeout_ms);
> > +
> > +#define intel_pcode_write(uncore, mbox, val) \
> > + intel_pcode_write_timeout(uncore, mbox, val, 500, 0)
> > +
> > +int intel_pcode_request(struct intel_uncore *uncore, u32 mbox, u32 request,
> > + u32 reply_mask, u32 reply, int timeout_base_ms);
> > +
> > +#define snb_pcode_read(i915, mbox, val, val1) \
> > + intel_pcode_read(&(i915)->uncore, mbox, val, val1)
> > +
> > +#define snb_pcode_write_timeout(i915, mbox, val, fast_timeout_us, slow_timeout_ms) \
> > + intel_pcode_write_timeout(&(i915)->uncore, mbox, val, fast_timeout_us, slow_timeout_ms)
> > +
> > +#define snb_pcode_write(i915, mbox, val) \
> > snb_pcode_write_timeout(i915, mbox, val, 500, 0)
> >
> > -int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request,
> > - u32 reply_mask, u32 reply, int timeout_base_ms);
> > +#define skl_pcode_request(i915, mbox, request, reply_mask, reply, timeout_base_ms) \
> > + intel_pcode_request(&(i915)->uncore, mbox, request, reply_mask, reply, timeout_base_ms)
>
> and for the exported one, since we are renaming it, shouldn't we rename
> all the users instead of creating these defines?
Ok, in that case we might as well retain the original function names
(snb_/skl_ etc. and just change the first argument to uncore)? So will do
that in the next rev unless we think we want to rename everything to
intel_?
Thanks.
--
Ashutosh
next prev parent reply other threads:[~2022-04-29 15:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 0:39 [Intel-gfx] [PATCH v3 0/9] drm/i915: Media freq factor and per-gt enhancements/fixes Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 1/9] drm/i915: Introduce has_media_ratio_mode Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 2/9] drm/i915/gt: Add media freq factor to per-gt sysfs Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's Ashutosh Dixit
2022-04-29 12:58 ` Rodrigo Vivi
2022-04-29 14:46 ` Dixit, Ashutosh [this message]
2022-04-29 0:39 ` [Intel-gfx] [PATCH 4/9] drm/i915/gt: Convert callers to use per-gt pcode functions Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 5/9] drm/i915/pcode: Add a couple of pcode helpers Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 6/9] drm/i915/gt: Add media RP0/RPn to per-gt sysfs Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in " Ashutosh Dixit
2022-04-29 0:39 ` [Intel-gfx] [PATCH 8/9] drm/i915/gt: Expose per-gt RPS defaults in sysfs Ashutosh Dixit
2022-04-29 12:42 ` Rodrigo Vivi
2022-04-29 0:39 ` [Intel-gfx] [PATCH 9/9] drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs Ashutosh Dixit
2022-04-29 12:42 ` Rodrigo Vivi
2022-04-29 0:57 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev3) Patchwork
2022-04-29 0:57 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-29 1:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-29 2:40 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-04-20 6:25 [Intel-gfx] [PATCH v2 0/9] drm/i915: Media freq factor and per-gt enhancements/fixes Ashutosh Dixit
2022-04-20 6:25 ` [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's Ashutosh Dixit
2022-04-24 19:08 ` Andi Shyti
2022-04-29 1:21 ` Dixit, Ashutosh
2022-04-26 7:55 ` Jani Nikula
2022-04-26 20:05 ` Dixit, Ashutosh
2022-04-13 18:11 [Intel-gfx] [PATCH 0/8] drm/i915: Media freq factor and per-gt enhancements/fixes Ashutosh Dixit
2022-04-20 5:21 ` [Intel-gfx] [PATCH v2 0/9] " Ashutosh Dixit
2022-04-20 5:21 ` [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's Ashutosh Dixit
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=87zgk43q36.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox