All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	DRI Devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] [PATCH v5 2/7] drm/i915: Prepare for multiple GTs
Date: Sun, 6 Mar 2022 21:20:32 +0200	[thread overview]
Message-ID: <YiUJgKaZx3ulPRMa@intel.intel> (raw)
In-Reply-To: <730e317a-8672-c13b-fa8d-713e9e7bd0d7@intel.com>

Hi Andrzej,

[...]

> > -int intel_gt_probe_lmem(struct intel_gt *gt)
> > +static int intel_gt_probe_lmem(struct intel_gt *gt)
> >   {
> >   	struct drm_i915_private *i915 = gt->i915;
> > +	unsigned int instance = gt->info.id;
> >   	struct intel_memory_region *mem;
> >   	int id;
> >   	int err;
> > +	id = INTEL_REGION_LMEM_0 + instance;
> > +	if (drm_WARN_ON(&i915->drm, id >= INTEL_REGION_STOLEN_SMEM))
> 
> Do we need to check id correctness? wouldn't be enough to check it on
> initialization of gt->info.id.
> If yes, maybe (id > INTEL_REGION_LMEM_3) would be more readable, or (info.id
> < MAX_GT),  up to you.

yes, it's indeed redundant. Also because if that 'if' was true it
would be a bit more catastrophic than a simple warning. I will
remove it completely.

[...]

> > +	if (id) {
> > +		struct intel_uncore_mmio_debug *mmio_debug;
> > +		struct intel_uncore *uncore;
> > +
> > +		uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
> > +		if (!gt->uncore)
> > +			return -ENOMEM;
> 
> s/gt->uncore/uncore/

thanks!

[...]

> > +static void
> > +intel_gt_tile_cleanup(struct intel_gt *gt)
> > +{
> > +	intel_uncore_cleanup_mmio(gt->uncore);
> > +
> > +	if (gt->info.id) {
> > +		kfree(gt->uncore);
> > +		kfree(gt);
> 
> What about gt->uncore->debug ?

you don't want to leak anything? :)

will add it, nice catch! Thanks!

[...]

> > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
> > index 1c67ff735f18..144f989e4fef 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -320,9 +320,8 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
> >   	intel_device_info_subplatform_init(dev_priv);
> >   	intel_step_init(dev_priv);
> > -	intel_gt_init_early(to_gt(dev_priv), dev_priv);
> > +	/* All tiles share a single mmio_debug */
> 
> So why are we allocating mmio_debug in intel_gt_tile_setup ?

yes... this is a leftover from previous development cycles... I
will remove the comment. Indeed this goes only to tile 0.

[...]

> >   void intel_uncore_cleanup_mmio(struct intel_uncore *uncore)
> >   {
> > -	struct pci_dev *pdev = to_pci_dev(uncore->i915->drm.dev);
> > -
> > -	pci_iounmap(pdev, uncore->regs);
> > +	if (uncore->regs)
> > +		iounmap(uncore->regs);
> 
> 'if' is not necessary, up to you.

will remove, thanks!

[...]

Thank you for the review!
Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@linux.intel.com>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@gmail.com>,
	Andi Shyti <andi.shyti@linux.intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Intel GFX <intel-gfx@lists.freedesktop.org>,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	DRI Devel <dri-devel@lists.freedesktop.org>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	Matthew Auld <matthew.auld@intel.com>,
	Andi Shyti <andi@etezian.org>,
	Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
Subject: Re: [PATCH v5 2/7] drm/i915: Prepare for multiple GTs
Date: Sun, 6 Mar 2022 21:20:32 +0200	[thread overview]
Message-ID: <YiUJgKaZx3ulPRMa@intel.intel> (raw)
In-Reply-To: <730e317a-8672-c13b-fa8d-713e9e7bd0d7@intel.com>

Hi Andrzej,

[...]

> > -int intel_gt_probe_lmem(struct intel_gt *gt)
> > +static int intel_gt_probe_lmem(struct intel_gt *gt)
> >   {
> >   	struct drm_i915_private *i915 = gt->i915;
> > +	unsigned int instance = gt->info.id;
> >   	struct intel_memory_region *mem;
> >   	int id;
> >   	int err;
> > +	id = INTEL_REGION_LMEM_0 + instance;
> > +	if (drm_WARN_ON(&i915->drm, id >= INTEL_REGION_STOLEN_SMEM))
> 
> Do we need to check id correctness? wouldn't be enough to check it on
> initialization of gt->info.id.
> If yes, maybe (id > INTEL_REGION_LMEM_3) would be more readable, or (info.id
> < MAX_GT),  up to you.

yes, it's indeed redundant. Also because if that 'if' was true it
would be a bit more catastrophic than a simple warning. I will
remove it completely.

[...]

> > +	if (id) {
> > +		struct intel_uncore_mmio_debug *mmio_debug;
> > +		struct intel_uncore *uncore;
> > +
> > +		uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
> > +		if (!gt->uncore)
> > +			return -ENOMEM;
> 
> s/gt->uncore/uncore/

thanks!

[...]

> > +static void
> > +intel_gt_tile_cleanup(struct intel_gt *gt)
> > +{
> > +	intel_uncore_cleanup_mmio(gt->uncore);
> > +
> > +	if (gt->info.id) {
> > +		kfree(gt->uncore);
> > +		kfree(gt);
> 
> What about gt->uncore->debug ?

you don't want to leak anything? :)

will add it, nice catch! Thanks!

[...]

> > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
> > index 1c67ff735f18..144f989e4fef 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -320,9 +320,8 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
> >   	intel_device_info_subplatform_init(dev_priv);
> >   	intel_step_init(dev_priv);
> > -	intel_gt_init_early(to_gt(dev_priv), dev_priv);
> > +	/* All tiles share a single mmio_debug */
> 
> So why are we allocating mmio_debug in intel_gt_tile_setup ?

yes... this is a leftover from previous development cycles... I
will remove the comment. Indeed this goes only to tile 0.

[...]

> >   void intel_uncore_cleanup_mmio(struct intel_uncore *uncore)
> >   {
> > -	struct pci_dev *pdev = to_pci_dev(uncore->i915->drm.dev);
> > -
> > -	pci_iounmap(pdev, uncore->regs);
> > +	if (uncore->regs)
> > +		iounmap(uncore->regs);
> 
> 'if' is not necessary, up to you.

will remove, thanks!

[...]

Thank you for the review!
Andi

  reply	other threads:[~2022-03-06 19:20 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17 14:41 [Intel-gfx] [PATCH v5 0/7] Introduce multitile support Andi Shyti
2022-02-17 14:41 ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0 Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-02-28 19:53   ` [Intel-gfx] " Michal Wajdeczko
2022-02-28 19:53     ` Michal Wajdeczko
2022-03-01 15:19   ` [Intel-gfx] " Andrzej Hajda
2022-03-01 15:19     ` Andrzej Hajda
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 2/7] drm/i915: Prepare for multiple GTs Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-03-01 15:15   ` [Intel-gfx] " Andrzej Hajda
2022-03-01 15:15     ` Andrzej Hajda
2022-03-06 19:20     ` Andi Shyti [this message]
2022-03-06 19:20       ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 3/7] drm/i915/gt: add gt_is_root() helper Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-02-28 20:02   ` [Intel-gfx] " Michal Wajdeczko
2022-03-01 15:25     ` Andrzej Hajda
2022-03-06 19:23       ` Andi Shyti
2022-03-06 19:23         ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 4/7] drm/i915/gt: create per-tile sysfs interface Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-03-02 16:57   ` [Intel-gfx] " Andrzej Hajda
2022-03-02 16:57     ` Andrzej Hajda
2022-03-06 23:04     ` [Intel-gfx] " Andi Shyti
2022-03-06 23:04       ` Andi Shyti
2022-03-07 20:25       ` [Intel-gfx] " Andrzej Hajda
2022-03-07 20:25         ` Andrzej Hajda
2022-03-13 19:45         ` [Intel-gfx] " Andi Shyti
2022-03-13 19:45           ` Andi Shyti
2022-03-13 21:30           ` [Intel-gfx] " Andi Shyti
2022-03-13 21:30             ` Andi Shyti
2022-03-14 12:08           ` [Intel-gfx] " Andrzej Hajda
2022-03-14 12:08             ` Andrzej Hajda
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 " Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-02-17 15:34   ` [Intel-gfx] " Tvrtko Ursulin
2022-02-17 15:53     ` Andi Shyti
2022-02-17 15:53       ` Andi Shyti
2022-02-18  9:12       ` Tvrtko Ursulin
2022-02-18  9:21         ` Andi Shyti
2022-02-18  9:21           ` Andi Shyti
2022-02-18 10:46       ` Joonas Lahtinen
2022-02-21 17:12         ` Tvrtko Ursulin
2022-02-22  8:57           ` Andi Shyti
2022-02-22  8:57             ` Andi Shyti
2022-11-07  0:08             ` Dixit, Ashutosh
2022-11-07  0:08               ` Dixit, Ashutosh
2022-02-17 20:49   ` kernel test robot
2022-02-17 20:49     ` kernel test robot
2022-02-17 23:53   ` kernel test robot
2022-02-17 23:53     ` kernel test robot
2022-02-17 23:53     ` kernel test robot
2022-03-03 10:19   ` Andrzej Hajda
2022-03-03 10:19     ` Andrzej Hajda
2022-03-13 22:15     ` [Intel-gfx] " Andi Shyti
2022-03-13 22:15       ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-02-17 19:47   ` [Intel-gfx] " kernel test robot
2022-02-17 19:47     ` kernel test robot
2022-03-03 10:55   ` Andrzej Hajda
2022-03-03 10:55     ` Andrzej Hajda
2022-03-13 23:09     ` [Intel-gfx] " Andi Shyti
2022-03-13 23:09       ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: Adding new sysfs frequency attributes Andi Shyti
2022-02-17 14:41   ` Andi Shyti
2022-02-17 15:45   ` [Intel-gfx] " Andi Shyti
2022-02-17 15:45     ` Andi Shyti
2022-02-17 17:06     ` [Intel-gfx] " Sundaresan, Sujaritha
2022-02-17 17:06       ` Sundaresan, Sujaritha
2022-02-28 20:37   ` [Intel-gfx] " Michal Wajdeczko
2022-02-28 20:37     ` Michal Wajdeczko
2022-03-14  0:38     ` [Intel-gfx] " Andi Shyti
2022-03-14  0:38       ` Andi Shyti
2022-03-14  1:32       ` [Intel-gfx] " Sundaresan, Sujaritha
2022-03-14  1:32         ` Sundaresan, Sujaritha
2022-03-03 11:17   ` [Intel-gfx] " Andrzej Hajda
2022-03-03 11:17     ` Andrzej Hajda
2022-02-17 23:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce multitile support Patchwork
2022-02-17 23:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-17 23:40 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-02-17 23:40 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " 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=YiUJgKaZx3ulPRMa@intel.intel \
    --to=andi.shyti@linux.intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.auld@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.