On Thu, Jun 29, 2017 at 06:22:45PM +0300, Jani Nikula wrote: > On Thu, 29 Jun 2017, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote: > >> In a IGD passthrough environment, the real ISA bridge may doesn't exist. > >> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is > >> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as > >> LPT_H,then errors occur when i915 runs on LPT_LP machines with igd > >> passthrough. > >> > >> This patch set pch_id for HSW/BDW according to IGD type and isn't fully > >> correct. But it solves such issue on HSW/BDW ult/ulx machines. > >> QA CI system is blocked by this issue for a long time, it's better that > >> we could merge it to unblock QA CI system. > >> > >> We know the root cause is in device model of virtual passthrough, and > >> will resolve it in the future with several parts cooperation in kernel, > >> qemu and xen. > >> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938 > >> > >> Signed-off-by: Xiong Zhang <xiong.y.zhang@xxxxxxxxx> > >> --- > >> drivers/gpu/drm/i915/i915_drv.c | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > >> index 1f802de..2e664c5 100644 > >> --- a/drivers/gpu/drm/i915/i915_drv.c > >> +++ b/drivers/gpu/drm/i915/i915_drv.c > >> @@ -135,6 +135,10 @@ static enum intel_pch intel_virt_detect_pch(struct drm_i915_private *dev_priv) > >> DRM_DEBUG_KMS("Assuming CouarPoint PCH\n"); > >> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) { > >> ret = PCH_LPT; > >> + if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv)) > >> + dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE; > >> + else > >> + dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE; > > > > So it's imo silly that we're leaking the pch_id to our code when we > > already have pch_type, but oh well. > > It's for distinguishing between LP and non-LP, which we need in the > code, and why we have this patch in the first place. I guess we could add separate pch_types for the LP variants. But I think that'll just slightly shift the complexity between the HAS_PCH/HAS_PCH_H/HAS_PCH_LP macros. Or maybe we should just nuke pch_type? > > > Anyway, this is all about the physical pch on the chip, nothing to do with > > the virtualized one, and we've been hard-coding these forever. > > > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > Afaiui if this isn't true on a machine, someone used a solder iron to > > build something that Intel doesn't sell. > > Bspec says there are (at least) non-ULT/ULX Broadwells with LP PCH. We > do seem to warn about the combo in the bare metal PCH detection, so I > guess it's safe to assume they are rare. But strictly speaking this > change just moves problems from one setup to another. > > This has all been covered in the thread that I linked to in my previous > reply, and all of that discussion has been conveniently overlooked and > ignored in this patch submission and the commit message. > > I'm not opposed to merging the patch, but this needs to be documented > for posterity. > > Of course, this gets *much* more complicated from SKL/SPT on, where the > combos can be mixed even more freely (e.g. SKL+KBP and KBL+SPT). Actually I'm not sure we have PCH_KBP since it seems to be identical to SPT? We don't have PCH_PPT or PCH_WPT either. So IMO we should either remove PCH_KBP or add PCH_PPT+PCH_WPT. > > > BR, > Jani. > > > > > -Daniel > > > >> DRM_DEBUG_KMS("Assuming LynxPoint PCH\n"); > >> } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) { > >> ret = PCH_SPT; > >> -- > >> 2.7.4 > >> > >> _______________________________________________ > >> Intel-gfx mailing list > >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
