Re: [Intel-gfx] [PATCH v2] drm/i915: Catch non-existent registers in find_fw_domain

[Joonas Lahtinen]

On ke, 2016-12-07 at 18:28 +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 06:18:02PM +, Tvrtko Ursulin wrote:
> > 
> > Only slight issues I can spot is that for some platforms, should it
> > trigger, it would trigger twice since
> > intel_uncore_forcewake_for_read/write functions have the same WARN.
> 
> I don't think that's too much of an issue whilst both are WARN() - we
> are likely to get a flood of hits if we get any.

Yep, and they have slightly differing calling paths. Merged the patch,
thanks for the review.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC i-g-t v3 5/5] Add support for hotplug testing with the Chamelium

[Tomeu Vizoso]

On 7 December 2016 at 20:56, Lyude Paul  wrote:
> On Wed, 2016-12-07 at 12:27 +0100, Tomeu Vizoso wrote:
>> On 1 December 2016 at 02:24, Lyude  wrote:

(big snip)

>> > + * By default, this file is expected to exist in
>> > ~/.igt_chamelium_rc . The
>> > + * directory for this can be overriden by setting the environment
>> > variable
>> > + * %CHAMELIUM_CONFIG_PATH.
>>
>> It would be a pity if in time we need to add configuration parameters
>> for other aspects of IGT and we have to choose between renaming this
>> file, or having two configuration files for the same project. Why not
>> call it just .igt_rc?
> Nice catch. While I'm at it I'll add a patch to expose a function or
> two to get a global GKeyFile that's shared across tests that need
> configurations. As well I'll make sure connector groups are prefixed
> with something such as "Chamelium:" since we'll be sharing things.

Sounds great.

>> > +/**
>> > + * chamelium_async_hpd_pulse_finish:
>> > + *
>> > + * Waits for any asynchronous RPC started by
>> > #chamelium_async_hpd_pulse_start
>> > + * to complete, and then cleans up any leftover responses from the
>> > chamelium.
>> > + * If all of the RPC calls have already completed, this function
>> > returns
>> > + * immediately.
>>
>> This makes me wonder if it wouldn't have been better to go with
>> libsoup, as it uses a real event loop that we may need to use in
>> tests
>> for other reasons.
>
> Fwiw, I wouldn't worry about this part too much. The only reason we we
> use async calls here is so that we can use the mixed pulses RPC to get
> the chamelium to send delayed hotplug events by using the pulse width
> as the delay. I wouldn't think there would be any situations where the
> chamelium would fail to send a hotplug, since all that part requires is
> just asserting the hpd line. It could fail if the IO board stopped
> responding, but in that case everything else is going to fail too and
> we won't get the hotplug event we're expecting anyway.
>
> This is just my opinion though, if you can think of some use cases that
> this could seriously cause some issues I'll be happy to change it.

Fair enough. When this issue came up first, I tried to think of any
use cases in which having a proper event loop would be important, but
I wasn't able to back then and I still cannot think of anything, so
I'm fine with things as they are. Also, as you have the code
structured, it would be quite easy to switch to libsoup if needed in
the future.

>> > +   /* Sleep so we don't accidentally cause an hpd
>> > storm */
>> > +   sleep(1);
>>
>> Wouldn't such a long sleep unnecessarily slow test runs down?
> Yes, but I don't see much of a way around it right now. Eventually I'd
> like to add something to i915's debugfs to allow disabling HPD storm
> detection (we'll need this as well if we want to eventually add HPD
> storm detection tests).

That's cool, but I was thinking that the sleep duration could be shorter.

>> > +
>> > +static void
>> > +test_display(data_t *data, struct chamelium_port *port)
>> > +{
>> > +   igt_display_t display;
>> > +   igt_output_t *output;
>> > +   igt_plane_t *primary;
>> > +   struct igt_fb fb;
>> > +   drmModeRes *res;
>> > +   drmModeModeInfo *mode;
>> > +   drmModeConnector *connector;
>> > +   uint32_t crtc_id;
>> > +   int fb_id;
>> > +
>> > +   reset_state(data, port);
>> > +
>> > +   chamelium_plug(port->id);
>> > +   wait_for_connector(data, port, DRM_MODE_CONNECTED);
>> > +   igt_assert(res = drmModeGetResources(data->drm_fd));
>> > +   kmstest_unset_all_crtcs(data->drm_fd, res);
>> > +
>> > +   igt_display_init(, data->drm_fd);
>> > +
>> > +   /* Find the output struct for this connector */
>> > +   for_each_connected_output(, output) {
>> > +   if (output->config.connector->connector_id ==
>> > +   port->connector_id)
>> > +   break;
>>
>> Are we that sure that we'll always find such an output? Could be
>> quite
>> disconcerting if that stopped being true, even if by a bug.
> Not sure I follow here: that's what the wait_for_connector() call is
> there for. I'd expect that we could make the assumption we'll find a
> connector if we've managed to make it that far without failing.

My concern was rather that, as code evolve, that assumption could
become false and the bug would manifest in a disconcerting way. So I
would just assert that the connector that we got after the loop is
really the one we expected.

Thanks,

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: split off Pineview desktop and mobile device info

[Saarinen, Jani]

> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915: split off Pineview desktop and
> mobile device info
> URL   : https://patchwork.freedesktop.org/series/16511/
> State : warning
> 
> == Summary ==
> 
> Series 16511v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/16511/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-6770hq)
Still around: https://bugs.freedesktop.org/show_bug.cgi?id=97929

> 
> fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28
> fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52
> fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41
> fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41
> fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45
> fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33
> fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33
> fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66
> fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34
> fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35
> fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35
> fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27
> fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33
> fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34
> fi-skl-6770hqtotal:247  pass:219  dwarn:1   dfail:0   fail:0   skip:27
> fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45
> fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46
> 
> ffcd96e45b3b3e4ca57d4879405d02b7b1b58946 drm-tip: 2016y-12m-07d-21h-
> 45m-40s UTC integration manifest 9750e7f drm/i915: reduce PCI ID duplication
> in IS_IRONLAKE_M()
> bb0d903 drm/i915: split off Pineview desktop and mobile device info
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3229/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

Re: [Intel-gfx] [PATCH] drm/i915: Parse panel BL controller from VBT

[Mika Kahola]

Tested-by: Mika Kahola 

On Wed, 2016-12-07 at 20:32 +0530, Vidya Srinivas wrote:
> Currently the backlight controller is taken as 0. It needs to derive
> value from the VBT. Adding the necessary changes.
> 
> v2: Updated the commit header
> 
> Signed-off-by: Uma Shankar 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/i915_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_bios.c  | 5 +
>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 8daa4fb..6a85fdf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1633,6 +1633,7 @@ struct intel_vbt_data {
>   bool present;
>   bool active_low_pwm;
>   u8 min_brightness;  /* min_brightness/255 of
> max */
> + u8 controller;  /* brightness
> controller number */
>   enum intel_backlight_type type;
>   } backlight;
>  
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index eaade27..130db0f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -330,6 +330,8 @@ static u32 get_blocksize(const void *block_data)
>  
>   method = _data-
> >backlight_control[panel_type];
>   dev_priv->vbt.backlight.type = method->type;
> + dev_priv->vbt.backlight.controller = 0;
> + dev_priv->vbt.backlight.controller = method-
> >controller;
>   }
>  
>   dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> @@ -341,6 +343,9 @@ static u32 get_blocksize(const void *block_data)
>     dev_priv->vbt.backlight.active_low_pwm ? "low"
> : "high",
>     dev_priv->vbt.backlight.min_brightness,
>     backlight_data->level[panel_type]);
> +
> + DRM_DEBUG_KMS("VBT BL controller %u\n",
> + dev_priv->vbt.backlight.controller);
>  }
>  
>  /* Try to find sdvo panel data */
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 3578b40..6a7d4c3 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1612,7 +1612,7 @@ static int vlv_setup_backlight(struct
> intel_connector *connector, enum pipe pipe
>    * For BXT hard coding the Backlight controller to 0.
>    * TODO : Read the controller value from VBT and generalize
>    */
> - panel->backlight.controller = 0;
> + panel->backlight.controller = dev_priv-
> >vbt.backlight.controller;
>  
>   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel-
> >backlight.controller));
>  
-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH] drm/i915: Do not reset detect_done flag in intel_dp_detect

[Manasi Navare]

Ville,
You mentioned that this detect_done should be set to false also
in the resume case so in i915_display_resume where it calls
intel_hpd_init that eventually schedules the hpd_poll_init_work and
calls drm_helper_hpd_irq_event() which then calls .detect().
So in this case if I have to reset this detect_done in the
hpd_poll_init_work, how do I make sure I do it only if the
connector is DP?

Manasi 

On Wed, Dec 07, 2016 at 04:05:56PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 06, 2016 at 04:43:51PM -0800, Manasi Navare wrote:
> > The detect_done flag was introduced in the commit
> > 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c in order to avoid
> > multiple detects on hotplug where intel_dp_long_pulse()
> > was called from HPD handler as well as in intel_dp_detect.
> > So this detect_done flag was required to make sure intel_dp_detect()
> > did not call long pulse handler again if it was already been called
> > from HPD handler. However commit 1015811609c0328b5ed670d07748591b837e74eb
> > differs the long hpd handling entirely until the hotplug work runs to
> > avoid the double long hpd handling the "detect_done" flag is trying
> > to prevent.
> 
> That sentence doesn't parse here. Anyways, the flag indeed is now a nop
> and your patch is pretty much the same what I did here:
> https://patchwork.freedesktop.org/patch/101476/
> 
> > 
> > So now we do not need to reset the detect_done flag to false in
> > intel_dp_detect. It will be reset in the intel_dp_hpd_pulse so
> > that intel_dp_detect does a full detect. However if the .detect
> > gets called during mode enumeration then we do not need to do a
> > full detect. This patch avoids the WARNS_ONS during connected boot
> > case when it calls intel_dp_check_link_status() due to multiple
> > detects
> 
> How exactly does it do that? Also we shouldn't sweep that under the rug
> anyway. Instead someone should actually fix the problem that causes the
> WARN.
> 
> > and also avoids DP compliance failures. It avoids doing
> > a full detect every single time on .detect().
> > 
> > Cc: Ville Syrjala 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index db75bb9..9c9277e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4470,8 +4470,6 @@ static bool intel_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> > if (!intel_dp->detect_done)
> > status = intel_dp_long_pulse(intel_dp->attached_connector);
> >  
> > -   intel_dp->detect_done = false;
> > -
> > return status;
> >  }
> >  
> > -- 
> > 1.9.1
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

[Daniel Vetter]

On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote:
> This is still missing corresponding documentation changes, and I haven't
> moved anything to drm_print.h yet, as suggested.
> 
> Sending out with a few functional improvements first to get agreement
> before documenting anything (changes summarised in v2: section below)
> 
> In particular, affecting the output format, I stole an idea from Tvrtko
> Ursulin to have the prefix for messages be based on the driver name,
> such as "[i915]" instead of always being "[drm]".
> 
> Depending on peoples thoughts on compatibility, we could consider
> removing the prefix given that the dynamic debug control interface has a
> way of specifying that messages should include a module name, function
> or line info like:
> 
> echo "module i915 +mfp" > dynamic_debug/control
> 
> That would enable all i915 debug messages with a module and function
> prefix.
> 
> A trade-off would be that anyone only using the drm.drm_debug interface
> to control messages would loose some information. If we really wanted we
> could have the best of both by adding a utility printing api that can
> recognise when printing due to a dynamic debug control query vs
> drm.drm_debug to conditionally add the prefix.
> 
> --- >8 --- (git am --scissors)
> 
> Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt)
> allow fine grained control over which debug messages are enabled with
> runtime control through /sysfs/kernel/debug/dynamic_debug/control
> 
> This provides more control than the current drm.drm_debug parameter
> which for some use cases is impractical to use given how chatty
> some drm debug categories are.
> 
> For example all debug messages in i915_drm.c can be enabled with:
> echo "file i915_perf.c +p" > dynamic_debug/control
> 
> This doesn't strictly maintain format compatibility with the previous
> debug messages since the category is now added as part of the prefix
> like "[drm][kms] No FB found". Adding the categories with a consistent
> format makes it possible to enable categories with a dynamic debug
> query like: echo "format [kms] +p" > dynamic_debug/control
> 
> This maintains support for enabling debug messages using the drm_debug
> parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the
> debug messages essentially work as before, except with the inclusion of
> categories in the format strings as described above.
> 
> This removes the drm_[dev_]printk wrappers considering that the dynamic
> debug macros are only useful if they can track the __FILE__, __func__
> and __LINE__ where they are called. The wrapper didn't seem necessary in
> the DRM_UT_NONE case with no category flag.
> 
> The non _DEV macros are no longer defined in terms of passing NULL to a
> _DEV variant to avoid have the core.c dev_printk implementation adding
> "(NULL device *)". The previous drm_[dev_]prink function used to handle
> this as a special case.
> 
> Instead of using DRM_NAME to add [drm] to the start of every message,
> the prefix is now based on module_name(THIS_MODULE) so it will be [drm]
> or e.g. [i915] for the Intel driver. Later we might consider removing
> the prefix altogether considering that the dynamic debug control
> interface has a way of optionally adding the module, function or line to
> the formatting of messages.
> 
> v2:
> Add categories to format like "[drm][kms] No FB found"
> Only single conditional call per message (macros expand to less code)
> Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features
> Use module name for msg prefix like [drm] or [i915]
> 
> Signed-off-by: Robert Bragg 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Daniel Vetter 
> Cc: Tvrtko Ursulin 

So assuming I understand it correctly - I like this 3way cascade of
dynamic debug, then printk and no_printk fallback if CONFIG_DEBUG=n for
the space concious. But I guess we do need to add a DRM Kconfig knob to
set DEBUG, at least I'm not entirely sure how that's supposed to work. Or
we might need to have our own #ifdef maze for this. Maybe we need to keep
the old drm*printk stuff for that?

Anyway, I still think this is pretty cool, if we can get some common
ground with Tvrtko's stuff and some acks and reviews then I can pull it
in.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c |  47 ---
>  include/drm/drmP.h| 202 
> +-
>  2 files changed, 127 insertions(+), 122 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index f74b7d0..25d00aa 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -65,53 +65,6 @@ static struct idr drm_minors_idr;
>  
>  static struct dentry *drm_debugfs_root;
>  
> -#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> -
> -void drm_dev_printk(const struct device *dev, const char *level,
> - unsigned int category, const char 

[Intel-gfx] [PATCH i-g-t] igt_kms: Remove support for drivers with <1 drm_plane

[Lyude]

We've had support for universal planes since kernel version 3.15, so
there's not really a good reason to try supporting drivers that lack
plane support now. As well, the current has_universal_planes logic is
broken anyway as it makes the assumption that having display planes
always means we have both a primary plane and a cursor plane (this isn't
true on radeon/amdgpu and nouveau).

So, remove this, and just check for whether or not we have a cursor
plane.

Signed-off-by: Lyude 
---
 lib/igt_kms.c | 29 ++---
 lib/igt_kms.h |  2 +-
 tests/kms_crtc_background_color.c |  2 --
 tests/kms_plane_scaling.c |  1 -
 tests/kms_rotation_crc.c  | 25 +
 tests/kms_universal_plane.c   |  5 +
 6 files changed, 25 insertions(+), 39 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82bb41d..0e7b8e8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1407,7 +1407,6 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane = >planes[IGT_PLANE_PRIMARY];
plane->is_primary = 1;
plane->index = IGT_PLANE_PRIMARY;
-   display->has_universal_planes = 1;
break;
case DRM_PLANE_TYPE_CURSOR:
/*
@@ -1420,7 +1419,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane = >planes[IGT_PLANE_CURSOR];
plane->is_cursor = 1;
plane->index = IGT_PLANE_CURSOR;
-   display->has_universal_planes = 1;
+   display->has_cursor_plane = true;
break;
default:
plane = >planes[p];
@@ -1445,35 +1444,27 @@ void igt_display_init(igt_display_t *display, int 
drm_fd)
plane->rotation = (igt_rotation_t)prop_value;
}
 
-   if (display->has_universal_planes) {
-   /*
-* If we have universal planes, we should have both
-* primary and cursor planes setup now.
-*/
-   igt_assert(pipe->planes[IGT_PLANE_PRIMARY].drm_plane &&
-  pipe->planes[IGT_PLANE_CURSOR].drm_plane);
+   /*
+* At the bare minimum, we should expect to have a primary
+* plane
+*/
+   igt_assert(pipe->planes[IGT_PLANE_PRIMARY].drm_plane);
 
+   if (display->has_cursor_plane) {
/*
 * Cursor was put in the last slot.  If we have 0 or
 * only 1 sprite, that's the wrong slot and we need to
 * move it down.
 */
if (p != IGT_PLANE_CURSOR) {
-   pipe->planes[p] = 
pipe->planes[IGT_PLANE_CURSOR];
+   pipe->planes[p] =
+   pipe->planes[IGT_PLANE_CURSOR];
pipe->planes[p].index = p;
memset(>planes[IGT_PLANE_CURSOR], 0,
   sizeof *plane);
}
} else {
-   /*
-* No universal plane support.  Add drm_plane-less
-* primary and cursor planes.
-*/
-   plane = >planes[IGT_PLANE_PRIMARY];
-   plane->pipe = pipe;
-   plane->index = IGT_PLANE_PRIMARY;
-   plane->is_primary = true;
-
+   /* Add drm_plane-less cursor */
plane = >planes[p];
plane->pipe = pipe;
plane->index = p;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 6422adc..0dcb325 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -311,7 +311,7 @@ struct igt_display {
unsigned long pipes_in_use;
igt_output_t *outputs;
igt_pipe_t pipes[I915_MAX_PIPES];
-   bool has_universal_planes;
+   bool has_cursor_plane;
bool is_atomic;
 };
 
diff --git a/tests/kms_crtc_background_color.c 
b/tests/kms_crtc_background_color.c
index b97c114..537d4ce 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -131,8 +131,6 @@ static void test_crtc_background(data_t *data)
enum pipe pipe;
int valid_tests = 0;
 
-   igt_require(data->display.has_universal_planes);
-
for_each_pipe_with_valid_output(display, pipe, output) {
igt_plane_t *plane;
 
diff --git 

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Kill the 830 MI_OVERLAY_OFF workaround

[kbuild test robot]

Hi Ville,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20161207]
[cannot apply to v4.9-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/ville-syrjala-linux-intel-com/drm-i915-Overlay-fixes/20161208-060045
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s0-12080653 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/intel_overlay.c: In function 'intel_overlay_off':
>> drivers/gpu/drm/i915/intel_overlay.c:409: error: unused variable 'dev_priv'

vim +/dev_priv +409 drivers/gpu/drm/i915/intel_overlay.c

18cb592b Ville Syrjälä 2016-12-07  403  
i830_overlay_clock_gating(dev_priv, true);
02e792fb Daniel Vetter 2009-09-15  404  }
02e792fb Daniel Vetter 2009-09-15  405  
02e792fb Daniel Vetter 2009-09-15  406  /* overlay needs to be disabled in OCMD 
reg */
ce453d81 Chris Wilson  2011-02-21  407  static int intel_overlay_off(struct 
intel_overlay *overlay)
02e792fb Daniel Vetter 2009-09-15  408  {
1ee8da6d Chris Wilson  2016-05-12 @409  struct drm_i915_private 
*dev_priv = overlay->i915;
dad540ce John Harrison 2015-05-29  410  struct drm_i915_gem_request 
*req;
7e37f889 Chris Wilson  2016-08-02  411  struct intel_ring *ring;
8dc5d147 Chris Wilson  2010-08-12  412  u32 flip_addr = 
overlay->flip_addr;

:: The code at line 409 was first introduced by commit
:: 1ee8da6df17dc481948aa2d04005e87bc7d387a4 drm/i915: Convert 
intel_overlay.c to use native drm_i915_private pointers

:: TO: Chris Wilson <ch...@chris-wilson.co.uk>
:: CC: Chris Wilson <ch...@chris-wilson.co.uk>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: split off Pineview desktop and mobile device info

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: split off Pineview desktop and 
mobile device info
URL   : https://patchwork.freedesktop.org/series/16511/
State : warning

== Summary ==

Series 16511v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16511/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:219  dwarn:1   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

ffcd96e45b3b3e4ca57d4879405d02b7b1b58946 drm-tip: 2016y-12m-07d-21h-45m-40s UTC 
integration manifest
9750e7f drm/i915: reduce PCI ID duplication in IS_IRONLAKE_M()
bb0d903 drm/i915: split off Pineview desktop and mobile device info

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3229/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Take ownership of the dmabuf->obj when exporting

[Patchwork]

== Series Details ==

Series: drm: Take ownership of the dmabuf->obj when exporting
URL   : https://patchwork.freedesktop.org/series/16509/
State : success

== Summary ==

Series 16509v1 drm: Take ownership of the dmabuf->obj when exporting
https://patchwork.freedesktop.org/api/1.0/series/16509/revisions/1/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

ffcd96e45b3b3e4ca57d4879405d02b7b1b58946 drm-tip: 2016y-12m-07d-21h-45m-40s UTC 
integration manifest
e64145e4 drm: Take ownership of the dmabuf->obj when exporting

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3228/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Calculate common rates and max lane count in Long pulse handler

[Manasi Navare]

On Thu, Dec 08, 2016 at 12:04:21AM +0200, Jani Nikula wrote:
> On Wed, 07 Dec 2016, Manasi Navare  wrote:
> > Hi Jani,
> >
> > Actually this patch is no longer valid, I have included a differnt interface
> > change with the link training patch series for calculating the 
> > max_sink_link_rate
> > and max_sink_lane_count in the long pulse handler and not recompute
> > it everytime when the caller needs common_rates and lane_count. These max 
> > values
> > will be used in the computation of common_rates when caller requests it and
> > same for lane count.
> >
> > Could you please review the latest patch:
> 
> I'm really not amused by the firehose rate of permutations of the
> patches. I've literally lost count how many versions and variations I've
> reviewed. *sigh*.
> 
> If you repeatedly ping me on the mailing list and IRC to review, and
> specifically say you'll rebase the other stuff on this one, then please
> *also* specifically say if you don't pursue a patch anymore.
> 
> Jani.
>

Sorry about that Jani. I moved it to become part of the link training patch 
series
instead because of the feedback I received from Daniel on IRC and I just 
assumed that you
must have seen it. But I will specifically call it out next time,
So now could you review the patch as mentioned below?

Regards
Manasi
 
> >
> > https://patchwork.freedesktop.org/patch/125744/
> >
> > Also this simplifies the fallback logic on link train
> > failure since I can update the max sink link rate and max sink lane count
> > to match the fallback values thus lowering the max capabilities advertised
> > by the sink.
> >
> > Manasi
> >
> > On Wed, Dec 07, 2016 at 11:25:29PM +0200, Jani Nikula wrote:
> >> On Fri, 02 Dec 2016, Manasi Navare  wrote:
> >> > Supported link rate common to source and sink as well as the
> >> > maximum supported lane count based on source and sink capabilities should
> >> > be set only once on hotplug and then used anytime they are requested.
> >> > This patch creates and array of common rates and max lane count as the
> >> > intel_dp member. It gets calculated only once in the long pulse handler
> >> > and then gets used when requested in compute_config and other functions.
> >> >
> >> > Cc: Jani Nikula 
> >> > Cc: Daniel Vetter 
> >> > Cc: Ville Syrjala 
> >> > Signed-off-by: Manasi Navare 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
> >> > --
> >> >  drivers/gpu/drm/i915/intel_drv.h |  5 +
> >> >  2 files changed, 21 insertions(+), 22 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> > b/drivers/gpu/drm/i915/intel_dp.c
> >> > index 9dfbde4..de37807 100644
> >> > --- a/drivers/gpu/drm/i915/intel_dp.c
> >> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> > @@ -274,8 +274,7 @@ static int intersect_rates(const int *source_rates, 
> >> > int source_len,
> >> >  return k;
> >> >  }
> >> >  
> >> > -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> >> > - int *common_rates)
> >> > +static int intel_dp_common_rates(struct intel_dp *intel_dp)
> >> 
> >> This here is a bad interface change. After this, you can only use the
> >> function to update intel_dp->common_rates. However, this doesn't finish
> >> the job, and leaves it up to the caller to set intel_dp->common_len. The
> >> sole remaining call site of intel_dp_common_rates() should set the alarm
> >> bells ringing.
> >> 
> >> Please keep it as a helper, passing in common_rates. There's follow-up
> >> work to be done on top, but we can leave that for later.
> >> 
> >> >  {
> >> >  const int *source_rates, *sink_rates;
> >> >  int source_len, sink_len;
> >> > @@ -285,7 +284,7 @@ static int intel_dp_common_rates(struct intel_dp 
> >> > *intel_dp,
> >> >  
> >> >  return intersect_rates(source_rates, source_len,
> >> > sink_rates, sink_len,
> >> > -   common_rates);
> >> > +   intel_dp->common_rates);
> >> >  }
> >> >  
> >> >  static enum drm_mode_status
> >> > @@ -312,7 +311,7 @@ static int intel_dp_common_rates(struct intel_dp 
> >> > *intel_dp,
> >> >  }
> >> >  
> >> >  max_link_clock = intel_dp_max_link_rate(intel_dp);
> >> > -max_lanes = intel_dp_max_lane_count(intel_dp);
> >> > +max_lanes = intel_dp->max_lane_count;
> >> >  
> >> >  max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> >> >  mode_rate = intel_dp_link_required(target_clock, 18);
> >> > @@ -1430,8 +1429,7 @@ static void snprintf_int_array(char *str, size_t 
> >> > len,
> >> >  static void intel_dp_print_rates(struct intel_dp *intel_dp)
> >> >  {
> >> >  const int *source_rates, *sink_rates;
> >> > -int source_len, sink_len, 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: More documentation hooked to i915.rst (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: More documentation hooked to i915.rst (rev3)
URL   : https://patchwork.freedesktop.org/series/16114/
State : success

== Summary ==

Series 16114v3 drm/i915/perf: More documentation hooked to i915.rst
https://patchwork.freedesktop.org/api/1.0/series/16114/revisions/3/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

ffcd96e45b3b3e4ca57d4879405d02b7b1b58946 drm-tip: 2016y-12m-07d-21h-45m-40s UTC 
integration manifest
d7cb56d drm/i915/perf: More documentation hooked to i915.rst

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3227/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info

[Jani Nikula]

On Thu, 08 Dec 2016, Jani Nikula  wrote:
> This lets us use IS_MOBILE() for distinguishing the desktop and mobile
> parts instead of duplicating PCI IDs in Pineview specific checks.

This probably needs more thorough review of the !IS_MOBILE() paths in
parts not touched by this patch.

For example this one in i915_gem_detect_bit_6_swizzle() which was pretty
weird already before the Pineview device info patches:

} else if (IS_MOBILE(dev_priv) ||
   (IS_GEN3(dev_priv) &&
!IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv))) {

BR,
Jani.


>
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  arch/x86/kernel/early-quirks.c  |  3 ++-
>  drivers/gpu/drm/i915/i915_drv.h |  2 --
>  drivers/gpu/drm/i915/i915_pci.c | 12 ++--
>  drivers/gpu/drm/i915/intel_pm.c |  4 ++--
>  include/drm/i915_pciids.h   |  6 --
>  5 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 6a08e25a48d8..34af418d88cc 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -508,7 +508,8 @@ static const struct pci_device_id intel_early_ids[] 
> __initconst = {
>   INTEL_I945G_IDS(_early_ops),
>   INTEL_I945GM_IDS(_early_ops),
>   INTEL_VLV_IDS(_early_ops),
> - INTEL_PINEVIEW_IDS(_early_ops),
> + INTEL_PINEVIEW_D_IDS(_early_ops),
> + INTEL_PINEVIEW_M_IDS(_early_ops),
>   INTEL_I965G_IDS(_early_ops),
>   INTEL_G33_IDS(_early_ops),
>   INTEL_I965GM_IDS(_early_ops),
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1480e733312a..ee1726b28b82 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2616,8 +2616,6 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define IS_G45(dev_priv) ((dev_priv)->info.platform == INTEL_G45)
>  #define IS_GM45(dev_priv)((dev_priv)->info.platform == INTEL_GM45)
>  #define IS_G4X(dev_priv) (IS_G45(dev_priv) || IS_GM45(dev_priv))
> -#define IS_PINEVIEW_G(dev_priv)  (INTEL_DEVID(dev_priv) == 0xa001)
> -#define IS_PINEVIEW_M(dev_priv)  (INTEL_DEVID(dev_priv) == 0xa011)
>  #define IS_PINEVIEW(dev_priv)((dev_priv)->info.platform == 
> INTEL_PINEVIEW)
>  #define IS_G33(dev_priv) ((dev_priv)->info.platform == INTEL_G33)
>  #define IS_IRONLAKE_M(dev_priv)  (INTEL_DEVID(dev_priv) == 0x0046)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 93f50ef2a309..451113f79499 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -139,7 +139,14 @@ static const struct intel_device_info intel_g33_info = {
>   .has_overlay = 1,
>  };
>  
> -static const struct intel_device_info intel_pineview_info = {
> +static const struct intel_device_info intel_pineview_d_info = {
> + GEN3_FEATURES,
> + .platform = INTEL_PINEVIEW,
> + .has_hotplug = 1,
> + .has_overlay = 1,
> +};
> +
> +static const struct intel_device_info intel_pineview_m_info = {
>   GEN3_FEATURES,
>   .platform = INTEL_PINEVIEW, .is_mobile = 1,
>   .has_hotplug = 1,
> @@ -444,7 +451,8 @@ static const struct pci_device_id pciidlist[] = {
>   INTEL_I965GM_IDS(_i965gm_info),
>   INTEL_GM45_IDS(_gm45_info),
>   INTEL_G45_IDS(_g45_info),
> - INTEL_PINEVIEW_IDS(_pineview_info),
> + INTEL_PINEVIEW_D_IDS(_pineview_d_info),
> + INTEL_PINEVIEW_M_IDS(_pineview_m_info),
>   INTEL_IRONLAKE_D_IDS(_ironlake_d_info),
>   INTEL_IRONLAKE_M_IDS(_ironlake_m_info),
>   INTEL_SNB_D_IDS(_sandybridge_d_info),
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9171431558a3..afe07947e51c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -659,7 +659,7 @@ static void pineview_update_wm(struct intel_crtc 
> *unused_crtc)
>   u32 reg;
>   unsigned long wm;
>  
> - latency = intel_get_cxsr_latency(IS_PINEVIEW_G(dev_priv),
> + latency = intel_get_cxsr_latency(!IS_MOBILE(dev_priv),
>dev_priv->is_ddr3,
>dev_priv->fsb_freq,
>dev_priv->mem_freq);
> @@ -7730,7 +7730,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
>   vlv_setup_wm_latency(dev_priv);
>   dev_priv->display.update_wm = vlv_update_wm;
>   } else if (IS_PINEVIEW(dev_priv)) {
> - if (!intel_get_cxsr_latency(IS_PINEVIEW_G(dev_priv),
> + if (!intel_get_cxsr_latency(!IS_MOBILE(dev_priv),
>   dev_priv->is_ddr3,
>   dev_priv->fsb_freq,
>   dev_priv->mem_freq)) {
> diff --git a/include/drm/i915_pciids.h 

[Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info

[Jani Nikula]

This lets us use IS_MOBILE() for distinguishing the desktop and mobile
parts instead of duplicating PCI IDs in Pineview specific checks.

Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 arch/x86/kernel/early-quirks.c  |  3 ++-
 drivers/gpu/drm/i915/i915_drv.h |  2 --
 drivers/gpu/drm/i915/i915_pci.c | 12 ++--
 drivers/gpu/drm/i915/intel_pm.c |  4 ++--
 include/drm/i915_pciids.h   |  6 --
 5 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 6a08e25a48d8..34af418d88cc 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -508,7 +508,8 @@ static const struct pci_device_id intel_early_ids[] 
__initconst = {
INTEL_I945G_IDS(_early_ops),
INTEL_I945GM_IDS(_early_ops),
INTEL_VLV_IDS(_early_ops),
-   INTEL_PINEVIEW_IDS(_early_ops),
+   INTEL_PINEVIEW_D_IDS(_early_ops),
+   INTEL_PINEVIEW_M_IDS(_early_ops),
INTEL_I965G_IDS(_early_ops),
INTEL_G33_IDS(_early_ops),
INTEL_I965GM_IDS(_early_ops),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1480e733312a..ee1726b28b82 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2616,8 +2616,6 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define IS_G45(dev_priv)   ((dev_priv)->info.platform == INTEL_G45)
 #define IS_GM45(dev_priv)  ((dev_priv)->info.platform == INTEL_GM45)
 #define IS_G4X(dev_priv)   (IS_G45(dev_priv) || IS_GM45(dev_priv))
-#define IS_PINEVIEW_G(dev_priv)(INTEL_DEVID(dev_priv) == 0xa001)
-#define IS_PINEVIEW_M(dev_priv)(INTEL_DEVID(dev_priv) == 0xa011)
 #define IS_PINEVIEW(dev_priv)  ((dev_priv)->info.platform == INTEL_PINEVIEW)
 #define IS_G33(dev_priv)   ((dev_priv)->info.platform == INTEL_G33)
 #define IS_IRONLAKE_M(dev_priv)(INTEL_DEVID(dev_priv) == 0x0046)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 93f50ef2a309..451113f79499 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -139,7 +139,14 @@ static const struct intel_device_info intel_g33_info = {
.has_overlay = 1,
 };
 
-static const struct intel_device_info intel_pineview_info = {
+static const struct intel_device_info intel_pineview_d_info = {
+   GEN3_FEATURES,
+   .platform = INTEL_PINEVIEW,
+   .has_hotplug = 1,
+   .has_overlay = 1,
+};
+
+static const struct intel_device_info intel_pineview_m_info = {
GEN3_FEATURES,
.platform = INTEL_PINEVIEW, .is_mobile = 1,
.has_hotplug = 1,
@@ -444,7 +451,8 @@ static const struct pci_device_id pciidlist[] = {
INTEL_I965GM_IDS(_i965gm_info),
INTEL_GM45_IDS(_gm45_info),
INTEL_G45_IDS(_g45_info),
-   INTEL_PINEVIEW_IDS(_pineview_info),
+   INTEL_PINEVIEW_D_IDS(_pineview_d_info),
+   INTEL_PINEVIEW_M_IDS(_pineview_m_info),
INTEL_IRONLAKE_D_IDS(_ironlake_d_info),
INTEL_IRONLAKE_M_IDS(_ironlake_m_info),
INTEL_SNB_D_IDS(_sandybridge_d_info),
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9171431558a3..afe07947e51c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -659,7 +659,7 @@ static void pineview_update_wm(struct intel_crtc 
*unused_crtc)
u32 reg;
unsigned long wm;
 
-   latency = intel_get_cxsr_latency(IS_PINEVIEW_G(dev_priv),
+   latency = intel_get_cxsr_latency(!IS_MOBILE(dev_priv),
 dev_priv->is_ddr3,
 dev_priv->fsb_freq,
 dev_priv->mem_freq);
@@ -7730,7 +7730,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
vlv_setup_wm_latency(dev_priv);
dev_priv->display.update_wm = vlv_update_wm;
} else if (IS_PINEVIEW(dev_priv)) {
-   if (!intel_get_cxsr_latency(IS_PINEVIEW_G(dev_priv),
+   if (!intel_get_cxsr_latency(!IS_MOBILE(dev_priv),
dev_priv->is_ddr3,
dev_priv->fsb_freq,
dev_priv->mem_freq)) {
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 540be9ff0346..9c226eb1788f 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -100,8 +100,10 @@
INTEL_VGA_DEVICE(0x2e42, info), /* B43_G */ \
INTEL_VGA_DEVICE(0x2e92, info)  /* B43_G.1 */
 
-#define INTEL_PINEVIEW_IDS(info)   \
-   INTEL_VGA_DEVICE(0xa001, info), \
+#define INTEL_PINEVIEW_D_IDS(info) \
+   INTEL_VGA_DEVICE(0xa001, info)
+
+#define INTEL_PINEVIEW_M_IDS(info) \
INTEL_VGA_DEVICE(0xa011, info)
 
 #define INTEL_IRONLAKE_D_IDS(info) \
-- 
2.1.4

[Intel-gfx] [PATCH 2/2] drm/i915: reduce PCI ID duplication in IS_IRONLAKE_M()

[Jani Nikula]

Reduce PCI ID duplication by replacing direct PCI ID check with
INTEL_IRONLAKE && IS_MOBILE() check.

It's slightly less optimal, but clarity and single point of truth win.

Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ee1726b28b82..a15161007109 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2618,7 +2618,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define IS_G4X(dev_priv)   (IS_G45(dev_priv) || IS_GM45(dev_priv))
 #define IS_PINEVIEW(dev_priv)  ((dev_priv)->info.platform == INTEL_PINEVIEW)
 #define IS_G33(dev_priv)   ((dev_priv)->info.platform == INTEL_G33)
-#define IS_IRONLAKE_M(dev_priv)(INTEL_DEVID(dev_priv) == 0x0046)
+#define IS_IRONLAKE_M(dev_priv)((dev_priv)->info.platform == 
INTEL_IRONLAKE && \
+IS_MOBILE(dev_priv))
 #define IS_IVYBRIDGE(dev_priv) ((dev_priv)->info.platform == INTEL_IVYBRIDGE)
 #define IS_IVB_GT1(dev_priv)   (INTEL_DEVID(dev_priv) == 0x0156 || \
 INTEL_DEVID(dev_priv) == 0x0152 || \
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: distinguish G33 and Pineview from each other

[Jani Nikula]

On Wed, 07 Dec 2016, Ville Syrjälä  wrote:
> A lot of the checks involving g33 are apparently quite ugly. Might be
> nice to clean some of those up into a more readable form. But the
> patch looks correct so, and it looks like the rest of the IS_G33 checks
> already deal with PNV separately.

Agreed. But this is the required first step.

> I do wonder a bit about the IS_PINEVIEW_G and IS_PINEVIEW_M. I wonder if
> we should/could convert that to .is_mobile=true/false? Right now we seem
> to set .is_mobile=true for both.

Patches follow.

In the mean time, this one pushed, thanks for the review.

BR,
Jani.


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

Re: [Intel-gfx] [PATCH] drm/i915: Calculate common rates and max lane count in Long pulse handler

[Jani Nikula]

On Wed, 07 Dec 2016, Manasi Navare  wrote:
> Hi Jani,
>
> Actually this patch is no longer valid, I have included a differnt interface
> change with the link training patch series for calculating the 
> max_sink_link_rate
> and max_sink_lane_count in the long pulse handler and not recompute
> it everytime when the caller needs common_rates and lane_count. These max 
> values
> will be used in the computation of common_rates when caller requests it and
> same for lane count.
>
> Could you please review the latest patch:

I'm really not amused by the firehose rate of permutations of the
patches. I've literally lost count how many versions and variations I've
reviewed. *sigh*.

If you repeatedly ping me on the mailing list and IRC to review, and
specifically say you'll rebase the other stuff on this one, then please
*also* specifically say if you don't pursue a patch anymore.

Jani.

>
> https://patchwork.freedesktop.org/patch/125744/
>
> Also this simplifies the fallback logic on link train
> failure since I can update the max sink link rate and max sink lane count
> to match the fallback values thus lowering the max capabilities advertised
> by the sink.
>
> Manasi
>
> On Wed, Dec 07, 2016 at 11:25:29PM +0200, Jani Nikula wrote:
>> On Fri, 02 Dec 2016, Manasi Navare  wrote:
>> > Supported link rate common to source and sink as well as the
>> > maximum supported lane count based on source and sink capabilities should
>> > be set only once on hotplug and then used anytime they are requested.
>> > This patch creates and array of common rates and max lane count as the
>> > intel_dp member. It gets calculated only once in the long pulse handler
>> > and then gets used when requested in compute_config and other functions.
>> >
>> > Cc: Jani Nikula 
>> > Cc: Daniel Vetter 
>> > Cc: Ville Syrjala 
>> > Signed-off-by: Manasi Navare 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
>> > --
>> >  drivers/gpu/drm/i915/intel_drv.h |  5 +
>> >  2 files changed, 21 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> > b/drivers/gpu/drm/i915/intel_dp.c
>> > index 9dfbde4..de37807 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > @@ -274,8 +274,7 @@ static int intersect_rates(const int *source_rates, 
>> > int source_len,
>> >return k;
>> >  }
>> >  
>> > -static int intel_dp_common_rates(struct intel_dp *intel_dp,
>> > -   int *common_rates)
>> > +static int intel_dp_common_rates(struct intel_dp *intel_dp)
>> 
>> This here is a bad interface change. After this, you can only use the
>> function to update intel_dp->common_rates. However, this doesn't finish
>> the job, and leaves it up to the caller to set intel_dp->common_len. The
>> sole remaining call site of intel_dp_common_rates() should set the alarm
>> bells ringing.
>> 
>> Please keep it as a helper, passing in common_rates. There's follow-up
>> work to be done on top, but we can leave that for later.
>> 
>> >  {
>> >const int *source_rates, *sink_rates;
>> >int source_len, sink_len;
>> > @@ -285,7 +284,7 @@ static int intel_dp_common_rates(struct intel_dp 
>> > *intel_dp,
>> >  
>> >return intersect_rates(source_rates, source_len,
>> >   sink_rates, sink_len,
>> > - common_rates);
>> > + intel_dp->common_rates);
>> >  }
>> >  
>> >  static enum drm_mode_status
>> > @@ -312,7 +311,7 @@ static int intel_dp_common_rates(struct intel_dp 
>> > *intel_dp,
>> >}
>> >  
>> >max_link_clock = intel_dp_max_link_rate(intel_dp);
>> > -  max_lanes = intel_dp_max_lane_count(intel_dp);
>> > +  max_lanes = intel_dp->max_lane_count;
>> >  
>> >max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
>> >mode_rate = intel_dp_link_required(target_clock, 18);
>> > @@ -1430,8 +1429,7 @@ static void snprintf_int_array(char *str, size_t len,
>> >  static void intel_dp_print_rates(struct intel_dp *intel_dp)
>> >  {
>> >const int *source_rates, *sink_rates;
>> > -  int source_len, sink_len, common_len;
>> > -  int common_rates[DP_MAX_SUPPORTED_RATES];
>> > +  int source_len, sink_len;
>> >char str[128]; /* FIXME: too big for stack? */
>> >  
>> >if ((drm_debug & DRM_UT_KMS) == 0)
>> > @@ -1445,8 +1443,8 @@ static void intel_dp_print_rates(struct intel_dp 
>> > *intel_dp)
>> >snprintf_int_array(str, sizeof(str), sink_rates, sink_len);
>> >DRM_DEBUG_KMS("sink rates: %s\n", str);
>> >  
>> > -  common_len = intel_dp_common_rates(intel_dp, common_rates);
>> > -  snprintf_int_array(str, sizeof(str), common_rates, common_len);
>> > +  snprintf_int_array(str, sizeof(str), intel_dp->common_rates,
>> > + intel_dp->common_len);
>> >

[Intel-gfx] [PATCH v2 i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

[Manasi Navare]

This is the userspace component of the Displayport Compliance
testing software required for compliance testing of the I915
Display Port driver. This must be running in order to successfully
complete Display Port compliance testing. This app and the kernel
code that accompanies it has been written to satify the requirements
of the Displayport Link CTS 1.2 rev1.1 specification from VESA.
Note that this application does not support eDP compliance testing.
This utility has an automation support for the Link training tests
(4.3.1.1. - 4.3.2.3), EDID tests (4.2.2.3
- 4.2.2.6) and Video Pattern generation tests (4.3.3.1) from CTS
specification 1.2 Rev 1.1.

This tool has the support for responding to the hotplug uevents
sent by compliance testting unit after each test.

The Linux DUT running this utility must be in text (console) mode
and cannot have any other display manager running. Since this uses
sysfs nodes for kernel interaction, this utility should be run as
Root. Once this user application is up and running, waiting for
test requests, the test appliance software on the windows host
can now be used to execute the compliance tests.

This app is based on some prior work done in April 2015 (by
Todd Previte )

v2:
* Add mode unset on hotplug uevent on disconnect (Manasi Navare)

Cc: Petri Latvala 
Cc: Marius Vlad 
Cc: Daniel Vetter 
Signed-off-by: Manasi Navare 
---
 tools/Makefile.am   |3 +-
 tools/Makefile.sources  |7 +
 tools/intel_dp_compliance.c | 1060 +++
 tools/intel_dp_compliance.h |   35 ++
 tools/intel_dp_compliance_hotplug.c |  123 
 5 files changed, 1227 insertions(+), 1 deletion(-)
 create mode 100644 tools/intel_dp_compliance.c
 create mode 100644 tools/intel_dp_compliance.h
 create mode 100644 tools/intel_dp_compliance_hotplug.c

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 18f86f6..eac6d64 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -13,7 +13,7 @@ AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib
 AM_CFLAGS = $(DEBUG_CFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) \
$(CAIRO_CFLAGS) $(LIBUNWIND_CFLAGS) -DPKGDATADIR=\"$(pkgdatadir)\" \
$(WERROR_CFLAGS)
-LDADD = $(top_builddir)/lib/libintel_tools.la
+LDADD = $(top_builddir)/lib/libintel_tools.la $(GLIB_LIBS)
 AM_LDFLAGS = -Wl,--as-needed
 
 
@@ -24,6 +24,7 @@ moduledir = $(libdir)
 intel_aubdump_la_LDFLAGS = -module -avoid-version -no-undefined
 intel_aubdump_la_SOURCES = aubdump.c
 intel_aubdump_la_LIBADD = $(top_builddir)/lib/libintel_tools.la -ldl
+intel_dp_compliance_la_LIBADD = $(LDADD)
 
 bin_SCRIPTS = intel_aubdump
 CLEANFILES = $(bin_SCRIPTS)
diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index be58871..09c0667 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -13,6 +13,7 @@ tools_prog_lists =\
intel_bios_reader   \
intel_display_crc   \
intel_display_poller\
+   intel_dp_compliance \
intel_forcewaked\
intel_gpu_frequency \
intel_firmware_decode   \
@@ -55,3 +56,9 @@ intel_l3_parity_SOURCES = \
intel_l3_parity.h   \
intel_l3_udev_listener.c
 
+intel_dp_compliance_SOURCES = \
+intel_dp_compliance.c \
+intel_dp_compliance.h \
+intel_dp_compliance_hotplug.c \
+$(NULL)
+
diff --git a/tools/intel_dp_compliance.c b/tools/intel_dp_compliance.c
new file mode 100644
index 000..807d3f4
--- /dev/null
+++ b/tools/intel_dp_compliance.c
@@ -0,0 +1,1060 @@
+/*
+ * Copyright ? 2014-2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * 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.
+ *
+ * Displayport Compliance Testing Application
+ *
+ * This is the userspace component of the 

[Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting

[Chris Wilson]

Currently the reference for the dmabuf->obj is incremented for the
dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace
interface), but is released in drm_gem_dmabuf_release() (the lowlevel
handler). Improve the symmetry of the dmabuf->obj ownership by acquiring
the reference in drm_gem_dmabuf_export(). This makes it easier to use
the prime functions directly.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_prime.c   | 9 +
 drivers/gpu/drm/vgem/vgem_fence.c | 1 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index b22a94dd7b53..5ef946d5a32d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -300,8 +300,11 @@ struct dma_buf *drm_gem_dmabuf_export(struct drm_device 
*dev,
struct dma_buf *dma_buf;
 
dma_buf = dma_buf_export(exp_info);
-   if (!IS_ERR(dma_buf))
-   drm_dev_ref(dev);
+   if (IS_ERR(dma_buf))
+   return dma_buf;
+
+   drm_dev_ref(dev);
+   drm_gem_object_reference(exp_info->priv);
 
return dma_buf;
 }
@@ -472,8 +475,6 @@ static struct dma_buf *export_and_register_object(struct 
drm_device *dev,
 */
obj->dma_buf = dmabuf;
get_dma_buf(obj->dma_buf);
-   /* Grab a new ref since the callers is now used by the dma-buf */
-   drm_gem_object_reference(obj);
 
return dmabuf;
 }
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index 9cb00a5d5d08..da25dfe7b80e 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -126,7 +126,6 @@ static int attach_dmabuf(struct drm_device *dev,
return PTR_ERR(dmabuf);
 
obj->dma_buf = dmabuf;
-   drm_gem_object_reference(obj);
return 0;
 }
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Calculate common rates and max lane count in Long pulse handler

[Manasi Navare]

Hi Jani,

Actually this patch is no longer valid, I have included a differnt interface
change with the link training patch series for calculating the 
max_sink_link_rate
and max_sink_lane_count in the long pulse handler and not recompute
it everytime when the caller needs common_rates and lane_count. These max values
will be used in the computation of common_rates when caller requests it and
same for lane count.

Could you please review the latest patch:

https://patchwork.freedesktop.org/patch/125744/

Also this simplifies the fallback logic on link train
failure since I can update the max sink link rate and max sink lane count
to match the fallback values thus lowering the max capabilities advertised
by the sink.

Manasi

On Wed, Dec 07, 2016 at 11:25:29PM +0200, Jani Nikula wrote:
> On Fri, 02 Dec 2016, Manasi Navare  wrote:
> > Supported link rate common to source and sink as well as the
> > maximum supported lane count based on source and sink capabilities should
> > be set only once on hotplug and then used anytime they are requested.
> > This patch creates and array of common rates and max lane count as the
> > intel_dp member. It gets calculated only once in the long pulse handler
> > and then gets used when requested in compute_config and other functions.
> >
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 38 
> > --
> >  drivers/gpu/drm/i915/intel_drv.h |  5 +
> >  2 files changed, 21 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 9dfbde4..de37807 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -274,8 +274,7 @@ static int intersect_rates(const int *source_rates, int 
> > source_len,
> > return k;
> >  }
> >  
> > -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > -int *common_rates)
> > +static int intel_dp_common_rates(struct intel_dp *intel_dp)
> 
> This here is a bad interface change. After this, you can only use the
> function to update intel_dp->common_rates. However, this doesn't finish
> the job, and leaves it up to the caller to set intel_dp->common_len. The
> sole remaining call site of intel_dp_common_rates() should set the alarm
> bells ringing.
> 
> Please keep it as a helper, passing in common_rates. There's follow-up
> work to be done on top, but we can leave that for later.
> 
> >  {
> > const int *source_rates, *sink_rates;
> > int source_len, sink_len;
> > @@ -285,7 +284,7 @@ static int intel_dp_common_rates(struct intel_dp 
> > *intel_dp,
> >  
> > return intersect_rates(source_rates, source_len,
> >sink_rates, sink_len,
> > -  common_rates);
> > +  intel_dp->common_rates);
> >  }
> >  
> >  static enum drm_mode_status
> > @@ -312,7 +311,7 @@ static int intel_dp_common_rates(struct intel_dp 
> > *intel_dp,
> > }
> >  
> > max_link_clock = intel_dp_max_link_rate(intel_dp);
> > -   max_lanes = intel_dp_max_lane_count(intel_dp);
> > +   max_lanes = intel_dp->max_lane_count;
> >  
> > max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
> > mode_rate = intel_dp_link_required(target_clock, 18);
> > @@ -1430,8 +1429,7 @@ static void snprintf_int_array(char *str, size_t len,
> >  static void intel_dp_print_rates(struct intel_dp *intel_dp)
> >  {
> > const int *source_rates, *sink_rates;
> > -   int source_len, sink_len, common_len;
> > -   int common_rates[DP_MAX_SUPPORTED_RATES];
> > +   int source_len, sink_len;
> > char str[128]; /* FIXME: too big for stack? */
> >  
> > if ((drm_debug & DRM_UT_KMS) == 0)
> > @@ -1445,8 +1443,8 @@ static void intel_dp_print_rates(struct intel_dp 
> > *intel_dp)
> > snprintf_int_array(str, sizeof(str), sink_rates, sink_len);
> > DRM_DEBUG_KMS("sink rates: %s\n", str);
> >  
> > -   common_len = intel_dp_common_rates(intel_dp, common_rates);
> > -   snprintf_int_array(str, sizeof(str), common_rates, common_len);
> > +   snprintf_int_array(str, sizeof(str), intel_dp->common_rates,
> > +  intel_dp->common_len);
> > DRM_DEBUG_KMS("common rates: %s\n", str);
> >  }
> >  
> > @@ -1495,14 +1493,12 @@ static int rate_to_index(int find, const int *rates)
> >  int
> >  intel_dp_max_link_rate(struct intel_dp *intel_dp)
> >  {
> > -   int rates[DP_MAX_SUPPORTED_RATES] = {};
> > -   int len;
> > +   int len = intel_dp->common_len;
> >  
> > -   len = intel_dp_common_rates(intel_dp, rates);
> > if (WARN_ON(len <= 0))
> > return 162000;
> >  
> > -   return rates[len - 1];
> > +   return intel_dp->common_rates[len - 1];
> >  }
> >  
> >  int 

[Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst

[Robert Bragg]

This adds a 'Perf' section to i915.rst with the following sub sections:
- Overview
- Comparison with Core Perf
- i915 Driver Entry Points
- i915 Perf Stream
- i915 Perf Observation Architecture Stream
- All i915 Perf Internals

v2:
section headers in i915.rst (Daniel Vetter)
missing symbol docs + other fixups (Matthew Auld)

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
Cc: Daniel Vetter 
---
 Documentation/gpu/i915.rst   |  91 +
 drivers/gpu/drm/i915/i915_drv.h  | 151 +++---
 drivers/gpu/drm/i915/i915_perf.c | 412 ---
 3 files changed, 598 insertions(+), 56 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 117d2ab..3843ef6 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -356,4 +356,95 @@ switch_mm
 .. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
:doc: switch_mm tracepoint
 
+Perf
+
+
+Overview
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :doc: i915 Perf Overview
+
+Comparison with Core Perf
+-
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :doc: i915 Perf History and Comparison with Core Perf
+
+i915 Driver Entry Points
+
+
+This section covers the entrypoints exported outside of i915_perf.c to
+integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl.
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_init
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_fini
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_register
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_unregister
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_open_ioctl
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_release
+
+i915 Perf Stream
+
+
+This section covers the stream-semantics-agnostic structures and functions
+for representing an i915 perf stream FD and associated file operations.
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h
+   :functions: i915_perf_stream
+.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h
+   :functions: i915_perf_stream_ops
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: read_properties_unlocked
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_open_ioctl_locked
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_destroy_locked
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_read
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_ioctl
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_enable_locked
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_disable_locked
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_poll
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_perf_poll_locked
+
+i915 Perf Observation Architecture Stream
+-
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h
+   :functions: i915_oa_ops
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_oa_stream_init
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_oa_read
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_oa_stream_enable
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_oa_stream_disable
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_oa_wait_unlocked
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :functions: i915_oa_poll_wait
+
+All i915 Perf Internals
+---
+
+This section simply includes all currently documented i915 perf internals, in
+no particular order, but may include some more minor utilities or platform
+specific details than found in the more high-level sections.
+
+.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
+   :internal:
+
 .. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/drm/i915/i915_irq.c
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 33758ac..49c7651 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1847,89 +1847,186 @@ struct i915_oa_reg {
 
 struct i915_perf_stream;
 
+/**
+ * struct i915_perf_stream_ops - the OPs to support a specific stream type
+ */
 struct i915_perf_stream_ops {
-   /* Enables the collection of HW samples, either in response to
-* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
-* opened without I915_PERF_FLAG_DISABLED.
+   /**
+* @enable: Enables the collection of HW samples, either in response to
+* `I915_PERF_IOCTL_ENABLE` or implicitly called when stream is opened
+* without 

Re: [Intel-gfx] [PATCH] drm/i915: Calculate common rates and max lane count in Long pulse handler

[Jani Nikula]

On Fri, 02 Dec 2016, Manasi Navare  wrote:
> Supported link rate common to source and sink as well as the
> maximum supported lane count based on source and sink capabilities should
> be set only once on hotplug and then used anytime they are requested.
> This patch creates and array of common rates and max lane count as the
> intel_dp member. It gets calculated only once in the long pulse handler
> and then gets used when requested in compute_config and other functions.
>
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 38 --
>  drivers/gpu/drm/i915/intel_drv.h |  5 +
>  2 files changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9dfbde4..de37807 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -274,8 +274,7 @@ static int intersect_rates(const int *source_rates, int 
> source_len,
>   return k;
>  }
>  
> -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> -  int *common_rates)
> +static int intel_dp_common_rates(struct intel_dp *intel_dp)

This here is a bad interface change. After this, you can only use the
function to update intel_dp->common_rates. However, this doesn't finish
the job, and leaves it up to the caller to set intel_dp->common_len. The
sole remaining call site of intel_dp_common_rates() should set the alarm
bells ringing.

Please keep it as a helper, passing in common_rates. There's follow-up
work to be done on top, but we can leave that for later.

>  {
>   const int *source_rates, *sink_rates;
>   int source_len, sink_len;
> @@ -285,7 +284,7 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>  
>   return intersect_rates(source_rates, source_len,
>  sink_rates, sink_len,
> -common_rates);
> +intel_dp->common_rates);
>  }
>  
>  static enum drm_mode_status
> @@ -312,7 +311,7 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>   }
>  
>   max_link_clock = intel_dp_max_link_rate(intel_dp);
> - max_lanes = intel_dp_max_lane_count(intel_dp);
> + max_lanes = intel_dp->max_lane_count;
>  
>   max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
>   mode_rate = intel_dp_link_required(target_clock, 18);
> @@ -1430,8 +1429,7 @@ static void snprintf_int_array(char *str, size_t len,
>  static void intel_dp_print_rates(struct intel_dp *intel_dp)
>  {
>   const int *source_rates, *sink_rates;
> - int source_len, sink_len, common_len;
> - int common_rates[DP_MAX_SUPPORTED_RATES];
> + int source_len, sink_len;
>   char str[128]; /* FIXME: too big for stack? */
>  
>   if ((drm_debug & DRM_UT_KMS) == 0)
> @@ -1445,8 +1443,8 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>   snprintf_int_array(str, sizeof(str), sink_rates, sink_len);
>   DRM_DEBUG_KMS("sink rates: %s\n", str);
>  
> - common_len = intel_dp_common_rates(intel_dp, common_rates);
> - snprintf_int_array(str, sizeof(str), common_rates, common_len);
> + snprintf_int_array(str, sizeof(str), intel_dp->common_rates,
> +intel_dp->common_len);
>   DRM_DEBUG_KMS("common rates: %s\n", str);
>  }
>  
> @@ -1495,14 +1493,12 @@ static int rate_to_index(int find, const int *rates)
>  int
>  intel_dp_max_link_rate(struct intel_dp *intel_dp)
>  {
> - int rates[DP_MAX_SUPPORTED_RATES] = {};
> - int len;
> + int len = intel_dp->common_len;
>  
> - len = intel_dp_common_rates(intel_dp, rates);
>   if (WARN_ON(len <= 0))
>   return 162000;
>  
> - return rates[len - 1];
> + return intel_dp->common_rates[len - 1];
>  }
>  
>  int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
> @@ -1550,22 +1546,18 @@ static int intel_dp_compute_bpp(struct intel_dp 
> *intel_dp,
>   struct intel_connector *intel_connector = intel_dp->attached_connector;
>   int lane_count, clock;
>   int min_lane_count = 1;
> - int max_lane_count = intel_dp_max_lane_count(intel_dp);
> + int max_lane_count = intel_dp->max_lane_count;
>   /* Conveniently, the link BW constants become indices with a shift...*/
>   int min_clock = 0;
>   int max_clock;
>   int bpp, mode_rate;
>   int link_avail, link_clock;
> - int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> - int common_len;
>   uint8_t link_bw, rate_select;
>  
> - common_len = intel_dp_common_rates(intel_dp, common_rates);
> -
>   /* No common link rates between source and sink */
> - WARN_ON(common_len <= 0);
> + WARN_ON(intel_dp->common_len <= 0);

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: distinguish G33 and Pineview from each other

[Patchwork]

== Series Details ==

Series: drm/i915: distinguish G33 and Pineview from each other
URL   : https://patchwork.freedesktop.org/series/16506/
State : warning

== Summary ==

Series 16506v1 drm/i915: distinguish G33 and Pineview from each other
https://patchwork.freedesktop.org/api/1.0/series/16506/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:219  dwarn:1   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

e46c97f4cfb63328f5bbbc0fb85c3f53703792f2 drm-tip: 2016y-12m-07d-17h-47m-18s UTC 
integration manifest
39342ea drm/i915: distinguish G33 and Pineview from each other

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3226/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: distinguish G33 and Pineview from each other

[Ville Syrjälä]

On Wed, Dec 07, 2016 at 10:48:09PM +0200, Jani Nikula wrote:
> Pineview deserves to use its own platform enum (which was already added,
> unused, previously). IS_G33() no longer matches Pineview, and gets
> replaced by IS_G33() || IS_PINEVIEW() or equivalent. Pineview is no
> longer an outlier among platform definitions.
> 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   | 3 +--
>  drivers/gpu/drm/i915/i915_gem.c   | 8 +---
>  drivers/gpu/drm/i915/i915_gem_fence_reg.c | 5 +++--
>  drivers/gpu/drm/i915/i915_gem_stolen.c| 4 ++--
>  drivers/gpu/drm/i915/i915_pci.c   | 2 +-
>  drivers/gpu/drm/i915/intel_display.c  | 5 +++--
>  drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
>  drivers/gpu/drm/i915/intel_uncore.c   | 2 +-
>  8 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 33758ac5ec9a..969a59345fb2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -688,7 +688,6 @@ struct intel_csr {
>  
>  #define DEV_INFO_FOR_EACH_FLAG(func) \
>   func(is_mobile); \
> - func(is_pineview); \
>   func(is_lp); \
>   func(is_alpha_support); \
>   /* Keep has_* in alphabetical order */ \
> @@ -2533,7 +2532,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define IS_G4X(dev_priv) (IS_G45(dev_priv) || IS_GM45(dev_priv))
>  #define IS_PINEVIEW_G(dev_priv)  (INTEL_DEVID(dev_priv) == 0xa001)
>  #define IS_PINEVIEW_M(dev_priv)  (INTEL_DEVID(dev_priv) == 0xa011)
> -#define IS_PINEVIEW(dev_priv)((dev_priv)->info.is_pineview)
> +#define IS_PINEVIEW(dev_priv)((dev_priv)->info.platform == 
> INTEL_PINEVIEW)
>  #define IS_G33(dev_priv) ((dev_priv)->info.platform == INTEL_G33)
>  #define IS_IRONLAKE_M(dev_priv)  (INTEL_DEVID(dev_priv) == 0x0046)
>  #define IS_IVYBRIDGE(dev_priv)   ((dev_priv)->info.platform == 
> INTEL_IVYBRIDGE)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dd1a34ac830f..36183945e61a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2084,7 +2084,8 @@ u64 i915_gem_get_ggtt_alignment(struct drm_i915_private 
> *dev_priv, u64 size,
>* Minimum alignment is 4k (GTT page size), but might be greater
>* if a fence register is needed for the object.
>*/
> - if (INTEL_GEN(dev_priv) >= 4 || (!fenced && IS_G33(dev_priv)) ||
> + if (INTEL_GEN(dev_priv) >= 4 ||
> + (!fenced && (IS_G33(dev_priv) || IS_PINEVIEW(dev_priv))) ||
>   tiling_mode == I915_TILING_NONE)
>   return 4096;
>  
> @@ -4498,8 +4499,9 @@ i915_gem_load_init_fences(struct drm_i915_private 
> *dev_priv)
>   if (INTEL_INFO(dev_priv)->gen >= 7 && !IS_VALLEYVIEW(dev_priv) &&
>   !IS_CHERRYVIEW(dev_priv))
>   dev_priv->num_fence_regs = 32;
> - else if (INTEL_INFO(dev_priv)->gen >= 4 || IS_I945G(dev_priv) ||
> -  IS_I945GM(dev_priv) || IS_G33(dev_priv))
> + else if (INTEL_INFO(dev_priv)->gen >= 4 ||
> +  IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
> +  IS_G33(dev_priv) || IS_PINEVIEW(dev_priv))
>   dev_priv->num_fence_regs = 16;
>   else
>   dev_priv->num_fence_regs = 8;
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
> b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> index d006bcb69e91..09193cfb5d8b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> @@ -512,8 +512,9 @@ i915_gem_detect_bit_6_swizzle(struct drm_i915_private 
> *dev_priv)
>*/
>   swizzle_x = I915_BIT_6_SWIZZLE_NONE;
>   swizzle_y = I915_BIT_6_SWIZZLE_NONE;
> - } else if (IS_MOBILE(dev_priv) || (IS_GEN3(dev_priv) &&
> -!IS_G33(dev_priv))) {
> + } else if (IS_MOBILE(dev_priv) ||
> +(IS_GEN3(dev_priv) &&
> + !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv))) {
>   uint32_t dcc;
>  
>   /* On 9xx chipsets, channel interleave by the CPU is
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index c81b22f238c3..efc0e748ef89 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -203,8 +203,8 @@ static unsigned long i915_stolen_to_physical(struct 
> drm_i915_private *dev_priv)
>   return 0;
>  
>   /* make sure we don't clobber the GTT if it's within stolen memory */
> - if (INTEL_GEN(dev_priv) <= 4 && !IS_G33(dev_priv) &&
> - !IS_G4X(dev_priv)) {
> + if (INTEL_GEN(dev_priv) <= 4 &&
> + !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv) 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/16] drm/i915: Provide a hook for selftests (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [01/16] drm/i915: Provide a hook for selftests 
(rev2)
URL   : https://patchwork.freedesktop.org/series/16488/
State : success

== Summary ==

Series 16488v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16488/revisions/2/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

e46c97f4cfb63328f5bbbc0fb85c3f53703792f2 drm-tip: 2016y-12m-07d-17h-47m-18s UTC 
integration manifest
6bb976b drm/i915: Provide a hook for selftests

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3225/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: distinguish G33 and Pineview from each other

[Jani Nikula]

Pineview deserves to use its own platform enum (which was already added,
unused, previously). IS_G33() no longer matches Pineview, and gets
replaced by IS_G33() || IS_PINEVIEW() or equivalent. Pineview is no
longer an outlier among platform definitions.

Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h   | 3 +--
 drivers/gpu/drm/i915/i915_gem.c   | 8 +---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 5 +++--
 drivers/gpu/drm/i915/i915_gem_stolen.c| 4 ++--
 drivers/gpu/drm/i915/i915_pci.c   | 2 +-
 drivers/gpu/drm/i915/intel_display.c  | 5 +++--
 drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
 drivers/gpu/drm/i915/intel_uncore.c   | 2 +-
 8 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 33758ac5ec9a..969a59345fb2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -688,7 +688,6 @@ struct intel_csr {
 
 #define DEV_INFO_FOR_EACH_FLAG(func) \
func(is_mobile); \
-   func(is_pineview); \
func(is_lp); \
func(is_alpha_support); \
/* Keep has_* in alphabetical order */ \
@@ -2533,7 +2532,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define IS_G4X(dev_priv)   (IS_G45(dev_priv) || IS_GM45(dev_priv))
 #define IS_PINEVIEW_G(dev_priv)(INTEL_DEVID(dev_priv) == 0xa001)
 #define IS_PINEVIEW_M(dev_priv)(INTEL_DEVID(dev_priv) == 0xa011)
-#define IS_PINEVIEW(dev_priv)  ((dev_priv)->info.is_pineview)
+#define IS_PINEVIEW(dev_priv)  ((dev_priv)->info.platform == INTEL_PINEVIEW)
 #define IS_G33(dev_priv)   ((dev_priv)->info.platform == INTEL_G33)
 #define IS_IRONLAKE_M(dev_priv)(INTEL_DEVID(dev_priv) == 0x0046)
 #define IS_IVYBRIDGE(dev_priv) ((dev_priv)->info.platform == INTEL_IVYBRIDGE)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dd1a34ac830f..36183945e61a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2084,7 +2084,8 @@ u64 i915_gem_get_ggtt_alignment(struct drm_i915_private 
*dev_priv, u64 size,
 * Minimum alignment is 4k (GTT page size), but might be greater
 * if a fence register is needed for the object.
 */
-   if (INTEL_GEN(dev_priv) >= 4 || (!fenced && IS_G33(dev_priv)) ||
+   if (INTEL_GEN(dev_priv) >= 4 ||
+   (!fenced && (IS_G33(dev_priv) || IS_PINEVIEW(dev_priv))) ||
tiling_mode == I915_TILING_NONE)
return 4096;
 
@@ -4498,8 +4499,9 @@ i915_gem_load_init_fences(struct drm_i915_private 
*dev_priv)
if (INTEL_INFO(dev_priv)->gen >= 7 && !IS_VALLEYVIEW(dev_priv) &&
!IS_CHERRYVIEW(dev_priv))
dev_priv->num_fence_regs = 32;
-   else if (INTEL_INFO(dev_priv)->gen >= 4 || IS_I945G(dev_priv) ||
-IS_I945GM(dev_priv) || IS_G33(dev_priv))
+   else if (INTEL_INFO(dev_priv)->gen >= 4 ||
+IS_I945G(dev_priv) || IS_I945GM(dev_priv) ||
+IS_G33(dev_priv) || IS_PINEVIEW(dev_priv))
dev_priv->num_fence_regs = 16;
else
dev_priv->num_fence_regs = 8;
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index d006bcb69e91..09193cfb5d8b 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -512,8 +512,9 @@ i915_gem_detect_bit_6_swizzle(struct drm_i915_private 
*dev_priv)
 */
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
-   } else if (IS_MOBILE(dev_priv) || (IS_GEN3(dev_priv) &&
-  !IS_G33(dev_priv))) {
+   } else if (IS_MOBILE(dev_priv) ||
+  (IS_GEN3(dev_priv) &&
+   !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv))) {
uint32_t dcc;
 
/* On 9xx chipsets, channel interleave by the CPU is
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index c81b22f238c3..efc0e748ef89 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -203,8 +203,8 @@ static unsigned long i915_stolen_to_physical(struct 
drm_i915_private *dev_priv)
return 0;
 
/* make sure we don't clobber the GTT if it's within stolen memory */
-   if (INTEL_GEN(dev_priv) <= 4 && !IS_G33(dev_priv) &&
-   !IS_G4X(dev_priv)) {
+   if (INTEL_GEN(dev_priv) <= 4 &&
+   !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv) && !IS_G4X(dev_priv)) {
struct {
u32 start, end;
} stolen[2] = {
diff --git a/drivers/gpu/drm/i915/i915_pci.c 

Re: [Intel-gfx] [PATCH] drm/i915: Do not reset detect_done flag in intel_dp_detect

[Manasi Navare]

On Wed, Dec 07, 2016 at 04:05:56PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 06, 2016 at 04:43:51PM -0800, Manasi Navare wrote:
> > The detect_done flag was introduced in the commit
> > 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c in order to avoid
> > multiple detects on hotplug where intel_dp_long_pulse()
> > was called from HPD handler as well as in intel_dp_detect.
> > So this detect_done flag was required to make sure intel_dp_detect()
> > did not call long pulse handler again if it was already been called
> > from HPD handler. However commit 1015811609c0328b5ed670d07748591b837e74eb
> > differs the long hpd handling entirely until the hotplug work runs to
> > avoid the double long hpd handling the "detect_done" flag is trying
> > to prevent.
> 
> That sentence doesn't parse here. Anyways, the flag indeed is now a nop
> and your patch is pretty much the same what I did here:
> https://patchwork.freedesktop.org/patch/101476/
>

I looked at this patch and yes it is the same thing except that it keeps
the name of the flag unchanged plus previous patch is too old and wont
apply cleanly unless you rebase it. I will add the reseting of this flag in the
resume case. 
Thoughts?

> > 
> > So now we do not need to reset the detect_done flag to false in
> > intel_dp_detect. It will be reset in the intel_dp_hpd_pulse so
> > that intel_dp_detect does a full detect. However if the .detect
> > gets called during mode enumeration then we do not need to do a
> > full detect. This patch avoids the WARNS_ONS during connected boot
> > case when it calls intel_dp_check_link_status() due to multiple
> > detects
> 
> How exactly does it do that? Also we shouldn't sweep that under the rug
> anyway. Instead someone should actually fix the problem that causes the
> WARN.
>

Actually an additional call to intel_dp_long_pulse from intel_dp_detect()
because we are not resetting the detect_done flag, makes the function
call intel_dp_check_link_status() in the case when intel_dp->lane_count is 
0 and throws the WARN about that. So by resetting the flag we avoid this
unwanted call to intel_dp_long_pulse and that gets rid of the warning.

Manasi
 
> > and also avoids DP compliance failures. It avoids doing
> > a full detect every single time on .detect().
> > 
> > Cc: Ville Syrjala 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index db75bb9..9c9277e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4470,8 +4470,6 @@ static bool intel_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> > if (!intel_dp->detect_done)
> > status = intel_dp_long_pulse(intel_dp->attached_connector);
> >  
> > -   intel_dp->detect_done = false;
> > -
> > return status;
> >  }
> >  
> > -- 
> > 1.9.1
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Overlay fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Overlay fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/16495/
State : success

== Summary ==

Series 16495v3 drm/i915: Overlay fixes
https://patchwork.freedesktop.org/api/1.0/series/16495/revisions/3/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

e46c97f4cfb63328f5bbbc0fb85c3f53703792f2 drm-tip: 2016y-12m-07d-17h-47m-18s UTC 
integration manifest
4166a37 drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff
e2124bf drm/i915: Fix oops in overlay due to frontbuffer trakcing

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3224/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v11 18/21] tests/sw_sync: Add igt_require check for sw_sync feature

[Robert Foss]

Make sure that this test is skipped if the sw_sync feature is missing from
the host system.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3c47fd2d..ac17e447 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -722,6 +722,9 @@ static void test_sync_random_merge(void)
 
 igt_main
 {
+   igt_fixture
+   igt_require_sw_sync();
+
igt_subtest("alloc_timeline")
test_alloc_timeline();
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH igt] intel-ci: Do module loads first + last

[Chris Wilson]

On Wed, Dec 07, 2016 at 09:41:42PM +0200, Jani Nikula wrote:
> On Wed, 07 Dec 2016, Chris Wilson  wrote:
> > Do the module reload test first, so that it has the best chance of
> > succeeding without outside influence (broken driver). And then do it
> > last, so that it has the best chance of catching some missing
> > finalisation (e.g. memleak) over the lifetime of the testing.
> 
> I see your point, and maybe I worry too much, but running stuff with a
> reloaded module is never the normal use case. This makes all the test
> run with a reloaded module.

You can move the reload-inject to the end, but something I would like
for CI to start doing is not allowing i915 to load during the boot. We
miss error messages from that first load that do not appear again later.
:(

That again is an unusual configuration (so we still need
initramfs/builtin checking). Combitorial explosions of combitorial
explosions.

Anyway reload-final really should be the final operation irrespective of
this discussion :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v11 12/21] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

[Robert Foss]

This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 66 +
 1 file changed, 66 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index cad2ee3b..d3ae4b5c 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -231,6 +231,69 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void test_sync_multi_timeline_wait(void)
+{
+   int timeline[3];
+   int in_fence[3];
+   int fence_merge;
+   int active, signaled, ret;
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+   timeline[2] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 5);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 5);
+   in_fence[2] = sw_sync_fence_create(timeline[2], 5);
+
+   fence_merge = sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sync_merge(in_fence[2], fence_merge);
+
+   /* Confirm fence isn't signaled */
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 3, "Fence signaled too early\n");
+
+   ret = sync_wait(fence_merge, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Failure waiting on fence 
until timeout\n");
+
+   sw_sync_timeline_inc(timeline[0], 5);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 2 && signaled == 1,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[1], 5);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 1 && signaled == 2,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[2], 5);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 0 && signaled == 3,
+"Fence did not signal properly\n");
+
+   /* confirm you can successfully wait */
+   ret = sync_wait(fence_merge, 100);
+   igt_assert_f(ret == 0, "Failure waiting on signaled fence\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+   close(timeline[2]);
+}
+
 #define MULTI_CONSUMER_THREADS 8
 #define MULTI_CONSUMER_ITERATIONS (1 << 14)
 static void * test_sync_multi_consumer_thread(void *arg)
@@ -487,6 +550,9 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
 
+   igt_subtest("sync_multi_timeline_wait")
+   test_sync_multi_timeline_wait();
+
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid

[Robert Foss]

Add subtest test_sync_merge_invalid that tests merging invalid fences.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index ac17e447..44ddab78 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -172,6 +172,44 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_merge_invalid(void)
+{
+   int in_fence;
+   int fence_invalid;
+   int fence_merge;
+   int timeline;
+   char tmppath[] = "/tmp/igt-XX";
+   int skip = 0;
+
+   timeline = sw_sync_timeline_create();
+   in_fence = sw_sync_fence_create(timeline, 1);
+
+   fence_invalid = -1;
+   fence_merge = sync_merge(in_fence, fence_invalid);
+   igt_assert_f(fence_merge < 0, "Verify invalid fd (-1) handling");
+
+   fence_invalid = drm_open_driver(DRIVER_ANY);
+   fence_merge = sync_merge(in_fence, fence_invalid);
+   igt_assert_f(fence_merge < 0, "Verify invalid fd (device fd) handling");
+
+   fence_invalid = mkstemp(tmppath);
+   if (fence_invalid == -1) {
+   skip = 1;
+   goto out;
+   }
+   unlink(tmppath);
+   fence_invalid = drm_open_driver(DRIVER_ANY);
+   fence_merge = sync_merge(in_fence, fence_invalid);
+   close(fence_invalid);
+   igt_assert_f(fence_merge < 0, "Verify invalid fd (file fd) handling");
+
+out:
+   close(in_fence);
+   close(fence_merge);
+   close(timeline);
+   igt_require(skip == 0);
+}
+
 static void test_sync_merge(void)
 {
int in_fence[3];
@@ -746,6 +784,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
 
+   igt_subtest("sync_merge_invalid")
+   test_sync_merge_invalid();
+
igt_subtest("sync_merge")
test_sync_merge();
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 21/21] tests/sw_sync: Add subtest test_sync_busy_unixsocket

[Robert Foss]

Add subtest test_sync_busy_fork which increments the timeline in a forked child
process, where the timeline fd has been sent through a UNIX socket.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 453ba5ea..cb8c1f77 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "igt.h"
@@ -172,6 +174,104 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_busy_fork_unixsocket(void)
+{
+   int fence, ret;
+   int timeline;
+   int skip = 0;
+   int sv[2];
+
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sv) != 0) {
+   skip = 1;
+   goto out;
+   }
+
+   switch (fork()) {
+   case 0:
+   {
+   /* Child process */
+   int socket = sv[1];
+   int socket_timeline;
+   struct msghdr msg = {0};
+   struct cmsghdr *cmsg;
+   unsigned char *data;
+   char m_buffer[256];
+   char c_buffer[256];
+   struct iovec io = { .iov_base = m_buffer, .iov_len = 
sizeof(m_buffer) };
+   close(sv[0]);
+
+   msg.msg_iov = 
+   msg.msg_iovlen = 1;
+   msg.msg_control = c_buffer;
+   msg.msg_controllen = sizeof(c_buffer);
+
+   if (recvmsg(socket, , 0) < 0)
+   _Exit(1);
+
+   cmsg = CMSG_FIRSTHDR();
+   data = CMSG_DATA(cmsg);
+   socket_timeline = *((int *) data);
+
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(socket_timeline, 1);
+
+   _Exit(0);
+   break;
+   }
+   case -1:
+   {
+   /* Failed fork */
+   skip = 1;
+   break;
+   }
+   default:
+   {
+   /* Parent process */
+   int socket = sv[0];
+   struct cmsghdr *cmsg;
+   struct iovec io = { .iov_base = (char *)"ABC", .iov_len = 3 };
+   struct msghdr msg = { 0 };
+   char buf[CMSG_SPACE(sizeof(timeline))];
+   memset(buf, '\0', sizeof(buf));
+   close(sv[1]);
+
+   msg.msg_iov = 
+   msg.msg_iovlen = 1;
+   msg.msg_control = buf;
+   msg.msg_controllen = sizeof(buf);
+
+   cmsg = CMSG_FIRSTHDR();
+   cmsg->cmsg_level = SOL_SOCKET;
+   cmsg->cmsg_type = SCM_RIGHTS;
+   cmsg->cmsg_len = CMSG_LEN(sizeof(timeline));
+
+   *((int *) CMSG_DATA(cmsg)) = timeline;
+   msg.msg_controllen = cmsg->cmsg_len;
+
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it 
should not have been signalled yet)\n");
+
+   if (sendmsg(socket, , 0) < 0) {
+   skip = 1;
+   goto out;
+   }
+
+   ret = sync_wait(fence, 2*1000);
+   igt_assert_f(ret == 0, "Fence not signaled (timeline value 1 
fence seqno 1)\n");
+   break;
+   }
+   }
+
+out:
+   close(fence);
+   close(timeline);
+   igt_require(!skip);
+}
+
 static void test_sync_busy_fork(void)
 {
int fence, ret;
@@ -823,6 +923,9 @@ igt_main
igt_subtest("sync_busy_fork")
test_sync_busy_fork();
 
+   igt_subtest("sync_busy_fork_unixsocket")
+   test_sync_busy_fork_unixsocket();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 11/21] tests/sw_sync: Add subtest test_sync_random_merge

[Robert Foss]

This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 73 +
 1 file changed, 73 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index f32dae5a..cad2ee3b 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -394,6 +394,76 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static void test_sync_random_merge(void)
+{
+   int i, size, ret;
+   const int nbr_timeline = 32;
+   const int nbr_merge = 1024;
+   int fence_map[nbr_timeline];
+   int timeline_arr[nbr_timeline];
+   int fence, tmpfence, merged;
+   int timeline, timeline_offset, sync_pt;
+
+   srand(time(NULL));
+
+   for (i = 0; i < nbr_timeline; i++) {
+   timeline_arr[i] = sw_sync_timeline_create();
+   fence_map[i] = -1;
+   }
+
+   sync_pt = rand();
+   fence = sw_sync_fence_create(timeline_arr[0], sync_pt);
+
+   fence_map[0] = sync_pt;
+
+   /* Randomly create syncpoints out of a fixed set of timelines,
+* and merge them together.
+*/
+   for (i = 0; i < nbr_merge; i++) {
+   /* Generate syncpoint. */
+   timeline_offset = rand() % nbr_timeline;
+   timeline = timeline_arr[timeline_offset];
+   sync_pt = rand();
+
+   /* Keep track of the latest sync_pt in each timeline. */
+   if (fence_map[timeline_offset] == -1)
+   fence_map[timeline_offset] = sync_pt;
+   else if (fence_map[timeline_offset] < sync_pt)
+   fence_map[timeline_offset] = sync_pt;
+
+   /* Merge. */
+   tmpfence = sw_sync_fence_create(timeline, sync_pt);
+   merged = sync_merge(tmpfence, fence);
+   close(tmpfence);
+   close(fence);
+   fence = merged;
+   }
+
+   size = 0;
+   for (i = 0; i < nbr_timeline; i++)
+   if (fence_map[i] != -1)
+   size++;
+
+   /* Trigger the merged fence. */
+   for (i = 0; i < nbr_timeline; i++) {
+   if (fence_map[i] != -1) {
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME,
+   "Failure waiting on fence until timeout\n");
+   /* Increment the timeline to the last sync_pt */
+   sw_sync_timeline_inc(timeline_arr[i], fence_map[i]);
+   }
+   }
+
+   /* Check that the fence is triggered. */
+   ret = sync_wait(fence, 1);
+   igt_assert_f(ret == 0, "Failure triggering fence\n");
+
+   close(fence);
+   for (i = 0; i < nbr_timeline; i++)
+   close(timeline_arr[i]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -422,5 +492,8 @@ igt_main
 
igt_subtest("sync_multi_consumer_producer")
test_sync_multi_consumer_producer();
+
+   igt_subtest("sync_random_merge")
+   test_sync_random_merge();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 17/21] lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync support

[Robert Foss]

Add igt_require_sw_sync to provide tests to skip if sw_sync support isn't
available on the host machine.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 lib/sw_sync.c | 14 ++
 lib/sw_sync.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/lib/sw_sync.c b/lib/sw_sync.c
index aa8feefe..276dc795 100644
--- a/lib/sw_sync.c
+++ b/lib/sw_sync.c
@@ -212,3 +212,17 @@ int sync_fence_count_status(int fd, int status)
 
return count;
 }
+
+static bool kernel_has_sw_sync(void)
+{
+   char buf[128];
+
+   igt_ignore_warn(system("/sbin/modprobe -s r sw_sync"));
+
+   return kernel_sw_sync_path(buf, sizeof(buf));
+}
+
+void igt_require_sw_sync(void)
+{
+   igt_require(kernel_has_sw_sync());
+}
diff --git a/lib/sw_sync.h b/lib/sw_sync.h
index cea5a603..82af3378 100644
--- a/lib/sw_sync.h
+++ b/lib/sw_sync.h
@@ -39,6 +39,7 @@ int sync_merge(int fd1, int fd2);
 int sync_wait(int fence, int timeout);
 int sync_fence_count(int fd);
 int sync_fence_count_status(int fd, int status);
+void igt_require_sw_sync(void);
 
 #endif
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 10/21] tests/sw_sync: Add subtest test_sync_multi_consumer_producer

[Robert Foss]

This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 95 ++---
 1 file changed, 90 insertions(+), 5 deletions(-)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 5b6532c2..f32dae5a 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -102,24 +102,28 @@ static void test_sync_busy(void)
 
/* Make sure that fence has not been signaled yet */
ret = sync_wait(fence, 0);
-   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early 
(timeline value 0, fence seqno 5)\n");
+   igt_assert_f(ret == -1 && errno == ETIME,
+   "Fence signaled early (timeline value 0, fence seqno 5)\n");
 
/* Advance timeline from 0 -> 1 */
sw_sync_timeline_inc(timeline, 1);
 
/* Make sure that fence has not been signaled yet */
ret = sync_wait(fence, 0);
-   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early 
(timeline value 1, fence seqno 5)\n");
+   igt_assert_f(ret == -1 && errno == ETIME,
+   "Fence signaled early (timeline value 1, fence seqno 5)\n");
 
/* Advance timeline from 1 -> 5: signaling the fence (seqno 5)*/
sw_sync_timeline_inc(timeline, 4);
ret = sync_wait(fence, 0);
-   igt_assert_f(ret == 0, "Fence not signaled (timeline value 5, fence 
seqno 5)\n");
+   igt_assert_f(ret == 0,
+   "Fence not signaled (timeline value 5, fence seqno 5)\n");
 
/* Go even further, and confirm wait still succeeds */
sw_sync_timeline_inc(timeline, 5);
ret = sync_wait(fence, 0);
-   igt_assert_f(ret == 0, "Fence not signaled (timeline value 10, fence 
seqno 5)\n");
+   igt_assert_f(ret == 0,
+   "Fence not signaled (timeline value 10, fence seqno 5)\n");
 
seqno = 10;
for_each_prime_number(prime, 100) {
@@ -130,7 +134,8 @@ static void test_sync_busy(void)
sw_sync_timeline_inc(timeline, prime);
 
ret = sync_wait(fence_prime, 0);
-   igt_assert_f(ret == 0, "Fence not signaled during test of prime 
timeline increments\n");
+   igt_assert_f(ret == 0,
+   "Fence not signaled during test of prime timeline 
increments\n");
close(fence_prime);
}
 
@@ -312,6 +317,83 @@ static void test_sync_multi_consumer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+#define MULTI_CONSUMER_PRODUCER_THREADS 8
+#define MULTI_CONSUMER_PRODUCER_ITERATIONS (1 << 14)
+static void * test_sync_multi_consumer_producer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int timeline = data->timeline;
+   int ret, i;
+
+   for (i = 0; i < MULTI_CONSUMER_PRODUCER_ITERATIONS; i++) {
+   int next_point = i * MULTI_CONSUMER_PRODUCER_THREADS + 
thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sync_wait(fence, 1000);
+   if (ret == -1)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   (*data->counter)++;
+
+   /* Kick off the next thread. */
+   sw_sync_timeline_inc(timeline, 1);
+
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer_producer(void)
+{
+   data_t data_arr[MULTI_CONSUMER_PRODUCER_THREADS];
+   pthread_t thread_arr[MULTI_CONSUMER_PRODUCER_THREADS];
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   timeline = sw_sync_timeline_create();
+
+   data.counter = 
+   data.timeline = timeline;
+
+   /* Start consumer threads. */
+   for (i = 0; i < MULTI_CONSUMER_PRODUCER_THREADS; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_producer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < MULTI_CONSUMER_PRODUCER_THREADS; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+
+ 

[Intel-gfx] [PATCH i-g-t v11 16/21] tests/sw_sync: Add subtest test_timeline_closed_signaled

[Robert Foss]

Add subtest test_timeline_closed_signaled that verifies that a signaled fence
stays signaled after its timeline has been closed.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 26bdd210..3c47fd2d 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -85,6 +85,21 @@ static void test_timeline_closed(void)
 "Failure waiting on unsignaled fence on closed timeline\n");
 }
 
+static void test_timeline_closed_signaled(void)
+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   sw_sync_timeline_inc(timeline, 1);
+   close(timeline);
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == 0,
+"Failure waiting on signaled fence for closed timeline\n");
+}
+
 static void test_alloc_merge_fence(void)
 {
int in_fence[2];
@@ -719,6 +734,9 @@ igt_main
igt_subtest("timeline_closed")
test_timeline_closed();
 
+   igt_subtest("timeline_closed_signaled")
+   test_timeline_closed_signaled();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 20/21] tests/sw_sync: Add subtest test_sync_busy_fork

[Robert Foss]

Add subtest test_sync_busy_fork which increments the timeline in a forked child
process.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 44ddab78..453ba5ea 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -172,6 +172,42 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_busy_fork(void)
+{
+   int fence, ret;
+   int timeline;
+   int skip = 0;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   switch (fork()) {
+   case 0:
+   /* Child process */
+   usleep(1*1000*1000);
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(timeline, 1);
+   _Exit(0);
+   break;
+   case -1:
+   /* Failed fork */
+   skip = 1;
+   break;
+   default:
+   /* Parent process */
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it 
should not have been signalled yet)\n");
+
+   ret = sync_wait(fence, 2*1000);
+   igt_assert_f(ret == 0, "Fence not signaled (timeline value 1 
fence seqno 1)\n");
+   break;
+   }
+
+   close(fence);
+   close(timeline);
+   igt_require(!skip);
+}
+
 static void test_sync_merge_invalid(void)
 {
int in_fence;
@@ -784,6 +820,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
 
+   igt_subtest("sync_busy_fork")
+   test_sync_busy_fork();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 13/21] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

[Robert Foss]

This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 139 
 1 file changed, 139 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index d3ae4b5c..f4d1f139 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -457,6 +457,142 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static int test_mspc_wait_on_fence(int fence)
+{
+   int error, active;
+
+   do {
+   error = sync_fence_count_status(fence,
+  SW_SYNC_FENCE_STATUS_ERROR);
+   igt_assert_f(error == 0, "Error occurred on fence\n");
+   active = sync_fence_count_status(fence,
+   
SW_SYNC_FENCE_STATUS_ACTIVE);
+   } while (active);
+
+   return 0;
+}
+
+static struct {
+   int iterations;
+   int threads;
+   int counter;
+   int cons_timeline;
+   int *prod_timeline;
+   pthread_mutex_t lock;
+} test_mpsc_data;
+
+static int mpsc_producer_thread(void *d)
+{
+   int id = (long)d;
+   int fence, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+
+   for (i = 0; i < iterations; i++) {
+   fence = sw_sync_fence_create(cons_timeline, i);
+
+   /* Wait for the consumer to finish. Use alternate
+* means of waiting on the fence
+*/
+   if ((iterations + id) % 8 != 0) {
+   igt_assert_f(sync_wait(fence, -1) == 0,
+"Failure waiting on fence\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   /* Every producer increments the counter, the consumer
+* checks and erases it
+*/
+   pthread_mutex_lock(_mpsc_data.lock);
+   test_mpsc_data.counter++;
+   pthread_mutex_unlock(_mpsc_data.lock);
+
+   sw_sync_timeline_inc(prod_timeline[id], 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+static int mpsc_consumer_thread(void)
+{
+   int fence, merged, tmp, it, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+   int n = test_mpsc_data.threads;
+
+   for (it = 1; it <= iterations; it++) {
+   fence = sw_sync_fence_create(prod_timeline[0], it);
+   for (i = 1; i < n; i++) {
+   tmp = sw_sync_fence_create(prod_timeline[i], it);
+   merged = sync_merge(tmp, fence);
+   close(tmp);
+   close(fence);
+   fence = merged;
+   }
+
+   /* Make sure we see an increment from every producer thread.
+* Vary the means by which we wait.
+*/
+   if (iterations % 8 != 0) {
+   igt_assert_f(sync_wait(fence, -1) == 0,
+   "Producers did not increment as 
expected\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   igt_assert_f(test_mpsc_data.counter == n * it,
+"Counter value mismatch\n");
+
+   /* Release the producer threads */
+   sw_sync_timeline_inc(cons_timeline, 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+/* IMPORTANT NOTE: if you see this test failing on your system, it may be
+ * due to a shortage of file descriptors. Please ensure your system has
+ * a sensible limit for this test to finish correctly.
+ */
+static void test_sync_multi_producer_single_consumer(void)
+{
+   int iterations = 1 << 12;
+   int n = 5;
+   int prod_timeline[n];
+   int cons_timeline;
+   pthread_t threads[n];
+   long i;
+
+   cons_timeline = sw_sync_timeline_create();
+   for (i = 0; i < n; i++)
+   prod_timeline[i] = sw_sync_timeline_create();
+
+   test_mpsc_data.prod_timeline = prod_timeline;
+   test_mpsc_data.cons_timeline = cons_timeline;
+   test_mpsc_data.iterations = iterations;
+   test_mpsc_data.threads = n;
+   test_mpsc_data.counter = 0;
+   

[Intel-gfx] [PATCH i-g-t v11 06/21] tests/sw_sync: Add subtest test_sync_busy

[Robert Foss]

This subtest verifies that waiting on fences works properly.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 1af571bb..075791fd 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -29,6 +29,7 @@
 
 #include "igt.h"
 #include "igt_aux.h"
+#include "igt_primes.h"
 
 #include "sw_sync.h"
 
@@ -81,6 +82,53 @@ static void test_alloc_merge_fence(void)
close(timeline[1]);
 }
 
+static void test_sync_busy(void)
+{
+   int fence, ret;
+   int timeline;
+   int seqno;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 5);
+
+   /* Make sure that fence has not been signaled yet */
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early 
(timeline value 0, fence seqno 5)\n");
+
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(timeline, 1);
+
+   /* Make sure that fence has not been signaled yet */
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled early 
(timeline value 1, fence seqno 5)\n");
+
+   /* Advance timeline from 1 -> 5: signaling the fence (seqno 5)*/
+   sw_sync_timeline_inc(timeline, 4);
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Fence not signaled (timeline value 5, fence 
seqno 5)\n");
+
+   /* Go even further, and confirm wait still succeeds */
+   sw_sync_timeline_inc(timeline, 5);
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Fence not signaled (timeline value 10, fence 
seqno 5)\n");
+
+   seqno = 10;
+   for_each_prime_number(prime, 100) {
+   int fence_prime;
+   seqno += prime;
+
+   fence_prime = sw_sync_fence_create(timeline, seqno);
+   sw_sync_timeline_inc(timeline, prime);
+
+   ret = sync_wait(fence_prime, 0);
+   igt_assert_f(ret == 0, "Fence not signaled during test of prime 
timeline increments\n");
+   close(fence_prime);
+   }
+
+   close(fence);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -94,5 +142,8 @@ igt_main
 
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
+
+   igt_subtest("sync_busy")
+   test_sync_busy();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 05/21] tests/sw_sync: Add subtest test_alloc_merge_fence

[Robert Foss]

This subtest verifies that merging two fences works in the simples possible
case.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 1ec88741..1af571bb 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -61,6 +61,26 @@ static void test_alloc_fence_invalid_timeline(void)
"Did not fail to create fence on invalid timeline\n");
 }
 
+static void test_alloc_merge_fence(void)
+{
+   int in_fence[2];
+   int fence_merge;
+   int timeline[2];
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 1);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 1);
+   fence_merge = sync_merge(in_fence[1], in_fence[0]);
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -71,5 +91,8 @@ igt_main
 
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+
+   igt_subtest("alloc_merge_fence")
+   test_alloc_merge_fence();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 00/21] Implement sw_sync test

[Robert Foss]

This series implements the sw_sync test and the lib/sw_sync helper functions 
for said test.

The sw_sync subtests range from very basic tests of the sw_sync functionality, 
to stress testing and randomized tests.


Changes since v1:
Added "Reviewed-by: Eric Engestrom " tag

  lib/sw_sync:
  - Fixed fd value checking
  - Fixed fd validity check in sw_sync_fd_close()
  - Moved sw_sync related paths to define
  - Switched from malloc+memset to calloc in sync_file_info()
  - Switched sizeof to dereferenced ptr

  tests/sw_sync:
  - Moved lib/sw_sync related code to lib/sw_sync commit
  - Replaced memset with assignment in loop


Changes since v2:

  lib/sw_sync:
  - Replaced fd validity check in sw_sync_timeline_create()
  - Replace sw_sync_XXX_destroy() functions with close()
  - Simplified sw_sync_timeline_inc() comparison
  - Changed sw_sync_merge() return value to -errno
  - Changed name of sw_sync_fence_size() to sw_sync_fence_count()
  - Reworked implementation of sw_sync_fence_count()
  - Reworked implementation of sw_sync_fence_count_status()

  tests/sw_sync:
  - Replace sw_sync_XXX_destroy() functions with close()


Changes since v3:

  lib/sw_sync:
  - Changed sw_sync_fence_create() to take uint32_t seqno
  - Added raw __sw_sync_fence_create() and failure check sw_sync_fence_create()

  tests/sw_sync:
  - Switch to using __sw_sync_fence_create() for failure cases


Changes since v4:

  lib/sw_sync:
  - Fixed whitespace in sw_sync_fence_count()
  - Fixed whitespace and style of sw_sync_wait()
  - Fixed whitespace in __sw_sync_fence_count_status()


Changes since v5:

  lib/sw_sync:
  - Added kernel_has_sw_sync()
  - Added igt_require_sw_sync()
  - Split out __sw_sync_merge() from sw_sync_merge()
  - Added igt_debugfs.h include
  - Change sw_sync_wait to reflect android implementation
  - Renamed some functions:
   - sw_sync_merge -> sync_merge
   - sw_sync_wait -> sync_wait
   - sw_sync_fence_count -> sync_fence_count
   - sw_sync_fence_count_status -> sync_fence_count_status
   - __sw_sync_fence_count_status -> __sync_fence_count_status

  tests/sw_sync:
  - Added subtest test_sync_expired_merge
  - Added subtest test_timeline_closed
  - Added subtest test_timeline_closed_signaled
  - Added subtest test_sync_merge_invalid
  - Added subtest test_sync_busy_fork
  - Added subtest test_sync_busy_unixsockets
  - Skip test on no sw_sync support
  - Reworked comments of test_sync_wait
  - Renamed test_sync_wait -> test_sync_busy
  - Improved test_sync_wait igt_assert_f messages


Changes since v6:

  tests/sw_sync:
  - Added igt_assert to test_sync_expired_merge
  - Added prime increments to test_sync_busy


Changes since v7:

  - Removed accidental inclusions


Changes since v8:

  - Removed some more accidental inclusions

  lib/sw_sync:
- Moved some changes into the lib/sw_sync commit


Changes since v9:

Added: Reviewed-by: Tomeu Vizoso 
Made asserts more informative

  tests/sw_sync:
- Removed nbr_threads from data_t
- Removed nbr_iterations from data_t
  lib/sw_sync:
- Removed undue Google/AOSP attribution
- Added LOCAL_ prefix to some defines
- Added comment for sw_sync path defines
- Changed return type of sw_sync_fd_is_valid to bool
- Made sw_sync_fd_is_valid internal to lib/sw_sync
- Remove dead sw_sync_fd_is_valid call from sync_merge
- Initialize structs at declaration instead of using memset


Changes since v10:

  tests/sw_sync:
- Changed sync_wait usage in test_sync_random_merge
  lib/sw_sync:
- Extracted sw_sync path search from kernel_has_sw_sync


Rafael Antognolli (1):
  tests/sw_sync: Add subtest test_sync_expired_merge

Robert Foss (20):
  lib/sw_sync: Add helper functions for managing synchronization
primitives
  test/sw_sync: Add sw_sync test
  tests/sw_sync: Add subtest test_alloc_fence
  tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline
  tests/sw_sync: Add subtest test_alloc_merge_fence
  tests/sw_sync: Add subtest test_sync_busy
  tests/sw_sync: Add subtest test_sync_merge
  tests/sw_sync: Add subtest test_sync_merge_same
  tests/sw_sync: Add subtest test_sync_multi_consumer
  tests/sw_sync: Add subtest test_sync_multi_consumer_producer
  tests/sw_sync: Add subtest test_sync_random_merge
  tests/sw_sync: Add subtest test_sync_multi_timeline_wait
  tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer
  tests/sw_sync: Add subtest test_timeline_closed
  tests/sw_sync: Add subtest test_timeline_closed_signaled
  lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync
support
  tests/sw_sync: Add igt_require check for sw_sync feature
  tests/sw_sync: Add subtest test_sync_merge_invalid
  tests/sw_sync: Add subtest test_sync_busy_fork
  tests/sw_sync: Add subtest test_sync_busy_unixsocket

 lib/Makefile.sources   |   2 +
 lib/sw_sync.c  | 228 
 lib/sw_sync.h  |  45 +++
 tests/Makefile.sources |   1 +
 

[Intel-gfx] [PATCH i-g-t v11 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

[Robert Foss]

From: Rafael Antognolli 

This test creates an already expired fence, then creates a merged fence
out of that expired one (passed twice to the merge operation), and
finally closes the merged fence. It shows that if the refcounts are
wrong on the original expired fence, it might get freed while still in
use. Usually a kernel panick will follow.

Signed-off-by: Rafael Antognolli 
Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index f4d1f139..e88ecde4 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -593,6 +593,34 @@ static void test_sync_multi_producer_single_consumer(void)
pthread_join(threads[i], NULL);
 }
 
+static void test_sync_expired_merge(void)
+{
+   int iterations = 1 << 20;
+   int timeline;
+   int i;
+   int fence_expired, fence_merged;
+
+   timeline = sw_sync_timeline_create();
+
+   sw_sync_timeline_inc(timeline, 100);
+   fence_expired = sw_sync_fence_create(timeline, 1);
+   igt_assert_f(sync_wait(fence_expired, 0) == 0,
+"Failure waiting for expired fence\n");
+
+   fence_merged = sync_merge(fence_expired, fence_expired);
+   close(fence_merged);
+
+   for (i = 0; i < iterations; i++) {
+   int fence = sync_merge(fence_expired, fence_expired);
+
+   igt_assert_f(sync_wait(fence, -1) == 0,
+"Failure waiting on fence\n");
+   close(fence);
+   }
+
+   close(fence_expired);
+}
+
 static void test_sync_random_merge(void)
 {
int i, size, ret;
@@ -698,6 +726,9 @@ igt_main
igt_subtest("sync_multi_producer_single_consumer")
test_sync_multi_producer_single_consumer();
 
+   igt_subtest("sync_expired_merge")
+   test_sync_expired_merge();
+
igt_subtest("sync_random_merge")
test_sync_random_merge();
 }
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 09/21] tests/sw_sync: Add subtest test_sync_multi_consumer

[Robert Foss]

This subtest verifies the access ordering of multiple consumer threads.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 98 +
 1 file changed, 98 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index c0eade51..5b6532c2 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -24,6 +24,8 @@
  *Robert Foss 
  */
 
+#include 
+#include 
 #include 
 #include 
 
@@ -36,6 +38,13 @@
 
 IGT_TEST_DESCRIPTION("Test SW Sync Framework");
 
+typedef struct {
+   int timeline;
+   uint32_t thread_id;
+   volatile uint32_t * volatile counter;
+   sem_t *sem;
+} data_t;
+
 static void test_alloc_timeline(void)
 {
int timeline;
@@ -217,6 +226,92 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+#define MULTI_CONSUMER_THREADS 8
+#define MULTI_CONSUMER_ITERATIONS (1 << 14)
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int timeline = data->timeline;
+   int ret, i;
+
+   for (i = 0; i < MULTI_CONSUMER_ITERATIONS; i++) {
+   int next_point = i * MULTI_CONSUMER_THREADS + thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sync_wait(fence, 1000);
+   if (ret == -1)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   sem_post(data->sem);
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+
+   data_t data_arr[MULTI_CONSUMER_THREADS];
+   pthread_t thread_arr[MULTI_CONSUMER_THREADS];
+   sem_t sem;
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   sem_init(, 0, 0);
+   timeline = sw_sync_timeline_create();
+
+   data.counter = 
+   data.timeline = timeline;
+   data.sem = 
+
+   /* Start sync threads. */
+   for (i = 0; i < MULTI_CONSUMER_THREADS; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Produce 'content'. */
+   for (i = 0; i < MULTI_CONSUMER_THREADS * MULTI_CONSUMER_ITERATIONS; i++)
+   {
+   sem_wait();
+
+   counter++;
+   sw_sync_timeline_inc(timeline, 1);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < MULTI_CONSUMER_THREADS; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+   sem_destroy();
+
+   igt_assert_f(counter == MULTI_CONSUMER_THREADS * 
MULTI_CONSUMER_ITERATIONS,
+"Counter has unexpected value.\n");
+
+   igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -239,5 +334,8 @@ igt_main
 
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+   igt_subtest("sync_multi_consumer")
+   test_sync_multi_consumer();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 07/21] tests/sw_sync: Add subtest test_sync_merge

[Robert Foss]

Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 075791fd..7780c9e1 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -129,6 +129,70 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_merge(void)
+{
+   int in_fence[3];
+   int fence_merge;
+   int timeline;
+   int active, signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_fence_create(timeline, 2);
+   in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+   fence_merge = sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sync_merge(in_fence[2], fence_merge);
+
+   /* confirm all fences have one active point (even d) */
+   active = sync_fence_count_status(in_fence[0],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+   active = sync_fence_count_status(in_fence[1],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+   active = sync_fence_count_status(in_fence[2],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+   /* confirm that fence_merge is not signaled until the max of fence 
0,1,2 */
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+   signaled = sync_fence_count_status(fence_merge,
+  SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -145,5 +209,8 @@ igt_main
 
igt_subtest("sync_busy")
test_sync_busy();
+
+   igt_subtest("sync_merge")
+   test_sync_merge();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 02/21] test/sw_sync: Add sw_sync test

[Robert Foss]

Add initial tests for sw_sync.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/Makefile.sources |  1 +
 tests/sw_sync.c| 51 ++
 2 files changed, 52 insertions(+)
 create mode 100644 tests/sw_sync.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 04dd2d58..5fde3946 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -134,6 +134,7 @@ TESTS_progs_M = \
prime_mmap_kms \
prime_self_import \
prime_vgem \
+   sw_sync \
template \
vgem_basic \
vgem_slow \
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
new file mode 100644
index ..42fc1e2b
--- /dev/null
+++ b/tests/sw_sync.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * 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.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_aux.h"
+
+#include "sw_sync.h"
+
+
+IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+
+static void test_alloc_timeline(void)
+{
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   close(timeline);
+}
+
+igt_main
+{
+   igt_subtest("alloc_timeline")
+   test_alloc_timeline();
+}
+
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 15/21] tests/sw_sync: Add subtest test_timeline_closed

[Robert Foss]

This subtest verifies that the fences of a timeline are not signalled when
a timelne is closed.

Signed-off-by: Robert Foss 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index e88ecde4..26bdd210 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -71,6 +71,20 @@ static void test_alloc_fence_invalid_timeline(void)
"Did not fail to create fence on invalid timeline\n");
 }
 
+static void test_timeline_closed(void)
+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   close(timeline);
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME,
+"Failure waiting on unsignaled fence on closed timeline\n");
+}
+
 static void test_alloc_merge_fence(void)
 {
int in_fence[2];
@@ -702,6 +716,9 @@ igt_main
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
 
+   igt_subtest("timeline_closed")
+   test_timeline_closed();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 08/21] tests/sw_sync: Add subtest test_sync_merge_same

[Robert Foss]

This subtest verifies merging a fence with itself does not fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 7780c9e1..c0eade51 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -193,6 +193,30 @@ static void test_sync_merge(void)
close(timeline);
 }
 
+static void test_sync_merge_same(void)
+{
+   int in_fence[2];
+   int timeline;
+   int signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sync_merge(in_fence[0], in_fence[0]);
+
+   signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 0, "Fence signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "Fence did not signal\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -212,5 +236,8 @@ igt_main
 
igt_subtest("sync_merge")
test_sync_merge();
+
+   igt_subtest("sync_merge_same")
+   test_sync_merge_same();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 03/21] tests/sw_sync: Add subtest test_alloc_fence

[Robert Foss]

Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 42fc1e2b..3db62cd0 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -43,9 +43,25 @@ static void test_alloc_timeline(void)
close(timeline);
 }
 
+static void test_alloc_fence(void)
+{
+   int in_fence;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   in_fence = sw_sync_fence_create(timeline, 0);
+
+   close(in_fence);
+   close(timeline);
+}
+
+
 igt_main
 {
igt_subtest("alloc_timeline")
test_alloc_timeline();
+
+   igt_subtest("alloc_fence")
+   test_alloc_fence();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 04/21] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline

[Robert Foss]

This subtests tests that creating fences on negative timelines fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 tests/sw_sync.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 3db62cd0..1ec88741 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -55,6 +55,11 @@ static void test_alloc_fence(void)
close(timeline);
 }
 
+static void test_alloc_fence_invalid_timeline(void)
+{
+   igt_assert_f(__sw_sync_fence_create(-1, 0) < 0,
+   "Did not fail to create fence on invalid timeline\n");
+}
 
 igt_main
 {
@@ -63,5 +68,8 @@ igt_main
 
igt_subtest("alloc_fence")
test_alloc_fence();
+
+   igt_subtest("alloc_fence_invalid_timeline")
+   test_alloc_fence_invalid_timeline();
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH i-g-t v11 01/21] lib/sw_sync: Add helper functions for managing synchronization primitives

[Robert Foss]

Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.

Signed-off-by: Robert Foss 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Engestrom 
Reviewed-by: Tomeu Vizoso 
---
 lib/Makefile.sources |   2 +
 lib/sw_sync.c| 214 +++
 lib/sw_sync.h|  44 +++
 3 files changed, 260 insertions(+)
 create mode 100644 lib/sw_sync.c
 create mode 100644 lib/sw_sync.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 602e3f68..53fdb54c 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -63,6 +63,8 @@ lib_source_list = \
rendercopy_gen8.c   \
rendercopy_gen9.c   \
rendercopy.h\
+   sw_sync.c   \
+   sw_sync.h   \
intel_reg_map.c \
intel_iosf.c\
igt_kms.c   \
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
new file mode 100644
index ..aa8feefe
--- /dev/null
+++ b/lib/sw_sync.c
@@ -0,0 +1,214 @@
+/*
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * 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.
+ *
+ * Authors:
+ *Robert Foss 
+ */
+
+#ifndef ANDROID
+#define _GNU_SOURCE
+#else
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt_debugfs.h"
+#include "sw_sync.h"
+#include "drmtest.h"
+#include "ioctl_wrappers.h"
+
+#ifndef SW_SYNC_IOC_INC
+struct sw_sync_create_fence_data {
+   __u32   value;
+   charname[32];
+   __s32   fence;
+};
+
+#define LOCAL_SW_SYNC_IOC_MAGIC'W'
+#define LOCAL_SW_SYNC_IOC_CREATE_FENCE _IOWR(LOCAL_SW_SYNC_IOC_MAGIC, 0,\
+   struct 
sw_sync_create_fence_data)
+#define LOCAL_SW_SYNC_IOC_INC  _IOW(LOCAL_SW_SYNC_IOC_MAGIC, 
1, __u32)
+#endif
+
+
+static bool kernel_sw_sync_path(char *path, int length)
+{
+   snprintf(path, length, "%s", "/dev/sw_sync");
+   if (access(path, R_OK | W_OK) == 0) {
+   return true;
+   }
+
+   snprintf(path, length, "%s", "/sys/kernel/debug/sync/sw_sync");
+   if (access(path, R_OK | W_OK) == 0) {
+   return true;
+   }
+
+   snprintf(path, length, "%s/sw_sync", igt_debugfs_mount());
+   if (access(path, R_OK | W_OK) == 0) {
+   return true;
+   }
+
+return false;
+}
+
+static bool sw_sync_fd_is_valid(int fd)
+{
+   int status;
+
+   if (fd < 0)
+   return 0;
+
+   status = fcntl(fd, F_GETFD, 0);
+   return status >= 0;
+}
+
+int sw_sync_timeline_create(void)
+{
+   char buf[128];
+   int fd;
+
+   igt_assert_f(kernel_sw_sync_path(buf, sizeof(buf)),
+   "Unable to find valid path for sw_sync\n");
+
+   fd = open(buf, O_RDWR);
+   igt_assert_f(sw_sync_fd_is_valid(fd), "Created invalid timeline\n");
+
+   return fd;
+}
+
+int __sw_sync_fence_create(int fd, uint32_t seqno)
+{
+   struct sw_sync_create_fence_data data = {0};
+   data.value = seqno;
+
+   if (igt_ioctl(fd, LOCAL_SW_SYNC_IOC_CREATE_FENCE, ))
+   return -errno;
+
+   return data.fence;
+}
+
+int sw_sync_fence_create(int fd, uint32_t seqno)
+{
+   int fence = __sw_sync_fence_create(fd, seqno);
+
+   igt_assert_f(sw_sync_fd_is_valid(fence), "Created invalid fence\n");
+
+   return fence;
+}
+
+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+   uint32_t arg = count;
+
+   do_ioctl(fd, LOCAL_SW_SYNC_IOC_INC, );
+}
+
+int sync_merge(int fd1, int fd2)
+{
+   struct sync_merge_data data = {};
+   int err;
+
+   data.fd2 

Re: [Intel-gfx] [RFC i-g-t v3 5/5] Add support for hotplug testing with the Chamelium

[Lyude Paul]

On Wed, 2016-12-07 at 12:27 +0100, Tomeu Vizoso wrote:
> Hi Lyude,
> 
> this looks very good. Some minor comments below.
> 
> Regards,
> 
> Tomeu
> 
> On 1 December 2016 at 02:24, Lyude  wrote:
> > For the purpose of testing things such as hotplugging and bad
> > monitors,
> > the ChromeOS team ended up designing a neat little device known as
> > the
> > Chamelium. More information on this can be found here:
> > 
> > https://www.chromium.org/chromium-os/testing/chamelium
> > 
> > This adds support for a couple of things to intel-gpu-tools:
> >  - igt library functions for connecting to udev and monitoring it
> > for
> >    hotplug events, loosely based off of the unfinished hotplugging
> >    implementation in testdisplay
> >  - Library functions for controlling the chamelium in tests using
> >    xmlrpc. A couple of RPC calls were ommitted here, mainly because
> > they
> >    didn't seem very useful for our needs (yet)
> >  - A set of basic tests using the chamelium.
> > 
> > Signed-off-by: Lyude 
> > 
> > Changes since v1:
> > - Don't try to guess connector mappings, have the user specify them
> >   manually using a configuration file
> > - Open DRM fd using DRIVER_ANY, not DRIVER_INTEL
> > - Lower the hotplug timeout a little bit, since 30 seconds was
> > leftover
> >   from debugging these tests anyway
> > - Don't try to keep track of the original state of the chamelium
> > ports,
> >   and just leave them plugged in after each run. This makes more
> > sense
> >   to me, since I'd imagine in automated testing setups using
> > chameliums
> >   that all of the extra monitors will probably be provided by the
> >   Chamelium to begin with, so keeping them plugged in would make
> > sure
> >   tests running afterwards that require >1 monitor don't get
> > skipped.
> > - Add wait_for_connector() to the chamelium tests. After some more
> >   testing, I found that depending on the system some tests would
> > throw
> >   false negatives due to us not waiting long enough for the system
> > to
> >   detect that we connected something to it. This mainly happened
> > with
> >   VGA connectors, since their lack of HPD makes them take
> > significantly
> >   longer for the hardware to notice. wait_for_connector() fixes
> > this by
> >   continually reprobing the status of the desired connector
> > (without
> >   relying on a hpd event happening, since that might never come)
> > until
> >   we get what we want, or we time out and fail.
> > - Use kmstest_get_property() for retrieving EDIDs instead of doing
> > it by
> >   hand
> > - Don't hardcode PIPE_A for bringing up the display, use kmstest to
> > find
> >   an appropriate CRTC to use.
> > Changes since v2:
> > - Fix incorrect usage of the list helpers when recording new EDIDs
> > - Add missing documentation
> > - Make sure documentation actually appears
> > - Since we finally got video capture working, add CRC functions and
> > fix
> >   the ones we couldn't actually test before
> > - In the exit handler, reset the xmlrpc env so we can properly
> > reset the
> >   Chamelium even after an RPC error
> > - Make sure compiling without Chamelium support still works
> > ---
> >  configure.ac   |  13 +
> >  .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
> >  lib/Makefile.am|   4 +-
> >  lib/Makefile.sources   |  10 +-
> >  lib/igt.h  |   4 +
> >  lib/igt_chamelium.c| 849
> > +
> >  lib/igt_chamelium.h|  73 ++
> >  scripts/run-tests.sh   |   4 +-
> >  tests/Makefile.am  |   5 +-
> >  tests/Makefile.sources |   9 +-
> >  tests/chamelium.c  | 407
> > ++
> >  11 files changed, 1371 insertions(+), 8 deletions(-)
> >  create mode 100644 lib/igt_chamelium.c
> >  create mode 100644 lib/igt_chamelium.h
> >  create mode 100644 tests/chamelium.c
> > 
> > diff --git a/configure.ac b/configure.ac
> > index b62b8fc..1920609 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -263,6 +263,18 @@ if test "x$with_libunwind" = xyes; then
> >   AC_MSG_ERROR([libunwind not found. Use --
> > without-libunwind to disable libunwind support.]))
> >  fi
> > 
> > +# enable support for using the chamelium
> > +AC_ARG_ENABLE(chamelium,
> > + AS_HELP_STRING([--disable-chamelium],
> > +[Build tests without chamelium
> > support]),
> > + [], [enable_chamelium=yes])
> > +
> > +AM_CONDITIONAL(HAVE_CHAMELIUM, [test "x$enable_chamelium" = xyes])
> > +if test "x$enable_chamelium" = xyes; then
> > +   AC_DEFINE(HAVE_CHAMELIUM, 1, [chamelium suport])
> > +   PKG_CHECK_MODULES(XMLRPC, xmlrpc_client)
> > +fi
> > +
> 
> 

Re: [Intel-gfx] [RFC] Smattering of selftests

[Paulo Zanoni]

Em Qua, 2016-12-07 às 13:58 +, Chris Wilson escreveu:
> More changes to GEM are on the cards, so before touching it again,
> let's
> try and nail down how the internals are meant to work. The advantage
> of mock testing is that we can write a universal test independent of
> the
> hw (e.g. testing physical object creation) and we can inspect
> internal
> state which should be able to spot subtle bugs easier than mashing
> the
> uabi. The downside to mock testing is that it doubles the upfront
> cost
> of every patch submission (if you change internal state, you're
> likely
> going to upset a test) and adds maintainance burden tracking change
> to
> external API (on the other hand it catches those silent changes that
> would lead to broken code).
> 
> In addition to mock tests, I thought it would be useful to start
> writing
> a few run-once tests against real hardware. These are not as
> interesting
> as probing uabi (I don't envisage having kms_flip inside the kernel),
> but we might like to exercise runtime suspend once upon startup, for
> example. Again, we have access to internal state that may prove
> impossible to capture even in debugfs.
> 
> Is this a totally insane and impractical proposal?

In case my opinion matters to anyone, I really like the idea of kernel-
side tests. There's a limit to what we can do from user space, and the
Kernel even has self-tests for other modules, so we have a precedent
here. Also, in the past I did have some ideas for kernel-side test code
that I never implemented since we didn't have this infrastructure (I
forgot what were my ideas). I'd love to be able to contribute to this
when I have appropriate ideas.

Can we somehow make passing these tests a requirement for the CI system
too?

Now, I haven't looked at the specific tests you proposed, so I'm not in
the position to judge sanity in those specific tests. I'm also assuming
that DRM_I915_SELFTESTS=n will keep performance the same as before.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Enable dynamic debug for DRM_[DEV]_DEBUG* (rev3)

[Patchwork]

== Series Details ==

Series: drm: Enable dynamic debug for DRM_[DEV]_DEBUG* (rev3)
URL   : https://patchwork.freedesktop.org/series/16235/
State : success

== Summary ==

Series 16235v3 drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
https://patchwork.freedesktop.org/api/1.0/series/16235/revisions/3/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-bxt-t5700 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

e46c97f4cfb63328f5bbbc0fb85c3f53703792f2 drm-tip: 2016y-12m-07d-17h-47m-18s UTC 
integration manifest
63ca4de drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3223/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave, first set of fixes for drm-next/v4.10-rc1.

BR,
Jani.

The following changes since commit e9cbc4bd0140e1d4e0172e2fe8fe07ba278e5980:

  drm/i915: Update DRIVER_DATE to 20161121 (2016-11-21 09:45:03 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/drm-intel-next-fixes-2016-12-07

for you to fetch changes up to 7a9e10253e9e52451bbe80ddb2874368dbd240a3:

  drm/i915: Move priority bumping for flips earlier (2016-12-05 11:00:32 +0200)


Chris Wilson (5):
  drm/i915: Complete requests in nop_submit_request
  drm/i915/debugfs: Drop i915_hws_info
  drm/i915/debugfs: Increment return value of gt.next_seqno
  drm/i915: Hold a reference on the request for its fence chain
  drm/i915: Move priority bumping for flips earlier

Du, Changbin (1):
  drm/i915/gvt: fix missing init param.primary

Jani Nikula (1):
  Merge tag 'gvt-next-2016-11-30' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes

Libin Yang (1):
  drm/i915/audio: fix hdmi audio noise issue

Ville Syrjälä (3):
  drm/i915: Make skl_write_{plane,cursor}_wm() static
  drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
  drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time

Xiaoguang Chen (1):
  drm/i915/gvt: fix getting 64bit bar size error

Zhenyu Wang (1):
  drm/i915/gvt: fix lock not released bug for dispatch_workload() err path

 drivers/gpu/drm/i915/gvt/gvt.h  |  2 ++
 drivers/gpu/drm/i915/gvt/scheduler.c| 10 ++
 drivers/gpu/drm/i915/gvt/vgpu.c |  1 +
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +-
 drivers/gpu/drm/i915/i915_gem.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_request.c | 34 ++---
 drivers/gpu/drm/i915/i915_sw_fence.h|  5 +
 drivers/gpu/drm/i915/intel_audio.c  |  7 +--
 drivers/gpu/drm/i915/intel_display.c| 11 +++
 drivers/gpu/drm/i915/intel_pm.c | 14 +++---
 10 files changed, 63 insertions(+), 50 deletions(-)

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

Re: [Intel-gfx] [PATCH igt] intel-ci: Do module loads first + last

[Jani Nikula]

On Wed, 07 Dec 2016, Chris Wilson  wrote:
> Do the module reload test first, so that it has the best chance of
> succeeding without outside influence (broken driver). And then do it
> last, so that it has the best chance of catching some missing
> finalisation (e.g. memleak) over the lifetime of the testing.

I see your point, and maybe I worry too much, but running stuff with a
reloaded module is never the normal use case. This makes all the test
run with a reloaded module.

BR,
Jani.

>
> Signed-off-by: Chris Wilson 
> Cc: Petri Latvala 
> ---
>  tests/intel-ci/fast-feedback.testlist | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/intel-ci/fast-feedback.testlist 
> b/tests/intel-ci/fast-feedback.testlist
> index e25facf3..b79b0c14 100644
> --- a/tests/intel-ci/fast-feedback.testlist
> +++ b/tests/intel-ci/fast-feedback.testlist
> @@ -1,11 +1,10 @@
> +igt@drv_module_reload@basic-reload
> +igt@drv_module_reload@basic-reload-inject
>  igt@core_auth@basic-auth
>  igt@core_prop_blob@basic
>  igt@drv_getparams_basic@basic-eu-total
>  igt@drv_getparams_basic@basic-subslice-total
>  igt@drv_hangman@error-state-basic
> -igt@drv_module_reload@basic-reload
> -igt@drv_module_reload@basic-reload-inject
> -igt@drv_module_reload@basic-reload-final
>  igt@gem_basic@bad-close
>  igt@gem_basic@create-close
>  igt@gem_basic@create-fd-close
> @@ -245,3 +244,4 @@ igt@vgem_basic@mmap
>  igt@vgem_basic@second-client
>  igt@vgem_basic@sysfs
>  igt@vgem_basic@unload
> +igt@drv_module_reload@basic-reload-final # keep last

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

Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

[Paulo Zanoni]

Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> This series implements following set of functionality
>   Implement IPC WA's for Broxton/KBL
>   Enable IPC in supported platforms
>   Convert WM calculation to fixed point calculation
>   Calculation of System memory Bandwidth for SKL/KBL/BXT
>   Implementation of Arbitrated memory Bandwidth related WM WA's

Pushed patches 1, 2, 3, 5 and 6, with small bikesheds applied. Thanks
for the patches!

(actually I had a little problem with dim, so right now only dinq has
the patches, drm-tip doesn't, soon they will appear)

Let's resume the discussion on the remaining patches. For a possible
next series, make sure to rebase and send only what's not applied.

> 
> 
> Mahesh Kumar (8):
>   drm/i915/skl: Add variables to check x_tile and y_tile
>   drm/i915/bxt: IPC WA for Broxton
>   drm/i915/kbl: IPC workaround for kabylake
>   drm/i915/bxt: Enable IPC support
>   drm/i915/skl+: change WM calc to fixed point 16.16
>   drm/i915: Add intel_atomic_get_existing_crtc_state function
>   drm/i915: Decode system memory bandwidth
>   drm/i915/gen9: WM memory bandwidth related workaround
> 
>  drivers/gpu/drm/i915/i915_drv.c  | 175 ++
>  drivers/gpu/drm/i915/i915_drv.h  | 109 ++
>  drivers/gpu/drm/i915/i915_reg.h  |  38 +
>  drivers/gpu/drm/i915/intel_display.c |  24 
>  drivers/gpu/drm/i915/intel_drv.h |  15 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 272
> +--
>  6 files changed, 586 insertions(+), 47 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Consolidate checks for memcpy-from-wc support

[Patchwork]

== Series Details ==

Series: drm/i915: Consolidate checks for memcpy-from-wc support
URL   : https://patchwork.freedesktop.org/series/16493/
State : warning

== Summary ==

Series 16493v1 drm/i915: Consolidate checks for memcpy-from-wc support
https://patchwork.freedesktop.org/api/1.0/series/16493/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-ilk-650)

fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:180  dwarn:1   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

e46c97f4cfb63328f5bbbc0fb85c3f53703792f2 drm-tip: 2016y-12m-07d-17h-47m-18s UTC 
integration manifest
a695b3e drm/i915: Consolidate checks for memcpy-from-wc support

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3222/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for FOR_UPSTREAM [VPG]: drm/i915: Parse panel BL controller from VBT (rev3)

[Patchwork]

== Series Details ==

Series: FOR_UPSTREAM [VPG]: drm/i915: Parse panel BL controller from VBT (rev3)
URL   : https://patchwork.freedesktop.org/series/16489/
State : success

== Summary ==

Series 16489v3 FOR_UPSTREAM [VPG]: drm/i915: Parse panel BL controller from VBT
https://patchwork.freedesktop.org/api/1.0/series/16489/revisions/3/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

e46c97f4cfb63328f5bbbc0fb85c3f53703792f2 drm-tip: 2016y-12m-07d-17h-47m-18s UTC 
integration manifest
452ecd0 drm/i915: Parse panel BL controller from VBT

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3221/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

[Robert Bragg]

On Mon, Dec 5, 2016 at 4:31 PM, Daniel Vetter  wrote:

> On Mon, Dec 05, 2016 at 11:24:44AM +, Robert Bragg wrote:
> > Forgot to send to dri-devel when I first sent this out...
> >
> > The few times I've looked at using DRM_DEBUG messages, I haven't found
> > them very helpful considering how noisy some of the categories are. More
> > than once now I've preferred to go in and modify individual files to
> > affect what messages I see and re-build.
> >
> > After recently converting some of the i915_perf.c messages to use
> > DRM_DEBUG, I thought I'd see if DRM_DEBUG could be updated to have a bit
> > more fine grained control than the current category flags.
> >
> > A few things to note with this first iteration:
> >
> > - I haven't looked to see what affect the change has on linked object
> >   sizes.
> >
> > - It seems like it could be nice if dynamic debug could effectively make
> >   the drm_debug parameter redundant but dynamic debug doesn't give us a
> >   way to categorise messages so maybe we'd want to consider including
> >   categories in messages something like:
> >
> >   "[drm][kms] No FB found"
> >
> >   This way all kms messages could be enabled via:
> >   echo "format [kms] +p" > dynamic_debug/control
> >
> >   Note with this simple scheme categories would no longer be mutually
> >   exclusive which could be a nice bonus.
>
> Really nice idea, and I agree that unifying drm.debug with dynamic debug
> in some way would be useful. We could implement your idea by reworking the
> existing debug helpers to auto-prepend the right string. That also opens
> up the door for much more fine-grained bucketing maybe, only challenge is
> that we should document things somewhere.
>

yup, I don't mind writing some doc updates for this if it looks worthwhile.


>
> >   Since it would involve changing the output format, I wonder how
> >   concerned others might be about breaking some userspace (maybe CI test
> >   runners) that for some reason grep for specific messages?
>
> I think the only thing we have to keep working (somehow) is drm.debug. The
> exact output format doesn't really matter at all. Getting drm.debug to
> work when dynamic debugging is enabled probably requires exporting some
> functions, so that we can set the right ddebug options from the drm.debug
> mod-option write handler. There's special mod-option macros that allow you
> to specify write handlers, so that part is ok.
>

dynamic_debug.h exposes a macro for declaring your own dynamic debug meta
data as well as a macro for testing whether the message has been enabled.

I'm handling compatibility by using those macros so I can still test the
drm.drm_debug flags.

Handling compatibility in terms of running control queries from the kernel
would be a bit more tricky since we'd need to export some api from
dynamic_debug.c as well as adding a write handler for drm_debug. Also the
enabledness of messages is boolean not refcounted so I suppose there could
be slightly annoying interactions if mixing both - though that could be
documented.

The only disadvantage I can think of currently for not handling
compatibility in terms of running control queries is that the dynamic debug
macros can normally avoid evaluating any conditions on the cpu while a
message is disabled, based on jump labels/static branches. We were already
evaluating a condition for disabled drm debug messages though, so it seems
reasonable to continue for now.


>
> The other bit of backwards compat we imo need is that by default we should
> still keep drm.debug working, even when dynamic debugging is disabled.
> Having a third option that uses no_printk or similar (to get rid of all
> the debug strings and dead-code-eliminate all the related output code)
>

Yeah, I think the current code already handles this, but sorry if it's not
clear.

This version is #ifdefed so that if dynamic debug isn't enabled the dynamic
debug path reduces to a no_prink

I'm considering CONFIG_DYNAMIC_DEBUG being enabled or not and when enabled
I check drm_debug and the dynamic debug state, when disabled I'm just
checking the drm_debug flags and the dynamic debugs bits boil out.

In my updated patch things we re-jigged a little so pr_debug and dev_dbg
are used when CONFIG_DYNAMIC_DEBUG is not enabled, and these internally
boil down to no_printk if DEBUG is disabled. Actually we might want to
consider if that's the desired behaviour - since DRM_DEBUG wasn't
previously affected by DEBUG being defined or not.


> > --- >8 --- (git am --scissors)
> >
> > Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt)
> > allow fine grained control over which debug messages are enabled with
> > runtime control through /sysfs/kernel/debug/dynamic_debug/control
> >
> > This provides more control than the current drm.drm_debug parameter
> > which for some use cases is impractical to use given how chatty
> > some drm debug categories are.
> >
> > For example all debug messages in i915_drm.c 

[Intel-gfx] [PATCH 1/2] drm/i915: Move uncore selfchecks to late selftest infrastructure

[Chris Wilson]

Now that the kselftest infrastructure exists, put it to use and add to
it the existing consistency checks on the fw register lookup tables.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_late_selftests.h |   1 +
 drivers/gpu/drm/i915/intel_uncore.c| 116 +
 2 files changed, 69 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_late_selftests.h 
b/drivers/gpu/drm/i915/i915_late_selftests.h
index e6645d08d964..289a651db2fd 100644
--- a/drivers/gpu/drm/i915/i915_late_selftests.h
+++ b/drivers/gpu/drm/i915/i915_late_selftests.h
@@ -8,4 +8,5 @@
  *
  * Tests are executed in reverse order by igt/drv_selftest
  */
+selftest(uncore, intel_uncore_late_selftests)
 selftest(sanitycheck, i915_late_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index c1ca4df38dea..bd8436b8f3a4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -628,33 +628,6 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 
offset)
return entry ? entry->domains : 0;
 }
 
-static void
-intel_fw_table_check(struct drm_i915_private *dev_priv)
-{
-   const struct intel_forcewake_range *ranges;
-   unsigned int num_ranges;
-   s32 prev;
-   unsigned int i;
-
-   if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
-   return;
-
-   ranges = dev_priv->uncore.fw_domains_table;
-   if (!ranges)
-   return;
-
-   num_ranges = dev_priv->uncore.fw_domains_table_entries;
-
-   for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
-   WARN_ON_ONCE(IS_GEN9(dev_priv) &&
-(prev + 1) != (s32)ranges->start);
-   WARN_ON_ONCE(prev >= (s32)ranges->start);
-   prev = ranges->start;
-   WARN_ON_ONCE(prev >= (s32)ranges->end);
-   prev = ranges->end;
-   }
-}
-
 #define GEN_FW_RANGE(s, e, d) \
{ .start = (s), .end = (e), .domains = (d) }
 
@@ -693,23 +666,6 @@ static const i915_reg_t gen8_shadowed_regs[] = {
/* TODO: Other registers are not yet used */
 };
 
-static void intel_shadow_table_check(void)
-{
-   const i915_reg_t *reg = gen8_shadowed_regs;
-   s32 prev;
-   u32 offset;
-   unsigned int i;
-
-   if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
-   return;
-
-   for (i = 0, prev = -1; i < ARRAY_SIZE(gen8_shadowed_regs); i++, reg++) {
-   offset = i915_mmio_reg_offset(*reg);
-   WARN_ON_ONCE(prev >= (s32)offset);
-   prev = offset;
-   }
-}
-
 static int mmio_reg_cmp(u32 key, const i915_reg_t *reg)
 {
u32 offset = i915_mmio_reg_offset(*reg);
@@ -1436,10 +1392,6 @@ void intel_uncore_init(struct drm_i915_private *dev_priv)
break;
}
 
-   intel_fw_table_check(dev_priv);
-   if (INTEL_GEN(dev_priv) >= 8)
-   intel_shadow_table_check();
-
if (intel_vgpu_active(dev_priv)) {
ASSIGN_WRITE_MMIO_VFUNCS(vgpu);
ASSIGN_READ_MMIO_VFUNCS(vgpu);
@@ -1962,3 +1914,71 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
*dev_priv,
 
return fw_domains;
 }
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "i915_selftest.h"
+
+static int intel_fw_table_check(struct drm_i915_private *i915)
+{
+   const struct intel_forcewake_range *ranges;
+   unsigned int num_ranges, i;
+   s32 prev;
+
+   ranges = i915->uncore.fw_domains_table;
+   if (!ranges)
+   return 0;
+
+   num_ranges = i915->uncore.fw_domains_table_entries;
+   for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
+   /* Check that the tabke is watertight */
+   if (WARN_ON(IS_GEN9(i915) && (prev + 1) != (s32)ranges->start))
+   return -EINVAL;
+
+   /* Check that the table never goes backwards */
+   if (WARN_ON(prev >= (s32)ranges->start))
+   return -EINVAL;
+
+   /* Check that the entry is valid */
+   if (WARN_ON(ranges->start >= (s32)ranges->end))
+   return -EINVAL;
+
+   prev = ranges->end;
+   }
+
+   return 0;
+}
+
+static int intel_shadow_table_check(void)
+{
+   const i915_reg_t *reg = gen8_shadowed_regs;
+   unsigned int i;
+   s32 prev;
+
+   for (i = 0, prev = -1; i < ARRAY_SIZE(gen8_shadowed_regs); i++, reg++) {
+   u32 offset = i915_mmio_reg_offset(*reg);
+   if (WARN_ON(prev >= (s32)offset))
+   return -EINVAL;
+
+   prev = offset;
+   }
+
+   return 0;
+}
+
+int intel_uncore_late_selftests(struct drm_i915_private *i915)
+{
+   int err;
+
+   err = intel_fw_table_check(i915);
+   if (err)
+   return err;
+
+   if 

[Intel-gfx] [PATCH 2/2] drm/i915: Test all fw tables during mock selftests

[Chris Wilson]

In addition to just testing the fw table we load, during the initial
mock testing we can test that all tables are valid (so the testing is
not limited to just the platforms that load that particular table).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_mock_selftests.h |  1 +
 drivers/gpu/drm/i915/intel_uncore.c| 43 +++---
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_mock_selftests.h 
b/drivers/gpu/drm/i915/i915_mock_selftests.h
index 34f32f777b34..d2c469eba1dc 100644
--- a/drivers/gpu/drm/i915/i915_mock_selftests.h
+++ b/drivers/gpu/drm/i915/i915_mock_selftests.h
@@ -11,4 +11,5 @@
 selftest(objects, i915_gem_object_selftests)
 selftest(requests, i915_gem_request_selftest)
 selftest(breadcrumbs, intel_breadcrumbs_selftest)
+selftest(uncore, intel_uncore_mock_selftests)
 selftest(sanitycheck, i915_mock_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index bd8436b8f3a4..8ad93acbb16f 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1918,20 +1918,16 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
*dev_priv,
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "i915_selftest.h"
 
-static int intel_fw_table_check(struct drm_i915_private *i915)
+static int intel_fw_table_check(const struct intel_forcewake_range *ranges,
+   unsigned int num_ranges,
+   int gen)
 {
-   const struct intel_forcewake_range *ranges;
-   unsigned int num_ranges, i;
+   unsigned int i;
s32 prev;
 
-   ranges = i915->uncore.fw_domains_table;
-   if (!ranges)
-   return 0;
-
-   num_ranges = i915->uncore.fw_domains_table_entries;
for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
/* Check that the tabke is watertight */
-   if (WARN_ON(IS_GEN9(i915) && (prev + 1) != (s32)ranges->start))
+   if (WARN_ON(gen >= 9 && (prev + 1) != (s32)ranges->start))
return -EINVAL;
 
/* Check that the table never goes backwards */
@@ -1965,11 +1961,38 @@ static int intel_shadow_table_check(void)
return 0;
 }
 
+int intel_uncore_mock_selftests(void)
+{
+   struct {
+   const struct intel_forcewake_range *ranges;
+   unsigned int num_ranges;
+   int gen;
+   } fw[] = {
+   { __vlv_fw_ranges, ARRAY_SIZE(__vlv_fw_ranges), 7 },
+   { __chv_fw_ranges, ARRAY_SIZE(__chv_fw_ranges), 8 },
+   { __gen9_fw_ranges, ARRAY_SIZE(__gen9_fw_ranges), 9 },
+   };
+   int err, i;
+
+   for (i = 0; i < ARRAY_SIZE(fw); i++) {
+   err = intel_fw_table_check(fw[i].ranges,
+  fw[i].num_ranges,
+  fw[i].gen);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
 int intel_uncore_late_selftests(struct drm_i915_private *i915)
 {
int err;
 
-   err = intel_fw_table_check(i915);
+   /* Confirm the table we load is still valid */
+   err = intel_fw_table_check(i915->uncore.fw_domains_table,
+  i915->uncore.fw_domains_table_entries,
+  INTEL_GEN(i915));
if (err)
return err;
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay

[Ville Syrjälä]

On Wed, Dec 07, 2016 at 06:25:50PM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 07:51:16PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 07, 2016 at 05:41:39PM +, Chris Wilson wrote:
> > > Or we can push this wait to where it can interrupt, such as 
> > > prepare_planes_fb.
> > > (For intel_atomic_commit_tail, intel_crtc_disable_noatomic() should always
> > > be a no-op.) And then we are down to just the shrinker running
> > > uninterruptibly, just one last place to fix.
> > 
> > Hmm. Yeah I guess we could try to do this in a different place.
> 
> If we do the intel_overlay_off() via mmio (rather than CS) that makes it
> simpler, as we just have to wait for the prior operation.
> 
> I'm not imagining that we can just use mmio, right?

Yeah, I have a branch that always uses mmio for the overlay
enable/disable/flips. I finished rebasing it the other night,
though it seems I have a bit of a buglet in there on 830 on
account of the DOVSTA "overlay update finished" bit not being 
truthful once the overlay has turned off. So still needs a bit
more work I think.

And we still need to use the ring for the texture cache vs.
overlay line buffers reconfiguration thing though. So far what
I have doesn't really split the steps apart that much. Ie. I
always emit the MI_OVERLAY_OFF as soon as the plane has turned
off. We could postpone it a bit just in case the plane is about
to be re-enabled almost immediately (eg. could be it's just
getting moved to the other pipe).

Though I'm not really sure if the cache reconfiguration alone
depends on the pipe somehow, or if we could just shut down the
pipe before the cache recofiguration has finished. I'd have to
play around with it a bit more to find out I guess.

So there are still a few unknowns with the mmio apporach.

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

[Intel-gfx] [PATCH] drm/i915: Asynchronously wait for the overlay to finish

[Chris Wilson]

Treat the overlay as another wait-source, just like other rendering to
the fb, and asynchronously wait upon it before doing an atomic modeset.

Signed-off-by: Chris Wilson 
---
This is half the solution, it should prevent the wait before disabling
the overlay, but we still need to remove the wait from inside
intel_overlay_off() itself, preferably by switching to mmio instead of
CS here.
---
 drivers/gpu/drm/i915/intel_display.c |  9 +
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_overlay.c | 19 +++
 3 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bfcd368ebf6f..6c51b0f2a96e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14183,9 +14183,18 @@ intel_prepare_plane_fb(struct drm_plane *plane,
int ret;
 
if (plane->state->fb && old_plane_needs_modeset(plane, new_state)) {
+   struct intel_crtc *crtc = to_intel_crtc(plane->state->crtc);
struct drm_i915_gem_object *old_obj =
intel_fb_obj(plane->state->fb);
 
+   /* Queue this update after a previous old-school overlay flip */
+   if (crtc->overlay) {
+   ret = intel_overlay_await(crtc->overlay,
+ _state->commit_ready);
+   if (ret)
+   return ret;
+   }
+
/* Big Hammer, we also need to ensure that any pending
 * MI_WAIT_FOR_EVENT inside a user batch buffer on the
 * current scanout is retired before unpinning the old
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5c521065dc3b..87fd544339d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1566,6 +1566,8 @@ void intel_attach_aspect_ratio_property(struct 
drm_connector *connector);
 /* intel_overlay.c */
 void intel_setup_overlay(struct drm_i915_private *dev_priv);
 void intel_cleanup_overlay(struct drm_i915_private *dev_priv);
+int intel_overlay_await(struct intel_overlay *overlay,
+   struct i915_sw_fence *fence);
 int intel_overlay_switch_off(struct intel_overlay *overlay);
 int intel_overlay_put_image_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 79f93e7d699d..476a25961f34 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -855,6 +855,25 @@ static int intel_overlay_do_put_image(struct intel_overlay 
*overlay,
return ret;
 }
 
+int intel_overlay_await(struct intel_overlay *overlay,
+   struct i915_sw_fence *fence)
+{
+   struct drm_i915_gem_request *request;
+   int err;
+
+   request = i915_gem_active_peek(>last_flip,
+  >i915->drm.struct_mutex);
+   if (!request)
+   return 0;
+
+   err = i915_sw_fence_await_dma_fence(fence,
+   >fence, 0, GFP_KERNEL);
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+
 int intel_overlay_switch_off(struct intel_overlay *overlay)
 {
struct drm_i915_private *dev_priv = overlay->i915;
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Allow CAP_PRIME on !MODESET (rev2)

[Patchwork]

== Series Details ==

Series: drm: Allow CAP_PRIME on !MODESET (rev2)
URL   : https://patchwork.freedesktop.org/series/16479/
State : success

== Summary ==

Series 16479v2 drm: Allow CAP_PRIME on !MODESET
https://patchwork.freedesktop.org/api/1.0/series/16479/revisions/2/mbox/

Test prime_vgem:
Subgroup basic-busy-default:
skip   -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-byt-n2820)
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-kbl-7500u)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-skl-6700hq)
skip   -> PASS   (fi-ivb-3520m)
skip   -> PASS   (fi-skl-6700k)
skip   -> PASS   (fi-bdw-5557u)
skip   -> PASS   (fi-ivb-3770)
skip   -> PASS   (fi-skl-6260u)
skip   -> PASS   (fi-snb-2600)
skip   -> PASS   (fi-bsw-n3050)
skip   -> PASS   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-fence-flip:
skip   -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-byt-n2820)
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-kbl-7500u)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-skl-6700k)
skip   -> PASS   (fi-hsw-4770)
skip   -> PASS   (fi-ivb-3770)
skip   -> PASS   (fi-skl-6260u)
skip   -> PASS   (fi-snb-2600)
skip   -> PASS   (fi-bdw-5557u)
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-fence-mmap:
skip   -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-byt-n2820)
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-kbl-7500u)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-skl-6700hq)
skip   -> PASS   (fi-ivb-3520m)
skip   -> PASS   (fi-skl-6700k)
skip   -> PASS   (fi-bdw-5557u)
skip   -> PASS   (fi-ivb-3770)
skip   -> PASS   (fi-skl-6260u)
skip   -> PASS   (fi-snb-2600)
skip   -> PASS   (fi-bsw-n3050)
skip   -> PASS   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-fence-read:
skip   -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-byt-n2820)
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-kbl-7500u)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-skl-6700hq)
skip   -> PASS   (fi-ivb-3520m)
skip   -> PASS   (fi-skl-6700k)
skip   -> PASS   (fi-bdw-5557u)
skip   -> PASS   (fi-ivb-3770)
skip   -> PASS   (fi-skl-6260u)
skip   -> PASS   (fi-snb-2600)
skip   -> PASS   (fi-bsw-n3050)
skip   -> PASS   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-fence-wait-default:
skip   -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-byt-n2820)
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-kbl-7500u)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-skl-6700hq)
skip   -> PASS   (fi-ivb-3520m)
skip   -> PASS   (fi-skl-6700k)
skip   -> PASS   (fi-bdw-5557u)
skip   -> PASS   (fi-ivb-3770)
skip   -> PASS   (fi-skl-6260u)
skip   -> PASS   (fi-snb-2600)
skip   -> PASS   (fi-bsw-n3050)
skip   -> PASS   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)
Subgroup basic-gtt:
skip   -> PASS   (fi-byt-j1900)
skip   -> PASS   (fi-byt-n2820)
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-kbl-7500u)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-skl-6700hq)
skip   -> PASS   (fi-ivb-3520m)
skip   -> PASS   (fi-skl-6700k)
skip  

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: make Pineview a platform of its own

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915: make Pineview a platform of its own
> URL   : https://patchwork.freedesktop.org/series/16490/
> State : warning
> 
> == Summary ==
> 
> Series 16490v1 drm/i915: make Pineview a platform of its own
> https://patchwork.freedesktop.org/api/1.0/series/16490/revisions/1/mbox/
> 
> Test kms_force_connector_basic:
> Subgroup force-connector-state:
> pass   -> DMESG-WARN (fi-snb-2520m)
*ERROR* EDID checksum is invalid
=> https://bugs.freedesktop.org/show_bug.cgi?id=98625

> fi-snb-2520m total:247  pass:201  dwarn:1   dfail:0   fail:0   skip:45
> 
> a20a4a6107256124d136c8320fc3f7adef93bb8a drm-tip: 2016y-12m-07d-15h-
> 56m-01s UTC integration manifest 8b8c20d drm/i915: make Pineview a
> platform of its own
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3218/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*

[Robert Bragg]

This is still missing corresponding documentation changes, and I haven't
moved anything to drm_print.h yet, as suggested.

Sending out with a few functional improvements first to get agreement
before documenting anything (changes summarised in v2: section below)

In particular, affecting the output format, I stole an idea from Tvrtko
Ursulin to have the prefix for messages be based on the driver name,
such as "[i915]" instead of always being "[drm]".

Depending on peoples thoughts on compatibility, we could consider
removing the prefix given that the dynamic debug control interface has a
way of specifying that messages should include a module name, function
or line info like:

echo "module i915 +mfp" > dynamic_debug/control

That would enable all i915 debug messages with a module and function
prefix.

A trade-off would be that anyone only using the drm.drm_debug interface
to control messages would loose some information. If we really wanted we
could have the best of both by adding a utility printing api that can
recognise when printing due to a dynamic debug control query vs
drm.drm_debug to conditionally add the prefix.

--- >8 --- (git am --scissors)

Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt)
allow fine grained control over which debug messages are enabled with
runtime control through /sysfs/kernel/debug/dynamic_debug/control

This provides more control than the current drm.drm_debug parameter
which for some use cases is impractical to use given how chatty
some drm debug categories are.

For example all debug messages in i915_drm.c can be enabled with:
echo "file i915_perf.c +p" > dynamic_debug/control

This doesn't strictly maintain format compatibility with the previous
debug messages since the category is now added as part of the prefix
like "[drm][kms] No FB found". Adding the categories with a consistent
format makes it possible to enable categories with a dynamic debug
query like: echo "format [kms] +p" > dynamic_debug/control

This maintains support for enabling debug messages using the drm_debug
parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the
debug messages essentially work as before, except with the inclusion of
categories in the format strings as described above.

This removes the drm_[dev_]printk wrappers considering that the dynamic
debug macros are only useful if they can track the __FILE__, __func__
and __LINE__ where they are called. The wrapper didn't seem necessary in
the DRM_UT_NONE case with no category flag.

The non _DEV macros are no longer defined in terms of passing NULL to a
_DEV variant to avoid have the core.c dev_printk implementation adding
"(NULL device *)". The previous drm_[dev_]prink function used to handle
this as a special case.

Instead of using DRM_NAME to add [drm] to the start of every message,
the prefix is now based on module_name(THIS_MODULE) so it will be [drm]
or e.g. [i915] for the Intel driver. Later we might consider removing
the prefix altogether considering that the dynamic debug control
interface has a way of optionally adding the module, function or line to
the formatting of messages.

v2:
Add categories to format like "[drm][kms] No FB found"
Only single conditional call per message (macros expand to less code)
Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features
Use module name for msg prefix like [drm] or [i915]

Signed-off-by: Robert Bragg 
Cc: dri-de...@lists.freedesktop.org
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/drm_drv.c |  47 ---
 include/drm/drmP.h| 202 +-
 2 files changed, 127 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f74b7d0..25d00aa 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -65,53 +65,6 @@ static struct idr drm_minors_idr;
 
 static struct dentry *drm_debugfs_root;
 
-#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
-
-void drm_dev_printk(const struct device *dev, const char *level,
-   unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...)
-{
-   struct va_format vaf;
-   va_list args;
-
-   if (category != DRM_UT_NONE && !(drm_debug & category))
-   return;
-
-   va_start(args, format);
-   vaf.fmt = format;
-   vaf.va = 
-
-   if (dev)
-   dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
-  );
-   else
-   printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, );
-
-   va_end(args);
-}
-EXPORT_SYMBOL(drm_dev_printk);
-
-void drm_printk(const char *level, unsigned int category,
-   const char *format, ...)
-{
-   struct va_format vaf;
-   va_list args;
-
-   if (category != DRM_UT_NONE && !(drm_debug & 

Re: [Intel-gfx] [PATCH v2] drm/i915: Catch non-existent registers in find_fw_domain

[Chris Wilson]

On Wed, Dec 07, 2016 at 06:18:02PM +, Tvrtko Ursulin wrote:
> 
> On 07/12/2016 14:22, Joonas Lahtinen wrote:
> >Add WARN_ON to find_fw_domain to registers related to uninitialized
> >hardware.
> >
> >v2:
> >- Print the uninitialized domains and register (Chris)
> >
> >Cc: Imre Deak 
> >Cc: Wang Elaine 
> >Cc: Chris Wilson 
> >Signed-off-by: Joonas Lahtinen 
> >---
> > drivers/gpu/drm/i915/intel_uncore.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> >b/drivers/gpu/drm/i915/intel_uncore.c
> >index 07779d0..88f3611 100644
> >--- a/drivers/gpu/drm/i915/intel_uncore.c
> >+++ b/drivers/gpu/drm/i915/intel_uncore.c
> >@@ -625,7 +625,14 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 
> >offset)
> > dev_priv->uncore.fw_domains_table_entries,
> > fw_range_cmp);
> >
> >-return entry ? entry->domains : 0;
> >+if (!entry)
> >+return 0;
> >+
> >+WARN(entry->domains & ~dev_priv->uncore.fw_domains,
> >+ "Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n",
> >+ entry->domains & ~dev_priv->uncore.fw_domains, offset);
> >+
> >+return entry->domains;
> > }
> >
> > static void
> >
> 
> Only slight issues I can spot is that for some platforms, should it
> trigger, it would trigger twice since
> intel_uncore_forcewake_for_read/write functions have the same WARN.

I don't think that's too much of an issue whilst both are WARN() - we
are likely to get a flood of hits if we get any.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay

[Chris Wilson]

On Wed, Dec 07, 2016 at 07:51:16PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2016 at 05:41:39PM +, Chris Wilson wrote:
> > Or we can push this wait to where it can interrupt, such as 
> > prepare_planes_fb.
> > (For intel_atomic_commit_tail, intel_crtc_disable_noatomic() should always
> > be a no-op.) And then we are down to just the shrinker running
> > uninterruptibly, just one last place to fix.
> 
> Hmm. Yeah I guess we could try to do this in a different place.

If we do the intel_overlay_off() via mmio (rather than CS) that makes it
simpler, as we just have to wait for the prior operation.

I'm not imagining that we can just use mmio, right?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

[Chris Wilson]

On Wed, Dec 07, 2016 at 08:11:33PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2016 at 05:56:47PM +, Chris Wilson wrote:
> > From: Ville Syrjälä 
> > 
> > The i915_gem_active stuff doesn't like a NULL ->retire hook, but
> > the overlay code can set it to NULL. That obviously ends up oopsing.
> > Fix it by introducing a new helper to assign the retirement callback
> > that will switch out the NULL function pointer with
> > i915_gem_retire_noop.
> > 
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
> > Signed-off-by: Ville Syrjälä 
> > Signed-off-by: Chris Wilson 
> 
> lgtm, feel free to put yourself as the author is you want.
> 
> BTW I don't think we ever call the init_foo() thing on last_flip.
> Should be do that in overlay_init() or some such place?

Eeek. yes, we are missing the init_request_active() as well. A trivial
patch to add it to overlay_init, gratefully r-b'ed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Catch non-existent registers in find_fw_domain

[Tvrtko Ursulin]

On 07/12/2016 14:22, Joonas Lahtinen wrote:

Add WARN_ON to find_fw_domain to registers related to uninitialized
hardware.

v2:
- Print the uninitialized domains and register (Chris)

Cc: Imre Deak 
Cc: Wang Elaine 
Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_uncore.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 07779d0..88f3611 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -625,7 +625,14 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 
offset)
dev_priv->uncore.fw_domains_table_entries,
fw_range_cmp);

