Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

On Mon, 28 Oct 2013 16:46:09 +1100 Stephen Rothwell  
wrote:
>
> @@@ -1486,8 -1542,8 +1562,8 @@@ static void intel_edp_psr_setup(struct 
>   intel_edp_psr_write_vsc(intel_dp, &psr_vsc);
>   
>   /* Avoid continuous PSR exit by masking memup and hpd */
>  -I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
>  +I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
> -EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
> +EDP_PSR_DEBUG_MASK_HPD);
>   
>   intel_dp->psr_setup_done = true;
>   }

This last hunk is wrong.  I fixed it up to do the reverse of the above.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpsH4ImC37W3.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_dp.c between commit 0cc4b69960f3 ("drm/i915:
Mask LPSP to get PSR working even with Power Well in use by audio") from
Linus' tree and commit 52e1e223456e ("drm/i915/dp: workaround BIOS eDP
bpp clamping issue") from the drm-intel-fixes tree and commits
18442d087864 ("drm/i915: Fix port_clock and adjusted_mode.clock readout
all over") and 18b5992c3756 ("drm/i915: Calculate PSR register offsets
from base + gen") from the drm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_dp.c
index 1a431377d83b,1e3d2720d811..
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1402,31 -1469,20 +1469,40 @@@ static void intel_dp_get_config(struct 
pipe_config->port_clock = 27;
}
  
 +  if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
 +  pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
 +  /*
 +   * This is a big fat ugly hack.
 +   *
 +   * Some machines in UEFI boot mode provide us a VBT that has 18
 +   * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
 +   * unknown we fail to light up. Yet the same BIOS boots up with
 +   * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
 +   * max, not what it tells us to use.
 +   *
 +   * Note: This will still be broken if the eDP panel is not lit
 +   * up by the BIOS, and thus we can't get the mode at module
 +   * load.
 +   */
 +  DRM_DEBUG_KMS("pipe has %d bpp for eDP panel, overriding 
BIOS-provided max %d bpp\n",
 +pipe_config->pipe_bpp, dev_priv->vbt.edp_bpp);
 +  dev_priv->vbt.edp_bpp = pipe_config->pipe_bpp;
 +  }
++
+   dotclock = intel_dotclock_calculate(pipe_config->port_clock,
+   &pipe_config->dp_m_n);
+ 
+   if (HAS_PCH_SPLIT(dev_priv->dev) && port != PORT_A)
+   ironlake_check_encoder_dotclock(pipe_config, dotclock);
+ 
+   pipe_config->adjusted_mode.crtc_clock = dotclock;
  }
  
- static bool is_edp_psr(struct intel_dp *intel_dp)
+ static bool is_edp_psr(struct drm_device *dev)
  {
-   return is_edp(intel_dp) &&
-   intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+ 
+   return dev_priv->psr.sink_support;
  }
  
  static bool intel_edp_is_psr_enabled(struct drm_device *dev)
@@@ -1486,8 -1542,8 +1562,8 @@@ static void intel_edp_psr_setup(struct 
intel_edp_psr_write_vsc(intel_dp, &psr_vsc);
  
/* Avoid continuous PSR exit by masking memup and hpd */
 -  I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
 +  I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
-  EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
+  EDP_PSR_DEBUG_MASK_HPD);
  
intel_dp->psr_setup_done = true;
  }


pgpF3INdlcqYt.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/4] Fix Win8 backlight issue

[Aaron Lu]

On 10/25/2013 02:35 PM, Igor Gnatenko wrote:
> Aaron, add this notebook to list. I've CC'ed owner.
> And I've tested this patch on my TP X230 (add as Reported-and-Tested me
> please)
> + {
> +  .callback = video_set_use_native_backlight,
> +  .ident = "Dell Inspiron 7520",
> +  .matches = {
> +  DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +  DMI_MATCH(DMI_PRODUCT_VERSION, "Inspiron 7520"),
> + },
> + },

Thanks Igor, updated patch follows:

From: Aaron Lu 
Subject: [PATCH] ACPI / video: Add systems that should favour native backlight
 interface

Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. To be
specific, the ThinkPad T430s/X230, Lenovo Yoga 13 and Dell Inspiron 7520
are added here.

Thinkpad T430s:
Reported-by: Theodore Tso 
Reported-and-tested-by: Peter Weber 
Thinkpad X230:
Reported-and-tested-by: Igor Gnatenko 
Lenovo Yoga 13:
Reported-by: Lennart Poettering 
Reported-and-tested-by: Kevin Smith 
Dell Inspiron 7520:
Reported-by: Renat Ibragimov 

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Signed-off-by: Aaron Lu 
---
 drivers/acpi/video.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index d020df5..0a1b030 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -412,6 +412,12 @@ static int video_ignore_initial_backlight(const struct 
dmi_system_id *d)
return 0;
 }
 
