Re: [Intel-gfx] [PATCH v2] drm/i915: Try to guess PCH type even without ISA bridge

[Zhang, Xiong Y]

> On Fri, 18 Dec 2020, Xiong Zhang  wrote:
> > From: Zhenyu Wang 
> >
> > Some vmm like hyperv and crosvm don't supply any ISA bridge to their
> > guest, when igd passthrough is equipped on these vmm, guest i915
> > display may couldn't work as guest i915 detects PCH_NONE pch type.
> >
> > When i915 runs as guest, this patch guess pch type through gpu type
> > even without ISA bridge.
> >
> > v2: Fix CI warning
> >
> > Signed-off-by: Zhenyu Wang 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  7 +-
> > drivers/gpu/drm/i915/intel_pch.c | 38 ++--
> >  2 files changed, 32 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 5a7df5621aa3..df0b8f9268b2
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1758,6 +1758,11 @@ tgl_revids_get(struct drm_i915_private
> > *dev_priv)  #define INTEL_DISPLAY_ENABLED(dev_priv) \
> > (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),
> > !(dev_priv)->params.disable_display)
> >
> > +static inline bool run_as_guest(void) {
> > +   return !hypervisor_is_type(X86_HYPER_NATIVE);
> > +}
> > +
> >  static inline bool intel_vtd_active(void)  {  #ifdef
> > CONFIG_INTEL_IOMMU @@ -1766,7 +1771,7 @@ static inline bool
> > intel_vtd_active(void)  #endif
> >
> > /* Running as a guest, we assume the host is enforcing VT'd */
> > -   return !hypervisor_is_type(X86_HYPER_NATIVE);
> > +   return run_as_guest();
> >  }
> >
> >  static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private
> > *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > b/drivers/gpu/drm/i915/intel_pch.c
> > index f31c0dabd0cc..a73c60bf349e 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.c
> > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > @@ -184,6 +184,23 @@ intel_virt_detect_pch(const struct
> drm_i915_private *dev_priv)
> > return id;
> >  }
> >
> > +static void intel_detect_pch_virt(struct drm_i915_private *dev_priv)
> > +{
> > +   unsigned short id;
> > +   enum intel_pch pch_type;
> > +
> > +   id = intel_virt_detect_pch(dev_priv);
> 
> intel_detect_pch_virt() calls intel_virt_detect_pch()... the naming should be
> clarified to make some difference.
 [Zhang, Xiong Y] Indeed the naming is confusing. How about deleting this new 
added function, then move intel_pch_type() calling into original 
intel_virt_detect_pch(), and let intel_virt_detect_pch() return id and 
pch_type,  finally assign id and pch_type  in intel_detect_pch().

thanks
> 
> > +   pch_type = intel_pch_type(dev_priv, id);
> > +
> > +   /* Sanity check virtual PCH id */
> > +   if (drm_WARN_ON(_priv->drm,
> > +   id && pch_type == PCH_NONE))
> > +   id = 0;
> > +
> > +   dev_priv->pch_type = pch_type;
> > +   dev_priv->pch_id = id;
> 
> Previously the pch type and id assignments were all done in
> intel_detect_pch(), so moving this to a separate function in *some* but not
> all cases reduces clarity too.
> 
> BR,
> Jani.
> 
> > +}
> > +
> >  void intel_detect_pch(struct drm_i915_private *dev_priv)  {
> > struct pci_dev *pch = NULL;
> > @@ -221,16 +238,7 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> > break;
> > } else if (intel_is_virt_pch(id, pch->subsystem_vendor,
> >  pch->subsystem_device)) {
> > -   id = intel_virt_detect_pch(dev_priv);
> > -   pch_type = intel_pch_type(dev_priv, id);
> > -
> > -   /* Sanity check virtual PCH id */
> > -   if (drm_WARN_ON(_priv->drm,
> > -   id && pch_type == PCH_NONE))
> > -   id = 0;
> > -
> > -   dev_priv->pch_type = pch_type;
> > -   dev_priv->pch_id = id;
> > +   intel_detect_pch_virt(dev_priv);
> > break;
> > }
> > }
> > @@ -246,8 +254,14 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> > dev_priv->pch_id = 0;
> > }
> >
> > -   if (!pch)
> > -   drm_dbg_kms(_priv->drm, "No PCH found.\n");
> > +   if (!pch) {
> > +   if (run_as_guest()) {
> > +   drm_dbg_kms(_priv->drm, "No PCH found in
> vm, try guess..\n");
> > +   intel_detect_pch_virt(dev_priv);
> > +   } else {
> > +   drm_dbg_kms(_priv->drm, "No PCH found.\n");
> > +   }
> > +   }
> >
> > pci_dev_put(pch);
> >  }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Recall: [PATCH v2] drm/i915: Try to guess PCH type even without ISA bridge

[Zhang, Xiong Y]

Zhang, Xiong Y would like to recall the message, "[PATCH v2] drm/i915: Try to 
guess PCH type even without ISA bridge".
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Try to guess PCH type even without ISA bridge

[Zhang, Xiong Y]

> On Fri, 18 Dec 2020, Xiong Zhang  wrote:
> > From: Zhenyu Wang 
> >
> > Some vmm like hyperv and crosvm don't supply any ISA bridge to their
> > guest, when igd passthrough is equipped on these vmm, guest i915
> > display may couldn't work as guest i915 detects PCH_NONE pch type.
> >
> > When i915 runs as guest, this patch guess pch type through gpu type
> > even without ISA bridge.
> >
> > v2: Fix CI warning
> >
> > Signed-off-by: Zhenyu Wang 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  7 +-
> > drivers/gpu/drm/i915/intel_pch.c | 38 ++--
> >  2 files changed, 32 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 5a7df5621aa3..df0b8f9268b2
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1758,6 +1758,11 @@ tgl_revids_get(struct drm_i915_private
> > *dev_priv)  #define INTEL_DISPLAY_ENABLED(dev_priv) \
> > (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),
> > !(dev_priv)->params.disable_display)
> >
> > +static inline bool run_as_guest(void) {
> > +   return !hypervisor_is_type(X86_HYPER_NATIVE);
> > +}
> > +
> >  static inline bool intel_vtd_active(void)  {  #ifdef
> > CONFIG_INTEL_IOMMU @@ -1766,7 +1771,7 @@ static inline bool
> > intel_vtd_active(void)  #endif
> >
> > /* Running as a guest, we assume the host is enforcing VT'd */
> > -   return !hypervisor_is_type(X86_HYPER_NATIVE);
> > +   return run_as_guest();
> >  }
> >
> >  static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private
> > *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > b/drivers/gpu/drm/i915/intel_pch.c
> > index f31c0dabd0cc..a73c60bf349e 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.c
> > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > @@ -184,6 +184,23 @@ intel_virt_detect_pch(const struct
> drm_i915_private *dev_priv)
> > return id;
> >  }
> >
> > +static void intel_detect_pch_virt(struct drm_i915_private *dev_priv)
> > +{
> > +   unsigned short id;
> > +   enum intel_pch pch_type;
> > +
> > +   id = intel_virt_detect_pch(dev_priv);
> 
> intel_detect_pch_virt() calls intel_virt_detect_pch()... the naming should be
> clarified to make some difference.
[Zhang, Xiong Y] Indeed the naming is confusing. How about deleting this new 
added function, then move intel_pch_type() calling into original intel_virt
> 
> > +   pch_type = intel_pch_type(dev_priv, id);
> > +
> > +   /* Sanity check virtual PCH id */
> > +   if (drm_WARN_ON(_priv->drm,
> > +   id && pch_type == PCH_NONE))
> > +   id = 0;
> > +
> > +   dev_priv->pch_type = pch_type;
> > +   dev_priv->pch_id = id;
> 
> Previously the pch type and id assignments were all done in
> intel_detect_pch(), so moving this to a separate function in *some* but not
> all cases reduces clarity too.
> 
> BR,
> Jani.
> 
> > +}
> > +
> >  void intel_detect_pch(struct drm_i915_private *dev_priv)  {
> > struct pci_dev *pch = NULL;
> > @@ -221,16 +238,7 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> > break;
> > } else if (intel_is_virt_pch(id, pch->subsystem_vendor,
> >  pch->subsystem_device)) {
> > -   id = intel_virt_detect_pch(dev_priv);
> > -   pch_type = intel_pch_type(dev_priv, id);
> > -
> > -   /* Sanity check virtual PCH id */
> > -   if (drm_WARN_ON(_priv->drm,
> > -   id && pch_type == PCH_NONE))
> > -   id = 0;
> > -
> > -   dev_priv->pch_type = pch_type;
> > -   dev_priv->pch_id = id;
> > +   intel_detect_pch_virt(dev_priv);
> > break;
> > }
> > }
> > @@ -246,8 +254,14 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> > dev_priv->pch_id = 0;
> > }
> >
> > -   if (!pch)
> > -   drm_dbg_kms(_priv->drm, "No PCH found.\n");
> > +   if (!pch) {
> > +   if (run_as_guest()) {
> > +   drm_dbg_kms(_priv->drm, "No PCH found in
> vm, try guess..\n");
> > +   intel_detect_pch_virt(dev_priv);
> > +   } else {
> > +   drm_dbg_kms(_priv->drm, "No PCH found.\n");
> > +   }
> > +   }
> >
> > pci_dev_put(pch);
> >  }
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Try to guess PCH type even without ISA bridge

[Zhang, Xiong Y]

> On 2020.12.18 17:05:31 +0800, Xiong Zhang wrote:
> > From: Zhenyu Wang 
> >
> > Some vmm like hyperv and crosvm don't supply any ISA bridge to their
> > guest, when igd passthrough is equipped on these vmm, guest i915
> > display may couldn't work as guest i915 detects PCH_NONE pch type.
> >
> > When i915 runs as guest, this patch guess pch type through gpu type
> > even without ISA bridge.
> >
> > v2: Fix CI warning
> >
> > Signed-off-by: Zhenyu Wang 
> 
> Need to add yourself in sob.
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  7 +-
> > drivers/gpu/drm/i915/intel_pch.c | 38 ++--
> >  2 files changed, 32 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 5a7df5621aa3..df0b8f9268b2
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1758,6 +1758,11 @@ tgl_revids_get(struct drm_i915_private
> > *dev_priv)  #define INTEL_DISPLAY_ENABLED(dev_priv) \
> > (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)),
> > !(dev_priv)->params.disable_display)
> >
> > +static inline bool run_as_guest(void) {
> > +   return !hypervisor_is_type(X86_HYPER_NATIVE);
> > +}
> > +
> >  static inline bool intel_vtd_active(void)  {  #ifdef
> > CONFIG_INTEL_IOMMU @@ -1766,7 +1771,7 @@ static inline bool
> > intel_vtd_active(void)  #endif
> >
> > /* Running as a guest, we assume the host is enforcing VT'd */
> > -   return !hypervisor_is_type(X86_HYPER_NATIVE);
> > +   return run_as_guest();
> >  }
> >
> >  static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private
> > *dev_priv) diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > b/drivers/gpu/drm/i915/intel_pch.c
> > index f31c0dabd0cc..a73c60bf349e 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.c
> > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > @@ -184,6 +184,23 @@ intel_virt_detect_pch(const struct
> drm_i915_private *dev_priv)
> > return id;
> >  }
> >
> > +static void intel_detect_pch_virt(struct drm_i915_private *dev_priv)
> > +{
> > +   unsigned short id;
> > +   enum intel_pch pch_type;
> > +
> > +   id = intel_virt_detect_pch(dev_priv);
> > +   pch_type = intel_pch_type(dev_priv, id);
> > +
> > +   /* Sanity check virtual PCH id */
> > +   if (drm_WARN_ON(_priv->drm,
> > +   id && pch_type == PCH_NONE))
> > +   id = 0;
> > +
> > +   dev_priv->pch_type = pch_type;
> > +   dev_priv->pch_id = id;
> > +}
> > +
> >  void intel_detect_pch(struct drm_i915_private *dev_priv)  {
> > struct pci_dev *pch = NULL;
> > @@ -221,16 +238,7 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> > break;
> > } else if (intel_is_virt_pch(id, pch->subsystem_vendor,
> >  pch->subsystem_device)) {
> > -   id = intel_virt_detect_pch(dev_priv);
> > -   pch_type = intel_pch_type(dev_priv, id);
> > -
> > -   /* Sanity check virtual PCH id */
> > -   if (drm_WARN_ON(_priv->drm,
> > -   id && pch_type == PCH_NONE))
> > -   id = 0;
> > -
> > -   dev_priv->pch_type = pch_type;
> > -   dev_priv->pch_id = id;
> > +   intel_detect_pch_virt(dev_priv);
> > break;
> > }
> > }
> > @@ -246,8 +254,14 @@ void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> > dev_priv->pch_id = 0;
> > }
> >
> > -   if (!pch)
> > -   drm_dbg_kms(_priv->drm, "No PCH found.\n");
> > +   if (!pch) {
> 
> Require HAS_DISPLAY() here?
[Zhang, Xiong Y] yes, require it.

thanks
> 
> > +   if (run_as_guest()) {
> > +   drm_dbg_kms(_priv->drm, "No PCH found in
> vm, try guess..\n");
> > +   intel_detect_pch_virt(dev_priv);
> > +   } else {
> > +   drm_dbg_kms(_priv->drm, "No PCH found.\n");
> > +   }
> > +   }
> >
> > pci_dev_put(pch);
> >  }
> > --
> > 2.17.1
> >
> 
> --
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] question about i915 GPU driver in VM

[Zhang, Xiong Y]

> Hi,
> 
> I'm trying to get iGPU passthrough working in a VM running on a Chrome OS
> "7th Generation (Kaby Lake) Intel Core i5-7Y57 with HD Graphics 615" device.
> I'm able to pass the iGPU through to the VM and execute the i915 driver, but
> the driver doesn't succeed in getting the system to the point where the
> screen works.
> 
> With physical access to the iGPU from inside the guest, is it reasonable to
> just run the same kernel/driver that works on the host and expect it to work?
> Or are there often extra hoops to jump through even with
> physical/unemulated access to the host GPU and CPU?
[Zhang, Xiong Y] yes, both host and guest use the same kernel/driver.
> 
> On a higher level, it would help if anyone had an idea from the logs below if
> I'm "close" to getting this to work? Or maybe its hard to say?
[Zhang, Xiong Y] it is close to work.
> 
> NOTE: I totally avoid touching the GPU in the host, and have verified that the
> i915 driver in the guest should have all the info (e.g.
> OpRegion tables) it needs to drive the GPU. Interestingly, running
> i915 in the VM causes the VM kernel to crash at random code paths unless I
> wait until after system startup to modprobe i915. The VM doesn't crash at all
> if I disable i915. These crashes happen well after i915 is done trying to
> initialize the GPU, so not sure if i915 is touching memory it shouldn't be or
> what..
[Zhang, Xiong Y] Please check whether intel_iommu is enabled on host or not. If 
it isn't , please add intel_iommu=on to host grub.

is the dmesg from host or guest ?
If it is guest, this message shouldn't appear according to your qemu boot 
parameter.
> [0.475961] [drm:i915_ggtt_probe_hw] GTT stolen size = 64M
> [0.476927] [drm:i915_gem_init_stolen] Memory reserved for graphics
> device: 65536K, usable: 64512K
Please paste qemu output.

thanks
> 
> Thanks,
> Micah
> 
> KERNEL CONSOLE (modified for brevity):
> localhost ~ # qemu-system-x86_64 -serial mon:stdio -m 2G -smp 2 -M pc -vga
> none -usbdevice tablet -cpu host,-invpcid,-tsc-deadline,check -drive
> 'file=/mnt/stateful_partition/chromiumos_test_image.bin,index=0,media=dis
> k,cache=unsafe,format=raw'
> -enable-kvm -device
> vfio-pci,x-igd-opregion=on,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,ro
> mbar=0
> -device 'virtio-net,netdev=eth0' -netdev
> 'user,id=eth0,net=10.0.2.0/27,hostfwd=tcp:127.0.0.1:9222-:22'
> qemu-system-x86_64: -usbdevice tablet: '-usbdevice' is deprecated, please
> use '-device usb-...' instead
> qemu-system-x86_64: -device
> vfio-pci,x-igd-opregion=on,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x2,ro
> mbar=0:
> IGD device :00:02.0 has no ROM, legacy mode disabled VNC server
> running on 127.0.0.1:5900
> [0.00] Linux version 4.14.114
> (mort...@mortonm2.mtv.corp.google.com) (Chromium OS
> 9.0_pre353983_p20190325-r11 clang version 9.0.0
> (/var/cache/chromeos-cache/distfiles/host/egit-src/clang.git
> 171531e31716e2db2c372cf8b57220ddf9e721d8)
> (/var/cache/chromeos-cache/distfiles/host/egit-src/llvm.git
> 5077597e0d5b86d9f9c27286d8b28f8b3645a74c) (based on LLVM 9.0.0svn))
> #14 SMP PREEMPT Fri May 31 09:50:35 PDT 2019
> [0.00] Command line: BOOT_IMAGE=vmlinuz.A init=/sbin/init
> boot=local rootwait ro noresume noswap loglevel=7 noinitrd
> console=ttyS0 disablevmx=off
> root=PARTUUID=60B83A78-8581-014B-8942-6128789234C3 i915.modeset=1
> cros_legacy cros_debug
> 
> [snip]
> 
> [0.00] Reserving Intel graphics memory at [mem
> 0x7c00-0x7fff]
> 
> [snip]
> 
> [0.415534] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
> [0.416418] [drm:i915_driver_load] Assuming SunrisePoint PCH
> [0.417296] [drm:intel_power_domains_init] Allowed DC state mask 03
> [0.418290] [drm:intel_device_info_dump] i915 device info:
> platform=KABYLAKE gen=9 pciid=0x591e rev=0x02
> [0.418292] [drm:intel_device_info_dump] i915 device info: is_mobile:
> no
> [0.419684] [drm:intel_device_info_dump] i915 device info: is_lp: no
> [0.420740] [drm:intel_device_info_dump] i915 device info:
> is_alpha_support: no
> [0.421712] [drm:intel_device_info_dump] i915 device info:
> has_64bit_reloc: yes
> [0.422806] [drm:intel_device_info_dump] i915 device info:
> has_aliasing_ppgtt: yes
> [0.423900] [drm:intel_device_info_dump] i915 device info: has_csr: yes
> [0.425036] [drm:intel_device_info_dump] i915 device info: has_ddi: yes
> [0.426033] [drm:intel_device_info_dump] i915 device info: has_dp_mst:
> yes
> [0.427040] [drm:intel_device_info_dump] i915 device info:
> has_reset_engine: yes
> [0.428076] [drm:intel_device_info_dump] i915 device info: has_fbc: yes
> [0.429180] [drm:intel_device_info_dump] i915 

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt to GVT GEM context

[Zhang, Xiong Y]

> Quoting Zhang, Xiong Y (2018-10-19 11:11:23)
> > > Quoting Zhenyu Wang (2018-10-19 04:05:20)
> > > > On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> > > > > Currently the guest couldn't boot up under GVT-g environment as
> > > > > the following call trace exists:
> > > > > [  272.504762] BUG: unable to handle kernel NULL pointer
> > > > > dereference at 0100 [  272.504834] Call Trace:
> > > > > [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915] [
> > > > > 272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0
> > > > > [i915]
> > > [
> > > > > 272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915] [
> > > > > 272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915] [
> > > > > 272.504916]  elsp_mmio_write+0xc7/0x130 [i915] [  272.504930]
> > > > > intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915] [  272.504944]
> > > > > intel_vgpu_emulate_mmio_write+0xac/0x240 [i915] [  272.504947]
> > > > > intel_vgpu_rw+0x22d/0x270 [kvmgt] [  272.504949]
> > > > > intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > > > >
> > > > > GVT GEM context is created by i915_gem_context_create_gvt()
> > > > > which doesn't allocate ppgtt. So GVT GEM context structure
> > > > > doesn't have a valid i915_hw_ppgtt.
> > > > >
> > > > > This patch create ppgtt table at GVT GEM context creation, then
> > > > > assign shadow ppgtt's root table address to this ppgtt when
> > > > > shadow ppgtt will be used on GPU. So GVT GEM context has valid
> > > > > ppgtt address. But note that this ppgtt only contain valid ppgtt
> > > > > root table address, the table entry in this ppgtt structure are 
> > > > > invalid.
> > > > >
> > > > > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce
> > > > > ppgtt for execlists")
> > > > >
> > > > > Signed-off-by: Xiong Zhang 
> > > > > Reviewed-by: Zhenyu Wang 
> > > >
> > > > Any more comment for this? We need it for current gvt broken on
> > > > drm-tip, and it requires to change i915 for gvt ppgtt allocation,
> > > > so I assume it's better to be merged by i915 directly, or do you
> > > > like a gvt pull
> > > instead?
> > >
> > > You only needed ctx->ppgtt being set I thought, as you previously
> > > ignored the initial PD bits in the context image and overwrote the
> registers anyway.
> > >
> > > Do you want what appears to be a significant change to gvt itself to
> > > enter from i915?
> > [Zhang, Xiong Y] For 48 bit guest ppgtt, we only need ctx->ppgtt being set.
> > But for 32 bit guest ppgtt, i915 call execlists_update_context_pdps() which
> is behind gvt pdp updates, if ctx->ppgtt isn't correct, 32bit ppgtt guest 
> will be
> broken.
> 
> The code implies that gvt doesn't support 32b guests.
[Zhang, Xiong Y] shadow ppgtt has some code to handle 32b ppgtt. Actually I 
didn't find any guest use 32b ppgtt, linux guest force to use 48 bit ppgtt, 
even 32 bit win7 driver use 48 bit also. And I asked others whether 32 bit 
should be supported or not, the answer is yes. So I added the code in gvt.

> -Chris
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt to GVT GEM context

[Zhang, Xiong Y]

> Quoting Zhenyu Wang (2018-10-19 04:05:20)
> > On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> > > Currently the guest couldn't boot up under GVT-g environment as the
> > > following call trace exists:
> > > [  272.504762] BUG: unable to handle kernel NULL pointer dereference
> > > at 0100 [  272.504834] Call Trace:
> > > [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915] [
> > > 272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> [
> > > 272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915] [
> > > 272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915] [
> > > 272.504916]  elsp_mmio_write+0xc7/0x130 [i915] [  272.504930]
> > > intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915] [  272.504944]
> > > intel_vgpu_emulate_mmio_write+0xac/0x240 [i915] [  272.504947]
> > > intel_vgpu_rw+0x22d/0x270 [kvmgt] [  272.504949]
> > > intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > >
> > > GVT GEM context is created by i915_gem_context_create_gvt() which
> > > doesn't allocate ppgtt. So GVT GEM context structure doesn't have a
> > > valid i915_hw_ppgtt.
> > >
> > > This patch create ppgtt table at GVT GEM context creation, then
> > > assign shadow ppgtt's root table address to this ppgtt when shadow
> > > ppgtt will be used on GPU. So GVT GEM context has valid ppgtt
> > > address. But note that this ppgtt only contain valid ppgtt root
> > > table address, the table entry in this ppgtt structure are invalid.
> > >
> > > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce
> > > ppgtt for execlists")
> > >
> > > Signed-off-by: Xiong Zhang 
> > > Reviewed-by: Zhenyu Wang 
> >
> > Any more comment for this? We need it for current gvt broken on
> > drm-tip, and it requires to change i915 for gvt ppgtt allocation, so I
> > assume it's better to be merged by i915 directly, or do you like a gvt pull
> instead?
> 
> You only needed ctx->ppgtt being set I thought, as you previously ignored
> the initial PD bits in the context image and overwrote the registers anyway.
> 
> Do you want what appears to be a significant change to gvt itself to enter
> from i915?
[Zhang, Xiong Y] For 48 bit guest ppgtt, we only need ctx->ppgtt being set.
But for 32 bit guest ppgtt, i915 call execlists_update_context_pdps() which is 
behind gvt pdp updates, if ctx->ppgtt isn't correct, 32bit ppgtt guest will be 
broken. 

thanks
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

[Zhang, Xiong Y]

> + Zhi and Zhenyu
> 
> Quoting Xiong Zhang (2018-03-29 13:58:41)
> > Four drm_mm_node are used to reserve guest ggtt space, but some of
> > them may aren't initialized and used in intel_vgt_balloon(), so these
> > unused drm_mm_node couldn't be removed through
> drm_mm_remove_node().
> 
> I'm not sure how this slipped by in previous review, but is there an
> explanation why we have;
> 
> static struct _balloon_info_ bl_info;
> 
> ... and are not even initializing it?
> 
> This should definitely find it's way into dev_priv and be properly 
> initialized.
[Zhang, Xiong Y] how about move bl_info into struct i915_virtual_gpu ? so that 
we could get it through dev_priv->vgpu.bl_info

thanks
> 
> Regards, Joonas
> 
> >
> > Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size
> > under gvt environment")
> > Signed-off-by: Xiong Zhang <xiong.y.zh...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_vgpu.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> > b/drivers/gpu/drm/i915/i915_vgpu.c
> > index 5fe9f3f..7545686 100644
> > --- a/drivers/gpu/drm/i915/i915_vgpu.c
> > +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> > @@ -100,6 +100,9 @@ static struct _balloon_info_ bl_info;  static void
> > vgt_deballoon_space(struct i915_ggtt *ggtt,
> > struct drm_mm_node *node)  {
> > +   if (!node->allocated)
> > +   return;
> > +
> > DRM_DEBUG_DRIVER("deballoon space: range [0x%llx -
> 0x%llx] %llu KiB.\n",
> >  node->start,
> >  node->start + node->size,
> > --
> > 2.7.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

[Zhang, Xiong Y]

> Quoting Xiong Zhang (2018-03-29 11:58:41)
> > Four drm_mm_node are used to reserve guest ggtt space, but some of
> > them may aren't initialized and used in intel_vgt_balloon(), so these
> > unused
> 
> may be skipped and not initialised due to space constraints,
[Zhang, Xiong Y] OK, I will apply it. thanks
> 
> > drm_mm_node couldn't be removed through drm_mm_remove_node().
> >
> > Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size
> > under gvt environment")
> > Signed-off-by: Xiong Zhang <xiong.y.zh...@intel.com>
> 
> Had to read through and work out what the problem was; whether it was a
> bug elsewhere in vgpu or deliberate, so amending the commit msg to be
> clear would be helpful.
[Zhang, Xiong Y] bl_info.space[i] is initialized only on specific condition in 
intel_vgt_balloon(). When guest i915 driver is unloaded, intel_vgt_deballon() 
go through all four bl_info.space[3:0] and call drm_mm_remove_node() for each. 
If one isn't initialized, warning and reference null pointer occur in 
drm_mm_remove_node().
I will update commit message. Thanks.
> 
> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
> 
> Who actually consumes bl_info? It just looks like being a balloon being set
> adrift.
[Zhang, Xiong Y] bl_info is internal static variable, only 
intel_vgt_deballoon() consume it at driver unload, it deballoon reserved ggtt 
space. 
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Zhang, Xiong Y]

> On Thu, 29 Jun 2017, Daniel Vetter <dan...@ffwll.ch> 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.zh...@intel.com>
> >> ---
> >>  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.
> 
> > 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.vet...@ffwll.ch>
> >
> > 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.
[Zhang, Xiong Y] Yes, I remembered your concern and have been seeking
the accurate map between IGD and PCH in the past months. Unfortunately
no one could give us such document. 
Then as Jonnas suggested, we try to pass real pch id from host to guest.
But we couldn't find a secure and acceptable register to pass such info.
Finally this issue blocks QA CI system for a long time and QA complained 
this. So we decided to send this again and resolve part of issue.

This is a limitation of IGD passthrough and need a spec which define
how to pass real pch id from host to guest in virtual environment. But this
need the top level design and much more time.
thanks
> 
> 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).
> 
> 
> 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@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Zhang, Xiong Y]

> 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.zh...@intel.com>
> 
> Looks ok to me, this is the assumption of the non-passthrough case
> anyway:
> Reviewed-by: Imre Deak <imre.d...@intel.com>
> 
> I noticed a few issues in the surrounding code: SPT/SPT_LP and
> CNP/CNP_LP have the same problem, although we don't need to distinguish
> between them atm. I think a cleaner way would be to adjust id and ext_id
> in the pass-through case in intel_detect_pch() upfront and set
> dev_priv->pch_type accordingly the same way as it's done in the
> non-passthrough case.
[Zhang, Xiong Y] Thanks for your suggestion.
pch_id in passthrough is guessed and isn't fully accurate,  so I don't add it to
SPT and CNP. Currently we are seeking acceptable method to pass pch id from
host to guest, once this decided, we will follow your suggestion.
> 
> Also, unrelated to the pass-through case, the HAS_PCH_CNP_LP() macro
> looks bogus, it checks only 8 bits of the PCI device ID instead of 9, so
> it'll be false on CNP_LP platforms (and true on SPT_LP).
[Zhang, Xiong Y] Please help fix it although HAS_PCH_CNP_LP() isn't used atm.
> 
> --Imre
> 
> > ---
> >  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;
> > 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Zhang, Xiong Y]

> On ke, 2017-05-03 at 09:22 +0000, Zhang, Xiong Y wrote:
> > >
> > > >
> > > > + David and Jon
> > > >
> > > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> > > >
> > > > The blocking issue I see is that bisecting is still not pointing at
> > > > relevant commits. Both bisected commits from Bugzilla are not related
> > > > to changes in stolen memory usage behavior. I'd assume a successful
> > > > bisect to land at the patches where we start creating kernel internal
> > > > objects from stolen memory. Otherwise we could be ignoring a bug
> > > > elsewhere. If it consistently lands on those patches, then there might
> > > > be something wrong with them, in addition to stolen memory problems.
> > > [Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla
> descripted,
> > > guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has gpu
> hang
> > > in guest dmesg. From this point, we could do git bisect.
> > > But tons of IOMMU DMA R/W exception to stolen memory exist in host
> dmesg
> > > when guest kernel is 4.8 and 4.9. This means guest domain iommu table
> > > doesn't
> > > have mapping for stolen memory and IGD fail in accessing stolen memory
> > > from guest kernel 4.8 and 4.9. From this point, this issue isn't a 
> > > regression
> and
> > > shouldn't go git bisect. You could check this host error message from the
> > > bugzilla
> > > attachment. And this should be fixed first.
> > > Anyway, I will try my best to get the ideal commit through git bisect, but
> I'm
> > > afraid
> > > the result is the same as past because we don't have a stable good point 
> > > to
> > > start git
> > > bisect.
> > [Zhang, Xiong Y] hi, Joonas:
> > As you said, the gpu hang exist because i915 create ring buffer from stolen
> memory.
> > I did git bisect again, and the following commit is the first bad commit:
> > commit c58b735fc762e891481e92af7124b85cb0a51fce
> > Author: Chris Wilson <ch...@chris-wilson.co.uk>
> > Date:   Thu Aug 18 17:16:57 2016 +0100
> >
> > drm/i915: Allocate rings from stolen
> >
> > If we have stolen available, make use of it for ringbuffer allocation.
> > Previously this was restricted to !llc platforms, as writing to stolen
> > requires a GGTT mapping - but now that we have partial mappable
> support,
> > the mappable aperture isn't quite so precious so we can use it more
> > freely and ringbuffers are a good user for the otherwise wasted stolen.
> >
> > After reverting this patch from drm-intel-nightly, I didn't see gpu hang 
> > during
> guest boot process.
> > So what's our next step ?
> 
> An appropriate next step would be to evaluate how much work it is to
> support the RMRR passthrough David mentioned about in his commit.
[Zhang, Xiong Y] As Kevin explained, KVM community found the disadvantage
Of RMRR and have decided to not support RMRR passthrough, so it is really hard
for us to push such solution and isn't related to the workload.
Except usb and graphic card, all other devices with RMRR couldn't passthrough
to guest. But the driver of usb and graphic card couldn't access RMRR in such
environment.
https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

> I'd also go talk with the IGD team, why they refuse to load the driver
> when stolen memory is correctly reported as zero, and insist on being
> lied to.
[Zhang, Xiong Y] thanks a lot for doing so.
> 
> While doing that, please update the freedesktop.org bugs.
[Zhang, Xiong Y] sure, I will update bugzilla once we have further
finding and make a decision.
> 
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Zhang, Xiong Y]

> > + David and Jon
> >
> > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> >
> > The blocking issue I see is that bisecting is still not pointing at
> > relevant commits. Both bisected commits from Bugzilla are not related
> > to changes in stolen memory usage behavior. I'd assume a successful
> > bisect to land at the patches where we start creating kernel internal
> > objects from stolen memory. Otherwise we could be ignoring a bug
> > elsewhere. If it consistently lands on those patches, then there might
> > be something wrong with them, in addition to stolen memory problems.
> [Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla 
> descripted,
> guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has gpu hang
> in guest dmesg. From this point, we could do git bisect.
> But tons of IOMMU DMA R/W exception to stolen memory exist in host dmesg
> when guest kernel is 4.8 and 4.9. This means guest domain iommu table
> doesn't
> have mapping for stolen memory and IGD fail in accessing stolen memory
> from guest kernel 4.8 and 4.9. From this point, this issue isn't a regression 
> and
> shouldn't go git bisect. You could check this host error message from the
> bugzilla
> attachment. And this should be fixed first.
> Anyway, I will try my best to get the ideal commit through git bisect, but I'm
> afraid
> the result is the same as past because we don't have a stable good point to
> start git
> bisect.
[Zhang, Xiong Y] hi, Joonas:
As you said, the gpu hang exist because i915 create ring buffer from stolen 
memory.
I did git bisect again, and the following commit is the first bad commit:
commit c58b735fc762e891481e92af7124b85cb0a51fce
Author: Chris Wilson <ch...@chris-wilson.co.uk>
Date:   Thu Aug 18 17:16:57 2016 +0100

drm/i915: Allocate rings from stolen

If we have stolen available, make use of it for ringbuffer allocation.
Previously this was restricted to !llc platforms, as writing to stolen
requires a GGTT mapping - but now that we have partial mappable support,
the mappable aperture isn't quite so precious so we can use it more
freely and ringbuffers are a good user for the otherwise wasted stolen.

After reverting this patch from drm-intel-nightly, I didn't see gpu hang during 
guest boot process.
So what's our next step ?

thanks
> 
> > Disabling power saving makes many bugs go away, but we still don't
> > disable power saving as a resolution to such bugs, but instead root
> > cause and fix the individual bugs.
> [Zhang, Xiong Y] I add i915.enable_rc6=0, i915.enable_dc=0,
> i915.enable_fbc=0,
> I915.enable_psr=0, i915.disable_power_well=0,i915.enable_ips=0 to grub.
> But gpu hang exist in guest and DMA R/W error exist in host.
> >
> > > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > > identity mapping in iommu table when host boot up, so IGD could access
> > > stolen memory in host OS. While according to 'commit c875d2c1b808
> > > ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
> > domains")',RMRR
> > > isn't supported by kvm, then both EPT and guest iommu domain table lack
> > > of maaping for stolen memory in kvm IGD passthrough environment.
> >
> > Commit message text still fails to address that an exclusion was added
> > by commit:
> >
> > commit 18436afdc11a00ac881990b454cfb2eae81d6003
> > Author: David Woodhouse <david.woodho...@intel.com>
> > Date:   Wed Mar 25 15:05:47 2015 +
> >
> > iommu/vt-d: Allow RMRR on graphics devices too
> >
> >     Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from
> > IOMMU API
> > domains") prevents certain options for devices with RMRRs. This even
> > prevents those devices from getting a 1:1 mapping with 'iommu=pt',
> > because we don't have the code to handle *preserving* the RMRR
> > regions
> > when moving the device between domains.
> >
> > 
> >
> > The quoted part of David's commit message leads me to believe it's
> > simply lack of some code in kernel for juggling the RMRRs when moving a
> > device between domains that is missing. Why is not that considered
> > instead? With that implemented, we would have more transparent pass-
> > through, which should be good.
> [Zhang, Xiong Y] c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from
> IOMMU API domains). This patch prevent devices associated with RMRRs from
> assigning to a guest, the one of reason is it knows RMRR isn't supported in
> guest
> domain IOMMU table, If these device's driver still access RMRR from guest,
> serious error will happen.
> 1

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Zhang, Xiong Y]

> + David and Jon
> 
> On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> 
> The blocking issue I see is that bisecting is still not pointing at
> relevant commits. Both bisected commits from Bugzilla are not related
> to changes in stolen memory usage behavior. I'd assume a successful
> bisect to land at the patches where we start creating kernel internal
> objects from stolen memory. Otherwise we could be ignoring a bug
> elsewhere. If it consistently lands on those patches, then there might
> be something wrong with them, in addition to stolen memory problems.
[Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla 
descripted,
guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has gpu hang
in guest dmesg. From this point, we could do git bisect.
But tons of IOMMU DMA R/W exception to stolen memory exist in host dmesg 
when guest kernel is 4.8 and 4.9. This means guest domain iommu table doesn't 
have mapping for stolen memory and IGD fail in accessing stolen memory 
from guest kernel 4.8 and 4.9. From this point, this issue isn't a regression 
and
shouldn't go git bisect. You could check this host error message from the 
bugzilla 
attachment. And this should be fixed first.
Anyway, I will try my best to get the ideal commit through git bisect, but I'm 
afraid
the result is the same as past because we don't have a stable good point to 
start git
bisect.

> Disabling power saving makes many bugs go away, but we still don't
> disable power saving as a resolution to such bugs, but instead root
> cause and fix the individual bugs.
[Zhang, Xiong Y] I add i915.enable_rc6=0, i915.enable_dc=0, i915.enable_fbc=0,
I915.enable_psr=0, i915.disable_power_well=0,i915.enable_ips=0 to grub.
But gpu hang exist in guest and DMA R/W error exist in host.
> 
> > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > identity mapping in iommu table when host boot up, so IGD could access
> > stolen memory in host OS. While according to 'commit c875d2c1b808
> > ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
> domains")',RMRR
> > isn't supported by kvm, then both EPT and guest iommu domain table lack
> > of maaping for stolen memory in kvm IGD passthrough environment.
> 
> Commit message text still fails to address that an exclusion was added
> by commit:
> 
> commit 18436afdc11a00ac881990b454cfb2eae81d6003
> Author: David Woodhouse <david.woodho...@intel.com>
> Date:   Wed Mar 25 15:05:47 2015 +
> 
> iommu/vt-d: Allow RMRR on graphics devices too
> 
>     Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from
> IOMMU API
> domains") prevents certain options for devices with RMRRs. This even
> prevents those devices from getting a 1:1 mapping with 'iommu=pt',
> because we don't have the code to handle *preserving* the RMRR
> regions
> when moving the device between domains.
> 
> 
> 
> The quoted part of David's commit message leads me to believe it's
> simply lack of some code in kernel for juggling the RMRRs when moving a
> device between domains that is missing. Why is not that considered
> instead? With that implemented, we would have more transparent pass-
> through, which should be good.
[Zhang, Xiong Y] c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from
IOMMU API domains). This patch prevent devices associated with RMRRs from
assigning to a guest, the one of reason is it knows RMRR isn't supported in 
guest 
domain IOMMU table, If these device's driver still access RMRR from guest, 
serious error will happen.
18436afdc ("iommu/vt-d: Allow RMRR on graphics devices too "), add an exception
to above commit. So IGD could be assigned to a guest. But this doesn't mean IGD
1:1 mapping for RMRR will be support in guest domain iommu table
'iommu=pt' is to set 1:1 mapping for all pci device in host domain iommu table.

When one device is assigned to a guest and this guest boot up, this guest domain
Iommu table will take place of host domain iommu table on hardware. Our issue
is guest domain iommu table doesn't have 1:1 mapping for RMRR.
In order to set up 1:1 mapping for RMRR in guest domain iommu table, we have
to modify kvm and qemu and kvm community have declined this.
> 
> Also, was fixing the IGD driver loading with zero stolen memory
> considered instead? All this information should exist in the commit
> message.
[Zhang, Xiong Y] IGD and i915 driver read pci config register 0x50 to get 
the size of stolen memory. When guest read this register, qemu could trap
it and return one value to guest.
So in order to  " fixing the IGD driver loading with zero stolen memory ",
We have to modify both Qemu and IGD driver:
1) QEMU: trap read from pci cfg 0x50 register, then return zero to guest
2) IGD driver: when IGD dri

