[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: i2c/gpio (rev3)

[Patchwork]

== Summary ==

Series 3075v3 drm/i915/dsi: i2c/gpio
2016-02-04T16:55:25.384210 
http://patchwork.freedesktop.org/api/1.0/series/3075/revisions/3/mbox/
Applying: drm/i915/dsi: defend gpio table against out of bounds access
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
Applying: drm/i915/dsi: don't pass arbitrary data to sideband
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
Patch failed at 0002 drm/i915/dsi: don't pass arbitrary data to sideband

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

Re: [Intel-gfx] [RFC 01/29] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Zhiyuan Lv]

Hi Chris,

On Fri, Jan 29, 2016 at 04:48:07PM +, Chris Wilson wrote:
> On Fri, Jan 29, 2016 at 03:57:09PM +0200, Joonas Lahtinen wrote:
> > Hi,
> > 
> > TL;DR Overall, we have same problem as with the scheduler series, there
> > is too much placeholder stuff for easy review. Just squash enough code
> > into one commit so it actually does something logical that can be
> > reviewed and then extend it later. Then it can be reviewed and pushed.
> > Just splitting the code down to achieve smaller patches is not the
> > right thing to do.
> > 
> > Comments on the overall code: You need to document all header file
> > functions (in the source files), and it is good to document the static
> > functions within a file too, to make future maintenance easier.
> > 
> > It is not about splitting the code down to small chunks, but splitting
> > it down to small *logical* chunks. It doesn't make sense to commit
> > dozens of empty bodied functions for review, and then later add their
> > code.
> > 
> > If you add functions, only add them at a patch that takes them into use
> > too, unless we're talking about general purpose shared code. And also
> > remember to add the function body and documentation header. If you
> > simply add a "return 0;" or similar function body, do add a comment to
> > why the function does not exist and when it will.
> > 
> > Then, there is a trend of having a boolean return values in the code.
> > When possible, it should rather be int and the cause for failure should
> > be propagated from the last level all the way to up (-ENOMEN etc.).
> > This way debugging becomes easier and if new error conditions appear,
> > there is less of a maintenance burden to add the propagation later.
> > 
> > Finally, make sure to look at the existing driver parts and
> > https://www.kernel.org/doc/Documentation/CodingStyle
> > for proper coding style. There are lots of whitespace fixes needed in
> > this series, like array initializations.
> > 
> > I hope to see this first patch rerolled so that you squash some of the
> > later commits into it so that all functions have a body and you add
> > documentation for the functions so I can both see what it should do and
> > what it actually does. Only reroll the first patch, to keep the
> > iterative step smaller. Lets only then continue with the rest of the
> > series once we've reached a consensus on the formatting and style
> > basics.
> > 
> > See more comments below.
> 
> I'm glad you did the nitpicking. As far as the integration goes, on the
> whole I'm happy with the way it is structured and the reuse of existing
> code. I tried to attack various aspects of the GVT contexts and came to
> the conclusion I couldn't suggest a better approach (though maybe
> tomorrow!). A few bits and pieces I got lost trying to pull together
> (in particular like how we do is read back through the GTT entries
> performed, the hypervisor_read_va abstraction iirc) and would appreciate
> having a branch available to get the complete picture.

I pushed the RFC code into below repo:

https://github.com/01org/Igvtg-kernel.git

Branch: gvt-upstream-rfc

Thanks for review and look forward to more comments!

Regards,
-Zhiyuan

> -Chris
> -- 
> 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] drm/i915: Fix to allow render compression on primary plane of PIPEB

[Thulasimani, Sivakumar]

not sure how this can be pushed separately even if approved at present.
why not push this as part of new patch set of the RC patches ?

but ignoring the dependency this is fine.
Reviewed-by: Sivakumar Thulasimani 

On 2/4/2016 11:44 AM, Mayuresh Gharpure wrote:

Currently, a flip with render compression enabled is failing on primary
plane of HDMI panel which is driven by PIPEB, this issue is fixed with
this patch

Change-Id: I197fe61faffad9da58733ed3f0e8cf6ef8640af7
Signed-off-by: Mayuresh Gharpure 
---
Please note that this patch depends on following patch:
https://patchwork.freedesktop.org/patch/67448/

Current patch is a bug fix on the above mentioned patch
  drivers/gpu/drm/i915/intel_display.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4b23ec2..f8485fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12777,10 +12777,6 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
  
  		if (fb && to_intel_plane_state(plane_state)->

render_comp_enable) {
-   if (to_intel_plane(plane)->plane != PLANE_A) {
-   DRM_DEBUG_KMS("RC supported only on planes 1 & 
2\n");
-   return -EINVAL;
-   }
ret = skl_check_compression(dev,
to_intel_plane_state(plane_state),
intel_crtc->pipe, crtc->x, crtc->y);
@@ -15088,6 +15084,7 @@ static int skl_check_compression(struct drm_device *dev,
enum pipe pipe, int x, int y)
  {
struct drm_framebuffer *fb = plane_state->base.fb;
+   struct drm_plane *plane = plane_state->base.plane;
int x_offset;
int src_w = drm_rect_width(&plane_state->src) >> 16;
  
@@ -15127,6 +15124,13 @@ static int skl_check_compression(struct drm_device *dev,

return -EINVAL;
}
  
+	if (!(plane->type == DRM_PLANE_TYPE_PRIMARY ||

+   (plane->type == DRM_PLANE_TYPE_OVERLAY &&
+   to_intel_plane(plane)->plane == PLANE_A))) {
+   DRM_DEBUG_KMS("RC supported only on planes 1 & 2\n");
+   return -EINVAL;
+   }
+
if (intel_rotation_90_or_270(plane_state->base.rotation)) {
DRM_DEBUG_KMS("RC support only with 0/180 degree rotation\n");
return -EINVAL;


___
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: Set invert bit for hpd based on VBT

[Thulasimani, Sivakumar]

On 2/4/2016 5:59 PM, Jani Nikula wrote:

On Thu, 04 Feb 2016, Shubhangi Shrivastava  
wrote:

This patch sets the invert bit for hpd detection for each port
based on vbt configuration. since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.

Signed-off-by: Sivakumar Thulasimani 
Signed-off-by: Durgadoss R 
Signed-off-by: Shubhangi Shrivastava 
---
  drivers/gpu/drm/i915/i915_irq.c | 49 +
  drivers/gpu/drm/i915/i915_reg.h |  9 
  2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 25a8937..305e6dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3424,6 +3424,54 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
  }
  
+/*

+ * For BXT invert bit has to be set based on AOB design
+ * for HPD detection logic, update it based on VBT fields.
+ */
+static void bxt_hpd_set_invert(struct drm_device *dev, u32 hotplug_port)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int i, reg_val, val = 0;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+
+   /* Proceed only if invert bit is set */
+   if (dev_priv->vbt.child_dev[i].common.hpd_invert == 0)
+   continue;
+
+   /*
+* Convert dvo_port to PORT_X and set appropriate bit
+* only if hotplug is enabled on that port
+*/
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+   case DVO_PORT_DPA:
+   case DVO_PORT_HDMIA:
+   if (hotplug_port & BXT_DE_PORT_HP_DDIA)
+   val |= BXT_DDIA_HPD_INVERT;
+   break;
+   case DVO_PORT_DPB:
+   case DVO_PORT_HDMIB:
+   if (hotplug_port & BXT_DE_PORT_HP_DDIB)
+   val |= BXT_DDIB_HPD_INVERT;
+   break;
+   case DVO_PORT_DPC:
+   case DVO_PORT_HDMIC:
+   if (hotplug_port & BXT_DE_PORT_HP_DDIC)
+   val |= BXT_DDIC_HPD_INVERT;
+   break;
+   default:
+   DRM_ERROR("HPD invert set for invalid dvo port %d\n",
+  dev_priv->vbt.child_dev[i].common.dvo_port);
+   break;
+   }
+   }
+   reg_val = I915_READ(BXT_HOTPLUG_CTL);
+   DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x val:%x\n",
+   reg_val, hotplug_port, val);
+   reg_val &= ~BXT_DDI_HPD_INVERT_MASK;
+   I915_WRITE(BXT_HOTPLUG_CTL, reg_val | val);
+}

No, we don't want this here. Separate VBT parsing from the rest of the
logic. See [1] for some directions where I want to take this type of
things.

hmm understood, will add intel_bios_requires_invert(dev, port)
and change the logic above to
if (intel_bios_requires_invert(dev,port)
val |= port;
hope this should be fine.

BR,
Jani.

[1] http://mid.gmane.org/cover.1452541881.git.jani.nik...@intel.com




+
  static void spt_hpd_irq_setup(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3494,6 +3542,7 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
PORTA_HOTPLUG_ENABLE;
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+   bxt_hpd_set_invert(dev, enabled_irqs);
  }
  
  static void ibx_irq_postinstall(struct drm_device *dev)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a98889..01bd3c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5936,6 +5936,15 @@ enum skl_disp_power_wells {
  #define GEN8_PCU_IIR _MMIO(0x444e8)
  #define GEN8_PCU_IER _MMIO(0x444ec)
  
+/* BXT hotplug control */

+#define BXT_HOTPLUG_CTL_MMIO(0xC4030)
+#define BXT_DDIA_HPD_INVERT(1 << 27)
+#define BXT_DDIC_HPD_INVERT(1 << 11)
+#define BXT_DDIB_HPD_INVERT(1 << 3)
+#define BXT_DDI_HPD_INVERT_MASK(BXT_DDIA_HPD_INVERT | \
+BXT_DDIB_HPD_INVERT | \
+BXT_DDIC_HPD_INVERT)
+
  #define ILK_DISPLAY_CHICKEN2  _MMIO(0x42004)
  /* Required on all Ironlake and Sandybridge according to the B-Spec. */
  #define  ILK_ELPIN_409_SELECT (1 << 25)


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

Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation

[Lukas Wunner]

Hi,

On Thu, Feb 04, 2016 at 09:21:17AM +, Li, Weinan Z wrote:
> We still need this patch. Seems 54632abe8ca3 ("drm/i915: Fix oops caused by 
> fbdev initialization
> failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
> initialization fails") this 2 patches can???t cover this case. It???s access 
> ifbdev->fb before the initialization
> finished, but not initialization failed. If don???t have any other patches or 
> code update relative, it may still have in 4.5.

Okay, I see.

> 
> add info NULL check should be better, it is also initialized in the async 
> queue
> >   info = ifbdev->helper.fbdev;
> > + if (info == NULL)
> > +return false;
> >   if (!info->screen_base)

So if there's indeed a race between fbdev initialization and the call to
intel_fbdev_restore_mode() (on lastclose), there's more that can go awry:
- intel_fbdev_restore_mode() dereferences ifbdev->fb->obj
- it calls __drm_atomic_helper_set_config() which WARNs if ifbdev->fb is NULL
- it calls drm_fb_helper_set_par() which dereferences ifbdev->helper.fbdev

Instead of checking all that it's probably simpler to call
async_synchronize_full() at the beginning of intel_fbdev_restore_mode(),
as Li Weinan suggested. I'll submit the corresponding one-liner patch
tomorrow if noone else does.

Chris' patch also modified intel_fbdev_set_suspend() as well as
intel_fbdev_output_poll_changed(), not sure if these are racy as well.
At least the stack traces posted by Li Weinan and Gustav Fägerlind
only indicate that lastclose is racy.

Best regards,

Lukas

> From: Li, Weinan Z
> Sent: Thursday, February 04, 2016 10:34 AM
> To: 'gustav.fagerl...@gmail.com'; Lukas Wunner
> Cc: Chris Wilson; 
> intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or 
> failed initialisation
> 
> Thanks for your quick response.
> Yes it is not easily be reproduced in native. In  iVGT we startup several VMs 
>  simultaneously, it can be reproduced in several cycles, upon 1/10 fail rate.
> Need to use GUI mode but not text mode to reproduce this issue.
> 
> BRs,
> Weinan Li
> 
> 
> From: Gustav Fägerlind [mailto:gustav.fagerl...@gmail.com]
> Sent: Thursday, February 04, 2016 1:08 AM
> To: Lukas Wunner
> Cc: Chris Wilson; 
> intel-gfx@lists.freedesktop.org; Li, 
> Weinan Z
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or 
> failed initialisation
> 
> Cool, thank you.
> I dont believe I can easily reproduce it, it has only happend few times (and 
> i reboot my lappy >2 times per day).
> 
> //
> Gustav
> 
> 2016-02-03 14:25 GMT+01:00 Lukas Wunner 
> mailto:lu...@wunner.de>>:
> Hi,
> 
> On Wed, Feb 03, 2016 at 09:17:37AM +, Chris Wilson wrote:
> > If the initialisation fails, we may be left with a dangling pointer with
> > an incomplete fbdev structure.
> 
> This shouldn't happen with 4.5, the fbdev is now clobbered if initialization
> fails, the existing "if (dev_priv->fbdev)" checks should thus be sufficient.
> See 54632abe8ca3 ("drm/i915: Fix oops caused by fbdev initialization
> failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
> initialization fails").
> 
> Gustav Fagerlind and Li Weinan both reported this for 4.3. It would be
> interesting to know if it can be reproduced at all with 4.5-rc2.
> 
> Best regards,
> 
> Lukas
> 
> > Here we want to disable internal calls
> > into fbdev. Similarly, the initialisation may be slow and we haven't yet
> > enabled the fbdev (e.g. quick suspend or last-close before the async init
> > completes).
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> > Reported-by: "Li, Weinan Z" 
> > mailto:weinan.z...@intel.com>>
> > Signed-off-by: Chris Wilson 
> > mailto:ch...@chris-wilson.co.uk>>
> > ---
> >  drivers/gpu/drm/i915/intel_fbdev.c | 41 
> > --
> >  1 file changed, 26 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 09840f4380f9..6218bc5370a1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -114,6 +114,20 @@ static struct fb_ops intelfb_ops = {
> >   .fb_debug_leave = drm_fb_helper_debug_leave,
> >  };
> >
> > +static bool intel_fbdev_active(struct intel_fbdev *ifbdev)
> > +{
> > + struct fb_info *info;
> > +
> > + if (ifbdev == NULL)
> > + return false;
> > +
> > + info = ifbdev->helper.fbdev;
> > + if (!info->screen_base)
> > + return false;
> > +
> > + return info->state == FBINFO_STATE_RUNNING;
> > +}
> > +
> >  static int intelfb_alloc(struct drm_fb_helper *helper,
> >struct drm_fb_helper_surface_size *sizes)
> >  {
> > @@ -753,6 +767,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, 
> > int state, bool synchronous
> >   return;
> >
> >

Re: [Intel-gfx] [PATCH igt 4/9] igt/vc4_wait_bo: Add a test for VC4's wait-for-BO ioctl.

[Eric Anholt]

Daniel Stone  writes:

> Hi,
>
> On 3 February 2016 at 21:41, Eric Anholt  wrote:
>> +   ret = ioctl(fd, DRM_IOCTL_VC4_WAIT_BO, &arg);
>> +   igt_assert(ret == -1 && errno == EINVAL);
>
> A couple of nitpicks: all these should be either do_ioctl() for
> success, or do_ioctl_err() for failure, which not only cuts down the
> number of lines a bit, but also shows you the exact condition which
> occurred (e.g. it'll show that errno was -EBUSY rather than expected
> -EINVAL without having to round-trip through the reporter). Similarly,
> all your igt_assert(x == y) should be igt_assert_eq(x, y), or any of
> the igt_assert_{eq,neq} variants, e.g. _u32 for comparing uint32_t.
> You can also use do_or_die(foo) as shorthand for igt_assert_eq(foo,
> 0).
>
> With those addressed:
> Reviewed-by: Daniel Stone 

I converted everything but one of the ones in wait_bo, and pushed the
updated series to the vc4 branch of my tree.  I'll give it another
couple of days in case anyone else has review to do on the series.

Thanks!


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

Re: [Intel-gfx] [PATCH i-g-t] list-workarounds: Extend the script to Mesa

[Jani Nikula]

On Thu, 04 Feb 2016, "Kibey, Sameer"  wrote:
> Thanks for the input. I changed the subject prefix for this thread,
> let me know if you would like me to send a new email with "PATCH
> i-g-t" instead.

Not necessary; I meant to say, "for future reference".

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 corrupting memory on shutdown since 4.4?

[Chris Bainbridge]

I eventually traced the filesystem corruption to a bug in the Apple
firmware which can cause memory corruption after Linux is booted:
https://bugzilla.kernel.org/show_bug.cgi?id=111781

On 29 January 2016 at 12:37, Chris Wilson  wrote:
> The timer error is definitely interesting

The timer error bisected to a recent ACPI change. It causes visual
glitches in Firefox. https://lkml.org/lkml/2016/2/3/273
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] list-workarounds: Extend the script to Mesa

[Kibey, Sameer]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, February 04, 2016 10:37 AM
> To: Kibey, Sameer; intel-gfx@lists.freedesktop.org; mesa-
> d...@lists.freedesktop.org
> Cc: Sharp, Sarah A; Kibey, Sameer; Widawsky, Benjamin
> Subject: Re: [Intel-gfx] [PATCH] list-workarounds: Extend the script to Mesa
> 
> 
> FYI, for IGT patches, please do as instructed in CONTRIBUTING:
> 
> """
>   Please use --subject-prefix="PATCH i-g-t" so that i-g-t patches are easily
>   identified in the massive amount mails on intel-gfx. To ensure this is 
> always
>   done just run
> 
> git config format.subjectprefix "PATCH i-g-t"
> 
>   from within your i-g-t git checkout.
> """
> 
> BR,
> Jani.
> 

Thanks for the input. I changed the subject prefix for this thread, let me know 
if you would like me to send a new email with "PATCH i-g-t" instead. 

> On Thu, 04 Feb 2016, "Kibey, Sameer"  wrote:
> > Updated the list-workarounds script so that it can parse Mesa
> > directory if provided. Moved the common code to a separate function to
> > allow reuse for both kernel and mesa.
> >
> > The new command line is:
> > Usage: list-workarounds [options] path-to-kernel
> >-k path-to-kernel -m path-to-mesa
> >
> > The legacy usage is retained to avoid breaking backwards
> > compatibility. New parameters -k and -m are added for the new
> > behavior.
> >
> > Either kernel or mesa or both paths can be specified.
> > If path-to-mesa is invalid, error is reported.
> >
> > Signed-off-by: Sameer Kibey 
> > ---
> >  scripts/list-workarounds | 75
> > ++--
> >  1 file changed, 54 insertions(+), 21 deletions(-)
> >
> > diff --git a/scripts/list-workarounds b/scripts/list-workarounds index
> > d11b6a9..0b63541 100755
> > --- a/scripts/list-workarounds
> > +++ b/scripts/list-workarounds
> > @@ -18,7 +18,7 @@ def find_nth(haystack, needle, n):
> > return start
> >
> >  valid_platforms = ('ctg', 'elk', 'ilk', 'snb', 'ivb', 'vlv', 'hsw', 'bdw',
> > -  'chv', 'skl', 'bxt')
> > +  'chv', 'skl', 'bxt', 'kbl', 'byt')
> >  def parse_platforms(line, p):
> > l =  p.split(',')
> > for p in l:
> > @@ -65,9 +65,15 @@ def execute(cmd):
> > return out, err
> >
> >  def parse_options(args):
> > -   usage = "Usage: list-workarounds [options] path-to-kernel"
> > +   usage = "Usage: list-workarounds [options] path-to-kernel -k path-
> to-kernel -m path-to-mesa"
> > parser = optparse.OptionParser(usage, version=1.0)
> >
> > +   parser.add_option("-k", "--kernel-path", dest="kernel_path",
> default=None,
> > + help="path to kernel")
> > +
> > +   parser.add_option("-m", "--mesa-path", dest="mesa_path",
> default=None,
> > + help="path to mesa")
> > +
> > parser.add_option("-v", "--verbose", action="store_true",
> >   dest="verbose", default=False,
> >   help="be more verbose")
> > @@ -76,30 +82,14 @@ def parse_options(args):
> >   help="List workarounds for the specified platform")
> >
> > (options, args) = parser.parse_args()
> > -
> > return (options, args)
> >
> > -if __name__ == '__main__':
> > -   (options, args) = parse_options(sys.argv[1:])
> > -   verbose = options.verbose
> > -
> > -   if not len(args):
> > -   sys.stderr.write("error: A path to a kernel tree is
> required\n")
> > -   sys.exit(1)
> > -
> > -   kernel_path = args[0]
> > -   kconfig = os.path.join(kernel_path, 'Kconfig')
> > -   if not os.path.isfile(kconfig):
> > -   sys.stderr.write("error: %s does not point to a kernel tree \n"
> > -% kernel_path)
> > -   sys.exit(1)
> > -
> > -   i915_dir = os.path.join('drivers', 'gpu', 'drm', 'i915')
> > +def print_workarounds(code_path, driver_dir):
> > olddir = os.getcwd()
> > -   os.chdir(kernel_path)
> > +   os.chdir(code_path)
> > work_arounds, err = execute(['git', 'grep', '-n',
> >  '-e', 'W[aA][A-Z0-9][a-zA-Z0-9_]\+',
> > -i915_dir])
> > +driver_dir])
> > os.chdir(olddir)
> > if err:
> > print(err)
> > @@ -111,3 +101,46 @@ if __name__ == '__main__':
> > print("%s: %s" % (wa, ', '.join(workarounds[wa])))
> > elif options.platform in workarounds[wa]:
> > print(wa)
> > +
> > +
> > +if __name__ == '__main__':
> > +   (options, args) = parse_options(sys.argv)
> > +   verbose = options.verbose
> > +   kernel_path = None
> > +
> > +   if not len(args) and options.kernel_path == None and
> options.mesa_path == None:
> > +   sys.stderr.write("error: A path to either a kernel tree or
> Mesa is required\n")
> > +   sys.exit(1)
> > +
> > +   if len(args):
> > +   kernel_path = args[0]
> > +   elif options.kernel_path != None:
> > +   kernel_p

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
>> Skip v3 gpio element because the support is not there, and skip gpio
>> element on non-vlv because the sideband code is vlv specific.
>> 
>> v2: the gpio stuff is currently only supported on vlv (Ville)
>> 
>> Cc: drm-intel-fi...@lists.freedesktop.org
>> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 

And pushed to dinq, thanks for the review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index f4d303ee538b..bcc083db7632 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> *intel_dsi, const u8 *data)
>>  struct drm_device *dev = intel_dsi->base.base.dev;
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  
>> +if (dev_priv->vbt.dsi.seq_version >= 3)
>> +data++;
>> +
>>  gpio = *data++;
>>  
>>  /* pull up/down */
>> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> *intel_dsi, const u8 *data)
>>  goto out;
>>  }
>>  
>> +if (!IS_VALLEYVIEW(dev_priv)) {
>> +DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
>> +goto out;
>> +}
>> +
>> +if (dev_priv->vbt.dsi.seq_version >= 3) {
>> +DRM_DEBUG_KMS("GPIO element v3 not supported\n");
>> +goto out;
>> +}
>> +
>>  function = gtable[gpio].function_reg;
>>  pad = gtable[gpio].pad_reg;
>>  
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] list-workarounds: Extend the script to Mesa

[Jani Nikula]

FYI, for IGT patches, please do as instructed in CONTRIBUTING:

"""
  Please use --subject-prefix="PATCH i-g-t" so that i-g-t patches are easily
  identified in the massive amount mails on intel-gfx. To ensure this is always
  done just run

git config format.subjectprefix "PATCH i-g-t"

  from within your i-g-t git checkout.
"""

BR,
Jani.


On Thu, 04 Feb 2016, "Kibey, Sameer"  wrote:
> Updated the list-workarounds script so that it
> can parse Mesa directory if provided. Moved the
> common code to a separate function to allow
> reuse for both kernel and mesa.
>
> The new command line is:
> Usage: list-workarounds [options] path-to-kernel
>-k path-to-kernel -m path-to-mesa
>
> The legacy usage is retained to avoid breaking
> backwards compatibility. New parameters -k and
> -m are added for the new behavior.
>
> Either kernel or mesa or both paths can be specified.
> If path-to-mesa is invalid, error is reported.
>
> Signed-off-by: Sameer Kibey 
> ---
>  scripts/list-workarounds | 75 
> ++--
>  1 file changed, 54 insertions(+), 21 deletions(-)
>
> diff --git a/scripts/list-workarounds b/scripts/list-workarounds
> index d11b6a9..0b63541 100755
> --- a/scripts/list-workarounds
> +++ b/scripts/list-workarounds
> @@ -18,7 +18,7 @@ def find_nth(haystack, needle, n):
>   return start
>  
>  valid_platforms = ('ctg', 'elk', 'ilk', 'snb', 'ivb', 'vlv', 'hsw', 'bdw',
> -'chv', 'skl', 'bxt')
> +'chv', 'skl', 'bxt', 'kbl', 'byt')
>  def parse_platforms(line, p):
>   l =  p.split(',')
>   for p in l:
> @@ -65,9 +65,15 @@ def execute(cmd):
>   return out, err
>  
>  def parse_options(args):
> - usage = "Usage: list-workarounds [options] path-to-kernel"
> + usage = "Usage: list-workarounds [options] path-to-kernel -k 
> path-to-kernel -m path-to-mesa"
>   parser = optparse.OptionParser(usage, version=1.0)
>  
> + parser.add_option("-k", "--kernel-path", dest="kernel_path", 
> default=None,
> +   help="path to kernel")
> +
> + parser.add_option("-m", "--mesa-path", dest="mesa_path", default=None,
> +   help="path to mesa")
> +
>   parser.add_option("-v", "--verbose", action="store_true",
> dest="verbose", default=False,
> help="be more verbose")
> @@ -76,30 +82,14 @@ def parse_options(args):
> help="List workarounds for the specified platform")
>  
>   (options, args) = parser.parse_args()
> -
>   return (options, args)
>  
> -if __name__ == '__main__':
> - (options, args) = parse_options(sys.argv[1:])
> - verbose = options.verbose
> -
> - if not len(args):
> - sys.stderr.write("error: A path to a kernel tree is required\n")
> - sys.exit(1)
> -
> - kernel_path = args[0]
> - kconfig = os.path.join(kernel_path, 'Kconfig')
> - if not os.path.isfile(kconfig):
> - sys.stderr.write("error: %s does not point to a kernel tree \n"
> -  % kernel_path)
> - sys.exit(1)
> -
> - i915_dir = os.path.join('drivers', 'gpu', 'drm', 'i915')
> +def print_workarounds(code_path, driver_dir):
>   olddir = os.getcwd()
> - os.chdir(kernel_path)
> + os.chdir(code_path)
>   work_arounds, err = execute(['git', 'grep', '-n',
>'-e', 'W[aA][A-Z0-9][a-zA-Z0-9_]\+',
> -  i915_dir])
> +  driver_dir])
>   os.chdir(olddir)
>   if err:
>   print(err)
> @@ -111,3 +101,46 @@ if __name__ == '__main__':
>   print("%s: %s" % (wa, ', '.join(workarounds[wa])))
>   elif options.platform in workarounds[wa]:
>   print(wa)
> +
> +
> +if __name__ == '__main__':
> + (options, args) = parse_options(sys.argv)
> + verbose = options.verbose
> + kernel_path = None
> +
> + if not len(args) and options.kernel_path == None and options.mesa_path 
> == None:
> + sys.stderr.write("error: A path to either a kernel tree or Mesa 
> is required\n")
> + sys.exit(1)
> +
> + if len(args):
> + kernel_path = args[0]
> + elif options.kernel_path != None:
> + kernel_path = options.kernel_path
> +
> + if kernel_path != None:
> + # --- list Kernel workarounds if path is provided ---
> + kconfig = os.path.join(kernel_path, 'Kconfig')
> + if not os.path.isfile(kconfig):
> + sys.stderr.write("error: %s does not point to a kernel 
> tree \n"
> + % kernel_path)
> + sys.exit(1)
> +
> + i915_dir = os.path.join('drivers', 'gpu', 'drm', 'i915')
> + print ("List of workarounds found in kernel:")
> + print_workarounds(kernel_path, i915_dir)
> +
>

[Intel-gfx] [PATCH] list-workarounds: Extend the script to Mesa

[Kibey, Sameer]

Updated the list-workarounds script so that it
can parse Mesa directory if provided. Moved the
common code to a separate function to allow
reuse for both kernel and mesa.

The new command line is:
Usage: list-workarounds [options] path-to-kernel
   -k path-to-kernel -m path-to-mesa

The legacy usage is retained to avoid breaking
backwards compatibility. New parameters -k and
-m are added for the new behavior.

Either kernel or mesa or both paths can be specified.
If path-to-mesa is invalid, error is reported.

Signed-off-by: Sameer Kibey 
---
 scripts/list-workarounds | 75 ++--
 1 file changed, 54 insertions(+), 21 deletions(-)

diff --git a/scripts/list-workarounds b/scripts/list-workarounds
index d11b6a9..0b63541 100755
--- a/scripts/list-workarounds
+++ b/scripts/list-workarounds
@@ -18,7 +18,7 @@ def find_nth(haystack, needle, n):
return start
 
 valid_platforms = ('ctg', 'elk', 'ilk', 'snb', 'ivb', 'vlv', 'hsw', 'bdw',
-  'chv', 'skl', 'bxt')
+  'chv', 'skl', 'bxt', 'kbl', 'byt')
 def parse_platforms(line, p):
l =  p.split(',')
for p in l:
@@ -65,9 +65,15 @@ def execute(cmd):
return out, err
 
 def parse_options(args):
-   usage = "Usage: list-workarounds [options] path-to-kernel"
+   usage = "Usage: list-workarounds [options] path-to-kernel -k 
path-to-kernel -m path-to-mesa"
parser = optparse.OptionParser(usage, version=1.0)
 
+   parser.add_option("-k", "--kernel-path", dest="kernel_path", 
default=None,
+ help="path to kernel")
+
+   parser.add_option("-m", "--mesa-path", dest="mesa_path", default=None,
+ help="path to mesa")
+
parser.add_option("-v", "--verbose", action="store_true",
  dest="verbose", default=False,
  help="be more verbose")
@@ -76,30 +82,14 @@ def parse_options(args):
  help="List workarounds for the specified platform")
 
(options, args) = parser.parse_args()
-
return (options, args)
 
-if __name__ == '__main__':
-   (options, args) = parse_options(sys.argv[1:])
-   verbose = options.verbose
-
-   if not len(args):
-   sys.stderr.write("error: A path to a kernel tree is required\n")
-   sys.exit(1)
-
-   kernel_path = args[0]
-   kconfig = os.path.join(kernel_path, 'Kconfig')
-   if not os.path.isfile(kconfig):
-   sys.stderr.write("error: %s does not point to a kernel tree \n"
-% kernel_path)
-   sys.exit(1)
-
-   i915_dir = os.path.join('drivers', 'gpu', 'drm', 'i915')
+def print_workarounds(code_path, driver_dir):
olddir = os.getcwd()
-   os.chdir(kernel_path)
+   os.chdir(code_path)
work_arounds, err = execute(['git', 'grep', '-n',
 '-e', 'W[aA][A-Z0-9][a-zA-Z0-9_]\+',
-i915_dir])
+driver_dir])
os.chdir(olddir)
if err:
print(err)
@@ -111,3 +101,46 @@ if __name__ == '__main__':
print("%s: %s" % (wa, ', '.join(workarounds[wa])))
elif options.platform in workarounds[wa]:
print(wa)
+
+
+if __name__ == '__main__':
+   (options, args) = parse_options(sys.argv)
+   verbose = options.verbose
+   kernel_path = None
+
+   if not len(args) and options.kernel_path == None and options.mesa_path 
== None:
+   sys.stderr.write("error: A path to either a kernel tree or Mesa 
is required\n")
+   sys.exit(1)
+
+   if len(args):
+   kernel_path = args[0]
+   elif options.kernel_path != None:
+   kernel_path = options.kernel_path
+
+   if kernel_path != None:
+   # --- list Kernel workarounds if path is provided ---
+   kconfig = os.path.join(kernel_path, 'Kconfig')
+   if not os.path.isfile(kconfig):
+   sys.stderr.write("error: %s does not point to a kernel 
tree \n"
+   % kernel_path)
+   sys.exit(1)
+
+   i915_dir = os.path.join('drivers', 'gpu', 'drm', 'i915')
+   print ("List of workarounds found in kernel:")
+   print_workarounds(kernel_path, i915_dir)
+
+   # --- list mesa workarounds if path is provided ---
+   if options.mesa_path != None:
+   # reset workarounds array
+   workarounds = {}
+
+   mesa_path = options.mesa_path
+   i965_dir = os.path.join('src', 'mesa', 'drivers', 'dri', 'i965')
+   mesa_dir = os.path.join(mesa_path, i965_dir)
+   if not os.path.exists(mesa_dir):
+   sys.stderr.write("error: %s does not point to a valid 
mesa path \n"
+

Re: [Intel-gfx] [PATCH 8/8] drm/i915/dsi: Added the generic gpio sequence support and gpio table

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:56PM +0200, Jani Nikula wrote:
> From: Deepak M 
> 
> The generic gpio is sequence is parsed from the VBT and the
> GPIO table is updated with the North core, South core and
> SUS core elements.
> 
> v2: Move changes in sideband.c file to new patch(Jani), rebase
> v3: Moved the Macro`s to intel_dsi_panel_vbt.c (Jani)
> 
> v3 by Jani
> - rebase on previous patches
> - don't return null on errors
> 
> Signed-off-by: Deepak M 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Mmmh, the gpio table actually has some pretty scary stuff. We shouldn't
> trust the vbt not to clobber some of the GPIOs listed in the table!
> 
> Also, is this really vlv specific as noted by Ville? What about chv, not
> to mention bxt?!

Indeed, and IIRC during my last review I noticed that the number of pins
in each of these blocks doesn't actually match how many pins the
hardware has in theose blocks. So either this is just wrong even for VLV
or it's based on some other spec that no one has ever seen (since IIRC I
didn't see anything in the VBT spec about this stuff).

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 589 
> +++--
>  1 file changed, 548 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index de1966552a33..b85d935617ef 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -59,30 +59,360 @@ static inline struct vbt_panel *to_vbt_panel(struct 
> drm_panel *panel)
>  
>  #define NS_KHZ_RATIO 100
>  
> -#define GPI0_NC_0_HV_DDI0_HPD   0x4130
> -#define GPIO_NC_0_HV_DDI0_PAD   0x4138
> -#define GPIO_NC_1_HV_DDI0_DDC_SDA   0x4120
> -#define GPIO_NC_1_HV_DDI0_DDC_SDA_PAD   0x4128
> -#define GPIO_NC_2_HV_DDI0_DDC_SCL   0x4110
> -#define GPIO_NC_2_HV_DDI0_DDC_SCL_PAD   0x4118
> -#define GPIO_NC_3_PANEL0_VDDEN  0x4140
> -#define GPIO_NC_3_PANEL0_VDDEN_PAD  0x4148
> -#define GPIO_NC_4_PANEL0_BLKEN  0x4150
> -#define GPIO_NC_4_PANEL0_BLKEN_PAD  0x4158
> -#define GPIO_NC_5_PANEL0_BLKCTL 0x4160
> -#define GPIO_NC_5_PANEL0_BLKCTL_PAD 0x4168
> -#define GPIO_NC_6_PCONF00x4180
> -#define GPIO_NC_6_PAD   0x4188
> -#define GPIO_NC_7_PCONF00x4190
> -#define GPIO_NC_7_PAD   0x4198
> -#define GPIO_NC_8_PCONF00x4170
> -#define GPIO_NC_8_PAD   0x4178
> -#define GPIO_NC_9_PCONF00x4100
> -#define GPIO_NC_9_PAD   0x4108
> -#define GPIO_NC_10_PCONF0   0x40E0
> -#define GPIO_NC_10_PAD  0x40E8
> -#define GPIO_NC_11_PCONF0   0x40F0
> -#define GPIO_NC_11_PAD  0x40F8
> +#define MAX_GPIO_NUM_NC  26
> +#define MAX_GPIO_NUM_SC  128
> +#define MAX_GPIO_NUM 172
> +
> +#define HV_DDI0_HPD_GPIONC_0_PCONF0 0x4130
> +#define HV_DDI0_HPD_GPIONC_0_PAD0x4138
> +#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF0 0x4120
> +#define HV_DDI0_DDC_SDA_GPIONC_1_PAD0x4128
> +#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF0 0x4110
> +#define HV_DDI0_DDC_SCL_GPIONC_2_PAD0x4118
> +#define PANEL0_VDDEN_GPIONC_3_PCONF00x4140
> +#define PANEL0_VDDEN_GPIONC_3_PAD   0x4148
> +#define PANEL0_BKLTEN_GPIONC_4_PCONF0   0x4150
> +#define PANEL0_BKLTEN_GPIONC_4_PAD  0x4158
> +#define PANEL0_BKLTCTL_GPIONC_5_PCONF0  0x4160
> +#define PANEL0_BKLTCTL_GPIONC_5_PAD 0x4168
> +#define HV_DDI1_HPD_GPIONC_6_PCONF0 0x4180
> +#define HV_DDI1_HPD_GPIONC_6_PAD0x4188
> +#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF0 0x4190
> +#define HV_DDI1_DDC_SDA_GPIONC_7_PAD0x4198
> +#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF0 0x4170
> +#define HV_DDI1_DDC_SCL_GPIONC_8_PAD0x4178
> +#define PANEL1_VDDEN_GPIONC_9_PCONF00x4100
> +#define PANEL1_VDDEN_GPIONC_9_PAD   0x4108
> +#define PANEL1_BKLTEN_GPIONC_10_PCONF0  0x40E0
> +#define PANEL1_BKLTEN_GPIONC_10_PAD 0x40E8
> +#define PANEL1_BKLTCTL_GPIONC_11_PCONF0 0x40F0
> +#define PANEL1_BKLTCTL_GPIONC_11_PAD0x40F8
> +#define GP_INTD_DSI_TE1_GPIONC_12_PCONF00x40C0
> +#define GP_INTD_DSI_TE1_GPIONC_12_PAD   0x40C8
> +#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF00x41A0
> +#define HV_DDI2_DDC_SDA_GPIONC_13_PAD   0x41A8
> +#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF00x41B0
> +#define HV_DDI2_DDC_SCL_GPIONC_14_PAD   0x41B8
> +#define GP_CAMERASB00_GPIONC_15_PCONF0  0x4010
> +#define GP_CAMERASB00_GPIONC_15_PAD 0x4018
> +#define GP_CAMERASB01_GPIONC_16_PCONF0  0x4040
> +#define GP_CAMERASB01_GPIONC_16_PAD 0x4048
> +#define GP_CAMERASB02_GPIONC_17_P

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
> Skip v3 gpio element because the support is not there, and skip gpio
> element on non-vlv because the sideband code is vlv specific.
> 
> v2: the gpio stuff is currently only supported on vlv (Ville)
> 
> Cc: drm-intel-fi...@lists.freedesktop.org
> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index f4d303ee538b..bcc083db7632 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   struct drm_device *dev = intel_dsi->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (dev_priv->vbt.dsi.seq_version >= 3)
> + data++;
> +
>   gpio = *data++;
>  
>   /* pull up/down */
> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   goto out;
>   }
>  
> + if (!IS_VALLEYVIEW(dev_priv)) {
> + DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
> + goto out;
> + }
> +
> + if (dev_priv->vbt.dsi.seq_version >= 3) {
> + DRM_DEBUG_KMS("GPIO element v3 not supported\n");
> + goto out;
> + }
> +
>   function = gtable[gpio].function_reg;
>   pad = gtable[gpio].pad_reg;
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 07:22:30PM +0200, Jani Nikula wrote:
> On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> > On Thu, Feb 04, 2016 at 07:10:42PM +0200, Jani Nikula wrote:
> >> On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> >> > On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
> >> >> Skip v3 gpio element because the support is not there, and skip gpio
> >> >> element on non-vlv because the sideband code is vlv specific.
> >> >> 
> >> >> v2: the gpio stuff is currently only supported on vlv (Ville)
> >> >> 
> >> >> Cc: drm-intel-fi...@lists.freedesktop.org
> >> >> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence 
> >> >> block v3")
> >> >> Signed-off-by: Jani Nikula 
> >> >> ---
> >> >>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
> >> >>  1 file changed, 13 insertions(+)
> >> >> 
> >> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> >> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> >> index f4d303ee538b..bcc083db7632 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> >> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> >> >> *intel_dsi, const u8 *data)
> >> >> struct drm_device *dev = intel_dsi->base.base.dev;
> >> >> struct drm_i915_private *dev_priv = dev->dev_private;
> >> >>  
> >> >> +   if (dev_priv->vbt.dsi.seq_version >= 3)
> >> >> +   data++;
> >> >> +
> >> >
> >> > So here we handle v3
> >> >
> >> >> gpio = *data++;
> >> >>  
> >> >> /* pull up/down */
> >> >> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> >> >> *intel_dsi, const u8 *data)
> >> >> goto out;
> >> >> }
> >> >>  
> >> >> +   if (!IS_VALLEYVIEW(dev_priv)) {
> >> >> +   DRM_DEBUG_KMS("GPIO element not supported on this 
> >> >> platform\n");
> >> >> +   goto out;
> >> >> +   }
> >> >> +
> >> >> +   if (dev_priv->vbt.dsi.seq_version >= 3) {
> >> >> +   DRM_DEBUG_KMS("GPIO element v3 not supported\n");
> >> >> +   goto out;
> >> >> +   }
> >> >
> >> > but here we say it's not supported. Is there more missing?
> >> 
> >> The whole point of doing it this way is to support *skipping* v3 in a
> >> graceful manner. If I bailed out at the top, I'd have to duplicate the
> >> knowledge about the length of the element.
> >
> > Hmm, right. But the question still stands; what more is missing for
> > actual v3 support?
> 
> That's the ugly patch #8...?

Ah, right it's the randomly (?) chosen gpio pin blocks split thing.

> 
> > From what I saw in the spec, the new byte is there just for Windows.
> > Which in itself is an utter fail on part of the spec. There's no good
> > reason why Windows and Linux should do things differently because that
> > will probably mean putting Linux on some random machine that came with
> > Windows won't work :(
> 
> There's no disagreement here. Ugly specs lead to ugly implementations.
> 
> BR,
> Jani.
> 
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 07:10:42PM +0200, Jani Nikula wrote:
>> On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
>> > On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
>> >> Skip v3 gpio element because the support is not there, and skip gpio
>> >> element on non-vlv because the sideband code is vlv specific.
>> >> 
>> >> v2: the gpio stuff is currently only supported on vlv (Ville)
>> >> 
>> >> Cc: drm-intel-fi...@lists.freedesktop.org
>> >> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block 
>> >> v3")
>> >> Signed-off-by: Jani Nikula 
>> >> ---
>> >>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>> >>  1 file changed, 13 insertions(+)
>> >> 
>> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> >> index f4d303ee538b..bcc083db7632 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> >> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> >> *intel_dsi, const u8 *data)
>> >>   struct drm_device *dev = intel_dsi->base.base.dev;
>> >>   struct drm_i915_private *dev_priv = dev->dev_private;
>> >>  
>> >> + if (dev_priv->vbt.dsi.seq_version >= 3)
>> >> + data++;
>> >> +
>> >
>> > So here we handle v3
>> >
>> >>   gpio = *data++;
>> >>  
>> >>   /* pull up/down */
>> >> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> >> *intel_dsi, const u8 *data)
>> >>   goto out;
>> >>   }
>> >>  
>> >> + if (!IS_VALLEYVIEW(dev_priv)) {
>> >> + DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
>> >> + goto out;
>> >> + }
>> >> +
>> >> + if (dev_priv->vbt.dsi.seq_version >= 3) {
>> >> + DRM_DEBUG_KMS("GPIO element v3 not supported\n");
>> >> + goto out;
>> >> + }
>> >
>> > but here we say it's not supported. Is there more missing?
>> 
>> The whole point of doing it this way is to support *skipping* v3 in a
>> graceful manner. If I bailed out at the top, I'd have to duplicate the
>> knowledge about the length of the element.
>
> Hmm, right. But the question still stands; what more is missing for
> actual v3 support?

That's the ugly patch #8...?

> From what I saw in the spec, the new byte is there just for Windows.
> Which in itself is an utter fail on part of the spec. There's no good
> reason why Windows and Linux should do things differently because that
> will probably mean putting Linux on some random machine that came with
> Windows won't work :(

There's no disagreement here. Ugly specs lead to ugly implementations.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 07:10:42PM +0200, Jani Nikula wrote:
> On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> > On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
> >> Skip v3 gpio element because the support is not there, and skip gpio
> >> element on non-vlv because the sideband code is vlv specific.
> >> 
> >> v2: the gpio stuff is currently only supported on vlv (Ville)
> >> 
> >> Cc: drm-intel-fi...@lists.freedesktop.org
> >> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block 
> >> v3")
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
> >>  1 file changed, 13 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> index f4d303ee538b..bcc083db7632 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> >> *intel_dsi, const u8 *data)
> >>struct drm_device *dev = intel_dsi->base.base.dev;
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>  
> >> +  if (dev_priv->vbt.dsi.seq_version >= 3)
> >> +  data++;
> >> +
> >
> > So here we handle v3
> >
> >>gpio = *data++;
> >>  
> >>/* pull up/down */
> >> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> >> *intel_dsi, const u8 *data)
> >>goto out;
> >>}
> >>  
> >> +  if (!IS_VALLEYVIEW(dev_priv)) {
> >> +  DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
> >> +  goto out;
> >> +  }
> >> +
> >> +  if (dev_priv->vbt.dsi.seq_version >= 3) {
> >> +  DRM_DEBUG_KMS("GPIO element v3 not supported\n");
> >> +  goto out;
> >> +  }
> >
> > but here we say it's not supported. Is there more missing?
> 
> The whole point of doing it this way is to support *skipping* v3 in a
> graceful manner. If I bailed out at the top, I'd have to duplicate the
> knowledge about the length of the element.

Hmm, right. But the question still stands; what more is missing for
actual v3 support?

From what I saw in the spec, the new byte is there just for Windows.
Which in itself is an utter fail on part of the spec. There's no good
reason why Windows and Linux should do things differently because that
will probably mean putting Linux on some random machine that came with
Windows won't work :(

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 08/38] drm/i915: Prepare retire_requests to handle out-of-order seqnos

[Jesse Barnes]

On 01/11/2016 02:10 PM, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 06:42:37PM +, john.c.harri...@intel.com wrote:
>> From: John Harrison 
>>
>> A major point of the GPU scheduler is that it re-orders batch buffers
>> after they have been submitted to the driver. This leads to requests
>> completing out of order. In turn, this means that the retire
>> processing can no longer assume that all completed entries are at the
>> front of the list. Rather than attempting to re-order the request list
>> on a regular basis, it is better to simply scan the entire list.
> 
> This is a major misstep. Just think in terms of per-context timelines,
> and retirment order within those timelines being consistent..

I think you're just re-iterating the desire for per-context timelines.  We all 
want this, but after already implementing several big reworks, I don't think 
it's fair to make John do this.  When we move that direction after this lands, 
we can simplify/drop code where possible (sure maybe it's more total churn, but 
my guess is we'll probably find other things to refactor as well, so it doesn't 
matter too much).

Jesse

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

Re: [Intel-gfx] [PATCH v5] drm/i915: Extend gpio read/write to other cores

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 06:55:15PM +0200, Jani Nikula wrote:
>> From: Deepak M 
>> 
>> Make the gpio read/write functions more generic iosf sideband read/write
>> functions, taking the iosf port as argument.
>> 
>> v2: rebase
>> v3: rebase
>> v4 by Jani: address Ville's review
>> v5 by Jani: drop the PCI_DEVFN change (Ville)
>> 
>> Signed-off-by: Deepak M 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 

Pushed this patch to dinq, thanks for the review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h| 4 ++--
>>  drivers/gpu/drm/i915/i915_reg.h| 2 ++
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +++--
>>  drivers/gpu/drm/i915/intel_sideband.c  | 9 +
>>  4 files changed, 12 insertions(+), 8 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index bd126ff3a6e2..8216665405eb 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -3471,8 +3471,8 @@ int sandybridge_pcode_write(struct drm_i915_private 
>> *dev_priv, u32 mbox, u32 val
>>  u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
>>  void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
>>  u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
>> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
>> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>> +u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
>> +void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
>> u32 val);
>>  u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
>>  void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>>  u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 6867295dbdc1..6732fc139196 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -618,6 +618,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>>  #define   IOSF_PORT_CCK 0x14
>>  #define   IOSF_PORT_DPIO_2  0x1a
>>  #define   IOSF_PORT_FLISDSI 0x1b
>> +#define   IOSF_PORT_GPIO_SC 0x48
>> +#define   IOSF_PORT_GPIO_SUS0xa8
>>  #define   IOSF_PORT_CCU 0xa9
>>  #define VLV_IOSF_DATA   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2104)
>>  #define VLV_IOSF_ADDR   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2108)
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index bcc083db7632..b96ac87902b4 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -235,14 +235,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> *intel_dsi, const u8 *data)
>>  if (!gtable[gpio].init) {
>>  /* program the function */
>>  /* FIXME: remove constant below */
>> -vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
>> +vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
>> +  0x2000CC00);
>>  gtable[gpio].init = 1;
>>  }
>>  
>>  val = 0x4 | action;
>>  
>>  /* pull up/down */
>> -vlv_gpio_nc_write(dev_priv, pad, val);
>> +vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
>>  mutex_unlock(&dev_priv->sb_lock);
>>  
>>  out:
>> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
>> b/drivers/gpu/drm/i915/intel_sideband.c
>> index f5b0ab6f5942..c3998188cf35 100644
>> --- a/drivers/gpu/drm/i915/intel_sideband.c
>> +++ b/drivers/gpu/drm/i915/intel_sideband.c
>> @@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
>> addr)
>>  return val;
>>  }
>>  
>> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
>> +u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg)
>>  {
>>  u32 val = 0;
>> -vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
>> +vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), port,
>>  SB_CRRDDA_NP, reg, &val);
>>  return val;
>>  }
>>  
>> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
>> +void vlv_iosf_sb_write(struct drm_i915_private *dev_priv,
>> +   u8 port, u32 reg, u32 val)
>>  {
>> -vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
>> +vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), port,
>>  SB_CRWRDA_NP, reg, &val);
>>  }
>>  
>> -- 
>> 2.1.4

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailm

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Jani Nikula]

On Thu, 04 Feb 2016, Jani Nikula  wrote:
> On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
>> On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
>>> Skip v3 gpio element because the support is not there, and skip gpio
>>> element on non-vlv because the sideband code is vlv specific.
>>> 
>>> v2: the gpio stuff is currently only supported on vlv (Ville)
>>> 
>>> Cc: drm-intel-fi...@lists.freedesktop.org
>>> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block 
>>> v3")
>>> Signed-off-by: Jani Nikula 
>>> ---
>>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>>>  1 file changed, 13 insertions(+)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>>> index f4d303ee538b..bcc083db7632 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>>> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>>> *intel_dsi, const u8 *data)
>>> struct drm_device *dev = intel_dsi->base.base.dev;
>>> struct drm_i915_private *dev_priv = dev->dev_private;
>>>  
>>> +   if (dev_priv->vbt.dsi.seq_version >= 3)
>>> +   data++;
>>> +
>>
>> So here we handle v3
>>
>>> gpio = *data++;
>>>  
>>> /* pull up/down */
>>> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>>> *intel_dsi, const u8 *data)
>>> goto out;
>>> }
>>>  
>>> +   if (!IS_VALLEYVIEW(dev_priv)) {
>>> +   DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
>>> +   goto out;
>>> +   }
>>> +
>>> +   if (dev_priv->vbt.dsi.seq_version >= 3) {
>>> +   DRM_DEBUG_KMS("GPIO element v3 not supported\n");
>>> +   goto out;
>>> +   }
>>
>> but here we say it's not supported. Is there more missing?
>
> The whole point of doing it this way is to support *skipping* v3 in a
> graceful manner. If I bailed out at the top, I'd have to duplicate the
> knowledge about the length of the element.

Oh, and I want to split the v3 support like this to allow backporting
*this* patch for fixes, while the actual support goes through dinq.

>
> BR,
> Jani.
>
>
>>
>>> +
>>> function = gtable[gpio].function_reg;
>>> pad = gtable[gpio].pad_reg;
>>>  
>>> -- 
>>> 2.1.4
>>> 
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
>> Skip v3 gpio element because the support is not there, and skip gpio
>> element on non-vlv because the sideband code is vlv specific.
>> 
>> v2: the gpio stuff is currently only supported on vlv (Ville)
>> 
>> Cc: drm-intel-fi...@lists.freedesktop.org
>> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index f4d303ee538b..bcc083db7632 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> *intel_dsi, const u8 *data)
>>  struct drm_device *dev = intel_dsi->base.base.dev;
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  
>> +if (dev_priv->vbt.dsi.seq_version >= 3)
>> +data++;
>> +
>
> So here we handle v3
>
>>  gpio = *data++;
>>  
>>  /* pull up/down */
>> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> *intel_dsi, const u8 *data)
>>  goto out;
>>  }
>>  
>> +if (!IS_VALLEYVIEW(dev_priv)) {
>> +DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
>> +goto out;
>> +}
>> +
>> +if (dev_priv->vbt.dsi.seq_version >= 3) {
>> +DRM_DEBUG_KMS("GPIO element v3 not supported\n");
>> +goto out;
>> +}
>
> but here we say it's not supported. Is there more missing?

The whole point of doing it this way is to support *skipping* v3 in a
graceful manner. If I bailed out at the top, I'd have to duplicate the
knowledge about the length of the element.

BR,
Jani.


>
>> +
>>  function = gtable[gpio].function_reg;
>>  pad = gtable[gpio].pad_reg;
>>  
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Jani Nikula]

Skip v3 gpio element because the support is not there, and skip gpio
element on non-vlv because the sideband code is vlv specific.

v2: the gpio stuff is currently only supported on vlv (Ville)

Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f4d303ee538b..bcc083db7632 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   if (dev_priv->vbt.dsi.seq_version >= 3)
+   data++;
+
gpio = *data++;
 
/* pull up/down */
@@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
goto out;
}
 
+   if (!IS_VALLEYVIEW(dev_priv)) {
+   DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
+   goto out;
+   }
+
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   DRM_DEBUG_KMS("GPIO element v3 not supported\n");
+   goto out;
+   }
+
function = gtable[gpio].function_reg;
pad = gtable[gpio].pad_reg;
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH v4 05/38] drm/i915: Cache request pointer in *_submission_final()

[Jesse Barnes]

On 01/11/2016 10:42 AM, john.c.harri...@intel.com wrote:
> From: Dave Gordon 
> 
> Keep a local copy of the request pointer in the _final() functions
> rather than dereferencing the params block repeatedly.
> 
> v3: New patch in series.
> 
> For: VIZ-1587
> Signed-off-by: Dave Gordon 
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++--
>  drivers/gpu/drm/i915/intel_lrc.c   | 11 ++-
>  2 files changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index eff171d..0ad32f6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1243,6 +1243,7 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>  int i915_gem_ringbuffer_submission_final(struct i915_execbuffer_params 
> *params)
>  {
>   struct drm_i915_private *dev_priv = params->dev->dev_private;
> + struct drm_i915_gem_request *req = params->request;
>   struct intel_engine_cs  *ring = params->ring;
>   u64 exec_start, exec_len;
>   int ret;
> @@ -1256,12 +1257,12 @@ int i915_gem_ringbuffer_submission_final(struct 
> i915_execbuffer_params *params)
>* Unconditionally invalidate gpu caches and ensure that we do flush
>* any residual writes from the previous batch.
>*/
> - ret = intel_ring_invalidate_all_caches(params->request);
> + ret = intel_ring_invalidate_all_caches(req);
>   if (ret)
>   goto error;
>  
>   /* Switch to the correct context for the batch */
> - ret = i915_switch_context(params->request);
> + ret = i915_switch_context(req);
>   if (ret)
>   goto error;
>  
> @@ -1270,7 +1271,7 @@ int i915_gem_ringbuffer_submission_final(struct 
> i915_execbuffer_params *params)
>  
>   if (ring == &dev_priv->ring[RCS] &&
>   params->instp_mode != dev_priv->relative_constants_mode) {
> - ret = intel_ring_begin(params->request, 4);
> + ret = intel_ring_begin(req, 4);
>   if (ret)
>   goto error;
>  
> @@ -1284,7 +1285,7 @@ int i915_gem_ringbuffer_submission_final(struct 
> i915_execbuffer_params *params)
>   }
>  
>   if (params->args_flags & I915_EXEC_GEN7_SOL_RESET) {
> - ret = i915_reset_gen7_sol_offsets(params->dev, params->request);
> + ret = i915_reset_gen7_sol_offsets(params->dev, req);
>   if (ret)
>   goto error;
>   }
> @@ -1293,13 +1294,13 @@ int i915_gem_ringbuffer_submission_final(struct 
> i915_execbuffer_params *params)
>   exec_start = params->batch_obj_vm_offset +
>params->args_batch_start_offset;
>  
> - ret = ring->dispatch_execbuffer(params->request,
> + ret = ring->dispatch_execbuffer(req,
>   exec_start, exec_len,
>   params->dispatch_flags);
>   if (ret)
>   goto error;
>  
> - trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
> + trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
>  
>   i915_gem_execbuffer_retire_commands(params);
>  
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 014180c..a344a3a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -929,7 +929,8 @@ int intel_execlists_submission(struct 
> i915_execbuffer_params *params,
>  int intel_execlists_submission_final(struct i915_execbuffer_params *params)
>  {
>   struct drm_i915_private *dev_priv = params->dev->dev_private;
> - struct intel_ringbuffer *ringbuf = params->request->ringbuf;
> + struct drm_i915_gem_request *req = params->request;
> + struct intel_ringbuffer *ringbuf = req->ringbuf;
>   struct intel_engine_cs *ring = params->ring;
>   u64 exec_start;
>   int ret;
> @@ -941,13 +942,13 @@ int intel_execlists_submission_final(struct 
> i915_execbuffer_params *params)
>* Unconditionally invalidate gpu caches and ensure that we do flush
>* any residual writes from the previous batch.
>*/
> - ret = logical_ring_invalidate_all_caches(params->request);
> + ret = logical_ring_invalidate_all_caches(req);
>   if (ret)
>   return ret;
>  
>   if (ring == &dev_priv->ring[RCS] &&
>   params->instp_mode != dev_priv->relative_constants_mode) {
> - ret = intel_logical_ring_begin(params->request, 4);
> + ret = intel_logical_ring_begin(req, 4);
>   if (ret)
>   return ret;
>  
> @@ -963,11 +964,11 @@ int intel_execlists_submission_final(struct 
> i915_execbuffer_params *params)
>   exec_start = params->batch_obj_vm_offset +
>params->args_batch_start_offset;
>  
> - ret = ring->emit_bb_start(para

Re: [Intel-gfx] [PATCH v4 04/38] drm/i915: Split i915_dem_do_execbuffer() in half

[Jesse Barnes]

On 01/11/2016 10:42 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> Split the execbuffer() function in half. The first half collects and
> validates all the information required to process the batch buffer. It
> also does all the object pinning, relocations, active list management,
> etc - basically anything that must be done upfront before the IOCTL
> returns and allows the user land side to start changing/freeing
> things. The second half does the actual ring submission.
> 
> This change implements the split but leaves the back half being called
> directly from the end of the front half.
> 
> v2: Updated due to changes in underlying tree - addition of sync fence
> support and removal of cliprects.
> 
> v3: Moved local 'ringbuf' variable to make later patches in the
> series a bit neater.
> 
> v4: Corrected a typo in the commit message and downgraded a BUG_ON to
> a WARN_ON as the latter is preferred. Also removed all the external
> sync/fence support as that will now be a separate patch series.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  11 
>  drivers/gpu/drm/i915/i915_gem.c|   2 +
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 101 
> ++---
>  drivers/gpu/drm/i915/intel_lrc.c   |  57 +++-
>  drivers/gpu/drm/i915/intel_lrc.h   |   1 +
>  5 files changed, 130 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index acfe25f..2520459 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1679,10 +1679,18 @@ struct i915_execbuffer_params {
>   struct drm_device   *dev;
>   struct drm_file *file;
>   uint32_tdispatch_flags;
> + uint32_targs_flags;
>   uint32_targs_batch_start_offset;
> + uint32_targs_batch_len;
> + uint32_targs_num_cliprects;
> + uint32_targs_DR1;
> + uint32_targs_DR4;
>   uint64_tbatch_obj_vm_offset;
>   struct intel_engine_cs  *ring;
>   struct drm_i915_gem_object  *batch_obj;
> + struct drm_clip_rect*cliprects;
> + uint32_tinstp_mask;
> + int instp_mode;
>   struct intel_context*ctx;
>   struct drm_i915_gem_request *request;
>  };
> @@ -1944,6 +1952,7 @@ struct drm_i915_private {
>   int (*execbuf_submit)(struct i915_execbuffer_params *params,
> struct drm_i915_gem_execbuffer2 *args,
> struct list_head *vmas);
> + int (*execbuf_final)(struct i915_execbuffer_params *params);
>   int (*init_rings)(struct drm_device *dev);
>   void (*cleanup_ring)(struct intel_engine_cs *ring);
>   void (*stop_ring)(struct intel_engine_cs *ring);
> @@ -2790,9 +2799,11 @@ int i915_gem_sw_finish_ioctl(struct drm_device *dev, 
> void *data,
>  void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
>   struct drm_i915_gem_request *req);
>  void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params 
> *params);
> +void i915_gem_execbuff_release_batch_obj(struct drm_i915_gem_object 
> *batch_obj);
>  int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
>  struct drm_i915_gem_execbuffer2 *args,
>  struct list_head *vmas);
> +int i915_gem_ringbuffer_submission_final(struct i915_execbuffer_params 
> *params);
>  int i915_gem_execbuffer(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
>  int i915_gem_execbuffer2(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e8ec49e..5bf7da6 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5220,11 +5220,13 @@ int i915_gem_init(struct drm_device *dev)
>  
>   if (!i915.enable_execlists) {
>   dev_priv->gt.execbuf_submit = i915_gem_ringbuffer_submission;
> + dev_priv->gt.execbuf_final = 
> i915_gem_ringbuffer_submission_final;
>   dev_priv->gt.init_rings = i915_gem_init_rings;
>   dev_priv->gt.cleanup_ring = intel_cleanup_ring_buffer;
>   dev_priv->gt.stop_ring = intel_stop_ring_buffer;
>   } else {
>   dev_priv->gt.execbuf_submit = intel_execlists_submission;
> + dev_priv->gt.execbuf_final = intel_execlists_submission_final;
>   dev_priv->gt.init_rings = intel_logical_rings_init;
>   dev_priv->gt.cleanup_ring = intel_logical_

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: skip gpio element execution when not supported

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 06:52:47PM +0200, Jani Nikula wrote:
> Skip v3 gpio element because the support is not there, and skip gpio
> element on non-vlv because the sideband code is vlv specific.
> 
> v2: the gpio stuff is currently only supported on vlv (Ville)
> 
> Cc: drm-intel-fi...@lists.freedesktop.org
> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index f4d303ee538b..bcc083db7632 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   struct drm_device *dev = intel_dsi->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (dev_priv->vbt.dsi.seq_version >= 3)
> + data++;
> +

So here we handle v3

>   gpio = *data++;
>  
>   /* pull up/down */
> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   goto out;
>   }
>  
> + if (!IS_VALLEYVIEW(dev_priv)) {
> + DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
> + goto out;
> + }
> +
> + if (dev_priv->vbt.dsi.seq_version >= 3) {
> + DRM_DEBUG_KMS("GPIO element v3 not supported\n");
> + goto out;
> + }

but here we say it's not supported. Is there more missing?

> +
>   function = gtable[gpio].function_reg;
>   pad = gtable[gpio].pad_reg;
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: Extend gpio read/write to other cores

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 06:55:15PM +0200, Jani Nikula wrote:
> From: Deepak M 
> 
> Make the gpio read/write functions more generic iosf sideband read/write
> functions, taking the iosf port as argument.
> 
> v2: rebase
> v3: rebase
> v4 by Jani: address Ville's review
> v5 by Jani: drop the PCI_DEVFN change (Ville)
> 
> Signed-off-by: Deepak M 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.h| 4 ++--
>  drivers/gpu/drm/i915/i915_reg.h| 2 ++
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +++--
>  drivers/gpu/drm/i915/intel_sideband.c  | 9 +
>  4 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bd126ff3a6e2..8216665405eb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3471,8 +3471,8 @@ int sandybridge_pcode_write(struct drm_i915_private 
> *dev_priv, u32 mbox, u32 val
>  u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
>  void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
>  u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> +u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
> +void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
> u32 val);
>  u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
>  void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6867295dbdc1..6732fc139196 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -618,6 +618,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   IOSF_PORT_CCK  0x14
>  #define   IOSF_PORT_DPIO_2   0x1a
>  #define   IOSF_PORT_FLISDSI  0x1b
> +#define   IOSF_PORT_GPIO_SC  0x48
> +#define   IOSF_PORT_GPIO_SUS 0xa8
>  #define   IOSF_PORT_CCU  0xa9
>  #define VLV_IOSF_DATA_MMIO(VLV_DISPLAY_BASE 
> + 0x2104)
>  #define VLV_IOSF_ADDR_MMIO(VLV_DISPLAY_BASE 
> + 0x2108)
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index bcc083db7632..b96ac87902b4 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -235,14 +235,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   if (!gtable[gpio].init) {
>   /* program the function */
>   /* FIXME: remove constant below */
> - vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
> + vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
> +   0x2000CC00);
>   gtable[gpio].init = 1;
>   }
>  
>   val = 0x4 | action;
>  
>   /* pull up/down */
> - vlv_gpio_nc_write(dev_priv, pad, val);
> + vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
>   mutex_unlock(&dev_priv->sb_lock);
>  
>  out:
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> b/drivers/gpu/drm/i915/intel_sideband.c
> index f5b0ab6f5942..c3998188cf35 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
> addr)
>   return val;
>  }
>  
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
> +u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg)
>  {
>   u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
> + vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), port,
>   SB_CRRDDA_NP, reg, &val);
>   return val;
>  }
>  
> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> +void vlv_iosf_sb_write(struct drm_i915_private *dev_priv,
> +u8 port, u32 reg, u32 val)
>  {
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
> + vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), port,
>   SB_CRWRDA_NP, reg, &val);
>  }
>  
> -- 
> 2.1.4

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 03/38] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

[Jesse Barnes]

On 01/11/2016 10:42 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The scheduler decouples the submission of batch buffers to the driver
> with their submission to the hardware. This basically means splitting
> the execbuffer() function in half. This change rearranges some code
> ready for the split to occur.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 63 
> ++
>  drivers/gpu/drm/i915/intel_lrc.c   | 18 ++---
>  2 files changed, 51 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index bfc4c17..0eca2b6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -933,10 +933,7 @@ i915_gem_execbuffer_move_to_gpu(struct 
> drm_i915_gem_request *req,
>   if (flush_domains & I915_GEM_DOMAIN_GTT)
>   wmb();
>  
> - /* Unconditionally invalidate gpu caches and ensure that we do flush
> -  * any residual writes from the previous batch.
> -  */
> - return intel_ring_invalidate_all_caches(req);
> + return 0;
>  }
>  
>  static bool
> @@ -1189,17 +1186,6 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>   u32 instp_mask;
>   int ret;
>  
> - ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas);
> - if (ret)
> - return ret;
> -
> - ret = i915_switch_context(params->request);
> - if (ret)
> - return ret;
> -
> - WARN(params->ctx->ppgtt && params->ctx->ppgtt->pd_dirty_rings & 
> (1 -  "%s didn't clear reload\n", ring->name);
> -
>   instp_mode = args->flags & I915_EXEC_CONSTANTS_MASK;
>   instp_mask = I915_EXEC_CONSTANTS_MASK;
>   switch (instp_mode) {
> @@ -1233,11 +1219,37 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>   return -EINVAL;
>   }
>  
> + ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas);
> + if (ret)
> + return ret;
> +
> + i915_gem_execbuffer_move_to_active(vmas, params->request);
> +
> + /* To be split into two functions here... */
> +
> + intel_runtime_pm_get(dev_priv);
> +
> + /*
> +  * Unconditionally invalidate gpu caches and ensure that we do flush
> +  * any residual writes from the previous batch.
> +  */
> + ret = intel_ring_invalidate_all_caches(params->request);
> + if (ret)
> + goto error;
> +
> + /* Switch to the correct context for the batch */
> + ret = i915_switch_context(params->request);
> + if (ret)
> + goto error;
> +
> + WARN(params->ctx->ppgtt && params->ctx->ppgtt->pd_dirty_rings & 
> (1 +  "%s didn't clear reload\n", ring->name);
> +
>   if (ring == &dev_priv->ring[RCS] &&
>   instp_mode != dev_priv->relative_constants_mode) {
>   ret = intel_ring_begin(params->request, 4);
>   if (ret)
> - return ret;
> + goto error;
>  
>   intel_ring_emit(ring, MI_NOOP);
>   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
> @@ -1251,7 +1263,7 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>   if (args->flags & I915_EXEC_GEN7_SOL_RESET) {
>   ret = i915_reset_gen7_sol_offsets(dev, params->request);
>   if (ret)
> - return ret;
> + goto error;
>   }
>  
>   exec_len   = args->batch_len;
> @@ -1262,14 +1274,20 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>   exec_start, exec_len,
>   params->dispatch_flags);
>   if (ret)
> - return ret;
> + goto error;
>  
>   trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
>  
> - i915_gem_execbuffer_move_to_active(vmas, params->request);
>   i915_gem_execbuffer_retire_commands(params);
>  
> - return 0;
> +error:
> + /*
> +  * intel_gpu_busy should also get a ref, so it will free when the device
> +  * is really idle.
> +  */
> + intel_runtime_pm_put(dev_priv);
> +
> + return ret;
>  }
>  
>  /**
> @@ -1424,8 +1442,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
> *data,
>   dispatch_flags |= I915_DISPATCH_RS;
>   }
>  
> - intel_runtime_pm_get(dev_priv);
> -
>   ret = i915_mutex_lock_interruptible(dev);
>   if (ret)
>   goto pre_mutex_err;
> @@ -1599,9 +1615,6 @@ err:
>   mutex_unlock(&dev->struct_mutex);
>  
>  pre_mutex_err:
> - /* intel_gpu_busy should also get a ref, so it will free when the device
> -  * is really idle. */
> - intel_runtime_pm_put(dev_priv);
>   return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/int

Re: [Intel-gfx] [PATCH 6/8] drm/i915/vlv: drop unused vlv_gps_core_read/write functions

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 12:50:54PM +0200, Jani Nikula wrote:
>> Not needed.
>> 
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 

Pushed patches 5-6 to dinq, thanks for the review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h   |  2 --
>>  drivers/gpu/drm/i915/i915_reg.h   |  1 -
>>  drivers/gpu/drm/i915/intel_sideband.c | 14 --
>>  3 files changed, 17 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 77227a39f3d5..af601be8b490 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -3483,8 +3483,6 @@ u32 vlv_ccu_read(struct drm_i915_private *dev_priv, 
>> u32 reg);
>>  void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>>  u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
>>  void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
>> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 
>> val);
>>  u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int 
>> reg);
>>  void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int 
>> reg, u32 val);
>>  u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index f3b4b19198b9..c761fa2f3b8b 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -618,7 +618,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>>  #define   IOSF_PORT_CCK 0x14
>>  #define   IOSF_PORT_DPIO_2  0x1a
>>  #define   IOSF_PORT_FLISDSI 0x1b
>> -#define   IOSF_PORT_GPS_CORE0x48
>>  #define   IOSF_PORT_CCU 0xa9
>>  #define VLV_IOSF_DATA   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2104)
>>  #define VLV_IOSF_ADDR   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2108)
>> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
>> b/drivers/gpu/drm/i915/intel_sideband.c
>> index 8831fc579ade..f5b0ab6f5942 100644
>> --- a/drivers/gpu/drm/i915/intel_sideband.c
>> +++ b/drivers/gpu/drm/i915/intel_sideband.c
>> @@ -171,20 +171,6 @@ void vlv_ccu_write(struct drm_i915_private *dev_priv, 
>> u32 reg, u32 val)
>>  SB_CRWRDA_NP, reg, &val);
>>  }
>>  
>> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
>> -{
>> -u32 val = 0;
>> -vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
>> -SB_CRRDDA_NP, reg, &val);
>> -return val;
>> -}
>> -
>> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
>> -{
>> -vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
>> -SB_CRWRDA_NP, reg, &val);
>> -}
>> -
>>  u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int 
>> reg)
>>  {
>>  u32 val = 0;
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dsi: don't pass arbitrary data to sideband

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 12:50:50PM +0200, Jani Nikula wrote:
>> Since sequence block v2 the second byte contains flags other than just
>> pull up/down. Don't pass arbitrary data to the sideband interface.
>> 
>> The rest may or may not work for sequence block v2, but there should be
>> no harm done.
>> 
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Ville Syrjälä 
>
> well, as far as it can be reviewed with the crappy specs.

Pushed patches 1-2 to dinq, thanks for the review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index 4775aa5462e8..6f013efba45b 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -207,7 +207,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
>> *intel_dsi, const u8 *data)
>>  gpio = *data++;
>>  
>>  /* pull up/down */
>> -action = *data++;
>> +action = *data++ & 1;
>>  
>>  if (gpio >= ARRAY_SIZE(gtable)) {
>>  DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5] drm/i915: Extend gpio read/write to other cores

[Jani Nikula]

From: Deepak M 

Make the gpio read/write functions more generic iosf sideband read/write
functions, taking the iosf port as argument.

v2: rebase
v3: rebase
v4 by Jani: address Ville's review
v5 by Jani: drop the PCI_DEVFN change (Ville)

Signed-off-by: Deepak M 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h| 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +++--
 drivers/gpu/drm/i915/intel_sideband.c  | 9 +
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bd126ff3a6e2..8216665405eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3471,8 +3471,8 @@ int sandybridge_pcode_write(struct drm_i915_private 
*dev_priv, u32 mbox, u32 val
 u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
 void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
 u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
+void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
u32 val);
 u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6867295dbdc1..6732fc139196 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -618,6 +618,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   IOSF_PORT_CCK0x14
 #define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_FLISDSI0x1b
+#define   IOSF_PORT_GPIO_SC0x48
+#define   IOSF_PORT_GPIO_SUS   0xa8
 #define   IOSF_PORT_CCU0xa9
 #define VLV_IOSF_DATA  _MMIO(VLV_DISPLAY_BASE + 0x2104)
 #define VLV_IOSF_ADDR  _MMIO(VLV_DISPLAY_BASE + 0x2108)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index bcc083db7632..b96ac87902b4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -235,14 +235,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
if (!gtable[gpio].init) {
/* program the function */
/* FIXME: remove constant below */
-   vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
+   vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
+ 0x2000CC00);
gtable[gpio].init = 1;
}
 
val = 0x4 | action;
 
/* pull up/down */
-   vlv_gpio_nc_write(dev_priv, pad, val);
+   vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
mutex_unlock(&dev_priv->sb_lock);
 
 out:
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index f5b0ab6f5942..c3998188cf35 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
addr)
return val;
 }
 
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
+u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg)
 {
u32 val = 0;
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), port,
SB_CRRDDA_NP, reg, &val);
return val;
 }
 
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+void vlv_iosf_sb_write(struct drm_i915_private *dev_priv,
+  u8 port, u32 reg, u32 val)
 {
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), port,
SB_CRWRDA_NP, reg, &val);
 }
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation

[Gustav Fägerlind]

Cool, thank you.
I dont believe I can easily reproduce it, it has only happend few times
(and i reboot my lappy >2 times per day).

//
Gustav

2016-02-03 14:25 GMT+01:00 Lukas Wunner :

> Hi,
>
> On Wed, Feb 03, 2016 at 09:17:37AM +, Chris Wilson wrote:
> > If the initialisation fails, we may be left with a dangling pointer with
> > an incomplete fbdev structure.
>
> This shouldn't happen with 4.5, the fbdev is now clobbered if
> initialization
> fails, the existing "if (dev_priv->fbdev)" checks should thus be
> sufficient.
> See 54632abe8ca3 ("drm/i915: Fix oops caused by fbdev initialization
> failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
> initialization fails").
>
> Gustav Fagerlind and Li Weinan both reported this for 4.3. It would be
> interesting to know if it can be reproduced at all with 4.5-rc2.
>
> Best regards,
>
> Lukas
>
> > Here we want to disable internal calls
> > into fbdev. Similarly, the initialisation may be slow and we haven't yet
> > enabled the fbdev (e.g. quick suspend or last-close before the async init
> > completes).
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> > Reported-by: "Li, Weinan Z" 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/intel_fbdev.c | 41
> --
> >  1 file changed, 26 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 09840f4380f9..6218bc5370a1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -114,6 +114,20 @@ static struct fb_ops intelfb_ops = {
> >   .fb_debug_leave = drm_fb_helper_debug_leave,
> >  };
> >
> > +static bool intel_fbdev_active(struct intel_fbdev *ifbdev)
> > +{
> > + struct fb_info *info;
> > +
> > + if (ifbdev == NULL)
> > + return false;
> > +
> > + info = ifbdev->helper.fbdev;
> > + if (!info->screen_base)
> > + return false;
> > +
> > + return info->state == FBINFO_STATE_RUNNING;
> > +}
> > +
> >  static int intelfb_alloc(struct drm_fb_helper *helper,
> >struct drm_fb_helper_surface_size *sizes)
> >  {
> > @@ -753,6 +767,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev,
> int state, bool synchronous
> >   return;
> >
> >   info = ifbdev->helper.fbdev;
> > + if (!info->screen_base)
> > + return;
> >
> >   if (synchronous) {
> >   /* Flush any pending work to turn the console on, and then
> > @@ -794,29 +810,24 @@ void intel_fbdev_set_suspend(struct drm_device
> *dev, int state, bool synchronous
> >
> >  void intel_fbdev_output_poll_changed(struct drm_device *dev)
> >  {
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - if (dev_priv->fbdev)
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > +
> > + if (intel_fbdev_active(dev_priv->fbdev))
> >   drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
> >  }
> >
> >  void intel_fbdev_restore_mode(struct drm_device *dev)
> >  {
> > - int ret;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - struct intel_fbdev *ifbdev = dev_priv->fbdev;
> > - struct drm_fb_helper *fb_helper;
> > + struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
> >
> > - if (!ifbdev)
> > + if (!intel_fbdev_active(ifbdev))
> >   return;
> >
> > - fb_helper = &ifbdev->helper;
> > -
> > - ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> > - if (ret) {
> > - DRM_DEBUG("failed to restore crtc mode\n");
> > - } else {
> > - mutex_lock(&fb_helper->dev->struct_mutex);
> > + if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) ==
> 0) {
> > + mutex_lock(&dev->struct_mutex);
> >   intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> > - mutex_unlock(&fb_helper->dev->struct_mutex);
> > + mutex_unlock(&dev->struct_mutex);
> > + } else {
> > + DRM_DEBUG("failed to restore crtc mode\n");
> >   }
> >  }
> > --
> > 2.7.0
> >
> > ___
> > 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] kernel/cpu: Distinctive name for cpu_hotplug.dep_map

[Gautham R Shenoy]

Hello Joonas,

On Wed, Feb 03, 2016 at 04:24:28PM +0200, Joonas Lahtinen wrote:
> Use distinctive name for cpu_hotplug.dep_map to avoid the actual
> cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
> 
> Cc: Gautham R. Shenoy 
> Cc: Rafael J. Wysocki 
> Cc: Intel graphics driver community testing & development 
> 
> Signed-off-by: Joonas Lahtinen 
> ---
>  kernel/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 5b9d396..6a13f24 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -78,7 +78,7 @@ static struct {
>   .wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
>   .lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
>  #ifdef CONFIG_DEBUG_LOCK_ALLOC
> - .dep_map = {.name = "cpu_hotplug.lock" },
> + .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map", 
> &cpu_hotplug.dep_map),

Looks good to me!
Acked-by: Gautham R. Shenoy 

--
Thanks and Regards
gautham.

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

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present

[Lukas Wunner]

Hi,

On Thu, Feb 04, 2016 at 04:05:04PM +, Chris Wilson wrote:
> On Thu, Feb 04, 2016 at 04:46:55PM +0100, Lukas Wunner wrote:
> > > + /* If the stolen region can be modified behind our backs upon suspend,
> > > +  * then we cannot use it to store nonvolatile contents (i.e user data)
> > > +  * as it will be corrupted upon resume.
> > > +  */
> > > + dev_priv->mm.nonvolatile_stolen = true;
> > > +#ifdef CONFIG_SUSPEND
> > > + if (intel_detect_acpi_rst()) {
> > > + /* BIOSes using RapidStart Technology have been reported
> > > +  * to overwrite stolen across S3, not just S4.
> > > +  */
> > > + dev_priv->mm.nonvolatile_stolen = false;
> > > + }
> > > +#endif
> > > +
> > 
> > I'd suggest simplifying it like this:
> > 
> > dev_priv->mm.nonvolatile_stolen = !(IS_ENABLED(CONFIG_SUSPEND) &&
> > acpi_dev_present("INT3392"));
> 
> Using if (IS_ENABLED(CONFIG_SUSPEND) && intel_detect_acpi_rst()) would
> be better indeed. My main concern here is that we document carefully why
> we had to disable this, and to leave room for future caveats.

Yes absolutely, keep the comments. (Or meld them into one if simplifying
the code as suggested.)

> We could #define INTEL_RAPID_START "INT3392" for
> if (IS_ENABLED(CONFIG_SUSPEND) && acpi_dev_present(INTEL_RAPID_START))
> but Anki wanted to keep the acpi details themselves out of stolen (hence
> the current split).

At the very least the #ifdef needs to be replaced by IS_ENABLED,
Documentation/CodingStyle chapter 20 very clearly states this is
to be preferred.

Less code is almost always better, it's more work for a reader to
follow the logic if things are split across multiple files.

If you absolutely positively want to keep the current split,
the "static const struct acpi_device_id irst_ids[]" data structure
should be replaced by a "static const char*" in order to not waste
memory.

I'd also suggest renaming "dev_priv->mm.nonvolatile_stolen" to
"volatile_stolen" since the only user of the flag uses its negation
and its calculation requires negation as well.

Best regards,

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

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Adding the parsing logic for the i2c element

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 06:21:23PM +0200, Jani Nikula wrote:
> On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> > On Thu, Feb 04, 2016 at 12:50:51PM +0200, Jani Nikula wrote:
> >> From: vkorjani 
> >> 
> >> New sequence element for i2c is been added in the
> >> mipi sequence block of the VBT. This patch parses
> >> and executes the i2c sequence.
> >> 
> >> v2: Add i2c_put_adapter call(Jani), rebase
> >> 
> >> v3: corrected the retry loop(Jani), rebase
> >> 
> >> v4 by Jani:
> >>  - don't put the adapter if get fails
> >>  - print an error message if all retries exhausted
> >>  - use a for loop
> >>  - fix warnings for unused variables
> >> 
> >> v5 by Jani:
> >>  - rebase on the skip i2c element patch
> >> 
> >> v6: by Jani:
> >>  - ignore the gmbus i2c elements (Ville)
> >> 
> >> Signed-off-by: vkorjani 
> >> Signed-off-by: Deepak M 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 64 
> >> --
> >>  1 file changed, 61 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> index 6f013efba45b..f4d303ee538b 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> @@ -31,6 +31,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include "i915_drv.h"
> >> @@ -235,9 +236,66 @@ out:
> >>return data;
> >>  }
> >>  
> >> -static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 
> >> *data)
> >> +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 
> >> *data)
> >>  {
> >> -  return data + *(data + 6) + 7;
> >> +  struct i2c_adapter *adapter;
> >> +  int ret, i;
> >> +  u8 reg_offset, payload_size;
> >> +  struct i2c_msg msg;
> >> +  u8 *transmit_buffer;
> >> +  u8 flag, resource_id, bus_number;
> >> +  u16 slave_add;
> >> +
> >> +  flag = *data++;
> >> +  resource_id = *data++;
> >> +  bus_number = *data++;
> >> +  slave_add = *(u16 *)(data);
> >> +  data += 2;
> >> +  reg_offset = *data++;
> >> +  payload_size = *data++;
> >> +
> >> +  if (resource_id == 0xff || bus_number == 0xff) {
> >> +  DRM_DEBUG_KMS("ignoring gmbus (resource id %02x, bus %02x)\n",
> >> +resource_id, bus_number);
> >> +  goto out;
> >> +  }
> >> +
> >
> > Still missing the check for __i2c_first_dynamic_bus_num which I think
> > would at least provide some kind of half arsed protection against
> > something not registering these magic i2c busses.
> 
> I meant to reply to that part of the review but forgot.
> 
> Problem is, we'd have to include drivers/i2c/i2c-core.h directly, which
> also has this warning,
> 
> /* These symbols are exported ONLY FOR the i2c core.
>  * No other users will be supported.
>  */
> 
> and there are no users outside of drivers/i2c. I'm quite reluctant to
> add that.

The we need some other way to look up the adapter. Passing in
essentially random adapter numbers could give us more or less
any i2c bus on the system, and if we go poke there we could do
real damage.

The whole scheme is very poorly thoght out I think. There really
should be some kind of ACPI ID or something that lets us look up
exactly the right thing.

> 
> 
> BR,
> Jani.
> 
> 
> >
> >> +  adapter = i2c_get_adapter(bus_number);
> >> +  if (!adapter) {
> >> +  DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
> >> +  goto out;
> >> +  }
> >> +
> >> +  transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
> >> +  if (!transmit_buffer)
> >> +  goto out_put;
> >> +
> >> +  transmit_buffer[0] = reg_offset;
> >> +  memcpy(&transmit_buffer[1], data, payload_size);
> >> +
> >> +  msg.addr = slave_add;
> >> +  msg.flags = 0;
> >> +  msg.len = payload_size + 1;
> >> +  msg.buf = &transmit_buffer[0];
> >> +
> >> +  for (i = 0; i < 6; i++) {
> >> +  ret = i2c_transfer(adapter, &msg, 1);
> >> +  if (ret == 1) {
> >> +  goto out_free;
> >> +  } else if (ret == -EAGAIN) {
> >> +  usleep_range(1000, 2500);
> >> +  } else {
> >> +  break;
> >> +  }
> >> +  }
> >> +
> >> +  DRM_ERROR("i2c transfer failed: %d\n", ret);
> >> +out_free:
> >> +  kfree(transmit_buffer);
> >> +out_put:
> >> +  i2c_put_adapter(adapter);
> >> +out:
> >> +  return data + payload_size;
> >>  }
> >>  
> >>  typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
> >> @@ -246,7 +304,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
> >>[MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
> >>[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
> >>[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
> >> -  [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
> >> +  [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
> >>  };
> >>  
> >>  /*
> >> -- 
> >> 2.1.4
> >> 
> >> ___
> >> Intel-gfx mailing list
> >> In

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Adding the parsing logic for the i2c element

[Jani Nikula]

On Thu, 04 Feb 2016, Ville Syrjälä  wrote:
> On Thu, Feb 04, 2016 at 12:50:51PM +0200, Jani Nikula wrote:
>> From: vkorjani 
>> 
>> New sequence element for i2c is been added in the
>> mipi sequence block of the VBT. This patch parses
>> and executes the i2c sequence.
>> 
>> v2: Add i2c_put_adapter call(Jani), rebase
>> 
>> v3: corrected the retry loop(Jani), rebase
>> 
>> v4 by Jani:
>>  - don't put the adapter if get fails
>>  - print an error message if all retries exhausted
>>  - use a for loop
>>  - fix warnings for unused variables
>> 
>> v5 by Jani:
>>  - rebase on the skip i2c element patch
>> 
>> v6: by Jani:
>>  - ignore the gmbus i2c elements (Ville)
>> 
>> Signed-off-by: vkorjani 
>> Signed-off-by: Deepak M 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 64 
>> --
>>  1 file changed, 61 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index 6f013efba45b..f4d303ee538b 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -31,6 +31,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "i915_drv.h"
>> @@ -235,9 +236,66 @@ out:
>>  return data;
>>  }
>>  
>> -static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 
>> *data)
>> +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
>>  {
>> -return data + *(data + 6) + 7;
>> +struct i2c_adapter *adapter;
>> +int ret, i;
>> +u8 reg_offset, payload_size;
>> +struct i2c_msg msg;
>> +u8 *transmit_buffer;
>> +u8 flag, resource_id, bus_number;
>> +u16 slave_add;
>> +
>> +flag = *data++;
>> +resource_id = *data++;
>> +bus_number = *data++;
>> +slave_add = *(u16 *)(data);
>> +data += 2;
>> +reg_offset = *data++;
>> +payload_size = *data++;
>> +
>> +if (resource_id == 0xff || bus_number == 0xff) {
>> +DRM_DEBUG_KMS("ignoring gmbus (resource id %02x, bus %02x)\n",
>> +  resource_id, bus_number);
>> +goto out;
>> +}
>> +
>
> Still missing the check for __i2c_first_dynamic_bus_num which I think
> would at least provide some kind of half arsed protection against
> something not registering these magic i2c busses.

I meant to reply to that part of the review but forgot.

Problem is, we'd have to include drivers/i2c/i2c-core.h directly, which
also has this warning,

/* These symbols are exported ONLY FOR the i2c core.
 * No other users will be supported.
 */

and there are no users outside of drivers/i2c. I'm quite reluctant to
add that.


BR,
Jani.


>
>> +adapter = i2c_get_adapter(bus_number);
>> +if (!adapter) {
>> +DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
>> +goto out;
>> +}
>> +
>> +transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
>> +if (!transmit_buffer)
>> +goto out_put;
>> +
>> +transmit_buffer[0] = reg_offset;
>> +memcpy(&transmit_buffer[1], data, payload_size);
>> +
>> +msg.addr = slave_add;
>> +msg.flags = 0;
>> +msg.len = payload_size + 1;
>> +msg.buf = &transmit_buffer[0];
>> +
>> +for (i = 0; i < 6; i++) {
>> +ret = i2c_transfer(adapter, &msg, 1);
>> +if (ret == 1) {
>> +goto out_free;
>> +} else if (ret == -EAGAIN) {
>> +usleep_range(1000, 2500);
>> +} else {
>> +break;
>> +}
>> +}
>> +
>> +DRM_ERROR("i2c transfer failed: %d\n", ret);
>> +out_free:
>> +kfree(transmit_buffer);
>> +out_put:
>> +i2c_put_adapter(adapter);
>> +out:
>> +return data + payload_size;
>>  }
>>  
>>  typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
>> @@ -246,7 +304,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
>>  [MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
>>  [MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
>>  [MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
>> -[MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
>> +[MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
>>  };
>>  
>>  /*
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915/vlv: drop unused vlv_gps_core_read/write functions

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:54PM +0200, Jani Nikula wrote:
> Not needed.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  2 --
>  drivers/gpu/drm/i915/i915_reg.h   |  1 -
>  drivers/gpu/drm/i915/intel_sideband.c | 14 --
>  3 files changed, 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 77227a39f3d5..af601be8b490 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3483,8 +3483,6 @@ u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 
> reg);
>  void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
>  void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int 
> reg);
>  void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int 
> reg, u32 val);
>  u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f3b4b19198b9..c761fa2f3b8b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -618,7 +618,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   IOSF_PORT_CCK  0x14
>  #define   IOSF_PORT_DPIO_2   0x1a
>  #define   IOSF_PORT_FLISDSI  0x1b
> -#define   IOSF_PORT_GPS_CORE 0x48
>  #define   IOSF_PORT_CCU  0xa9
>  #define VLV_IOSF_DATA_MMIO(VLV_DISPLAY_BASE 
> + 0x2104)
>  #define VLV_IOSF_ADDR_MMIO(VLV_DISPLAY_BASE 
> + 0x2108)
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 8831fc579ade..f5b0ab6f5942 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -171,20 +171,6 @@ void vlv_ccu_write(struct drm_i915_private *dev_priv, 
> u32 reg, u32 val)
>   SB_CRWRDA_NP, reg, &val);
>  }
>  
> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> -{
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
> - SB_CRWRDA_NP, reg, &val);
> -}
> -
>  u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg)
>  {
>   u32 val = 0;
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl: Fix typo in DPLL_CFGCR1 definition

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 10:43:21AM -0500, Lyude wrote:
> We accidentally point both cfgcr registers for the second shared DPLL to
> the same location in i915_reg.h. This results in a lot of hw pipe state
> mismatches whenever we try to do a modeset that requires allocating the
> DPLL to a CRTC:
> 
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> dpll_hw_state.cfgcr1 (expected 0x8168, found 0x04a5)
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> base.adjusted_mode.crtc_clock (expected 108000, found 49500)
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock 
> (expected 108000, found 49500)
> 
> This usually ends up causing blank monitors, since the DPLL never can
> get set to the right clock.
> 
> Fixes: f0f59a00a1 ("drm/i915: Type safe register read/write")

Actually
Fixes: 086f8e84a085 ("drm/i915: Prefix raw register defines with underscore")

That's the second regression from the type safety stuff :( I guess we
still don't have enough testing coverage since this has gone undetected
for so long.

Reviewed-by: Ville Syrjälä 

> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 007ae83..b9a564b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7514,7 +7514,7 @@ enum skl_disp_power_wells {
>  #define  DPLL_CFGCR2_PDIV_7 (4<<2)
>  #define  DPLL_CFGCR2_CENTRAL_FREQ_MASK   (3)
>  
> -#define DPLL_CFGCR1(id)  _MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR1, 
> _DPLL2_CFGCR2)
> +#define DPLL_CFGCR1(id)  _MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR1, 
> _DPLL2_CFGCR1)
>  #define DPLL_CFGCR2(id)  _MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR2, 
> _DPLL2_CFGCR2)
>  
>  /* BXT display engine PLL */
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915: put the IOSF port defines in numerical order

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:53PM +0200, Jani Nikula wrote:
> Make it easier to spot duplicates.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c0bd691b41f8..f3b4b19198b9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -610,16 +610,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   IOSF_BYTE_ENABLES_SHIFT4
>  #define   IOSF_BAR_SHIFT 1
>  #define   IOSF_SB_BUSY   (1<<0)
> -#define   IOSF_PORT_BUNIT0x3
> -#define   IOSF_PORT_PUNIT0x4
> +#define   IOSF_PORT_BUNIT0x03
> +#define   IOSF_PORT_PUNIT0x04
>  #define   IOSF_PORT_NC   0x11
>  #define   IOSF_PORT_DPIO 0x12
> -#define   IOSF_PORT_DPIO_2   0x1a
>  #define   IOSF_PORT_GPIO_NC  0x13
>  #define   IOSF_PORT_CCK  0x14
> -#define   IOSF_PORT_CCU  0xA9
> +#define   IOSF_PORT_DPIO_2   0x1a
> +#define   IOSF_PORT_FLISDSI  0x1b
>  #define   IOSF_PORT_GPS_CORE 0x48
> -#define   IOSF_PORT_FLISDSI  0x1B
> +#define   IOSF_PORT_CCU  0xa9
>  #define VLV_IOSF_DATA_MMIO(VLV_DISPLAY_BASE 
> + 0x2104)
>  #define VLV_IOSF_ADDR_MMIO(VLV_DISPLAY_BASE 
> + 0x2108)
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present

[Chris Wilson]

On Thu, Feb 04, 2016 at 04:46:55PM +0100, Lukas Wunner wrote:
> > +   /* If the stolen region can be modified behind our backs upon suspend,
> > +* then we cannot use it to store nonvolatile contents (i.e user data)
> > +* as it will be corrupted upon resume.
> > +*/
> > +   dev_priv->mm.nonvolatile_stolen = true;
> > +#ifdef CONFIG_SUSPEND
> > +   if (intel_detect_acpi_rst()) {
> > +   /* BIOSes using RapidStart Technology have been reported
> > +* to overwrite stolen across S3, not just S4.
> > +*/
> > +   dev_priv->mm.nonvolatile_stolen = false;
> > +   }
> > +#endif
> > +
> 
> I'd suggest simplifying it like this:
> 
>   dev_priv->mm.nonvolatile_stolen = !(IS_ENABLED(CONFIG_SUSPEND) &&
>   acpi_dev_present("INT3392"));

Using if (IS_ENABLED(CONFIG_SUSPEND) && intel_detect_acpi_rst()) would
be better indeed. My main concern here is that we document carefully why we had
to disable this, and to leave room for future caveats. Hence my
preference for the verbose layout.

We could #define INTEL_RAPID_START "INT339" for
if (IS_ENABLED(CONFIG_SUSPEND) && acpi_dev_present(INTEL_RAPID_START))
but Anki wanted to keep the acpi details themselves out of stolen (hence
the current split).
-Chris

-- 
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 2/8] drm/i915/dsi: don't pass arbitrary data to sideband

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:50PM +0200, Jani Nikula wrote:
> Since sequence block v2 the second byte contains flags other than just
> pull up/down. Don't pass arbitrary data to the sideband interface.
> 
> The rest may or may not work for sequence block v2, but there should be
> no harm done.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

well, as far as it can be reviewed with the crappy specs.

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 4775aa5462e8..6f013efba45b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -207,7 +207,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   gpio = *data++;
>  
>   /* pull up/down */
> - action = *data++;
> + action = *data++ & 1;
>  
>   if (gpio >= ARRAY_SIZE(gtable)) {
>   DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present

[Lukas Wunner]

Hi,

On Thu, Feb 04, 2016 at 03:00:11PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma 
> 
> The BIOS RapidStartTechnology may corrupt the stolen memory across S3
> suspend due to unalarmed hibernation, in which case we will not be able
> to preserve the User data stored in the stolen region. Hence this patch
> tries to identify presence of the RST device on the ACPI bus, and
> disables use of stolen memory (for persistent data) if found.
> 
> v2: Updated comment, updated/corrected new functions private to driver
> (Chris/Tvrtko)
> 
> v3: Disabling stolen by default, wait till required acpi changes to
> detect device presence are pulled in (Ankit)
> 
> v4: Enabled stolen by default as required acpi changes are merged
> (Ankit)
> 
> Signed-off-by: Ankitprasad Sharma 
> ---
>  drivers/gpu/drm/i915/i915_drv.h| 11 +++
>  drivers/gpu/drm/i915/i915_gem.c|  8 
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 14 ++
>  drivers/gpu/drm/i915/intel_acpi.c  | 10 ++
>  4 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 16f2f94..9d67097 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1349,6 +1349,16 @@ struct i915_gem_mm {
>*/
>   bool busy;
>  
> + /**
> +  * Stolen will be lost upon hibernate (as the memory is unpowered).
> +  * Across resume, we expect stolen to be intact - however, it may
> +  * also be utililised by third parties (e.g. Intel RapidStart
> +  * Technology) and if so we have to assume that any data stored in
> +  * stolen across resume is lost and we set this flag to indicate that
> +  * the stolen memory is volatile.
> +  */
> + bool nonvolatile_stolen;
> +
>   /* the indicator for dispatch video commands on two BSD rings */
>   unsigned int bsd_ring_dispatch_index;
>  
> @@ -3465,6 +3475,7 @@ intel_opregion_notify_adapter(struct drm_device *dev, 
> pci_power_t state)
>  #endif
>  
>  /* intel_acpi.c */
> +bool intel_detect_acpi_rst(void);
>  #ifdef CONFIG_ACPI
>  extern void intel_register_dsm_handler(void);
>  extern void intel_unregister_dsm_handler(void);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0cd57d4..63dab63 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -396,8 +396,16 @@ static struct drm_i915_gem_object *
>  i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
>  {
>   struct drm_i915_gem_object *obj;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + if (!dev_priv->mm.nonvolatile_stolen) {
> + /* Stolen may be overwritten by external parties
> +  * so unsuitable for persistent user data.
> +  */
> + return ERR_PTR(-ENODEV);
> + }
> +
>   mutex_lock(&dev->struct_mutex);
>   obj = i915_gem_object_create_stolen(dev, size);
>   if (IS_ERR(obj))
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 335a1ef..4f44531 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -482,6 +482,20 @@ int i915_gem_init_stolen(struct drm_device *dev)
>*/
>   drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_usable_size);
>  
> + /* If the stolen region can be modified behind our backs upon suspend,
> +  * then we cannot use it to store nonvolatile contents (i.e user data)
> +  * as it will be corrupted upon resume.
> +  */
> + dev_priv->mm.nonvolatile_stolen = true;
> +#ifdef CONFIG_SUSPEND
> + if (intel_detect_acpi_rst()) {
> + /* BIOSes using RapidStart Technology have been reported
> +  * to overwrite stolen across S3, not just S4.
> +  */
> + dev_priv->mm.nonvolatile_stolen = false;
> + }
> +#endif
> +

I'd suggest simplifying it like this:

dev_priv->mm.nonvolatile_stolen = !(IS_ENABLED(CONFIG_SUSPEND) &&
acpi_dev_present("INT3392"));

And add to i915_gem_stolen.c:

#include 

Best regards,

Lukas

>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index eb638a1..67dc9b2 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -23,6 +23,11 @@ static const u8 intel_dsm_guid[] = {
>   0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
>  };
>  
> +static const struct acpi_device_id irst_ids[] = {
> + {"INT3392", 0},
> + {"", 0}
> +};
> +
>  static char *intel_dsm_port_name(u8 id)
>  {
>   switch (id) {
> @@ -162,3 +167,8 @@ void intel_register_dsm_handler(void)
>  void intel_unregister_dsm_handler(void)
>  {
>  }
> +
> +bool intel_detect_acpi_rst(void)
> +{
> + return acpi_dev_present(irst_

[Intel-gfx] [PATCH] drm/i915/skl: Fix typo in DPLL_CFGCR1 definition

[Lyude]

We accidentally point both cfgcr registers for the second shared DPLL to
the same location in i915_reg.h. This results in a lot of hw pipe state
mismatches whenever we try to do a modeset that requires allocating the
DPLL to a CRTC:

[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 
(expected 0x8168, found 0x04a5)
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
base.adjusted_mode.crtc_clock (expected 108000, found 49500)
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 
108000, found 49500)

This usually ends up causing blank monitors, since the DPLL never can
get set to the right clock.

Fixes: f0f59a00a1 ("drm/i915: Type safe register read/write")
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 007ae83..b9a564b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7514,7 +7514,7 @@ enum skl_disp_power_wells {
 #define  DPLL_CFGCR2_PDIV_7 (4<<2)
 #define  DPLL_CFGCR2_CENTRAL_FREQ_MASK (3)
 
-#define DPLL_CFGCR1(id)_MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR1, 
_DPLL2_CFGCR2)
+#define DPLL_CFGCR1(id)_MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR1, 
_DPLL2_CFGCR1)
 #define DPLL_CFGCR2(id)_MMIO_PIPE((id) - SKL_DPLL1, _DPLL1_CFGCR2, 
_DPLL2_CFGCR2)
 
 /* BXT display engine PLL */
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 1/8] drm/i915/dsi: defend gpio table against out of bounds access

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:49PM +0200, Jani Nikula wrote:
> Do not blindly trust the VBT data used for indexing.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 1d43e6f37fc1..4775aa5462e8 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -209,6 +209,11 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   /* pull up/down */
>   action = *data++;
>  
> + if (gpio >= ARRAY_SIZE(gtable)) {
> + DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
> + goto out;
> + }
> +
>   function = gtable[gpio].function_reg;
>   pad = gtable[gpio].pad_reg;
>  
> @@ -226,6 +231,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   vlv_gpio_nc_write(dev_priv, pad, val);
>   mutex_unlock(&dev_priv->sb_lock);
>  
> +out:
>   return data;
>  }
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Extend gpio read/write to other cores

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:55PM +0200, Jani Nikula wrote:
> From: Deepak M 
> 
> Make the gpio read/write functions more generic iosf sideband read/write
> functions, taking the iosf port as argument.
> 
> v2: rebase
> v3: rebase
> v4 by Jani: address Ville's review
> 
> Signed-off-by: Deepak M 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_drv.h| 4 ++--
>  drivers/gpu/drm/i915/i915_reg.h| 2 ++
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +++--
>  drivers/gpu/drm/i915/intel_sideband.c  | 9 +
>  4 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index af601be8b490..47da528c16d0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3475,8 +3475,8 @@ int sandybridge_pcode_write(struct drm_i915_private 
> *dev_priv, u32 mbox, u32 val
>  u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
>  void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
>  u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> +u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
> +void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
> u32 val);
>  u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
>  void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c761fa2f3b8b..d00e5b8e5469 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -618,6 +618,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define   IOSF_PORT_CCK  0x14
>  #define   IOSF_PORT_DPIO_2   0x1a
>  #define   IOSF_PORT_FLISDSI  0x1b
> +#define   IOSF_PORT_GPIO_SC  0x48
> +#define   IOSF_PORT_GPIO_SUS 0xa8
>  #define   IOSF_PORT_CCU  0xa9
>  #define VLV_IOSF_DATA_MMIO(VLV_DISPLAY_BASE 
> + 0x2104)
>  #define VLV_IOSF_ADDR_MMIO(VLV_DISPLAY_BASE 
> + 0x2108)
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 3e1e70f81506..de1966552a33 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -235,14 +235,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   if (!gtable[gpio].init) {
>   /* program the function */
>   /* FIXME: remove constant below */
> - vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
> + vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
> +   0x2000CC00);
>   gtable[gpio].init = 1;
>   }
>  
>   val = 0x4 | action;
>  
>   /* pull up/down */
> - vlv_gpio_nc_write(dev_priv, pad, val);
> + vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
>   mutex_unlock(&dev_priv->sb_lock);
>  
>  out:
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> b/drivers/gpu/drm/i915/intel_sideband.c
> index f5b0ab6f5942..78c3d93fd963 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
> addr)
>   return val;
>  }
>  
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
> +u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg)
>  {
>   u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
> + vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), port,
^

Not correct.

>   SB_CRRDDA_NP, reg, &val);
>   return val;
>  }
>  
> -void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> +void vlv_iosf_sb_write(struct drm_i915_private *dev_priv,
> +u8 port, u32 reg, u32 val)
>  {
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
> + vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), port,

ditto

>   SB_CRWRDA_NP, reg, &val);
>  }
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/8] drm/i915/dsi: skip gpio element execution when not supported

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:52PM +0200, Jani Nikula wrote:
> Skip v3 gpio element because the support is not there, and skip gpio
> element on non-vlv/chv because the sideband code is vlv/chv specific.
> 
> Cc: drm-intel-fi...@lists.freedesktop.org
> Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index f4d303ee538b..3e1e70f81506 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   struct drm_device *dev = intel_dsi->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (dev_priv->vbt.dsi.seq_version >= 3)
> + data++;
> +
>   gpio = *data++;
>  
>   /* pull up/down */
> @@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   goto out;
>   }
>  
> + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> + DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
> + goto out;
> + }

The gpio register table is VLV specific. So CHV shall not pass.

> +
> + if (dev_priv->vbt.dsi.seq_version >= 3) {
> + DRM_DEBUG_KMS("GPIO element v3 not supported\n");
> + goto out;
> + }
> +
>   function = gtable[gpio].function_reg;
>   pad = gtable[gpio].pad_reg;
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Adding the parsing logic for the i2c element

[Ville Syrjälä]

On Thu, Feb 04, 2016 at 12:50:51PM +0200, Jani Nikula wrote:
> From: vkorjani 
> 
> New sequence element for i2c is been added in the
> mipi sequence block of the VBT. This patch parses
> and executes the i2c sequence.
> 
> v2: Add i2c_put_adapter call(Jani), rebase
> 
> v3: corrected the retry loop(Jani), rebase
> 
> v4 by Jani:
>  - don't put the adapter if get fails
>  - print an error message if all retries exhausted
>  - use a for loop
>  - fix warnings for unused variables
> 
> v5 by Jani:
>  - rebase on the skip i2c element patch
> 
> v6: by Jani:
>  - ignore the gmbus i2c elements (Ville)
> 
> Signed-off-by: vkorjani 
> Signed-off-by: Deepak M 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 64 
> --
>  1 file changed, 61 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 6f013efba45b..f4d303ee538b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "i915_drv.h"
> @@ -235,9 +236,66 @@ out:
>   return data;
>  }
>  
> -static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 
> *data)
> +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
>  {
> - return data + *(data + 6) + 7;
> + struct i2c_adapter *adapter;
> + int ret, i;
> + u8 reg_offset, payload_size;
> + struct i2c_msg msg;
> + u8 *transmit_buffer;
> + u8 flag, resource_id, bus_number;
> + u16 slave_add;
> +
> + flag = *data++;
> + resource_id = *data++;
> + bus_number = *data++;
> + slave_add = *(u16 *)(data);
> + data += 2;
> + reg_offset = *data++;
> + payload_size = *data++;
> +
> + if (resource_id == 0xff || bus_number == 0xff) {
> + DRM_DEBUG_KMS("ignoring gmbus (resource id %02x, bus %02x)\n",
> +   resource_id, bus_number);
> + goto out;
> + }
> +

Still missing the check for __i2c_first_dynamic_bus_num which I think
would at least provide some kind of half arsed protection against
something not registering these magic i2c busses.

> + adapter = i2c_get_adapter(bus_number);
> + if (!adapter) {
> + DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
> + goto out;
> + }
> +
> + transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
> + if (!transmit_buffer)
> + goto out_put;
> +
> + transmit_buffer[0] = reg_offset;
> + memcpy(&transmit_buffer[1], data, payload_size);
> +
> + msg.addr = slave_add;
> + msg.flags = 0;
> + msg.len = payload_size + 1;
> + msg.buf = &transmit_buffer[0];
> +
> + for (i = 0; i < 6; i++) {
> + ret = i2c_transfer(adapter, &msg, 1);
> + if (ret == 1) {
> + goto out_free;
> + } else if (ret == -EAGAIN) {
> + usleep_range(1000, 2500);
> + } else {
> + break;
> + }
> + }
> +
> + DRM_ERROR("i2c transfer failed: %d\n", ret);
> +out_free:
> + kfree(transmit_buffer);
> +out_put:
> + i2c_put_adapter(adapter);
> +out:
> + return data + payload_size;
>  }
>  
>  typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
> @@ -246,7 +304,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
>   [MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
>   [MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
>   [MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
> - [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
> + [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
>  };
>  
>  /*
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt 4/9] igt/vc4_wait_bo: Add a test for VC4's wait-for-BO ioctl.

[Daniel Stone]

Hi,

On 3 February 2016 at 21:41, Eric Anholt  wrote:
> +   ret = ioctl(fd, DRM_IOCTL_VC4_WAIT_BO, &arg);
> +   igt_assert(ret == -1 && errno == EINVAL);

A couple of nitpicks: all these should be either do_ioctl() for
success, or do_ioctl_err() for failure, which not only cuts down the
number of lines a bit, but also shows you the exact condition which
occurred (e.g. it'll show that errno was -EBUSY rather than expected
-EINVAL without having to round-trip through the reporter). Similarly,
all your igt_assert(x == y) should be igt_assert_eq(x, y), or any of
the igt_assert_{eq,neq} variants, e.g. _u32 for comparing uint32_t.
You can also use do_or_die(foo) as shorthand for igt_assert_eq(foo,
0).

With those addressed:
Reviewed-by: Daniel Stone 

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

[Intel-gfx] [PATCH xf86-video-intel] Sync PCI ids with latest kernel, adding more BXT devices

[Damien Lespiau]

  commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0
  Author: Imre Deak 
  Date:   Thu Jan 28 16:04:12 2016 +0200

  drm/i915/bxt: update list of PCIIDs

Signed-off-by: Damien Lespiau 
---
 src/i915_pciids.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/i915_pciids.h b/src/i915_pciids.h
index f970209..9b48ac1 100644
--- a/src/i915_pciids.h
+++ b/src/i915_pciids.h
@@ -296,7 +296,9 @@
 #define INTEL_BXT_IDS(info) \
INTEL_VGA_DEVICE(0x0A84, info), \
INTEL_VGA_DEVICE(0x1A84, info), \
-   INTEL_VGA_DEVICE(0x5A84, info)
+   INTEL_VGA_DEVICE(0x1A85, info), \
+   INTEL_VGA_DEVICE(0x5A84, info), /* APL HD Graphics 505 */ \
+   INTEL_VGA_DEVICE(0x5A85, info)  /* APL HD Graphics 500 */
 
 #define INTEL_KBL_GT1_IDS(info)\
INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

[Deepak, M]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, February 4, 2016 7:28 PM
> To: Deepak, M ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider
> form B0 stepping onwards
> 
> On Thu, 04 Feb 2016, "Deepak, M"  wrote:
> >> -Original Message-
> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >> Sent: Thursday, February 4, 2016 6:29 PM
> >> To: Deepak, M ; intel-gfx@lists.freedesktop.org
> >> Cc: Deepak, M 
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock
> >> divider form B0 stepping onwards
> >>
> >> On Wed, 03 Feb 2016, Deepak M  wrote:
> >> > The MIPI clock calculations for the addtional clock are revised
> >> > from
> >> > B0 stepping onwards, the bit definitions have changed compared to
> >> > old stepping.
> >> >
> >> > v2: Fixing compilation warning.
> >>
> >> Why did you move and rename everything when it was not needed?
> >>
> >> BR,
> >> Jani.
> >>
> > [Deepak, M] I have deleted the old macro and added the new as per the
> new definitions. With the new bit fields nothing was matching as that of the
> old.
> 
> It's not nothing. Plenty of masks and shifts matched, but you had renamed
> the defines.
> 
> Besides, please don't move the definitions where they don't belong. We also
> have the convention of specifying the bits from highest to lowest.
> 
[Deepak, M] Okay, will fix the macro`s, are there any changes required in the 
function.
> >>
> >> >
> >> > Signed-off-by: Deepak M 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_reg.h  | 104 +-
> ---
> >> --
> >> >  drivers/gpu/drm/i915/intel_dsi_pll.c |  64 ++---
> >> >  2 files changed, 95 insertions(+), 73 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> > b/drivers/gpu/drm/i915/i915_reg.h index c0bd691..2568f35 100644
> >> > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > @@ -7638,6 +7638,57 @@ enum skl_disp_power_wells {
> >> >
> >> >  /* MIPI DSI registers */
> >> >
> >> > +#define  BXT_MIPI1_RX_LOWER_SHIFT   16
> >> > +#define  BXT_MIPI2_RX_LOWER_SHIFT   0
> >> > +#define  BXT_MIPI_RX_LOWER_SHIFT(port)  \
> >> > +_MIPI_PORT(port, BXT_MIPI1_RX_LOWER_SHIFT, \
> >> > +BXT_MIPI2_RX_LOWER_SHIFT)
> >> > +#define  BXT_MIPI1_RX_LOWER_DIVIDER_MASK(3 << 16)
> >> > +#define  BXT_MIPI2_RX_LOWER_DIVIDER_MASK(3 << 0)
> >> > +#define  BXT_MIPI_RX_LOWER_DIVIDER_MASK(port)   \
> >> > +(3 << BXT_MIPI_RX_LOWER_SHIFT(port))
> >> > +#define  BXT_MIPI_RX_LOWER_DIVIDER(port, val)   \
> >> > +((val & 3) << BXT_MIPI_RX_LOWER_SHIFT(port))
> >> > +
> >> > +#define  BXT_MIPI1_8X_BY3_SHIFT 19
> >> > +#define  BXT_MIPI2_8X_BY3_SHIFT 3
> >> > +#define  BXT_MIPI_8X_BY3_SHIFT(port)  \
> >> > +_MIPI_PORT(port, BXT_MIPI1_8X_BY3_SHIFT, \
> >> > +BXT_MIPI2_8X_BY3_SHIFT)
> >> > +#define  BXT_MIPI1_8X_BY3_DIVIDER_MASK  (3 << 19)
> >> > +#define  BXT_MIPI2_8X_BY3_DIVIDER_MASK  (3 << 3)
> >> > +#define  BXT_MIPI_8X_BY3_DIVIDER_MASK(port) \
> >> > +(3 << BXT_MIPI_8X_BY3_SHIFT(port))
> >> > +#define  BXT_MIPI_8X_BY3_DIVIDER(port, val) \
> >> > +((val & 3) << BXT_MIPI_8X_BY3_SHIFT(port))
> >> > +
> >> > +#define  BXT_MIPI1_RX_UPPER_SHIFT   21
> >> > +#define  BXT_MIPI2_RX_UPPER_SHIFT   5
> >> > +#define  BXT_MIPI_RX_UPPER_SHIFT(port)  \
> >> > +_MIPI_PORT(port, BXT_MIPI1_RX_UPPER_SHIFT, \
> >> > +BXT_MIPI2_RX_UPPER_SHIFT)
> >> > +#define  BXT_MIPI1_RX_UPPER_DIVIDER_MASK(3 << 21)
> >> > +#define  BXT_MIPI2_RX_UPPER_DIVIDER_MASK(3 << 5)
> >> > +#define  BXT_MIPI_RX_UPPER_DIVIDER_MASK(port)   \
> >> > +(3 << BXT_MIPI_RX_UPPER_SHIFT(port))
> >> > +#define  BXT_MIPI_RX_UPPER_DIVIDER(port, val)   \
> >> > +((val & 3) << BXT_MIPI_RX_UPPER_SHIFT(port))
> >> > +
> >> > +#define  BXT_MIPI1_TX_SHIFT 26
> >> > +#define  BXT_MIPI2_TX_SHIFT 10
> >> > +#define  BXT_MIPI_TX_SHIFT(port)\
> >> > +_MIPI_PORT(port, BXT_MIPI1_TX_SHIFT, \
> >> > +BXT_MIPI2_TX_SHIFT)
> >> > +#define  BXT_MIPI1_TX_DIVIDER_MASK  (0x3F << 26)
> >> > +#define  BXT_MIPI2_TX_DIVIDER_MASK  (0x3F << 10)
> >> > +#define  BXT_MIPI_TX_DIVIDER_MASK(port) \
> >> > +(0x3F << BXT_MIPI_TX_SHIFT(port))
> >> > +#define  BXT_MIPI_TX_DIVIDER(port, val) \
> >> > +((val & 0x3F) << BXT_MIPI_TX_SHIFT(port))
> >> > +
> >> > +#define RX_DIVIDER_BIT_1_2   

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

On Thu, Feb 4, 2016 at 1:17 PM, Robert Bragg  wrote:

>
> On Thu, Feb 4, 2016 at 1:42 AM, Emil Velikov 
> wrote:
>
>> On 3 February 2016 at 18:39, Robert Bragg  wrote:
>>
>>>
>>> > +};
>>> > +
>>> > +struct drm_i915_perf_open_param {
>>> > +   /** CLOEXEC, NONBLOCK... */
>>> > +   __u32 flags;
>>> > +
>>> And ... we broke 32 bit userspare on 64 bit kernels. Please check for
>>> holes and other issues as described in Daniel Vetter's
>>> article/documentation [1]
>>>
>>> [1]
>>> https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt
>>
>>
>> Ah yeah, don't think this would break 32bit userspace, but still would be
>> good to remove that hole, this has been through a few iterations and there
>> used to be a __u32 type here, well spotted thanks.
>>
>> I think I'll bump the flags to be 64bit.
>>
>>
>
Actually, just noticed that since the structure has a u32 hole at the end
too I can move the trailing u32 num_properties up into here instead.

Am also renaming properties to properties_ptr which seems the norm in
i915_drm.h.

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: implement WaIncreaseDefaultTLBEntries

[Tvrtko Ursulin]

On 04/02/16 13:09, Patchwork wrote:

== Summary ==

Series 3077v1 drm/i915: implement WaIncreaseDefaultTLBEntries
http://patchwork.freedesktop.org/api/1.0/series/3077/revisions/1/mbox/

Test gem_sync:
 Subgroup basic-blt:
 incomplete -> PASS   (skl-i5k-2)

bdw-nuci7total:161  pass:152  dwarn:0   dfail:0   fail:0   skip:9
bdw-ultratotal:164  pass:152  dwarn:0   dfail:0   fail:0   skip:12
byt-nuc  total:164  pass:141  dwarn:0   dfail:0   fail:0   skip:23
hsw-brixbox  total:164  pass:151  dwarn:0   dfail:0   fail:0   skip:13
hsw-gt2  total:164  pass:154  dwarn:0   dfail:0   fail:0   skip:10
ilk-hp8440p  total:164  pass:116  dwarn:0   dfail:0   fail:0   skip:48
ivb-t430stotal:164  pass:150  dwarn:0   dfail:0   fail:0   skip:14
skl-i5k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14
skl-i7k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14
snb-dellxps  total:164  pass:142  dwarn:0   dfail:0   fail:0   skip:22
snb-x220ttotal:164  pass:142  dwarn:0   dfail:0   fail:1   skip:21

Results at /archive/results/CI_IGT_test/Patchwork_1364/

82b0b8e5fd2d7b63877c91cbe45138efbc46114e drm-intel-nightly: 
2016y-02m-04d-11h-00m-00s UTC integration manifest
d6a44d13ce71c2a8dcbaaa6e38fcd06b634d2b50 drm/i915: implement 
WaIncreaseDefaultTLBEntries


Patch merged.

Regards,

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

[Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: Don't suspend the machine if

[Marius Vlad]

suspend-read-crc-pipe will perform a suspend and then skip the test in case the
pipe is not present on the platform. Skip the test before doing the suspend.


Signed-off-by: Marius Vlad 
---
 tests/kms_pipe_crc_basic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index 3c51ba0..dbb2919 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -271,6 +271,7 @@ igt_main
test_read_crc(&data, i, TEST_SEQUENCE | TEST_NONBLOCK);
 
igt_subtest_f("suspend-read-crc-pipe-%c", 'A'+i) {
+   igt_skip_on(i >= data.display.n_pipes);
igt_system_suspend_autoresume();
 
test_read_crc(&data, i, 0);
-- 
2.7.0

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

[Jani Nikula]

On Thu, 04 Feb 2016, "Deepak, M"  wrote:
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Thursday, February 4, 2016 6:29 PM
>> To: Deepak, M ; intel-gfx@lists.freedesktop.org
>> Cc: Deepak, M 
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider
>> form B0 stepping onwards
>> 
>> On Wed, 03 Feb 2016, Deepak M  wrote:
>> > The MIPI clock calculations for the addtional clock are revised from
>> > B0 stepping onwards, the bit definitions have changed compared to old
>> > stepping.
>> >
>> > v2: Fixing compilation warning.
>> 
>> Why did you move and rename everything when it was not needed?
>> 
>> BR,
>> Jani.
>> 
> [Deepak, M] I have deleted the old macro and added the new as per the new 
> definitions. With the new bit fields nothing was matching as that of the old. 

It's not nothing. Plenty of masks and shifts matched, but you had
renamed the defines.

Besides, please don't move the definitions where they don't belong. We
also have the convention of specifying the bits from highest to lowest.

>> 
>> >
>> > Signed-off-by: Deepak M 
>> > ---
>> >  drivers/gpu/drm/i915/i915_reg.h  | 104 +
>> --
>> >  drivers/gpu/drm/i915/intel_dsi_pll.c |  64 ++---
>> >  2 files changed, 95 insertions(+), 73 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h index c0bd691..2568f35 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -7638,6 +7638,57 @@ enum skl_disp_power_wells {
>> >
>> >  /* MIPI DSI registers */
>> >
>> > +#define  BXT_MIPI1_RX_LOWER_SHIFT 16
>> > +#define  BXT_MIPI2_RX_LOWER_SHIFT 0
>> > +#define  BXT_MIPI_RX_LOWER_SHIFT(port)\
>> > +  _MIPI_PORT(port, BXT_MIPI1_RX_LOWER_SHIFT, \
>> > +  BXT_MIPI2_RX_LOWER_SHIFT)
>> > +#define  BXT_MIPI1_RX_LOWER_DIVIDER_MASK  (3 << 16)
>> > +#define  BXT_MIPI2_RX_LOWER_DIVIDER_MASK  (3 << 0)
>> > +#define  BXT_MIPI_RX_LOWER_DIVIDER_MASK(port) \
>> > +  (3 << BXT_MIPI_RX_LOWER_SHIFT(port))
>> > +#define  BXT_MIPI_RX_LOWER_DIVIDER(port, val) \
>> > +  ((val & 3) << BXT_MIPI_RX_LOWER_SHIFT(port))
>> > +
>> > +#define  BXT_MIPI1_8X_BY3_SHIFT   19
>> > +#define  BXT_MIPI2_8X_BY3_SHIFT   3
>> > +#define  BXT_MIPI_8X_BY3_SHIFT(port)  \
>> > +  _MIPI_PORT(port, BXT_MIPI1_8X_BY3_SHIFT, \
>> > +  BXT_MIPI2_8X_BY3_SHIFT)
>> > +#define  BXT_MIPI1_8X_BY3_DIVIDER_MASK(3 << 19)
>> > +#define  BXT_MIPI2_8X_BY3_DIVIDER_MASK(3 << 3)
>> > +#define  BXT_MIPI_8X_BY3_DIVIDER_MASK(port)   \
>> > +  (3 << BXT_MIPI_8X_BY3_SHIFT(port))
>> > +#define  BXT_MIPI_8X_BY3_DIVIDER(port, val)   \
>> > +  ((val & 3) << BXT_MIPI_8X_BY3_SHIFT(port))
>> > +
>> > +#define  BXT_MIPI1_RX_UPPER_SHIFT 21
>> > +#define  BXT_MIPI2_RX_UPPER_SHIFT 5
>> > +#define  BXT_MIPI_RX_UPPER_SHIFT(port)\
>> > +  _MIPI_PORT(port, BXT_MIPI1_RX_UPPER_SHIFT, \
>> > +  BXT_MIPI2_RX_UPPER_SHIFT)
>> > +#define  BXT_MIPI1_RX_UPPER_DIVIDER_MASK  (3 << 21)
>> > +#define  BXT_MIPI2_RX_UPPER_DIVIDER_MASK  (3 << 5)
>> > +#define  BXT_MIPI_RX_UPPER_DIVIDER_MASK(port) \
>> > +  (3 << BXT_MIPI_RX_UPPER_SHIFT(port))
>> > +#define  BXT_MIPI_RX_UPPER_DIVIDER(port, val) \
>> > +  ((val & 3) << BXT_MIPI_RX_UPPER_SHIFT(port))
>> > +
>> > +#define  BXT_MIPI1_TX_SHIFT   26
>> > +#define  BXT_MIPI2_TX_SHIFT   10
>> > +#define  BXT_MIPI_TX_SHIFT(port)  \
>> > +  _MIPI_PORT(port, BXT_MIPI1_TX_SHIFT, \
>> > +  BXT_MIPI2_TX_SHIFT)
>> > +#define  BXT_MIPI1_TX_DIVIDER_MASK(0x3F << 26)
>> > +#define  BXT_MIPI2_TX_DIVIDER_MASK(0x3F << 10)
>> > +#define  BXT_MIPI_TX_DIVIDER_MASK(port)   \
>> > +  (0x3F << BXT_MIPI_TX_SHIFT(port))
>> > +#define  BXT_MIPI_TX_DIVIDER(port, val)   \
>> > +  ((val & 0x3F) << BXT_MIPI_TX_SHIFT(port))
>> > +
>> > +#define RX_DIVIDER_BIT_1_20x3
>> > +#define RX_DIVIDER_BIT_3_40xC
>> > +
>> >  #define _MIPI_PORT(port, a, c)_PORT3(port, a, 0, c)   /* ports A
>> and C only */
>> >  #define _MMIO_MIPI(port, a, c)_MMIO(_MIPI_PORT(port, a, c))
>> >
>> > @@ -7650,59 +7701,6 @@ enum skl_disp_power_wells {
>> >  #define  BXT_MIPI_DIV_SHIFT(port) \
>> >_MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
>> >BXT_MIPI2_DIV_SHIFT)
>> > -/* Var clock divider to generate TX source. Result must be < 39.5 M */
>> > -#define  BXT_MIPI1_ESCLK_VAR_DIV_MASK (0x3F << 26)
>> > -#define  BXT_MIPI2_ESCLK_VAR_DIV_MASK (0x3F << 10)

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Fixed COS blanking issue

[Jani Nikula]

On Wed, 03 Feb 2016, Ramalingam C  wrote:
> From: Uma Shankar 
>
> During Charging OS mode, mipi display was blanking.This is
> because during driver load, though encoder, connector were
> active but crtc returned inactive. This caused sanitize
> function to disable the DSI panel. In AOS, this is fine
> since HWC will do a modeset and crtc, connector, encoder
> mapping will be restored. But in COS, no modeset is called,
> it just calls DPMS ON/OFF.
>
> This is fine on BYT/CHT since transcoder is common b/w
> all encoders. But for BXT, there is a separate mipi
> transcoder. Hence this needs special handling for BXT.
>
> Signed-off-by: Uma Shankar 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  115 
> --
>  1 file changed, 109 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a66220a..58d2cd9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include "intel_drv.h"
> +#include "intel_dsi.h"
>  #include 
>  #include "i915_drv.h"
>  #include "i915_trace.h"
> @@ -7814,6 +7815,69 @@ static void intel_set_pipe_timings(struct intel_crtc 
> *intel_crtc)
>  (intel_crtc->config->pipe_src_h - 1));
>  }
>  
> +static void intel_get_dsi_pipe_timings(struct intel_crtc *crtc,
> +struct intel_crtc_state *pipe_config)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;

Hum, how does this work for DSI transcoders.

> + struct intel_encoder *encoder;
> + uint32_t tmp;
> +
> + tmp = I915_READ(HTOTAL(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_hdisplay = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_htotal =
> + ((tmp >> 16) & 0x) + 1;
> + tmp = I915_READ(HBLANK(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_hblank_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_hblank_end =
> + ((tmp >> 16) & 0x) + 1;
> + tmp = I915_READ(HSYNC(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_hsync_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_hsync_end =
> + ((tmp >> 16) & 0x) + 1;
> +
> + tmp = I915_READ(VBLANK(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_vblank_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_vblank_end =
> + ((tmp >> 16) & 0x) + 1;
> + tmp = I915_READ(VSYNC(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_vsync_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_vsync_end =
> + ((tmp >> 16) & 0x) + 1;
> +
> + if (I915_READ(PIPECONF(cpu_transcoder)) & PIPECONF_INTERLACE_MASK) {
> + pipe_config->base.adjusted_mode.flags |=
> + DRM_MODE_FLAG_INTERLACE;
> + pipe_config->base.adjusted_mode.crtc_vtotal += 1;
> + pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
> + }
> +
> +
> + for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
> + struct intel_dsi *intel_dsi =
> + enc_to_intel_dsi(&encoder->base);
> + enum port port;
> +
> + pipe_config->pipe_bpp = intel_dsi->dsi_bpp;
> + for_each_dsi_port(port, intel_dsi->ports) {
> + pipe_config->base.adjusted_mode.crtc_hdisplay =
> + I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
> + pipe_config->base.adjusted_mode.crtc_vdisplay =
> + I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
> + pipe_config->base.adjusted_mode.crtc_vtotal =
> + I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
> + }
> + }

Since you already figure out the port/pipe in bxt_get_pipe_config_dsi, I
feel it would be better to use that instead of doing the for loops here
and semi-blindly casting the encoder to intel_dsi.

> +
> + tmp = I915_READ(PIPESRC(crtc->pipe));
> + pipe_config->pipe_src_h = (tmp & 0x) + 1;
> + pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> +
> + pipe_config->base.mode.vdisplay = pipe_config->pipe_src_h;
> + pipe_config->base.mode.hdisplay = pipe_config->pipe_src_w;
> +}

What's the point of duplicating most of intel_get_pipe_timings() when
you could just call that first, and then do your bxt dsi specific stuff?
I can't spot any differences.

Do we even need to read the generic HTOTAL etc. registe

Re: [Intel-gfx] [PATCH] drm/i915: Mitigate retirement starvation a bit

[Chris Wilson]

On Thu, Feb 04, 2016 at 01:30:30PM +, Tvrtko Ursulin wrote:
> On 04/02/16 12:40, Chris Wilson wrote:
> >The most effective treatment I found is moving the retire-requests from
> >execbuf (which exists for similar reasons) to get-pages.
> >
> >http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=75f4e53f1c9141ba2dd8847396a1bcc8dbeecd55
> 
> I struggle to understand how it is OK to stall get pages or even the
> object close when you objected to those in the past?

Note also this reduces the number of those stalls.
-Chris

-- 
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] drm/i915: Mitigate retirement starvation a bit

[Chris Wilson]

On Thu, Feb 04, 2016 at 01:30:30PM +, Tvrtko Ursulin wrote:
> 
> 
> On 04/02/16 12:40, Chris Wilson wrote:
> >On Thu, Feb 04, 2016 at 12:25:24PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>In execlists mode internal house keeping of the discarded
> >>requests (and so contexts and VMAs) relies solely on the retire
> >>worker, which can be prevented from running by just being
> >>unlucky when busy clients are hammering on the big lock.
> >>
> >>Prime example is the gem_close_race IGT, which due to this
> >>effect causes internal lists to grow to epic proportions, with
> >>a consequece of object VMA traversal to growing exponentially
> >>and resulting in tens of minutes test runtime. Memory use is
> >>also very high and a limiting factor on some platforms.
> >>
> >>Since we do not want to run this internal house keeping more
> >>frequently, due concerns that it may affect performance, and
> >>the scenario being statistically not very likely in real
> >>workloads, one possible workaround is to run it when new
> >>client handles are opened.
> >>
> >>This will solve the issues with this particular test case,
> >>making it complete in tens of seconds instead of tens of
> >>minutes, and will not add any run-time penalty to running
> >>clients.
> >>
> >>It can only slightly slow down new client startup, but on a
> >>realisticaly loaded system we are expecting this to be not
> >>significant. Even with heavy rendering in progress we can have
> >>perhaps up to several thousands of requests pending retirement,
> >>which, with a typical retirement cost of 80ns to 1us per
> >>request, is not significant.
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>Testcase: igt/gem_close_race/gem-close-race
> >>Cc: Chris Wilson 
> >
> >Still doesn't fix actual workloads where this is demonstrably bad, which
> >can be demonstrated with a single fd.
> 
> Which are those?

OglDrvCtx and clones.

> >The most effective treatment I found is moving the retire-requests from
> >execbuf (which exists for similar reasons) to get-pages.
> >
> >http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=75f4e53f1c9141ba2dd8847396a1bcc8dbeecd55
> 
> I struggle to understand how it is OK to stall get pages or even the
> object close when you objected to those in the past?

Benchmarks. Taking a hit here avoids situations that end up invoking the
shrinker.
-Chris

-- 
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] drm/i915/bxt: Added identifier for MIPI transcoder.

[Jani Nikula]

On Thu, 04 Feb 2016, Jani Nikula  wrote:
> On Wed, 03 Feb 2016, Animesh Manna  wrote:
>> Changes done:
>> - Added identifier for Mipi transcoder A and C.
>> - Added power domain identifier for newly added mipi trancoder.
>> - Initialized transcoder for mipi during compute config.
>
> Please separate the power domain control from the addition of the
> transcoders. I think the former is safer to go in.

Hmm, that probably doesn't work either. But this would require a
thorough checking of *all* uses of cpu_transcoder in bxt code paths,
ensuring we don't accidentally index registers with DSI transcoders. And
you'll also notice the transcoders are not at uniformly spread register
offsets, so you can't just assume whatever value TRANSCODER_MIPI_A will
get will be the right offset when used as cpu_transcoder.

See for example what [1] does and imagine TRANSCODER_MIPI_A for HTOTAL
et al.

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1454502456-10556-2-git-send-email-ramalinga...@intel.com


>
> BR,
> Jani.
>
>
>>
>> v1: Initial RFC version.
>>
>> v2: Rebased on tot.
>>
>> Cc: Jani Nikula 
>> Signed-off-by: Animesh Manna 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h | 4 
>>  drivers/gpu/drm/i915/intel_dsi.c| 8 
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 6 ++
>>  3 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 65a2cd0..c484df8 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -122,6 +122,8 @@ enum transcoder {
>>  TRANSCODER_B,
>>  TRANSCODER_C,
>>  TRANSCODER_EDP,
>> +TRANSCODER_MIPI_A,
>> +TRANSCODER_MIPI_C,
>>  I915_MAX_TRANSCODERS
>>  };
>>  #define transcoder_name(t) ((t) + 'A')
>> @@ -176,6 +178,8 @@ enum intel_display_power_domain {
>>  POWER_DOMAIN_TRANSCODER_B,
>>  POWER_DOMAIN_TRANSCODER_C,
>>  POWER_DOMAIN_TRANSCODER_EDP,
>> +POWER_DOMAIN_TRANSCODER_MIPI_A,
>> +POWER_DOMAIN_TRANSCODER_MIPI_C,
>>  POWER_DOMAIN_PORT_DDI_A_LANES,
>>  POWER_DOMAIN_PORT_DDI_B_LANES,
>>  POWER_DOMAIN_PORT_DDI_C_LANES,
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 91cef35..4f2b513 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -273,6 +273,7 @@ static bool intel_dsi_compute_config(struct 
>> intel_encoder *encoder,
>>  struct intel_connector *intel_connector = intel_dsi->attached_connector;
>>  struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
>>  struct drm_display_mode *adjusted_mode = 
>> &pipe_config->base.adjusted_mode;
>> +struct drm_device *dev = intel_connector->base.dev;
>>  
>>  DRM_DEBUG_KMS("\n");
>>  
>> @@ -284,6 +285,13 @@ static bool intel_dsi_compute_config(struct 
>> intel_encoder *encoder,
>>  /* DSI uses short packets for sync events, so clear mode flags for DSI 
>> */
>>  adjusted_mode->flags = 0;
>>  
>> +if (IS_BROXTON(dev)) {
>> +if (intel_dsi->ports & (1 << PORT_A))
>> +pipe_config->cpu_transcoder = TRANSCODER_MIPI_A;
>> +else
>> +pipe_config->cpu_transcoder = TRANSCODER_MIPI_C;
>> +}
>> +
>>  return true;
>>  }
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index bbca527..611dc1e 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -87,6 +87,10 @@ intel_display_power_domain_str(enum 
>> intel_display_power_domain domain)
>>  return "TRANSCODER_B";
>>  case POWER_DOMAIN_TRANSCODER_C:
>>  return "TRANSCODER_C";
>> +case POWER_DOMAIN_TRANSCODER_MIPI_A:
>> +return "TRANSCODER_MIPI_A";
>> +case POWER_DOMAIN_TRANSCODER_MIPI_C:
>> +return "TRANSCODER_MIPI_C";
>>  case POWER_DOMAIN_TRANSCODER_EDP:
>>  return "TRANSCODER_EDP";
>>  case POWER_DOMAIN_PORT_DDI_A_LANES:
>> @@ -403,6 +407,8 @@ static void hsw_set_power_well(struct drm_i915_private 
>> *dev_priv,
>>  BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>>  BIT(POWER_DOMAIN_PIPE_A) |  \
>>  BIT(POWER_DOMAIN_TRANSCODER_EDP) |  \
>> +BIT(POWER_DOMAIN_TRANSCODER_MIPI_A) |   \
>> +BIT(POWER_DOMAIN_TRANSCODER_MIPI_C) |   \
>>  BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
>>  BIT(POWER_DOMAIN_PORT_DDI_A_LANES) |\
>>  BIT(POWER_DOMAIN_AUX_A) |   \

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Mitigate retirement starvation a bit

[Tvrtko Ursulin]

On 04/02/16 12:40, Chris Wilson wrote:

On Thu, Feb 04, 2016 at 12:25:24PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In execlists mode internal house keeping of the discarded
requests (and so contexts and VMAs) relies solely on the retire
worker, which can be prevented from running by just being
unlucky when busy clients are hammering on the big lock.

Prime example is the gem_close_race IGT, which due to this
effect causes internal lists to grow to epic proportions, with
a consequece of object VMA traversal to growing exponentially
and resulting in tens of minutes test runtime. Memory use is
also very high and a limiting factor on some platforms.

Since we do not want to run this internal house keeping more
frequently, due concerns that it may affect performance, and
the scenario being statistically not very likely in real
workloads, one possible workaround is to run it when new
client handles are opened.

This will solve the issues with this particular test case,
making it complete in tens of seconds instead of tens of
minutes, and will not add any run-time penalty to running
clients.

It can only slightly slow down new client startup, but on a
realisticaly loaded system we are expecting this to be not
significant. Even with heavy rendering in progress we can have
perhaps up to several thousands of requests pending retirement,
which, with a typical retirement cost of 80ns to 1us per
request, is not significant.

Signed-off-by: Tvrtko Ursulin 
Testcase: igt/gem_close_race/gem-close-race
Cc: Chris Wilson 


Still doesn't fix actual workloads where this is demonstrably bad, which
can be demonstrated with a single fd.


Which are those?


The most effective treatment I found is moving the retire-requests from
execbuf (which exists for similar reasons) to get-pages.

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=75f4e53f1c9141ba2dd8847396a1bcc8dbeecd55


I struggle to understand how it is OK to stall get pages or even the 
object close when you objected to those in the past?


Regards,

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mitigate retirement starvation a bit

[Patchwork]

== Summary ==

Series 3079v1 drm/i915: Mitigate retirement starvation a bit
http://patchwork.freedesktop.org/api/1.0/series/3079/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (skl-i5k-2)

bdw-nuci7total:161  pass:152  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultratotal:164  pass:152  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:164  pass:136  dwarn:0   dfail:0   fail:0   skip:28 
hsw-brixbox  total:164  pass:151  dwarn:0   dfail:0   fail:0   skip:13 
hsw-gt2  total:164  pass:154  dwarn:0   dfail:0   fail:0   skip:10 
ilk-hp8440p  total:164  pass:116  dwarn:0   dfail:0   fail:0   skip:48 
ivb-t430stotal:164  pass:150  dwarn:0   dfail:0   fail:0   skip:14 
skl-i5k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14 
skl-i7k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14 
snb-dellxps  total:164  pass:142  dwarn:0   dfail:0   fail:0   skip:22 
snb-x220ttotal:164  pass:142  dwarn:0   dfail:0   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1365/

82b0b8e5fd2d7b63877c91cbe45138efbc46114e drm-intel-nightly: 
2016y-02m-04d-11h-00m-00s UTC integration manifest
064b71b007c661c6a9558ab929739354e1529260 drm/i915: Mitigate retirement 
starvation a bit

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

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

On Thu, Feb 4, 2016 at 1:42 AM, Emil Velikov 
wrote:

> On 3 February 2016 at 18:39, Robert Bragg  wrote:
>
> > index a5524cc..68ca26e 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
>
> > @@ -1170,4 +1172,71 @@ struct drm_i915_gem_context_param {
> > __u64 value;
> >  };
> >
> > +#define I915_PERF_FLAG_FD_CLOEXEC  (1<<0)
> > +#define I915_PERF_FLAG_FD_NONBLOCK (1<<1)
> > +#define I915_PERF_FLAG_DISABLED(1<<2)
> > +
> > +enum drm_i915_perf_property_id {
> > +   /**
> > +* Open the stream for a specific context handle (as used with
> > +* execbuffer2). A stream opened for a specific context this way
> > +* won't typically require root privileges.
> > +*/
> > +   DRM_I915_PERF_CTX_HANDLE_PROP = 1,
> > +
> Wouldn't DRM_I915_PERF_PROP_CTX_HANDLE be a better name ? It's more
> obvious at least :-P
>

Yeah would be more consistent to keep the common namespacing at the front.


>
> > +   DRM_I915_PERF_PROP_MAX /* non-ABI */
> Isn't the use of enums (in drm UAPI) discouraged ? Afaics only the old
> DRI1 i915 code has them.
> Same question applies throughout the patch/series.
>

An enum here seems like a pretty good technical fit. I think the potential
for different enums to have different sizes is a likely reason for being
cautious about using them as part of a kernel ABI (so probably unwise to
have enum based members in an ioctl structure) but in this case these IDs
are always passed to the kernel as a u64. We benefit from the compiler
reminding us to handle all properties in the driver if we switch on this
enum which I like, as well as having the _MAX value to refer to in the
driver which is perhaps a little more reliable at the end of an enum vs a
#define which needs to be explicitly updated for each addition.

For reference, the first iteration of this driver was based on the core
pref infrastructure and in this case the enum + _MAX /* non-ABI */ approach
is borrowed from there (ref: include/uapi/linux/perf_event.h)


> > +};
> > +
> > +struct drm_i915_perf_open_param {
> > +   /** CLOEXEC, NONBLOCK... */
> Some other places in i915 define the macros just after the __u32
> flags. This will allow you to drop the comment ;-)
>
> > +   __u32 flags;
> > +
> And ... we broke 32 bit userspare on 64 bit kernels. Please check for
> holes and other issues as described in Daniel Vetter's
> article/documentation [1]
>
> [1] https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt


Ah yeah, don't think this would break 32bit userspace, but still would be
good to remove that hole, this has been through a few iterations and there
used to be a __u32 type here, well spotted thanks.

I think I'll bump the flags to be 64bit.


>
>
> > +   /**
> > +* Pointer to array of u64 (id, value) pairs configuring the
> stream
> > +* to open.
> > +*/
> > +   __u64 __user properties;
> > +
> > +   /** The number of u64 (id, value) pairs */
> > +   __u32 n_properties;
> The rest of the file uses num_foo or foo_count. Can we opt for one of
> those ?
>

Ah yep, num_properties looks good to me.


>
> > +};
> > +
> > +#define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
> > +#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
> > +
> > +/**
> > + * Common to all i915 perf records
> > + */
> > +struct drm_i915_perf_record_header {
> > +   __u32 type;
> > +   __u16 pad;
> Move pad at the end ? This way we can (maybe?) reuse it in the future.
>

This header was originally based on struct perf_event_header which is layed
out with the padding in the middle too. I can't currently think of a strong
reason to maintain a record header that's ABI compatible with perf, but
/maybe/ it could be convenient in some case to have a common layout for
profiling tools that deal with both. I think we can consider it reserved
for future use either way.


>
> > +   __u16 size;
> > +};
> > +
>
> Daniel, is there a consensus about zeroing the pad from userspace and
> checking it for garbage in the ioctl ? The documentation says "do it",
> yet I have a hunch that we're missing a few. Also what error should
> the ioctl return in such a case - EINVAL or EFAULT ? Worth
> documenting, just in case ?
>

In case you're wondering about the padding in the header above, note that
this header never gets passed in from userspace, it's a header for data
read by userspace and the driver zeros the padding.

For the hole in the ioctl I'll probably fill that by extending the flags
member and the driver currently returns -EINVAL if any unknown flag bits
are set by userspace.


Thanks for looking through this,
- Robert


>
> -Emil
>
___
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: Using the bpp value wrt the pixel format

[Jani Nikula]

On Wed, 03 Feb 2016, Ramalingam C  wrote:
> From: Deepak M 
>
> The bpp value which is used while calulating the txbyteclkhs values
> should be wrt the pixel format value. Currently bpp is coming
> from pipe config to calculate txbyteclkhs. Fix it in this patch.
>
> Signed-off-by: Deepak M 
> Signed-off-by: Yogesh Mohan Marimuthu 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c   |5 ++---
>  drivers/gpu/drm/i915/intel_dsi.h   |1 +
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |1 +
>  3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 91cef35..aa11293 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -775,10 +775,9 @@ static void set_dsi_timings(struct drm_encoder *encoder,
>  {
>   struct drm_device *dev = encoder->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>   enum port port;
> - unsigned int bpp = intel_crtc->config->pipe_bpp;
> + unsigned int bpp = intel_dsi->dsi_bpp;
>   unsigned int lane_count = intel_dsi->lane_count;
>  
>   u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
> @@ -849,7 +848,7 @@ static void intel_dsi_prepare(struct intel_encoder 
> *intel_encoder)
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>   const struct drm_display_mode *adjusted_mode = 
> &intel_crtc->config->base.adjusted_mode;
>   enum port port;
> - unsigned int bpp = intel_crtc->config->pipe_bpp;
> + unsigned int bpp = intel_dsi->dsi_bpp;
>   u32 val, tmp;
>   u16 mode_hdisplay;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index de7be7f..9bf6fa1d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -64,6 +64,7 @@ struct intel_dsi {
>  
>   /* video mode pixel format for MIPI_DSI_FUNC_PRG register */
>   u32 pixel_format;
> + u32 dsi_bpp;

Please never add extra state for things that can trivially be derived
from existing information.

Given the dsi_pixel_format_bpp() in intel_dsi_pll.c, this should always
hold, right:

intel_dsi->dsi_bpp == dsi_pixel_format_bpp(intel_dsi->pixel_format)

Please just make dsi_pixel_format_bpp() available and use it. As a nice
bonus, this becomes self-documenting code on why pipe config is not used
where the bpp based on pixel format is used.

BR,
Jani.


>  
>   /* video mode format for MIPI_VIDEO_MODE_FORMAT register */
>   u32 video_mode_format;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 1d43e6f..bf266cb 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -435,6 +435,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
> *intel_dsi, u16 panel_id)
>   intel_dsi->bw_timer = mipi_config->dbi_bw_timer;
>   intel_dsi->video_frmt_cfg_bits =
>   mipi_config->bta_enabled ? DISABLE_VIDEO_BTA : 0;
> + intel_dsi->dsi_bpp = bits_per_pixel;
>  
>   pclk = mode->clock;

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: implement WaIncreaseDefaultTLBEntries

[Patchwork]

== Summary ==

Series 3077v1 drm/i915: implement WaIncreaseDefaultTLBEntries
http://patchwork.freedesktop.org/api/1.0/series/3077/revisions/1/mbox/

Test gem_sync:
Subgroup basic-blt:
incomplete -> PASS   (skl-i5k-2)

bdw-nuci7total:161  pass:152  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultratotal:164  pass:152  dwarn:0   dfail:0   fail:0   skip:12 
byt-nuc  total:164  pass:141  dwarn:0   dfail:0   fail:0   skip:23 
hsw-brixbox  total:164  pass:151  dwarn:0   dfail:0   fail:0   skip:13 
hsw-gt2  total:164  pass:154  dwarn:0   dfail:0   fail:0   skip:10 
ilk-hp8440p  total:164  pass:116  dwarn:0   dfail:0   fail:0   skip:48 
ivb-t430stotal:164  pass:150  dwarn:0   dfail:0   fail:0   skip:14 
skl-i5k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14 
skl-i7k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14 
snb-dellxps  total:164  pass:142  dwarn:0   dfail:0   fail:0   skip:22 
snb-x220ttotal:164  pass:142  dwarn:0   dfail:0   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1364/

82b0b8e5fd2d7b63877c91cbe45138efbc46114e drm-intel-nightly: 
2016y-02m-04d-11h-00m-00s UTC integration manifest
d6a44d13ce71c2a8dcbaaa6e38fcd06b634d2b50 drm/i915: implement 
WaIncreaseDefaultTLBEntries

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

[Deepak, M]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, February 4, 2016 6:29 PM
> To: Deepak, M ; intel-gfx@lists.freedesktop.org
> Cc: Deepak, M 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider
> form B0 stepping onwards
> 
> On Wed, 03 Feb 2016, Deepak M  wrote:
> > The MIPI clock calculations for the addtional clock are revised from
> > B0 stepping onwards, the bit definitions have changed compared to old
> > stepping.
> >
> > v2: Fixing compilation warning.
> 
> Why did you move and rename everything when it was not needed?
> 
> BR,
> Jani.
> 
[Deepak, M] I have deleted the old macro and added the new as per the new 
definitions. With the new bit fields nothing was matching as that of the old. 
> 
> >
> > Signed-off-by: Deepak M 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  | 104 +
> --
> >  drivers/gpu/drm/i915/intel_dsi_pll.c |  64 ++---
> >  2 files changed, 95 insertions(+), 73 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index c0bd691..2568f35 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7638,6 +7638,57 @@ enum skl_disp_power_wells {
> >
> >  /* MIPI DSI registers */
> >
> > +#define  BXT_MIPI1_RX_LOWER_SHIFT  16
> > +#define  BXT_MIPI2_RX_LOWER_SHIFT  0
> > +#define  BXT_MIPI_RX_LOWER_SHIFT(port) \
> > +   _MIPI_PORT(port, BXT_MIPI1_RX_LOWER_SHIFT, \
> > +   BXT_MIPI2_RX_LOWER_SHIFT)
> > +#define  BXT_MIPI1_RX_LOWER_DIVIDER_MASK   (3 << 16)
> > +#define  BXT_MIPI2_RX_LOWER_DIVIDER_MASK   (3 << 0)
> > +#define  BXT_MIPI_RX_LOWER_DIVIDER_MASK(port)  \
> > +   (3 << BXT_MIPI_RX_LOWER_SHIFT(port))
> > +#define  BXT_MIPI_RX_LOWER_DIVIDER(port, val)  \
> > +   ((val & 3) << BXT_MIPI_RX_LOWER_SHIFT(port))
> > +
> > +#define  BXT_MIPI1_8X_BY3_SHIFT19
> > +#define  BXT_MIPI2_8X_BY3_SHIFT3
> > +#define  BXT_MIPI_8X_BY3_SHIFT(port)  \
> > +   _MIPI_PORT(port, BXT_MIPI1_8X_BY3_SHIFT, \
> > +   BXT_MIPI2_8X_BY3_SHIFT)
> > +#define  BXT_MIPI1_8X_BY3_DIVIDER_MASK (3 << 19)
> > +#define  BXT_MIPI2_8X_BY3_DIVIDER_MASK (3 << 3)
> > +#define  BXT_MIPI_8X_BY3_DIVIDER_MASK(port)\
> > +   (3 << BXT_MIPI_8X_BY3_SHIFT(port))
> > +#define  BXT_MIPI_8X_BY3_DIVIDER(port, val)\
> > +   ((val & 3) << BXT_MIPI_8X_BY3_SHIFT(port))
> > +
> > +#define  BXT_MIPI1_RX_UPPER_SHIFT  21
> > +#define  BXT_MIPI2_RX_UPPER_SHIFT  5
> > +#define  BXT_MIPI_RX_UPPER_SHIFT(port) \
> > +   _MIPI_PORT(port, BXT_MIPI1_RX_UPPER_SHIFT, \
> > +   BXT_MIPI2_RX_UPPER_SHIFT)
> > +#define  BXT_MIPI1_RX_UPPER_DIVIDER_MASK   (3 << 21)
> > +#define  BXT_MIPI2_RX_UPPER_DIVIDER_MASK   (3 << 5)
> > +#define  BXT_MIPI_RX_UPPER_DIVIDER_MASK(port)  \
> > +   (3 << BXT_MIPI_RX_UPPER_SHIFT(port))
> > +#define  BXT_MIPI_RX_UPPER_DIVIDER(port, val)  \
> > +   ((val & 3) << BXT_MIPI_RX_UPPER_SHIFT(port))
> > +
> > +#define  BXT_MIPI1_TX_SHIFT26
> > +#define  BXT_MIPI2_TX_SHIFT10
> > +#define  BXT_MIPI_TX_SHIFT(port)   \
> > +   _MIPI_PORT(port, BXT_MIPI1_TX_SHIFT, \
> > +   BXT_MIPI2_TX_SHIFT)
> > +#define  BXT_MIPI1_TX_DIVIDER_MASK (0x3F << 26)
> > +#define  BXT_MIPI2_TX_DIVIDER_MASK (0x3F << 10)
> > +#define  BXT_MIPI_TX_DIVIDER_MASK(port)\
> > +   (0x3F << BXT_MIPI_TX_SHIFT(port))
> > +#define  BXT_MIPI_TX_DIVIDER(port, val)\
> > +   ((val & 0x3F) << BXT_MIPI_TX_SHIFT(port))
> > +
> > +#define RX_DIVIDER_BIT_1_2 0x3
> > +#define RX_DIVIDER_BIT_3_4 0xC
> > +
> >  #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A
> and C only */
> >  #define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
> >
> > @@ -7650,59 +7701,6 @@ enum skl_disp_power_wells {
> >  #define  BXT_MIPI_DIV_SHIFT(port)  \
> > _MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
> > BXT_MIPI2_DIV_SHIFT)
> > -/* Var clock divider to generate TX source. Result must be < 39.5 M */
> > -#define  BXT_MIPI1_ESCLK_VAR_DIV_MASK  (0x3F << 26)
> > -#define  BXT_MIPI2_ESCLK_VAR_DIV_MASK  (0x3F << 10)
> > -#define  BXT_MIPI_ESCLK_VAR_DIV_MASK(port) \
> > -   _MIPI_PORT(port,
> BXT_MIPI1_ESCLK_VAR_DIV_MASK, \
> > -
>   BXT_MIPI2_ESCLK_VAR_DIV_MASK)
> > -
> > -#define  BXT_MIPI_ESCLK_VAR_DIV(port, val) \
> > -   (val << BXT_MIPI_DIV_SHIFT(port))
> > -/* TX control divider to select actual TX clock output from (8x/va

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards

[Jani Nikula]

On Wed, 03 Feb 2016, Deepak M  wrote:
> The MIPI clock calculations for the addtional clock
> are revised from B0 stepping onwards, the bit definitions
> have changed compared to old stepping.
>
> v2: Fixing compilation warning.

Why did you move and rename everything when it was not needed?

BR,
Jani.


>
> Signed-off-by: Deepak M 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 104 
> +--
>  drivers/gpu/drm/i915/intel_dsi_pll.c |  64 ++---
>  2 files changed, 95 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c0bd691..2568f35 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7638,6 +7638,57 @@ enum skl_disp_power_wells {
>  
>  /* MIPI DSI registers */
>  
> +#define  BXT_MIPI1_RX_LOWER_SHIFT16
> +#define  BXT_MIPI2_RX_LOWER_SHIFT0
> +#define  BXT_MIPI_RX_LOWER_SHIFT(port)   \
> + _MIPI_PORT(port, BXT_MIPI1_RX_LOWER_SHIFT, \
> + BXT_MIPI2_RX_LOWER_SHIFT)
> +#define  BXT_MIPI1_RX_LOWER_DIVIDER_MASK (3 << 16)
> +#define  BXT_MIPI2_RX_LOWER_DIVIDER_MASK (3 << 0)
> +#define  BXT_MIPI_RX_LOWER_DIVIDER_MASK(port)\
> + (3 << BXT_MIPI_RX_LOWER_SHIFT(port))
> +#define  BXT_MIPI_RX_LOWER_DIVIDER(port, val)\
> + ((val & 3) << BXT_MIPI_RX_LOWER_SHIFT(port))
> +
> +#define  BXT_MIPI1_8X_BY3_SHIFT  19
> +#define  BXT_MIPI2_8X_BY3_SHIFT  3
> +#define  BXT_MIPI_8X_BY3_SHIFT(port)  \
> + _MIPI_PORT(port, BXT_MIPI1_8X_BY3_SHIFT, \
> + BXT_MIPI2_8X_BY3_SHIFT)
> +#define  BXT_MIPI1_8X_BY3_DIVIDER_MASK   (3 << 19)
> +#define  BXT_MIPI2_8X_BY3_DIVIDER_MASK   (3 << 3)
> +#define  BXT_MIPI_8X_BY3_DIVIDER_MASK(port)  \
> + (3 << BXT_MIPI_8X_BY3_SHIFT(port))
> +#define  BXT_MIPI_8X_BY3_DIVIDER(port, val)  \
> + ((val & 3) << BXT_MIPI_8X_BY3_SHIFT(port))
> +
> +#define  BXT_MIPI1_RX_UPPER_SHIFT21
> +#define  BXT_MIPI2_RX_UPPER_SHIFT5
> +#define  BXT_MIPI_RX_UPPER_SHIFT(port)   \
> + _MIPI_PORT(port, BXT_MIPI1_RX_UPPER_SHIFT, \
> + BXT_MIPI2_RX_UPPER_SHIFT)
> +#define  BXT_MIPI1_RX_UPPER_DIVIDER_MASK (3 << 21)
> +#define  BXT_MIPI2_RX_UPPER_DIVIDER_MASK (3 << 5)
> +#define  BXT_MIPI_RX_UPPER_DIVIDER_MASK(port)\
> + (3 << BXT_MIPI_RX_UPPER_SHIFT(port))
> +#define  BXT_MIPI_RX_UPPER_DIVIDER(port, val)\
> + ((val & 3) << BXT_MIPI_RX_UPPER_SHIFT(port))
> +
> +#define  BXT_MIPI1_TX_SHIFT  26
> +#define  BXT_MIPI2_TX_SHIFT  10
> +#define  BXT_MIPI_TX_SHIFT(port) \
> + _MIPI_PORT(port, BXT_MIPI1_TX_SHIFT, \
> + BXT_MIPI2_TX_SHIFT)
> +#define  BXT_MIPI1_TX_DIVIDER_MASK   (0x3F << 26)
> +#define  BXT_MIPI2_TX_DIVIDER_MASK   (0x3F << 10)
> +#define  BXT_MIPI_TX_DIVIDER_MASK(port)  \
> + (0x3F << BXT_MIPI_TX_SHIFT(port))
> +#define  BXT_MIPI_TX_DIVIDER(port, val)  \
> + ((val & 0x3F) << BXT_MIPI_TX_SHIFT(port))
> +
> +#define RX_DIVIDER_BIT_1_2   0x3
> +#define RX_DIVIDER_BIT_3_4   0xC
> +
>  #define _MIPI_PORT(port, a, c)   _PORT3(port, a, 0, c)   /* ports A and 
> C only */
>  #define _MMIO_MIPI(port, a, c)   _MMIO(_MIPI_PORT(port, a, c))
>  
> @@ -7650,59 +7701,6 @@ enum skl_disp_power_wells {
>  #define  BXT_MIPI_DIV_SHIFT(port)\
>   _MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
>   BXT_MIPI2_DIV_SHIFT)
> -/* Var clock divider to generate TX source. Result must be < 39.5 M */
> -#define  BXT_MIPI1_ESCLK_VAR_DIV_MASK(0x3F << 26)
> -#define  BXT_MIPI2_ESCLK_VAR_DIV_MASK(0x3F << 10)
> -#define  BXT_MIPI_ESCLK_VAR_DIV_MASK(port)   \
> - _MIPI_PORT(port, BXT_MIPI1_ESCLK_VAR_DIV_MASK, \
> - BXT_MIPI2_ESCLK_VAR_DIV_MASK)
> -
> -#define  BXT_MIPI_ESCLK_VAR_DIV(port, val)   \
> - (val << BXT_MIPI_DIV_SHIFT(port))
> -/* TX control divider to select actual TX clock output from (8x/var) */
> -#define  BXT_MIPI1_TX_ESCLK_SHIFT21
> -#define  BXT_MIPI2_TX_ESCLK_SHIFT5
> -#define  BXT_MIPI_TX_ESCLK_SHIFT(port)   \
> - _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_SHIFT, \
> - BXT_MIPI2_TX_ESCLK_SHIFT)
> -#define  BXT_MIPI1_TX_ESCLK_FIXDIV_MASK  (3 << 21)
> -#define  BXT_MIPI2_TX_ESCLK_FIXDIV_MASK  (3 << 5)
> -#define  BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port) \
> - _MIPI_PORT(port, BXT_MIPI1_

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Added identifier for MIPI transcoder.

[Jani Nikula]

On Wed, 03 Feb 2016, Animesh Manna  wrote:
> Changes done:
> - Added identifier for Mipi transcoder A and C.
> - Added power domain identifier for newly added mipi trancoder.
> - Initialized transcoder for mipi during compute config.

Please separate the power domain control from the addition of the
transcoders. I think the former is safer to go in.

BR,
Jani.


>
> v1: Initial RFC version.
>
> v2: Rebased on tot.
>
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 
>  drivers/gpu/drm/i915/intel_dsi.c| 8 
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 6 ++
>  3 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 65a2cd0..c484df8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -122,6 +122,8 @@ enum transcoder {
>   TRANSCODER_B,
>   TRANSCODER_C,
>   TRANSCODER_EDP,
> + TRANSCODER_MIPI_A,
> + TRANSCODER_MIPI_C,
>   I915_MAX_TRANSCODERS
>  };
>  #define transcoder_name(t) ((t) + 'A')
> @@ -176,6 +178,8 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_TRANSCODER_B,
>   POWER_DOMAIN_TRANSCODER_C,
>   POWER_DOMAIN_TRANSCODER_EDP,
> + POWER_DOMAIN_TRANSCODER_MIPI_A,
> + POWER_DOMAIN_TRANSCODER_MIPI_C,
>   POWER_DOMAIN_PORT_DDI_A_LANES,
>   POWER_DOMAIN_PORT_DDI_B_LANES,
>   POWER_DOMAIN_PORT_DDI_C_LANES,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 91cef35..4f2b513 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -273,6 +273,7 @@ static bool intel_dsi_compute_config(struct intel_encoder 
> *encoder,
>   struct intel_connector *intel_connector = intel_dsi->attached_connector;
>   struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
>   struct drm_display_mode *adjusted_mode = 
> &pipe_config->base.adjusted_mode;
> + struct drm_device *dev = intel_connector->base.dev;
>  
>   DRM_DEBUG_KMS("\n");
>  
> @@ -284,6 +285,13 @@ static bool intel_dsi_compute_config(struct 
> intel_encoder *encoder,
>   /* DSI uses short packets for sync events, so clear mode flags for DSI 
> */
>   adjusted_mode->flags = 0;
>  
> + if (IS_BROXTON(dev)) {
> + if (intel_dsi->ports & (1 << PORT_A))
> + pipe_config->cpu_transcoder = TRANSCODER_MIPI_A;
> + else
> + pipe_config->cpu_transcoder = TRANSCODER_MIPI_C;
> + }
> +
>   return true;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index bbca527..611dc1e 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -87,6 +87,10 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "TRANSCODER_B";
>   case POWER_DOMAIN_TRANSCODER_C:
>   return "TRANSCODER_C";
> + case POWER_DOMAIN_TRANSCODER_MIPI_A:
> + return "TRANSCODER_MIPI_A";
> + case POWER_DOMAIN_TRANSCODER_MIPI_C:
> + return "TRANSCODER_MIPI_C";
>   case POWER_DOMAIN_TRANSCODER_EDP:
>   return "TRANSCODER_EDP";
>   case POWER_DOMAIN_PORT_DDI_A_LANES:
> @@ -403,6 +407,8 @@ static void hsw_set_power_well(struct drm_i915_private 
> *dev_priv,
>   BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT(POWER_DOMAIN_PIPE_A) |  \
>   BIT(POWER_DOMAIN_TRANSCODER_EDP) |  \
> + BIT(POWER_DOMAIN_TRANSCODER_MIPI_A) |   \
> + BIT(POWER_DOMAIN_TRANSCODER_MIPI_C) |   \
>   BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
>   BIT(POWER_DOMAIN_PORT_DDI_A_LANES) |\
>   BIT(POWER_DOMAIN_AUX_A) |   \

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: i2c/gpio

[Patchwork]

== Summary ==

Series 3075v1 drm/i915/dsi: i2c/gpio
http://patchwork.freedesktop.org/api/1.0/series/3075/revisions/1/mbox/

Test gem_sync:
Subgroup basic-blt:
incomplete -> PASS   (skl-i5k-2)

bdw-nuci7total:161  pass:152  dwarn:0   dfail:0   fail:0   skip:9  
bdw-ultratotal:164  pass:152  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:164  pass:136  dwarn:0   dfail:0   fail:0   skip:28 
byt-nuc  total:164  pass:141  dwarn:0   dfail:0   fail:0   skip:23 
hsw-brixbox  total:164  pass:151  dwarn:0   dfail:0   fail:0   skip:13 
hsw-gt2  total:164  pass:154  dwarn:0   dfail:0   fail:0   skip:10 
ilk-hp8440p  total:164  pass:116  dwarn:0   dfail:0   fail:0   skip:48 
ivb-t430stotal:164  pass:150  dwarn:0   dfail:0   fail:0   skip:14 
skl-i5k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14 
skl-i7k-2total:164  pass:149  dwarn:1   dfail:0   fail:0   skip:14 
snb-dellxps  total:164  pass:142  dwarn:0   dfail:0   fail:0   skip:22 
snb-x220ttotal:164  pass:142  dwarn:0   dfail:0   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1363/

82b0b8e5fd2d7b63877c91cbe45138efbc46114e drm-intel-nightly: 
2016y-02m-04d-11h-00m-00s UTC integration manifest
153ea3657256af0ff0a69034617c65cf2e9ff584 drm/i915/dsi: Added the generic gpio 
sequence support and gpio table
36e84496ec9bc2b370901167d0f6f3a82a5e5ead drm/i915: Extend gpio read/write to 
other cores
9b18e955646369f63527273a52fc866008e309ba drm/i915/vlv: drop unused 
vlv_gps_core_read/write functions
d3b3ece97c24a1097b85239da9d1540c34573286 drm/i915: put the IOSF port defines in 
numerical order
592caf8e1850a690beed9c31b9db643f9c2ade21 drm/i915/dsi: skip gpio element 
execution when not supported
030d66367e8f38cf3de84b8d3c328523ce61bccf drm/i915: Adding the parsing logic for 
the i2c element
ea8629e96fa6d769dfcef796fd00f861ae41fd4a drm/i915/dsi: don't pass arbitrary 
data to sideband
33e71e3b31b6801ae3cb182d0e60afa561d98c0c drm/i915/dsi: defend gpio table 
against out of bounds access

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

Re: [Intel-gfx] [PATCH] drm/i915: Mitigate retirement starvation a bit

[Chris Wilson]

On Thu, Feb 04, 2016 at 12:25:24PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> In execlists mode internal house keeping of the discarded
> requests (and so contexts and VMAs) relies solely on the retire
> worker, which can be prevented from running by just being
> unlucky when busy clients are hammering on the big lock.
> 
> Prime example is the gem_close_race IGT, which due to this
> effect causes internal lists to grow to epic proportions, with
> a consequece of object VMA traversal to growing exponentially
> and resulting in tens of minutes test runtime. Memory use is
> also very high and a limiting factor on some platforms.
> 
> Since we do not want to run this internal house keeping more
> frequently, due concerns that it may affect performance, and
> the scenario being statistically not very likely in real
> workloads, one possible workaround is to run it when new
> client handles are opened.
> 
> This will solve the issues with this particular test case,
> making it complete in tens of seconds instead of tens of
> minutes, and will not add any run-time penalty to running
> clients.
> 
> It can only slightly slow down new client startup, but on a
> realisticaly loaded system we are expecting this to be not
> significant. Even with heavy rendering in progress we can have
> perhaps up to several thousands of requests pending retirement,
> which, with a typical retirement cost of 80ns to 1us per
> request, is not significant.
> 
> Signed-off-by: Tvrtko Ursulin 
> Testcase: igt/gem_close_race/gem-close-race
> Cc: Chris Wilson 

Still doesn't fix actual workloads where this is demonstrably bad, which
can be demonstrated with a single fd.

The most effective treatment I found is moving the retire-requests from
execbuf (which exists for similar reasons) to get-pages.

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=75f4e53f1c9141ba2dd8847396a1bcc8dbeecd55

I would also suggest

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=7c1b679c76524780f8e15cc8b0c6652539182d51

for the reasons above.
-Chris

-- 
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/3] drm/i915: Allow i915_gem_object_get_page() on userptr as well

[Jani Nikula]

On Wed, 03 Feb 2016, Jani Nikula  wrote:
> On Fri, 29 Jan 2016, Chris Wilson  wrote:
>> commit 033908aed5a596f6202c848c6bbc8a40fb1a8490
>> Author: Dave Gordon 
>> Date:   Thu Dec 10 18:51:23 2015 +
>>
>> drm/i915: mark GEM object pages dirty when mapped & written by the CPU
>>
>> introduced a check into i915_gem_object_get_dirty_pages() that returned
>> a NULL pointer when called with a bad object, one that was not backed by
>> shmemfs. This WARN was too strict as we can work on all struct page
>> backed objects, and resulted in a WARN + GPF for existing userspace. In
>> order to differentiate the various types of objects, add a new flags field
>> to the i915_gem_object_ops struct to describe their capabilities, with
>> the first flag being whether the object has struct pages.
>>
>> v2: Drop silly const before an integer in the structure declaration.
>>
>> Testcase: igt/gem_userptr_blits/relocations
>> Reported-and-tested-by: Kristian Høgsberg Kristensen 
>> Signed-off-by: Chris Wilson 
>> Cc: Dave Gordon 
>> Cc: Kristian Høgsberg Kristensen 
>> Cc: Daniel Vetter 
>> Reviewed-by: Dave Gordon 
>> Reviewed-by: Kristian Høgsberg Kristensen 
>
> Cc: drm-intel-fi...@lists.freedesktop.org
>
> to pick for 4.5

Picked up in drm-intel-fixes.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h | 4 
>>  drivers/gpu/drm/i915/i915_gem.c | 3 ++-
>>  drivers/gpu/drm/i915/i915_gem_userptr.c | 3 ++-
>>  3 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 905e90f25957..a2d2f08b7515 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2000,6 +2000,9 @@ enum hdmi_force_audio {
>>  #define I915_GTT_OFFSET_NONE ((u32)-1)
>>  
>>  struct drm_i915_gem_object_ops {
>> +unsigned int flags;
>> +#define I915_GEM_OBJECT_HAS_STRUCT_PAGE 0x1
>> +
>>  /* Interface between the GEM object and its backing storage.
>>   * get_pages() is called once prior to the use of the associated set
>>   * of pages before to binding them into the GTT, and put_pages() is
>> @@ -2015,6 +2018,7 @@ struct drm_i915_gem_object_ops {
>>   */
>>  int (*get_pages)(struct drm_i915_gem_object *);
>>  void (*put_pages)(struct drm_i915_gem_object *);
>> +
>>  int (*dmabuf_export)(struct drm_i915_gem_object *);
>>  void (*release)(struct drm_i915_gem_object *);
>>  };
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index a928823507c5..e9b19bca1383 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -4465,6 +4465,7 @@ void i915_gem_object_init(struct drm_i915_gem_object 
>> *obj,
>>  }
>>  
>>  static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
>> +.flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
>>  .get_pages = i915_gem_object_get_pages_gtt,
>>  .put_pages = i915_gem_object_put_pages_gtt,
>>  };
>> @@ -5309,7 +5310,7 @@ i915_gem_object_get_dirty_page(struct 
>> drm_i915_gem_object *obj, int n)
>>  struct page *page;
>>  
>>  /* Only default objects have per-page dirty tracking */
>> -if (WARN_ON(obj->ops != &i915_gem_object_ops))
>> +if (WARN_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0))
>>  return NULL;
>>  
>>  page = i915_gem_object_get_page(obj, n);
>> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
>> b/drivers/gpu/drm/i915/i915_gem_userptr.c
>> index 74a4d1714879..7107f2fd38f5 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
>> @@ -708,9 +708,10 @@ i915_gem_userptr_dmabuf_export(struct 
>> drm_i915_gem_object *obj)
>>  }
>>  
>>  static const struct drm_i915_gem_object_ops i915_gem_userptr_ops = {
>> -.dmabuf_export = i915_gem_userptr_dmabuf_export,
>> +.flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
>>  .get_pages = i915_gem_userptr_get_pages,
>>  .put_pages = i915_gem_userptr_put_pages,
>> +.dmabuf_export = i915_gem_userptr_dmabuf_export,
>>  .release = i915_gem_userptr_release,
>>  };

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915/skl: fix RC6 residency time calculation

[Imre Deak]

On to, 2016-02-04 at 15:39 +0530, Kamble, Sagar A wrote:
> Ok. I related my change to below definition:
> 
> #define GT_INTERVAL_FROM_US(dev_priv, us) (IS_GEN9(dev_priv) ? \
>  (IS_BROXTON(dev_priv) ? \
>  INTERVAL_0_833_US(us) : \
>  INTERVAL_1_33_US(us)) : \
>  INTERVAL_1_28_US(us))
> 
> This is using 1.33us unit for SKL.
> May be we need to define these based on mode (normal/PSMI).
> Not sure how to determine modes.

Hm, good point. Looking at this now, the above macro is used for
registers that have the same contradicting description in BSpec: all
specify 1.28us units, but the "Timestamp Bases" section kind of
suggests that you need to use the units defined there for these
registers too, which could be 1.28us or 1.33us depending on the mode.
It's also possible that GT_GFX_RC6 really uses different units than
these registers. We'd really need a clarification on these in BSpec
before making changes.

--Imre

> Thanks
> Sagar
> 
> 
> On 2/3/2016 10:40 PM, Imre Deak wrote:
> > On ke, 2016-02-03 at 11:29 +0530, Sagar Arun Kamble wrote:
> > > The RC6 residency time unit is 1.33us on SKL according to the
> > > specification, so update the calculation accordingly.
> > > 
> > > Cc: Imre Deak 
> > > Signed-off-by: Sagar Arun Kamble 
> > > ---
> > >   drivers/gpu/drm/i915/i915_sysfs.c | 3 ++-
> > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> > > b/drivers/gpu/drm/i915/i915_sysfs.c
> > > index c6188dd..9aa49a9 100644
> > > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > > @@ -58,7 +58,8 @@ static u32 calc_residency(struct drm_device
> > > *dev,
> > >   } else if (IS_BROXTON(dev)) {
> > >   units = 1;
> > >   div = 1200; /* 833.33ns */
> > > - }
> > > + } else if (IS_SKYLAKE(dev))
> > > + units = 133ULL;
> > Hrm. The SKL/GT_GFX_RC6 description in ConfigDB doesn't say
> > anything
> > about the units, the BSpec "Timestamp Bases" provides two values
> > for
> > two different modes:
> > 
> > 1.33us and 1.28us
> > 
> > Not sure what are these different modes.
> > 
> > BSpec GT_GFX_RC6 description specifies 1.28us.
> > 
> > Running igt/pm_rc6_residency calculating with the current 1.28us
> > results in:
> > Residency in rc6 or deeper state: 2983 ms (sleep duration 3003 ms)
> > (ratio to expected duration: 0,99)
> > Subtest rc6-accuracy: SUCCESS (0,000s)
> > 
> > and after applying your patch (calculating with 1.33us):
> > Residency in rc6 or deeper state: 3101 ms (sleep duration 3001 ms)
> > (ratio to expected duration: 1,03)
> > (pm_rc6_residency:6281) CRITICAL: Test assertion failure function
> > residency_accuracy, file pm_rc6_residency.c:110:
> > (pm_rc6_residency:6281) CRITICAL: Failed assertion: ratio > 0.9 &&
> > ratio <= 1
> > (pm_rc6_residency:6281) CRITICAL: Sysfs RC6 residency counter is
> > inaccurate.
> > 
> > While the measurement can be inaccurate, normally we should only
> > err by
> > measuring less duration in RC6 than the duration of the actual
> > sleep.
> > So I'm not convinced that 1.33us is the correct value..
> > 
> > --Imre
> > 
> > >   
> > >   raw_time = I915_READ(reg) * units;
> > >   ret = DIV_ROUND_UP_ULL(raw_time, div);
> 
___
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: Set invert bit for hpd based on VBT

[Jani Nikula]

On Thu, 04 Feb 2016, Shubhangi Shrivastava  
wrote:
> This patch sets the invert bit for hpd detection for each port
> based on vbt configuration. since each AOB can be designed to
> depend on invert bit or not, it is expected if an AOB requires
> invert bit, the user will set respective bit in VBT.
>
> Signed-off-by: Sivakumar Thulasimani 
> Signed-off-by: Durgadoss R 
> Signed-off-by: Shubhangi Shrivastava 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 49 
> +
>  drivers/gpu/drm/i915/i915_reg.h |  9 
>  2 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 25a8937..305e6dd 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3424,6 +3424,54 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
>   I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
>  }
>  
> +/*
> + * For BXT invert bit has to be set based on AOB design
> + * for HPD detection logic, update it based on VBT fields.
> + */
> +static void bxt_hpd_set_invert(struct drm_device *dev, u32 hotplug_port)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int i, reg_val, val = 0;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> +
> + /* Proceed only if invert bit is set */
> + if (dev_priv->vbt.child_dev[i].common.hpd_invert == 0)
> + continue;
> +
> + /*
> +  * Convert dvo_port to PORT_X and set appropriate bit
> +  * only if hotplug is enabled on that port
> +  */
> + switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
> + case DVO_PORT_DPA:
> + case DVO_PORT_HDMIA:
> + if (hotplug_port & BXT_DE_PORT_HP_DDIA)
> + val |= BXT_DDIA_HPD_INVERT;
> + break;
> + case DVO_PORT_DPB:
> + case DVO_PORT_HDMIB:
> + if (hotplug_port & BXT_DE_PORT_HP_DDIB)
> + val |= BXT_DDIB_HPD_INVERT;
> + break;
> + case DVO_PORT_DPC:
> + case DVO_PORT_HDMIC:
> + if (hotplug_port & BXT_DE_PORT_HP_DDIC)
> + val |= BXT_DDIC_HPD_INVERT;
> + break;
> + default:
> + DRM_ERROR("HPD invert set for invalid dvo port %d\n",
> +dev_priv->vbt.child_dev[i].common.dvo_port);
> + break;
> + }
> + }
> + reg_val = I915_READ(BXT_HOTPLUG_CTL);
> + DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x val:%x\n",
> + reg_val, hotplug_port, val);
> + reg_val &= ~BXT_DDI_HPD_INVERT_MASK;
> + I915_WRITE(BXT_HOTPLUG_CTL, reg_val | val);
> +}

No, we don't want this here. Separate VBT parsing from the rest of the
logic. See [1] for some directions where I want to take this type of
things.

BR,
Jani.

[1] http://mid.gmane.org/cover.1452541881.git.jani.nik...@intel.com



> +
>  static void spt_hpd_irq_setup(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -3494,6 +3542,7 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
>   hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
>   PORTA_HOTPLUG_ENABLE;
>   I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
> + bxt_hpd_set_invert(dev, enabled_irqs);
>  }
>  
>  static void ibx_irq_postinstall(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0a98889..01bd3c5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5936,6 +5936,15 @@ enum skl_disp_power_wells {
>  #define GEN8_PCU_IIR _MMIO(0x444e8)
>  #define GEN8_PCU_IER _MMIO(0x444ec)
>  
> +/* BXT hotplug control */
> +#define BXT_HOTPLUG_CTL  _MMIO(0xC4030)
> +#define BXT_DDIA_HPD_INVERT  (1 << 27)
> +#define BXT_DDIC_HPD_INVERT  (1 << 11)
> +#define BXT_DDIB_HPD_INVERT  (1 << 3)
> +#define BXT_DDI_HPD_INVERT_MASK  (BXT_DDIA_HPD_INVERT | \
> +  BXT_DDIB_HPD_INVERT | \
> +  BXT_DDIC_HPD_INVERT)
> +
>  #define ILK_DISPLAY_CHICKEN2 _MMIO(0x42004)
>  /* Required on all Ironlake and Sandybridge according to the B-Spec. */
>  #define  ILK_ELPIN_409_SELECT(1 << 25)

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Mitigate retirement starvation a bit

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In execlists mode internal house keeping of the discarded
requests (and so contexts and VMAs) relies solely on the retire
worker, which can be prevented from running by just being
unlucky when busy clients are hammering on the big lock.

Prime example is the gem_close_race IGT, which due to this
effect causes internal lists to grow to epic proportions, with
a consequece of object VMA traversal to growing exponentially
and resulting in tens of minutes test runtime. Memory use is
also very high and a limiting factor on some platforms.

Since we do not want to run this internal house keeping more
frequently, due concerns that it may affect performance, and
the scenario being statistically not very likely in real
workloads, one possible workaround is to run it when new
client handles are opened.

This will solve the issues with this particular test case,
making it complete in tens of seconds instead of tens of
minutes, and will not add any run-time penalty to running
clients.

It can only slightly slow down new client startup, but on a
realisticaly loaded system we are expecting this to be not
significant. Even with heavy rendering in progress we can have
perhaps up to several thousands of requests pending retirement,
which, with a typical retirement cost of 80ns to 1us per
request, is not significant.

Signed-off-by: Tvrtko Ursulin 
Testcase: igt/gem_close_race/gem-close-race
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d46a0462c765..f02991d28048 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5162,6 +5162,10 @@ int i915_gem_open(struct drm_device *dev, struct 
drm_file *file)
if (ret)
kfree(file_priv);
 
+   mutex_lock(&dev->struct_mutex);
+   i915_gem_retire_requests(dev);
+   mutex_unlock(&dev->struct_mutex);
+
return ret;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH i-g-t v3] lib/igt_core.c: Expand --run-subtest functionality.

[Derek Morton]

Added extended wildcard support when specifying --run-subtest.

Wildcard format is as specified in rfc3977 and the uwildmat() implementation
is taken from libinn.
See https://tools.ietf.org/html/rfc3977#section-4 for a description of
allowed wildcard expressions.

v2: Use comma as list separator (Ville Syrjala)
support both ^ and ! as not operators (Dave Gordon)

v3: Updated to use uwildmat() (Dave Gordon)

Signed-off-by: Derek Morton 
---
 COPYING |  21 +++
 lib/Makefile.sources|   2 +
 lib/igt_core.c  |  17 +-
 lib/uwildmat/uwildmat.c | 474 
 lib/uwildmat/uwildmat.h |  24 +++
 5 files changed, 536 insertions(+), 2 deletions(-)
 create mode 100644 lib/uwildmat/uwildmat.c
 create mode 100644 lib/uwildmat/uwildmat.h

diff --git a/COPYING b/COPYING
index b8f6753..16375f2 100644
--- a/COPYING
+++ b/COPYING
@@ -106,3 +106,24 @@ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, 
DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 IN THE SOFTWARE.
+
+Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
+2013, 2014 by Internet Systems Consortium, Inc. ("ISC")
+Copyright (c) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
+2002, 2003 by The Internet Software Consortium and Rich Salz
+
+This code is derived from software contributed to the Internet Software
+Consortium by Rich Salz.
+
+Permission to use, copy, modify, and distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
+REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY
+SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 4999868..e33861e 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -60,6 +60,8 @@ libintel_tools_la_SOURCES =   \
igt_core.h  \
igt_draw.c  \
igt_draw.h  \
+   uwildmat/uwildmat.h \
+   uwildmat/uwildmat.c \
$(NULL)
 
 .PHONY: version.h.tmp
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 6b69bb7..8e0bd2e 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -56,7 +56,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "drmtest.h"
 #include "intel_chipset.h"
@@ -209,6 +209,19 @@
  * intel gpu to be present). Then individual subtests can be run with
  * "--run-subtest". Usage help for tests with subtests can be obtained with the
  * "--help" command line option.
+ *
+ * A wildcard expression can be given to --run-subtest to specify a subset of
+ * subtests to run. See https://tools.ietf.org/html/rfc3977#section-4 for a
+ * description of allowed wildcard expressions.
+ * Some examples of allowed wildcard expressions are:
+ *
+ * - '*basic*' match any subtest containing basic
+ * - 'basic-???' match any subtest named basic- with 3 characters after -
+ * - 'basic-[0-9]' match any subtest named basic- with a single number after -
+ * - 'basic-[^0-9]' match any subtest named basic- with a single non numerical 
character after -
+ * - 'basic*,advanced*' match any subtest starting basic or advanced
+ * - '*,!basic*' match any subtest not starting basic
+ * - 'basic*,!basic-render*' match any subtest starting basic but not starting 
basic-render
  */
 
 static unsigned int exit_handler_count;
@@ -814,7 +827,7 @@ bool __igt_run_subtest(const char *subtest_name)
}
 
if (run_single_subtest) {
-   if (fnmatch(run_single_subtest, subtest_name, 0) != 0)
+   if (uwildmat(subtest_name, run_single_subtest) == 0)
return false;
else
run_single_subtest_found = true;
diff --git a/lib/uwildmat/uwildmat.c b/lib/uwildmat/uwildmat.c
new file mode 100644
index 000..2d34742
--- /dev/null
+++ b/lib/uwildmat/uwildmat.c
@@ -0,0 +1,474 @@
+/* uwildmat.c is reused from libinn - 
https://launchpad.net/ubuntu/+source/inn2/2.5.4-1
+
+This provides wild card matching originally used in InterNetNews and is
+described in https://tools.ietf.org/html/rfc3977#section-4
+
+INN licence:
+INN as a whole and all code contained in it not otherwise marked with
+different licenses and/or copyrights is covered by the following copyright
+and license:
+
+   Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
+   2013, 2014 by Internet Systems Consortium, Inc. ("ISC")
+   Cop

[Intel-gfx] [PATCH] lib/igt_kms: Add COMMIT_ATOMIC to igt_display_commit2()

[Mayuresh Gharpure]

Co-Author : Marius Vlad 

So far we have had only two commit styles, COMMIT_LEGACY
and COMMIT_UNIVERSAL. This patch adds another commit style
COMMIT_ATOMIC which makes use of drmModeAtomicCommit()

v2 : (Marius)
i)Set CRTC_ID to zero while disabling plane
ii)Modified the log message in igt_atomic_prepare_plane_commit
https://patchwork.freedesktop.org/patch/71945/

v3 : (Marius)Set FB_ID to zero while disabling plane
https://patchwork.freedesktop.org/patch/72179/

v4: (Maarten) Corrected the typo in commit message

Signed-off-by: Mayuresh Gharpure 
---
 lib/igt_kms.c | 318 +-
 lib/igt_kms.h |  71 -
 2 files changed, 387 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 90c8da7..6c07223 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -145,6 +145,120 @@ const unsigned char* igt_kms_get_base_edid(void)
  *
  * Returns: an alternate edid block
  */
+static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
+   "SRC_X",
+   "SRC_Y",
+   "SRC_W",
+   "SRC_H",
+   "CRTC_X",
+   "CRTC_Y",
+   "CRTC_W",
+   "CRTC_H",
+   "FB_ID",
+   "CRTC_ID",
+   "type",
+   "rotation"
+};
+
+static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
+   "background_color"
+};
+
+static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
+   "scaling mode",
+   "DPMS"
+};
+
+/*
+ * Retrieve all the properies specified in props_name and store them into
+ * plane->atomic_props_plane.
+ */
+static void
+igt_atomic_fill_plane_props(igt_display_t *display, igt_plane_t *plane,
+   int num_props, const char **prop_names)
+{
+   drmModeObjectPropertiesPtr props;
+   int i, j, fd;
+
+   fd = display->drm_fd;
+
+   props = drmModeObjectGetProperties(fd, plane->drm_plane->plane_id, 
DRM_MODE_OBJECT_PLANE);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_props; j++) {
+   if (strcmp(prop->name, prop_names[j]) != 0)
+   continue;
+
+   plane->atomic_props_plane[j] = props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+}
+
+/*
+ * Retrieve all the properies specified in props_name and store them into
+ * config->atomic_props_crtc and config->atomic_props_connector.
+ */
+static void
+igt_atomic_fill_props(igt_display_t *display, igt_output_t *output,
+   int num_crtc_props, const char **crtc_prop_names,
+   int num_connector_props, const char **conn_prop_names)
+{
+   drmModeObjectPropertiesPtr props;
+   int i, j, fd;
+
+   fd = display->drm_fd;
+
+   props = drmModeObjectGetProperties(fd, output->config.crtc->crtc_id, 
DRM_MODE_OBJECT_CRTC);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_crtc_props; j++) {
+   if (strcmp(prop->name, crtc_prop_names[j]) != 0)
+   continue;
+
+   output->config.atomic_props_crtc[j] = props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+   props = NULL;
+   props = drmModeObjectGetProperties(fd, 
output->config.connector->connector_id, DRM_MODE_OBJECT_CONNECTOR);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_connector_props; j++) {
+   if (strcmp(prop->name, conn_prop_names[j]) != 0)
+   continue;
+
+   output->config.atomic_props_connector[j] = 
props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+
+}
+
 const unsigned char* igt_kms_get_alt_edid(void)
 {
update_edid_csum(alt_edid);
@@ -952,6 +1066,8 @@ static void igt_output_refresh(igt_output_t *output)
kmstest_pipe_name(output->config.pipe));
 
display->pipes_in_use |= 1 << output->config.pipe;
+   igt_atomic_fill_props(display, output, IGT_NUM_CRTC_PROPS, 
igt_crtc_prop_names,
+   IGT_NUM_CONNECTOR_PROPS, igt_connector_prop_names);
 }
 
 static bool
@@ -1020,6 +1136,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
 {
drm

[Intel-gfx] [PATCH] drm/i915: implement WaIncreaseDefaultTLBEntries

[tim . gore]

From: Tim Gore 

WaIncreaseDefaultTLBEntries increases the number of TLB
entries available for GPGPU workloads and gives significant
( > 10% ) performance gain for some OCL benchmarks.
Put this in a new function that can be a place for
workarounds that are GT related but not required per ring.
This function is called on driver load and also after a
reset and on resume, so it is safe for workarounds that get
clobbered in these situations. This function currently has
just this one workaround.

v2: This was originally split into 3 patches but following
  review feedback was squashed into 1.
  I have not incorporated some style comments from Chris
  Wilson as I felt that after defining and intialising a
  temporary variable and then adding an additional if block
  to only write the register if the temporary variable had
  been set, this didn't really give a net gain.

v3: Resending in the hope that BAT will run

v4: Change subject line to trigger BAT (please!)

Signed-off-by: Tim Gore 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 21 +
 drivers/gpu/drm/i915/i915_reg.h |  7 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7377b67..5cd5f8b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2132,6 +2132,25 @@ static void i915_address_space_init(struct 
i915_address_space *vm,
list_add_tail(&vm->global_link, &dev_priv->vm_list);
 }
 
+static void gtt_write_workarounds(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   /* This function is for gtt related workarounds. This function is
+* called on driver load and after a GPU reset, so you can place
+* workarounds here even if they get overwritten by GPU reset.
+*/
+   /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt */
+   if (IS_BROADWELL(dev))
+   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
+   else if (IS_CHERRYVIEW(dev))
+   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
+   else if (IS_SKYLAKE(dev))
+   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
+   else if (IS_BROXTON(dev))
+   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
+}
+
 int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2148,6 +2167,8 @@ int i915_ppgtt_init(struct drm_device *dev, struct 
i915_hw_ppgtt *ppgtt)
 
 int i915_ppgtt_init_hw(struct drm_device *dev)
 {
+   gtt_write_workarounds(dev);
+
/* In the case of execlists, PPGTT is enabled by the context descriptor
 * and the PDPs are contained within the context itself.  We don't
 * need to do anything here. */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65e32a3..0ab6312 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8170,4 +8170,11 @@ enum skl_disp_power_wells {
 #define GEN9_VEBOX_MOCS(i) _MMIO(0xcb00 + (i) * 4) /* Video MOCS registers 
*/
 #define GEN9_BLT_MOCS(i)   _MMIO(0xcc00 + (i) * 4) /* Blitter MOCS 
registers */
 
+/* gamt regs */
+#define GEN8_L3_LRA_1_GPGPU _MMIO(0x4dd4)
+#define   GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW  0x67F1427F /* max/min for 
LRA1/2 */
+#define   GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV  0x5FF101FF /* max/min for 
LRA1/2 */
+#define   GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL  0x67F1427F /*"" */
+#define   GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT  0x5FF101FF /*"" */
+
 #endif /* _I915_REG_H_ */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_core.c: Expand --run-subtest functionality.

[David Weinehall]

I really like the thought of having this functionality in i-g-t,
especially if combined with my patches that allows for categorising
subtests (I'll submit a new version of those patches soon, since they
never got merged last time around). I'll refrain from bikeshedding on
the syntax.

In the longer run I think a rewrite of the subtest logic to allow not
only specifying what tests to run and/or exclude, but also to specify
what *order* to run the tests in (if reordering is possible) and to
randomise the order would be useful.

Since some testcases contain so many subtests that having those
testcases be a part of the CI/Piglit testruns isn't possible,
we need some way to have those tests run anyway.

My current train of thought is to either traverse through the tests
(1..20, 21..40, 41..60, etc.; which would require piglit to keep state,
which it currently doesn't) or to randomise a set of subtests that would
take something like 30s.

This might mean that things could slip under the radar for a long time,
but compared to today's situation where these tests aren't run at all
it'd still be an improvement.

Just my 2¢.


Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 02/29] drm/i915: Introduce host graphics memory balloon for gvt

[Joonas Lahtinen]

Hi,

On to, 2016-01-28 at 18:21 +0800, Zhi Wang wrote:
> From: Bing Niu 
> 
> This patch introduces host graphics memory ballon when GVT-g is enabled.
> 
> As under GVT-g, i915 only owned limited graphics resources, others are
> managed by GVT-g resource allocator and kept for other vGPUs.
> 
> For graphics memory space partition, a typical layout looks like:
> 
> +---+---+--+---+
> > * Host |   *GVT-g Resource |* Host|   *GVT-g Resource |
> > Owned |   Allocator Managed   | Owned|   Allocator Managed   |
> >   |   |  |   |
> +---+---+--+---+---+
> >   |   |   |   |  |   |   |   |
> > i915  | vm 1  | vm 2  | vm 3  | i915 | vm 1  | vm 2  | vm 3  |
> >   |   |   |   |  |   |   |   |
> +---+---+---+--+---+---+---+
> >   Aperture|Hidden|
> +---+--+
> >   GGTT memory space  |
> +--+
> 
> Similar with fence registers partition:
> 
>  +-- +---+
>  | * Host|GVT-g Resource |
>  | Owned |   Allocator Managed   +
>  0   |   31
>  +---+---+---+
>  |   |   |   |   |
>  | i915  | vm 1  | vm 2  | vm 3  |
>  |   |   |   |   |
>  +---+---+---+---+
> 
> i915 host will read the amount of allocated resources via GVT-g kernel 
> parameters.
> 
> Signed-off-by: Bing Niu 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/gvt/params.h   |  3 +++
>  drivers/gpu/drm/i915/i915_gem.c |  3 +++
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  4 ++--
>  drivers/gpu/drm/i915/i915_vgpu.c| 16 
>  drivers/gpu/drm/i915/i915_vgpu.h|  1 +
>  5 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/params.h 
> b/drivers/gpu/drm/i915/gvt/params.h
> index d2955b9..0656a98 100644
> --- a/drivers/gpu/drm/i915/gvt/params.h
> +++ b/drivers/gpu/drm/i915/gvt/params.h
> @@ -27,6 +27,9 @@
>  struct gvt_kernel_params {
>   bool enable;
>   int debug;
> + int dom0_low_gm_sz;
> + int dom0_high_gm_sz;
> + int dom0_fence_sz;
>  };
>  
>  extern struct gvt_kernel_params gvt;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 799a53a..e916e43 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5080,6 +5080,9 @@ i915_gem_load(struct drm_device *dev)
>   else
>   dev_priv->num_fence_regs = 8;
>  
> + if(intel_gvt_host_active(dev))

Space between "if" and "("

> + dev_priv->num_fence_regs = gvt.dom0_fence_sz;
> +
>   if (intel_vgpu_active(dev))
>   dev_priv->num_fence_regs =
>   I915_READ(vgtif_reg(avail_rs.fence_num));

I'd like to see the above as "else if" construct just like you have
below with the intel_vgt_balloon(). Could even do

if (gvt_host)  {
...
} else if (vgpu_active) {
...
} else {
per machine detection
}

Right?

> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 7377b67..0540de2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2713,7 +2713,7 @@ static int i915_gem_setup_global_gtt(struct drm_device 
> *dev,
>   i915_address_space_init(ggtt_vm, dev_priv);
>   ggtt_vm->total += PAGE_SIZE;
>  
> - if (intel_vgpu_active(dev)) {
> + if (intel_vgpu_active(dev) || intel_gvt_host_active(dev)) {
>   ret = intel_vgt_balloon(dev);
>   if (ret)
>   return ret;
> @@ -2810,7 +2810,7 @@ void i915_global_gtt_cleanup(struct drm_device *dev)
>   }
>  
>   if (drm_mm_initialized(&vm->mm)) {
> - if (intel_vgpu_active(dev))
> + if (intel_vgpu_active(dev) || intel_gvt_host_active(dev))
>   intel_vgt_deballoon();
>  
>   drm_mm_takedown(&vm->mm);
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index dea7429..fbe6114 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -188,10 +188,18 @@ int intel_vgt_balloon(struct drm_device *dev)
>   unsigned long unmappable_base, unmappable_size, unmappable_end;
>   int ret;
>  
> - mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
> - mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
> - unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
> - unmappable_size = I915_READ(vgtif_reg

Re: [Intel-gfx] [RFC 01/29] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Joonas Lahtinen]

Hi,

On ke, 2016-02-03 at 14:01 +0800, Zhi Wang wrote:
> Hi Joonas:
>  Thanks you very much! We're very excited for receiving your advice 
> and continue to be open to any comments. :)
> 
> I'm supposed that we should make the agreements on i915 host change at 
> the very beginning, as I'm concerned during the discussion of i915 host 
> change, you know, maybe some code of GVT-g needs to be refined or 
> re-designed. So we put the i915 host changes to the beginning of the 
> patch set for the convenience of discussion.
> 
> I summarize your comments as below, very applicate. :)
> 
> - Replace boolean return value with int as much as possible.
> - Replace customized debug ASSERT() function & macros with DRM_DEBUG_*
> - Document all non-static functions like i915
> - Fix all whitespace via scripts/cleanpatch.pl
> - Commit function structure refinement.
> - Change the register access behavior just like what i915 does.
> 
> For other comments, see my comments below. :)
> 
> On 01/29/16 21:57, Joonas Lahtinen wrote:
> > Hi,
> > 
> > TL;DR Overall, we have same problem as with the scheduler series, there
> > is too much placeholder stuff for easy review. Just squash enough code
> > into one commit so it actually does something logical that can be
> > reviewed and then extend it later. Then it can be reviewed and pushed.
> > Just splitting the code down to achieve smaller patches is not the
> > right thing to do.
> > 
> > Comments on the overall code: You need to document all header file
> > functions (in the source files), and it is good to document the static
> > functions within a file too, to make future maintenance easier.
> > 
> > It is not about splitting the code down to small chunks, but splitting
> > it down to small *logical* chunks. It doesn't make sense to commit
> > dozens of empty bodied functions for review, and then later add their
> > code.
> > 
> > If you add functions, only add them at a patch that takes them into use
> > too, unless we're talking about general purpose shared code. And also
> > remember to add the function body and documentation header. If you
> > simply add a "return 0;" or similar function body, do add a comment to
> > why the function does not exist and when it will.
> > 
> > Then, there is a trend of having a boolean return values in the code.
> > When possible, it should rather be int and the cause for failure should
> > be propagated from the last level all the way to up (-ENOMEN etc.).
> > This way debugging becomes easier and if new error conditions appear,
> > there is less of a maintenance burden to add the propagation later.
> > 
> > Finally, make sure to look at the existing driver parts and
> > https://www.kernel.org/doc/Documentation/CodingStyle
> > for proper coding style. There are lots of whitespace fixes needed in
> > this series, like array initializations.
> > 
> > I hope to see this first patch rerolled so that you squash some of the
> > later commits into it so that all functions have a body and you add
> > documentation for the functions so I can both see what it should do and
> > what it actually does. Only reroll the first patch, to keep the
> > iterative step smaller. Lets only then continue with the rest of the
> > series once we've reached a consensus on the formatting and style
> > basics.
> > 
> > See more comments below.
> > 
> > On to, 2016-01-28 at 18:21 +0800, Zhi Wang wrote:
> > > This patch introduces the very basic framework of GVT-g device model,
> > > includes basic prototypes, definitions, initialization.
> > > ---
> > >   arch/x86/include/asm/xen/interface.h  |   3 +
> > >   drivers/gpu/drm/i915/Kconfig  |  16 ++
> > >   drivers/gpu/drm/i915/Makefile |   2 +
> > >   drivers/gpu/drm/i915/gvt/Makefile |   5 +
> > >   drivers/gpu/drm/i915/gvt/debug.h  |  72 +++
> > >   drivers/gpu/drm/i915/gvt/fb_decoder.c |  34 
> > >   drivers/gpu/drm/i915/gvt/fb_decoder.h | 110 ++
> > >   drivers/gpu/drm/i915/gvt/gvt.c| 366 
> > > ++
> > >   drivers/gpu/drm/i915/gvt/gvt.h| 130 
> > >   drivers/gpu/drm/i915/gvt/hypercall.h  |  30 +++
> > >   drivers/gpu/drm/i915/gvt/mpt.h|  97 +
> > >   drivers/gpu/drm/i915/gvt/params.c |  29 +++
> > >   drivers/gpu/drm/i915/gvt/params.h |  34 
> > >   drivers/gpu/drm/i915/gvt/reg.h|  34 
> > >   drivers/gpu/drm/i915/i915_dma.c   |  19 ++
> > >   drivers/gpu/drm/i915/i915_drv.h   |   6 +
> > >   drivers/gpu/drm/i915/i915_vgpu.h  |   3 +
> > >   include/xen/interface/xen.h   |   1 +
> > >   18 files changed, 991 insertions(+)
> > >   create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
> > >   create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
> > >   create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
> > >   create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h
> > >   create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
> > >   create mode 100644 d

[Intel-gfx] Universal Plane with NV12 support on Skylake

[Tang, Jun]

Hi All,

Do we support NV12 format with universal plane on Skylake by now? Thanks.

-James

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

[Intel-gfx] [PATCH 3/8] drm/i915: Adding the parsing logic for the i2c element

[Jani Nikula]

From: vkorjani 

New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.

v2: Add i2c_put_adapter call(Jani), rebase

v3: corrected the retry loop(Jani), rebase

v4 by Jani:
 - don't put the adapter if get fails
 - print an error message if all retries exhausted
 - use a for loop
 - fix warnings for unused variables

v5 by Jani:
 - rebase on the skip i2c element patch

v6: by Jani:
 - ignore the gmbus i2c elements (Ville)

Signed-off-by: vkorjani 
Signed-off-by: Deepak M 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 64 --
 1 file changed, 61 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 6f013efba45b..f4d303ee538b 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -235,9 +236,66 @@ out:
return data;
 }
 
-static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 
*data)
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
 {
-   return data + *(data + 6) + 7;
+   struct i2c_adapter *adapter;
+   int ret, i;
+   u8 reg_offset, payload_size;
+   struct i2c_msg msg;
+   u8 *transmit_buffer;
+   u8 flag, resource_id, bus_number;
+   u16 slave_add;
+
+   flag = *data++;
+   resource_id = *data++;
+   bus_number = *data++;
+   slave_add = *(u16 *)(data);
+   data += 2;
+   reg_offset = *data++;
+   payload_size = *data++;
+
+   if (resource_id == 0xff || bus_number == 0xff) {
+   DRM_DEBUG_KMS("ignoring gmbus (resource id %02x, bus %02x)\n",
+ resource_id, bus_number);
+   goto out;
+   }
+
+   adapter = i2c_get_adapter(bus_number);
+   if (!adapter) {
+   DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
+   goto out;
+   }
+
+   transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
+   if (!transmit_buffer)
+   goto out_put;
+
+   transmit_buffer[0] = reg_offset;
+   memcpy(&transmit_buffer[1], data, payload_size);
+
+   msg.addr = slave_add;
+   msg.flags = 0;
+   msg.len = payload_size + 1;
+   msg.buf = &transmit_buffer[0];
+
+   for (i = 0; i < 6; i++) {
+   ret = i2c_transfer(adapter, &msg, 1);
+   if (ret == 1) {
+   goto out_free;
+   } else if (ret == -EAGAIN) {
+   usleep_range(1000, 2500);
+   } else {
+   break;
+   }
+   }
+
+   DRM_ERROR("i2c transfer failed: %d\n", ret);
+out_free:
+   kfree(transmit_buffer);
+out_put:
+   i2c_put_adapter(adapter);
+out:
+   return data + payload_size;
 }
 
 typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
@@ -246,7 +304,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
-   [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
+   [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
 };
 
 /*
-- 
2.1.4

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

[Intel-gfx] [PATCH 5/8] drm/i915: put the IOSF port defines in numerical order

[Jani Nikula]

Make it easier to spot duplicates.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c0bd691b41f8..f3b4b19198b9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -610,16 +610,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   IOSF_BYTE_ENABLES_SHIFT  4
 #define   IOSF_BAR_SHIFT   1
 #define   IOSF_SB_BUSY (1<<0)
-#define   IOSF_PORT_BUNIT  0x3
-#define   IOSF_PORT_PUNIT  0x4
+#define   IOSF_PORT_BUNIT  0x03
+#define   IOSF_PORT_PUNIT  0x04
 #define   IOSF_PORT_NC 0x11
 #define   IOSF_PORT_DPIO   0x12
-#define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_GPIO_NC0x13
 #define   IOSF_PORT_CCK0x14
-#define   IOSF_PORT_CCU0xA9
+#define   IOSF_PORT_DPIO_2 0x1a
+#define   IOSF_PORT_FLISDSI0x1b
 #define   IOSF_PORT_GPS_CORE   0x48
-#define   IOSF_PORT_FLISDSI0x1B
+#define   IOSF_PORT_CCU0xa9
 #define VLV_IOSF_DATA  _MMIO(VLV_DISPLAY_BASE + 0x2104)
 #define VLV_IOSF_ADDR  _MMIO(VLV_DISPLAY_BASE + 0x2108)
 
-- 
2.1.4

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

[Intel-gfx] [PATCH 1/8] drm/i915/dsi: defend gpio table against out of bounds access

[Jani Nikula]

Do not blindly trust the VBT data used for indexing.

Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 1d43e6f37fc1..4775aa5462e8 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -209,6 +209,11 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
/* pull up/down */
action = *data++;
 
+   if (gpio >= ARRAY_SIZE(gtable)) {
+   DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
+   goto out;
+   }
+
function = gtable[gpio].function_reg;
pad = gtable[gpio].pad_reg;
 
@@ -226,6 +231,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
vlv_gpio_nc_write(dev_priv, pad, val);
mutex_unlock(&dev_priv->sb_lock);
 
+out:
return data;
 }
 
-- 
2.1.4

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

[Intel-gfx] [PATCH 6/8] drm/i915/vlv: drop unused vlv_gps_core_read/write functions

[Jani Nikula]

Not needed.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 --
 drivers/gpu/drm/i915/i915_reg.h   |  1 -
 drivers/gpu/drm/i915/intel_sideband.c | 14 --
 3 files changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77227a39f3d5..af601be8b490 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3483,8 +3483,6 @@ u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 
reg);
 void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg);
 void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int 
reg, u32 val);
 u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3b4b19198b9..c761fa2f3b8b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -618,7 +618,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   IOSF_PORT_CCK0x14
 #define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_FLISDSI0x1b
-#define   IOSF_PORT_GPS_CORE   0x48
 #define   IOSF_PORT_CCU0xa9
 #define VLV_IOSF_DATA  _MMIO(VLV_DISPLAY_BASE + 0x2104)
 #define VLV_IOSF_ADDR  _MMIO(VLV_DISPLAY_BASE + 0x2108)
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 8831fc579ade..f5b0ab6f5942 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -171,20 +171,6 @@ void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 
reg, u32 val)
SB_CRWRDA_NP, reg, &val);
 }
 
