OpenCloudOS-Kernel/drivers/gpu/drm/i915/gvt/display.h

225 lines
5.7 KiB
C
Raw Normal View History

/*
* Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* Authors:
* Ke Yu
* Zhiyuan Lv <zhiyuan.lv@intel.com>
*
* Contributors:
* Terrence Xu <terrence.xu@intel.com>
* Changbin Du <changbin.du@intel.com>
* Bing Niu <bing.niu@intel.com>
* Zhi Wang <zhi.a.wang@intel.com>
*
*/
#ifndef _GVT_DISPLAY_H_
#define _GVT_DISPLAY_H_
#include <linux/types.h>
drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual display 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 <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044630.284269-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-26 12:46:30 +08:00
#include <linux/hrtimer.h>
struct intel_gvt;
struct intel_vgpu;
#define SBI_REG_MAX 20
#define DPCD_SIZE 0x700
#define intel_vgpu_port(vgpu, port) \
(&(vgpu->display.ports[port]))
#define intel_vgpu_has_monitor_on_port(vgpu, port) \
(intel_vgpu_port(vgpu, port)->edid && \
intel_vgpu_port(vgpu, port)->edid->data_valid)
#define intel_vgpu_port_is_dp(vgpu, port) \
((intel_vgpu_port(vgpu, port)->type == GVT_DP_A) || \
(intel_vgpu_port(vgpu, port)->type == GVT_DP_B) || \
(intel_vgpu_port(vgpu, port)->type == GVT_DP_C) || \
(intel_vgpu_port(vgpu, port)->type == GVT_DP_D))
#define INTEL_GVT_MAX_UEVENT_VARS 3
/* DPCD start */
#define DPCD_SIZE 0x700
/* DPCD */
#define DP_SET_POWER 0x600
#define DP_SET_POWER_D0 0x1
#define AUX_NATIVE_WRITE 0x8
#define AUX_NATIVE_READ 0x9
#define AUX_NATIVE_REPLY_MASK (0x3 << 4)
#define AUX_NATIVE_REPLY_ACK (0x0 << 4)
#define AUX_NATIVE_REPLY_NAK (0x1 << 4)
#define AUX_NATIVE_REPLY_DEFER (0x2 << 4)
drm/i915/gvt: Fix the validation on size field of dp aux header The assertion for len is wrong, so fix it. And for where to validate user input, we should not warn by call trace. [ 290.584739] WARNING: CPU: 0 PID: 1471 at drivers/gpu/drm/i915/gvt/handlers.c:969 dp_aux_ch_ctl_mmio_write+0x394/0x430 [i915] [ 290.586113] task: ffff880111fe8000 task.stack: ffffc90044a9c000 [ 290.586192] RIP: e030:dp_aux_ch_ctl_mmio_write+0x394/0x430 [i915] [ 290.586258] RSP: e02b:ffffc90044a9fd88 EFLAGS: 00010282 [ 290.586315] RAX: 0000000000000017 RBX: 0000000000000003 RCX: ffffffff82461148 [ 290.586391] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000201 [ 290.586468] RBP: ffffc90043ed1000 R08: 0000000000000248 R09: 00000000000003d8 [ 290.586544] R10: ffffc90044bdd314 R11: 0000000000000011 R12: 0000000000064310 [ 290.586621] R13: 00000000fe4003ff R14: ffffc900432d1008 R15: ffff88010fa7cb40 [ 290.586701] FS: 0000000000000000(0000) GS:ffff880123200000(0000) knlGS:0000000000000000 [ 290.586787] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 290.586849] CR2: 00007f67ea44e000 CR3: 0000000116078000 CR4: 0000000000042660 [ 290.586926] Call Trace: [ 290.586958] ? __switch_to_asm+0x40/0x70 [ 290.587017] intel_vgpu_mmio_reg_rw+0x1ec/0x3c0 [i915] [ 290.587087] intel_vgpu_emulate_mmio_write+0xa8/0x2c0 [i915] [ 290.587151] xengt_emulation_thread+0x501/0x7a0 [xengt] [ 290.587208] ? __schedule+0x3c6/0x890 [ 290.587250] ? wait_woken+0x80/0x80 [ 290.587290] kthread+0xfc/0x130 [ 290.587326] ? xengt_gpa_to_va+0x1f0/0x1f0 [xengt] [ 290.587378] ? kthread_create_on_node+0x70/0x70 [ 290.587429] ? do_group_exit+0x3a/0xa0 [ 290.587471] ret_from_fork+0x35/0x40 Fixes: 04d348a ("drm/i915/gvt: vGPU display virtualization") Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2018-04-11 16:39:22 +08:00
#define AUX_BURST_SIZE 20
/* DPCD addresses */
#define DPCD_REV 0x000
#define DPCD_MAX_LINK_RATE 0x001
#define DPCD_MAX_LANE_COUNT 0x002
#define DPCD_TRAINING_PATTERN_SET 0x102
#define DPCD_SINK_COUNT 0x200
#define DPCD_LANE0_1_STATUS 0x202
#define DPCD_LANE2_3_STATUS 0x203
#define DPCD_LANE_ALIGN_STATUS_UPDATED 0x204
#define DPCD_SINK_STATUS 0x205
/* link training */
#define DPCD_TRAINING_PATTERN_SET_MASK 0x03
#define DPCD_LINK_TRAINING_DISABLED 0x00
#define DPCD_TRAINING_PATTERN_1 0x01
#define DPCD_TRAINING_PATTERN_2 0x02
#define DPCD_CP_READY_MASK (1 << 6)
/* lane status */
#define DPCD_LANES_CR_DONE 0x11
#define DPCD_LANES_EQ_DONE 0x22
#define DPCD_SYMBOL_LOCKED 0x44
#define DPCD_INTERLANE_ALIGN_DONE 0x01
#define DPCD_SINK_IN_SYNC 0x03
/* DPCD end */
#define SBI_RESPONSE_MASK 0x3
#define SBI_RESPONSE_SHIFT 0x1
#define SBI_STAT_MASK 0x1
#define SBI_STAT_SHIFT 0x0
#define SBI_OPCODE_SHIFT 8
#define SBI_OPCODE_MASK (0xff << SBI_OPCODE_SHIFT)
#define SBI_CMD_IORD 2
#define SBI_CMD_IOWR 3
#define SBI_CMD_CRRD 6
#define SBI_CMD_CRWR 7
#define SBI_ADDR_OFFSET_SHIFT 16
#define SBI_ADDR_OFFSET_MASK (0xffff << SBI_ADDR_OFFSET_SHIFT)
struct intel_vgpu_sbi_register {
unsigned int offset;
u32 value;
};
struct intel_vgpu_sbi {
int number;
struct intel_vgpu_sbi_register registers[SBI_REG_MAX];
};
enum intel_gvt_plane_type {
PRIMARY_PLANE = 0,
CURSOR_PLANE,
SPRITE_PLANE,
MAX_PLANE
};
struct intel_vgpu_dpcd_data {
bool data_valid;
u8 data[DPCD_SIZE];
};
enum intel_vgpu_port_type {
GVT_CRT = 0,
GVT_DP_A,
GVT_DP_B,
GVT_DP_C,
GVT_DP_D,
GVT_HDMI_B,
GVT_HDMI_C,
GVT_HDMI_D,
GVT_PORT_MAX
};
enum intel_vgpu_edid {
GVT_EDID_1024_768,
GVT_EDID_1920_1200,
GVT_EDID_NUM,
};
drm/i915/gvt: Get accurate vGPU virtual display refresh rate from vreg 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: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044559.283622-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-26 12:45:59 +08:00
#define GVT_DEFAULT_REFRESH_RATE 60
struct intel_vgpu_port {
/* per display EDID information */
struct intel_vgpu_edid_data *edid;
/* per display DPCD information */
struct intel_vgpu_dpcd_data *dpcd;
int type;
enum intel_vgpu_edid id;
drm/i915/gvt: Get accurate vGPU virtual display refresh rate from vreg 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: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044559.283622-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-26 12:45:59 +08:00
/* x1000 to get accurate 59.94, 24.976, 29.94, etc. in timing std. */
u32 vrefresh_k;
};
drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual display 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 <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044630.284269-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-26 12:46:30 +08:00
struct intel_vgpu_vblank_timer {
struct hrtimer timer;
u32 vrefresh_k;
u64 period;
};
static inline char *vgpu_edid_str(enum intel_vgpu_edid id)
{
switch (id) {
case GVT_EDID_1024_768:
return "1024x768";
case GVT_EDID_1920_1200:
return "1920x1200";
default:
return "";
}
}
static inline unsigned int vgpu_edid_xres(enum intel_vgpu_edid id)
{
switch (id) {
case GVT_EDID_1024_768:
return 1024;
case GVT_EDID_1920_1200:
return 1920;
default:
return 0;
}
}
static inline unsigned int vgpu_edid_yres(enum intel_vgpu_edid id)
{
switch (id) {
case GVT_EDID_1024_768:
return 768;
case GVT_EDID_1920_1200:
return 1200;
default:
return 0;
}
}
drm/i915/gvt: Refactor GVT vblank emulator for vGPU virtual display 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 <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210226044630.284269-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-02-26 12:46:30 +08:00
void intel_vgpu_emulate_vblank(struct intel_vgpu *vgpu);
void vgpu_update_vblank_emulation(struct intel_vgpu *vgpu, bool turnon);
int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64 resolution);
void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
#endif