Re: [Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

[Zhang, Xiong Y]

> On Thu, 13 Apr 2017 05:44:18 +
> "Zhang, Xiong Y" <xiong.y.zh...@intel.com> wrote:
> 
> > > On Wed, 12 Apr 2017 20:20:00 +0800
> > > Xiong Zhang <xiong.y.zh...@intel.com> wrote:
> > >
> > > > Stolen memory isn't a standard pci resource and exists in RMRR which
> has
> > > > identity mapping in iommu table, IGD could access stolen memory in
> host
> > > OS.
> > > > While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude
> devices
> > > using
> > > > RMRRs from IOMMU API domains")',RMRR isn't supported by kvm, then
> > > both EPT
> > > > and guest iommu domain table lack of maaping for stolen memory in
> kvm
> > > IGD
> > > > passthrough environment. If IGD access stolen memory in such
> environment,
> > > > many iommu exceptions exist in host dmesg and gpu hang exists also.
> > > > DMAR: [DMA Read] Request device [00:02.0] fault addr da012000
> > > > [fault reason 05] PTE Write access is not set
> > > > DMAR: [DMA Read] Request device [00:02.0] fault addr da2df000
> > > > [fault reason 06] PTE Read access is not set
> > > >
> > > > So stolen memory should be disabled in KVM IGD passthrough
> environment,
> > > > this patch detects such environment through the existence of qemu
> > > emulated
> > > > isa bridge.
> > > >
> > > > When the real ISA bridge is also passed through to guest, guest will 
> > > > have
> > > > two isa bridges: emulated and real. Qemu guarantees the
> busnum:devnum.
> > > > funcnum of emulated isa bridge is always less than the real one. Then
> > > > emulated isa bridge is always detected first by pci_get_class(ISA). So
> > > > stolen memory will be disabled in this case also.
> > >
> > > Where does QEMU make this guarantee or any sort of guarantee wrt the
> > > ISA bridge?  Thanks,
> > >
> > > Alex
> > >
> > [Zhang, Xiong Y] In my guest environment I always see emulated devices
> > are at head of pci device list, the passed through devices are at tail. 
> > Even if
> > I want to assign the passed IGD to 00:02.0, the qemu tell me 00:02.0 has
> already
> > occupied by emulated graphic card.
> > If I pass through real ISA bridge to guest, the emulated ISA bridge is at
> 00:01.0,
> > While real ISA bridge is at 00:04.0.
> > Then I checked the code: emulated devices are created in pc_init1() 
> > function,
> it
> > creates host_bridge firstly, create isa_bridge secondly, create all other
> devices following.
> > So I think Qemu could guarantee. Now I'm suspect it, and need your coach.
> 
> So you're calling the current default behavior a guarantee.  That's not
> valid, it ignores that we might have future chipsets that do things
> differently and it ignores that the user can override some of those
> defaults and specify addresses for devices that may not match your
> expectations.  There is no agreement with the QEMU community to make
> this a stable feature of the VM.  What about using smbios information
> or detecting kvm (or any hypervisor) via the hypervisor MSRs?  You could
> maybe use the VM PCI host bridge and figure out that this version of
> IGD never shipped on 440fx or q35, but then you'll have the maintenance
> headache of updating the code for any new chipset QEMU decides to
> implement. Thanks,
> 
[Zhang, Xiong Y] Thanks for your teach and propose.
For smbios, could you teach me which type and field could be used ?
For hypervisor MSRs, from 
https://www.kernel.org/doc/Documentation/virtual/kvm/msr.txt,
We should use cupid(0x4001) first, then use rdmsr(), in this case we could 
use
cupid(0x4000) directly to detect kvm. But I don't know whether community 
could accept
it or not ?

> Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

[Zhang, Xiong Y]

> On Wed, 12 Apr 2017 20:20:00 +0800
> Xiong Zhang <xiong.y.zh...@intel.com> wrote:
> 
> > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > identity mapping in iommu table, IGD could access stolen memory in host
> OS.
> > While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices
> using
> > RMRRs from IOMMU API domains")',RMRR isn't supported by kvm, then
> both EPT
> > and guest iommu domain table lack of maaping for stolen memory in kvm
> IGD
> > passthrough environment. If IGD access stolen memory in such environment,
> > many iommu exceptions exist in host dmesg and gpu hang exists also.
> > DMAR: [DMA Read] Request device [00:02.0] fault addr da012000
> > [fault reason 05] PTE Write access is not set
> > DMAR: [DMA Read] Request device [00:02.0] fault addr da2df000
> > [fault reason 06] PTE Read access is not set
> >
> > So stolen memory should be disabled in KVM IGD passthrough environment,
> > this patch detects such environment through the existence of qemu
> emulated
> > isa bridge.
> >
> > When the real ISA bridge is also passed through to guest, guest will have
> > two isa bridges: emulated and real. Qemu guarantees the busnum:devnum.
> > funcnum of emulated isa bridge is always less than the real one. Then
> > emulated isa bridge is always detected first by pci_get_class(ISA). So
> > stolen memory will be disabled in this case also.
> 
> Where does QEMU make this guarantee or any sort of guarantee wrt the
> ISA bridge?  Thanks,
> 
> Alex
> 
[Zhang, Xiong Y] In my guest environment I always see emulated devices 
are at head of pci device list, the passed through devices are at tail. Even if
I want to assign the passed IGD to 00:02.0, the qemu tell me 00:02.0 has already
occupied by emulated graphic card.
If I pass through real ISA bridge to guest, the emulated ISA bridge is at 
00:01.0,
While real ISA bridge is at 00:04.0.
Then I checked the code: emulated devices are created in pc_init1() function, it
creates host_bridge firstly, create isa_bridge secondly, create all other 
devices following.
So I think Qemu could guarantee. Now I'm suspect it, and need your coach. 

thanks

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V5] drm/i915: Disable stolen memory when i915 runs on qemu

[Zhang, Xiong Y]

> + Kevin and David
> 
> On ke, 2017-04-12 at 20:20 +0800, Xiong Zhang wrote:
> > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > identity mapping in iommu table, IGD could access stolen memory in host
> OS.
> > While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices
> using
> > RMRRs from IOMMU API domains")',RMRR isn't supported by kvm, then
> both EPT
> > and guest iommu domain table lack of maaping for stolen memory in kvm
> IGD
> > passthrough environment. If IGD access stolen memory in such environment,
> > many iommu exceptions exist in host dmesg and gpu hang exists also.
> > DMAR: [DMA Read] Request device [00:02.0] fault addr da012000
> > [fault reason 05] PTE Write access is not set
> > DMAR: [DMA Read] Request device [00:02.0] fault addr da2df000
> > [fault reason 06] PTE Read access is not set
> >
> > So stolen memory should be disabled in KVM IGD passthrough environment,
> > this patch detects such environment through the existence of qemu
> emulated
> > isa bridge.
> >
> > When the real ISA bridge is also passed through to guest, guest will have
> > two isa bridges: emulated and real. Qemu guarantees the busnum:devnum.
> > funcnum of emulated isa bridge is always less than the real one. Then
> > emulated isa bridge is always detected first by pci_get_class(ISA). So
> > stolen memory will be disabled in this case also.
> >
> > Stolen memory exists in kernel for a long time, but this patch depends
> > on INTEL_PCH_QEMU_DEVICE_ID_TYPE which was introduced in v4.5 kernel,
> > so this patch should be backported into v4.5 kernel and above.
> >
> > v2:GVT-g may run in non qemu (Zhenyu)
> > v3:Make commit message clear (Daniel)
> > v4:Fix typo
> > v5:Exclude P2X as it is used for VMware (Joonas)
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028
> >
> > Signed-off-by: Xiong Zhang <xiong.y.zh...@intel.com>
> > Reviewed-by: Zhenyu Wang <zhen...@linux.intel.com>
> > Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> > Cc: sta...@vger.kernel.org
> 
> The commit message still fails to address the fact that the Bugzilla
> entry has a completely bogus bisect, the fact that there is a later
> commit that allows RMRRs on graphics devices;
[Zhang, Xiong Y] Indeed when I boot kernel 3.18, gpu hang don't
happen during boot process, but IOMMU DMA R/W to stolen memory
exception still exist in host dmesg.
When I boot kernel 3.19 and above, I see DMA R/W exception
in host dmesg and gpu hang. I'm lack of the knowledge to analyze the
gpu hang error. And I have updated the error into bugzilla, could you
help check whether this hang is caused by GT accessing to stolen memory
or not?

https://bugs.freedesktop.org/show_bug.cgi?id=99028
and
https://bugs.freedesktop.org/show_bug.cgi?id=99025
are the same issue which could be fixed by disable stolen memory.
But bisect result are different, so I think the first bad commit of 
git bisect isn't accurate.

> 
> commit 18436afdc11a00ac881990b454cfb2eae81d6003
> Author: David Woodhouse <david.woodho...@intel.com>
> Date:   Wed Mar 25 15:05:47 2015 +
> 
> iommu/vt-d: Allow RMRR on graphics devices too
> 
[Zhang, Xiong Y] 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices
Using RMRRs from IOMMU API domains")', this commit prevent devices
associated with RMRR from passing through to guest.
'commit 18436afdc11a ("iommu/vt-d: Allow RMRR on graphics devices too")',
this commit add an exception for graphics device to above commit. So that
IGD could be assigned (pass through) to guest.

Hi, David:
   The following message exists in your 18436afdc11a commit message: 
"Add an exclusion for graphics devices too, so that 'iommu=pt' works
there. We should be able to successfully assign graphics devices to
guests too, as long as the initial handling of stolen memory is
reconfigured appropriately. This has certainly worked in the past."
What's the mean of "initial handling of stolen memory is reconfigured 
appropriately" ? we meet guest IGD accessing stolen memory issue.
 
> And the fact that GuC status is still not answered even I explicitly
> asked for it.
[Zhang, Xiong Y] GuC accessing to stolen memory bypass VT-d, Kevin has
confirmed this with VPG.

I add i915.enable_guc_loading=1 and i915.enable_guc_submission=1 option, and 
the dmesg demonstrate guc works when stolen memory is disabled.
[5.265653] [drm:intel_uc_prepare_fw [i915]] fetch uC fw from 
i915/skl_guc_ver6_1.bin succeeded, fw 9167bc93c1e0
[5.265668] [drm:intel_uc_prepare_fw [i915]] firmware version 6.1 OK 
(minimum 6.1)
[5.265709] [drm:intel_uc_prepare_fw [i915]

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for Gen7.5+ in virtual environment

[Zhang, Xiong Y]

> On Wed, Mar 29, 2017 at 05:02:47PM +0800, Xiong Zhang wrote:
> > In a virtual passthrough environment, the ISA bridge isn't able to
> > be passed through. So pch_id couldn't be gotten from ISA bridge, but
> > pch_id is used to identify LPT_H and LPT_LP, this patch set pch_id
> > according to IGD type.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938
> >
> > Signed-off-by: Xiong Zhang <xiong.y.zh...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> > index 8b807a9..32a9bff 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -135,9 +135,17 @@ 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;
> > DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> > } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> > ret = PCH_SPT;
> > +   if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv))
> > +   dev_priv->pch_id = INTEL_PCH_SPT_LP_DEVICE_ID_TYPE;
> > +       else
> > +   dev_priv->pch_id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> 
> I'm not 100% sure the ULT/ULX <=> LP thing always holds. I *think* it
> should but I've never been able to convince myself totally.
[Zhang, Xiong Y] For BDW ULT/ULX, it should be LP. A picture from 
https://gfxspecs.intel.com/Predator/Home/Index/4216 could confirm this.
For HSW ULT/ULX, I couldn't find a material to confirm this.
Anyway I copy this condition from the WARN_ON() in intel_detect_pch() 

For SKL/KBL ULT/ULX, I couldn't find a material to confirm this neither.

> As far as KBL goes, maybe we want PCH_KBP for it? Although I don't actually
> know why we even make the distinction between the two since they seem
> identical for us, and we don't distinguish LPT vs. WPT either. Rodrigo?
[Zhang, Xiong Y] For PCH_KBP, I couldn't find out which KBL type will co-work 
with it.
As the real ISA Bridge doesn't exist in a emulated guest machine, we couldn't 
get the real and accurate pch_id in guest. In such passthrough virtual 
environment, the only real HW is IGD which is passed through to guest, we could 
only assume the pch_id from this IGD.
Fortunately pch_id is only used to identify LPT_LP and LPT_H currently.
Without this patch, pch_id is totally wrong. And on LPT_LP platform without 
this patch, the local HDMI/DP display couldn't lightup when guest boot up. But 
this patch could only remedy part of pch_id. Currently I have two plans to 
improve this patch:
1) only remain pch_id assuming for HSW and BDW, as this is really we need to 
fix the bug.
  Delete pch_id assuming for SKL and KBL, as currently i915 driver don't use it.
2) Claim this patch's limitation in commit message.
Any suggestion ?
> > DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> > }
> >
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHi v2] drm/i915: Enhanced disable access to stolen memory as a guest

[Zhang, Xiong Y]

> > Reviewed-by: Zhenyu Wang <zhen...@linux.intel.com>
> 
> Entirely disabling stolen is rather massive, this stuff is supposed to
> work ... There should be special RMRR mappings in the iommu to help the
> guest access the stolen range correctly from the gpu.
> 
> Which machine where does this blow up on?
> -Daniel
[Zhang, Xiong Y] Yes. Stolen memory is protected by RMRR on host. But Qemu 
couldn't support and don't have plan to support RMRR. Then EPT lack of mapping 
for stolen memory, guest couldn't access it.
The Qemu/Vfio is designed by Redhat engineers, Redhat has a white paper to 
explain why Qemu don't support RMRR:
https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> 
> On Thu, 26 Nov 2015 16:58:09 +0100,
> Ville Syrjälä wrote:
> >
> > On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote:
> > > On Thu, 26 Nov 2015 16:43:23 +0100,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote:
> > > > >
> > > > >
> > > > > On 2015-11-26 16:23, Takashi Iwai wrote:
> > > > > > On Thu, 26 Nov 2015 16:08:06 +0100,
> > > > > > David Henningsson wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On 2015-11-26 10:24, Takashi Iwai wrote:
> > > > > >>> On Thu, 26 Nov 2015 10:16:17 +0100,
> > > > > >>> Zhang, Xiong Y wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>> On Thu, 26 Nov 2015 08:57:30 +0100,
> > > > > >>>>> Zhang, Xiong Y wrote:
> > > > > >>>>>>
> > > > > >>>>>>>>> BTW, I have a patchset to avoid the audio h/w wakeup by a
> new
> > > > > >>>>>>>>> component ops to get ELD and connection states.  It was
> posted to
> > > > > >>>>>>>>> alsa-devel shortly ago just as a reference, but this should
> work well
> > > > > >>>>>>>>> in such a case, too.  The test patches are found in
> test/hdmi-jack
> > > > > >>>>>>>>> branch of my sound git tree.
> > > > > >>>>>>>
> > > > > >>>>>>> Did you try this branch (merge onto intel-test-nightly)?
> > > > > >>>>>>>
> > > > > >>>>>> [Zhang, Xiong Y] Yes, this branch could fix my issue.
> > > > > >>>>>
> > > > > >>>>> OK, good to hear.  But this isn't for 4.4 or backport, as it's 
> > > > > >>>>> more
> > > > > >>>>> radical changes.
> > > > > >>>>>
> > > > > >>>>> Could you check the patch below instead?  This suppresses the
> notifier
> > > > > >>>>> handling during suspend.  It's bad, but the hotplug should be 
> > > > > >>>>> still
> > > > > >>>>> handled via normal unsol event, so it should keep working, good
> enough
> > > > > >>>>> as a stop gap.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Takashi
> > > > > >>>>>
> > > > > >>>>> ---
> > > > > >>>>> diff --git a/sound/pci/hda/patch_hdmi.c
> b/sound/pci/hda/patch_hdmi.c
> > > > > >>>>> index bdb6f226d006..f7c70e2ae65c 100644
> > > > > >>>>> --- a/sound/pci/hda/patch_hdmi.c
> > > > > >>>>> +++ b/sound/pci/hda/patch_hdmi.c
> > > > > >>>>> @@ -33,6 +33,7 @@
> > > > > >>>>>#include 
> > > > > >>>>>#include 
> > > > > >>>>>#include 
> > > > > >>>>> +#include 
> > > > > >>>>>#include 
> > > > > >>>>>#include 
> > > > > >>>>>#include 
> > > > > >>>>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void
> *audio_ptr, int
> > > > > >>>>> port)
> > > > > >>>>> struct hda_codec *codec = audio_ptr;
> > > > > >>>>> int pin_nid = port + 0x04;
> > > > > >>>>>
> > > > > >>>>> -   check_presence_and_report(codec, pin_nid);
> > > > > >>>>> +   if (!atomic_read(>core.in_pm) &&
> > > > > >>>>> +   !pm_runtime_suspended(hda_codec_dev(codec)))
> > > > > >>>>> +   check_presence_and_report(codec, pin_nid);
> > > > > >>>>>}
> > > > > >>>>>
> > > > > >>>>>static int patch_generic_hdmi(struct hda_codec *cod

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Thu, 26 Nov 2015 08:57:30 +0100,
> Zhang, Xiong Y wrote:
> >
> > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > > > component ops to get ELD and connection states.  It was posted to
> > > > > alsa-devel shortly ago just as a reference, but this should work well
> > > > > in such a case, too.  The test patches are found in test/hdmi-jack
> > > > > branch of my sound git tree.
> > >
> > > Did you try this branch (merge onto intel-test-nightly)?
> > >
> > [Zhang, Xiong Y] Yes, this branch could fix my issue.
> 
> OK, good to hear.  But this isn't for 4.4 or backport, as it's more
> radical changes.
> 
> Could you check the patch below instead?  This suppresses the notifier
> handling during suspend.  It's bad, but the hotplug should be still
> handled via normal unsol event, so it should keep working, good enough
> as a stop gap.
> 
> 
> Takashi
> 
> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..f7c70e2ae65c 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> port)
>   struct hda_codec *codec = audio_ptr;
>   int pin_nid = port + 0x04;
> 
> - check_presence_and_report(codec, pin_nid);
> + if (!atomic_read(>core.in_pm) &&
> + !pm_runtime_suspended(hda_codec_dev(codec)))
> + check_presence_and_report(codec, pin_nid);
>  }
> 
>  static int patch_generic_hdmi(struct hda_codec *codec)
[Zhang, Xiong Y]  this patch couldn't remove the error message. So audio 
controller isn't in Runtime D3 after azx_suspend().

thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