+static int __init video_set_use_native_backlight(const struct dmi_system_id *d)
+{
+   use_native_backlight = true;
+   return 0;
+}
+
 static struct dmi_system_id video_dmi_table[] __initdata = {
/*
 * Broken _BQC workaround 
http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -504,6 +510,38 @@ static struct dmi_system_id video_dmi_table[] __initdata = 
{
DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion m4 Notebook PC"),
},
},
+   {
+.callback = video_set_use_native_backlight,
+.ident = "ThinkPad T430s",
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T430s"),
+   },
+   },
+   {
+.callback = video_set_use_native_backlight,
+.ident = "ThinkPad X230",
+.matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X230"),
+   },
+   },
+   {
+.callback = video_set_use_native_backlight,
+.ident = "Lenovo Yoga 13",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo IdeaPad Yoga 13"),
+   },
+   },
+   {
+.callback = video_set_use_native_backlight,
+.ident = "Dell Inspiron 7520",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+DMI_MATCH(DMI_PRODUCT_VERSION, "Inspiron 7520"),
+   },
+   },
{}
 };
 
-- 
1.8.4.39.ga0d3f10

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

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: remove device field from struct power_well

[Daniel Vetter]

On Fri, Oct 25, 2013 at 05:50:18PM -0200, Paulo Zanoni wrote:
> 2013/10/25 Imre Deak :
> > The only real need for this field was in
> > i915_{request,release}_power_well, but there we can get at it by a
> > container_of magic. Also since in the future we'll have multiple power
> > wells each with its own power_well struct it makes sense to remove the
> > field from there where it'd be just redundancy.
> >
> > Suggested-by: Paulo Zanoni 
> 
> My original idea was to just move it from i915_power_well to
> i915_power_domains, so hsw_pwr (which is the new external static
> thing) would still have a pointer to our driver. This way we wouldn't
> need the container_of magic. But your solution works too, and saves
> 4/8 bytes :)
> 
> Reviewed-by: Paulo Zanoni 

First 3 patches merged, thanks.
-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] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Daniel Vetter]

On Sun, Oct 27, 2013 at 11:35:58AM -0700, Guenter Roeck wrote:
> On 10/27/2013 10:33 AM, Greg KH wrote:
> >On Sun, Oct 27, 2013 at 04:13:42PM +, Rob Pearce wrote:
> >>From: Rob Pearce 
> >>
> >>The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
> >>having LVDS but the hardware is not populated. This patch adds them to
> >>the list of such systems. Patch is against 3.11.4
> >>
> >>Signed-off-by: Rob Pearce 
> >>---
> >>Patch revised to match the D425KT exactly as the D425KTW does have LVDS.
> >>According to Intel's documentation, the D410PTL and D410PLTW don't.
> >
> >Any reason you don't want this in the stable tree as well?
> >
> 
> Hi Greg,
> 
> pardon my ignorance, but I thought this was supposed to be the maintainer's 
> call to make ?
> Did I get this wrong ?

Maintainer occasionally fumble it, so it's better when the patch submitter
also thinks about this. I can always change it when I disagree ;-)
-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] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Guenter Roeck]

On 10/27/2013 10:33 AM, Greg KH wrote:

On Sun, Oct 27, 2013 at 04:13:42PM +, Rob Pearce wrote:

From: Rob Pearce 

The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Patch is against 3.11.4

Signed-off-by: Rob Pearce 
---
Patch revised to match the D425KT exactly as the D425KTW does have LVDS.
According to Intel's documentation, the D410PTL and D410PLTW don't.


Any reason you don't want this in the stable tree as well?



Hi Greg,

pardon my ignorance, but I thought this was supposed to be the maintainer's 
call to make ?
Did I get this wrong ?

Thanks,
Guenter




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

Re: [Intel-gfx] [PATCH] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Rob Pearce]

On 27/10/13 17:33, Greg KH wrote:
> On Sun, Oct 27, 2013 at 04:13:42PM +, Rob Pearce wrote:
>> From: Rob Pearce 
>>
>> The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
>> having LVDS but the hardware is not populated. This patch adds them to
>> the list of such systems. Patch is against 3.11.4
>>
>> Signed-off-by: Rob Pearce 
>> ---
>> Patch revised to match the D425KT exactly as the D425KTW does have LVDS. 
>> According to Intel's documentation, the D410PTL and D410PLTW don't.
> 
> Any reason you don't want this in the stable tree as well?
> 

No, should be in stable. Sorry, I'm obviously getting some etiquette
wrong (this is the first patch I've submitted).

Cheers,
Rob

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

Re: [Intel-gfx] [PATCH] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Daniel Vetter]

On Sun, Oct 27, 2013 at 10:33:02AM -0700, Greg KH wrote:
> On Sun, Oct 27, 2013 at 04:13:42PM +, Rob Pearce wrote:
> > From: Rob Pearce 
> > 
> > The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
> > having LVDS but the hardware is not populated. This patch adds them to
> > the list of such systems. Patch is against 3.11.4
> > 
> > Signed-off-by: Rob Pearce 
> > ---
> > Patch revised to match the D425KT exactly as the D425KTW does have LVDS. 
> > According to Intel's documentation, the D410PTL and D410PLTW don't.
> 
> Any reason you don't want this in the stable tree as well?

None. Picked up for -fixes, thanks for the patch. Also I prefer the patch
change log in the commit message proper and less screaming in the summary
;-) All fixed while applying.
-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

[Intel-gfx] [PATCH] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Rob Pearce]

From: Rob Pearce 

The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Patch is against 3.11.4

Signed-off-by: Rob Pearce 
---
Patch revised to match the D425KT exactly as the D425KTW does have LVDS. 
According to Intel's documentation, the D410PTL and D410PLTW don't.


diff -uprN -X linux-3.11.4/Documentation/dontdiff 
linux-3.11.4/drivers/gpu/drm/i915/intel_lvds.c 
linux-3.11.4-ovs/drivers/gpu/drm/i915/intel_lvds.c
--- linux-3.11.4/drivers/gpu/drm/i915/intel_lvds.c   2013-10-22 
19:00:30.0 +0100
+++ linux-3.11.4-ovs/drivers/gpu/drm/i915/intel_lvds.c   2013-10-27 
15:51:25.0 +
@@ -696,6 +696,22 @@
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Intel D410PT",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
+   DMI_MATCH(DMI_BOARD_NAME, "D410PT"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Intel D425KT",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, "D425KT"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Intel D510MO",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Intel"),

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

Re: [Intel-gfx] [PATCH] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Rob Pearce]

Hi Daniel,

On 27/10/13 13:51, Daniel Vetter wrote:
>> +.matches = {
>> > +  DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
>> > +  DMI_MATCH(DMI_BOARD_NAME, "D425KT"),
> At least this one here has a KTW variant with lvds connector. I think we
> need a DMI_EXACT_MATCH. I haven't found out whether the D410PT board also
> has such a cousin, so please digg in a bit for me.
> 
Yes, you're right, sorry. I've had a dig and it looks like the D410PT
variants don't have LVDS (the differences in that range are legacy I/O,
PCIe and wireless). I'll re-submit with the 425 as an exact match.

Regards,
Rob


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

[Intel-gfx] [PATCH] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Rob Pearce]

From: Rob Pearce  

These Intel D410PT and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Tested against 3.9.10 and 3.11.4

Signed-off-by: Rob Pearce 
---
diff -uprN -X linux-3.9.10/Documentation/dontdiff 
linux-3.9.10/drivers/gpu/drm/i915/intel_lvds.c 
linux-3.9.10-ovs/drivers/gpu/drm/i915/intel_lvds.c
--- linux-3.9.10/drivers/gpu/drm/i915/intel_lvds.c   2013-10-22 
19:00:30.0 +0100
+++ linux-3.9.10-ovs/drivers/gpu/drm/i915/intel_lvds.c   2013-10-22 
18:58:56.0 +0100
@@ -843,6 +843,22 @@
},
{
.callback = intel_no_lvds_dmi_callback,
+   .ident = "Intel D410PT",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
+   DMI_MATCH(DMI_BOARD_NAME, "D410PT"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "Intel D425KT",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
+   DMI_MATCH(DMI_BOARD_NAME, "D425KT"),
+   },
+   },
+   {
+   .callback = intel_no_lvds_dmi_callback,
.ident = "Supermicro X7SPA-H",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"),

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

Re: [Intel-gfx] [PATCH] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Greg KH]

On Sun, Oct 27, 2013 at 04:13:42PM +, Rob Pearce wrote:
> From: Rob Pearce 
> 
> The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
> having LVDS but the hardware is not populated. This patch adds them to
> the list of such systems. Patch is against 3.11.4
> 
> Signed-off-by: Rob Pearce 
> ---
> Patch revised to match the D425KT exactly as the D425KTW does have LVDS. 
> According to Intel's documentation, the D410PTL and D410PLTW don't.

Any reason you don't want this in the stable tree as well?

thanks,

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

Re: [Intel-gfx] [PATCH v2] drm/i915/vlv: enable HDMI audio for Valleyview2

[Daniel Vetter]

On Wed, Oct 23, 2013 at 07:08:11PM -0400, mengdong@intel.com wrote:
> From: Mengdong Lin 
> 
> This patch defines audio configuration registers and adds audio enabling code
> for Valleyview2.
> 
> Signed-off-by: Mengdong Lin 
> Reviewed-by: Jesse Barnes 

[snip]

> @@ -6905,8 +6910,19 @@ static void ironlake_write_eld(struct drm_connector 
> *connector,
>  
>   DRM_DEBUG_DRIVER("ELD on pipe %c\n", pipe_name(pipe));
>  
> - i = I915_READ(aud_cntl_st);
> - i = (i >> 29) & DIP_PORT_SEL_MASK;  /* DIP_Port_Select, 0x1 
> = PortB */
> + if (IS_VALLEYVIEW(connector->dev))  {
> + struct intel_encoder *intel_encoder;
> + int port = 0;
> + intel_encoder = intel_attached_encoder(connector);
> + if (intel_encoder)
> + port = intel_ddi_get_encoder_port(intel_encoder);

This is a haswell specific function. Please use
enc_to_dig_port(intel_encoder)->port instead, which does the right thing
on all platforms for hdmi/dp ports.

Also, when poking for review feedback (like you've done in private to
Jesse and me) please consider next time around that:
- Never drop the public mailings lists. That way other people can also
  notice that a patch needs attention. Also Jesse's r-b tag is now lost
  since he replied to your private mail.
- Leave more than 8 hours of time for review to happen. In that time frame
  most of our team was off-duty. A few days is a good waiting time.

For the patch itself please add a patch changelog so that everyone knows
what changed from v1 to v2. This is doubly important since the review
happened off-list.

Finally please submit updated patches in reply to the original submission
or the patch review. Tightly grouping discussions like that helps with
managing the mail flood on a busy place like intel-gfx.

Furthermore v1 was rather decently broken with the wrong register offset
due to lack of the VLV_DISPLAY_BASE offset. So I'm wondering how solid
your testing is and whether we can automate this somehow to ensure we
cover all ugly combinations of ports and pipes. As-is I suspect you often
won't notice that things work simply due to settings left behind by the
bios or register default values matching what we want.

Maybe we could use the port CRC stuff to make sure that audio is actually
working ...

I won't block byt enabling on this, but expect me to be a royal pita for
the next platform enabling ;-)

Cheers, Daniel


> + i = port;
> + } else {
> + i = I915_READ(aud_cntl_st);
> + i = (i >> 29) & DIP_PORT_SEL_MASK;
> + /* DIP_Port_Select, 0x1 = PortB */
> + }
> +
>   if (!i) {
>   DRM_DEBUG_DRIVER("Audio directed to unknown port\n");
>   /* operate blindly on all ports */
> @@ -10195,7 +10211,8 @@ static void intel_init_display(struct drm_device *dev)
>   }
>   } else if (IS_G4X(dev)) {
>   dev_priv->display.write_eld = g4x_write_eld;
> - }
> + } else if (IS_VALLEYVIEW(dev))
> + dev_priv->display.write_eld = ironlake_write_eld;
>  
>   /* Default just returns -ENODEV to indicate unsupported */
>   dev_priv->display.queue_flip = intel_default_queue_flip;
> -- 
> 1.8.1.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] INTEL DRM DRIVERS : No LVDS hardware on Intel D410PT and D425KT

