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

Zhang, Tina tina.zhang at intel.com
Tue Mar 24 03:50:28 UTC 2020 

Guest driver just gets those values from registers, instead of edid or something else.

BR,
Tina

> -----Original Message-----
> From: Zhenyu Wang <zhenyuw at linux.intel.com>
> Sent: Tuesday, March 24, 2020 10:53 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.24 00:45:42 +0000, Zhang, Tina wrote:
> >
> >
> > > -----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.
> >
> 
> Pixel rate clock is from modeline timing, e.g 30/60hz refresh would have
> different clock.
> 
> > 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.
> >
> 
> Pls at least note the m/n value in above calculation and what's mode clock
> generated against, instead of just register value which is vague to understand.
> 
> > 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
> > _______________________________________________
> > 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