From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: Alexander Usyskin <alexander.usyskin@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Tomas Winkler <tomas.winkler@intel.com>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Vitaly Lubart <vitaly.lubart@intel.com>
Subject: Re: [Intel-gfx] [PATCH 07/20] drm/i915/gsc: skip irq initialization if using polling
Date: Mon, 11 Apr 2022 14:30:33 -0700 [thread overview]
Message-ID: <796c188e-615d-0027-125c-484b11c85e9d@intel.com> (raw)
In-Reply-To: <20220407125839.1479249-8-alexander.usyskin@intel.com>
On 4/7/2022 5:58 AM, Alexander Usyskin wrote:
> From: Vitaly Lubart <vitaly.lubart@intel.com>
>
> If we use polling instead of interrupts,
> irq initialization should be skipped.
This needs at least a 1 line explanation if why we might need to use
polling. Something like "some platforms require the host to poll on the
GSC reply instead of relaying on the interrupts. For those platforms,
irq initialization should be skipped."
>
> Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_gsc.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c b/drivers/gpu/drm/i915/gt/intel_gsc.c
> index 21e860861f0b..280dba4fd32d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gsc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
> @@ -40,6 +40,7 @@ struct gsc_def {
> const char *name;
> unsigned long bar;
> size_t bar_size;
> + bool use_polling;
> };
>
> /* gsc resources and definitions (HECI1 and HECI2) */
> @@ -97,6 +98,10 @@ static void gsc_init_one(struct drm_i915_private *i915,
> return;
> }
>
> + /* skip irq initialization */
> + if (def->use_polling)
> + goto add_device;
We tend to limit the use of gotos to the error paths, so I'd prefer it
if this was flipped to avoid it, i.e.:
if (!def->use_polling) {
/* set up irqs */
[...]
}
But not a blocker. With the commit message updated:
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Daniele
> +
> intf->irq = irq_alloc_desc(0);
> if (intf->irq < 0) {
> drm_err(&i915->drm, "gsc irq error %d\n", intf->irq);
> @@ -109,6 +114,7 @@ static void gsc_init_one(struct drm_i915_private *i915,
> goto fail;
> }
>
> +add_device:
> adev = kzalloc(sizeof(*adev), GFP_KERNEL);
> if (!adev)
> goto fail;
> @@ -162,10 +168,8 @@ static void gsc_irq_handler(struct intel_gt *gt, unsigned int intf_id)
> return;
> }
>
> - if (gt->gsc.intf[intf_id].irq < 0) {
> - drm_err_ratelimited(>->i915->drm, "GSC irq: irq not set");
> + if (gt->gsc.intf[intf_id].irq < 0)
> return;
> - }
>
> ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
> if (ret)
next prev parent reply other threads:[~2022-04-11 21:30 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 12:58 [Intel-gfx] [PATCH 00/20] GSC support for XeHP SDV and DG2 platforms Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 01/20] drm/i915/gsc: add gsc as a mei auxiliary device Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 02/20] mei: add support for graphics system controller (gsc) devices Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 03/20] mei: gsc: setup char driver alive in spite of firmware handshake failure Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 04/20] mei: gsc: add runtime pm handlers Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 05/20] mei: gsc: retrieve the firmware version Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 06/20] HAX: drm/i915: force INTEL_MEI_GSC on for CI Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 07/20] drm/i915/gsc: skip irq initialization if using polling Alexander Usyskin
2022-04-11 21:30 ` Ceraolo Spurio, Daniele [this message]
2022-04-07 12:58 ` [Intel-gfx] [PATCH 08/20] drm/i915/gsc: add slow_fw flag to the mei auxiliary device Alexander Usyskin
2022-04-11 21:34 ` Ceraolo Spurio, Daniele
2022-04-07 12:58 ` [Intel-gfx] [PATCH 09/20] drm/i915/gsc: add slow_fw flag to the gsc device definition Alexander Usyskin
2022-04-11 21:36 ` Ceraolo Spurio, Daniele
2022-04-07 12:58 ` [Intel-gfx] [PATCH 10/20] drm/i915/gsc: add GSC XeHP SDV platform definition Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 11/20] mei: gsc: use polling instead of interrupts Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 12/20] mei: gsc: wait for reset thread on stop Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 13/20] mei: extend timeouts on slow devices Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 14/20] drm/i915/dg2: add gsc with special gsc bar offsets Alexander Usyskin
2022-04-13 19:12 ` Ceraolo Spurio, Daniele
2022-04-07 12:58 ` [Intel-gfx] [PATCH 15/20] mei: bus: export common mkhi definitions into a separate header Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 16/20] mei: mkhi: add memory ready command Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 17/20] mei: gsc: setup gsc extended operational memory Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 18/20] mei: gsc: add transition to PXP mode in resume flow Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 19/20] mei: debugfs: add pxp mode to devstate in debugfs Alexander Usyskin
2022-04-07 12:58 ` [Intel-gfx] [PATCH 20/20] drm/i915/gsc: allocate extended operational memory in LMEM Alexander Usyskin
2022-04-08 10:54 ` Matthew Auld
2022-04-07 16:13 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GSC support for XeHP SDV and DG2 platforms Patchwork
2022-04-07 16:14 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-07 16:49 ` [Intel-gfx] ✗ Fi.CI.BAT: 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=796c188e-615d-0027-125c-484b11c85e9d@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=airlied@linux.ie \
--cc=alexander.usyskin@intel.com \
--cc=daniel@ffwll.ch \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=tomas.winkler@intel.com \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=vitaly.lubart@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