Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 12月, 2022 1 次提交
    • A
      drm/i915/pxp: Promote pxp subsystem to top-level of i915 · f67986b0
      由 Alan Previn 提交于 
      Starting with MTL, there will be two GT-tiles, a render and media
tile. PXP as a service for supporting workloads with protected
contexts and protected buffers can be subscribed by process
workloads on any tile. However, depending on the platform,
only one of the tiles is used for control events pertaining to PXP
operation (such as creating the arbitration session and session
tear-down).

PXP as a global feature is accessible via batch buffer instructions
on any engine/tile and the coherency across tiles is handled implicitly
by the HW. In fact, for the foreseeable future, we are expecting this
single-control-tile for the PXP subsystem.

In MTL, it's the standalone media tile (not the root tile) because
it contains the VDBOX and KCR engine (among the assets PXP relies on
for those events).

Looking at the current code design, each tile is represented by the
intel_gt structure while the intel_pxp structure currently hangs off the
intel_gt structure.

Keeping the intel_pxp structure within the intel_gt structure makes some
internal functionalities more straight forward but adds code complexity to
code readability and maintainibility to many external-to-pxp subsystems
which may need to pick the correct intel_gt structure. An example of this
would be the intel_pxp_is_active or intel_pxp_is_enabled functionality
which should be viewed as a global level inquiry, not a per-gt inquiry.

That said, this series promotes the intel_pxp structure into the
drm_i915_private structure making it a top-level subsystem and the PXP
subsystem will select the control gt internally and keep a pointer to
it for internal reference.

This promotion comes with two noteworthy changes:

1. Exported pxp functions that are called by external subsystems
   (such as intel_pxp_enabled/active) will have to check implicitly
   if i915->pxp is valid as that structure will not be allocated
   for HW that doesn't support PXP.

2. Since GT is now considered a soft-dependency of PXP we are
   ensuring that GT init happens before PXP init and vice versa
   for fini. This causes a minor ordering change whereby we previously
   called intel_pxp_suspend after intel_uc_suspend but now is before
   i915_gem_suspend_late but the change is required for correct
   dependency flows. Additionally, this re-order change doesn't
   have any impact because at that point in either case, the top level
   entry to i915 won't observe any PXP events (since the GPU was
   quiesced during suspend_prepare). Also, any PXP event doesn't
   really matter when we disable the PXP HW (global GT irqs are
   already off anyway, so even if there was a bug that generated
   spurious events we wouldn't see it and we would just clean it
   up on resume which is okay since the default fallback action
   for PXP would be to keep the sessions off at this suspend stage).

Changes from prior revs:
  v11: - Reformat a comment (Tvrtko).
  v10: - Change the code flow for intel_pxp_init to make it more
         cleaner and readible with better comments explaining the
         difference between full-PXP-feature vs the partial-teelink
         inits depending on the platform. Additionally, only do
         the pxp allocation when we are certain the subsystem is
         needed. (Tvrtko).
   v9: - Cosmetic cleanups in supported/enabled/active. (Daniele).
       - Add comments for intel_pxp_init and pxp_get_ctrl_gt that
         explain the functional flow for when PXP is not supported
         but the backend-assets are needed for HuC authentication
         (Daniele and Tvrtko).
       - Fix two remaining functions that are accessible outside
         PXP that need to be checking pxp ptrs before using them:
         intel_pxp_irq_handler and intel_pxp_huc_load_and_auth
         (Tvrtko and Daniele).
       - User helper macro in pxp-debugfs (Tvrtko).
   v8: - Remove pxp_to_gt macro (Daniele).
       - Fix a bug in pxp_get_ctrl_gt for the case of MTL and we don't
         support GSC-FW on it. (Daniele).
       - Leave i915->pxp as NULL if we dont support PXP and in line
         with that, do additional validity check on i915->pxp for
         intel_pxp_is_supported/enabled/active (Daniele).
       - Remove unncessary include header from intel_gt_debugfs.c
         and check drm_minor i915->drm.primary (Daniele).
       - Other cosmetics / minor issues / more comments on suspend
         flow order change (Daniele).
   v7: - Drop i915_dev_to_pxp and in intel_pxp_init use 'i915->pxp'
         through out instead of local variable newpxp. (Rodrigo)
       - In the case intel_pxp_fini is called during driver unload but
         after i915 loading failed without pxp being allocated, check
         i915->pxp before referencing it. (Alan)
   v6: - Remove HAS_PXP macro and replace it with intel_pxp_is_supported
         because : [1] introduction of 'ctrl_gt' means we correct this
         for MTL's upcoming series now. [2] Also, this has little impact
         globally as its only used by PXP-internal callers at the moment.
       - Change intel_pxp_init/fini to take in i915 as its input to avoid
         ptr-to-ptr in init/fini calls.(Jani).
       - Remove the backpointer from pxp->i915 since we can use
         pxp->ctrl_gt->i915 if we need it. (Rodrigo).
   v5: - Switch from series to single patch (Rodrigo).
       - change function name from pxp_get_kcr_owner_gt to
         pxp_get_ctrl_gt.
       - Fix CI BAT failure by removing redundant call to intel_pxp_fini
         from driver-remove.
       - NOTE: remaining open still persists on using ptr-to-ptr
         and back-ptr.
   v4: - Instead of maintaining intel_pxp as an intel_gt structure member
         and creating a number of convoluted helpers that takes in i915 as
         input and redirects to the correct intel_gt or takes any intel_gt
         and internally replaces with the correct intel_gt, promote it to
         be a top-level i915 structure.
   v3: - Rename gt level helper functions to "intel_pxp_is_enabled/
         supported/ active_on_gt" (Daniele)
       - Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is
         supported as the new intel_pxp_is_supported_on_gt to check for
         PXP feature support vs the tee support for huc authentication.
         Fix pxp-debugfs-registration to use only the former to decide
         support. (Daniele)
       - Couple minor optimizations.
   v2: - Avoid introduction of new device info or gt variables and use
         existing checks / macros to differentiate the correct GT->PXP
         control ownership (Daniele Ceraolo Spurio)
       - Don't reuse the updated global-checkers for per-GT callers (such
         as other files within PXP) to avoid unnecessary GT-reparsing,
         expose a replacement helper like the prior ones. (Daniele).
   v1: - Add one more patch to the series for the intel_pxp suspend/resume
         for similar refactoring

