[Intel-xe] [PATCH 09/12] drm/xe/gsc: Add an interface for GSC packet submissions
John Harrison
john.c.harrison at intel.com
Tue Nov 14 19:32:18 UTC 2023
On 11/13/2023 13:19, Daniele Ceraolo Spurio wrote:
> On 11/13/2023 11:59 AM, John Harrison wrote:
>> On 10/27/2023 15:29, Daniele Ceraolo Spurio wrote:
>>> Communication with the GSC FW is done via input/output buffers, whose
>>> addresses are provided via a GSCCS command. The buffers contain a
>>> generic header and a client-specific packet (e.g. PXP, HDCP); the
>>> clients don't care about the header format and/or the GSCCS command in
>>> the batch, they only care about their client-specific header. This
>>> patch
>>> therefore introduces helpers that allow the callers to automatically
>>> fill in the input header, submit the GSCCS job and decode the output
>>> header, to make it so that the caller only needs to worry about their
>>> client-specific input and output messages.
>>>
>>> NOTE: this patch by itself only adds the interface so it does nothing,
>>> I've kept it separate for review but the plan is to squash it with the
>>> follow up patch before merge, so that the interface and the user are
>>> introduced at the same time.
>>>
>>> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>>> Cc: Alan Previn <alan.previn.teres.alexis at intel.com>
>>> Cc: Suraj Kandpal <suraj.kandpal at intel.com>
>>> ---
>>> drivers/gpu/drm/xe/Makefile | 1 +
>>> .../gpu/drm/xe/abi/gsc_command_header_abi.h | 46 +++++
>>> .../gpu/drm/xe/instructions/xe_gsc_commands.h | 2 +
>>> drivers/gpu/drm/xe/xe_gsc_submit.c | 170
>>> ++++++++++++++++++
>>> drivers/gpu/drm/xe/xe_gsc_submit.h | 30 ++++
>>> 5 files changed, 249 insertions(+)
>>> create mode 100644 drivers/gpu/drm/xe/abi/gsc_command_header_abi.h
>>> create mode 100644 drivers/gpu/drm/xe/xe_gsc_submit.c
>>> create mode 100644 drivers/gpu/drm/xe/xe_gsc_submit.h
>>>
>>> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
>>> index 4a442dcf4d79..876c122ad63c 100644
>>> --- a/drivers/gpu/drm/xe/Makefile
>>> +++ b/drivers/gpu/drm/xe/Makefile
>>> @@ -58,6 +58,7 @@ xe-y += xe_bb.o \
>>> xe_force_wake.o \
>>> xe_ggtt.o \
>>> xe_gsc.o \
>>> + xe_gsc_submit.o \
>>> xe_gt.o \
>>> xe_gt_clock.o \
>>> xe_gt_debugfs.o \
>>> diff --git a/drivers/gpu/drm/xe/abi/gsc_command_header_abi.h
>>> b/drivers/gpu/drm/xe/abi/gsc_command_header_abi.h
>>> new file mode 100644
>>> index 000000000000..a4c2646803b5
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/xe/abi/gsc_command_header_abi.h
>>> @@ -0,0 +1,46 @@
>>> +/* SPDX-License-Identifier: MIT */
>>> +/*
>>> + * Copyright © 2023 Intel Corporation
>>> + */
>>> +
>>> +#ifndef _ABI_GSC_COMMAND_HEADER_ABI_H
>>> +#define _ABI_GSC_COMMAND_HEADER_ABI_H
>>> +
>>> +#include <linux/types.h>
>>> +
>>> +struct intel_gsc_mtl_header {
>> Is this all really MTL platform specific? Or is it GSC version specific?
>>
>> Given that the reset of the driver is moving to be IP version based
>> instead of platform name based, it seems like this should also be
>> based in some kind of version rather than platform name. Or are the
>> GSC versions all just relative to the platform anyway?
>
> GSC versioning is relative to the platform. As far as I'm aware the
> expectation so far is that this header will stay the same for LNL, but
> that's not a guarantee. Some of the binary headers for example are
> slightly different in the LNL blob (but the differences don't impact
> any of the areas we actually look at, so we can re-use the MTL code
> there as well). If you want to avoid the platform name I can call it
> intel_gsc_cmd_header for now and we can think about per-platform
> naming if we ever get different versions. Would that work?
If the GSC team are saying that this is a platform specific interface
then naming it by platform is fine by me. And keeping the name for
future platforms doesn't seem like an issue. That's how everything else
works - named by the device/platform/gen that introduced the feature and
still used for future devices/platforms/gens until the next version
comes along with a new name.
Reviewed-by: John Harrison <John.C.Harrison at Intel.Com>
>
> Daniele
>
>>
>> Apart from that, it all looks good to me.
>>
>> John.
>>
>
More information about the Intel-xe
mailing list