Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 3月, 2021 2 次提交
    • C
      drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual display · b01739fb
      由 Colin Xu 提交于 
      Current vblank emulator uses single hrtimer at 16ms period for all vGPUs,
which introduces three major issues:

- 16ms matches the refresh rate at 62.5Hz (instead of 60Hz) which
  doesn't follow standard timing. This leads to some frame drop or glitch
  issue during video playback. SW expects a vsync interval of 16.667ms or
  higher precision for an accurate 60Hz refresh rate. However current
  vblank emulator only works at 16ms.

- Doesn't respect the fact that with current virtual EDID timing set,
  not all resolutions are running at 60Hz. For example, current virtual
  EDID also supports refresh rate at 56Hz, 59.97Hz, 60Hz, 75Hz, etc.

- Current vblank emulator use single hrtimer for all vGPUs. Regardsless
  the possibility that different guests could run in different
  resolutions, all vsync interrupts are injected at 16ms interval with
  same hrtimer.

Based on previous patch which decode guest expected refresh rate from
vreg, the vblank emulator refactor patch makes following changes:
- Change the vblank emulator hrtimer from gvt global to per-vGPU.
  By doing this, each vGPU display can operates at different refresh
  rates. Currently only one dislay is supported for each vGPU so per-vGPU
  hrtimer is enough. If multiple displays are supported per-vGPU in
  future, we can expand to per-PIPE further.
- Change the fixed hrtimer period from 16ms to dynamic based on vreg.
  GVT is expected to emulate the HW as close as possible. So reflacting
  the accurate vsync interrupt interval is more correct than fixed 16ms.
- Change the vblank timer period and start the timer on PIPECONF change.
  The initial period is updated to 16666667 based on 60Hz refresh rate.
  According to PRM, PIPECONF controls the timing generator of the
  connected display on this pipe, so it's safe to stop hrtimer on
  PIPECONF disabling, and re-start hrtimer at new period on enabling.

Other changes including:
- Move vblank_timer_fn from irq.c into display.c.
- Clean per-vGPU vblank timer at clean_display instead of clean_irq.

To run quick test, launch a web browser and goto URL: www.displayhz.com

The actual refresh rate from guest can now always match guest settings.

V2:
Rebase to 5.11.
Remove unused intel_gvt_clean_irq().
Simplify enable logic in update_vblank_emulation(). (zhenyu)
Loop all vGPU by idr when check all vblank timer. (zhenyu)
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210226044630.284269-1-colin.xu@intel.comReviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      b01739fb
    • C
      drm/i915/gvt: Get accurate vGPU virtual display refresh rate from vreg · 6a4500c7
      由 Colin Xu 提交于 
      Guest OS builds up its timing mode list based on the virtual EDID as
simulated by GVT. However since there are several timings supported in
the virtual EDID, and each timing can also support several modes
(resolution and refresh rate), current emulated vblank period (16ms)
may not always be correct and could lead to miss-sync behavior in guest.

Guest driver will setup new resolution and program vregs accordingly and
it should always follows GEN PRM. Based on the simulated display regs by
GVT, it's safe to decode the actual refresh rate using by guest from
vreg only.

Current implementation only enables PIPE_A and PIPE_A is always tied to
TRANSCODER_A in HW. GVT may simulate DP monitor on PORT_B or PORT_D
based on the caller. So we can find out which DPLL is used by PORT_x
which connected to TRANSCODER_A and calculate the DP bit rate from the
DPLL frequency. Then DP stream clock (pixel clock) can be calculated
from DP link M/N and DP bit rate. Finally, get the refresh rate from
pixel clock, H total and V total.

The per-vGPU accurate refresh rate is not used yet but only stored,
until per-vGPU vblank timer is enabled. Then each vGPU can have
different and accurate refresh rate per-guest driver configuration.

Refer to PRM for GEN display and VESA timing standard for more details.

V2:
Rebase to 5.11.
Correctly calculate DP link rate for BDW and BXT.
Use GVT_DEFAULT_REFRESH_RATE instead of hardcoded to 60 as init refresh.
Typo fix. (zhenyu)
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210226044559.283622-1-colin.xu@intel.comReviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      6a4500c7
  3. 25 12月, 2020 3 次提交
  5. 03 12月, 2020 1 次提交
  7. 02 12月, 2020 1 次提交
  9. 19 11月, 2020 1 次提交
  11. 10 11月, 2020 1 次提交
    • C
      drm/i915/gvt: Save/restore HW status to support GVT suspend/resume · 5f60b12e
      由 Colin Xu 提交于 
      This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.

Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries on each host_entry update, restore the saved dirty entries
and re-init fence regs in resume routine.

V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c and
move the actual implementation to gvt.h/gvt.c. (zhenyu)
- Check gvt config on and active with intel_gvt_active(). (zhenyu)

V3: (zhenyu)
- Incorrect copy length. Should be num entries * entry size.
- Use memcpy_toio()/memcpy_fromio() instead of memcpy for iomem.
- Add F_PM_SAVE flags to indicate which MMIOs to save/restore for PM.

V4:
Rebase.

V5:
Fail intel_gvt_save_ggtt as -ENOMEM if fail to alloc memory to save
ggtt. Free allocated ggtt_entries on failure.

V6:
Save host entry to per-vGPU gtt.ggtt_mm on each host_entry update.