References: https://patchwork.freedesktop.org/patch/msgid/20221202011407.4068371-1-alan.previn.teres.alexis@intel.comSigned-off-by: NAlan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208180542.998148-1-alan.previn.teres.alexis@intel.com
      f67986b0
  3. 09 9月, 2022 1 次提交
  5. 31 8月, 2022 1 次提交
  7. 24 8月, 2022 1 次提交
  9. 27 7月, 2022 2 次提交
  11. 21 6月, 2022 1 次提交
  13. 12 4月, 2022 2 次提交
  15. 05 3月, 2022 2 次提交
  17. 24 2月, 2022 3 次提交
  19. 24 1月, 2022 1 次提交
  21. 18 1月, 2022 5 次提交
  23. 15 12月, 2021 2 次提交
  25. 04 12月, 2021 1 次提交
  27. 03 12月, 2021 4 次提交
  29. 02 12月, 2021 1 次提交
  31. 24 11月, 2021 1 次提交
  33. 23 11月, 2021 1 次提交
  35. 11 11月, 2021 1 次提交
  37. 04 11月, 2021 3 次提交
    • V
      drm/i915: Split skl+ plane update into noarm+arm pair · 890b6ec4
      由 Ville Syrjälä 提交于 
      Chop skl_program_plane() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.

Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.

A few notable oddities I did not realize were self arming
are AUX_DIST and COLOR_CTL.

i915_update_info doesn't look too terrible on my cfl running
kms_atomic_transition --r plane-all-transition --extended:
w/o patch                           w/ patch
Updates: 2178                       Updates: 2018
       |                                   |
   1us |                               1us |
       |                                   |
   4us |                               4us |*****
       |*********                          |**********
  16us |**********                    16us |*******
       |***                                |
  66us |                              66us |
       |                                   |
 262us |                             262us |
       |                                   |
   1ms |                               1ms |
       |                                   |
   4ms |                               4ms |
       |                                   |
  17ms |                              17ms |
       |                                   |
Min update: 8332ns                  Min update: 6164ns
Max update: 48758ns                 Max update: 31808ns
Average update: 19959ns             Average update: 13159ns
Overruns > 100us: 0                 Overruns > 100us: 0

And with lockdep enabled:
w/o patch                           w/ patch
Updates: 2177			    Updates: 2172
       |			    	   |
   1us |			       1us |
       |			    	   |
   4us |			       4us |
       |*******			    	   |*********
  16us |**********		      16us |**********
       |*******			    	   |*
  66us |			      66us |
       |			    	   |
 262us |			     262us |
       |			    	   |
   1ms |			       1ms |
       |			    	   |
   4ms |			       4ms |
       |			    	   |
  17ms |			      17ms |
       |			    	   |
Min update: 12645ns		    Min update: 9980ns
Max update: 50153ns		    Max update: 33533ns
Average update: 25337ns		    Average update: 18245ns
Overruns > 250us: 0		    Overruns > 250us: 0

