kernel/drivers/gpu/drm/i915/gvt/display.c, branch linux-6.5.y

drm/i915: s/PIPECONF/TRANSCONF/

2023-02-17T21:25:15Z

Rename PIPECONF to TRANSCONF to make it clear what it actually applies to. While the usual convention is to pick the earliers name I think in this case it's more clear to use the later name. Especially as even the register offset is in the wrong range (0x70000 vs. 0x60000) and thus makes it look like this is per-pipe. There is one place in gvt that's doing something with TRANSCONF while iterating with for_each_pipe(). So that might not be doing the right thing for TRANSCODER_EDP, dunno. Not knowing what it does I left it as is to avoid breakage. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230213225258.2127-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915/display: add intel_display_limits.h for key enums

2023-01-25T11:59:12Z

Move a handful of key enums to a new file intel_display_limits.h. These are the enum types, and the MAX/NUM enumerations within them, that are used in other headers. Otherwise, there's no common theme between them. Replace intel_display.h include with intel_display_limit.h where relevant, and add the intel_display.h include directly in the .c files where needed. Since intel_display.h is used almost everywhere in display/, include it from intel_display_types.h to avoid massive changes across the board. There are very few files that would need intel_display_types.h but not intel_display.h so this is neglible, and further cleanup between these headers can be left for the future. Overall this change drops the direct and indirect dependencies on intel_display.h from about 300 to about 100 compilation units, because we can drop the include from i915_drv.h. Signed-off-by: Jani Nikula Reviewed-by: Rodrigo Vivi Acked-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230116164644.1752009-1-jani.nikula@intel.com

drm/i915/dpio: move dpio_channel and dpio_phy enums to intel_dpio_phy.h

2022-11-03T14:20:53Z

Reduce the size of intel_display.h by moving out the dpio_channel and dpio_phy enums. Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/7c3ee7a6482540a0267f7b2974d22cab8188707a.1667383630.git.jani.nikula@intel.com

drm/i915: Only include i915_reg.h from .c files

2022-02-02T15:59:54Z

Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much every file of the driver, even those that don't have any kind of register access. Let's delete the i915_reg.h include from all headers and add an explicit include from the .c files that truly need the register definitions; those that need a definition of i915_reg_t for a function definition can get it from i915_reg_defs.h instead. We also remove two non-register #define's (VLV_DISPLAY_BASE and GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the i915_reg.h include from a couple of headers. There's probably a lot more header dependency optimization possible, but the changes here roughly cut the number of files compiled after 'touch i915_reg.h' in half --- a good first step. Cc: Jani Nikula Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-7-matthew.d.roper@intel.com

drm/i915: Clean up M/N register defines

2022-01-28T06:47:51Z

Use REG_GENMASK() & co. for the M/N register values. There are also a lot of weird unused defines (eg. *_OFFSET) we can just throw out. Also let's mask out the unused bits during readout for good measure. Previously we only masked out the TU_SIZE from one of the registers, which was a bit too inconsistent for my taste. v2: Mention the readout masking in the commit msg (Jani) Deal wth gvt Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220127120219.20143-1-ville.syrjala@linux.intel.com

drm/i915: Clean up PIPECONF bit defines

2022-01-26T19:28:42Z

Use REG_BIT() & co. for PIPECONF bits, and adjust the naming of various bits to be more consistent. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula

drm/i915: Clean up pre-skl primary plane registers

2022-01-24T09:38:26Z

Use REG_BIT() & co. for the pre-skl primary plane registers. Also give everything a consistent namespace. v2: s/DSP/DISP/ to avoid confusion (José) Use DISP_WIDTH rather than DISP_POS_X for DSPSIZE (José) Deal with gvt Cc: José Roberto de Souza Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220121113036.23240-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza

drm/i915: Clean up cursor registers

2022-01-18T02:03:27Z

Use REG_BIT() & co. to polish the cursor plane registers. v2: deal with gvt Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-12-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza

Merge tag 'gvt-next-2021-03-16' of https://github.com/intel/gvt-linux into drm-intel-next

2021-03-16T11:42:33Z

gvt-next-2021-03-16 - Parse accurate vGPU virtual display rate (Colin) - Convert vblank timer as per-vGPU based on current rate (Colin) - spelling fix (Bhaskar) Signed-off-by: Jani Nikula From: Zhenyu Wang Link: https://patchwork.freedesktop.org/patch/msgid/20210316074330.GC1551@zhen-hp.sh.intel.com

drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual display

2021-03-01T05:52:46Z

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: Colin Xu Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20210226044630.284269-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang