Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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(&gt_to_xe(gt)->heci_gsc, iir);

Daniele

>


  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