Recently I always see the following error message during S4 or S3 resume with 
drm-intel-nightly.
[   97.778063] PM: Syncing filesystems ... done.
[   97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
[   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
[   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
[   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
[   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
[   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
[   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
[   97.806363] PM: Basic memory bitmaps created
[   97.806409] PM: Preallocating image memory... done (allocated 321557 pages)
[   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s)
[   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[   98.151998] Suspending console(s) (use no_console_suspend to debug)
[   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: 
Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 
128
[  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, switching 
to polling mode: last cmd=0x206f2f00
[  102.195492] snd_hda_intel :00:1f.3: No response from codec, disabling 
MSI: last cmd=0x206f2f00
[  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, switching 
to single_cmd mode: last cmd=0x206f2f00
[  103.201396] azx_single_wait_for_response: 42 callbacks suppressed

The bisect result points to this commit. 
I checked this patch and had one question: if i915 driver wake up ahead of 
snd_hda_intel driver during resume,  i915 driver will call audio driver's 
hdmi_present_sense() function through this patch, but the audio interrupt is 
disabled at this moment, how could hdmi_present_sense() get the response from 
codec ?  

thanks
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> David Henningsson
> Sent: Saturday, August 29, 2015 1:03 AM
> To: ti...@suse.de; alsa-de...@alsa-project.org;
> intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Yang, Libin; 
> Vetter,
> Daniel
> Cc: David Henningsson
> Subject: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD 
> notify
> events
> 
> Whenever there is an event from the i915 driver, wake the codec
> and recheck plug/unplug + ELD status.
> 
> This fixes the issue with lost unsol events in power save mode,
> the codec and controller can now sleep in D3 and still know when
> the HDMI monitor has been connected.
> 
> Right now, this might mean we get two callbacks from the same event,
> one from the unsol event and one from the i915 driver, but this is
> not harmful and can be optimised away in a later patch.
> 
> Reviewed-by: Takashi Iwai 
> Signed-off-by: David Henningsson 
> ---
>  sound/pci/hda/patch_hdmi.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index a97db5f..acbfbe0 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -37,6 +37,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "hda_codec.h"
>  #include "hda_local.h"
>  #include "hda_jack.h"
> @@ -144,6 +146,9 @@ struct hdmi_spec {
>*/
>   struct hda_multi_out multiout;
>   struct hda_pcm_stream pcm_playback;
> +
> + /* i915/powerwell (Haswell+/Valleyview+) specific */
> + struct i915_audio_component_audio_ops i915_audio_ops;
>  };
> 
> 
> @@ -2191,6 +2196,9 @@ static void generic_hdmi_free(struct hda_codec
> *codec)
>   struct hdmi_spec *spec = codec->spec;
>   int pin_idx;
> 
> + if (is_haswell_plus(codec) || is_valleyview_plus(codec))
> + 

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Wed, 25 Nov 2015 10:56:51 +0100,
> Zhang, Xiong Y wrote:
> >
> > Recently I always see the following error message during S4 or S3 resume
> with drm-intel-nightly.
> > [   97.778063] PM: Syncing filesystems ... done.
> > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> done.
> > [   97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
> > [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
> > [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> > [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> > [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> > [   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
> > [   97.806363] PM: Basic memory bitmaps created
> > [   97.806409] PM: Preallocating image memory... done (allocated 321557
> pages)
> > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> MB/s)
> > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 
> > seconds)
> done.
> > [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2:
> HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > [   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0,
> force 128
> > [  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout,
> switching to polling mode: last cmd=0x206f2f00
> > [  102.195492] snd_hda_intel :00:1f.3: No response from codec,
> disabling MSI: last cmd=0x206f2f00
> > [  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout,
> switching to single_cmd mode: last cmd=0x206f2f00
> > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> >
> > The bisect result points to this commit.
> > I checked this patch and had one question: if i915 driver wake up ahead of
> snd_hda_intel driver during resume,  i915 driver will call audio driver's
> hdmi_present_sense() function through this patch, but the audio interrupt is
> disabled at this moment, how could hdmi_present_sense() get the response
> from codec ?
> 
> Yeah, a bad thing happens there.  The fix should be simple like below,
> though.  Basically the pins are checked in the resume callback in
> anyway, so there is no need to handle the notification during PM.
> 
> Could you check whether it works?
> 
> 
> thanks,
> 
> Takashi

Strange, your patch couldn't get away the error message.

thanks
> 
> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..b468fe0e6195 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> port)
>   struct hda_codec *codec = audio_ptr;
>   int pin_nid = port + 0x04;
> 
> - check_presence_and_report(codec, pin_nid);
> + /* don't call notifier during PM; will be checked in resume callback */
> + if (!atomic_read(>core.in_pm))
> + check_presence_and_report(codec, pin_nid);
>  }
> 
>  static int patch_generic_hdmi(struct hda_codec *codec)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> > > BTW, I have a patchset to avoid the audio h/w wakeup by a new
> > > component ops to get ELD and connection states.  It was posted to
> > > alsa-devel shortly ago just as a reference, but this should work well
> > > in such a case, too.  The test patches are found in test/hdmi-jack
> > > branch of my sound git tree.
> 
> Did you try this branch (merge onto intel-test-nightly)?
> 
[Zhang, Xiong Y] Yes, this branch could fix my issue.

> 
> Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Wed, 25 Nov 2015 11:57:13 +0100,
> Zhang, Xiong Y wrote:
> >
> > > On Wed, 25 Nov 2015 10:56:51 +0100,
> > > Zhang, Xiong Y wrote:
> > > >
> > > > Recently I always see the following error message during S4 or S3 resume
> > > with drm-intel-nightly.
> > > > [   97.778063] PM: Syncing filesystems ... done.
> > > > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> > > done.
> > > > [   97.804297] PM: Marking nosave pages: [mem
> 0x-0x0fff]
> > > > [   97.804302] PM: Marking nosave pages: [mem
> 0x00058000-0x00058fff]
> > > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
> > > > [   97.804310] PM: Marking nosave pages: [mem
> 0x84c11000-0x84c12fff]
> > > > [   97.804312] PM: Marking nosave pages: [mem
> 0x876fc000-0x87746fff]
> > > > [   97.804317] PM: Marking nosave pages: [mem
> 0x8785e000-0x87fe9fff]
> > > > [   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
> > > > [   97.806363] PM: Basic memory bitmaps created
> > > > [   97.806409] PM: Preallocating image memory... done (allocated
> 321557
> > > pages)
> > > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > > MB/s)
> > > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds)
> > > done.
> > > > [   98.151998] Suspending console(s) (use no_console_suspend to
> debug)
> > > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi
> hdaudioC0D2:
> > > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > > [   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> last
> > > cmd=0x206f2e08
> > > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size
> is 0,
> > > force 128
> > > > [  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > > switching to polling mode: last cmd=0x206f2f00
> > > > [  102.195492] snd_hda_intel :00:1f.3: No response from codec,
> > > disabling MSI: last cmd=0x206f2f00
> > > > [  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > > switching to single_cmd mode: last cmd=0x206f2f00
> > > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > > >
> > > > The bisect result points to this commit.
> > > > I checked this patch and had one question: if i915 driver wake up ahead 
> > > > of
> > > snd_hda_intel driver during resume,  i915 driver will call audio driver's
> > > hdmi_present_sense() function through this patch, but the audio interrupt
> is
> > > disabled at this moment, how could hdmi_present_sense() get the
> response
> > > from codec ?
> > >
> > > Yeah, a bad thing happens there.  The fix should be simple like below,
> > > though.  Basically the pins are checked in the resume callback in
> > > anyway, so there is no need to handle the notification during PM.
> > >
> > > Could you check whether it works?
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> >
> > Strange, your patch couldn't get away the error message.
> 
> OK, then it's not about the race *during* the hd-audio driver
> resuming or such.  I guess it's the other way round: the i915 driver
> notifies it unnecessarily while it's getting o

Re: [Intel-gfx] Skylake 6700k Intel HD Graphics 530 Display Port Panic

[Zhang, Xiong Y]

I see the similar error message on one SKL machine, but DP system works well 
and system doesn't panic.
I resolved it by one of the following three method, maybe you could try it.
1) boot with i915.disable_power_well=0
2)delete /lib/firmware/i915/skl_dmc_ver1.bin
3) apply the patch set in 
http://lists.freedesktop.org/archives/intel-gfx/2015-August/072870.html

thanks
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Matthew Minter
> Sent: Sunday, September 6, 2015 12:34 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] Skylake 6700k Intel HD Graphics 530 Display Port Panic
> 
> Hello,
> 
> I am currently trying to set up a newly built system with a Skylake
> 6700k CPU but am having an extremely
> reproducible kernel panic every time I connect a monitor to the display
> port connector of the Intel
> integrated graphics chip.
> 
> This issue occurs either immediately upon connecting a display port
> monitor to the machine while it is up
> or late in the boot process if the display port is connected at boot
> time.
> 
> The monitor which I am using is a Dell U3415W ultra wide and the
> motherboard is a MSI Z170A Gaming M7.
> 
> I am not entirely surprised by the link train errors as there appear to
> be various posts about users having
> problems with this monitor and display port training, what surprises me
> most is the fact it is causing a kernel panic.
> 
> Upon the panic happening the kernel prints the following dump (to the
> second non DP monitor), (note this is hand copied as I
> have no way to dump the messages anywhere but the display so pardon any
> small typos).
> 
> [   22.318630]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.365449]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.420272]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.475105]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.529931]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.584759]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.639588]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.649935]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   22.650532]  [drm:intel_dp_start_link_traln [i915]] *ERROR* too many
> full retries, give up
> [   24.329955]  Kernel panic - not syncing: Timeout: Not all CPUs
> entered broadcast exception handler
> [   25.345911]  Shutting down cpus with NMI
> [   25.356092]  Kernel offset: disabled
> [   25.356101]  Rebooting in 30 seconds.
> 
> If running kernel 4.2 occasionally these errors are followed by what
> seems to be a an mce machine check exception mentioning
>   a corrupt processor context which is very hard to note down as it is
> only on the screen very briefly. However if running the
> latest kernel from https://github.com/torvalds/linux only the above
> error occurs, not the mce exception. I am pretty confident
> the mce exception is spurious due to this and the fact the system
> otherwise tests out fine.
> 
> I apologise if this report is a little sparse on details, it is very
> hard to post mortem debug the system due to the panic and
> the fact I have no available serial terminal or hardware debugger.
> 
> Otherwise the system flawlessly passes memtest86+ and is completely
> stable even under heavy load.
> This issue seems to occur on every kernel I have tested so far including
> a stock ubuntu 15.4, a vanilla 4.0.5 kernel,
> a vanilla 4.2.0 kernel and the head of https://github.com/torvalds/linux
> as of a few hours ago.
> 
> The kernel config used for the kernel taken from git is available here:
> http://paste2.org/MH9vV4Le
> The 4.2 and 4.0.5 configs were extremely similar and only differ in the
> new entries made by oldconfig.
> 
> If there is anything I can do to produce more info I am more than happy
> to do so.
> Or if this is not the right mailing list for this issue please let me
> know where would be better.
> 
> Many thanks,
> Matthew
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.

[Zhang, Xiong Y]

 On Wed, 2015-08-26 at 11:15 +0300, Jani Nikula wrote:
  On Thu, 13 Aug 2015, Jindal, Sonika sonika.jin...@intel.com
  wrote:
   On 8/13/2015 8:57 AM, Zhang, Xiong Y wrote:
 On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
   On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
 -Original Message-
 From: Vivi, Rodrigo
 Sent: Saturday, August 8, 2015 8:34 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Vivi, Rodrigo; Zhang, Xiong Y
 Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A
 shares 4
 lanes.

 DDI-A and DDI-E shares the 4 lanes. So when DDI-E is
 present we
 need to configure lane count propperly for both.

 This was based on Sonika's
 [PATCH] drm/i915/skl: Select DDIA lane capability based
 upon vbt

 Credits-to: Sonika Jindal sonika.jin...@intel.com
 Cc: Xiong Zhang xiong.y.zh...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 ---
   drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
 drivers/gpu/drm/i915/intel_dp.c  |  8 +---
   2 files changed, 15 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_ddi.c
 b/drivers/gpu/drm/i915/intel_ddi.c
 index 110d546..557cecf 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct
 drm_device
 *dev, enum port port)
   struct intel_digital_port *intel_dig_port;
   struct intel_encoder *intel_encoder;
   struct drm_encoder *encoder;
 - bool init_hdmi, init_dp;
 + bool init_hdmi, init_dp, ddi_e_present;
 +
 + /*
 +  * On SKL we don't have a way to detect DDI-E
 so we
 rely
 on VBT.
 +  */
 + ddie_present = IS_SKYLAKE(dev) 
 + (dev_priv
 -vbt.ddi_port_info[PORT_E].supports_dp
  
 +  dev_priv
 -vbt.ddi_port_info[PORT_E].supports_dvi
  
 +  dev_priv
 -vbt.ddi_port_info[PORT_E].supports_hdmi);
[Zhang, Xiong Y]  ddie_present should be ddi_e_present

   init_hdmi = (dev_priv
 -vbt.ddi_port_info[port].supports_dvi ||
dev_priv
 -vbt.ddi_port_info[port].supports_hdmi);
 @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct
 drm_device
 *dev, enum port port)
   intel_dig_port-port = port;
   intel_dig_port-saved_port_bits =
 I915_READ(DDI_BUF_CTL(port)) 

   (DDI_BUF_PORT_REVERSAL |
 -
  DDI_A_4_LANES);
 +
  ddi_e_present ? 0 :
 DDI_A_4_LANES);
[Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes
when
DDI-E doesn't exist, I think your patch will do nothing.
  
   Actually DDI_A_4_LANES is being already set
   unconditionally, so
   Sonika's patch has no effect.
  [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under
  many
  conditions.
  +   if (IS_SKYLAKE(dev)  port == PORT_A
  +!(val  DDI_BUF_CTL_ENABLE)
  +!dev_priv-vbt.ddi_e_used)
  +   I915_WRITE(DDI_BUF_CTL(port), val |
  DDI_A_4_LANES)
  
   saved_port_bits goes to intel_dp-DP that goes to
   DDI_BUF_CTL and
   also it is used to calculate the number of lanes.
  
   With this patch we stop setting DDI_A_4_LANES when ddi_e is
   present
   so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E
  [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES
  when ddi_e
  is present.
  But this patch won't set DDI_A_4_LANES under following
  conditions
  which is purpose for Sonika patch 1. Bios fail to driver eDP
  and
  doesn't enable DDI_A buffer

 If DDI_A isn't enabled we don't need to set DDI_A_4_LANES
[Zhang, Xiong Y] From commit message on Sonika patch, she want to
set DDI_A_4_LANES on such case. Maybe she met such fail case on
one high
resolution eDP screen. Let's Sonikia explain it.

  2. Bios clear DDI_A_4_LANES
  3. DDI_E isn't present

 I don't agree... This is already covered on current code.
 DDI_A_4_LANES is
 already being set when enabling DDI_A.

   As Zhang mentioned and as my commit message explains, my patch is
   needed
   when bios failed to drive edp (In my case it was an intermediate
   frequency supported panel which was set to 3.24 GHz and bios didn't
   have
   support for intermediate frequencies), it will not enable DDIA in
   which
   case, it will not set DDI_BUF_CTL and DDI Lane capability will
   remain 0
   (which is DDIA with 2 lanes

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Adding Panel Filter function for DP

[Zhang, Xiong Y]

 On Fri, Aug 14, 2015 at 07:28:44PM +0300, Ville Syrjälä wrote:
  On Fri, Aug 14, 2015 at 05:12:57AM +, Zhang, Xiong Y wrote:
On Mon, Aug 10, 2015 at 03:26:09PM +0800, Xiong Zhang wrote:
 Only internal eDP, LVDS, DVI screen could set scalling mode, some
 customers need to set scalling mode for external DP, HDMI, VGA screen.
 Let's fulfill this.

 bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90989

 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c | 63
 -
  1 file changed, 44 insertions(+), 19 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c
 b/drivers/gpu/drm/i915/intel_dp.c index f1b9f93..2da334b 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -207,7 +207,13 @@ intel_dp_mode_valid(struct drm_connector
*connector,
   int target_clock = mode-clock;
   int max_rate, mode_rate, max_lanes, max_link_clock;

 - if (is_edp(intel_dp)  fixed_mode) {
 + if (mode-clock  1)
 + return MODE_CLOCK_LOW;
 +
 + if (mode-flags  DRM_MODE_FLAG_DBLCLK)
 + return MODE_H_ILLEGAL;
 +
 + if (!intel_panel_scale_none(intel_connector-panel)) {
   if (mode-hdisplay  fixed_mode-hdisplay)
   return MODE_PANEL;

 @@ -226,12 +232,6 @@ intel_dp_mode_valid(struct drm_connector
*connector,
   if (mode_rate  max_rate)
   return MODE_CLOCK_HIGH;

 - if (mode-clock  1)
 - return MODE_CLOCK_LOW;
 -
 - if (mode-flags  DRM_MODE_FLAG_DBLCLK)
 - return MODE_H_ILLEGAL;
 -
   return MODE_OK;
  }

 @@ -1378,7 +1378,7 @@ intel_dp_compute_config(struct
 intel_encoder
*encoder,
   pipe_config-has_drrs = false;
   pipe_config-has_audio = intel_dp-has_audio  port != PORT_A;

 - if (is_edp(intel_dp)  intel_connector-panel.fixed_mode) {
 + if (!intel_panel_scale_none(intel_connector-panel)) {
   
 intel_fixed_panel_mode(intel_connector-panel.fixed_mode,
  adjusted_mode);

 @@ -4592,6 +4592,23 @@ static int intel_dp_get_modes(struct
drm_connector *connector)
   edid = intel_connector-detect_edid;
   if (edid) {
   int ret = intel_connector_update_modes(connector, edid);
 +
 + if (ret  intel_connector-panel.fixed_mode == NULL) {
 + /* init fixed mode as preferred mode for DP */
 + struct drm_display_mode *fixed_mode = NULL;
 + struct drm_display_mode *scan;
 +
 + list_for_each_entry(scan, 
 connector-probed_modes,
 head) {
 + if (scan-type  
 DRM_MODE_TYPE_PREFERRED)
 + fixed_mode =
 drm_mode_duplicate(connector-dev,
 + 
 scan);
 + }
 +
 + if (fixed_mode)
 + 
 intel_panel_init(intel_connector-panel,
 +  fixed_mode, NULL);
 + }
   
How are we supposed to get rid of a stale fixed_mode when some other
display gets plugged in?
   [Zhang, Xiong Y] Thanks so much for your good question. Yes, we should
 clear the
   stale fitting_mode and fixed_mode when display is disconnect in
   intel_dp_hpd_pulse() function.
   
Also what would happen if the preferred mode can't be supported due to
 some
source limitation?
   [Zhang, Xiong Y] In this case, which mode should be selected as
 fixed_mode ?
 
  At the very least we should make sure it's a mode we can use.
 
   As you said maybe kernel isn't the right place to do such decision.
 
  There are a lot of options how we could pick the mode. Eg. might want to
  pick the next largest mode, and if there is none try to pick the largest
  smaller mode (since pfit can't downscale by much). Also should we try to
  pick an intelaced mode if the user requested one etc. Lots of open
  questions how this policy should be handled. Would be easier to punt it
  all to userspace, which would also avoid the kernel policy doing the
  wrong thing when userspace knows what it wants.
 
   
In general I'm not entirely happy with having this kind of policy in the
 kernel.
I'd much prefer if we could get crtc size and border properties done so
 that
userspace could set up the scaling any which way it chooses.
   [Zhang, Xiong Y] Could you give more detail about your preference ?
 
  The idea would be to expose some sort of crtc size properties that would
  provide pipe_src_{w,h

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Adding DDI_E power well domain

[Zhang, Xiong Y]

Sorry, but I don't get how this enables power_well_2 as well. I just see it 
enabling ddi A/E as the other.

Maybe Paulo or Imre are the best one to review this.

On Thu, Aug 13, 2015 at 2:54 AM Xiong Zhang 
xiong.y.zh...@intel.commailto:xiong.y.zh...@intel.com wrote:
From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.

In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.

Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.

This patch also fix the DDI-E hotplug function.

Signed-off-by: Xiong Zhang 
xiong.y.zh...@intel.commailto:xiong.y.zh...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/intel_display.c| 3 ++-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86734be..5523b6e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2564,6 +2564,8 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
return PORT_DDI_D_2_LANES;
case POWER_DOMAIN_PORT_DDI_D_4_LANES:
return PORT_DDI_D_4_LANES;
+   case POWER_DOMAIN_PORT_DDI_E_2_LANES:
+   return PORT_DDI_E_2_LANES;
case POWER_DOMAIN_PORT_DSI:
return PORT_DSI;
case POWER_DOMAIN_PORT_CRT:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b157865..ee71f90 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -182,6 +182,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_C_4_LANES,
POWER_DOMAIN_PORT_DDI_D_2_LANES,
POWER_DOMAIN_PORT_DDI_D_4_LANES,
+   POWER_DOMAIN_PORT_DDI_E_2_LANES,
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_PORT_CRT,
POWER_DOMAIN_PORT_OTHER,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 801187c..ccd3f0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5150,7 +5150,6 @@ static enum intel_display_power_domain 
port_to_power_domain(enum port port)
 {
switch (port) {
case PORT_A:
-   case PORT_E:
return POWER_DOMAIN_PORT_DDI_A_4_LANES;
case PORT_B:
return POWER_DOMAIN_PORT_DDI_B_4_LANES;
@@ -5158,6 +5157,8 @@ static enum intel_display_power_domain 
port_to_power_domain(enum port port)
return POWER_DOMAIN_PORT_DDI_C_4_LANES;
case PORT_D:
return POWER_DOMAIN_PORT_DDI_D_4_LANES;
+   case PORT_E:
+   return POWER_DOMAIN_PORT_DDI_E_2_LANES;
default:
WARN_ON_ONCE(1);
return POWER_DOMAIN_PORT_OTHER;
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 821644d..af7fdb3 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -297,6 +297,7 @@ static void hsw_set_power_well(struct drm_i915_private 
*dev_priv,
BIT(POWER_DOMAIN_PORT_DDI_C_4_LANES) |  \
BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) |  \
BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |  \
+   BIT(POWER_DOMAIN_PORT_DDI_E_2_LANES)
[Zhang, Xiong Y] this line put DDI_E_2_LANES into 
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS, but the git format-patch doesn’t show
#define SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS. So it isn’t easy to review this.
|  \
BIT(POWER_DOMAIN_AUX_B) |   \
BIT(POWER_DOMAIN_AUX_C) |   \
BIT(POWER_DOMAIN_AUX_D) |   \
@@ -316,6 +317,7 @@ static void hsw_set_power_well(struct drm_i915_private 
*dev_priv,
 #define SKL_DISPLAY_DDI_A_E_POWER_DOMAINS (\
BIT(POWER_DOMAIN_PORT_DDI_A_2_LANES) |  \
BIT(POWER_DOMAIN_PORT_DDI_A_4_LANES) |  \
+   BIT(POWER_DOMAIN_PORT_DDI_E_2_LANES) |  \
BIT(POWER_DOMAIN_INIT))
 #define SKL_DISPLAY_DDI_B_POWER_DOMAINS (  \
BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) |  \
--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.orgmailto:Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E

[Zhang, Xiong Y]

 On Thu, Aug 13, 2015 at 02:57:38AM +, Zhang, Xiong Y wrote:
   On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
DDI-E doesn't have the correspondent GMBUS pin.
   
We rely on VBT to tell us which one it being used instead.
   
The DVI/HDMI on shared port couldn't exist.
   
This patch isn't tested without hardware wchich has HDMI on DDI-E.
   
v2: fix trailing whitespace
v3: WARN() take place of BUG()
  
   I asked for MISSING_CASE, not WARN.
   -Daniel
  [Zhang, Xiong Y] Because DDI-E on SKL doesn't have correspondent GMBUS
 pin, it should share such pin with DDI-B/C/D. We don't know the default
 GMBUS pin for DDI-E if VBT doesn't tell us.
  If VBT don't tell us or give us an invalid GMBUS pin, driver will fail in 
  getting
 HDMI info. In such case, we really need a warn which tell us why driver
 couldn't read EDID info for HDMI on DDI-E.
 
 Have you bothered to look at the MISSING_CASE macro?! It does boil down to
 a WARN, but I prefer it much over a WARN_ON since it's nicely standardized.
 
[Zhang, Xiong Y] Please forgive my innocence! I misunderstand MISSING_CASE at 
the beginning.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Adding break for one case

[Zhang, Xiong Y]

 On Thu, Aug 13, 2015 at 01:37:49PM +0300, Timo Aaltonen wrote:
  On 13.08.2015 13:36, Timo Aaltonen wrote:
   On 13.08.2015 13:00, Xiong Zhang wrote:
   Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
   ---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
  
   diff --git a/drivers/gpu/drm/i915/intel_display.c
   b/drivers/gpu/drm/i915/intel_display.c
   index 65cc5b1..801187c 100644
   --- a/drivers/gpu/drm/i915/intel_display.c
   +++ b/drivers/gpu/drm/i915/intel_display.c
   @@ -1100,6 +1100,7 @@ bool ibx_digital_port_connected(struct
 drm_i915_private *dev_priv,
break;
case PORT_E:
bit = SDE_PORTE_HOTPLUG_SPT;
   +break;
default:
return true;
}
  
  
   shouldn't this belong to [5/6]?
 
  Nevermind, I see now that it got merged already.
 
 I dropped that patch again so that we can rectify this properly. Jani's 
 complaint
 about the sub-par commit message still holds though, like why was this not
 caught in testing?
[Zhang, Xiong Y] Yes, it's better to drop it. I will explain it the commit 
message and resent the patch.
 -Daniel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Adding intel_panel_scale_none() helper function

[Zhang, Xiong Y]

 On Mon, Aug 10, 2015 at 06:23:19PM +, Rodrigo Vivi wrote:
  I believe this function could be added along with the next patch that
  is the first to use it...
  Or it would be good to have a good commit message explaining why this
  function is needed and what is be used for...
 
 Yes, please don't split up patches so much that you end up adding dead code
 or dead structures - always try to have at least a minimal user for something.
 
 If you want to split things up really tiny then go the other way round:
 First add the callers, then add the implementation. That way reviewers can
 understand the big scope first and then dig into details. But this one here 
 really
 is small enough to just be squashed in.
 -Daniel
 
[Zhang, Xiong Y] Thanks for teaching me how to handle this. I'll follow it in 
the next version.
thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Adding Panel Filter function for DP

[Zhang, Xiong Y]

 On Mon, Aug 10, 2015 at 03:26:09PM +0800, Xiong Zhang wrote:
  Only internal eDP, LVDS, DVI screen could set scalling mode, some
  customers need to set scalling mode for external DP, HDMI, VGA screen.
  Let's fulfill this.
 
  bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90989
 
  Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
  ---
   drivers/gpu/drm/i915/intel_dp.c | 63
  -
   1 file changed, 44 insertions(+), 19 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_dp.c
  b/drivers/gpu/drm/i915/intel_dp.c index f1b9f93..2da334b 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -207,7 +207,13 @@ intel_dp_mode_valid(struct drm_connector
 *connector,
  int target_clock = mode-clock;
  int max_rate, mode_rate, max_lanes, max_link_clock;
 
  -   if (is_edp(intel_dp)  fixed_mode) {
  +   if (mode-clock  1)
  +   return MODE_CLOCK_LOW;
  +
  +   if (mode-flags  DRM_MODE_FLAG_DBLCLK)
  +   return MODE_H_ILLEGAL;
  +
  +   if (!intel_panel_scale_none(intel_connector-panel)) {
  if (mode-hdisplay  fixed_mode-hdisplay)
  return MODE_PANEL;
 
  @@ -226,12 +232,6 @@ intel_dp_mode_valid(struct drm_connector
 *connector,
  if (mode_rate  max_rate)
  return MODE_CLOCK_HIGH;
 
  -   if (mode-clock  1)
  -   return MODE_CLOCK_LOW;
  -
  -   if (mode-flags  DRM_MODE_FLAG_DBLCLK)
  -   return MODE_H_ILLEGAL;
  -
  return MODE_OK;
   }
 
  @@ -1378,7 +1378,7 @@ intel_dp_compute_config(struct intel_encoder
 *encoder,
  pipe_config-has_drrs = false;
  pipe_config-has_audio = intel_dp-has_audio  port != PORT_A;
 
  -   if (is_edp(intel_dp)  intel_connector-panel.fixed_mode) {
  +   if (!intel_panel_scale_none(intel_connector-panel)) {
  intel_fixed_panel_mode(intel_connector-panel.fixed_mode,
 adjusted_mode);
 
  @@ -4592,6 +4592,23 @@ static int intel_dp_get_modes(struct
 drm_connector *connector)
  edid = intel_connector-detect_edid;
  if (edid) {
  int ret = intel_connector_update_modes(connector, edid);
  +
  +   if (ret  intel_connector-panel.fixed_mode == NULL) {
  +   /* init fixed mode as preferred mode for DP */
  +   struct drm_display_mode *fixed_mode = NULL;
  +   struct drm_display_mode *scan;
  +
  +   list_for_each_entry(scan, connector-probed_modes, 
  head) {
  +   if (scan-type  DRM_MODE_TYPE_PREFERRED)
  +   fixed_mode = 
  drm_mode_duplicate(connector-dev,
  +   scan);
  +   }
  +
  +   if (fixed_mode)
  +   intel_panel_init(intel_connector-panel,
  +fixed_mode, NULL);
  +   }
 
 How are we supposed to get rid of a stale fixed_mode when some other
 display gets plugged in?
[Zhang, Xiong Y] Thanks so much for your good question. Yes, we should clear the
stale fitting_mode and fixed_mode when display is disconnect in 
intel_dp_hpd_pulse() function.
 
 Also what would happen if the preferred mode can't be supported due to some
 source limitation?
[Zhang, Xiong Y] In this case, which mode should be selected as fixed_mode ?
As you said maybe kernel isn't the right place to do such decision.
 
 In general I'm not entirely happy with having this kind of policy in the 
 kernel.
 I'd much prefer if we could get crtc size and border properties done so that
 userspace could set up the scaling any which way it chooses.
[Zhang, Xiong Y] Could you give more detail about your preference ?

thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E

[Zhang, Xiong Y]

 On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
  DDI-E doesn't have the correspondent GMBUS pin.
 
  We rely on VBT to tell us which one it being used instead.
 
  The DVI/HDMI on shared port couldn't exist.
 
  This patch isn't tested without hardware wchich has HDMI on DDI-E.
 
  v2: fix trailing whitespace
  v3: WARN() take place of BUG()
 
 I asked for MISSING_CASE, not WARN.
 -Daniel
[Zhang, Xiong Y] Because DDI-E on SKL doesn't have correspondent GMBUS pin, it 
should share such pin with DDI-B/C/D. We don't know the default GMBUS pin for 
DDI-E if VBT doesn't tell us. 
If VBT don't tell us or give us an invalid GMBUS pin, driver will fail in 
getting HDMI info. In such case, we really need a warn which tell us why driver 
couldn't read EDID info for HDMI on DDI-E.

thanks
 
 
  Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
  Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
  ---
   drivers/gpu/drm/i915/i915_drv.h   |  5 +
   drivers/gpu/drm/i915/intel_bios.c | 25 +
  drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
   3 files changed, 44 insertions(+), 4 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_drv.h
  b/drivers/gpu/drm/i915/i915_drv.h index 6d93334..5d8e7fe 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -1414,6 +1414,10 @@ enum modeset_restore {  #define DP_AUX_C
 0x20
  #define DP_AUX_D 0x30
 
  +#define DDC_PIN_B  0x05
  +#define DDC_PIN_C  0x04
  +#define DDC_PIN_D  0x06
  +
   struct ddi_vbt_port_info {
  /*
   * This is an index in the HDMI/DVI DDI buffer translation table.
  @@ -1428,6 +1432,7 @@ struct ddi_vbt_port_info {
  uint8_t supports_dp:1;
 
  uint8_t alternate_aux_channel;
  +   uint8_t alternate_ddc_pin;
   };
 
   enum psr_lines_to_wait {
  diff --git a/drivers/gpu/drm/i915/intel_bios.c
  b/drivers/gpu/drm/i915/intel_bios.c
  index 16cdf17..8140531 100644
  --- a/drivers/gpu/drm/i915/intel_bios.c
  +++ b/drivers/gpu/drm/i915/intel_bios.c
  @@ -894,7 +894,7 @@ static void parse_ddi_port(struct drm_i915_private
 *dev_priv, enum port port,
  uint8_t hdmi_level_shift;
  int i, j;
  bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
  -   uint8_t aux_channel;
  +   uint8_t aux_channel, ddc_pin;
  /* Each DDI port can have more than one value on the DVO Port field,
   * so look for all the possible values for each port and abort if more
   * than one is found. */
  @@ -928,6 +928,7 @@ static void parse_ddi_port(struct drm_i915_private
 *dev_priv, enum port port,
  return;
 
  aux_channel = child-raw[25];
  +   ddc_pin = child-common.ddc_pin;
 
  is_dvi = child-common.device_type 
 DEVICE_TYPE_TMDS_DVI_SIGNALING;
  is_dp = child-common.device_type 
 DEVICE_TYPE_DISPLAYPORT_OUTPUT;
  @@ -959,11 +960,27 @@ static void parse_ddi_port(struct
 drm_i915_private *dev_priv, enum port port,
  DRM_DEBUG_KMS(Port %c is internal DP\n, port_name(port));
 
  if (is_dvi) {
  -   if (child-common.ddc_pin == 0x05  port != PORT_B)
  +   if (port == PORT_E) {
  +   info-alternate_ddc_pin = ddc_pin;
  +   /* if DDIE share ddc pin with other port, then
  +* dvi/hdmi couldn't exist on the shared port.
  +* Otherwise they share the same ddc bin and system
  +* couldn't communicate with them seperately. */
  +   if (ddc_pin == DDC_PIN_B) {
  +   
  dev_priv-vbt.ddi_port_info[PORT_B].supports_dvi = 0;
  +   
  dev_priv-vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
  +   } else if (ddc_pin == DDC_PIN_C) {
  +   
  dev_priv-vbt.ddi_port_info[PORT_C].supports_dvi = 0;
  +   
  dev_priv-vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
  +   } else if (ddc_pin == DDC_PIN_D) {
  +   
  dev_priv-vbt.ddi_port_info[PORT_D].supports_dvi = 0;
  +   
  dev_priv-vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
  +   }
  +   } else if (ddc_pin == DDC_PIN_B  port != PORT_B)
  DRM_DEBUG_KMS(Unexpected DDC pin for port B\n);
  -   if (child-common.ddc_pin == 0x04  port != PORT_C)
  +   else if (ddc_pin == DDC_PIN_C  port != PORT_C)
  DRM_DEBUG_KMS(Unexpected DDC pin for port C\n);
  -   if (child-common.ddc_pin == 0x06  port != PORT_D)
  +   else if (ddc_pin == DDC_PIN_D  port != PORT_D)
  DRM_DEBUG_KMS(Unexpected DDC pin for port D\n);
  }
 
  diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
  b/drivers/gpu/drm/i915/intel_hdmi.c
  index 70bad5b..a4129f2 100644
  --- a/drivers/gpu/drm/i915/intel_hdmi.c
  +++ b/drivers/gpu/drm/i915/intel_hdmi.c
  @@ -1991,6 +1991,24 @@ void intel_hdmi_init_connector(struct
 intel_digital_port *intel_dig_port

Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.

[Zhang, Xiong Y]

 On Wed, 2015-08-12 at 02:20 +, Zhang, Xiong Y wrote:
   On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
 -Original Message-
 From: Vivi, Rodrigo
 Sent: Saturday, August 8, 2015 8:34 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Vivi, Rodrigo; Zhang, Xiong Y
 Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4
 lanes.

 DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we
 need to configure lane count propperly for both.

 This was based on Sonika's
 [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt

 Credits-to: Sonika Jindal sonika.jin...@intel.com
 Cc: Xiong Zhang xiong.y.zh...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 ---
  drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
 drivers/gpu/drm/i915/intel_dp.c  |  8 +---
  2 files changed, 15 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_ddi.c
 b/drivers/gpu/drm/i915/intel_ddi.c
 index 110d546..557cecf 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device
 *dev, enum port port)
   struct intel_digital_port *intel_dig_port;
   struct intel_encoder *intel_encoder;
   struct drm_encoder *encoder;
 - bool init_hdmi, init_dp;
 + bool init_hdmi, init_dp, ddi_e_present;
 +
 + /*
 +  * On SKL we don't have a way to detect DDI-E so we
 rely
 on VBT.
 +  */
 + ddie_present = IS_SKYLAKE(dev) 
 + (dev_priv
 -vbt.ddi_port_info[PORT_E].supports_dp
  
 +  dev_priv
 -vbt.ddi_port_info[PORT_E].supports_dvi
  
 +  dev_priv
 -vbt.ddi_port_info[PORT_E].supports_hdmi);
[Zhang, Xiong Y]  ddie_present should be ddi_e_present

   init_hdmi = (dev_priv
 -vbt.ddi_port_info[port].supports_dvi ||
dev_priv
 -vbt.ddi_port_info[port].supports_hdmi);
 @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device
 *dev, enum port port)
   intel_dig_port-port = port;
   intel_dig_port-saved_port_bits =
 I915_READ(DDI_BUF_CTL(port)) 

  (DDI_BUF_PORT_REVERSAL |
 -DDI_A_4_LANES);
 +ddi_e_present ? 0 :
 DDI_A_4_LANES);
[Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when
DDI-E doesn't exist, I think your patch will do nothing.
  
   Actually DDI_A_4_LANES is being already set unconditionally, so
   Sonika's patch has no effect.
  [Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many
  conditions.
  +   if (IS_SKYLAKE(dev)  port == PORT_A
  +!(val  DDI_BUF_CTL_ENABLE)
  +!dev_priv-vbt.ddi_e_used)
  +   I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES)
  
   saved_port_bits goes to intel_dp-DP that goes to DDI_BUF_CTL and
   also it is used to calculate the number of lanes.
  
   With this patch we stop setting DDI_A_4_LANES when ddi_e is present
   so DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E
  [Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e
  is present.
  But this patch won't set DDI_A_4_LANES under following conditions
  which is purpose for Sonika patch 1. Bios fail to driver eDP and
  doesn't enable DDI_A buffer
 
 If DDI_A isn't enabled we don't need to set DDI_A_4_LANES
[Zhang, Xiong Y] From commit message on Sonika patch, she want to 
set DDI_A_4_LANES on such case. Maybe she met such fail case on one high
resolution eDP screen. Let's Sonikia explain it.
 
  2. Bios clear DDI_A_4_LANES
  3. DDI_E isn't present
 
 I don't agree... This is already covered on current code. DDI_A_4_LANES is
 already being set when enabling DDI_A.
 
 
 
  thanks
  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E

[Zhang, Xiong Y]

 On Tue, 2015-08-11 at 11:47 +0200, Daniel Vetter wrote:
  On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
   From: Rodrigo Vivi rodrigo.v...@intel.com
  
   On Skylake we have eDP-to-VGA using DDI-E and another aux.
   So let's identify it properly.
 
  eDP means panel (the only difference in the code we have between eDP
  and DP is the power panel sequncing). VGA very much means no panel.
 
  Is this some impressive hack (dp-vga dongle using panel power as it's
  power source) or what's going on here? Or just confused commit
  message?
 
 That's a good question. I've heard from customer the embedded converter is
 eDP-to-VGA, not DP-to-VGA so I'm not sure what is behind and I have no
 machine here with me.
[Xiong, Zhang]: From vbt, it is a DP-to-VGA, not eDP-to-VGA
[  103.407648] [drm:parse_ddi_port] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0 
CRT:0
 
 Xiong, could you please check with customer if everything works without this
 patch?
[Xiong, Zhang]: Everything works well without this patch on customer's machine. 
But if a eDP indeed connect to DDI-E without this patch, 
intel_dp_is_edp(PORT_E) will return false, then eDP on DDI-E couldn't work.
 
 Thanks,
 Rodrigo.
 
  I'll punt on this for now.
  -Daniel
 
  
   Also let's remove duplicated definitions to avoid later confusion.
  
   Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
   ---
drivers/gpu/drm/i915/intel_bios.h | 5 -
drivers/gpu/drm/i915/intel_dp.c   | 9 +
2 files changed, 5 insertions(+), 9 deletions(-)
  
   diff --git a/drivers/gpu/drm/i915/intel_bios.h
   b/drivers/gpu/drm/i915/intel_bios.h
   index 02255d8..a2ef0df 100644
   --- a/drivers/gpu/drm/i915/intel_bios.h
   +++ b/drivers/gpu/drm/i915/intel_bios.h
   @@ -747,11 +747,6 @@ int intel_parse_bios(struct drm_device *dev);
#define  DVO_C   2
#define  DVO_D   3
  
   -/* define the PORT for DP output type */
   -#define  PORT_IDPB   7
   -#define  PORT_IDPC   8
   -#define  PORT_IDPD   9
   -
/* Possible values for the DVO Port field for versions = 155:
   */
#define DVO_PORT_HDMIA   0
#define DVO_PORT_HDMIB   1
   diff --git a/drivers/gpu/drm/i915/intel_dp.c
   b/drivers/gpu/drm/i915/intel_dp.c index 7cd47bc..0643a91 100644
   --- a/drivers/gpu/drm/i915/intel_dp.c
   +++ b/drivers/gpu/drm/i915/intel_dp.c
   @@ -4978,16 +4978,17 @@ intel_trans_dp_port_sel(struct drm_crtc
   *crtc)
 return -1;
}
  
   -/* check the VBT to see whether the eDP is on DP-D port */
   +/* check the VBT to see whether the eDP is on another port */
bool intel_dp_is_edp(struct drm_device *dev, enum port port)  {
 struct drm_i915_private *dev_priv = dev-dev_private;
 union child_device_config *p_child;
 int i;
 static const short port_mapping[] = {
   - [PORT_B] = PORT_IDPB,
   - [PORT_C] = PORT_IDPC,
   - [PORT_D] = PORT_IDPD,
   + [PORT_B] = DVO_PORT_DPB,
   + [PORT_C] = DVO_PORT_DPC,
   + [PORT_D] = DVO_PORT_DPD,
   + [PORT_E] = DVO_PORT_DPE,
 };
  
 if (port == PORT_A)
   --
   2.1.4
  
   ___
   Intel-gfx mailing list
   Intel-gfx@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Set alternate aux for DDI-E

[Zhang, Xiong Y]

Reviewed-by: Xiong Zhang xiong.y.zh...@intel.com

thanks

From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Rodrigo 
Vivi [rodrigo.v...@intel.com]
Sent: Saturday, August 08, 2015 8:01 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH] drm/i915: Set alternate aux for DDI-E

There is no correspondent Aux channel for DDI-E.

So we need to rely on VBT to let us know witch one
is being used instead.

v2: Removing some trailing spaces and giving proper
credit to Xiong that added a nice way to avoid port
conflicts by setting supports_dp = 0 when using
equivalent aux for DDI-E.

Credits-to: Xiong Zhang xiong.y.zh...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h   |  7 +++
 drivers/gpu/drm/i915/intel_bios.c | 23 +++
 drivers/gpu/drm/i915/intel_ddi.c  |  5 ++---
 drivers/gpu/drm/i915/intel_dp.c   | 29 -
 4 files changed, 56 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4932d29..3ffd962 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1409,6 +1409,11 @@ enum modeset_restore {
MODESET_SUSPENDED,
 };

+#define DP_AUX_A 0x40
+#define DP_AUX_B 0x10
+#define DP_AUX_C 0x20
+#define DP_AUX_D 0x30
+
 struct ddi_vbt_port_info {
/*
 * This is an index in the HDMI/DVI DDI buffer translation table.
@@ -1421,6 +1426,8 @@ struct ddi_vbt_port_info {
uint8_t supports_dvi:1;
uint8_t supports_hdmi:1;
uint8_t supports_dp:1;
+
+   uint8_t alternate_aux_channel;
 };

 enum psr_lines_to_wait {
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 31b1079..990acc2 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -968,13 +968,28 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
}

if (is_dp) {
-   if (aux_channel == 0x40  port != PORT_A)
+   if (port == PORT_E) {
+   info-alternate_aux_channel = aux_channel;
+   /* if DDIE share aux channel with other port, then
+* DP couldn't exist on the shared port. Otherwise
+* they share the same aux channel and system
+* couldn't communicate with them seperately. */
+   if (aux_channel == DP_AUX_A)
+   dev_priv-vbt.ddi_port_info[PORT_A].supports_dp 
= 0;
+   else if (aux_channel == DP_AUX_B)
+   dev_priv-vbt.ddi_port_info[PORT_B].supports_dp 
= 0;
+   else if (aux_channel == DP_AUX_C)
+   dev_priv-vbt.ddi_port_info[PORT_C].supports_dp 
= 0;
+   else if (aux_channel == DP_AUX_D)
+   dev_priv-vbt.ddi_port_info[PORT_D].supports_dp 
= 0;
+   }
+   else if (aux_channel == DP_AUX_A  port != PORT_A)
DRM_DEBUG_KMS(Unexpected AUX channel for port A\n);
-   if (aux_channel == 0x10  port != PORT_B)
+   else if (aux_channel == DP_AUX_B  port != PORT_B)
DRM_DEBUG_KMS(Unexpected AUX channel for port B\n);
-   if (aux_channel == 0x20  port != PORT_C)
+   else if (aux_channel == DP_AUX_C  port != PORT_C)
DRM_DEBUG_KMS(Unexpected AUX channel for port C\n);
-   if (aux_channel == 0x30  port != PORT_D)
+   else if (aux_channel == DP_AUX_D  port != PORT_D)
DRM_DEBUG_KMS(Unexpected AUX channel for port D\n);
}

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..110d546 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3184,10 +3184,9 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
 dev_priv-vbt.ddi_port_info[port].supports_hdmi);
init_dp = dev_priv-vbt.ddi_port_info[port].supports_dp;
if (!init_dp  !init_hdmi) {
-   DRM_DEBUG_KMS(VBT says port %c is not DVI/HDMI/DP compatible, 
assuming it is\n,
+   DRM_DEBUG_KMS(VBT says port %c is not DVI/HDMI/DP compatible, 
respect it\n,
  port_name(port));
-   init_hdmi = true;
-   init_dp = true;
+   return;
}

intel_dig_port = kzalloc(sizeof(*intel_dig_port), GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 15f0d72..601a12a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1033,11 +1033,34 @@ static void
 intel_dp_aux_init(struct intel_dp *intel_dp, struct 

Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.

[Zhang, Xiong Y]

 -Original Message-
 From: Vivi, Rodrigo
 Sent: Saturday, August 8, 2015 8:34 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Vivi, Rodrigo; Zhang, Xiong Y
 Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
 
 DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we need to
 configure lane count propperly for both.
 
 This was based on Sonika's
 [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt
 
 Credits-to: Sonika Jindal sonika.jin...@intel.com
 Cc: Xiong Zhang xiong.y.zh...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 ---
  drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
 drivers/gpu/drm/i915/intel_dp.c  |  8 +---
  2 files changed, 15 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_ddi.c
 b/drivers/gpu/drm/i915/intel_ddi.c
 index 110d546..557cecf 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device *dev, enum
 port port)
   struct intel_digital_port *intel_dig_port;
   struct intel_encoder *intel_encoder;
   struct drm_encoder *encoder;
 - bool init_hdmi, init_dp;
 + bool init_hdmi, init_dp, ddi_e_present;
 +
 + /*
 +  * On SKL we don't have a way to detect DDI-E so we rely on VBT.
 +  */
 + ddie_present = IS_SKYLAKE(dev) 
 + (dev_priv-vbt.ddi_port_info[PORT_E].supports_dp ||
 +  dev_priv-vbt.ddi_port_info[PORT_E].supports_dvi ||
 +  dev_priv-vbt.ddi_port_info[PORT_E].supports_hdmi);
[Zhang, Xiong Y]  ddie_present should be ddi_e_present
 
   init_hdmi = (dev_priv-vbt.ddi_port_info[port].supports_dvi ||
dev_priv-vbt.ddi_port_info[port].supports_hdmi);
 @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device *dev, enum
 port port)
   intel_dig_port-port = port;
   intel_dig_port-saved_port_bits = I915_READ(DDI_BUF_CTL(port)) 
 (DDI_BUF_PORT_REVERSAL |
 -DDI_A_4_LANES);
 +ddi_e_present ? 0 : DDI_A_4_LANES);
[Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when DDI-E doesn't 
exist,
I think your patch will do nothing.
 
   intel_encoder-type = INTEL_OUTPUT_UNKNOWN;
   intel_encoder-crtc_mask = (1  0) | (1  1) | (1  2); diff --git
 a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index
 3ff2080..7ada79e 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -159,9 +159,11 @@ static u8 intel_dp_max_lane_count(struct intel_dp
 *intel_dp)
   u8 source_max, sink_max;
 
   source_max = 4;
 - if (HAS_DDI(dev)  intel_dig_port-port == PORT_A 
 - (intel_dig_port-saved_port_bits  DDI_A_4_LANES) == 0)
 - source_max = 2;
 + if (HAS_DDI(dev)  (intel_dig_port-port == PORT_E ||
 +  (intel_dig_port-port == PORT_A 
 +   (intel_dig_port-saved_port_bits 
 +DDI_A_4_LANES) == 0))
 + source_max = 2;
[Zhang, Xiong Y] it miss ')' at the end line. 
 
   sink_max = drm_dp_max_lane_count(intel_dp-dpcd);
 
 --
 2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Set power domain for DDI-E

[Zhang, Xiong Y]

DDI-4 should be DDI-A in  commit message.
Reviewed-by: Xiong Zhang xiong.y.zh...@intel.com

thanks

From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Xiong 
Zhang [xiong.y.zh...@intel.com]
Sent: Thursday, August 06, 2015 3:51 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 2/6] drm/i915: Set power domain for DDI-E

From: Rodrigo Vivi rodrigo.v...@intel.com

DDI-E and DDI-4 share 4 DDI-A lanes.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index aaa34b8..ea10fa8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5134,6 +5134,7 @@ static enum intel_display_power_domain 
port_to_power_domain(enum port port)
 {
switch (port) {
case PORT_A:
+   case PORT_E:
return POWER_DOMAIN_PORT_DDI_A_4_LANES;
case PORT_B:
return POWER_DOMAIN_PORT_DDI_B_4_LANES;
--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E

[Zhang, Xiong Y]

Reviewed-by: Xiong Zhang xiong.y.zh...@intel.com

thanks

From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Xiong 
Zhang [xiong.y.zh...@intel.com]
Sent: Thursday, August 06, 2015 3:51 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E

From: Rodrigo Vivi rodrigo.v...@intel.com

On Skylake we have eDP-to-VGA using DDI-E and another aux.
So let's identify it properly.

Also let's remove duplicated definitions to avoid later
confusion.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_bios.h | 5 -
 drivers/gpu/drm/i915/intel_dp.c   | 9 +
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 02255d8..a2ef0df 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -747,11 +747,6 @@ int intel_parse_bios(struct drm_device *dev);
 #defineDVO_C   2
 #defineDVO_D   3

-/* define the PORT for DP output type */
-#definePORT_IDPB   7
-#definePORT_IDPC   8
-#definePORT_IDPD   9
-
 /* Possible values for the DVO Port field for versions = 155: */
 #define DVO_PORT_HDMIA 0
 #define DVO_PORT_HDMIB 1
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7cd47bc..0643a91 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4978,16 +4978,17 @@ intel_trans_dp_port_sel(struct drm_crtc *crtc)
return -1;
 }

-/* check the VBT to see whether the eDP is on DP-D port */
+/* check the VBT to see whether the eDP is on another port */
 bool intel_dp_is_edp(struct drm_device *dev, enum port port)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
union child_device_config *p_child;
int i;
static const short port_mapping[] = {
-   [PORT_B] = PORT_IDPB,
-   [PORT_C] = PORT_IDPC,
-   [PORT_D] = PORT_IDPD,
+   [PORT_B] = DVO_PORT_DPB,
+   [PORT_C] = DVO_PORT_DPC,
+   [PORT_D] = DVO_PORT_DPD,
+   [PORT_E] = DVO_PORT_DPE,
};

if (port == PORT_A)
--
2.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E

[Zhang, Xiong Y]

 -Original Message-
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
 Sent: Tuesday, August 11, 2015 5:47 PM
 To: Zhang, Xiong Y
 Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
 Subject: Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E
 
 On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
  From: Rodrigo Vivi rodrigo.v...@intel.com
 
  On Skylake we have eDP-to-VGA using DDI-E and another aux.
  So let's identify it properly.
 
 eDP means panel (the only difference in the code we have between eDP and
 DP is the power panel sequncing). VGA very much means no panel.
 
 Is this some impressive hack (dp-vga dongle using panel power as it's power
 source) or what's going on here? Or just confused commit message?
[Zhang, Xiong Y] Sorry, it's a dp-to-vga converter connected to DDI-E.
DDI-E has the same role as DDI-B/C/D, so eDP could connect to DDI-E also.
 
 I'll punt on this for now.
 -Daniel
 
 
  Also let's remove duplicated definitions to avoid later confusion.
 
  Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
  ---
   drivers/gpu/drm/i915/intel_bios.h | 5 -
   drivers/gpu/drm/i915/intel_dp.c   | 9 +
   2 files changed, 5 insertions(+), 9 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_bios.h
  b/drivers/gpu/drm/i915/intel_bios.h
  index 02255d8..a2ef0df 100644
  --- a/drivers/gpu/drm/i915/intel_bios.h
  +++ b/drivers/gpu/drm/i915/intel_bios.h
  @@ -747,11 +747,6 @@ int intel_parse_bios(struct drm_device *dev);
   #defineDVO_C   2
   #defineDVO_D   3
 
  -/* define the PORT for DP output type */
  -#definePORT_IDPB   7
  -#definePORT_IDPC   8
  -#definePORT_IDPD   9
  -
   /* Possible values for the DVO Port field for versions = 155: */
   #define DVO_PORT_HDMIA 0
   #define DVO_PORT_HDMIB 1
  diff --git a/drivers/gpu/drm/i915/intel_dp.c
  b/drivers/gpu/drm/i915/intel_dp.c index 7cd47bc..0643a91 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -4978,16 +4978,17 @@ intel_trans_dp_port_sel(struct drm_crtc *crtc)
  return -1;
   }
 
  -/* check the VBT to see whether the eDP is on DP-D port */
  +/* check the VBT to see whether the eDP is on another port */
   bool intel_dp_is_edp(struct drm_device *dev, enum port port)  {
  struct drm_i915_private *dev_priv = dev-dev_private;
  union child_device_config *p_child;
  int i;
  static const short port_mapping[] = {
  -   [PORT_B] = PORT_IDPB,
  -   [PORT_C] = PORT_IDPC,
  -   [PORT_D] = PORT_IDPD,
  +   [PORT_B] = DVO_PORT_DPB,
  +   [PORT_C] = DVO_PORT_DPC,
  +   [PORT_D] = DVO_PORT_DPD,
  +   [PORT_E] = DVO_PORT_DPE,
  };
 
  if (port == PORT_A)
  --
  2.1.4
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/6] drm/i915/skl: Enable DDI-E

[Zhang, Xiong Y]

Reviewed-by: Xiong Zhang xiong.y.zh...@intel.com

thanks
 -Original Message-
 From: Vivi, Rodrigo
 Sent: Saturday, August 8, 2015 8:35 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Vivi, Rodrigo; Zhang, Xiong Y
 Subject: [PATCH 8/6] drm/i915/skl: Enable DDI-E
 
 There are OEMs using DDI-E out there,
 so let's enable it.
 
 Unfortunately there is no detection bit for DDI-E So we need to rely on VBT 
 for
 that.
 
 I also need to give credits to Xiong since before seing his approach to check
 info-support_* I was creating an ugly
 vbt-ddie_sfuse_strap in order to propagate the ddi presence info
 
 v2: Rebased as last patch in the series. since all other patches in this 
 series are
 needed for anything working propperly on DDI-E.
 
 Credits-to: Zhang, Xiong Y xiong.y.zh...@intel.com
 Cc: Zhang, Xiong Y xiong.y.zh...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 ---
  drivers/gpu/drm/i915/intel_bios.c| 14 +++---
  drivers/gpu/drm/i915/intel_bios.h|  2 ++
  drivers/gpu/drm/i915/intel_display.c |  9 +
  3 files changed, 18 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_bios.c
 b/drivers/gpu/drm/i915/intel_bios.c
 index c417973..c5b5a59b 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -898,19 +898,19 @@ static void parse_ddi_port(struct drm_i915_private
 *dev_priv, enum port port,
   /* Each DDI port can have more than one value on the DVO Port field,
* so look for all the possible values for each port and abort if more
* than one is found. */
 - int dvo_ports[][2] = {
 - {DVO_PORT_HDMIA, DVO_PORT_DPA},
 - {DVO_PORT_HDMIB, DVO_PORT_DPB},
 - {DVO_PORT_HDMIC, DVO_PORT_DPC},
 - {DVO_PORT_HDMID, DVO_PORT_DPD},
 - {DVO_PORT_CRT, -1 /* Port E can only be DVO_PORT_CRT */ },
 + int dvo_ports[][3] = {
 + {DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
 + {DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
 + {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
 + {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
 + {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
   };
 
   /* Find the child device to use, abort if more than one found. */
   for (i = 0; i  dev_priv-vbt.child_dev_num; i++) {
   it = dev_priv-vbt.child_dev + i;
 
 - for (j = 0; j  2; j++) {
 + for (j = 0; j  3; j++) {
   if (dvo_ports[port][j] == -1)
   break;
 
 diff --git a/drivers/gpu/drm/i915/intel_bios.h
 b/drivers/gpu/drm/i915/intel_bios.h
 index 77bf1dd..a2ef0df 100644
 --- a/drivers/gpu/drm/i915/intel_bios.h
 +++ b/drivers/gpu/drm/i915/intel_bios.h
 @@ -759,6 +759,8 @@ int intel_parse_bios(struct drm_device *dev);
  #define DVO_PORT_DPC 8
  #define DVO_PORT_DPD 9
  #define DVO_PORT_DPA 10
 +#define DVO_PORT_DPE 11
 +#define DVO_PORT_HDMIE   12
  #define DVO_PORT_MIPIA   21
  #define DVO_PORT_MIPIB   22
  #define DVO_PORT_MIPIC   23
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index fcf1230..7bf6209 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -13961,6 +13961,15 @@ static void intel_setup_outputs(struct
 drm_device *dev)
   intel_ddi_init(dev, PORT_C);
   if (found  SFUSE_STRAP_DDID_DETECTED)
   intel_ddi_init(dev, PORT_D);
 + /*
 +  * On SKL we don't have a way to detect DDI-E so we rely on VBT.
 +  */
 + if (IS_SKYLAKE(dev) 
 + (dev_priv-vbt.ddi_port_info[PORT_E].supports_dp ||
 +  dev_priv-vbt.ddi_port_info[PORT_E].supports_dvi ||
 +  dev_priv-vbt.ddi_port_info[PORT_E].supports_hdmi))
 + intel_ddi_init(dev, PORT_E);
 +
   } else if (HAS_PCH_SPLIT(dev)) {
   int found;
   dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
 --
 2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.

[Zhang, Xiong Y]

 On Tue, 2015-08-11 at 07:05 +, Zhang, Xiong Y wrote:
   -Original Message-
   From: Vivi, Rodrigo
   Sent: Saturday, August 8, 2015 8:34 AM
   To: intel-gfx@lists.freedesktop.org
   Cc: Vivi, Rodrigo; Zhang, Xiong Y
   Subject: [PATCH 7/6] drm/i915/skl: DDI-E and DDI-A shares 4 lanes.
  
   DDI-A and DDI-E shares the 4 lanes. So when DDI-E is present we need
   to configure lane count propperly for both.
  
   This was based on Sonika's
   [PATCH] drm/i915/skl: Select DDIA lane capability based upon vbt
  
   Credits-to: Sonika Jindal sonika.jin...@intel.com
   Cc: Xiong Zhang xiong.y.zh...@intel.com
   Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
   ---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
   drivers/gpu/drm/i915/intel_dp.c  |  8 +---
2 files changed, 15 insertions(+), 5 deletions(-)
  
   diff --git a/drivers/gpu/drm/i915/intel_ddi.c
   b/drivers/gpu/drm/i915/intel_ddi.c
   index 110d546..557cecf 100644
   --- a/drivers/gpu/drm/i915/intel_ddi.c
   +++ b/drivers/gpu/drm/i915/intel_ddi.c
   @@ -3178,7 +3178,15 @@ void intel_ddi_init(struct drm_device *dev,
   enum port port)
 struct intel_digital_port *intel_dig_port;
 struct intel_encoder *intel_encoder;
 struct drm_encoder *encoder;
   - bool init_hdmi, init_dp;
   + bool init_hdmi, init_dp, ddi_e_present;
   +
   + /*
   +  * On SKL we don't have a way to detect DDI-E so we rely
   on VBT.
   +  */
   + ddie_present = IS_SKYLAKE(dev) 
   + (dev_priv-vbt.ddi_port_info[PORT_E].supports_dp
   ||
   +  dev_priv-vbt.ddi_port_info[PORT_E].supports_dvi
   ||
   +  dev_priv
   -vbt.ddi_port_info[PORT_E].supports_hdmi);
  [Zhang, Xiong Y]  ddie_present should be ddi_e_present
  
 init_hdmi = (dev_priv
   -vbt.ddi_port_info[port].supports_dvi ||
  dev_priv
   -vbt.ddi_port_info[port].supports_hdmi);
   @@ -3210,7 +3218,7 @@ void intel_ddi_init(struct drm_device *dev,
   enum port port)
 intel_dig_port-port = port;
 intel_dig_port-saved_port_bits =
   I915_READ(DDI_BUF_CTL(port)) 
   (DDI_BUF_PORT_REVERSAL |
   -DDI_A_4_LANES);
   +ddi_e_present ? 0 :
   DDI_A_4_LANES);
  [Zhang, Xiong Y] Sonika's patch will set DDI-A to 4 lanes when DDI-E
  doesn't exist, I think your patch will do nothing.
 
 Actually DDI_A_4_LANES is being already set unconditionally, so Sonika's
 patch has no effect.
[Zhang, Xiong Y] No. Sonika's patch set DDI_A_4_LANES under many conditions.
+   if (IS_SKYLAKE(dev)  port == PORT_A
+!(val  DDI_BUF_CTL_ENABLE)
+!dev_priv-vbt.ddi_e_used)
+   I915_WRITE(DDI_BUF_CTL(port), val | DDI_A_4_LANES)
 
 saved_port_bits goes to intel_dp-DP that goes to DDI_BUF_CTL and also it is
 used to calculate the number of lanes.
 
 With this patch we stop setting DDI_A_4_LANES when ddi_e is present so
 DDI-A keeps with 2 lanes and let other 2 lanes for DDI-E
[Zhang, Xiong Y] Yes, this patch will clear DDI_A_4_LANES when ddi_e is present.
But this patch won't set DDI_A_4_LANES under following conditions which is 
purpose for Sonika patch
1. Bios fail to driver eDP and doesn't enable DDI_A buffer
2. Bios clear DDI_A_4_LANES
3. DDI_E isn't present

thanks
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Update DDI buffer translation programming.

[Zhang, Xiong Y]

Hi, Vivi:
Do you think this patch could resolve the following two issues ?
https://bugs.freedesktop.org/show_bug.cgi?id=91050
https://bugs.freedesktop.org/show_bug.cgi?id=91269

thanks
 -Original Message-
 From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
 Rodrigo Vivi
 Sent: Thursday, August 6, 2015 5:59 AM
 To: intel-gfx@lists.freedesktop.org
 Cc: Runyan, Arthur J; Vivi, Rodrigo
 Subject: [Intel-gfx] [PATCH] drm/i915/skl: Update DDI buffer translation
 programming.
 
 SKL-Y can now use the same programming for all VccIO values after an
 adjustment to I_boost.
 SKL-U DP table adjustments.
 1.   Remove SKL Y 0.95V from SKL H and S columns in all tables.  The
 other SKL Y column removes the 0.85V VccIO so it now applies to all
 voltages.
 2.   DP table changes SKL U 400mV+0db dword 0 value from 2016h to
 201Bh.
 3.   DP table changes SKL U 600mv+0db dword 0 value from 2016h to
 201Bh.
 4.   DP table increases I_boost to level 3 for SKL Y 400mv+9.5db.
 
 Reference: Graphics Spec Change r97962
 Cc: Arthur Runyan arthur.j.run...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
 ---
  drivers/gpu/drm/i915/intel_ddi.c | 73 
 ++--
  1 file changed, 25 insertions(+), 48 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_ddi.c
 b/drivers/gpu/drm/i915/intel_ddi.c
 index 9a40bfb..9e5a21b 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -128,7 +128,7 @@ static const struct ddi_buf_trans
 bdw_ddi_translations_hdmi[] = {
   { 0x80FF, 0x001B0002, 0x0 },/* 9:   100010000   */
  };
 
 -/* Skylake H, S, and Skylake Y with 0.95V VccIO */
 +/* Skylake H and S */
  static const struct ddi_buf_trans skl_ddi_translations_dp[] = {
   { 0x2016, 0x00A0, 0x0 },
   { 0x5012, 0x009B, 0x0 },
 @@ -143,23 +143,23 @@ static const struct ddi_buf_trans
 skl_ddi_translations_dp[] = {
 
  /* Skylake U */
  static const struct ddi_buf_trans skl_u_ddi_translations_dp[] = {
 - { 0x2016, 0x00A2, 0x0 },
 + { 0x201B, 0x00A2, 0x0 },
   { 0x5012, 0x0088, 0x0 },
   { 0x7011, 0x0087, 0x0 },
 - { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost */
 - { 0x2016, 0x009D, 0x0 },
 + { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost level 0x1 */
 + { 0x201B, 0x009D, 0x0 },
   { 0x5012, 0x00C7, 0x0 },
   { 0x7011, 0x00C7, 0x0 },
   { 0x2016, 0x0088, 0x0 },
   { 0x5012, 0x00C7, 0x0 },
  };
 
 -/* Skylake Y with 0.85V VccIO */
 -static const struct ddi_buf_trans skl_y_085v_ddi_translations_dp[] = {
 +/* Skylake Y */
 +static const struct ddi_buf_trans skl_y_ddi_translations_dp[] = {
   { 0x0018, 0x00A2, 0x0 },
   { 0x5012, 0x0088, 0x0 },
   { 0x7011, 0x0087, 0x0 },
 - { 0x80009010, 0x00C7, 0x1 },/* Uses I_boost */
 + { 0x80009010, 0x00C7, 0x3 },/* Uses I_boost level 0x3 */
   { 0x0018, 0x009D, 0x0 },
   { 0x5012, 0x00C7, 0x0 },
   { 0x7011, 0x00C7, 0x0 },
 @@ -168,7 +168,7 @@ static const struct ddi_buf_trans
 skl_y_085v_ddi_translations_dp[] = {  };
 
  /*
 - * Skylake H and S, and Skylake Y with 0.95V VccIO
 + * Skylake H and S
   * eDP 1.4 low vswing translation parameters
   */
  static const struct ddi_buf_trans skl_ddi_translations_edp[] = { @@ -202,10
 +202,10 @@ static const struct ddi_buf_trans skl_u_ddi_translations_edp[] =
 {  };
 
  /*
 - * Skylake Y with 0.95V VccIO
 + * Skylake Y
   * eDP 1.4 low vswing translation parameters
   */
 -static const struct ddi_buf_trans skl_y_085v_ddi_translations_edp[] = {
 +static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
   { 0x0018, 0x00A8, 0x0 },
   { 0x4013, 0x00AB, 0x0 },
   { 0x7011, 0x00A4, 0x0 },
 @@ -218,7 +218,7 @@ static const struct ddi_buf_trans
 skl_y_085v_ddi_translations_edp[] = {
   { 0x0018, 0x008A, 0x0 },
  };
 
 -/* Skylake H, S and U, and Skylake Y with 0.95V VccIO */
 +/* Skylake U, H and S */
  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
   { 0x0018, 0x00AC, 0x0 },
   { 0x5012, 0x009D, 0x0 },
 @@ -233,8 +233,8 @@ static const struct ddi_buf_trans
 skl_ddi_translations_hdmi[] = {
   { 0x0018, 0x00C7, 0x0 },
  };
 
 -/* Skylake Y with 0.85V VccIO */
 -static const struct ddi_buf_trans skl_y_085v_ddi_translations_hdmi[] = {
 +/* Skylake Y */
 +static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
   { 0x0018, 0x00A1, 0x0 },
   { 0x5012, 0x00DF, 0x0 },
   { 0x7011, 0x0084, 0x0 },
 @@ -244,7 +244,7 @@ static const struct ddi_buf_trans
 skl_y_085v_ddi_translations_hdmi[] = {
   { 0x6013, 0x00C7, 0x0 },
   { 0x0018, 0x008A, 0x0 },
   { 0x3015, 0x00C7, 0x0 },

[Intel-gfx] eDP is black after screen rotate in kernel 3.19

[Zhang, Xiong Y]

On one Broadwell machine with Ubuntu 15.04, eDP is black after running xrandr 
-output eDP1 -rotate inverted.
Only 3.19 kernel has such issue, 4.0 kernel doesn't have such issue.

When this issue happens, I see the following call trace in dmesg:
[  108.777612] [drm:drm_mode_setcrtc] [CRTC:9]
[  108.777621] [drm:drm_mode_setcrtc] [CONNECTOR:20:eDP-1]
[  108.777627] [drm:intel_crtc_set_config] [CRTC:9] [FB:42] #connectors=1 (x y) 
(0 0)
[  108.777634] [drm:intel_set_config_compute_mode_changes] computed changes for 
[CRTC:9], mode_changed=0, fb_changed=0
[  108.777639] [drm:intel_modeset_stage_output_state] [CONNECTOR:20:eDP-1] to 
[CRTC:9]
[  108.777659] [drm:intel_modeset_affected_pipes] set mode pipe masks: modeset: 
1, prepare: 1, disable: 0
[  108.777667] [drm:connected_sink_compute_bpp] [CONNECTOR:20:eDP-1] checking 
for sink bpp constrains
[  108.777675] [drm:intel_dp_compute_config] DP link computation with max lane 
count 4 max bw 14 pixel clock 361310KHz
[  108.777679] [drm:intel_dp_compute_config] clamping bpp for eDP panel to 
BIOS-provided 18
[  108.777684] [drm:intel_dp_compute_config] DP link bw 14 lane count 4 clock 
54 bpp 18
[  108.777687] [drm:intel_dp_compute_config] DP link bw required 650358 
available 1728000
[  108.777694] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 18, 
dithering: 1
[  108.777698] [drm:intel_dump_pipe_config] [CRTC:9][modeset] config for pipe A
[  108.02] [drm:intel_dump_pipe_config] cpu_transcoder: D
[  108.05] [drm:intel_dump_pipe_config] pipe bpp: 18, dithering: 1
[  108.10] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, 
gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  108.15] [drm:intel_dump_pipe_config] dp: 1, gmch_m: 3157174, gmch_n: 
8388608, link_m: 701594, link_n: 1048576, tu: 64
[  108.19] [drm:intel_dump_pipe_config] dp: 1, gmch_m2: 0, gmch_n2: 0, 
link_m2: 0, link_n2: 0, tu2: 0
[  108.23] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0
[  108.26] [drm:intel_dump_pipe_config] requested mode:
[  108.33] [drm:drm_mode_debug_printmodeline] Modeline 0: 0 361310 3200 
3248 3280 3316 1800 1802 1807 1816 0x0 0xa
[  108.36] [drm:intel_dump_pipe_config] adjusted mode:
[  108.42] [drm:drm_mode_debug_printmodeline] Modeline 0:3200x1800 60 
361310 3200 3248 3280 3316 1800 1802 1807 1816 0x48 0xa
[  108.48] [drm:intel_dump_crtc_timings] crtc timings: 361310 3200 3248 
3280 3316 1800 1802 1807 1816, type: 0x48 flags: 0xa
[  108.52] [drm:intel_dump_pipe_config] port clock: 54
[  108.55] [drm:intel_dump_pipe_config] pipe src size: 3200x1800
[  108.59] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, 
ratios: 0x, lvds border: 0x
[  108.63] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, size: 
0x, disabled
[  108.67] [drm:intel_dump_pipe_config] ips: 1
[  108.70] [drm:intel_dump_pipe_config] double wide: 0
[  108.877697] [ cut here ]
[  108.877749] WARNING: CPU: 0 PID: 0 at 
/home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:9713 
intel_check_page_flip+0xe6/0xf0 [i915]()
[  108.877751] Kicking stuck page flip: queued at 6212, now 6217
[  108.877753] Modules linked in: binfmt_misc rfcomm bnep nls_iso8859_1 
ax88179_178a usbnet mii hid_sensor_press hid_sensor_prox hid_sensor_als joydev 
hid_sensor_magn_3d hid_sensor_accel_3d hid_sensor_rotation hid_sensor_gyro_3d 
hid_sensor_incl_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf 
industrialio hid_sensor_iio_common snd_soc_sst_broadwell 
snd_soc_sst_haswell_pcm hid_sensor_hub hid_multitouch snd_soc_sst_dsp btusb 
intel_rapl bluetooth iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel arc4 kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
aesni_intel iwlmvm aes_x86_64 lrw gf128mul glue_helper ablk_helper mac80211 
cryptd serio_raw snd_hda_codec_hdmi iwlwifi uvcvideo videobuf2_vmalloc 
videobuf2_memops cfg80211 videobuf2_core v4l2_common videodev media 
snd_hda_intel
[  108.877791]  snd_hda_controller lpc_ich shpchp snd_hda_codec mei_me mei 
snd_hwdep processor_thermal_device i915 drm_kms_helper drm i2c_algo_bit mac_hid 
int3403_thermal soc_button_array winbond_cir rc_core 8250_fintek snd_soc_rt286 
snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_seq_midi 
snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer i2c_hid snd hid 
soundcore snd_soc_sst_acpi video acpi_pad rfkill_gpio int3402_thermal 
i2c_designware_platform int3400_thermal i2c_designware_core dw_dmac 
spi_pxa2xx_platform 8250_dw dw_dmac_core acpi_thermal_rel parport_pc ppdev lp 
parport autofs4 e1000e ahci libahci ptp sdhci_pci pps_core sdhci_acpi sdhci
[  108.877837] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.4-031904-generic 
#201504131440
[  108.877839] Hardware name: Intel Corporation Broadwell Client 
platform/Wilson Beach SDS, BIOS BDW-E2R1.86C.0080.R00.1406082006 06/08/2014
[  108.877841]  25f1 88024e403d78 

Re: [Intel-gfx] [Contact] Graphics Driver for Broadwell-H CPU

[Zhang, Xiong Y]

Ubuntu 15.04 which will be released at the end of this month should support 
Broadwell-H.
Ubuntu 15.04 beta still couldn’t support Broadwell-H.

Several days ago, I run Kernel 3.19.3 and xf86-video-intel – 2.99.917 on BDW-H.

thanks
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Heah, Jim Poh
Sent: Tuesday, April 14, 2015 10:34 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU


Hi,



I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal

silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for

testing Broadwell-H silicon?



One of the messages were: drm kms helper: panic occurred


Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 
| jim.poh.h...@intel.commailto:jim.poh.h...@intel.com

From: Chacn Limn, DanielX
Sent: Tuesday, April 14, 2015 1:08 AM
To: Heah, Jim Poh
Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael
Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU


Hi Jim Poh,

Please contact The Linux Graphics team in this e-mail: 
intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org



You can also reach them through IRC in: 
#intel-...@freenode.netirc://freenode.net/#intel-gfx.



Please let us know of anything else we can help you with.



Regards,

Daniel.





-Original Message-

From: Heah, Jim Poh

Sent: Monday, April 13, 2015 12:52 AM

To: Chacn Limn, DanielX

Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh

Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU



Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8.

The CPU I am testing with is not a production CPU but an engineering sample.



Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang |

604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com



-Original Message-

From: Chacn Limn, DanielX

Sent: Friday, April 10, 2015 12:52 AM

To: Heah, Jim Poh

Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael

Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU



Hi Jim,

Are you using drivers from the Downloads section of this site?

https://01.org/linuxgraphics/



Please provide more details on where did you get the drivers and what version

are you testing.



Thanks in advance,

Daniel.





-Original Message-

From: Becerra Ruiz, Lilia

Sent: Wednesday, April 8, 2015 10:45 AM

To: Chacn Limn, DanielX

Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU





Me dices si necesitas ayuda con este



-Original Message-

From: webmas...@01.orgmailto:webmas...@01.org [mailto:webmas...@01.org] On 
Behalf Of

jim.poh.h...@intel.commailto:jim.poh.h...@intel.com

Sent: Tuesday, April 7, 2015 9:47 PM

To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn,

DanielX

Subject: [Contact] Graphics Driver for Broadwell-H CPU



Jim Poh Heah (jim.poh.h...@intel.commailto:jim.poh.h...@intel.com) sent a 
message using the contact form at

https://01.org/about/contact-us.



I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal

silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for

testing Broadwell-H silicon?



One of the messages were: drm kms helper: panic occurred



Report as inappropriate:

https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Contact] Graphics Driver for Broadwell-H CPU

[Zhang, Xiong Y]

I don’t know the status of Fedora.

You could compile upstream 3.19.3 / 4.0 kernel and xf86-video-intel – 2.99.917 
in Fedora.

thanks
From: Heah, Jim Poh
Sent: Tuesday, April 14, 2015 12:38 PM
To: Zhang, Xiong Y; intel-gfx@lists.freedesktop.org
Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU

Thanks Xiong,
What about Fedora? Are there any plans for Fedora?

Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 
| jim.poh.h...@intel.commailto:jim.poh.h...@intel.com

From: Zhang, Xiong Y
Sent: Tuesday, April 14, 2015 10:57 AM
To: Heah, Jim Poh; 
intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org
Cc: Zhang, Xiong Y
Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU

Ubuntu 15.04 which will be released at the end of this month should support 
Broadwell-H.
Ubuntu 15.04 beta still couldn’t support Broadwell-H.

Several days ago, I run Kernel 3.19.3 and xf86-video-intel – 2.99.917 on BDW-H.

thanks
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Heah, Jim Poh
Sent: Tuesday, April 14, 2015 10:34 AM
To: intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU


Hi,



I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal

silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for

testing Broadwell-H silicon?



One of the messages were: drm kms helper: panic occurred


Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 
| jim.poh.h...@intel.commailto:jim.poh.h...@intel.com

From: Chacn Limn, DanielX
Sent: Tuesday, April 14, 2015 1:08 AM
To: Heah, Jim Poh
Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael
Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU


Hi Jim Poh,

Please contact The Linux Graphics team in this e-mail: 
intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org



You can also reach them through IRC in: 
#intel-...@freenode.netirc://freenode.net/#intel-gfx.



Please let us know of anything else we can help you with.



Regards,

Daniel.





-Original Message-

From: Heah, Jim Poh

Sent: Monday, April 13, 2015 12:52 AM

To: Chacn Limn, DanielX

Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh

Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU



Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8.

The CPU I am testing with is not a production CPU but an engineering sample.



Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang |

604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com



-Original Message-

From: Chacn Limn, DanielX

Sent: Friday, April 10, 2015 12:52 AM

To: Heah, Jim Poh

Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael

Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU



Hi Jim,

Are you using drivers from the Downloads section of this site?

https://01.org/linuxgraphics/



Please provide more details on where did you get the drivers and what version

are you testing.



Thanks in advance,

Daniel.





-Original Message-

From: Becerra Ruiz, Lilia

Sent: Wednesday, April 8, 2015 10:45 AM

To: Chacn Limn, DanielX

Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU





Me dices si necesitas ayuda con este



-Original Message-

From: webmas...@01.orgmailto:webmas...@01.org [mailto:webmas...@01.org] On 
Behalf Of

jim.poh.h...@intel.commailto:jim.poh.h...@intel.com

Sent: Tuesday, April 7, 2015 9:47 PM

To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn,

DanielX

Subject: [Contact] Graphics Driver for Broadwell-H CPU



Jim Poh Heah (jim.poh.h...@intel.commailto:jim.poh.h...@intel.com) sent a 
message using the contact form at

https://01.org/about/contact-us.



I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal

silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for

testing Broadwell-H silicon?



One of the messages were: drm kms helper: panic occurred



Report as inappropriate:

https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] igt: Correct the return value for drm short_buffer read

[Zhang, Xiong Y]

 -Original Message-
 From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
 Sent: Tuesday, December 23, 2014 7:31 PM
 To: Zhang, Xiong Y
 Cc: intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] igt: Correct the return value for drm
 short_buffer read
 
 On Tue, Dec 23, 2014 at 10:14:15AM +, Zhang, Xiong Y wrote:
   -Original Message-
   From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
   Sent: Tuesday, December 23, 2014 5:53 PM
   To: Zhang, Xiong Y
   Cc: intel-gfx@lists.freedesktop.org
   Subject: Re: [Intel-gfx] [PATCH] igt: Correct the return value for
   drm short_buffer read
  
   On Tue, Dec 23, 2014 at 03:52:11PM +0800, Xiong Zhang wrote:
After i915 commit:
commit bd008e5b2953186fc0c6633a885ade95e7043800
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Tue Oct 7 14:13:51 2014 +0100
   
drm: Implement O_NONBLOCK support on /dev/dri/cardN
   
the return value for drm short_buffer read is -1 and errno is EAGAIN.
  
   No, it is not.
   -Chris
  Without this patch, system fail in short-buffer-block and
 short-buffer-nonblock subtest.
  With this patch, these two subtest could pass.
 
 That's the point of the test, the kernel behaviour is wrong. There is a patch 
 to fix
 the kernel.
 -Chris
[Zhang, Xiong Y] Oh, I know it. Thanks.
So could you send this patch to fix it ?
 
 --
 Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] igt: Correct the return value for drm short_buffer read

[Zhang, Xiong Y]

 -Original Message-
 From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
 Sent: Tuesday, December 23, 2014 5:53 PM
 To: Zhang, Xiong Y
 Cc: intel-gfx@lists.freedesktop.org
 Subject: Re: [Intel-gfx] [PATCH] igt: Correct the return value for drm
 short_buffer read
 
 On Tue, Dec 23, 2014 at 03:52:11PM +0800, Xiong Zhang wrote:
  After i915 commit:
  commit bd008e5b2953186fc0c6633a885ade95e7043800
  Author: Chris Wilson ch...@chris-wilson.co.uk
  Date:   Tue Oct 7 14:13:51 2014 +0100
 
  drm: Implement O_NONBLOCK support on /dev/dri/cardN
 
  the return value for drm short_buffer read is -1 and errno is EAGAIN.
 
 No, it is not.
 -Chris
Without this patch, system fail in short-buffer-block and short-buffer-nonblock 
subtest.
With this patch, these two subtest could pass.
 
 --
 Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] lib/drmtest: add drmtest_disable/enable_prefault() function

[Zhang, Xiong Y]

Yes, I have tested it before I sent out the patch.
It hit all the slow paths.

Thanks.

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Saturday, July 20, 2013 12:14 AM
To: Zhang, Xiong Y
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] lib/drmtest: add 
drmtest_disable/enable_prefault() function

On Fri, Jul 19, 2013 at 06:42:51PM +0800, Xiong Zhang wrote:
 V2: add exit handler to enable prefault (Daniel)
 
 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com

Thanks a lot for doing these patches, I've merged them both. Just to
check: Are the subtests added now instead of your gem_prefault testcase good 
enough to still hit all slowpaths? I have to admit that I didn't even really 
compile-test my little idea that I've pasted as a diff into my reply ;-)

Cheers, Daniel

 ---
  lib/drmtest.c | 50 ++
  lib/drmtest.h |  3 +++
  2 files changed, 53 insertions(+)
 
 diff --git a/lib/drmtest.c b/lib/drmtest.c index 011d8c1..980fa49 
 100644
 --- a/lib/drmtest.c
 +++ b/lib/drmtest.c
 @@ -1593,3 +1593,53 @@ void kmstest_free_connector_config(struct 
 kmstest_connector_config *config)
   drmModeFreeEncoder(config-encoder);
   drmModeFreeConnector(config-connector);
  }
 +
 +#define PREFAULT_DEBUGFS /sys/module/i915/parameters/prefault_disable
 +static int drmtest_prefault_control(bool enable) {
 + char *name = PREFAULT_DEBUGFS;
 + int fd;
 + char buf[2] = {'Y', 'N'};
 + int index;
 + int result = 0;
 +
 + fd = open(name, O_RDWR);
 + if (fd == -1) {
 + fprintf(stderr, Couldn't open prefault_debugfs.%s\n,
 + strerror(errno));
 + return -1;
 + }
 +
 + if (enable)
 + index = 1;
 + else
 + index = 0;
 +
 + if (write(fd, buf[index], 1) != 1) {
 + fprintf(stderr, write prefault_debugfs error.%s\n,
 + strerror(errno));
 + result = -1;
 + }
 +
 + close(fd);
 +
 + return result;
 +}
 +
 +static void enable_prefault_at_exit(int sig) {
 + drmtest_enable_prefault();
 +}
 +
 +int drmtest_disable_prefault(void)
 +{
 + drmtest_install_exit_handler(enable_prefault_at_exit);
 +
 + return drmtest_prefault_control(false); }
 +
 +int drmtest_enable_prefault(void)
 +{
 + return drmtest_prefault_control(true); }
 +
 diff --git a/lib/drmtest.h b/lib/drmtest.h index e3a9275..80b344c 
 100644
 --- a/lib/drmtest.h
 +++ b/lib/drmtest.h
 @@ -179,3 +179,6 @@ void drmtest_enable_exit_handler(void);
  void drmtest_disable_exit_handler(void);
  
  int drmtest_set_vt_graphics_mode(void);
 +
 +int drmtest_disable_prefault(void);
 +int drmtest_enable_prefault(void);
 --
 1.8.3.2
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: run shmem_pread_fast() after page fault

[Zhang, Xiong Y]

It just influence one page.
During my test, I found one read slow path info when enable prefault. So I add 
this patch.
Why don't move fault_in_multipages_writeable() from i915_gem_shmem_pread() to 
the beginning of i915_gem_pread_ioctl() ? 
So the pread_ioctl() is like pwrite_ioctl(). Is the cost of 
fault_in_multipages_writeable() lager than fault_in_multipages_readable() ?
See the attachment.

thanks
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, July 19, 2013 3:29 PM
To: Zhang, Xiong Y
Cc: intel-gfx@lists.freedesktop.org; Chris Wilson
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: run shmem_pread_fast() after 
page fault

On Fri, Jul 19, 2013 at 01:51:26PM +0800, Xiong Zhang wrote:
 fault_in_multipages_writeable() will load fault page into physical 
 memory, then pread can run fast path, no need to run slow path
 
 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com

Hm, this avoids going through the slowpath for the first page. Does this have 
an impact on micro-benchmarks (we have a few) or is this just something you've 
spotted? I'm a bit vary of making the already complicated shmem pread/pwrite 
paths even more complicated. Chris?
-Daniel

 ---
  drivers/gpu/drm/i915/i915_gem.c | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
 b/drivers/gpu/drm/i915/i915_gem.c index f194d7e..982df1e 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -459,6 +459,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
   page_do_bit17_swizzling = obj_do_bit17_swizzling 
   (page_to_phys(page)  (1  17)) != 0;
  
 +read_again:
   ret = shmem_pread_fast(page, shmem_page_offset, page_length,
  user_data, page_do_bit17_swizzling,
  needs_clflush);
 @@ -475,6 +476,8 @@ i915_gem_shmem_pread(struct drm_device *dev,
* and just continue. */
   (void)ret;
   prefaulted = 1;
 + mutex_lock(dev-struct_mutex);
 + goto read_again;
   }
  
   ret = shmem_pread_slow(page, shmem_page_offset, page_length,
 --
 1.8.3.2
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


0001-drm-i915-move-page-fault-handle-to-i915_gem_pread_io.patch
Description: 0001-drm-i915-move-page-fault-handle-to-i915_gem_pread_io.patch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Decrease pll-refcount when freeze gpu

[Zhang, Xiong Y]

Hi Jesse:
  I supply this patch because I encounter the S3 and S4 problem on Haswell 
connecting VGA or HDMI screen.
  Currently nobody call intel_ddi_put_crtc_pll() to decrease pll_refcount and 
clear ddi_pll_sel when enter sleep states.
  So when resume from sleep states, pll_refcount is larger than zero. mode 
setting function will call intel_ddi_pll_mode_set().
  Intel_ddi_pll_mode_set call intel_ddi_put_crtc_pll() first, then set pll and 
increase pll-refcount. The results are:
  1. S3 resume have call trace in intel_ddi_put_crtc_pll()
If connecting vga, the call trace is WARN_ON(!SPLL_PLL_ENABLE)
If connecting HDMI, the call trace is WARN_ON(!WRPLL_PLL_ENABLE)
  2. S4 resume fail in intel_ddi_pll_mode_set()
If connecting VGA, intel_ddi_pll_mode_set () return false and mode setting 
exit without setting mode, vga is black
If connecting HDMI, before enter S4, HDMI use WRPLL1.After resume from S4, 
HDMI use WRPLL2.  The status is different during S4

 Actually, the above problem is a regression caused by your commit:
   commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
   Author: Jesse Barnes jbar...@virtuousgeek.org
   Date:   Tue Mar 26 09:25:45 2013 -0700
 drm/i915: enable VT switchless resume v3
  
In your patch, you delete intel_modeset_disable() from i915_drm_freeze(), 
intel_modeset_disable() will call dev_priv-display.off(crtc) to 
decrease pll_refcount and disable PLL.

My question is whether PLL can be disabled when enable VT switchless ?

Thanks

-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
Daniel Vetter
Sent: Friday, July 12, 2013 1:32 AM
To: Jesse Barnes
Cc: Zhang, Xiong Y; intel-gfx
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Decrease pll-refcount when freeze 
gpu

On Thu, Jul 11, 2013 at 6:53 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Thu, 11 Jul 2013 16:02:27 +0800
 Xiong Zhang xiong.y.zh...@intel.com wrote:

 display.crtc_mode_set will increase pll-refcount, but no one will 
 decrease pll-refcount when freeze gpu. So when gpu resume from 
 freeze,
 pll-refcount is still larger than zero. This is abnormal

 Without this patch, connecting vga screen on Haswell platform, there 
 are following results:
 1. when resume S3, call trace exist in intel_ddi_put_crtc_pll() 2. 
 when resume s4, vga monitor is black. because intel_ddi_pll_mode_set()
return false and haswell_crtc_mode_set() exit without setting mode

 With this patch, I don't find S3 and S4 regression on SandyBridge and 
 IvyBridge platform connecting VGA, HDMI and DP screen.

 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.c 
 b/drivers/gpu/drm/i915/i915_drv.c index 0485f43..0065735 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -575,8 +575,10 @@ static int i915_drm_freeze(struct drm_device *dev)
* Disable CRTCs directly since we want to preserve sw state
* for _thaw.
*/
 - list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
 + list_for_each_entry(crtc, dev-mode_config.crtc_list, 
 + head) {
   dev_priv-display.crtc_disable(crtc);
 + dev_priv-display.off(crtc);
 + }

   intel_modeset_suspend_hw(dev);
   }

 The comment above this call indicates we'll trash the sw state if we 
 call -off directly.  Does suspend/resume still work both with and 
 without X with this patch applied?  If we trash the sw state, the VT 
 switchless resume shouldn't work...

Even without that little issue: ddi refcounting issue need to be fixed in the 
haswell platform code, not by papering over in the core modeset infrastructure. 
We have refcounted pch plls on snb/ivb, and it works.
So imo there's no issue with the core code in the driver.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct obj-mm_list link to dev_priv-dev_priv-mm.inactive_list

[Zhang, Xiong Y]

I found this issue when I read code. I don't have testcase.

thanks
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, July 05, 2013 9:41 PM
To: Zhang, Xiong Y
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct obj-mm_list link to 
dev_priv-dev_priv-mm.inactive_list

On Fri, Jul 05, 2013 at 06:53:29PM +0800, Xiong Zhang wrote:
 obj-mm_list link to dev_priv-mm.inactive_list/active_list
 obj-global_list link to dev_priv-mm.unbound_list/bound_list
 
 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com

Oh dear have I screwed this up.

This fixes a regression introduced in

commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Thu Jan 10 18:03:00 2013 +0100

drm/i915: Revert shrinker changes from Track unbound pages

Cc: sta...@vger.kernel.org

Now the big question is why none of our tests has caught this. Xiong, how have 
you tracked down this issues? Do you perhaps have a testcase that can readily 
reproduce this that we could add to intel-gpu-tools?

Thanks, Daniel

 ---
  drivers/gpu/drm/i915/i915_gem.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c 
 b/drivers/gpu/drm/i915/i915_gem.c index 44d890b..b6a2402 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -4637,7 +4637,7 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, 
 struct shrink_control *sc)
   list_for_each_entry(obj, dev_priv-mm.unbound_list, global_list)
   if (obj-pages_pin_count == 0)
   cnt += obj-base.size  PAGE_SHIFT;
 - list_for_each_entry(obj, dev_priv-mm.inactive_list, global_list)
 + list_for_each_entry(obj, dev_priv-mm.inactive_list, mm_list)
   if (obj-pin_count == 0  obj-pages_pin_count == 0)
   cnt += obj-base.size  PAGE_SHIFT;
  
 --
 1.7.9.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: correct the calculation of first_pd_entry_in_global_pt

[Zhang, Xiong Y]

When ppgtt is enabled, dev_priv-gtt.total has excluded the gtt space occupied 
by ppgtt table in i915_gem_init_global_gtt() function. So the calculation of 
first_pd_entry_in_global_pt doesn't need to subtract I915_PPGTT_PD_ENTRIES 
again. Or else PPGTT directory table will be destroyed by global gtt allocation.

Signed-off-by: Xiong Zhangxiong.y.zh...@intel.com

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ce024bd..3cd48e2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -258,8 +258,7 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
/* ppgtt PDEs reside in the global gtt pagetable, which has 512*1024
 * entries. For aliasing ppgtt support we just steal them at the end for
 * now. */
-   first_pd_entry_in_global_pt =
-   gtt_total_entries(dev_priv-gtt) - I915_PPGTT_PD_ENTRIES;
+   first_pd_entry_in_global_pt = gtt_total_entries(dev_priv-gtt);

if (IS_HASWELL(dev)) {
ppgtt-pte_encode = hsw_pte_encode;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: ignore hotplug event across suspend

[Zhang, Xiong Y]

when system enter suspend, hibernate and poweroff state, it will
disable modeset firstly, then disable irq, but some system generate
hotplug event between disable modeset and disable irq, this will
result in S3, S4 failure. So this hotplug event should be ignored.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508
Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
---
 drivers/gpu/drm/i915/i915_irq.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2139714..68cc7a7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -290,6 +290,12 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
struct intel_encoder *encoder;
+
+/* some system generate hotplug envent when system enter sleep state.
+ * it should be ignored.
+ */
+if (dev_priv-mm.suspended)
+return;

/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fw: Very low performance when streaming textures

[Zhang, Xiong Y]

Using the latest mesa master tree, I test it on my Core i7-2600 : 

1)  In default configuration, the monitor's refresh rate is 60FPS, so the test 
result is 59.3 FPS
2)  export vblank_mode = 0, then the test result is 170 FPS.
I don't see the big difference between using direct transfer or using PBO, the 
test result almost is the same on these two cases.

thanks

-Original Message-
From: intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org 
[mailto:intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org] On 
Behalf Of Ben Widawsky
Sent: Tuesday, January 22, 2013 1:34 PM
To: mesa-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] Fw: Very low performance when streaming textures

mesa-dev is a better place for this question.

Begin forwarded message:

Date: Mon, 21 Jan 2013 22:13:34 +0100
From: Marcel Witte witte...@gmail.com
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] Very low performance when streaming textures


Hi,

I'm refering to the example of this article about streaming textures and using 
Pixel Buffer Objects: http://www.songho.ca/opengl/gl_pbo.html

The PBO Unpack example
(http://www.songho.ca/opengl/files/pboUnpack.zip) is creating an animated 
texture and can switch between three modes: Direct transfering of the texture 
using glTexSubImage2D, and using one or two PBOs for better performance.

I'm running this example on an notebook with an Intel Core i7-2630QM and an 
Nvidia Geforce GT 550M with Optimus. If I'm using the Nvidia card using optirun 
I get the expected high performance, using direct tranfer about 150 fps and 
using PBOs about 400 fps. But if I'm using the intel card I get really slow 
rates, about 40 fps in direct mode and even worse about 10 fps using PBOs.

Running the same example with windows I get about 100 fps using the intel card 
in every mode.

Is this expected behaviour or is this a bug in the intel linux driver?
How can I improve the performance? I hope you can help me here as I'm writing a 
real application using a video as texture.

Regards,
Marcel Witte
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] gfx context switch

[Zhang, Xiong Y]

Hi, all:

When gfx executes batch buffer in render ring buffer, it will do context switch 
.

Since only when the previous batch buffer has finished, the next batch buffer 
can start. the batch buffer is executed in order. So I think there is no need 
to do context switch.

Why i915 driver introduce context switch ?  If context switch is disabled, what 
error will occur ?

Why gfx need context switch, can somebody give me a example to use context 
switch ?

Thanks in advance.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: l3 parity sysfs interface

[Zhang, Xiong Y]

   
   Who will monitor this sysfs interface, 2D driver or 3D driver or other 
application ?
   Now, I don't find any user of this sysfs interface in 2D driver or 3D driver.

thanks

-Original Message-
From: intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org 
[mailto:intel-gfx-bounces+xiong.y.zhang=intel@lists.freedesktop.org] On 
Behalf Of Ben Widawsky
Sent: Saturday, May 26, 2012 7:56 AM
To: intel-gfx@lists.freedesktop.org
Cc: Ben Widawsky
Subject: [Intel-gfx] [PATCH 4/4] drm/i915: l3 parity sysfs interface

Dumb binary interfaces which allow root-only updates of the cache remapping 
registers. As mentioned in a previous patch, software using this interface 
needs to know about HW limits, and other programming considerations as the 
kernel interface does no checking for these things on the root-only interface.

v1: Drop extra posting reads (Chris)
Return negative values in the sysfs interfaces on errors (Chris)

v2: Return -EINVAL for offset % 4 (Jesse) Move schizo userspace check out 
(Jesse) Cleaner sysfs item initializers (Daniel)

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/i915_sysfs.c |  121 -
 1 file changed, 119 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 79f8344..c201327 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -29,6 +29,7 @@
 #include linux/module.h
 #include linux/stat.h
 #include linux/sysfs.h
+#include intel_drv.h
 #include i915_drv.h
 
 static u32 calc_residency(struct drm_device *dev, const u32 reg) @@ -92,20 
+93,136 @@ static struct attribute_group rc6_attr_group = {
.attrs =  rc6_attrs
 };
 
+static int l3_access_valid(struct drm_device *dev, loff_t offset) {
+   if (!IS_IVYBRIDGE(dev))
+   return -EPERM;
+
+   if (offset % 4 != 0)
+   return -EINVAL;
+
+   if (offset = GEN7_L3LOG_SIZE)
+   return -ENXIO;
+
+   return 0;
+}
+
+static ssize_t
+i915_l3_read(struct file *filp, struct kobject *kobj,
+struct bin_attribute *attr, char *buf,
+loff_t offset, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct drm_minor *dminor = container_of(dev, struct drm_minor, kdev);
+   struct drm_device *drm_dev = dminor-dev;
+   struct drm_i915_private *dev_priv = drm_dev-dev_private;
+   uint32_t misccpctl;
+   int i, ret;
+
+   ret = l3_access_valid(drm_dev, offset);
+   if (ret)
+   return ret;
+
+   ret = i915_mutex_lock_interruptible(drm_dev);
+   if (ret)
+   return ret;
+
+   misccpctl = I915_READ(GEN7_MISCCPCTL);
+   I915_WRITE(GEN7_MISCCPCTL, misccpctl  ~GEN7_DOP_CLOCK_GATE_ENABLE);
+
+   for (i = offset; count = 4  i  GEN7_L3LOG_SIZE; i += 4, count -= 4)
+   *((uint32_t *)(buf[i])) = I915_READ(GEN7_L3LOG_BASE + i);
+
+   I915_WRITE(GEN7_MISCCPCTL, misccpctl);
+
+   mutex_unlock(drm_dev-struct_mutex);
+
+   return i - offset;
+}
+
+static ssize_t
+i915_l3_write(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr, char *buf,
+ loff_t offset, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct drm_minor *dminor = container_of(dev, struct drm_minor, kdev);
+   struct drm_device *drm_dev = dminor-dev;
+   struct drm_i915_private *dev_priv = drm_dev-dev_private;
+   u32 *temp = NULL; /* Just here to make handling failures easy */
+   int ret;
+
+   ret = l3_access_valid(drm_dev, offset);
+   if (ret)
+   return ret;
+
+   ret = i915_mutex_lock_interruptible(drm_dev);
+   if (ret)
+   return ret;
+
+   if (!dev_priv-mm.l3_remap_info) {
+   temp = kzalloc(GEN7_L3LOG_SIZE, GFP_KERNEL);
+   if (!temp) {
+   mutex_unlock(drm_dev-struct_mutex);
+   return -ENOMEM;
+   }
+   }
+
+   ret = i915_gpu_idle(drm_dev);
+   if (ret) {
+   kfree(temp);
+   mutex_unlock(drm_dev-struct_mutex);
+   return ret;
+   }
+
+   /* TODO: Ideally we really want a GPU reset here to make sure errors
+* aren't propagated. Since I cannot find a stable way to reset the GPU
+* at this point it is left as a TODO.
+   */
+   if (temp)
+   dev_priv-mm.l3_remap_info = temp;
+
+   memcpy(dev_priv-mm.l3_remap_info + (offset/4),
+  buf + (offset/4),
+  count);
+
+   i915_gem_l3_remap(drm_dev);
+
+   mutex_unlock(drm_dev-struct_mutex);
+
+   return count;
+}
+
+static struct bin_attribute dpf_attrs = {
+   .attr = {.name = l3_parity, .mode = (S_IRUSR | S_IWUSR)},
+   .size = GEN7_L3LOG_SIZE,
+   .read = i915_l3_read,
+   .write =