TODO: On icl+ everything seems to be armed by PLANE_SURF, so we
      can optimize this even further on modern platforms. But I
      think there's a bit of refactoring to be done first to
      figure out the best way to go about it (eg. just reusing
      the current skl+ functions, or doing a lower level split).

TODO: Split scaler programming as well, but IIRC the scaler
      has some oddball double buffering behaviour on some
      platforms, so needs proper reverse engineering

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-6-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      890b6ec4
    • V
      drm/i915: Split update_plane() into update_noarm() + update_arm() · 8ac80733
      由 Ville Syrjälä 提交于 
      The amount of plane registers we have to write has been steadily
increasing, putting more pressure on the vblank evasion mechanism
and forcing us to increase its time budget. Let's try to take some
of the pressure off by splitting plane updates into two parts:
1) write all non-self arming plane registers, ie. the registers
   where the write actually does nothing until a separate arming
   register is also written which will cause the hardware to latch
   the new register values at the next start of vblank
2) write all self arming plane registers, ie. registers which always
   just latch at the next start of vblank, and registers which also
   arm other registers to do so

Here we just provide the mechanism, but don't actually implement
the split on any platform yet. so everything stays now in the _arm()
hooks. Subsequently we can move a whole bunch of stuff into the
_noarm() part, especially in more modern platforms where the number
of registers we have to write is also the greatest. On older
platforms this is less beneficial probably, but no real reason
to deviate from a common behaviour.

And let's sprinkle some TODOs around the areas that will need
adapting.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-5-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      8ac80733
    • V
      drm/i915: Fix async flip with decryption and/or DPT · 50faf7a1
      由 Ville Syrjälä 提交于 
      We're currently forgetting to set the PLANE_SURF_DECRYPT
flag in the async flip path. So if the hardware were to
latch that bit despite this being an async flip we'd start
scanning out garbage. And if it doesn't latch it then I
guess we'd just end up with a weird register value that
doesn't actually match the hardware state, which isn't
great for anyone staring at register dumps.

Similarly the async flip path also forgets to call
skl_surf_address() which means the DPT address space to
GGTT address space downshift is not being applied to
the offset. Which means we are pointing PLANE_SURF
at some random location in GGTT instead of the correct
DPT page.

So let's fix two birds with one stone and extract the
PLANE_SURF calculation from skl_program_plane() into
a small helper and use it in the async flip path as well.

Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-3-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
      50faf7a1
  39. 03 11月, 2021 2 次提交
    • I
      drm/i915/adlp/fb: Remove restriction on CCS AUX plane strides · e6d6f689
      由 Imre Deak 提交于 
      As opposed to other GEN12 platforms ADLP provides a way to program the
stride of CCS surfaces independently of the main surface stride (within
the corresponding limit of the preceding and succeeding power-of-two
values of the main surface stride). Using this HW feature we can remove
the POT stride restriction on CCS surfaces, making the ADLP CCS FB uAPI
(FB modifiers) identical to that of TGL.

The HW makes the CCS stride flexible programming possible by deriving
the stride from the value programmed to the PLANE_STRIDE register. After
that the HW rounds up this value to the next power-of-two value and uses
this for walking the pages of the main surface mapped to GTT/DPT.

To align with the above scheme, introduce a scanout_stride view
parameter which will be programmed to the PLANE_STRIDE register and use
the mapping_stride view param to store the POT aligned value of the
same. By requiring userspace to pass in FBs with a CCS stride that
aligns with the main surface stride (matching the requirement of all
GEN12 platforms), the scanout_stride will be the userspace main surface
stride and the mapping_stride will be the POT rounded value of the same.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Nanley G Chery <nanley.g.chery@intel.com>
Cc: Sameer Lattannavar <sameer.lattannavar@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-8-imre.deak@intel.com
      e6d6f689
    • I
      drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride · be6c1dd5
      由 Imre Deak 提交于 
      The next patch needs to distinguish between a view's mapping and scanout
stride. Rename the current stride parameter to mapping_stride with the
script below. mapping_stride will keep the same meaning as stride had
on all platforms so far, while the meaning of it will change on ADLP.

No functional changes.

@@
identifier intel_fb_view;
identifier i915_color_plane_view;
identifier color_plane;
expression e;
type T;
@@
struct intel_fb_view {
...
struct i915_color_plane_view {
...
- T stride;
+ T mapping_stride;
...
} color_plane[e];
...
};

@@
struct i915_color_plane_view pv;
@@
  pv.
-    stride
+    mapping_stride

@@
struct i915_color_plane_view *pvp;
@@
  pvp->
-     stride
+     mapping_stride
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-6-imre.deak@intel.com
      be6c1dd5
  41. 29 10月, 2021 3 次提交
  43. 22 10月, 2021 1 次提交