From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: "Usyskin, Alexander" <alexander.usyskin@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Winkler, Tomas" <tomas.winkler@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH 3/4] drm/xe/gsc: add gsc device support
Date: Wed, 13 Sep 2023 08:59:00 -0700 [thread overview]
Message-ID: <cf99d227-4fee-483a-ac51-fe8fc4acf579@intel.com> (raw)
In-Reply-To: <CY5PR11MB6366B470B6B6A72F32F2EB18EDF0A@CY5PR11MB6366.namprd11.prod.outlook.com>
On 9/13/2023 5:48 AM, Usyskin, Alexander wrote:
>>> +struct xe_gsc {
>> Please use a different name for this instead of just xe_gsc. In Xe we're
>> likely never going to fully use the GSC via HECI, only the GSCFI/CSC
>> part. In MTL and newer we also have the actual GSC part being split off
>> and placed inside GT (behind the GSCCS), so if we call this just xe_gsc
>> as well it'll be confusing. I suggest calling this something like
>> xe_heci_gsc, xe_heci_interface or something like that. I had actually
>> suggested this for i915 as well
>> (https://patchwork.freedesktop.org/patch/509653/) but Tomas was
>> concerned it might make backporting fixes difficult, so I dropped it;
>> this is not a concern for Xe right now.
>>
>> Note that this means renaming all the exposed functions as well.
>>
>> Daniele
>>
> Sure, will rename it xe_heci_gsc and move to xe_device.
>
>>> diff --git a/drivers/gpu/drm/xe/xe_irq.c b/drivers/gpu/drm/xe/xe_irq.c
>>> index 1dee3e832eb5..1ae4cc9f1522 100644
>>> --- a/drivers/gpu/drm/xe/xe_irq.c
>>> +++ b/drivers/gpu/drm/xe/xe_irq.c
>>> @@ -128,6 +128,7 @@ void xe_irq_enable_hwe(struct xe_gt *gt)
>>> struct xe_device *xe = gt_to_xe(gt);
>>> u32 ccs_mask, bcs_mask;
>>> u32 irqs, dmask, smask;
>>> + u32 gsc_mask = GSC_IRQ_INTF(1);
>>>
>>> if (xe_device_guc_submission_enabled(xe)) {
>>> irqs = GT_RENDER_USER_INTERRUPT |
>>> @@ -180,6 +181,9 @@ void xe_irq_enable_hwe(struct xe_gt *gt)
>>> if (xe_hw_engine_mask_per_class(gt,
>> XE_ENGINE_CLASS_OTHER)) {
>>> xe_mmio_write32(gt, GUNIT_GSC_INTR_ENABLE,
>> irqs);
>>> xe_mmio_write32(gt, GUNIT_GSC_INTR_MASK,
>> ~irqs);
>>> + } else if (HAS_HECI_GSCFI(xe)) {
>>> + xe_mmio_write32(gt, GUNIT_GSC_INTR_ENABLE,
>> gsc_mask);
>>> + xe_mmio_write32(gt, GUNIT_GSC_INTR_MASK,
>> ~gsc_mask);
> Danielle, how this enablement should look when gsc_heci is not gt related?
> I'm somewhat confused here.
This one you should be able to leave as-is, and your check in
HAS_HECI_GSCFI is already at the xe device level and not at the gt
level. Unfortunately the mmio writes functions only allow a gt parameter
for now, so we need to stick with that (I believe there is a plan to
change it at some point).
What will need to change is xe_gsc_irq_handler(), but you can change
that to take the heci_gsc as a parameter and then do:
xe_gsc_irq_handler(>_to_xe(gt)->heci_gsc, iir);
Daniele
>
next prev parent reply other threads:[~2023-09-13 15:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 13:08 [Intel-xe] [PATCH 0/4] drm/xe/gsc: add initial gsc support Alexander Usyskin
2023-09-12 13:08 ` [Intel-xe] [PATCH 1/4] drm/xe/gsc: add HECI2 register offsets Alexander Usyskin
2023-09-12 13:08 ` [Intel-xe] [PATCH 2/4] drm/xe/gsc: add has_heci_gscfi indication to device Alexander Usyskin
2023-09-12 13:08 ` [Intel-xe] [PATCH 3/4] drm/xe/gsc: add gsc device support Alexander Usyskin
2023-09-12 15:05 ` Daniele Ceraolo Spurio
2023-09-13 12:48 ` Usyskin, Alexander
2023-09-13 15:59 ` Daniele Ceraolo Spurio [this message]
2023-09-12 13:08 ` [Intel-xe] [PATCH 4/4] mei: gsc: add support for auxiliary device created by Xe driver Alexander Usyskin
2023-09-12 15:14 ` [Intel-xe] ✓ CI.Patch_applied: success for drm/xe/gsc: add initial gsc support Patchwork
2023-09-12 15:14 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-09-12 15:16 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-09-12 15:23 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-12 15:23 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-09-12 15:24 ` [Intel-xe] ✓ CI.checksparse: " 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=cf99d227-4fee-483a-ac51-fe8fc4acf579@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=alexander.usyskin@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=tomas.winkler@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