-u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
-{
-   u32 val = 0;
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
-   SB_CRRDDA_NP, reg, &val);
-   return val;
-}
-
-void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
-{
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPS_CORE,
-   SB_CRWRDA_NP, reg, &val);
-}
-
 u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg)
 {
u32 val = 0;
-- 
2.1.4

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

[Intel-gfx] [PATCH 8/8] drm/i915/dsi: Added the generic gpio sequence support and gpio table

[Jani Nikula]

From: Deepak M 

The generic gpio is sequence is parsed from the VBT and the
GPIO table is updated with the North core, South core and
SUS core elements.

v2: Move changes in sideband.c file to new patch(Jani), rebase
v3: Moved the Macro`s to intel_dsi_panel_vbt.c (Jani)

v3 by Jani
- rebase on previous patches
- don't return null on errors

Signed-off-by: Deepak M 
Signed-off-by: Jani Nikula 

---

Mmmh, the gpio table actually has some pretty scary stuff. We shouldn't
trust the vbt not to clobber some of the GPIOs listed in the table!

Also, is this really vlv specific as noted by Ville? What about chv, not
to mention bxt?!
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 589 +++--
 1 file changed, 548 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index de1966552a33..b85d935617ef 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -59,30 +59,360 @@ static inline struct vbt_panel *to_vbt_panel(struct 
drm_panel *panel)
 
 #define NS_KHZ_RATIO 100
 
-#define GPI0_NC_0_HV_DDI0_HPD   0x4130
-#define GPIO_NC_0_HV_DDI0_PAD   0x4138
-#define GPIO_NC_1_HV_DDI0_DDC_SDA   0x4120
-#define GPIO_NC_1_HV_DDI0_DDC_SDA_PAD   0x4128
-#define GPIO_NC_2_HV_DDI0_DDC_SCL   0x4110
-#define GPIO_NC_2_HV_DDI0_DDC_SCL_PAD   0x4118
-#define GPIO_NC_3_PANEL0_VDDEN  0x4140
-#define GPIO_NC_3_PANEL0_VDDEN_PAD  0x4148
-#define GPIO_NC_4_PANEL0_BLKEN  0x4150
-#define GPIO_NC_4_PANEL0_BLKEN_PAD  0x4158
-#define GPIO_NC_5_PANEL0_BLKCTL 0x4160
-#define GPIO_NC_5_PANEL0_BLKCTL_PAD 0x4168
-#define GPIO_NC_6_PCONF00x4180
-#define GPIO_NC_6_PAD   0x4188
-#define GPIO_NC_7_PCONF00x4190
-#define GPIO_NC_7_PAD   0x4198
-#define GPIO_NC_8_PCONF00x4170
-#define GPIO_NC_8_PAD   0x4178
-#define GPIO_NC_9_PCONF00x4100
-#define GPIO_NC_9_PAD   0x4108
-#define GPIO_NC_10_PCONF0   0x40E0
-#define GPIO_NC_10_PAD  0x40E8
-#define GPIO_NC_11_PCONF0   0x40F0
-#define GPIO_NC_11_PAD  0x40F8
+#define MAX_GPIO_NUM_NC26
+#define MAX_GPIO_NUM_SC128
+#define MAX_GPIO_NUM   172
+
+#define HV_DDI0_HPD_GPIONC_0_PCONF0 0x4130
+#define HV_DDI0_HPD_GPIONC_0_PAD0x4138
+#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF0 0x4120
+#define HV_DDI0_DDC_SDA_GPIONC_1_PAD0x4128
+#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF0 0x4110
+#define HV_DDI0_DDC_SCL_GPIONC_2_PAD0x4118
+#define PANEL0_VDDEN_GPIONC_3_PCONF00x4140
+#define PANEL0_VDDEN_GPIONC_3_PAD   0x4148
+#define PANEL0_BKLTEN_GPIONC_4_PCONF0   0x4150
+#define PANEL0_BKLTEN_GPIONC_4_PAD  0x4158
+#define PANEL0_BKLTCTL_GPIONC_5_PCONF0  0x4160
+#define PANEL0_BKLTCTL_GPIONC_5_PAD 0x4168
+#define HV_DDI1_HPD_GPIONC_6_PCONF0 0x4180
+#define HV_DDI1_HPD_GPIONC_6_PAD0x4188
+#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF0 0x4190
+#define HV_DDI1_DDC_SDA_GPIONC_7_PAD0x4198
+#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF0 0x4170
+#define HV_DDI1_DDC_SCL_GPIONC_8_PAD0x4178
+#define PANEL1_VDDEN_GPIONC_9_PCONF00x4100
+#define PANEL1_VDDEN_GPIONC_9_PAD   0x4108
+#define PANEL1_BKLTEN_GPIONC_10_PCONF0  0x40E0
+#define PANEL1_BKLTEN_GPIONC_10_PAD 0x40E8
+#define PANEL1_BKLTCTL_GPIONC_11_PCONF0 0x40F0
+#define PANEL1_BKLTCTL_GPIONC_11_PAD0x40F8
+#define GP_INTD_DSI_TE1_GPIONC_12_PCONF00x40C0
+#define GP_INTD_DSI_TE1_GPIONC_12_PAD   0x40C8
+#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF00x41A0
+#define HV_DDI2_DDC_SDA_GPIONC_13_PAD   0x41A8
+#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF00x41B0
+#define HV_DDI2_DDC_SCL_GPIONC_14_PAD   0x41B8
+#define GP_CAMERASB00_GPIONC_15_PCONF0  0x4010
+#define GP_CAMERASB00_GPIONC_15_PAD 0x4018
+#define GP_CAMERASB01_GPIONC_16_PCONF0  0x4040
+#define GP_CAMERASB01_GPIONC_16_PAD 0x4048
+#define GP_CAMERASB02_GPIONC_17_PCONF0  0x4080
+#define GP_CAMERASB02_GPIONC_17_PAD 0x4088
+#define GP_CAMERASB03_GPIONC_18_PCONF0  0x40B0
+#define GP_CAMERASB03_GPIONC_18_PAD 0x40B8
+#define GP_CAMERASB04_GPIONC_19_PCONF0  0x4000
+#define GP_CAMERASB04_GPIONC_19_PAD 0x4008
+#define GP_CAMERASB05_GPIONC_20_PCONF0  0x4030
+#define GP_CAMERASB05_GPIONC_20_PAD 0x4038
+#define GP_CAMERASB06_GPIONC_21_PCONF0  0x4060
+#define GP_CAMERASB06_GPIONC_21_PAD 0x4068
+#define GP_CAMERASB07_GPIONC_22_PCONF0  0x40A0
+#define GP_CAMER

[Intel-gfx] [PATCH 4/8] drm/i915/dsi: skip gpio element execution when not supported

[Jani Nikula]

Skip v3 gpio element because the support is not there, and skip gpio
element on non-vlv/chv because the sideband code is vlv/chv specific.

Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: 2a33d93486f2 ("drm/i915/bios: add support for MIPI sequence block v3")
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f4d303ee538b..3e1e70f81506 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -205,6 +205,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
struct drm_device *dev = intel_dsi->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   if (dev_priv->vbt.dsi.seq_version >= 3)
+   data++;
+
gpio = *data++;
 
/* pull up/down */
@@ -215,6 +218,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
goto out;
}
 
+   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
+   DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
+   goto out;
+   }
+
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   DRM_DEBUG_KMS("GPIO element v3 not supported\n");
+   goto out;
+   }
+
function = gtable[gpio].function_reg;
pad = gtable[gpio].pad_reg;
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Use insert_page for pwrite_fast

[kbuild test robot]

Hi Ankitprasad,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.5-rc2 next-20160204]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/ankitprasad-r-sharma-intel-com/Support-for-creating-using-Stolen-memory-backed-objects/20160204-175614
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/drm/drm_crtc.h:1533: warning: No description found for parameter 
'mutex'
   include/drm/drm_crtc.h:1533: warning: No description found for parameter 
'helper_private'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tile_idr'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'delayed_event'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'edid_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'dpms_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'path_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tile_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'plane_type_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'rotation_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_src_x'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_src_y'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_src_w'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_src_h'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_crtc_x'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_crtc_y'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_crtc_w'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_crtc_h'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_fb_id'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_crtc_id'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_active'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'prop_mode_id'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_subconnector_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_select_subconnector_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_mode_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_left_margin_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_right_margin_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_top_margin_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_bottom_margin_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_brightness_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_contrast_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_overscan_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_saturation_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'tv_hue_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'scaling_mode_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'aspect_ratio_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'dirty_info_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'suggested_x_property'
   include/drm/drm_crtc.h:2142: warning: No description found for parameter 
'suggested_y_pr

[Intel-gfx] [PATCH 7/8] drm/i915: Extend gpio read/write to other cores

[Jani Nikula]

From: Deepak M 

Make the gpio read/write functions more generic iosf sideband read/write
functions, taking the iosf port as argument.

v2: rebase
v3: rebase
v4 by Jani: address Ville's review

Signed-off-by: Deepak M 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h| 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +++--
 drivers/gpu/drm/i915/intel_sideband.c  | 9 +
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index af601be8b490..47da528c16d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3475,8 +3475,8 @@ int sandybridge_pcode_write(struct drm_i915_private 
*dev_priv, u32 mbox, u32 val
 u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
 void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
 u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
+void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
u32 val);
 u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c761fa2f3b8b..d00e5b8e5469 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -618,6 +618,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   IOSF_PORT_CCK0x14
 #define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_FLISDSI0x1b
+#define   IOSF_PORT_GPIO_SC0x48
+#define   IOSF_PORT_GPIO_SUS   0xa8
 #define   IOSF_PORT_CCU0xa9
 #define VLV_IOSF_DATA  _MMIO(VLV_DISPLAY_BASE + 0x2104)
 #define VLV_IOSF_ADDR  _MMIO(VLV_DISPLAY_BASE + 0x2108)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 3e1e70f81506..de1966552a33 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -235,14 +235,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
if (!gtable[gpio].init) {
/* program the function */
/* FIXME: remove constant below */
-   vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
+   vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
+ 0x2000CC00);
gtable[gpio].init = 1;
}
 
val = 0x4 | action;
 
/* pull up/down */
-   vlv_gpio_nc_write(dev_priv, pad, val);
+   vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
mutex_unlock(&dev_priv->sb_lock);
 
 out:
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index f5b0ab6f5942..78c3d93fd963 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
addr)
return val;
 }
 
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
+u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg)
 {
u32 val = 0;
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), port,
SB_CRRDDA_NP, reg, &val);
return val;
 }
 
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+void vlv_iosf_sb_write(struct drm_i915_private *dev_priv,
+  u8 port, u32 reg, u32 val)
 {
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), port,
SB_CRWRDA_NP, reg, &val);
 }
 
-- 
2.1.4

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

[Intel-gfx] [PATCH 2/8] drm/i915/dsi: don't pass arbitrary data to sideband

[Jani Nikula]

Since sequence block v2 the second byte contains flags other than just
pull up/down. Don't pass arbitrary data to the sideband interface.

The rest may or may not work for sequence block v2, but there should be
no harm done.

Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 4775aa5462e8..6f013efba45b 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -207,7 +207,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
gpio = *data++;
 
/* pull up/down */
-   action = *data++;
+   action = *data++ & 1;
 
if (gpio >= ARRAY_SIZE(gtable)) {
DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
-- 
2.1.4

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

[Intel-gfx] [PATCH 0/8] drm/i915/dsi: i2c/gpio

[Jani Nikula]

Sme fixes to i2c/gpio elements in dsi. I think patches 1-4 are needed
for bxt at this time. The remaining patches don't really help, since the
sideband code is vlv/chv specific anyway.

BR,
Jani.

Deepak M (2):
  drm/i915: Extend gpio read/write to other cores
  drm/i915/dsi: Added the generic gpio sequence support and gpio table

Jani Nikula (5):
  drm/i915/dsi: defend gpio table against out of bounds access
  drm/i915/dsi: don't pass arbitrary data to sideband
  drm/i915/dsi: skip gpio element execution when not supported
  drm/i915: put the IOSF port defines in numerical order
  drm/i915/vlv: drop unused vlv_gps_core_read/write functions

vkorjani (1):
  drm/i915: Adding the parsing logic for the i2c element

 drivers/gpu/drm/i915/i915_drv.h|   6 +-
 drivers/gpu/drm/i915/i915_reg.h|  13 +-
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 669 +++--
 drivers/gpu/drm/i915/intel_sideband.c  |  23 +-
 4 files changed, 641 insertions(+), 70 deletions(-)

-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Remove atomic.pre_disable_primary.

[Maarten Lankhorst]

Op 03-02-16 om 18:39 schreef Ville Syrjälä:
> On Wed, Feb 03, 2016 at 06:23:13PM +0100, Maarten Lankhorst wrote:
>> Op 03-02-16 om 17:07 schreef Ville Syrjälä:
>>> On Wed, Feb 03, 2016 at 04:53:24PM +0100, Maarten Lankhorst wrote:
 This can be derived from the atomic state in pre_plane_update,
 which makes it more clear when it's supposed to be called.

 Reviewed-by: Ander Conselvan de Oliveira 
 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/intel_display.c | 25 +++--
  drivers/gpu/drm/i915/intel_drv.h |  1 -
  2 files changed, 19 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index de94ef165fbe..c7f2a18ab34e 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -4807,19 +4807,33 @@ static void intel_post_plane_update(struct 
 intel_crtc *crtc)
memset(atomic, 0, sizeof(*atomic));
  }
  
 -static void intel_pre_plane_update(struct intel_crtc *crtc)
 +static void intel_pre_plane_update(struct intel_crtc_state 
 *old_crtc_state)
  {
 +  struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
 +  struct drm_atomic_state *old_state = old_crtc_state->base.state;
 +  struct drm_plane *primary = crtc->base.primary;
 +  struct drm_plane_state *old_pri_state =
 +  drm_atomic_get_existing_plane_state(old_state, primary);
 +  bool modeset = needs_modeset(&pipe_config->base);
  
if (atomic->update_fbc)
intel_fbc_pre_update(crtc);
  
 -  if (atomic->pre_disable_primary)
 -  intel_pre_disable_primary(&crtc->base);
 +  if (old_pri_state) {
>>> When might we not have and old state for the primary plane?
>>>
>> When updating some state unrelated to the primary plane, for example 
>> changing cursor.
> Hmm. I thought we added all the planes to the state currently...
> I guess that only happens due to watermark calculation on specific
> platforms.
>
Yes we do and that's a bug. I have a patch to reuse the old values for the 
planes not part of the state,
I just didn't send it upstream yet.

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915/skl: fix RC6 residency time calculation

[Kamble, Sagar A]

Ok. I related my change to below definition:

#define GT_INTERVAL_FROM_US(dev_priv, us) (IS_GEN9(dev_priv) ? \
(IS_BROXTON(dev_priv) ? \
INTERVAL_0_833_US(us) : \
INTERVAL_1_33_US(us)) : \
INTERVAL_1_28_US(us))

This is using 1.33us unit for SKL.
May be we need to define these based on mode (normal/PSMI).
Not sure how to determine modes.

Thanks
Sagar


On 2/3/2016 10:40 PM, Imre Deak wrote:

On ke, 2016-02-03 at 11:29 +0530, Sagar Arun Kamble wrote:

The RC6 residency time unit is 1.33us on SKL according to the
specification, so update the calculation accordingly.

Cc: Imre Deak 
Signed-off-by: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/i915_sysfs.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index c6188dd..9aa49a9 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -58,7 +58,8 @@ static u32 calc_residency(struct drm_device *dev,
} else if (IS_BROXTON(dev)) {
units = 1;
div = 1200; /* 833.33ns */
-   }
+   } else if (IS_SKYLAKE(dev))
+   units = 133ULL;

Hrm. The SKL/GT_GFX_RC6 description in ConfigDB doesn't say anything
about the units, the BSpec "Timestamp Bases" provides two values for
two different modes:

1.33us and 1.28us

Not sure what are these different modes.

BSpec GT_GFX_RC6 description specifies 1.28us.

Running igt/pm_rc6_residency calculating with the current 1.28us results in:
Residency in rc6 or deeper state: 2983 ms (sleep duration 3003 ms) (ratio to 
expected duration: 0,99)
Subtest rc6-accuracy: SUCCESS (0,000s)

and after applying your patch (calculating with 1.33us):
Residency in rc6 or deeper state: 3101 ms (sleep duration 3001 ms) (ratio to 
expected duration: 1,03)
(pm_rc6_residency:6281) CRITICAL: Test assertion failure function 
residency_accuracy, file pm_rc6_residency.c:110:
(pm_rc6_residency:6281) CRITICAL: Failed assertion: ratio > 0.9 && ratio <= 1
(pm_rc6_residency:6281) CRITICAL: Sysfs RC6 residency counter is inaccurate.

While the measurement can be inaccurate, normally we should only err by
measuring less duration in RC6 than the duration of the actual sleep.
So I'm not convinced that 1.33us is the correct value..

--Imre

  
  	raw_time = I915_READ(reg) * units;

ret = DIV_ROUND_UP_ULL(raw_time, div);


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

[Intel-gfx] [PATCH 04/10] drm/i915: Clearing buffer objects via CPU/GTT

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.

v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
variable assignments (Tvrtko)

v3: Map object page by page to the gtt if the pinning of the whole object
to the ggtt fails, Corrected function name (Chris)

v4: Clear the buffer page by page, and not map the whole object in the gtt
aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.

v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
updated barrier positioning (Chris)

v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
(Tvrtko)

v7: Fixed the onion (undo operation in reverse order) (Chris)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 47 +
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4c25c6..1122e1b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2938,6 +2938,7 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
int *needs_clflush);
 
 int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+int i915_gem_object_clear(struct drm_i915_gem_object *obj);
 
 static inline int __sg_page_count(struct scatterlist *sg)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 49a03f2..1aa4fc9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5405,3 +5405,50 @@ fail:
drm_gem_object_unreference(&obj->base);
return ERR_PTR(ret);
 }
+
+/**
+ * i915_gem_object_clear() - Clear buffer object via CPU/GTT
+ * @obj: Buffer object to be cleared
+ *
+ * Return: 0 - success, non-zero - failure
+ */
+int i915_gem_object_clear(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct drm_mm_node node;
+   char __iomem *base;
+   uint64_t size = obj->base.size;
+   int ret, i;
+
+   lockdep_assert_held(&obj->base.dev->struct_mutex);
+   ret = insert_mappable_node(i915, &node, PAGE_SIZE);
+   if (ret)
+   return ret;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret)
+   goto err_remove_node;
+
+   i915_gem_object_pin_pages(obj);
+   base = io_mapping_map_wc(i915->gtt.mappable, node.start);
+
+   for (i = 0; i < size/PAGE_SIZE; i++) {
+   i915->gtt.base.insert_page(&i915->gtt.base,
+  i915_gem_object_get_dma_address(obj, 
i),
+  node.start,
+  I915_CACHE_NONE, 0);
+   wmb(); /* flush modifications to the GGTT (insert_page) */
+   memset_io(base, 0, PAGE_SIZE);
+   wmb(); /* flush the write before we modify the GGTT */
+   }
+
+   io_mapping_unmap(base);
+   i915->gtt.base.clear_range(&i915->gtt.base,
+   node.start, node.size,
+   true);
+   i915_gem_object_unpin_pages(obj);
+
+err_remove_node:
+   remove_mappable_node(&node);
+   return ret;
+}
-- 
1.9.1

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

[Intel-gfx] [PATCH 06/10] drm/i915: Propagating correct error codes to the userspace

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user whenever there is a failure in object
allocation. This patch helps user to identify the correct reason for the
failure and not just -ENOMEM each time.

v2: Moved the patch up in the series, added error propagation for
i915_gem_alloc_object too (Chris)

v3: Removed storing of error pointer inside structs, Corrected error
propagation in caller functions (Chris)

v4: Remove assignments inside the predicate (Chris)

v5: Removed unnecessary initializations, updated kerneldoc for
i915_guc_client, corrected missed error pointer handling (Tvrtko)

v6: Use ERR_CAST/temporary variable to avoid storing invalid pointer
in a common field (Chris)

v7: Resolved rebasing conflicts (Ankit)

v8: Removed redundant code (Chris)

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c  | 23 ++--
 drivers/gpu/drm/i915/i915_gem_batch_pool.c   |  4 +--
 drivers/gpu/drm/i915/i915_gem_context.c  |  4 +--
 drivers/gpu/drm/i915/i915_gem_render_state.c |  7 ++--
 drivers/gpu/drm/i915/i915_gem_stolen.c   | 53 +++-
 drivers/gpu/drm/i915/i915_guc_submission.c   | 52 +--
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  6 ++--
 drivers/gpu/drm/i915/intel_lrc.c | 10 +++---
 drivers/gpu/drm/i915/intel_overlay.c |  4 +--
 drivers/gpu/drm/i915/intel_pm.c  |  7 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 21 +--
 12 files changed, 110 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 60d27fe..d63f18c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -397,19 +397,18 @@ i915_gem_alloc_object_stolen(struct drm_device *dev, 
size_t size)
 
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen(dev, size);
-   if (!obj) {
-   mutex_unlock(&dev->struct_mutex);
-   return NULL;
-   }
+   if (IS_ERR(obj))
+   goto out;
 
/* Always clear fresh buffers before handing to userspace */
ret = i915_gem_object_clear(obj);
if (ret) {
drm_gem_object_unreference(&obj->base);
-   mutex_unlock(&dev->struct_mutex);
-   return NULL;
+   obj = ERR_PTR(ret);
+   goto out;
}
 
+out:
mutex_unlock(&dev->struct_mutex);
return obj;
 }
@@ -444,8 +443,8 @@ i915_gem_create(struct drm_file *file,
return -EINVAL;
}
 
-   if (obj == NULL)
-   return -ENOMEM;
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
 
ret = drm_gem_handle_create(file, &obj->base, &handle);
/* drop reference from allocate - handle holds it now */
@@ -4562,14 +4561,16 @@ struct drm_i915_gem_object 
*i915_gem_alloc_object(struct drm_device *dev,
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
+   int ret;
 
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
-   if (drm_gem_object_init(dev, &obj->base, size) != 0) {
+   ret = drm_gem_object_init(dev, &obj->base, size);
+   if (ret) {
i915_gem_object_free(obj);
-   return NULL;
+   return ERR_PTR(ret);
}
 
mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 7bf2f3f..d79caa2 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -135,8 +135,8 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
int ret;
 
obj = i915_gem_alloc_object(pool->dev, size);
-   if (obj == NULL)
-   return ERR_PTR(-ENOMEM);
+   if (IS_ERR(obj))
+   return obj;
 
ret = i915_gem_object_get_pages(obj);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 83a097c..2dd5fed 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -179,8 +179,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t 
size)
int ret;
 
obj = i915_gem_alloc_object(dev, size);
-   if (obj == NULL)
-   return ERR_PTR(-ENOMEM);
+   if (IS_ERR(obj))
+   return obj;
 
/*
 * Try to make the context utilize L3 as well as LLC.
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH 08/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.

v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)

v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)

v6: Using pwrite_fast for non-shmem backed objects as well (Chris)

v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)

v8: Updated v7 commit message, mutex unlock around pwrite slow path for
non-shmem backed objects (Tvrtko)

v9: Corrected check during pread_ioctl, to avoid shmem_pread being
called for non-shmem backed objects (Tvrtko)

v10: Moved the write_domain check to needs_clflush and tiling mode check
to pwrite_fast (Chris)

v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
call fast_user_write regardless of pagefault in previous iteration

v12: Use page-by-page copy for slow user access too (Chris)

v13: Handled EFAULT, Avoid use of WARN_ON, put_fence only if whole obj
pinned (Chris)

Testcase: igt/gem_stolen, igt/gem_pread, igt/gem_pwrite

Signed-off-by: Ankitprasad Sharma 
---
 drivers/gpu/drm/i915/i915_gem.c | 211 ++--
 1 file changed, 179 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ed8ae5d..40f2906 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -55,6 +55,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
 
 static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
 {
+   if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+   return false;
+
if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
return true;
 
@@ -646,6 +649,141 @@ shmem_pread_slow(struct page *page, int 
shmem_page_offset, int page_length,
return ret ? - EFAULT : 0;
 }
 
+static inline uint64_t
+slow_user_access(struct io_mapping *mapping,
+uint64_t page_base, int page_offset,
+char __user *user_data,
+int length, bool pwrite)
+{
+   void __iomem *ioaddr;
+   void *vaddr;
+   uint64_t unwritten;
+
+   ioaddr = io_mapping_map_wc(mapping, page_base);
+   /* We can use the cpu mem copy function because this is X86. */
+   vaddr = (void __force *)ioaddr + page_offset;
+   if (pwrite)
+   unwritten = __copy_from_user(vaddr, user_data, length);
+   else
+   unwritten = __copy_to_user(user_data, vaddr, length);
+
+   io_mapping_unmap(ioaddr);
+   return unwritten;
+}
+
+static int
+i915_gem_gtt_pread(struct drm_device *dev,
+  struct drm_i915_gem_object *obj, uint64_t size,
+  uint64_t data_offset, uint64_t data_ptr)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_mm_node node;
+   char __user *user_data;
+   uint64_t remain;
+   uint64_t offset;
+   int ret = 0;
+
+   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   if (ret) {
+   ret = insert_mappable_node(dev_priv, &node, PAGE_SIZE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret) {
+   remove_mappable_node(&node);
+   goto out;
+   }
+
+   i915_gem_object_pin_pages(obj);
+   } else {
+   node.start = i915_gem_obj_ggtt_offset(obj);
+   node.allocated = false;
+   ret = i915_gem_object_put_fence(obj);
+   if (ret)
+   goto out_unpin;
+   }
+
+   ret = i915_gem_object_set_to_gtt_domain(obj, false);
+   if (ret)
+   goto out_unpin;
+
+   user_data = to_user_ptr(data_ptr);
+   remain = size;
+   offset = i915_gem_obj_ggtt_offset(obj) + data_offset;
+
+   mutex_unlock(&dev->struct_mutex);
+   if (likely(!i915.prefault_disable)) {
+   ret = fault_in_multipages_writeable(user_data, remain);
+   if (ret) {
+   mutex_lock(&dev->struct_mutex);
+   goto out_unpin;
+   }
+   }
+
+   while (remain > 0) {
+   /* Operation in this page
+*
+* page_base = page offset within aperture
+* page_offset = offset within page
+* page_length = bytes to copy for th

[Intel-gfx] [PATCH 05/10] drm/i915: Support for creating Stolen memory backed objects

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, which if set, an attempt will be made to allocate
the object from stolen memory subject to the availability of
free space in the stolen region.

v2: Rebased to the latest drm-intel-nightly (Ankit)

v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)

v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
Corrected function arguments ordering (Chris)

v5: Corrected function name (Chris)

v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
aligned (Chris)

v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
function for object allocation from stolen region (Ankit)

v8: Added comment explaining STOLEN placement flag (Chris)

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_dma.c|  3 +++
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 45 +++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |  4 +--
 include/uapi/drm/i915_drm.h| 41 +++
 5 files changed, 89 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a42eb58..1aa2cb6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -172,6 +172,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_SOFTPIN:
value = 1;
break;
+   case I915_PARAM_CREATE_VERSION:
+   value = 2;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1122e1b..55f2de9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3301,7 +3301,7 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*dev_priv,
 int i915_gem_init_stolen(struct drm_device *dev);
 void i915_gem_cleanup_stolen(struct drm_device *dev);
 struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+i915_gem_object_create_stolen(struct drm_device *dev, u64 size);
 struct drm_i915_gem_object *
 i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
   u32 stolen_offset,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1aa4fc9..60d27fe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -389,10 +389,36 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
kmem_cache_free(dev_priv->objects, obj);
 }
 
+static struct drm_i915_gem_object *
+i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
+{
+   struct drm_i915_gem_object *obj;
+   int ret;
+
+   mutex_lock(&dev->struct_mutex);
+   obj = i915_gem_object_create_stolen(dev, size);
+   if (!obj) {
+   mutex_unlock(&dev->struct_mutex);
+   return NULL;
+   }
+
+   /* Always clear fresh buffers before handing to userspace */
+   ret = i915_gem_object_clear(obj);
+   if (ret) {
+   drm_gem_object_unreference(&obj->base);
+   mutex_unlock(&dev->struct_mutex);
+   return NULL;
+   }
+
+   mutex_unlock(&dev->struct_mutex);
+   return obj;
+}
+
 static int
 i915_gem_create(struct drm_file *file,
struct drm_device *dev,
uint64_t size,
+   uint64_t flags,
uint32_t *handle_p)
 {
struct drm_i915_gem_object *obj;
@@ -403,8 +429,21 @@ i915_gem_create(struct drm_file *file,
if (size == 0)
return -EINVAL;
 
+   if (flags & __I915_CREATE_UNKNOWN_FLAGS)
+   return -EINVAL;
+
/* Allocate the new object */
-   obj = i915_gem_alloc_object(dev, size);
+   switch (flags & I915_CREATE_PLACEMENT_MASK) {
+   case I915_CREATE_PLACEMENT_NORMAL:
+   obj = i915_gem_alloc_object(dev, size);
+   break;
+   case I915_CREATE_PLACEMENT_STOLEN:
+   obj = i915_gem_alloc_object_stolen(dev, size);
+   break;
+   default:
+   return -EINVAL;
+   }
+
if (obj == NULL)
return -ENOMEM;
 
@@ -427,7 +466,7 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
args->size = args->pitch * args->height;
return i915_gem_create(file, dev,
-  args->size, &args->handle);
+  args->size, 0, &args->handle);

[Intel-gfx] [PATCH 03/10] drm/i915: Use insert_page for pwrite_fast

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than the mappable
aperture (e.g. if we need to pwrite with vGPU restricting the aperture
to a measely 8MiB or something like that).

v2: Pin pages before starting pwrite, Combined duplicate loops (Chris)

v3: Combined loops based on local patch by Chris (Chris)

v4: Added i915 wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Renamed wrapper function for drm_mm_insert_node_in_range (Chris)

v5: Added wrapper for drm_mm_remove_node() (Chris)

v6: Added get_pages call before pinning the pages (Tvrtko)
Added remove_mappable_node() wrapper for drm_mm_remove_node() (Chris)

v7: Added size argument for insert_mappable_node (Tvrtko)

v8: Do not put_pages after pwrite, do memset of node in the wrapper
function (insert_mappable_node) (Chris)

Signed-off-by: Ankitprasad Sharma 
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 92 +++--
 1 file changed, 70 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a928823..49a03f2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -61,6 +61,24 @@ static bool cpu_write_needs_clflush(struct 
drm_i915_gem_object *obj)
return obj->pin_display;
 }
 
+static int
+insert_mappable_node(struct drm_i915_private *i915,
+ struct drm_mm_node *node, u32 size)
+{
+   memset(node, 0, sizeof(*node));
+   return drm_mm_insert_node_in_range_generic(&i915->gtt.base.mm, node,
+  size, 0, 0, 0,
+  i915->gtt.mappable_end,
+  DRM_MM_SEARCH_DEFAULT,
+  DRM_MM_CREATE_DEFAULT);
+}
+
+static void
+remove_mappable_node(struct drm_mm_node *node)
+{
+   drm_mm_remove_node(node);
+}
+
 /* some bookkeeping */
 static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
  size_t size)
@@ -760,20 +778,33 @@ fast_user_write(struct io_mapping *mapping,
  * user into the GTT, uncached.
  */
 static int
-i915_gem_gtt_pwrite_fast(struct drm_device *dev,
+i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
 struct drm_i915_gem_object *obj,
 struct drm_i915_gem_pwrite *args,
 struct drm_file *file)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   ssize_t remain;
-   loff_t offset, page_base;
+   struct drm_mm_node node;
+   uint64_t remain, offset;
char __user *user_data;
-   int page_offset, page_length, ret;
+   int ret;
 
ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
-   if (ret)
-   goto out;
+   if (ret) {
+   ret = insert_mappable_node(i915, &node, PAGE_SIZE);
+   if (ret)
+   goto out;
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret) {
+   remove_mappable_node(&node);
+   goto out;
+   }
+
+   i915_gem_object_pin_pages(obj);
+   } else {
+   node.start = i915_gem_obj_ggtt_offset(obj);
+   node.allocated = false;
+   }
 
ret = i915_gem_object_set_to_gtt_domain(obj, true);
if (ret)
@@ -783,31 +814,39 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;
 
-   user_data = to_user_ptr(args->data_ptr);
-   remain = args->size;
-
-   offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
-
intel_fb_obj_invalidate(obj, ORIGIN_GTT);
+   obj->dirty = true;
 
-   while (remain > 0) {
+   user_data = to_user_ptr(args->data_ptr);
+   offset = args->offset;
+   remain = args->size;
+   while (remain) {
/* Operation in this page
 *
 * page_base = page offset within aperture
 * page_offset = offset within page
 * page_length = bytes to copy for this page
 */
-   page_base = offset & PAGE_MASK;
-   page_offset = offset_in_page(offset);
-   page_length = remain;
-   if ((page_offset + remain) > PAGE_SIZE)
-   page_length = PAGE_SIZE - page_offset;
-
+   u32 page_base = node.start;
+   unsigned page_offset = offset_in_page(offset);
+   unsigned page_length = PAGE_SIZE - page_offset;
+   page_length = remain < page_length ? rem

[Intel-gfx] [PATCH 02/10] drm/i915: Introduce i915_gem_object_get_dma_address()

[ankitprasad . r . sharma]

From: Chris Wilson 

This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
---
 drivers/gpu/drm/i915/i915_drv.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65a2cd0..e4c25c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2947,6 +2947,23 @@ static inline int __sg_page_count(struct scatterlist *sg)
 struct page *
 i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
 
+static inline dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
+{
+   if (n < obj->get_page.last) {
+   obj->get_page.sg = obj->pages->sgl;
+   obj->get_page.last = 0;
+   }
+
+   while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
+   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
+   if (unlikely(sg_is_chain(obj->get_page.sg)))
+   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
+   }
+
+   return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) << 
PAGE_SHIFT);
+}
+
 static inline struct page *
 i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
 {
-- 
1.9.1

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

[Intel-gfx] [PATCH v16 0/10] Support for creating/using Stolen memory backed objects

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

This patch series adds support for creating/using Stolen memory backed
objects.

Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIOS and reserved
for igfx use. Stolen memory is required for some functions of the GPU
and display engine, but in general it goes wasted. Whilst we cannot
return it back to the system, we need to find some other method for
utilising it. As we do not support direct access to the physical address
in the stolen region, it behaves like a different class of memory,
closer in kin to local GPU memory. This strongly suggests that we need a
placement model like TTM if we are to fully utilize these discrete
chunks of differing memory.

To add support for creating Stolen memory backed objects, we extend the
drm_i915_gem_create structure, by adding a new flag through which user
can specify the preference to allocate the object from stolen memory,
which if set, an attempt will be made to allocate the object from stolen
memory subject to the availability of free space in the stolen region.

This patch series adds support for clearing buffer objects via CPU/GTT.
This is particularly useful for clearing out the memory from stolen
region, but can also be used for other shmem allocated objects. Currently
being used for buffers allocated in the stolen region. Also adding support
for stealing purgable stolen pages, if we run out of stolen memory when
trying to allocate an object.

v2: Added support for read/write from/to objects not backed by
shmem using the pread/pwrite interface.
Also extended the current get_aperture ioctl to retrieve the
total and available size of the stolen region.

v3: Removed the extended get_aperture ioctl patch 5 (to be submitted as
part of other patch series), addressed comments by Chris about pread/pwrite
for non shmem backed objects.

v4: Rebased to the latest drm-intel-nightly.

v5: Addressed comments, replaced patch 1/4 "Clearing buffers via blitter
engine" by "Clearing buffers via CPU/GTT".

v6: Rebased to the latest drm-intel-nightly, Addressed comments, updated
stolen memory purging logic by maintaining a list for purgable stolen
memory objects, enabled pread/pwrite for all non-shmem backed objects
without tiling restrictions.

v7: Addressed comments, compiler optimization, new patch added for correct
error code propagation to the userspace.

v8: Added a new patch to the series to Migrate stolen objects before
hibernation, as stolen memory is not preserved across hibernation. Added
correct error propagation for shmem as well non-shmem backed object allocation.

v9: Addressed comments, use of insert_page helper function to map object page
by page which can be helpful in low aperture space availability.

v10: Addressed comments, use insert_page for clearing out the stolen memory

v11: Addressed comments, 3 new patches added to support allocation from Stolen
memory
1. Allow use of i915_gem_object_get_dma_address for stolen backed objects
2. Use insert_page for pwrite_fast
3. Fail the execbuff using stolen objects as batchbuffers

v12: Addressed comments, Removed patch "Fail the execbuff using stolen objects
as batchbuffers"

v13: Addressed comments, Added 2 patches to detect Intel RST and disable stolen
for persistent data if RST device found
1. acpi: Export acpi_bus_type
2. drm/i915: Disable use of stolen area by User when Intel RST is present

v14: Addressed comments, Added 2 base patches to the series
1. drm/i915: Add support for mapping an object page by page
2. drm/i915: Introduce i915_gem_object_get_dma_address()

v15: Addressed comments, Disabled stolen memory by default

v16: Addressed comments, Added low level rpm assertions, Enabled stolen
memory

This can be verified using IGT tests: igt/gem_stolen, igt/gem_create

Ankitprasad Sharma (6):
  drm/i915: Use insert_page for pwrite_fast
  drm/i915: Clearing buffer objects via CPU/GTT
  drm/i915: Support for creating Stolen memory backed objects
  drm/i915: Propagating correct error codes to the userspace
  drm/i915: Support for pread/pwrite from/to non shmem backed objects
  drm/i915: Disable use of stolen area by User when Intel RST is present

Chris Wilson (4):
  drm/i915: Add support for mapping an object page by page
  drm/i915: Introduce i915_gem_object_get_dma_address()
  drm/i915: Add support for stealing purgable stolen pages
  drm/i915: Migrate stolen objects before hibernation

 drivers/char/agp/intel-gtt.c |   9 +
 drivers/gpu/drm/i915/i915_debugfs.c  |   6 +-
 drivers/gpu/drm/i915/i915_dma.c  |   3 +
 drivers/gpu/drm/i915/i915_drv.c  |  17 +-
 drivers/gpu/drm/i915/i915_drv.h  |  58 ++-
 drivers/gpu/drm/i915/i915_gem.c  | 621 ---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c   |   4 +-
 drivers/gpu/drm/i915/i915_gem_context.c  |   4 +-

[Intel-gfx] [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present

[ankitprasad . r . sharma]

From: Ankitprasad Sharma 

The BIOS RapidStartTechnology may corrupt the stolen memory across S3
suspend due to unalarmed hibernation, in which case we will not be able
to preserve the User data stored in the stolen region. Hence this patch
tries to identify presence of the RST device on the ACPI bus, and
disables use of stolen memory (for persistent data) if found.

v2: Updated comment, updated/corrected new functions private to driver
(Chris/Tvrtko)

v3: Disabling stolen by default, wait till required acpi changes to
detect device presence are pulled in (Ankit)

v4: Enabled stolen by default as required acpi changes are merged
(Ankit)

Signed-off-by: Ankitprasad Sharma 
---
 drivers/gpu/drm/i915/i915_drv.h| 11 +++
 drivers/gpu/drm/i915/i915_gem.c|  8 
 drivers/gpu/drm/i915/i915_gem_stolen.c | 14 ++
 drivers/gpu/drm/i915/intel_acpi.c  | 10 ++
 4 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 16f2f94..9d67097 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1349,6 +1349,16 @@ struct i915_gem_mm {
 */
bool busy;
 
+   /**
+* Stolen will be lost upon hibernate (as the memory is unpowered).
+* Across resume, we expect stolen to be intact - however, it may
+* also be utililised by third parties (e.g. Intel RapidStart
+* Technology) and if so we have to assume that any data stored in
+* stolen across resume is lost and we set this flag to indicate that
+* the stolen memory is volatile.
+*/
+   bool nonvolatile_stolen;
+
/* the indicator for dispatch video commands on two BSD rings */
unsigned int bsd_ring_dispatch_index;
 
@@ -3465,6 +3475,7 @@ intel_opregion_notify_adapter(struct drm_device *dev, 
pci_power_t state)
 #endif
 
 /* intel_acpi.c */
+bool intel_detect_acpi_rst(void);
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
 extern void intel_unregister_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0cd57d4..63dab63 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -396,8 +396,16 @@ static struct drm_i915_gem_object *
 i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
 {
struct drm_i915_gem_object *obj;
+   struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
+   if (!dev_priv->mm.nonvolatile_stolen) {
+   /* Stolen may be overwritten by external parties
+* so unsuitable for persistent user data.
+*/
+   return ERR_PTR(-ENODEV);
+   }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen(dev, size);
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 335a1ef..4f44531 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -482,6 +482,20 @@ int i915_gem_init_stolen(struct drm_device *dev)
 */
drm_mm_init(&dev_priv->mm.stolen, 0, dev_priv->gtt.stolen_usable_size);
 
+   /* If the stolen region can be modified behind our backs upon suspend,
+* then we cannot use it to store nonvolatile contents (i.e user data)
+* as it will be corrupted upon resume.
+*/
+   dev_priv->mm.nonvolatile_stolen = true;
+#ifdef CONFIG_SUSPEND
+   if (intel_detect_acpi_rst()) {
+   /* BIOSes using RapidStart Technology have been reported
+* to overwrite stolen across S3, not just S4.
+*/
+   dev_priv->mm.nonvolatile_stolen = false;
+   }
+#endif
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..67dc9b2 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -23,6 +23,11 @@ static const u8 intel_dsm_guid[] = {
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
+static const struct acpi_device_id irst_ids[] = {
+   {"INT3392", 0},
+   {"", 0}
+};
+
 static char *intel_dsm_port_name(u8 id)
 {
switch (id) {
@@ -162,3 +167,8 @@ void intel_register_dsm_handler(void)
 void intel_unregister_dsm_handler(void)
 {
 }
+
+bool intel_detect_acpi_rst(void)
+{
+   return acpi_dev_present(irst_ids[0].id);
+}
-- 
1.9.1

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

[Intel-gfx] [PATCH 09/10] drm/i915: Migrate stolen objects before hibernation

[ankitprasad . r . sharma]

From: Chris Wilson 

Ville reminded us that stolen memory is not preserved across
hibernation, and a result of this was that context objects now being
allocated from stolen were being corrupted on S4 and promptly hanging
the GPU on resume.

We want to utilise stolen for as much as possible (nothing else will use
that wasted memory otherwise), so we need a strategy for handling
general objects allocated from stolen and hibernation. A simple solution
is to do a CPU copy through the GTT of the stolen object into a fresh
shmemfs backing store and thenceforth treat it as a normal objects. This
can be refined in future to either use a GPU copy to avoid the slow
uncached reads (though it's hibernation!) and recreate stolen objects
upon resume/first-use. For now, a simple approach should suffice for
testing the object migration.

v2:
Swap PTE for pinned bindings over to the shmemfs. This adds a
complicated dance, but is required as many stolen objects are likely to
be pinned for use by the hardware. Swapping the PTEs should not result
in externally visible behaviour, as each PTE update should be atomic and
the two pages identical. (danvet)

safe-by-default, or the principle of least surprise. We need a new flag
to mark objects that we can wilfully discard and recreate across
hibernation. (danvet)

Just use the global_list rather than invent a new stolen_list. This is
the slowpath hibernate and so adding a new list and the associated
complexity isn't worth it.

v3: Rebased on drm-intel-nightly (Ankit)

v4: Use insert_page to map stolen memory backed pages for migration to
shmem (Chris)

v5: Acquire mutex lock while copying stolen buffer objects to shmem (Chris)

v6: Handled file leak, Splitted object migration function, added kerneldoc
for migrate_stolen_to_shmemfs() function (Tvrtko)
Use i915 wrapper function for drm_mm_insert_node_in_range()

v7: Keep the object in cpu domain after get_pages, remove the object from
the unbound list only when marked PURGED, Corrected split of object migration
function (Chris)

v8: Split i915_gem_freeze(), removed redundant use of barrier, corrected
use of set_to_cpu_domain() (Chris)

v9: Replaced WARN_ON by BUG_ON and added a comment explaining it
(Daniel/Tvrtko)

v10: Document use of barriers (Chris)

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.c |  17 ++-
 drivers/gpu/drm/i915/i915_drv.h |  10 ++
 drivers/gpu/drm/i915/i915_gem.c | 198 ++--
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  49 
 drivers/gpu/drm/i915/intel_display.c|   3 +
 drivers/gpu/drm/i915/intel_fbdev.c  |   6 +
 drivers/gpu/drm/i915/intel_pm.c |   2 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |   6 +
 8 files changed, 279 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 11d8414..cfa44af 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -996,6 +996,21 @@ static int i915_pm_suspend(struct device *dev)
return i915_drm_suspend(drm_dev);
 }
 
+static int i915_pm_freeze(struct device *dev)
+{
+   int ret;
+
+   ret = i915_gem_freeze(pci_get_drvdata(to_pci_dev(dev)));
+   if (ret)
+   return ret;
+
+   ret = i915_pm_suspend(dev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
 static int i915_pm_suspend_late(struct device *dev)
 {
struct drm_device *drm_dev = dev_to_i915(dev)->dev;
@@ -1643,7 +1658,7 @@ static const struct dev_pm_ops i915_pm_ops = {
 * @restore, @restore_early : called after rebooting and restoring the
 *hibernation image [PMSG_RESTORE]
 */
-   .freeze = i915_pm_suspend,
+   .freeze = i915_pm_freeze,
.freeze_late = i915_pm_suspend_late,
.thaw_early = i915_pm_resume_early,
.thaw = i915_pm_resume,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 943b301..16f2f94 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2137,6 +2137,12 @@ struct drm_i915_gem_object {
 * Advice: are the backing pages purgeable?
 */
unsigned int madv:2;
+   /**
+* Whereas madv is for userspace, there are certain situations
+* where we want I915_MADV_DONTNEED behaviour on internal objects
+* without conflating the userspace setting.
+*/
+   unsigned int internal_volatile:1;
 
/**
 * Current tiling mode for the object.
@@ -3093,6 +3099,9 @@ int i915_gem_l3_remap(struct drm_i915_gem_request *req, 
int slice);
 void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 int __must_check i915_gpu_idle(struct drm_device *dev);
+int __must_check i915_gem_freeze(struct drm_device *dev);
+int __must_check
+i915_gem_object_migrate_stol

[Intel-gfx] [PATCH 01/10] drm/i915: Add support for mapping an object page by page

[ankitprasad . r . sharma]

From: Chris Wilson 

Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.

v2: Added low level rpm assertions to insert_page routines (Chris)

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
---
 drivers/char/agp/intel-gtt.c|  9 +
 drivers/gpu/drm/i915/i915_gem_gtt.c | 65 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +++
 include/drm/intel-gtt.h |  3 ++
 4 files changed, 82 insertions(+)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 1341a94..7c68576 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -838,6 +838,15 @@ static bool i830_check_flags(unsigned int flags)
return false;
 }
 
+void intel_gtt_insert_page(dma_addr_t addr,
+  unsigned int pg,
+  unsigned int flags)
+{
+   intel_private.driver->write_entry(addr, pg, flags);
+   wmb();
+}
+EXPORT_SYMBOL(intel_gtt_insert_page);
+
 void intel_gtt_insert_sg_entries(struct sg_table *st,
 unsigned int pg_start,
 unsigned int flags)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 715a771..a64018f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2341,6 +2341,28 @@ static void gen8_set_pte(void __iomem *addr, gen8_pte_t 
pte)
 #endif
 }
 
+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen8_pte_t __iomem *pte =
+   (gen8_pte_t __iomem *)dev_priv->gtt.gsm +
+   (offset >> PAGE_SHIFT);
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
+   wmb();
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 uint64_t start,
@@ -2412,6 +2434,28 @@ static void gen8_ggtt_insert_entries__BKL(struct 
i915_address_space *vm,
stop_machine(gen8_ggtt_insert_entries__cb, &arg, NULL);
 }
 
+static void gen6_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level level,
+ u32 flags)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   gen6_pte_t __iomem *pte =
+   (gen6_pte_t __iomem *)dev_priv->gtt.gsm +
+   (offset >> PAGE_SHIFT);
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   iowrite32(vm->pte_encode(addr, level, true, flags), pte);
+   wmb();
+
+   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 /*
  * Binds an object into the global gtt with the specified cache level. The 
object
  * will be accessible to the GPU via commands whose operands reference offsets
@@ -2523,6 +2567,24 @@ static void gen6_ggtt_clear_range(struct 
i915_address_space *vm,
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
+static void i915_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ uint64_t offset,
+ enum i915_cache_level cache_level,
+ u32 unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
+   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
+   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
+   int rpm_atomic_seq;
+
+   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
+
+   intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
+
+   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
+}
+
 static void i915_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *pages,
 uint64_t start,
@@ -3054,6 +3116,7 @@ static int gen8_gmch_probe(struct drm_device *dev,
ret = ggtt_probe_common(dev, gtt_size);
 
dev_priv->gtt.base.clear_range = gen8_ggtt_clear_range;
+   dev_priv->gtt.base.insert_page = gen8_ggtt_insert_page;
d