[Daniel Vetter]

On Sun, Oct 27, 2013 at 01:35:30PM +, Rob Pearce wrote:
> From: Rob Pearce  
> 
> These Intel D410PT and D425KT Mini-ITX desktop boards both show up as
> having LVDS but the hardware is not populated. This patch adds them to
> the list of such systems. Tested against 3.9.10 and 3.11.4
> 
> Signed-off-by: Rob Pearce 
> ---
> diff -uprN -X linux-3.9.10/Documentation/dontdiff 
> linux-3.9.10/drivers/gpu/drm/i915/intel_lvds.c 
> linux-3.9.10-ovs/drivers/gpu/drm/i915/intel_lvds.c
> --- linux-3.9.10/drivers/gpu/drm/i915/intel_lvds.c   2013-10-22 
> 19:00:30.0 +0100
> +++ linux-3.9.10-ovs/drivers/gpu/drm/i915/intel_lvds.c   2013-10-22 
> 18:58:56.0 +0100
> @@ -843,6 +843,22 @@
>   },
>   {
>   .callback = intel_no_lvds_dmi_callback,
> + .ident = "Intel D410PT",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
> + DMI_MATCH(DMI_BOARD_NAME, "D410PT"),
> + },
> + },
> + {
> + .callback = intel_no_lvds_dmi_callback,
> + .ident = "Intel D425KT",
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
> + DMI_MATCH(DMI_BOARD_NAME, "D425KT"),

At least this one here has a KTW variant with lvds connector. I think we
need a DMI_EXACT_MATCH. I haven't found out whether the D410PT board also
has such a cousin, so please digg in a bit for me.

Thanks, Daniel

> + },
> + },
> + {
> + .callback = intel_no_lvds_dmi_callback,
>   .ident = "Supermicro X7SPA-H",
>   .matches = {
>   DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"),
> 

-- 
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/4] drm/i915: Remove WaFbcDisableDpfcClockGating on HSW

[Daniel Vetter]

On Fri, Oct 25, 2013 at 03:27:50PM -0200, Paulo Zanoni wrote:
> 2013/10/24 Ben Widawsky :
> > Production HSW does not need it. I confirmed this with Art.
> >
> > Signed-off-by: Ben Widawsky 
> 
> I just hope these things don't start uncovering bugs :)
> 
> Reviewed-by: Paulo Zanoni 

Merged the first 2 patches of this series. Not sure what to do with the
other two, since fbc is essentially disabled on pre-hsw. And no one seems
to really work on it :( So I only see minimal reasons to frob with it ...
-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] ddccontrol doesn't work on the new kernel

[dbz]

 Hello, Bruno

Thank you for your answer!

Yes, I use integrated on-chip video (Intel Core i5-2500K CPU) and yes, seems 
both kernels use the same modules.
But unhappily from your answer I don't understand what can I do to try to get 
working ddccontrol on my system.

If you need some additional info about my system tell me what do you need and I 
give it to you immediately :)
Thank you one more time!