V7:
Restore GGTT entry based on present bit.
Split fence restore and mmio restore in different functions.
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NHang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20201027045308.158955-1-colin.xu@intel.com
      5f60b12e
  13. 30 10月, 2020 1 次提交
  15. 29 10月, 2020 1 次提交
  17. 19 10月, 2020 2 次提交
  19. 10 10月, 2020 1 次提交
  21. 10 9月, 2020 2 次提交
  23. 24 8月, 2020 1 次提交
  25. 09 7月, 2020 2 次提交
  27. 17 6月, 2020 3 次提交
  29. 03 6月, 2020 1 次提交
  31. 08 5月, 2020 1 次提交
    • Z
      drm/i915/gvt: Support PPGTT table load command · bec3df93
      由 Zhenyu Wang 提交于 
      The PPGTT in context image can be overridden by LRI cmd with another
PPGTT's pdps. In such case, the load mm is used instead of the one in
the context image. So we need to load its shadow mm in GVT and replace
ppgtt pointers in command.

This feature is used by guest IGD driver to share gfx VM between
different contexts. Verified by IGT "gem_ctx_clone" test.

v4:
- consolidate shadow mm handlers (Yan)
- fix cmd shadow mm pin error path

v3: (Zhenyu Wang)
- Cleanup PDP register offset check
- Add debug check for guest context ppgtt update
- Skip 3-level ppgtt guest handling code. The reason is that all
  guests now use 4-level ppgtt table and the only left case for
  3-level table is ancient aliasing ppgtt case. But those guest
  kernel has no use of PPGTT LRI command. So 3-level ppgtt guest
  for this feature becomes simply un-testable.

v2: (Zhenyu Wang)
- Change to list for handling possible multiple ppgtt table loads
  in one submission. Make sure shadow mm is to replace for each one.
Reviewed-by: NYan Zhao <yan.y.zhao@intel.com>
Cc: Yan Zhao <yan.y.zhao@intel.com>
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200508031409.2562-1-zhenyuw@linux.intel.com
      bec3df93
  33. 17 3月, 2020 1 次提交
  35. 06 3月, 2020 2 次提交
  37. 24 2月, 2020 2 次提交
  39. 06 2月, 2020 1 次提交
  41. 31 1月, 2020 1 次提交
  43. 29 12月, 2019 1 次提交
  45. 17 12月, 2019 1 次提交
  47. 27 11月, 2019 2 次提交
  49. 08 11月, 2019 1 次提交
  51. 30 10月, 2019 1 次提交
  53. 23 8月, 2019 1 次提交
    • J
      drm/i915/psr: Make PSR registers relative to transcoders · 4ab4fa10
      由 José Roberto de Souza 提交于 
      PSR registers are a mess, some have the full address while others just
have the additional offset from psr_mmio_base.

For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
0x800 and using it makes more difficult for people with an PSR
register address or PSR register name from from BSpec as i915 also
don't match the BSpec names.
For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers are
only available in DDIA.

Other reason to make relative to transcoder is that since BDW every
transcoder have PSR registers, so in theory it should be possible to
have PSR enabled in a non-eDP transcoder.

So for BDW+ we can use _TRANS2() to get the register offset of any
PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ
that will calculate the register offset for the single PSR instance,
noting that we are already guarded about trying to enable PSR in other
port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)' in
intel_psr_compute_config(), this check should only be valid for HSW
and will be changed in future.
PSR2 registers and PSR_EVENT was added after Haswell so that is why
_PSR_ADJ() is not used in some macros.

The only registers that can not be relative to transcoder are
PSR_IMR and PSR_IIR that are not relative to anything, so keeping it
hardcoded. That changed for TGL but it will be handled in another
patch.

Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it
is the only PSR register that GVT have.

v5:
- Macros changed to be more explicit about HSW (Dhinakaran)
- Squashed with the patch that added the tran parameter to the
macros (Dhinakaran)

v6:
- Checking for interruption errors after module reload in the
transcoder that will be used (Dhinakaran)
- Using lowercase to the registers offsets

v7:
- Removing IS_HASWELL() from registers macros(Jani)

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-1-jose.souza@intel.com
      4ab4fa10
  55. 17 6月, 2019 1 次提交
    • W
      drm/i915/gvt: ignore unexpected pvinfo write · 971afec3
      由 Weinan Li 提交于 
      There is pvinfo writing come from vgpu might be unexpected, like
writing to one unknown address, GVT-g should do as reserved register
to discard any invalid write. Now GVT-g lets it write to the vreg
without prompt error message, should ignore the unexpected pvinfo
write access and leave the vreg as the default value.

For possible guest query GVT-g host feature, this returned proper
value instead of wrong guest setting.

v2: ignore unexpected pvinfo write instead of return predefined value

Fixes: e39c5add ("drm/i915/gvt: vGPU MMIO virtualization")
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      971afec3
  57. 03 6月, 2019 1 次提交
    • W
      drm/i915/gvt: add F_CMD_ACCESS flag for wa regs · 3fcb01f8
      由 Weinan Li 提交于 
      Instead of updating by MMIO write, all of the wa regs are initialized by
wa_ctx. From host side, it should make this behavior as expected, add
'F_CMD_ACCESS' flag to these regs and allow access by commands.

[  123.557608] gvt: vgpu 2: srm access to non-render register (b11c)
[  123.563728] gvt: vgpu 2: MI_STORE_REGISTER_MEM handler error
[  123.569409] gvt: vgpu 2: cmd parser error
[  123.573424] 0x0
[  123.573425] 0x24

[  123.578686] gvt: vgpu 2: scan workload error
[  123.582958] GVT Internal error  for the guest
[  123.587317] Now vgpu 2 will enter failsafe mode.
[  123.591938] gvt: vgpu 2: failed to submit desc 0
[  123.596557] gvt: vgpu 2: fail submit workload on ring 0
[  123.601786] gvt: vgpu 2: fail to emulate MMIO write 00002230 len 4
Acked-by: NYan Zhao <yan.y.zhao@intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      3fcb01f8