-   return entry ? entry->domains : 0;
+   if (!entry)
+   return 0;
+
+   WARN(entry->domains & ~dev_priv->uncore.fw_domains,
+"Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n",
+entry->domains & ~dev_priv->uncore.fw_domains, offset);
+
+   return entry->domains;
 }

 static void



Only slight issues I can spot is that for some platforms, should it 
trigger, it would trigger twice since 
intel_uncore_forcewake_for_read/write functions have the same WARN.


If we wanted to avoid that then this WARN would work better in 
fwtable_read/write I think.


Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

[Ville Syrjälä]

On Wed, Dec 07, 2016 at 05:56:47PM +, Chris Wilson wrote:
> From: Ville Syrjälä 
> 
> The i915_gem_active stuff doesn't like a NULL ->retire hook, but
> the overlay code can set it to NULL. That obviously ends up oopsing.
> Fix it by introducing a new helper to assign the retirement callback
> that will switch out the NULL function pointer with
> i915_gem_retire_noop.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
> Signed-off-by: Ville Syrjälä 
> Signed-off-by: Chris Wilson 

lgtm, feel free to put yourself as the author is you want.

BTW I don't think we ever call the init_foo() thing on last_flip.
Should be do that in overlay_init() or some such place?

> ---
>  drivers/gpu/drm/i915/i915_gem_request.h | 19 +++
>  drivers/gpu/drm/i915/intel_overlay.c|  3 ++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index 2fc6b8b3f580..b0d50aa81acb 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -440,6 +440,25 @@ i915_gem_active_set(struct i915_gem_active *active,
>   rcu_assign_pointer(active->request, request);
>  }
>  
> +/**
> + * i915_gem_active_set_retire_fn - updates the retirement callback
> + * @active - the active tracker
> + * @fn - the routine called when the request is retired
> + * @mutex - struct_mutex used to guard retirements
> + *
> + * i915_gem_active_set_retire_fn() updates the function pointer that
> + * is called when the final request associated with the @active tracker
> + * is retired.
> + */
> +static inline void
> +i915_gem_active_set_retire_fn(struct i915_gem_active *active,
> +   i915_gem_retire_fn fn,
> +   struct mutex *mutex)
> +{
> + lockdep_assert_held(mutex);
> + active->retire = fn ?: i915_gem_retire_noop;
> +}
> +
>  static inline struct drm_i915_gem_request *
>  __i915_gem_active_peek(const struct i915_gem_active *active)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
> b/drivers/gpu/drm/i915/intel_overlay.c
> index 354f8cec96bb..29509f3055c8 100644
> --- a/drivers/gpu/drm/i915/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/intel_overlay.c
> @@ -216,7 +216,8 @@ static void intel_overlay_submit_request(struct 
> intel_overlay *overlay,
>  {
>   GEM_BUG_ON(i915_gem_active_peek(>last_flip,
>   >i915->drm.struct_mutex));
> - overlay->last_flip.retire = retire;
> + i915_gem_active_set_retire_fn(>last_flip, retire,
> +   >i915->drm.struct_mutex);
>   i915_gem_active_set(>last_flip, req);
>   i915_add_request(req);
>  }
> -- 
> 2.11.0

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

Re: [Intel-gfx] [PATCH v2] dim: Try git-merge --ff-only before git-rebase -i when updating branches.

[Jani Nikula]

On Wed, 07 Dec 2016, Maarten Lankhorst  
wrote:
> Op 07-12-16 om 10:33 schreef Jani Nikula:
>> On Tue, 06 Dec 2016, Maarten Lankhorst  
>> wrote:
>>> When a branch can be fast-forwarded, try it first before rebasing.
>>> This will prevent a whole lot of editor windows opening with 'noop'
>>> when running dim ub.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> ---
>>>  dim | 4 +---
>>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/dim b/dim
>>> index fa63ae8c8a79..b2e6841e23d7 100755
>>> --- a/dim
>>> +++ b/dim
>>> @@ -1286,9 +1286,7 @@ function dim_update_branches
>>> repo=`branch_to_repo $branch`
>>> remote=`repo_to_remote $repo`
>>>  
>>> -   if git diff --quiet $remote/$branch; then
>>> -   $DRY git rebase
>>> -   else
>>> +   if ! $DRY git merge --ff-only ; then
>> What does it assume for branches to merge when none are provided? Would
>> it be better to be explicit?
>>
>> Thanks for this, I've been meaning to do this forever...
>
> Hm I guess explicit might be better, what about this?
> --8<---
> When a branch can be fast-forwarded, try it first before rebasing.
> This will prevent a whole lot of editor windows opening with 'noop'
> when running dim ub.

LGTM.

>
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/dim b/dim
> index fa63ae8c8a79..e0551ace54e4 100755
> --- a/dim
> +++ b/dim
> @@ -1286,9 +1286,7 @@ function dim_update_branches
>   repo=`branch_to_repo $branch`
>   remote=`repo_to_remote $repo`
>  
> - if git diff --quiet $remote/$branch; then
> - $DRY git rebase
> - else
> + if ! $DRY git merge --ff-only $remote/$branch; then
>   $DRY git rebase -i
>   fi
>   done
>

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

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

[Ville Syrjälä]

On Wed, Dec 07, 2016 at 05:44:15PM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 07:28:04PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The i915_gem_active stuff doesn't like a NULL ->retire hook, but
> > the overlay code can set it to NULL. That obviously ends up oopsing.
> > Fix it by setting the ->retire hook using init_request_active()
> > so that it'll do the NULL->i915_gem_retire_noop conversion for us.
> > 
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_overlay.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
> > b/drivers/gpu/drm/i915/intel_overlay.c
> > index 1cc963814224..786389dd5175 100644
> > --- a/drivers/gpu/drm/i915/intel_overlay.c
> > +++ b/drivers/gpu/drm/i915/intel_overlay.c
> > @@ -216,7 +216,7 @@ static void intel_overlay_submit_request(struct 
> > intel_overlay *overlay,
> >  {
> > GEM_BUG_ON(i915_gem_active_peek(>last_flip,
> > >i915->drm.struct_mutex));
> > -   overlay->last_flip.retire = retire;
> > +   init_request_active(>last_flip, retire);
> 
> Hmm, init, not reinit.

Does it matter? The list head is the other thing in there I guess, but
at this point it shouldn't be on any list anymore AFAICS.

> The alternative is to use i915_gem_retire_noop
> instead of NULL. (And sorry, it did used to allow NULL.)
> 
> overlay->last_flip.retire = retire ?= i915_gem_retire_noop;
> 
> Or i915_gem_active_set_retire_fn(>last_flip, retire);
> That's seems like it should make everyone a bit happier.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

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

[Intel-gfx] [PATCH] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

[Chris Wilson]

From: Ville Syrjälä 

The i915_gem_active stuff doesn't like a NULL ->retire hook, but
the overlay code can set it to NULL. That obviously ends up oopsing.
Fix it by introducing a new helper to assign the retirement callback
that will switch out the NULL function pointer with
i915_gem_retire_noop.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
Signed-off-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.h | 19 +++
 drivers/gpu/drm/i915/intel_overlay.c|  3 ++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 2fc6b8b3f580..b0d50aa81acb 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -440,6 +440,25 @@ i915_gem_active_set(struct i915_gem_active *active,
rcu_assign_pointer(active->request, request);
 }
 
+/**
+ * i915_gem_active_set_retire_fn - updates the retirement callback
+ * @active - the active tracker
+ * @fn - the routine called when the request is retired
+ * @mutex - struct_mutex used to guard retirements
+ *
+ * i915_gem_active_set_retire_fn() updates the function pointer that
+ * is called when the final request associated with the @active tracker
+ * is retired.
+ */
+static inline void
+i915_gem_active_set_retire_fn(struct i915_gem_active *active,
+ i915_gem_retire_fn fn,
+ struct mutex *mutex)
+{
+   lockdep_assert_held(mutex);
+   active->retire = fn ?: i915_gem_retire_noop;
+}
+
 static inline struct drm_i915_gem_request *
 __i915_gem_active_peek(const struct i915_gem_active *active)
 {
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 354f8cec96bb..29509f3055c8 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -216,7 +216,8 @@ static void intel_overlay_submit_request(struct 
intel_overlay *overlay,
 {
GEM_BUG_ON(i915_gem_active_peek(>last_flip,
>i915->drm.struct_mutex));
-   overlay->last_flip.retire = retire;
+   i915_gem_active_set_retire_fn(>last_flip, retire,
+ >i915->drm.struct_mutex);
i915_gem_active_set(>last_flip, req);
i915_add_request(req);
 }
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay

[Ville Syrjälä]

On Wed, Dec 07, 2016 at 05:41:39PM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 07:28:05PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > We need an uninterruptible wait for the overlay off request during
> > modeset. Restore the operation of dev_priv->mm.interruptible
> > sufficiently for that.
> > 
> > Toss in a WARN_ON() to make sure the request succeeds.
> > 
> > Fixes: 7da844c5c6fc ("drm/i915: Move the special case wait-request handling 
> > to its one caller")
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_request.c | 36 
> > +
> >  drivers/gpu/drm/i915/i915_gem_request.h | 35 
> > ++--
> >  drivers/gpu/drm/i915/intel_display.c|  2 +-
> >  3 files changed, 39 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > b/drivers/gpu/drm/i915/i915_gem_request.c
> > index fcf22b0e2967..1a7b88166c51 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -1199,3 +1199,39 @@ void i915_gem_retire_requests(struct 
> > drm_i915_private *dev_priv)
> > for_each_engine(engine, dev_priv, id)
> > engine_retire_requests(engine);
> >  }
> > +
> > +/**
> > + * i915_gem_active_retire - waits until the request is retired
> > + * @active - the active request on which to wait
> > + *
> > + * i915_gem_active_retire() waits until the request is completed,
> > + * and then ensures that at least the retirement handler for this
> > + * @active tracker is called before returning. If the @active
> > + * tracker is idle, the function returns immediately.
> > + */
> > +int __must_check
> > +i915_gem_active_retire(struct i915_gem_active *active,
> > +  struct mutex *mutex)
> > +{
> > +   struct drm_i915_gem_request *request;
> > +   long ret;
> > +
> > +   request = i915_gem_active_raw(active, mutex);
> > +   if (!request)
> > +   return 0;
> > +
> > +   ret = i915_wait_request(request,
> > +   (request->i915->mm.interruptible ?
> > +I915_WAIT_INTERRUPTIBLE : 0) |
> > +   I915_WAIT_LOCKED,
> > +   MAX_SCHEDULE_TIMEOUT);
> 
> At least pass in the flags.
> 
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   list_del_init(>link);
> > +   RCU_INIT_POINTER(active->request, NULL);
> > +
> > +   active->retire(active, request);
> > +
> > +   return 0;
> > +}
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> > b/drivers/gpu/drm/i915/i915_gem_request.h
> > index e2b077df2da0..09add6b9cfc7 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> > @@ -657,39 +657,8 @@ i915_gem_active_wait(const struct i915_gem_active 
> > *active, unsigned int flags)
> > return ret < 0 ? ret : 0;
> >  }
> >  
> > -/**
> > - * i915_gem_active_retire - waits until the request is retired
> > - * @active - the active request on which to wait
> > - *
> > - * i915_gem_active_retire() waits until the request is completed,
> > - * and then ensures that at least the retirement handler for this
> > - * @active tracker is called before returning. If the @active
> > - * tracker is idle, the function returns immediately.
> > - */
> > -static inline int __must_check
> > -i915_gem_active_retire(struct i915_gem_active *active,
> > -  struct mutex *mutex)
> > -{
> > -   struct drm_i915_gem_request *request;
> > -   long ret;
> > -
> > -   request = i915_gem_active_raw(active, mutex);
> > -   if (!request)
> > -   return 0;
> > -
> > -   ret = i915_wait_request(request,
> > -   I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
> > -   MAX_SCHEDULE_TIMEOUT);
> > -   if (ret < 0)
> > -   return ret;
> > -
> > -   list_del_init(>link);
> > -   RCU_INIT_POINTER(active->request, NULL);
> > -
> > -   active->retire(active, request);
> > -
> > -   return 0;
> > -}
> > +int __must_check i915_gem_active_retire(struct i915_gem_active *active,
> > +   struct mutex *mutex);
> >  
> >  #define for_each_active(mask, idx) \
> > for (; mask ? idx = ffs(mask) - 1, 1 : 0; mask &= ~BIT(idx))
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a41082e2750e..5a74991854e3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4923,7 +4923,7 @@ static void intel_crtc_dpms_overlay_disable(struct 
> > intel_crtc *intel_crtc)
> >  
> > mutex_lock(>struct_mutex);
> > dev_priv->mm.interruptible = false;
> > -   (void) 

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Fix oops in overlay due to frontbuffer trakcing

[Chris Wilson]

On Wed, Dec 07, 2016 at 07:28:03PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The vma will be NULL if the overlay was previously off, so
> dereferencing it will oops. Check for NULL before doing that.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Fixes: 9b3b7841b86d ("drm/i915/overlay: Use VMA as the primary tracker for 
> images")
> Signed-off-by: Ville Syrjälä 

Oops,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

[Ville Syrjälä]

On Thu, Dec 01, 2016 at 09:29:09PM +0100, Hans de Goede wrote:
> Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
> 
> Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
> Cc: sta...@vger.kernel.org
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Ville Syrjälä 

Pushed to dinq. Thanks for the patch.

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 3 ++-
>  1 file changed, 2 insertions(+), 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 579d2f5..47cd1b2 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -300,7 +300,8 @@ static void chv_exec_gpio(struct drm_i915_private 
> *dev_priv,
>   mutex_lock(_priv->sb_lock);
>   vlv_iosf_sb_write(dev_priv, port, cfg1, 0);
>   vlv_iosf_sb_write(dev_priv, port, cfg0,
> -   CHV_GPIO_GPIOCFG_GPO | CHV_GPIO_GPIOTXSTATE(value));
> +   CHV_GPIO_GPIOEN | CHV_GPIO_GPIOCFG_GPO |
> +   CHV_GPIO_GPIOTXSTATE(value));
>   mutex_unlock(_priv->sb_lock);
>  }
>  
> -- 
> 2.9.3

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Catch non-existent registers in find_fw_domain (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Catch non-existent registers in find_fw_domain (rev2)
URL   : https://patchwork.freedesktop.org/series/16487/
State : success

== Summary ==

Series 16487v2 drm/i915: Catch non-existent registers in find_fw_domain
https://patchwork.freedesktop.org/api/1.0/series/16487/revisions/2/mbox/


fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

722bab6dc6ca5b0fd0c667e5dd65f7734c550f94 drm-tip: 2016y-12m-07d-16h-41m-46s UTC 
integration manifest
ee9b8cb drm/i915: Catch non-existent registers in find_fw_domain

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3219/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Parse panel BL controller from VBT

[Bob Paauwe]

I currently have this same patch in my tree (well with the two changes
below) and have been testing it so with the changes.

Reviewed-by: Bob Paauwe 
Tested-by: Bob Paauwe 

On Wed, 7 Dec 2016 20:32:18 +0530 Vidya Srinivas
 wrote:

> Currently the backlight controller is taken as 0. It needs to derive
> value from the VBT. Adding the necessary changes.
> 
> v2: Updated the commit header
> 
> Signed-off-by: Uma Shankar 
> Signed-off-by: Vidya Srinivas 
> ---
>  drivers/gpu/drm/i915/i915_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_bios.c  | 5 +
>  drivers/gpu/drm/i915/intel_panel.c | 2 +-
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8daa4fb..6a85fdf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1633,6 +1633,7 @@ struct intel_vbt_data {
>   bool present;
>   bool active_low_pwm;
>   u8 min_brightness;  /* min_brightness/255 of max */
> + u8 controller;  /* brightness controller number */
>   enum intel_backlight_type type;
>   } backlight;
>  
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index eaade27..130db0f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -330,6 +330,8 @@ static u32 get_blocksize(const void *block_data)
>  
>   method = _data->backlight_control[panel_type];
>   dev_priv->vbt.backlight.type = method->type;
> + dev_priv->vbt.backlight.controller = 0;

Setting it to zero first seems redundant.  Is there a reason you do
this?

> + dev_priv->vbt.backlight.controller = method->controller;
>   }
>  
>   dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> @@ -341,6 +343,9 @@ static u32 get_blocksize(const void *block_data)
> dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
> dev_priv->vbt.backlight.min_brightness,
> backlight_data->level[panel_type]);
> +
> + DRM_DEBUG_KMS("VBT BL controller %u\n",
> + dev_priv->vbt.backlight.controller);
>  }
>  
>  /* Try to find sdvo panel data */
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index 3578b40..6a7d4c3 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1612,7 +1612,7 @@ static int vlv_setup_backlight(struct intel_connector 
> *connector, enum pipe pipe
>* For BXT hard coding the Backlight controller to 0.
>* TODO : Read the controller value from VBT and generalize
>*/
> - panel->backlight.controller = 0;
> + panel->backlight.controller = dev_priv->vbt.backlight.controller;

You should remove the comment above now that it's not hard coded.

>  
>   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
>  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [RFC 0/5] DRM logging tidy

[Robert Bragg]

On Tue, Dec 6, 2016 at 6:57 PM, Tvrtko Ursulin  wrote:

> From: Tvrtko Ursulin 
>
> I wasn't here at the beginnings of DRM so I might have gotten this wrong,
> however the existance of DRM_NAME suggested to me that the intention was to
> allow individual drivers to override it and get appropriate prefixes in
> their
> log messages.
>
> I can't see that any driver is using it like that but I still thought it
> would
> be neat to do that. That way we could have our log messages look more
> obviously ours. For example after this series we have:
>
>  [i915] Memory usable by graphics device = 4096M
>  [i915] VT-d active for gfx access
>  [i915] Replacing VGA console driver
>  [i915] ACPI BIOS requests an excessive sleep of 2 ms, using 1500 ms
> instead
>  [i915] Finished loading DMC firmware i915/skl_dmc_ver1_26.bin (v1.26)
>  [i915] Disabling framebuffer compression (FBC) to prevent screen flicker
> with VT-d enabled
>  [i915] GuC firmware load skipped
>  [i915] Initialized i915 1.6.0 20161205 for :00:02.0 on minor 0
>  [i915] DRM_I915_DEBUG enabled
>  [i915] DRM_I915_DEBUG_GEM enabled
>  [i915] RC6 on
>
> Previously all that was prefixed with "[drm]" which was OK but I think the
> above is even better.
>
> Also to consider is that recent drm_printk work has removed (it hardcoded)
> DRM_NAME from DRM_ERROR and DRM_DEBUG macros, while leaving it with the
> rest
> (DRM_INFO, NOTE and WARNING) creating a bit of a inconsistency.
>

I wonder if I can maybe fold some of this idea into my related DRM_DEBUG
[RFC] sent out recently:
https://lists.freedesktop.org/archives/dri-devel/2016-December/126094.html

Instead of using DRM_NAME, I've experimented with updating my changes
adding support for dynamic debug to add a prefix based on
module_name(THIS_MODULE) for a similar result

One thing to consider here is that with the addition of dynamic debug
support this prefix arguably becomes redundant because the
dynamic_debug/control interface lets you choose to add a module name or
function prefix to messages, e.g. like:

echo "module i915 +mfp" > dynamic_debug/control

I've ignored the redundancy because my change still allows enabling
messages with the drm.drm_debug parameter and in that case the prefix is
still useful.

Br,
- Robert



> This series also makes all the logging macros use drm_printk, but also
> makes DRM_NAME passed in from the macro wrappers in all cases. So drivers
> can override it regardless of the log level.
>
> And finally, the series also removes a bit of redundant data from the debug
> messages effectively converting this:
>
>  [drm:edp_panel_off [i915]] Wait for panel power off time
>
> Into this:
>
>  [edp_panel_off [i915]] Wait for panel power off time
>
> Which still has all the data in it.
>
> Tvrtko Ursulin (5):
>   drm/i915: Give our log messages our name
>   drm: Respect driver set DRM_NAME in drm_printk
>   drm: Respect driver set DRM_NAME in drm_dev_printk
>   drm: Use drm_printk for all logging macros
>   drm: Do not log driver prefix in debug messages
>
>  drivers/gpu/drm/drm_drv.c   | 39 +++--
>  drivers/gpu/drm/i915/i915_drv.c |  3 +-
>  include/drm/drmP.h  | 94 --
> ---
>  include/drm/drm_drv.h   | 11 ++---
>  include/uapi/drm/i915_drm.h |  3 ++
>  5 files changed, 92 insertions(+), 58 deletions(-)
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

[Ville Syrjälä]

On Fri, Dec 02, 2016 at 04:01:28PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
> 
> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> MIPI_SEQ_DEASSERT_RESET.
> 
> Looking at the naming of the sequences that is the right thing to do,
> but the problem is, that the old mainline code and the ADF code was
> actually calling the right sequence (tested on a cube iwork8 air tablet),
> and the swapping of the calling breaks things.
> 
> This breakage was likely not noticed in testing because on cherrytrail,
> currently chv_exec_gpio ends up disabling the gpio pins rather then
> setting them (this is fixed in the next patch in this patch-set).
> 
> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> places in the enum defining them, so that their (new) names match their
> actual use.
> 
> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Hans de Goede 
> Acked-by: Jani Nikula 
> ---
> Changes in v2:
> -Add a comment to the enum explaining that the assert/reassert names
>  are swapped in the spec

Pushed to dinq. Thanks for the patch.

I sucked in the changelog again. In the future please include it in
the actual commit message, cause that's how we like it.

> ---
>  drivers/gpu/drm/i915/intel_bios.h  | 12 +---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  4 ++--
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index 8405b5a..7e3545f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -46,14 +46,20 @@ struct edp_power_seq {
>   u16 t11_t12;
>  } __packed;
>  
> -/* MIPI Sequence Block definitions */
> +/*
> + * MIPI Sequence Block definitions
> + *
> + * Note the VBT spec has AssertReset / DeassertReset swapped from their
> + * usual naming, we use the proper names here to avoid confusion when
> + * reading the code.
> + */
>  enum mipi_seq {
>   MIPI_SEQ_END = 0,
> - MIPI_SEQ_ASSERT_RESET,
> + MIPI_SEQ_DEASSERT_RESET,/* Spec says MipiAssertResetPin */
>   MIPI_SEQ_INIT_OTP,
>   MIPI_SEQ_DISPLAY_ON,
>   MIPI_SEQ_DISPLAY_OFF,
> - MIPI_SEQ_DEASSERT_RESET,
> + MIPI_SEQ_ASSERT_RESET,  /* Spec says MipiDeassertResetPin */
>   MIPI_SEQ_BACKLIGHT_ON,  /* sequence block v2+ */
>   MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
>   MIPI_SEQ_TEAR_ON,   /* sequence block v2+ */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 0d8ff00..579d2f5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
>   */
>  
>  static const char * const seq_name[] = {
> - [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> + [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
>   [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
>   [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
>   [MIPI_SEQ_DISPLAY_OFF]  = "MIPI_SEQ_DISPLAY_OFF",
> - [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> + [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
>   [MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
>   [MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
>   [MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> -- 
> 2.9.3

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

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

[Chris Wilson]

On Wed, Dec 07, 2016 at 07:28:04PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The i915_gem_active stuff doesn't like a NULL ->retire hook, but
> the overlay code can set it to NULL. That obviously ends up oopsing.
> Fix it by setting the ->retire hook using init_request_active()
> so that it'll do the NULL->i915_gem_retire_noop conversion for us.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_overlay.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
> b/drivers/gpu/drm/i915/intel_overlay.c
> index 1cc963814224..786389dd5175 100644
> --- a/drivers/gpu/drm/i915/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/intel_overlay.c
> @@ -216,7 +216,7 @@ static void intel_overlay_submit_request(struct 
> intel_overlay *overlay,
>  {
>   GEM_BUG_ON(i915_gem_active_peek(>last_flip,
>   >i915->drm.struct_mutex));
> - overlay->last_flip.retire = retire;
> + init_request_active(>last_flip, retire);

Hmm, init, not reinit. The alternative is to use i915_gem_retire_noop
instead of NULL. (And sorry, it did used to allow NULL.)

overlay->last_flip.retire = retire ?= i915_gem_retire_noop;

Or i915_gem_active_set_retire_fn(>last_flip, retire);
That's seems like it should make everyone a bit happier.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay

[Chris Wilson]

On Wed, Dec 07, 2016 at 07:28:05PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We need an uninterruptible wait for the overlay off request during
> modeset. Restore the operation of dev_priv->mm.interruptible
> sufficiently for that.
> 
> Toss in a WARN_ON() to make sure the request succeeds.
> 
> Fixes: 7da844c5c6fc ("drm/i915: Move the special case wait-request handling 
> to its one caller")
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 36 
> +
>  drivers/gpu/drm/i915/i915_gem_request.h | 35 ++--
>  drivers/gpu/drm/i915/intel_display.c|  2 +-
>  3 files changed, 39 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index fcf22b0e2967..1a7b88166c51 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -1199,3 +1199,39 @@ void i915_gem_retire_requests(struct drm_i915_private 
> *dev_priv)
>   for_each_engine(engine, dev_priv, id)
>   engine_retire_requests(engine);
>  }
> +
> +/**
> + * i915_gem_active_retire - waits until the request is retired
> + * @active - the active request on which to wait
> + *
> + * i915_gem_active_retire() waits until the request is completed,
> + * and then ensures that at least the retirement handler for this
> + * @active tracker is called before returning. If the @active
> + * tracker is idle, the function returns immediately.
> + */
> +int __must_check
> +i915_gem_active_retire(struct i915_gem_active *active,
> +struct mutex *mutex)
> +{
> + struct drm_i915_gem_request *request;
> + long ret;
> +
> + request = i915_gem_active_raw(active, mutex);
> + if (!request)
> + return 0;
> +
> + ret = i915_wait_request(request,
> + (request->i915->mm.interruptible ?
> +  I915_WAIT_INTERRUPTIBLE : 0) |
> + I915_WAIT_LOCKED,
> + MAX_SCHEDULE_TIMEOUT);

At least pass in the flags.

> + if (ret < 0)
> + return ret;
> +
> + list_del_init(>link);
> + RCU_INIT_POINTER(active->request, NULL);
> +
> + active->retire(active, request);
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index e2b077df2da0..09add6b9cfc7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -657,39 +657,8 @@ i915_gem_active_wait(const struct i915_gem_active 
> *active, unsigned int flags)
>   return ret < 0 ? ret : 0;
>  }
>  
> -/**
> - * i915_gem_active_retire - waits until the request is retired
> - * @active - the active request on which to wait
> - *
> - * i915_gem_active_retire() waits until the request is completed,
> - * and then ensures that at least the retirement handler for this
> - * @active tracker is called before returning. If the @active
> - * tracker is idle, the function returns immediately.
> - */
> -static inline int __must_check
> -i915_gem_active_retire(struct i915_gem_active *active,
> -struct mutex *mutex)
> -{
> - struct drm_i915_gem_request *request;
> - long ret;
> -
> - request = i915_gem_active_raw(active, mutex);
> - if (!request)
> - return 0;
> -
> - ret = i915_wait_request(request,
> - I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
> - MAX_SCHEDULE_TIMEOUT);
> - if (ret < 0)
> - return ret;
> -
> - list_del_init(>link);
> - RCU_INIT_POINTER(active->request, NULL);
> -
> - active->retire(active, request);
> -
> - return 0;
> -}
> +int __must_check i915_gem_active_retire(struct i915_gem_active *active,
> + struct mutex *mutex);
>  
>  #define for_each_active(mask, idx) \
>   for (; mask ? idx = ffs(mask) - 1, 1 : 0; mask &= ~BIT(idx))
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a41082e2750e..5a74991854e3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4923,7 +4923,7 @@ static void intel_crtc_dpms_overlay_disable(struct 
> intel_crtc *intel_crtc)
>  
>   mutex_lock(>struct_mutex);
>   dev_priv->mm.interruptible = false;
> - (void) intel_overlay_switch_off(intel_crtc->overlay);
> + WARN_ON(intel_overlay_switch_off(intel_crtc->overlay) != 0);
>   dev_priv->mm.interruptible = true;
>   mutex_unlock(>struct_mutex);

Or we can push this wait to where it can interrupt, such 

[Intel-gfx] [PATCH 11/11] drm/i915: Kill the 830 MI_OVERLAY_OFF workaround

[ville . syrjala]

From: Ville Syrjälä 

Now that we're disabling L2 clock gating MI_OVERLAY_OFF actually works
on 830, so let's use it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 9e8bbaa53a22..bfc9fa41c04e 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -431,23 +431,17 @@ static int intel_overlay_off(struct intel_overlay 
*overlay)
}
 
ring = req->ring;
+
/* wait for overlay to go idle */
intel_ring_emit(ring, MI_OVERLAY_FLIP | MI_OVERLAY_CONTINUE);
intel_ring_emit(ring, flip_addr);
intel_ring_emit(ring, MI_WAIT_FOR_EVENT | MI_WAIT_FOR_OVERLAY_FLIP);
+
/* turn overlay off */
-   if (IS_I830(dev_priv)) {
-   /* Workaround: Don't disable the overlay fully, since otherwise
-* it dies on the next OVERLAY_ON cmd. */
-   intel_ring_emit(ring, MI_NOOP);
-   intel_ring_emit(ring, MI_NOOP);
-   intel_ring_emit(ring, MI_NOOP);
-   } else {
-   intel_ring_emit(ring, MI_OVERLAY_FLIP | MI_OVERLAY_OFF);
-   intel_ring_emit(ring, flip_addr);
-   intel_ring_emit(ring,
-   MI_WAIT_FOR_EVENT | MI_WAIT_FOR_OVERLAY_FLIP);
-   }
+   intel_ring_emit(ring, MI_OVERLAY_FLIP | MI_OVERLAY_OFF);
+   intel_ring_emit(ring, flip_addr);
+   intel_ring_emit(ring, MI_WAIT_FOR_EVENT | MI_WAIT_FOR_OVERLAY_FLIP);
+
intel_ring_advance(ring);
 
intel_overlay_flip_prepare(overlay, NULL);
-- 
2.7.4

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

[Intel-gfx] [PATCH 10/11] drm/i915: Disable L2 cache clock gating on 830 when using the overlay

[ville . syrjala]

From: Ville Syrjälä 

BSpec says:
"Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating
must be disabled in order to prevent device hangs when turning off overlay.SW
must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)."

We only turned off the overlay clock gating (due to lack of docs I
presume). After a bit of experimentation it looks like the the magic
C8h register lives in the PCI config space of device 0, and the magic
bit appears to be bit 2. Or at the very least this eliminates the GPU
death after MI_OVERLAY_OFF.

L2 clock gating seems to save ~80mW, so let's keep it on unless we need
to actually use the overlay.

Also let's move the OVRUNIT clock gating to the same place since we can,
and 845 supposedly doesn't need it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_overlay.c | 30 ++
 drivers/gpu/drm/i915/intel_pm.c  |  2 --
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 90685d235410..e077e40f5005 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -110,6 +110,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   GRDOM_RESET_STATUS   (1 << 1)
 #define   GRDOM_RESET_ENABLE   (1 << 0)
 
+/* BSpec only has register offset, PCI device and bit found empirically */
+#define I830_CLOCK_GATE0xc8 /* device 0 */
+#define   I830_L2_CACHE_CLOCK_GATE_DISABLE (1 << 2)
+
 #define GCDGMBUS 0xcc
 
 #define GCFGC2 0xda
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index bc113ebc475f..9e8bbaa53a22 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -187,6 +187,29 @@ struct intel_overlay {
struct i915_gem_active last_flip;
 };
 
+static void i830_overlay_clock_gating(struct drm_i915_private *dev_priv,
+ bool enable)
+{
+   struct pci_dev *pdev = dev_priv->drm.pdev;
+   u8 val;
+
+   /* WA_OVERLAY_CLKGATE:alm */
+   if (enable)
+   I915_WRITE(DSPCLK_GATE_D, 0);
+   else
+   I915_WRITE(DSPCLK_GATE_D, OVRUNIT_CLOCK_GATE_DISABLE);
+
+   /* WA_DISABLE_L2CACHE_CLOCK_GATING:alm */
+   pci_bus_read_config_byte(pdev->bus,
+PCI_DEVFN(0, 0), I830_CLOCK_GATE, );
+   if (enable)
+   val &= ~I830_L2_CACHE_CLOCK_GATE_DISABLE;
+   else
+   val |= I830_L2_CACHE_CLOCK_GATE_DISABLE;
+   pci_bus_write_config_byte(pdev->bus,
+ PCI_DEVFN(0, 0), I830_CLOCK_GATE, val);
+}
+
 static struct overlay_registers __iomem *
 intel_overlay_map_regs(struct intel_overlay *overlay)
 {
@@ -261,6 +284,9 @@ static int intel_overlay_on(struct intel_overlay *overlay)
 
overlay->active = true;
 
+   if (IS_I830(dev_priv))
+   i830_overlay_clock_gating(dev_priv, false);
+
ring = req->ring;
intel_ring_emit(ring, MI_OVERLAY_FLIP | MI_OVERLAY_ON);
intel_ring_emit(ring, overlay->flip_addr | OFC_UPDATE);
@@ -365,12 +391,16 @@ static void intel_overlay_off_tail(struct i915_gem_active 
*active,
 {
struct intel_overlay *overlay =
container_of(active, typeof(*overlay), last_flip);
+   struct drm_i915_private *dev_priv = overlay->i915;
 
intel_overlay_release_old_vma(overlay);
 
overlay->crtc->overlay = NULL;
overlay->crtc = NULL;
overlay->active = false;
+
+   if (IS_I830(dev_priv))
+   i830_overlay_clock_gating(dev_priv, true);
 }
 
 /* overlay needs to be disabled in OCMD reg */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3ea7cf275be0..fd09ae08d86f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7593,8 +7593,6 @@ static void i85x_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
 static void i830_init_clock_gating(struct drm_i915_private *dev_priv)
 {
-   I915_WRITE(DSPCLK_GATE_D, OVRUNIT_CLOCK_GATE_DISABLE);
-
I915_WRITE(MEM_MODE,
   _MASKED_BIT_ENABLE(MEM_DISPLAY_A_TRICKLE_FEED_DISABLE) |
   _MASKED_BIT_ENABLE(MEM_DISPLAY_B_TRICKLE_FEED_DISABLE));
-- 
2.7.4

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

[Intel-gfx] [PATCH 07/11] drm/i915: Simplify SWIDTHSW calculation

[ville . syrjala]

From: Ville Syrjälä 

The formula in Bspec for computing the overlay SWIDTHSW is overly
obfuscated. Simplify the formula to something that's easily parsed by
humans.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 10e8d3b9a0c4..19ff5d86f9f9 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -566,19 +566,17 @@ static int uv_vsubsampling(u32 format)
 
 static u32 calc_swidthsw(struct drm_i915_private *dev_priv, u32 offset, u32 
width)
 {
-   u32 mask, shift, ret;
-   if (IS_GEN2(dev_priv)) {
-   mask = 0x1f;
-   shift = 5;
-   } else {
-   mask = 0x3f;
-   shift = 6;
-   }
-   ret = ((offset + width + mask) >> shift) - (offset >> shift);
-   if (!IS_GEN2(dev_priv))
-   ret <<= 1;
-   ret -= 1;
-   return ret << 2;
+   u32 sw;
+
+   if (IS_GEN2(dev_priv))
+   sw = ALIGN((offset & 31) + width, 32);
+   else
+   sw = ALIGN((offset & 63) + width, 64);
+
+   if (sw == 0)
+   return 0;
+
+   return (sw - 32) >> 3;
 }
 
 static const u16 y_static_hcoeffs[N_HORIZ_Y_TAPS * N_PHASES] = {
-- 
2.7.4

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

[Intel-gfx] [PATCH 09/11] drm/i915: Use primary plane->state for overlay ckey setup

[ville . syrjala]

From: Ville Syrjälä 

Extract the primary plane pixel format via plane state when setting up
the overlay colorkey.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index e4420b08f3ab..bc113ebc475f 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -689,31 +689,32 @@ static bool update_scaling_factors(struct intel_overlay 
*overlay,
 static void update_colorkey(struct intel_overlay *overlay,
struct overlay_registers __iomem *regs)
 {
+   const struct intel_plane_state *state =
+   to_intel_plane_state(overlay->crtc->base.primary->state);
u32 key = overlay->color_key;
-   u32 flags;
+   u32 format = 0;
+   u32 flags = 0;
 
-   flags = 0;
if (overlay->color_key_enabled)
flags |= DST_KEY_ENABLE;
 
-   switch (overlay->crtc->base.primary->fb->bits_per_pixel) {
-   case 8:
+   if (state->base.visible)
+   format = state->base.fb->pixel_format;
+
+   switch (format) {
+   case DRM_FORMAT_C8:
key = 0;
flags |= CLK_RGB8I_MASK;
break;
-
-   case 16:
-   if (overlay->crtc->base.primary->fb->depth == 15) {
-   key = RGB15_TO_COLORKEY(key);
-   flags |= CLK_RGB15_MASK;
-   } else {
-   key = RGB16_TO_COLORKEY(key);
-   flags |= CLK_RGB16_MASK;
-   }
+   case DRM_FORMAT_XRGB1555:
+   key = RGB15_TO_COLORKEY(key);
+   flags |= CLK_RGB15_MASK;
break;
-
-   case 24:
-   case 32:
+   case DRM_FORMAT_RGB565:
+   key = RGB16_TO_COLORKEY(key);
+   flags |= CLK_RGB16_MASK;
+   break;
+   default:
flags |= CLK_RGB24_MASK;
break;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 08/11] drm/i915: Reorganize overlay filter coeffs into a nicer form

[ville . syrjala]

From: Ville Syrjälä 

Use two-dimensional arrays and named initializers to make the
overlay filter coefficient tables easier to parse for humans.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 64 
 1 file changed, 36 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 19ff5d86f9f9..e4420b08f3ab 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -579,36 +579,44 @@ static u32 calc_swidthsw(struct drm_i915_private 
*dev_priv, u32 offset, u32 widt
return (sw - 32) >> 3;
 }
 
-static const u16 y_static_hcoeffs[N_HORIZ_Y_TAPS * N_PHASES] = {
-   0x3000, 0xb4a0, 0x1930, 0x1920, 0xb4a0,
-   0x3000, 0xb500, 0x19d0, 0x1880, 0xb440,
-   0x3000, 0xb540, 0x1a88, 0x2f80, 0xb3e0,
-   0x3000, 0xb580, 0x1b30, 0x2e20, 0xb380,
-   0x3000, 0xb5c0, 0x1bd8, 0x2cc0, 0xb320,
-   0x3020, 0xb5e0, 0x1c60, 0x2b80, 0xb2c0,
-   0x3020, 0xb5e0, 0x1cf8, 0x2a20, 0xb260,
-   0x3020, 0xb5e0, 0x1d80, 0x28e0, 0xb200,
-   0x3020, 0xb5c0, 0x1e08, 0x3f40, 0xb1c0,
-   0x3020, 0xb580, 0x1e78, 0x3ce0, 0xb160,
-   0x3040, 0xb520, 0x1ed8, 0x3aa0, 0xb120,
-   0x3040, 0xb4a0, 0x1f30, 0x3880, 0xb0e0,
-   0x3040, 0xb400, 0x1f78, 0x3680, 0xb0a0,
-   0x3020, 0xb340, 0x1fb8, 0x34a0, 0xb060,
-   0x3020, 0xb240, 0x1fe0, 0x32e0, 0xb040,
-   0x3020, 0xb140, 0x1ff8, 0x3160, 0xb020,
-   0xb000, 0x3000, 0x0800, 0x3000, 0xb000
+static const u16 y_static_hcoeffs[N_PHASES][N_HORIZ_Y_TAPS] = {
+   [ 0] = { 0x3000, 0xb4a0, 0x1930, 0x1920, 0xb4a0, },
+   [ 1] = { 0x3000, 0xb500, 0x19d0, 0x1880, 0xb440, },
+   [ 2] = { 0x3000, 0xb540, 0x1a88, 0x2f80, 0xb3e0, },
+   [ 3] = { 0x3000, 0xb580, 0x1b30, 0x2e20, 0xb380, },
+   [ 4] = { 0x3000, 0xb5c0, 0x1bd8, 0x2cc0, 0xb320, },
+   [ 5] = { 0x3020, 0xb5e0, 0x1c60, 0x2b80, 0xb2c0, },
+   [ 6] = { 0x3020, 0xb5e0, 0x1cf8, 0x2a20, 0xb260, },
+   [ 7] = { 0x3020, 0xb5e0, 0x1d80, 0x28e0, 0xb200, },
+   [ 8] = { 0x3020, 0xb5c0, 0x1e08, 0x3f40, 0xb1c0, },
+   [ 9] = { 0x3020, 0xb580, 0x1e78, 0x3ce0, 0xb160, },
+   [10] = { 0x3040, 0xb520, 0x1ed8, 0x3aa0, 0xb120, },
+   [11] = { 0x3040, 0xb4a0, 0x1f30, 0x3880, 0xb0e0, },
+   [12] = { 0x3040, 0xb400, 0x1f78, 0x3680, 0xb0a0, },
+   [13] = { 0x3020, 0xb340, 0x1fb8, 0x34a0, 0xb060, },
+   [14] = { 0x3020, 0xb240, 0x1fe0, 0x32e0, 0xb040, },
+   [15] = { 0x3020, 0xb140, 0x1ff8, 0x3160, 0xb020, },
+   [16] = { 0xb000, 0x3000, 0x0800, 0x3000, 0xb000, },
 };
 
-static const u16 uv_static_hcoeffs[N_HORIZ_UV_TAPS * N_PHASES] = {
-   0x3000, 0x1800, 0x1800, 0xb000, 0x18d0, 0x2e60,
-   0xb000, 0x1990, 0x2ce0, 0xb020, 0x1a68, 0x2b40,
-   0xb040, 0x1b20, 0x29e0, 0xb060, 0x1bd8, 0x2880,
-   0xb080, 0x1c88, 0x3e60, 0xb0a0, 0x1d28, 0x3c00,
-   0xb0c0, 0x1db8, 0x39e0, 0xb0e0, 0x1e40, 0x37e0,
-   0xb100, 0x1eb8, 0x3620, 0xb100, 0x1f18, 0x34a0,
-   0xb100, 0x1f68, 0x3360, 0xb0e0, 0x1fa8, 0x3240,
-   0xb0c0, 0x1fe0, 0x3140, 0xb060, 0x1ff0, 0x30a0,
-   0x3000, 0x0800, 0x3000
+static const u16 uv_static_hcoeffs[N_PHASES][N_HORIZ_UV_TAPS] = {
+   [ 0] = { 0x3000, 0x1800, 0x1800, },
+   [ 1] = { 0xb000, 0x18d0, 0x2e60, },
+   [ 2] = { 0xb000, 0x1990, 0x2ce0, },
+   [ 3] = { 0xb020, 0x1a68, 0x2b40, },
+   [ 4] = { 0xb040, 0x1b20, 0x29e0, },
+   [ 5] = { 0xb060, 0x1bd8, 0x2880, },
+   [ 6] = { 0xb080, 0x1c88, 0x3e60, },
+   [ 7] = { 0xb0a0, 0x1d28, 0x3c00, },
+   [ 8] = { 0xb0c0, 0x1db8, 0x39e0, },
+   [ 9] = { 0xb0e0, 0x1e40, 0x37e0, },
+   [10] = { 0xb100, 0x1eb8, 0x3620, },
+   [11] = { 0xb100, 0x1f18, 0x34a0, },
+   [12] = { 0xb100, 0x1f68, 0x3360, },
+   [13] = { 0xb0e0, 0x1fa8, 0x3240, },
+   [14] = { 0xb0c0, 0x1fe0, 0x3140, },
+   [15] = { 0xb060, 0x1ff0, 0x30a0, },
+   [16] = { 0x3000, 0x0800, 0x3000, },
 };
 
 static void update_polyphase_filter(struct overlay_registers __iomem *regs)
-- 
2.7.4

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

[Intel-gfx] [PATCH 01/11] drm/i915: Fix oops in overlay due to frontbuffer trakcing

[ville . syrjala]

From: Ville Syrjälä 

The vma will be NULL if the overlay was previously off, so
dereferencing it will oops. Check for NULL before doing that.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Fixes: 9b3b7841b86d ("drm/i915/overlay: Use VMA as the primary tracker for 
images")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 354f8cec96bb..1cc963814224 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -839,8 +839,8 @@ static int intel_overlay_do_put_image(struct intel_overlay 
*overlay,
if (ret)
goto out_unpin;
 
-   i915_gem_track_fb(overlay->vma->obj, new_bo,
- INTEL_FRONTBUFFER_OVERLAY(pipe));
+   i915_gem_track_fb(overlay->vma ? overlay->vma->obj : NULL,
+ vma->obj, INTEL_FRONTBUFFER_OVERLAY(pipe));
 
overlay->old_vma = overlay->vma;
overlay->vma = vma;
-- 
2.7.4

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

[Intel-gfx] [PATCH 04/11] drm/i915: Fix the overlay frontbuffer tracking

[ville . syrjala]

From: Ville Syrjälä 

Do the overlay frontbuffer tracking properly so that it matches
the state of the overlay on/off/continue requests.

One slight problem is that intel_frontbuffer_flip_complete()
may get delayed by an arbitrarily liong time due to the fact that
the overlay code likes to bail out when a signal occurs. So the
flip may not get completed until the ioctl is restarted. But fixing
that would require bigger surgery, so I decided to ignore it for now.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 64 +++-
 1 file changed, 41 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 786389dd5175..0c5e82beda4a 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -271,8 +271,30 @@ static int intel_overlay_on(struct intel_overlay *overlay)
return intel_overlay_do_wait_request(overlay, req, NULL);
 }
 
+static void intel_overlay_flip_prepare(struct intel_overlay *overlay,
+  struct i915_vma *vma)
+{
+   enum pipe pipe = overlay->crtc->pipe;
+
+   WARN_ON(overlay->old_vma);
+
+   i915_gem_track_fb(overlay->vma ? overlay->vma->obj : NULL,
+ vma ? vma->obj : NULL,
+ INTEL_FRONTBUFFER_OVERLAY(pipe));
+
+   intel_frontbuffer_flip_prepare(overlay->i915,
+  INTEL_FRONTBUFFER_OVERLAY(pipe));
+
+   overlay->old_vma = overlay->vma;
+   if (vma)
+   overlay->vma = i915_vma_get(vma);
+   else
+   overlay->vma = NULL;
+}
+
 /* overlay needs to be enabled in OCMD reg */
 static int intel_overlay_continue(struct intel_overlay *overlay,
+ struct i915_vma *vma,
  bool load_polyphase_filter)
 {
struct drm_i915_private *dev_priv = overlay->i915;
@@ -307,43 +329,44 @@ static int intel_overlay_continue(struct intel_overlay 
*overlay,
intel_ring_emit(ring, flip_addr);
intel_ring_advance(ring);
 
+   intel_overlay_flip_prepare(overlay, vma);
+
intel_overlay_submit_request(overlay, req, NULL);
 
return 0;
 }
 
-static void intel_overlay_release_old_vid_tail(struct i915_gem_active *active,
-  struct drm_i915_gem_request *req)
+static void intel_overlay_release_old_vma(struct intel_overlay *overlay)
 {
-   struct intel_overlay *overlay =
-   container_of(active, typeof(*overlay), last_flip);
struct i915_vma *vma;
 
vma = fetch_and_zero(>old_vma);
if (WARN_ON(!vma))
return;
 
-   i915_gem_track_fb(vma->obj, NULL,
- INTEL_FRONTBUFFER_OVERLAY(overlay->crtc->pipe));
+   intel_frontbuffer_flip_complete(overlay->i915,
+   
INTEL_FRONTBUFFER_OVERLAY(overlay->crtc->pipe));
 
i915_gem_object_unpin_from_display_plane(vma);
i915_vma_put(vma);
 }
 
+static void intel_overlay_release_old_vid_tail(struct i915_gem_active *active,
+  struct drm_i915_gem_request *req)
+{
+   struct intel_overlay *overlay =
+   container_of(active, typeof(*overlay), last_flip);
+
+   intel_overlay_release_old_vma(overlay);
+}
+
 static void intel_overlay_off_tail(struct i915_gem_active *active,
   struct drm_i915_gem_request *req)
 {
struct intel_overlay *overlay =
container_of(active, typeof(*overlay), last_flip);
-   struct i915_vma *vma;
 
-   /* never have the overlay hw on without showing a frame */
-   vma = fetch_and_zero(>vma);
-   if (WARN_ON(!vma))
-   return;
-
-   i915_gem_object_unpin_from_display_plane(vma);
-   i915_vma_put(vma);
+   intel_overlay_release_old_vma(overlay);
 
overlay->crtc->overlay = NULL;
overlay->crtc = NULL;
@@ -397,6 +420,8 @@ static int intel_overlay_off(struct intel_overlay *overlay)
}
intel_ring_advance(ring);
 
+   intel_overlay_flip_prepare(overlay, NULL);
+
return intel_overlay_do_wait_request(overlay, req,
 intel_overlay_off_tail);
 }
@@ -835,18 +860,10 @@ static int intel_overlay_do_put_image(struct 
intel_overlay *overlay,
 
intel_overlay_unmap_regs(overlay, regs);
 
-   ret = intel_overlay_continue(overlay, scale_changed);
+   ret = intel_overlay_continue(overlay, vma, scale_changed);
if (ret)
goto out_unpin;
 
-   i915_gem_track_fb(overlay->vma ? overlay->vma->obj : NULL,
- vma->obj, INTEL_FRONTBUFFER_OVERLAY(pipe));
-
-   overlay->old_vma = overlay->vma;
-   overlay->vma = vma;
-
-   

[Intel-gfx] [PATCH 05/11] drm/i915: Use pipe_src_w in overlay code

[ville . syrjala]

From: Ville Syrjälä 

Replace the use of crtc->mode.h/vdisplay with the more appropriate
config->pipe_src_w/h.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 0c5e82beda4a..638933bfd8a0 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -937,12 +937,13 @@ static void update_pfit_vscale_ratio(struct intel_overlay 
*overlay)
 static int check_overlay_dst(struct intel_overlay *overlay,
 struct drm_intel_overlay_put_image *rec)
 {
-   struct drm_display_mode *mode = >crtc->base.mode;
+   const struct intel_crtc_state *pipe_config =
+   overlay->crtc->config;
 
-   if (rec->dst_x < mode->hdisplay &&
-   rec->dst_x + rec->dst_width <= mode->hdisplay &&
-   rec->dst_y < mode->vdisplay &&
-   rec->dst_y + rec->dst_height <= mode->vdisplay)
+   if (rec->dst_x < pipe_config->pipe_src_w &&
+   rec->dst_x + rec->dst_width <= pipe_config->pipe_src_w &&
+   rec->dst_y < pipe_config->pipe_src_h &&
+   rec->dst_y + rec->dst_height <= pipe_config->pipe_src_h)
return 0;
else
return -EINVAL;
@@ -1162,7 +1163,6 @@ int intel_overlay_put_image_ioctl(struct drm_device *dev, 
void *data,
goto out_unlock;
 
if (overlay->crtc != crtc) {
-   struct drm_display_mode *mode = >base.mode;
ret = intel_overlay_switch_off(overlay);
if (ret != 0)
goto out_unlock;
@@ -1175,7 +1175,7 @@ int intel_overlay_put_image_ioctl(struct drm_device *dev, 
void *data,
crtc->overlay = overlay;
 
/* line too wide, i.e. one-line-mode */
-   if (mode->hdisplay > 1024 &&
+   if (crtc->config->pipe_src_w > 1024 &&
intel_panel_fitter_pipe(dev_priv) == crtc->pipe) {
overlay->pfit_active = true;
update_pfit_vscale_ratio(overlay);
-- 
2.7.4

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

[Intel-gfx] [PATCH 06/11] drm/i915: Kill intel_panel_fitter_pipe()

[ville . syrjala]

From: Ville Syrjälä 

Check pipe config gmch_pfit.control instead of using intel_panel_fitter_pipe()
to figure out if the pipe for the overlay is using the panel fitter.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 29 +
 1 file changed, 1 insertion(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 638933bfd8a0..10e8d3b9a0c4 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -1075,33 +1075,6 @@ static int check_overlay_src(struct drm_i915_private 
*dev_priv,
return 0;
 }
 
-/**
- * Return the pipe currently connected to the panel fitter,
- * or -1 if the panel fitter is not present or not in use
- */
-static int intel_panel_fitter_pipe(struct drm_i915_private *dev_priv)
-{
-   u32  pfit_control;
-
-   /* i830 doesn't have a panel fitter */
-   if (INTEL_GEN(dev_priv) <= 3 &&
-   (IS_I830(dev_priv) || !IS_MOBILE(dev_priv)))
-   return -1;
-
-   pfit_control = I915_READ(PFIT_CONTROL);
-
-   /* See if the panel fitter is in use */
-   if ((pfit_control & PFIT_ENABLE) == 0)
-   return -1;
-
-   /* 965 can place panel fitter on either pipe */
-   if (IS_GEN4(dev_priv))
-   return (pfit_control >> 29) & 0x3;
-
-   /* older chips can only use pipe 1 */
-   return 1;
-}
-
 int intel_overlay_put_image_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
 {
@@ -1176,7 +1149,7 @@ int intel_overlay_put_image_ioctl(struct drm_device *dev, 
void *data,
 
/* line too wide, i.e. one-line-mode */
if (crtc->config->pipe_src_w > 1024 &&
-   intel_panel_fitter_pipe(dev_priv) == crtc->pipe) {
+   crtc->config->gmch_pfit.control & PFIT_ENABLE) {
overlay->pfit_active = true;
update_pfit_vscale_ratio(overlay);
} else
-- 
2.7.4

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

[Intel-gfx] [PATCH 03/11] drm/i915: Restore dev_priv->mm.interruptible for overlay

[ville . syrjala]

From: Ville Syrjälä 

We need an uninterruptible wait for the overlay off request during
modeset. Restore the operation of dev_priv->mm.interruptible
sufficiently for that.

Toss in a WARN_ON() to make sure the request succeeds.

Fixes: 7da844c5c6fc ("drm/i915: Move the special case wait-request handling to 
its one caller")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 36 +
 drivers/gpu/drm/i915/i915_gem_request.h | 35 ++--
 drivers/gpu/drm/i915/intel_display.c|  2 +-
 3 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index fcf22b0e2967..1a7b88166c51 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1199,3 +1199,39 @@ void i915_gem_retire_requests(struct drm_i915_private 
*dev_priv)
for_each_engine(engine, dev_priv, id)
engine_retire_requests(engine);
 }
+
+/**
+ * i915_gem_active_retire - waits until the request is retired
+ * @active - the active request on which to wait
+ *
+ * i915_gem_active_retire() waits until the request is completed,
+ * and then ensures that at least the retirement handler for this
+ * @active tracker is called before returning. If the @active
+ * tracker is idle, the function returns immediately.
+ */
+int __must_check
+i915_gem_active_retire(struct i915_gem_active *active,
+  struct mutex *mutex)
+{
+   struct drm_i915_gem_request *request;
+   long ret;
+
+   request = i915_gem_active_raw(active, mutex);
+   if (!request)
+   return 0;
+
+   ret = i915_wait_request(request,
+   (request->i915->mm.interruptible ?
+I915_WAIT_INTERRUPTIBLE : 0) |
+   I915_WAIT_LOCKED,
+   MAX_SCHEDULE_TIMEOUT);
+   if (ret < 0)
+   return ret;
+
+   list_del_init(>link);
+   RCU_INIT_POINTER(active->request, NULL);
+
+   active->retire(active, request);
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index e2b077df2da0..09add6b9cfc7 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -657,39 +657,8 @@ i915_gem_active_wait(const struct i915_gem_active *active, 
unsigned int flags)
return ret < 0 ? ret : 0;
 }
 
-/**
- * i915_gem_active_retire - waits until the request is retired
- * @active - the active request on which to wait
- *
- * i915_gem_active_retire() waits until the request is completed,
- * and then ensures that at least the retirement handler for this
- * @active tracker is called before returning. If the @active
- * tracker is idle, the function returns immediately.
- */
-static inline int __must_check
-i915_gem_active_retire(struct i915_gem_active *active,
-  struct mutex *mutex)
-{
-   struct drm_i915_gem_request *request;
-   long ret;
-
-   request = i915_gem_active_raw(active, mutex);
-   if (!request)
-   return 0;
-
-   ret = i915_wait_request(request,
-   I915_WAIT_INTERRUPTIBLE | I915_WAIT_LOCKED,
-   MAX_SCHEDULE_TIMEOUT);
-   if (ret < 0)
-   return ret;
-
-   list_del_init(>link);
-   RCU_INIT_POINTER(active->request, NULL);
-
-   active->retire(active, request);
-
-   return 0;
-}
+int __must_check i915_gem_active_retire(struct i915_gem_active *active,
+   struct mutex *mutex);
 
 #define for_each_active(mask, idx) \
for (; mask ? idx = ffs(mask) - 1, 1 : 0; mask &= ~BIT(idx))
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a41082e2750e..5a74991854e3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4923,7 +4923,7 @@ static void intel_crtc_dpms_overlay_disable(struct 
intel_crtc *intel_crtc)
 
mutex_lock(>struct_mutex);
dev_priv->mm.interruptible = false;
-   (void) intel_overlay_switch_off(intel_crtc->overlay);
+   WARN_ON(intel_overlay_switch_off(intel_crtc->overlay) != 0);
dev_priv->mm.interruptible = true;
mutex_unlock(>struct_mutex);
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 02/11] drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

[ville . syrjala]

From: Ville Syrjälä 

The i915_gem_active stuff doesn't like a NULL ->retire hook, but
the overlay code can set it to NULL. That obviously ends up oopsing.
Fix it by setting the ->retire hook using init_request_active()
so that it'll do the NULL->i915_gem_retire_noop conversion for us.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 1cc963814224..786389dd5175 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -216,7 +216,7 @@ static void intel_overlay_submit_request(struct 
intel_overlay *overlay,
 {
GEM_BUG_ON(i915_gem_active_peek(>last_flip,
>i915->drm.struct_mutex));
-   overlay->last_flip.retire = retire;
+   init_request_active(>last_flip, retire);
i915_gem_active_set(>last_flip, req);
i915_add_request(req);
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH 00/11] drm/i915: Overlay fixes

[ville . syrjala]

From: Ville Syrjälä 

Fixes for some recentish regressions in the overlay support (kernel
would oops as soon as you try to use the overlay), and I decided to
dig up a few older cleanups and fixes I had lying around in my
gen2 dungeon.

Entire series (with Chris's phys obj fix) here:
git://github.com/vsyrjala/linux.git overlay_fixes

Ville Syrjälä (11):
  drm/i915: Fix oops in overlay due to frontbuffer trakcing
  drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff
  drm/i915: Restore dev_priv->mm.interruptible for overlay
  drm/i915: Fix the overlay frontbuffer tracking
  drm/i915: Use pipe_src_w in overlay code
  drm/i915: Kill intel_panel_fitter_pipe()
  drm/i915: Simplify SWIDTHSW calculation
  drm/i915: Reorganize overlay filter coeffs into a nicer form
  drm/i915: Use primary plane->state for overlay ckey setup
  drm/i915: Disable L2 cache clock gating on 830 when using the overlay
  drm/i915: Kill the 830 MI_OVERLAY_OFF workaround

 drivers/gpu/drm/i915/i915_gem_request.c |  36 +
 drivers/gpu/drm/i915/i915_gem_request.h |  35 +---
 drivers/gpu/drm/i915/i915_reg.h |   4 +
 drivers/gpu/drm/i915/intel_display.c|   2 +-
 drivers/gpu/drm/i915/intel_overlay.c| 278 +---
 drivers/gpu/drm/i915/intel_pm.c |   2 -
 6 files changed, 193 insertions(+), 164 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v2] dim: Try git-merge --ff-only before git-rebase -i when updating branches.

[Maarten Lankhorst]

Op 07-12-16 om 10:33 schreef Jani Nikula:
> On Tue, 06 Dec 2016, Maarten Lankhorst  
> wrote:
>> When a branch can be fast-forwarded, try it first before rebasing.
>> This will prevent a whole lot of editor windows opening with 'noop'
>> when running dim ub.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  dim | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/dim b/dim
>> index fa63ae8c8a79..b2e6841e23d7 100755
>> --- a/dim
>> +++ b/dim
>> @@ -1286,9 +1286,7 @@ function dim_update_branches
>>  repo=`branch_to_repo $branch`
>>  remote=`repo_to_remote $repo`
>>  
>> -if git diff --quiet $remote/$branch; then
>> -$DRY git rebase
>> -else
>> +if ! $DRY git merge --ff-only ; then
> What does it assume for branches to merge when none are provided? Would
> it be better to be explicit?
>
> Thanks for this, I've been meaning to do this forever...

Hm I guess explicit might be better, what about this?
--8<---
When a branch can be fast-forwarded, try it first before rebasing.
This will prevent a whole lot of editor windows opening with 'noop'
when running dim ub.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/dim b/dim
index fa63ae8c8a79..e0551ace54e4 100755
--- a/dim
+++ b/dim
@@ -1286,9 +1286,7 @@ function dim_update_branches
repo=`branch_to_repo $branch`
remote=`repo_to_remote $repo`
 
-   if git diff --quiet $remote/$branch; then
-   $DRY git rebase
-   else
+   if ! $DRY git merge --ff-only $remote/$branch; then
$DRY git rebase -i
fi
done

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: make Pineview a platform of its own

[Patchwork]

== Series Details ==

Series: drm/i915: make Pineview a platform of its own
URL   : https://patchwork.freedesktop.org/series/16490/
State : warning

== Summary ==

Series 16490v1 drm/i915: make Pineview a platform of its own
https://patchwork.freedesktop.org/api/1.0/series/16490/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:247  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bsw-n3050 total:247  pass:195  dwarn:0   dfail:0   fail:0   skip:52 
fi-byt-j1900 total:247  pass:206  dwarn:0   dfail:0   fail:0   skip:41 
fi-byt-n2820 total:247  pass:202  dwarn:0   dfail:0   fail:0   skip:45 
fi-hsw-4770  total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-hsw-4770r total:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-ilk-650   total:247  pass:181  dwarn:0   dfail:0   fail:0   skip:66 
fi-ivb-3520m total:247  pass:213  dwarn:0   dfail:0   fail:0   skip:34 
fi-ivb-3770  total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-kbl-7500u total:247  pass:212  dwarn:0   dfail:0   fail:0   skip:35 
fi-skl-6260u total:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-skl-6700hqtotal:247  pass:214  dwarn:0   dfail:0   fail:0   skip:33 
fi-skl-6700k total:247  pass:210  dwarn:3   dfail:0   fail:0   skip:34 
fi-skl-6770hqtotal:247  pass:220  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2520m total:247  pass:201  dwarn:1   dfail:0   fail:0   skip:45 
fi-snb-2600  total:247  pass:201  dwarn:0   dfail:0   fail:0   skip:46 

a20a4a6107256124d136c8320fc3f7adef93bb8a drm-tip: 2016y-12m-07d-15h-56m-01s UTC 
integration manifest
8b8c20d drm/i915: make Pineview a platform of its own

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3218/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] intel-ci: Do module loads first + last

[Chris Wilson]

Do the module reload test first, so that it has the best chance of
succeeding without outside influence (broken driver). And then do it
last, so that it has the best chance of catching some missing
finalisation (e.g. memleak) over the lifetime of the testing.

Signed-off-by: Chris Wilson 
Cc: Petri Latvala 
---
 tests/intel-ci/fast-feedback.testlist | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index e25facf3..b79b0c14 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -1,11 +1,10 @@
+igt@drv_module_reload@basic-reload
+igt@drv_module_reload@basic-reload-inject
 igt@core_auth@basic-auth
 igt@core_prop_blob@basic
 igt@drv_getparams_basic@basic-eu-total
 igt@drv_getparams_basic@basic-subslice-total
 igt@drv_hangman@error-state-basic
-igt@drv_module_reload@basic-reload
-igt@drv_module_reload@basic-reload-inject
-igt@drv_module_reload@basic-reload-final
 igt@gem_basic@bad-close
 igt@gem_basic@create-close
 igt@gem_basic@create-fd-close
@@ -245,3 +244,4 @@ igt@vgem_basic@mmap
 igt@vgem_basic@second-client
 igt@vgem_basic@sysfs
 igt@vgem_basic@unload
+igt@drv_module_reload@basic-reload-final # keep last
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove instructions to file a bug report.

[Daniel Vetter]

On Mon, Dec 05, 2016 at 04:55:47PM -0800, Matt Turner wrote:
> On Sat, Dec 3, 2016 at 1:52 AM, Jani Nikula  
> wrote:
> > On Sat, 03 Dec 2016, Matt Turner  wrote:
> >> From these instructions, users assume that /sys/class/drm/card0/error
> >> contains all the information a developer needs to diagnose and fix a GPU
> >> hang.
> >>
> >> In fact it doesn't, and we have no tools for solving them (other than
> >> stabbing in the dark). Most of the time the error state itself isn't
> >> even useful because it just shows a hang on a PIPE_CONTROL or similar.
> >>
> >> Until a time when the error state contains enough information to
> >> actually solve a hang, stop telling users to file unsolvable bugs, and
> >> instead rely on users who know where and how to file a good bug report
> >> to find their own way there.
> >>
> >> Signed-off-by: Matt Turner 
> >> ---
> >> Maybe now's a good time to discuss what *would* be useful to put in the
> >> error state for debugging hangs. The currently executing shader program
> >> would be a great place to start.
> >
> > I'm wondering why we're getting this patch now, and my guess is that
> > it's because we have been reassigning the related bugs to Mesa more
> > actively lately. Is that the case?
> 
> No, it's simply because I spent a week going through Bugzilla and
> realized how incomplete an unactionable the majority of GPU hang
> reports are.
> 
> Asking users to report bugs, but not telling them what actually
> constitutes a bug report, is a recipe for a lot of wasted developer
> time.
> 
> I suspect we could improve the usefulness of the reports by directing
> users to a webpage that gave a few suggestions (tell us what you were
> doing when the hang occurred would be an obvious one) about filing a
> bug and then provided a link to Bugzilla. Or even configured Bugzilla
> to have a default template that requested various bits of information.

I think dumping at least some of the aux buffers should make this tons
more useful for mesa, since it would indicate stuff like "we always die on
resolves on skl gt4" or stuff like that. Thus far error states have been
mostly used by kernel folks to debug kernel issues, which is why none of
that additional stuff gets dumped.

But a bare-bones parser to hunt for indirect state base addresses and fish
out the aux stuff shouldn't be that hard, and might make this fully
useful.

Like Chris said the goal is to at least be able to triage and classify
bugs, and I'm perfectly fine with merging additional code to the dumper to
get there for mesa folks. We z-compress the state, so size isn't really an
issue. And Ben has commit rights, so shouldn't be a problem to get this
all merged.

> > IIUC the bug reports are useful for us when it's a kernel bug, but less
> > useful for you when it's a Mesa bug. And you'd rather have fewer
> > incoming bugs that you think are unsolvable with the information at
> > hand.
> >
> > Sounds like a bug workflow issue between drm/i915 and Mesa to be ironed
> > out.
> 
> Indeed. I'd rather have the information provided in a bug report to
> actually solve it. I hope having access to the shader program will
> make many more reports useful.
> 
> I am also happy to see that there's now a sunset to the GPU hang message.

The other option is that mesa folks don't want error states that we triage
to mesa. We could definitely update the process in that area.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx