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 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.