All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chauhan, Shekhar" <shekhar.chauhan@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: Define all possible engines in media IP descriptors
Date: Thu, 18 Apr 2024 09:48:37 +0530	[thread overview]
Message-ID: <83d66294-c089-467b-a65c-e90314613caa@intel.com> (raw)
In-Reply-To: <44845ee2-79bf-4641-ad73-ffb88a23ce0c@intel.com>


On 4/18/2024 09:46, Chauhan, Shekhar wrote:
>
> On 4/17/2024 23:48, Lucas De Marchi wrote:
>> On Wed, Apr 17, 2024 at 08:26:22AM GMT, Matt Roper wrote:
>>> Rather than trying to identify exactly which engines are available on
>>> each platform in the IP descriptor, just include the list of all media
>>> engines that the IP could theoretically support (i.e., 8 VCS + 4 VECS).
>>> We still rely on the media fuse registers to tell us which specific
>>> engine instances are actually present on a given platform, so there
>>> shouldn't be any functional change.  This will help prevent mistakes
>>> with engine numbering (for example ambiguity about whether the 2nd VCS
>>> engine on a platform with exactly two engines is numbered "VCS1" or
>>> "VCS2") and will also future-proof the code a bit more in case new SKUs
>>> or platform refreshes extend the engine list in the future.
>>>
>>> Note that the media fuse register technically has an 8-bit field for
>>> VECS engine presence starting on Xe2.  However there's still no MMIO
>>> register range reserved for VE engines above VECS3, so VE0-VE3 is still
>>> consider the "maximum" VE engine mask that the driver can support for
>>> now.
>>>
>>> Bspec: 52614, 52615, 62567
>>> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>>
>> I remember we tried something similar for BCS and had to revert. However
>> for media it seems we have fuses available on all platforms, so should
>> be better handled by the current code.
>>
>> Assuming CI is happy,
>>
>> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>
>> Lucas De Marchi
>>
>>> ---
>>> drivers/gpu/drm/xe/xe_pci.c | 16 +++++++++-------
>>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
>>> index 3b30353dbc09..0d21306f8995 100644
>>> --- a/drivers/gpu/drm/xe/xe_pci.c
>>> +++ b/drivers/gpu/drm/xe/xe_pci.c
>>> @@ -185,8 +185,8 @@ static const struct xe_media_desc media_xem = {
>>>     .rel = 0,
>>>
>>>     .hw_engine_mask =
>>> -        BIT(XE_HW_ENGINE_VCS0) | BIT(XE_HW_ENGINE_VCS2) |
>>> -        BIT(XE_HW_ENGINE_VECS0),
>>> +        GENMASK(XE_HW_ENGINE_VCS7, XE_HW_ENGINE_VCS0) |
>>> +        GENMASK(XE_HW_ENGINE_VECS3, XE_HW_ENGINE_VECS0),
>>> };
>>>
>>> static const struct xe_media_desc media_xehpm = {
>>> @@ -195,21 +195,23 @@ static const struct xe_media_desc media_xehpm = {
>>>     .rel = 55,
>>>
>>>     .hw_engine_mask =
>>> -        BIT(XE_HW_ENGINE_VCS0) | BIT(XE_HW_ENGINE_VCS2) |
>>> -        BIT(XE_HW_ENGINE_VECS0) | BIT(XE_HW_ENGINE_VECS1),
>>> +        GENMASK(XE_HW_ENGINE_VCS7, XE_HW_ENGINE_VCS0) |
>>> +        GENMASK(XE_HW_ENGINE_VECS3, XE_HW_ENGINE_VECS0),
>>> };
>>>
>>> static const struct xe_media_desc media_xelpmp = {
>>>     .name = "Xe_LPM+",
>>>     .hw_engine_mask =
>>> -        BIT(XE_HW_ENGINE_VCS0) | BIT(XE_HW_ENGINE_VCS2) |
>>> -        BIT(XE_HW_ENGINE_VECS0) | BIT(XE_HW_ENGINE_GSCCS0)
>>> +        GENMASK(XE_HW_ENGINE_VCS7, XE_HW_ENGINE_VCS0) |
>>> +        GENMASK(XE_HW_ENGINE_VECS3, XE_HW_ENGINE_VECS0) |
>>> +        BIT(XE_HW_ENGINE_GSCCS0)
>>> };
>>>
>>> static const struct xe_media_desc media_xe2 = {
>>>     .name = "Xe2_LPM / Xe2_HPM",
>>>     .hw_engine_mask =
>>> -        BIT(XE_HW_ENGINE_VCS0) | BIT(XE_HW_ENGINE_VECS0), /* TODO: 
>>> GSC0 */
>>> +        GENMASK(XE_HW_ENGINE_VCS7, XE_HW_ENGINE_VCS0) |
>>> +        GENMASK(XE_HW_ENGINE_VECS3, XE_HW_ENGINE_VECS0), /* TODO: 
>>> GSC0 */
> Are we correct in excluding the 4 new additions that are part of a new 
> HSD, stated in BSpec 62567?
Correction: Not new, rather, different*
>>> };
>>>
>>> static const struct xe_device_desc tgl_desc = {
>>> -- 
>>> 2.44.0
>>>
-- 
-shekhar


  reply	other threads:[~2024-04-18  4:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 15:26 [PATCH] drm/xe: Define all possible engines in media IP descriptors Matt Roper
2024-04-17 15:38 ` ✓ CI.Patch_applied: success for " Patchwork
2024-04-17 15:38 ` ✓ CI.checkpatch: " Patchwork
2024-04-17 15:39 ` ✓ CI.KUnit: " Patchwork
2024-04-17 15:55 ` ✓ CI.Build: " Patchwork
2024-04-17 15:58 ` ✓ CI.Hooks: " Patchwork
2024-04-17 16:13 ` ✓ CI.checksparse: " Patchwork
2024-04-17 17:09 ` ✓ CI.BAT: " Patchwork
2024-04-17 18:18 ` [PATCH] " Lucas De Marchi
2024-04-18  4:16   ` Chauhan, Shekhar
2024-04-18  4:18     ` Chauhan, Shekhar [this message]
2024-04-19 14:23       ` Matt Roper
2024-04-22  3:12         ` Chauhan, Shekhar
2024-04-19  3:39 ` ✓ CI.FULL: success for " Patchwork
2024-04-19 14:27   ` Matt Roper

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=83d66294-c089-467b-a65c-e90314613caa@intel.com \
    --to=shekhar.chauhan@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.d.roper@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.