Searched hist:"27536 e03271da3dafcdddf735102041a26ad5bd0" (Results 1 – 3 of 3) sorted by relevance
| /openbmc/linux/drivers/gpu/drm/i915/gt/ |
| H A D | intel_gsc.c | diff 27536e03271da3dafcdddf735102041a26ad5bd0 Tue Sep 27 19:41:41 CDT 2022 Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> drm/i915/huc: track delayed HuC load with a fence
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.
Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.
Here's an example of the boot timing, captured with some logs added to
i915:
[ 17.908307] [drm] adding GSC device
[ 17.915717] [drm] i915 probe done
[ 22.282917] [drm] mei-gsc bound
[ 22.938153] [drm] HuC authenticated
Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.
The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.
v2: fix includes (Jani)
v5: gsc_notifier() remove unneeded ()
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-12-daniele.ceraolospurio@intel.com
|
| /openbmc/linux/drivers/gpu/drm/i915/gt/uc/ |
| H A D | intel_huc.h | diff 27536e03271da3dafcdddf735102041a26ad5bd0 Tue Sep 27 19:41:41 CDT 2022 Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> drm/i915/huc: track delayed HuC load with a fence
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.
Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.
Here's an example of the boot timing, captured with some logs added to
i915:
[ 17.908307] [drm] adding GSC device
[ 17.915717] [drm] i915 probe done
[ 22.282917] [drm] mei-gsc bound
[ 22.938153] [drm] HuC authenticated
Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.
The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.
v2: fix includes (Jani)
v5: gsc_notifier() remove unneeded ()
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-12-daniele.ceraolospurio@intel.com
|
| H A D | intel_huc.c | diff 27536e03271da3dafcdddf735102041a26ad5bd0 Tue Sep 27 19:41:41 CDT 2022 Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> drm/i915/huc: track delayed HuC load with a fence
Given that HuC load is delayed on DG2, this patch adds support for a fence
that can be used to wait for load completion. No waiters are added in this
patch (they're coming up in the next one), to keep the focus of the
patch on the tracking logic.
The full HuC loading flow on boot DG2 is as follows:
1) i915 exports the GSC as an aux device;
2) the mei-gsc driver is loaded on the aux device;
3) the mei-pxp component is loaded;
4) mei-pxp calls back into i915 and we load the HuC.
Between steps 1 and 2 there can be several seconds of gap, mainly due to
the kernel doing other work during the boot.
The resume flow is slightly different, because we don't need to
re-expose or re-probe the aux device, so we go directly to step 3 once
i915 and mei-gsc have completed their resume flow.
Here's an example of the boot timing, captured with some logs added to
i915:
[ 17.908307] [drm] adding GSC device
[ 17.915717] [drm] i915 probe done
[ 22.282917] [drm] mei-gsc bound
[ 22.938153] [drm] HuC authenticated
Also to note is that if something goes wrong during GSC HW init the
mei-gsc driver will still bind, but steps 3 and 4 will not happen.
The status tracking is done by registering a bus_notifier to receive a
callback when the mei-gsc driver binds, with a large enough timeout to
account for delays. Once mei-gsc is bound, we switch to a smaller
timeout to wait for the mei-pxp component to load.
The fence is signalled on HuC load complete or if anything goes wrong in
any of the tracking steps. Timeout are enforced via hrtimer callbacks.
v2: fix includes (Jani)
v5: gsc_notifier() remove unneeded ()
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-12-daniele.ceraolospurio@intel.com
|