Saturday, Oct. 26, 2013, 12:01 +02:00 from Bruno Prémont 
:
>CCing intel-gfx as it is related to intel GPU driver and might get missed
>by intel developers on LKML.
>
>Looking at the linked pastebins ddcontrol seems to make use of the same
>i2c/DDC line but getting different results.
>
>Surprising info I see in dmesg, that does apply to both kernels, is
>that uvesafb attaches intel GPU *after* i915/KMS has done so.
>Both i915 and uvesafb seem to be modular.
>
>Bruno
>
>
>On Fri, 25 October 2013 dbz < divide_by_z...@mail.ru > wrote:
>> Hi, guys and girls!
>> 
>> I have a strange trouble with ddccontrol that I cannot identify and solve
>> for about a month, so I hope you'll be able to help me.
>> 
>> So, I'm using LMDE system ( http://linuxmint.com/start/debian/ ). Initially
>> the kernel was 3.2.32, and ddccontrol worked perfectly with my Philips
>> 232E2SB. I was able to change monitor brightness through ddccontrol
>> commands and I was really happy :)
>> 
>> Then I upgraded my system to Update Pack 7, and the new kernel became of
>> version 3.10.5. On new kernel ddccontrol doesn't work anymore, but it still
>> works on the old one (so this isn't software issue).
>> 
>> I have checked kernel configs - for the old kernel and for the new one.
>> Both configs are identical at i2c sections. I've tried to use old (3.2.32's
>> one) config with the new kernel, but there was no success.
>> 
>> To be absolutely sure that the problem isn't in the this specific kernel
>> version (3.10.5), I've downloaded the latest one (3.11.3) from kernel.org and
>> tried to use old config on this new kernel, but the issue is still
>> reproducing...
>> 
>> It would be great if you can give me right direction on this issue, 'cause
>> I don't know what to do now... I really need new kernel and ability to use
>> ddccontrol.
>> 
>> P.S. Additional info:
>> 
>> The output of 'i2cdetect -l' on the old kernel (3.2.32):
>>  http://pastebin.com/SqDPcwS9
>> The same on the new one (3.10.5):  http://pastebin.com/YCTmX90m
>> 
>> The output of 'ddccontrol -p' on the old kernel (3.2.32):
>>  http://pastebin.com/QL0fAZVC
>> The same on the new one (3.10.5):  http://pastebin.com/vZ4bALmt
>> 
>> And dmesg outputs for both 3.2.32 and 3.10.5 kernels:
>> - 3.2.32:  http://pastebin.com/7ijujvkA
>> - 3.10.5:  http://pastebin.com/t1wdKrAd
>> 
>> I really need someone's help with ddccontrol. It would be great if you or
>> someone else who do you know can help me :)
>> 
>> Thank you in advance!___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ddccontrol doesn't work on the new kernel

