All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gupta, Anshuman" <anshuman.gupta@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	"Dixit, Ashutosh" <ashutosh.dixit@intel.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Wilson, Chris P" <chris.p.wilson@intel.com>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Dump i915 children runtime status
Date: Fri, 1 Apr 2022 15:42:38 +0000	[thread overview]
Message-ID: <b9082786922d4941a182441b01aa2eac@intel.com> (raw)
In-Reply-To: <87v8vs7v4v.fsf@intel.com>



> -----Original Message-----
> From: Jani Nikula <jani.nikula@linux.intel.com>
> Sent: Friday, April 1, 2022 7:40 PM
> To: Gupta, Anshuman <anshuman.gupta@intel.com>; Dixit, Ashutosh
> <ashutosh.dixit@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Wilson, Chris P <chris.p.wilson@intel.com>;
> Vivi, Rodrigo <rodrigo.vivi@intel.com>
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/debugfs: Dump i915 children runtime
> status
> 
> On Fri, 01 Apr 2022, "Gupta, Anshuman" <anshuman.gupta@intel.com> wrote:
> >> -----Original Message-----
> >> From: Jani Nikula <jani.nikula@linux.intel.com>
> >> Sent: Friday, April 1, 2022 6:26 PM
> >> To: Gupta, Anshuman <anshuman.gupta@intel.com>; Dixit, Ashutosh
> >> <ashutosh.dixit@intel.com>
> >> Cc: intel-gfx@lists.freedesktop.org; Wilson, Chris P
> >> <chris.p.wilson@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>
> >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/debugfs: Dump i915 children
> >> runtime status
> >>
> >> On Fri, 01 Apr 2022, "Gupta, Anshuman" <anshuman.gupta@intel.com>
> wrote:
> >> >> -----Original Message-----
> >> >> From: Jani Nikula <jani.nikula@linux.intel.com>
> >> >> Sent: Friday, April 1, 2022 5:31 PM
> >> >> To: Dixit, Ashutosh <ashutosh.dixit@intel.com>; Gupta, Anshuman
> >> >> <anshuman.gupta@intel.com>
> >> >> Cc: intel-gfx@lists.freedesktop.org; Wilson, Chris P
> >> >> <chris.p.wilson@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>
> >> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Dump i915
> >> >> children runtime status
> >> >>
> >> >> On Tue, 29 Mar 2022, "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
> wrote:
> >> >> > On Mon, 28 Mar 2022 03:22:27 -0700, Anshuman Gupta wrote:
> >> >> >>
> >> >> >> +#ifdef CONFIG_PM
> >> >> >> +static int i915_runtime_dump_child_status(struct device *dev,
> >> >> >> +void
> >> >> >> +*data) {
> >> >> >> +	struct seq_file *m = data;
> >> >> >> +	const char *rpm_status;
> >> >> >> +
> >> >> >> +	/* Early return if runtime_pm is disabled */
> >> >> >> +	if (dev->power.disable_depth)
> >> >> >> +		return 0;
> >> >> >> +
> >> >> >> +	switch (dev->power.runtime_status) {
> >> >> >> +	case RPM_SUSPENDED:
> >> >> >> +		rpm_status = "suspended";
> >> >> >> +		break;
> >> >> >> +	case RPM_SUSPENDING:
> >> >> >> +		rpm_status = "suspending";
> >> >> >> +		break;
> >> >> >> +	case RPM_RESUMING:
> >> >> >> +		rpm_status = "resuming";
> >> >> >> +		break;
> >> >> >> +	case RPM_ACTIVE:
> >> >> >> +		rpm_status = "active";
> >> >> >> +		break;
> >> >> >> +	default:
> >> >> >> +		rpm_status = "unknown";
> >> >> >> +	}
> >> >> >> +
> >> >> >> +	seq_printf(m, "\t%s %s: Runtime status: %s\n",
> dev_driver_string(dev),
> >> >> >> +		   dev_name(dev), rpm_status);
> >> >> >> +
> >> >> >> +	return 0;
> >> >> >> +}
> >> >> >> +#endif
> >> >> >
> >> >> > Maybe a nit, but perhaps defining a const array is better than
> >> >> > having a switch statement? Similar to what is done in
> >> >> > rtpm_status_str(). The function itself is very similar to
> >> >> > rtpm_status_str() so can probably benefit from that similarity.
> >> >> > Can perhaps even be nearly identical to
> >> >> > rtpm_status_str() (since that is static in the genpd (generic
> >> >> > power
> >> >> > domain) code).
> >> >> >
> >> >> > See also 2bd5306a8764 ("PM / Domains: add debugfs listing of
> >> >> > struct generic_pm_domain-s"), though I am not sure if genpd's
> >> >> > are applicable in our case and certainly look way out of scope for now.
> Thanks.
> >> >>
> >> >> See also /sys/devices/i915/power/runtime_status and
> >> >> /sys/devices/i915/power/runtime_active_kids.
> >> >>
> >> >> Kinda feels like the info should be made available there?
> >> > runtime_active_kids we are already printing by dev_priv->drm.dev-
> >> >power.child_count.
> >> > About runtime_status , we already prints usage count and pci device
> >> >power
> >> state, IMO that is sufficient for debug ?
> >> > If it is really needed , I will add dev->power.runtime_status in next revision.
> >>
> >> My point is, the patch at hand adds runtime pm status printing that
> >> isn't specific to drm or i915 into i915 debugfs. Why?
> >>
> >> What is the reason we should take on the burden of maintaining this
> >> while the right place for it might be in runtime pm code, benefiting
> >> other drivers in addition to ours?
> > Benefit is there to debug CI runtime suspend failures , we need to know the
> culprit child blocking i915 runtime PM.
> > runtime_active_kids just revels the count , it doesn't reveal the culprit children.
> 
> I understand. But how is that problem or the information specific to i915? Why
> should this be added to i915 instead of runtime pm infra?
> Surely this is not even a new problem; how do others currently figure this
> information out?
> 
> So I'm not going to block this if you all think this is a good idea. But the point is,
> the first solution should not be to add some i915 specific stuff when a more
> generic solution might exist or be preferred.
Hi Rafael,
Could you please provide your input,  about generic interface to dump the active children of a device.
Thanks,
Anshuman Gupta.
> 
> 
> BR,
> Jani.
> 
> 
> 
> 
> > Thanks,
> > Anshuman.
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> > Thanks,
> >> > Anshuman Gupta.
> >> >
> >> >
> >> >
> >> >
> >> >>
> >> >> BR,
> >> >> Jani.
> >> >>
> >> >> >
> >> >> >> +
> >> >> >>  static int i915_runtime_pm_status(struct seq_file *m, void
> >> >> >>*unused)
> >> >> >>  {
> >> >> >>	struct drm_i915_private *dev_priv = node_to_i915(m->private);
> >> >> >>@@
> >> >> >>-500,6 +534,10 @@ static int i915_runtime_pm_status(struct
> >> >> >>seq_file *m, void *unused)
> >> >> >>  #ifdef CONFIG_PM
> >> >> >>	seq_printf(m, "Usage count: %d\n",
> >> >> >>		   atomic_read(&dev_priv->drm.dev-
> >power.usage_count));
> >> >> >> +	seq_printf(m, "Runtime active children: %d\n",
> >> >> >> +		   atomic_read(&dev_priv->drm.dev-
> >power.child_count));
> >> >> >> +	device_for_each_child(&pdev->dev, m,
> >> >> >> +i915_runtime_dump_child_status);
> >> >> >> +
> >> >> >>  #else
> >> >> >>	seq_printf(m, "Device Power Management (CONFIG_PM)
> >> >> >>disabled\n");
> >> >> >>  #endif
> >> >> >> --
> >> >> >> 2.26.2
> >> >> >>
> >> >>
> >> >> --
> >> >> Jani Nikula, Intel Open Source Graphics Center
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-04-01 15:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-28 10:22 [Intel-gfx] [PATCH] drm/i915/debugfs: Dump i915 children runtime status Anshuman Gupta
2022-03-28 16:14 ` [Intel-gfx] ✗ Fi.CI.DOCS: warning for " Patchwork
2022-03-28 16:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-28 19:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-29 17:13 ` [Intel-gfx] [PATCH] " Nilawar, Badal
2022-03-29 23:09 ` Dixit, Ashutosh
2022-04-01 12:01   ` Jani Nikula
2022-04-01 12:40     ` Gupta, Anshuman
2022-04-01 12:55       ` Jani Nikula
2022-04-01 13:07         ` Gupta, Anshuman
2022-04-01 14:09           ` Jani Nikula
2022-04-01 15:42             ` Gupta, Anshuman [this message]
2022-04-01  7:57 ` [Intel-gfx] [PATCH v2] " Anshuman Gupta
2022-04-01 10:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: Dump i915 children runtime status (rev2) Patchwork
2022-04-01 12:09 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=b9082786922d4941a182441b01aa2eac@intel.com \
    --to=anshuman.gupta@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=chris.p.wilson@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=rafael.j.wysocki@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.