Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's
Date: Wed, 20 Apr 2022 16:32:39 +0000	[thread overview]
Message-ID: <ee1506a5a7bbbacf112a9361ff0a56ab5a3bf6b7.camel@intel.com> (raw)
In-Reply-To: <87wnfkwb8b.wl-ashutosh.dixit@intel.com>

On Tue, 2022-04-19 at 22:54 -0700, Dixit, Ashutosh wrote:
> On Fri, 15 Apr 2022 03:21:26 -0700, Rodrigo Vivi wrote:
> > On Thu, Apr 14, 2022 at 03:31:07PM -0700, Dixit, Ashutosh wrote:
> > > On Thu, 14 Apr 2022 06:28:57 -0700, Jani Nikula wrote:
> > > > 
> > > > On Wed, 13 Apr 2022, Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > > wrote:
> > > > > Each gt contains an independent instance of pcode. Extend
> > > > > pcode functions
> > > > > to interface with pcode on different gt's. Previous (GT0)
> > > > > pcode read/write
> > > > > interfaces are preserved.
> > > > 
> > > > The big problem here is that this hard couples display code to
> > > > gt code,
> > > > while we're trying hard to go the opposite direction. It
> > > > doesn't matter
> > > > that the existing interfaces are preserved as wrappers when it
> > > > relies on
> > > > an intel_gt being available (via i915->gt0).
> > 
> > I don't believe there is a big problem in here...
> > 
> > please note the intel_pcode.h is keeping the abstraction for
> > display
> > 
> > #define snb_pcode_write_timeout(i915, mbox, val, fast_timeout_us,
> > slow_timeout_ms) \
> >         intel_gt_pcode_write_timeout(&(i915)->gt0, mbox, val,
> > fast_timeout_us, slow_timeout_ms)
> > 
> > #define snb_pcode_write(i915, mbox, val) \
> >         snb_pcode_write_timeout(i915, mbox, val, 500, 0)
> > 
> > display only uses these macros that Ashutosh didn't touch.
> > 
> > > > 
> > > > Note how 'git grep intel_gt -- drivers/gpu/drm/i915/display/'
> > > > matches
> > > > only 1 line.
> > 
> > As well with the patches applied:
> > 
> > $ git log --oneline -1
> > 1f58f1195478 (HEAD -> drm-tip) drm/i915/gt: Expose per-gt RPS
> > defaults in sysfs
> > 
> > $ git grep intel_gt -- drivers/gpu/drm/i915/display/
> > drivers/gpu/drm/i915/display/intel_display.c:          
> > intel_gt_set_wedged(to_gt(dev_priv));
> > 
> > > 
> > > Hi Jani, would you have suggestions about how to do this (handle
> > > pcode on
> > > multiple gt's)? The thinking was this patch would be a
> > > straightforward way
> > > to avoid code duplication. Also:
> > 
> > Maybe it is just a matter of renaming the macros used by display
> > in intel_pcode.h to reflect that it should be used by display only?
> 
> In v2 I have added a patch ([PATCH 4/9] drm/i915/gt: Convert callers
> to
> user per-gt pcode functions) which correctly calls per-gt pcode
> functions
> where this is required. With this patch only display functions (and
> one
> other caller) are left calling the "global scope"
> snb_pcode_read/write*
> functions. So the legacy snb_pcode_read/write* are now basically
> being used
> only by display. Let's see if Jani is ok with this. Thanks.

Jani is not happy with this abstraction because it still creates some
dependency and also no with the name intel_gt_pcode_ in the
functions...

He has some valid points.

I believe the right way to do this is to keep intel_pcode totally clean
from intel_gt and only receive intel_uncore as the argument. Then, if
needed we create display/intel_display_pcode and/or gt/intel_gt_pcode
with the needed abstractions... but better with none I'd say.







  reply	other threads:[~2022-04-20 16:33 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 18:11 [Intel-gfx] [PATCH 0/8] drm/i915: Media freq factor and per-gt enhancements/fixes Ashutosh Dixit
2022-04-13 18:11 ` [Intel-gfx] [PATCH 1/8] drm/i915: Introduce has_media_ratio_mode Ashutosh Dixit
2022-04-15 10:26   ` Rodrigo Vivi
2022-04-13 18:11 ` [Intel-gfx] [PATCH 2/8] drm/i915/gt: Add media freq factor to per-gt sysfs Ashutosh Dixit
2022-04-13 18:11 ` [Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's Ashutosh Dixit
2022-04-14 13:28   ` Jani Nikula
2022-04-14 22:31     ` Dixit, Ashutosh
2022-04-15 10:21       ` Rodrigo Vivi
2022-04-20  5:54         ` Dixit, Ashutosh
2022-04-20 16:32           ` Vivi, Rodrigo [this message]
2022-04-26  7:42             ` Jani Nikula
2022-04-13 18:11 ` [Intel-gfx] [PATCH 4/8] drm/i915/pcode: Add a couple of pcode helpers Ashutosh Dixit
2022-04-15 10:31   ` Rodrigo Vivi
2022-04-19  1:23     ` Dixit, Ashutosh
2022-04-13 18:11 ` [Intel-gfx] [PATCH 5/8] drm/i915/gt: Add media RP0/RPn to per-gt sysfs Ashutosh Dixit
2022-04-25  9:39   ` Kamil Konieczny
2022-04-26  0:43     ` Dixit, Ashutosh
2022-04-13 18:11 ` [Intel-gfx] [PATCH 6/8] drm/i915/gt: Fix memory leaks in " Ashutosh Dixit
2022-04-13 19:14   ` Dixit, Ashutosh
2022-04-13 18:11 ` [Intel-gfx] [PATCH 7/8] drm/i915/gt: Expose per-gt RPS defaults in sysfs Ashutosh Dixit
2022-04-13 18:11 ` [Intel-gfx] [PATCH 8/8] drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs Ashutosh Dixit
2022-04-14  0:38 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Media freq factor and per-gt enhancements/fixes Patchwork
2022-04-14  0:38 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-14  1:00 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-04-14  5:57   ` Dixit, Ashutosh
2022-04-14  7:11     ` Vudum, Lakshminarayana
2022-04-14  6:43 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-14  9:27 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-04-20  5:21 ` [Intel-gfx] [PATCH v2 0/9] " Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 1/9] drm/i915: Introduce has_media_ratio_mode Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 2/9] drm/i915/gt: Add media freq factor to per-gt sysfs Ashutosh Dixit
2022-04-21 20:57     ` Rodrigo Vivi
2022-04-26  0:29       ` Dixit, Ashutosh
2022-04-20  5:21   ` [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 4/9] drm/i915/gt: Convert callers to user per-gt pcode functions Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 5/9] drm/i915/pcode: Add a couple of pcode helpers Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 6/9] drm/i915/gt: Add media RP0/RPn to per-gt sysfs Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in " Ashutosh Dixit
2022-04-20 12:17     ` Andrzej Hajda
2022-04-20 16:12       ` Dixit, Ashutosh
2022-04-20 19:51         ` Andrzej Hajda
2022-04-24 22:36           ` Andi Shyti
2022-04-27 20:46             ` Dixit, Ashutosh
2022-04-28 14:36               ` Andrzej Hajda
2022-04-29  4:25                 ` Dixit, Ashutosh
2022-05-02  6:22                   ` Andrzej Hajda
2022-05-03  4:29                     ` Dixit, Ashutosh
2022-04-20  5:21   ` [Intel-gfx] [PATCH 8/9] drm/i915/gt: Expose per-gt RPS defaults in sysfs Ashutosh Dixit
2022-04-20  5:21   ` [Intel-gfx] [PATCH 9/9] drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs Ashutosh Dixit
2022-04-20  6:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Media freq factor and per-gt enhancements/fixes Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2022-04-29 19:56 [Intel-gfx] [PATCH v4 0/8] " Ashutosh Dixit
2022-04-29 19:56 ` [Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's Ashutosh Dixit
2022-05-02 12:54   ` Rodrigo Vivi
2022-05-10  6:51   ` Andi Shyti
2022-05-10  7:34   ` Tvrtko Ursulin
2022-05-10  7:43     ` Jani Nikula
2022-05-11  5:26       ` Dixit, Ashutosh
2022-05-11  8:18         ` Tvrtko Ursulin
2022-05-12  4:28           ` Dixit, Ashutosh

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=ee1506a5a7bbbacf112a9361ff0a56ab5a3bf6b7.camel@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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