[PATCH] drm/i915/gvt: Set defaults to transcoder mn reg

Zhang, Tina tina.zhang at intel.com
Tue Mar 24 00:45:42 UTC 2020



> -----Original Message-----
> From: intel-gvt-dev <intel-gvt-dev-bounces at lists.freedesktop.org> On Behalf
> Of Zhenyu Wang
> Sent: Friday, March 20, 2020 11:56 AM
> To: Zhang, Tina <tina.zhang at intel.com>
> Cc: intel-gvt-dev at lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/gvt: Set defaults to transcoder mn reg
> 
> On 2020.03.20 11:02:49 +0800, Tina Zhang wrote:
> > GVT-g provides guest with dp type connectors and does the dp emulations.
> > For crtc timing, GVT-g just copys the parameters from host, which is
> > fine when host has dp type connectors as the vgpu's crtc timing never
> > goes to hardware and the reasonable data got by guest is mostly for
> > the sanity checking and clock related calculating.
> >
> > But when host doesn't have any dp ports, GVT-g may get invalid data
> > from dp related timing registers on host. And those invalid data
> > cannot let guest pass the sanity checking.
> >
> > So, solve the issue by providing reasonable defauts for the transcoder
> > mn registers no matter whether host has or has not dp type connectors.
> >
> > Signed-off-by: Tina Zhang <tina.zhang at intel.com>
> > ---
> >  drivers/gpu/drm/i915/gvt/display.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/display.c
> > b/drivers/gpu/drm/i915/gvt/display.c
> > index a83df2f84eb9..44185cda0905 100644
> > --- a/drivers/gpu/drm/i915/gvt/display.c
> > +++ b/drivers/gpu/drm/i915/gvt/display.c
> > @@ -167,6 +167,17 @@ static u8 dpcd_fix_data[DPCD_HEADER_SIZE] = {
> >  	0x12, 0x014, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
> > };
> >
> > +/* Set defaults to transcoder nm registers to gererate reasonable crtc
> clock */
> > +#define PIPE_MN_REG_NUM	0x4
> > +
> > +static u32 trans_m_n[4] = {
> > +	/*
> > +	 * PIPE_LINK_M1, PIPE_LINK_N1, PIPE_DATA_M1, PIPE_DATA_N1
> > +	 * generate crtc.clock = 89099 kHz
> > +	 */
> > +	0x46666, 0x80000, 0x7e34cccc, 0x800000
> 
> I can't remember clearly, but is this clock related to our virtual EDID mode
> timing? Would that be different for different mode? e.g If we want to extend
> for 4k resolution, does this need to be changed as well?
According to https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf page171, they don't come from edid. 

It seems things won't go bad, as we don't let the clock go on hardware really. So far we didn't see any kernel complains about those values. And we can check it again when 4k is introduced.

Cheers,
Tina 

> 
> > +};
> > +
> >  static void emulate_monitor_status_change(struct intel_vgpu *vgpu)  {
> >  	struct drm_i915_private *dev_priv = vgpu->gvt->gt->i915; @@ -
> 233,6
> > +244,10 @@ static void emulate_monitor_status_change(struct intel_vgpu
> *vgpu)
> >  		vgpu_vreg_t(vgpu, DDI_BUF_CTL(PORT_B)) |=
> DDI_BUF_CTL_ENABLE;
> >  		vgpu_vreg_t(vgpu, DDI_BUF_CTL(PORT_B)) &=
> ~DDI_BUF_IS_IDLE;
> >  		vgpu_vreg_t(vgpu, SDEISR) |= SDE_PORTB_HOTPLUG_CPT;
> > +		vgpu_vreg_t(vgpu, PIPE_LINK_M1(TRANSCODER_A)) =
> trans_m_n[0];
> > +		vgpu_vreg_t(vgpu, PIPE_LINK_N1(TRANSCODER_A)) =
> trans_m_n[1];
> > +		vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) =
> trans_m_n[2];
> > +		vgpu_vreg_t(vgpu, PIPE_DATA_N1(TRANSCODER_A)) =
> trans_m_n[3];
> >  	}
> >
> >  	if (intel_vgpu_has_monitor_on_port(vgpu, PORT_C)) { @@ -253,6
> > +268,10 @@ static void emulate_monitor_status_change(struct intel_vgpu
> *vgpu)
> >  		vgpu_vreg_t(vgpu, DDI_BUF_CTL(PORT_C)) |=
> DDI_BUF_CTL_ENABLE;
> >  		vgpu_vreg_t(vgpu, DDI_BUF_CTL(PORT_C)) &=
> ~DDI_BUF_IS_IDLE;
> >  		vgpu_vreg_t(vgpu, SFUSE_STRAP) |=
> SFUSE_STRAP_DDIC_DETECTED;
> > +		vgpu_vreg_t(vgpu, PIPE_LINK_M1(TRANSCODER_A)) =
> trans_m_n[0];
> > +		vgpu_vreg_t(vgpu, PIPE_LINK_N1(TRANSCODER_A)) =
> trans_m_n[1];
> > +		vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) =
> trans_m_n[2];
> > +		vgpu_vreg_t(vgpu, PIPE_DATA_N1(TRANSCODER_A)) =
> trans_m_n[3];
> >  	}
> >
> >  	if (intel_vgpu_has_monitor_on_port(vgpu, PORT_D)) { @@ -273,6
> > +292,10 @@ static void emulate_monitor_status_change(struct intel_vgpu
> *vgpu)
> >  		vgpu_vreg_t(vgpu, DDI_BUF_CTL(PORT_D)) |=
> DDI_BUF_CTL_ENABLE;
> >  		vgpu_vreg_t(vgpu, DDI_BUF_CTL(PORT_D)) &=
> ~DDI_BUF_IS_IDLE;
> >  		vgpu_vreg_t(vgpu, SFUSE_STRAP) |=
> SFUSE_STRAP_DDID_DETECTED;
> > +		vgpu_vreg_t(vgpu, PIPE_LINK_M1(TRANSCODER_A)) =
> trans_m_n[0];
> > +		vgpu_vreg_t(vgpu, PIPE_LINK_N1(TRANSCODER_A)) =
> trans_m_n[1];
> > +		vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) =
> trans_m_n[2];
> > +		vgpu_vreg_t(vgpu, PIPE_DATA_N1(TRANSCODER_A)) =
> trans_m_n[3];
> >  	}
> >
> >  	if ((IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv) ||
> > --
> > 2.17.1
> >
> > _______________________________________________
> > intel-gvt-dev mailing list
> > intel-gvt-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
> 
> --
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


More information about the intel-gvt-dev mailing list