[Bruno Prémont]

CCing intel-gfx as it is related to intel GPU driver and might get missed
by intel developers on LKML.

Looking at the linked pastebins ddcontrol seems to make use of the same
i2c/DDC line but getting different results.

Surprising info I see in dmesg, that does apply to both kernels, is
that uvesafb attaches intel GPU *after* i915/KMS has done so.
Both i915 and uvesafb seem to be modular.

Bruno


On Fri, 25 October 2013 dbz  wrote:
> Hi, guys and girls!
> 
> I have a strange trouble with ddccontrol that I cannot identify and solve
> for about a month, so I hope you'll be able to help me.
> 
> So, I'm using LMDE system (http://linuxmint.com/start/debian/). Initially
> the kernel was 3.2.32, and ddccontrol worked perfectly with my Philips
> 232E2SB. I was able to change monitor brightness through ddccontrol
> commands and I was really happy :)
> 
> Then I upgraded my system to Update Pack 7, and the new kernel became of
> version 3.10.5. On new kernel ddccontrol doesn't work anymore, but it still
> works on the old one (so this isn't software issue).
> 
> I have checked kernel configs - for the old kernel and for the new one.
> Both configs are identical at i2c sections. I've tried to use old (3.2.32's
> one) config with the new kernel, but there was no success.
> 
> To be absolutely sure that the problem isn't in the this specific kernel
> version (3.10.5), I've downloaded the latest one (3.11.3) from kernel.org and
> tried to use old config on this new kernel, but the issue is still
> reproducing...
> 
> It would be great if you can give me right direction on this issue, 'cause
> I don't know what to do now... I really need new kernel and ability to use
> ddccontrol.
> 
> P.S. Additional info:
> 
> The output of 'i2cdetect -l' on the old kernel (3.2.32):
> http://pastebin.com/SqDPcwS9
> The same on the new one (3.10.5): http://pastebin.com/YCTmX90m
> 
> The output of 'ddccontrol -p' on the old kernel (3.2.32):
> http://pastebin.com/QL0fAZVC
> The same on the new one (3.10.5): http://pastebin.com/vZ4bALmt
> 
> And dmesg outputs for both 3.2.32 and 3.10.5 kernels:
> - 3.2.32: http://pastebin.com/7ijujvkA
> - 3.10.5: http://pastebin.com/t1wdKrAd
> 
> I really need someone's help with ddccontrol. It would be great if you or
> someone else who do you know can help me :)
> 
> Thank you in advance!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [trivial] drm/i915: Convert straggling MCHBAR registers

[Daniel Vetter]

On Wed, Oct 23, 2013 at 09:54:41AM +0300, Jani Nikula wrote:
> On Wed, 23 Oct 2013, Ben Widawsky  wrote:
> > All our registers which are written through the MCHBAR are defined
> > descriptively as an offset to the MCHBAR. We had 3 outliers here.
> > Convert these as well so all registers which are offsets are MCHBAR can
> > be easily identified/found within the code.
> >
> > With this, convert DCLK to also follow this format.
> >
> > Signed-off-by: Ben Widawsky 
> 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-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 v3 4/4] drm/i915: rename i915_init_power_well to i915_init_power_domains

[Daniel Vetter]

On Fri, Oct 25, 2013 at 06:10:31PM -0200, Paulo Zanoni wrote:
> 2013/10/25 Imre Deak :
> > Similarly rename the other related functions in the power domain
> > interface.
> >
> > Higher level driver code calling these functions knows only about power
> > domains, not the underlying power wells which may be different on
> > different platforms. Also these functions really init/cleanup/resume
> > power domains and only through that all related power wells, so rename
> > them accordingly.
> >
> > Signed-off-by: Imre Deak 
> 
> I agree with the "_domains" rename, I think it's an improvement, but
> since you're already renaming things, I have to drop my bikeshed: we
> have intel_init_power_{well,domains} and
> i915_init_power_{well,domains}. IMHO this is really super annoyingly
> confusing, because they sound like they do the same thing. I know it's
> not your fault, but while you're at it, could you please propose names
> to unconfuse this?
> 
> i915_init_power_well takes care of initializing the structs and
> pointers, while intel_init_power_well is the only one that touches
> hardware. A possible suggestion:
> 
> - i915_init_power_well becomes intel_init_power_domains (just because
> I don't like the "i915_" prefix, since the PM code uses "intel_" for
> everything).
> - i915_remove_power_well becomes intel_remove_power_domains (to match
> the one above)
> - intel_init_power_well becomes intel_init_power_domains_hardware or
> intel_init_power_wells (since on the HW these things are actually
> called "power wells") or intel_init_hw_power_wells (to combine both
> suggestions)

The pattern we have thus far is $prefix_$block_init and
$prefix_$block_init_hw. Occasionally the $block is at the end, but for
cases where we have both an init and an init_hw function I think putting
the init[_hw] at the end to make it stick out more is better.

Just my 2 bikesheds ;-)
-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 v2 2/2] drm/i915: set HDMI pixel clock in audio configuration

[Daniel Vetter]

On Thu, Oct 24, 2013 at 11:59:35AM +0200, David Härdeman wrote:
> It should also be noted that manually hard-coding the pixel clock
> value to an obviously incorrect value will also cause the Pioneer
> receiver to do the right thing (I assume it will ignore the
> incorrect value and calculate it on the fly) - that would point
> towards some kind of bug / hardware incompatibility in the Pioneer
> receiver. But I agree that the receiver *does* work with other
> hardware that I've tried.
> 
> Attempts to contact Pioneer have been fruitless so far. Maybe Intel
> would have better luck there...

The hw has shipped, so usually that means you're out of luck. Maybe we
simply needs to start adding eld quirks to EDIDs ...
-Daniel

> 
> On 2013-10-24 11:07, Jasper Smet wrote:
> >Although i know it also happens in windows, the one particular thing i
> >am 'fiddling' with is that when i try the receiver with an nvidia or
> >amd apu (ion, e-450 trough hdmi) with my pioneer receiver audio works
> >fine with 44100hz at the 1080p@50/60 modes. Only with intel i need to
> >force upstreaming to 48000hz.
> >
> >So are we really sure this is a bug with the receiver or still
> >something wrong with the driver / pixel clock issue?
> >
> >Is there anything else we i do to help ?
> >
> >On Wed, Oct 16, 2013 at 11:34 AM, Jani Nikula 
> >wrote:
> >
> >>The HDMI audio expects HDMI pixel clock to be set in the audio
> >>configuration. We've currently just set 0, using 25.2 / 1.001 kHz
> >>frequency, which fails with some modes.
> >>
> >>v2: Now with a commit message.
> >>
> >>Reference:
> >>
> >http://mid.gmane.org/cagpeb3ep1lrzetpxhgrfbdqr5ts2tac8gcukwwuguf1u5ny...@mail.gmail.com
> >>[1]
> >>Reference: http://mid.gmane.org/20130206213533.ga16...@hardeman.nu
> >>Reported-by: David Härdeman 
> >>Reported-by: Jasper Smet 
> >>Tested-by: Jasper Smet 
> >>Signed-off-by: Jani Nikula 
> >>---
> >> drivers/gpu/drm/i915/i915_reg.h      |   12 -
> >> drivers/gpu/drm/i915/intel_display.c |   48
> >>+++---
> >> 2 files changed, 55 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >>b/drivers/gpu/drm/i915/i915_reg.h
> >>index 13153c3..3266819 100644
> >>--- a/drivers/gpu/drm/i915/i915_reg.h
> >>+++ b/drivers/gpu/drm/i915/i915_reg.h
> >>@@ -4875,7 +4875,17 @@
> >> #define   AUD_CONFIG_LOWER_N_SHIFT             4
> >> #define   AUD_CONFIG_LOWER_N_VALUE             (0xfff <<
> >>4)
> >> #define   AUD_CONFIG_PIXEL_CLOCK_HDMI_SHIFT    16
> >>-#define   AUD_CONFIG_PIXEL_CLOCK_HDMI          (0xf << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK     (0xf << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_25175    (0 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_25200    (1 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_27000    (2 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_27027    (3 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_54000    (4 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_54054    (5 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_74176    (6 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_74250    (7 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_148352   (8 << 16)
> >>+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_148500   (9 << 16)
> >> #define   AUD_CONFIG_DISABLE_NCTS              (1 << 3)
> >>
> >> /* HSW Audio */
> >>diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>b/drivers/gpu/drm/i915/intel_display.c
> >>index 55740f2..a097f84 100644
> >>--- a/drivers/gpu/drm/i915/intel_display.c
> >>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>@@ -6722,6 +6722,44 @@ static int intel_crtc_mode_set(struct
> >>drm_crtc *crtc,
> >>        return 0;
> >> }
> >>
> >>+static struct {
> >>+       int clock;
> >>+       u32 config;
> >>+} hdmi_audio_clock[] = {
> >>+       { DIV_ROUND_UP(25200 * 1000, 1001),
> >>AUD_CONFIG_PIXEL_CLOCK_HDMI_25175 },
> >>+       { 25200, AUD_CONFIG_PIXEL_CLOCK_HDMI_25200 }, /* default
> >>per bspec */
> >>+       { 27000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27000 },
> >>+       { 27000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27027
> >>},
> >>+       { 54000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54000 },
> >>+       { 54000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54054
> >>},
> >>+       { DIV_ROUND_UP(74250 * 1000, 1001),
> >>AUD_CONFIG_PIXEL_CLOCK_HDMI_74176 },
> >>+       { 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
> >>+       { DIV_ROUND_UP(148500 * 1000, 1001),
> >>AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 },
> >>+       { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> >>+};
> >>+
> >>+/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> >>+static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode
> >>*mode)
> >>+{
> >>+       int i;
> >>+
> >>+       for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> >>+               if (mode->clock ==
> >>hdmi_audio_clock[i].clock)
> >>+                       break;
> >>+       }
> >>+
> >>+       if (i == ARRAY_SIZE(hdmi_audio_clock)) {
> >>+               DRM_DEBUG_KMS("HDMI audi

Re: [Intel-gfx] [PATCH 7/7] drm/i915: add i915_get_reset_stats_ioctl

[Daniel Vetter]

On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote:
> Since the Mesa merge window is closing soon, I'm finally getting back on
> this.  I've pushed a rebase of my old Mesa branch to my fd.o repo
> 
> http://cgit.freedesktop.org/~idr/mesa/log/?h=robustness3
> 
> I have a couple questions...
> 
> 1. Has any of this landed an a kernel tree anywhere?

Afaik everything but the actual ioctl and i-g-t testcase has landed.

> 2. Has any support code landed in a libdrm tree anywhere?

Dunno whether Mika has libdrm patches. Since mesa is the only expected
user I'd just go with putting the ioctl wrapper (using the drmIoctl
helper) into mesa itself, that get rids of a dep for merging this support.

> 3. What method should I use to detect that the kernel has support?  In
> early discussions, reset notification was only going to be available on
> some GPUs, so there was a getparam to detect actual availability.  I
> guess now it's just based on kernel version?

Usually we add a new feature flag to get get_param ioctl if there's no
natural way otherwise for userspace to figure this out (usually by calling
the new ioctl and disabling the feature if that doesn't work).
-Daniel

> 
> It looks like I should just need to update df87cdd and 61dad8e in my
> Mesa tree.
> 
> On 07/03/2013 07:22 AM, Mika Kuoppala wrote:
> > This ioctl returns reset stats for specified context.
> > 
> > The struct returned contains context loss counters.
> > 
> > reset_count:all resets across all contexts
> > batch_active:   active batches lost on resets
> > batch_pending:  pending batches lost on resets
> > 
> > v2: get rid of state tracking completely and deliver only counts. Idea
> > from Chris Wilson.
> > 
> > v3: fix commit message
> > 
> > v4: default context handled inside i915_gem_contest_get_hang_stats
> > 
> > v5: reset_count only for priviledged process
> > 
> > v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson)
> > 
> > v7: context hang stats never returns NULL
> > 
> > Signed-off-by: Mika Kuoppala 
> > Cc: Ian Romanick 
> > Cc: Chris Wilson 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c |1 +
> >  drivers/gpu/drm/i915/i915_drv.c |   34 ++
> >  drivers/gpu/drm/i915/i915_drv.h |2 ++
> >  include/uapi/drm/i915_drm.h |   17 +
> >  4 files changed, 54 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 0e22142..d1a006f 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1889,6 +1889,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
> > DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE, 
> > i915_gem_context_create_ioctl, DRM_UNLOCKED),
> > DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY, 
> > i915_gem_context_destroy_ioctl, DRM_UNLOCKED),
> > DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_UNLOCKED),
> > +   DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS, i915_get_reset_stats_ioctl, 
> > DRM_UNLOCKED),
> >  };
> >  
> >  int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 33cb973..0d4e3a8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1350,3 +1350,37 @@ int i915_reg_read_ioctl(struct drm_device *dev,
> >  
> > return 0;
> >  }
> > +
> > +int i915_get_reset_stats_ioctl(struct drm_device *dev,
> > +  void *data, struct drm_file *file)
> > +{
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > +   struct drm_i915_reset_stats *args = data;
> > +   struct i915_ctx_hang_stats *hs;
> > +   int ret;
> > +
> > +   if (args->ctx_id == 0 && !capable(CAP_SYS_ADMIN))
> > +   return -EPERM;
> > +
> > +   ret = mutex_lock_interruptible(&dev->struct_mutex);
> > +   if (ret)
> > +   return ret;
> > +
> > +   hs = i915_gem_context_get_hang_stats(dev, file, args->ctx_id);
> > +   if (IS_ERR(hs)) {
> > +   mutex_unlock(&dev->struct_mutex);
> > +   return PTR_ERR(hs);
> > +   }
> > +
> > +   if (capable(CAP_SYS_ADMIN))
> > +   args->reset_count = i915_reset_count(&dev_priv->gpu_error);
> > +   else
> > +   args->reset_count = 0;
> > +
> > +   args->batch_active = hs->batch_active;
> > +   args->batch_pending = hs->batch_pending;
> > +
> > +   mutex_unlock(&dev->struct_mutex);
> > +
> > +   return 0;
> > +}
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1def049..0ca98fa 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2021,6 +2021,8 @@ extern int intel_enable_rc6(const struct drm_device 
> > *dev);
> >  extern bool i915_semaphore_is_enabled(struct drm_device *dev);
> >  int i915_reg_read_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file);
> > +int i915_get_reset_stats_ioctl(