date:20170207

[Intel-gfx] [PATCH i-g-t] lib/igt_gt: Define HANG_ALLOW_* as bit flags

2017-02-07 Thread Michel Thierry

As that is what they are meant to be. It will prevent any confusion if we
have to add other flags in the future.

Signed-off-by: Michel Thierry 
---
 lib/igt_gt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index e44b6db1..d83e23a1 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -45,8 +45,8 @@ igt_hang_t igt_hang_ctx(int fd,
int ring,
unsigned flags,
uint64_t *offset);
-#define HANG_ALLOW_BAN 1
-#define HANG_ALLOW_CAPTURE 2
+#define HANG_ALLOW_BAN (1<<0)
+#define HANG_ALLOW_CAPTURE (1<<1)
 
 igt_hang_t igt_hang_ring(int fd, int ring);
 void igt_post_hang_ring(int fd, igt_hang_t arg);
-- 
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/i915/dp: Reset the link params on HPD/connected boot/resume

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915/dp: Reset the link params on HPD/connected boot/resume
URL   : https://patchwork.freedesktop.org/series/19277/
State : success

== Summary ==

Series 19277v1 drm/i915/dp: Reset the link params on HPD/connected boot/resume
https://patchwork.freedesktop.org/api/1.0/series/19277/revisions/1/mbox/


fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

7f1b128ee8d8cdd07a558d77e914dd99cc641b0f drm-tip: 2017y-02m-07d-21h-44m-07s UTC 
integration manifest
24e13a9 drm/i915/dp: Reset the link params on HPD/connected boot/resume

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/dp: Reset the link params on HPD/connected boot/resume

2017-02-07 Thread Manasi Navare

The max link parameters should be set/reset only on HPD or
connected boot case or on system resume.

Add a flag reset_link_params to intel_dp to decide when
to reset the max link parameters. This prevents the parameters
from getting reset/overwritten through all other
connector->funcs->detect() calls. This is important when link
training fails and the max link params are modified to the
lower fallback values.

Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 16 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 21924cf..ed28788b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4624,11 +4624,15 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
  yesno(intel_dp_source_supports_hbr2(intel_dp)),
  yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
 
-   /* Set the max lane count for sink */
-   intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+   if (intel_dp->reset_link_params) {
+   /* Set the max lane count for sink */
+   intel_dp->max_sink_lane_count = 
drm_dp_max_lane_count(intel_dp->dpcd);
 
-   /* Set the max link BW for sink */
-   intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
+   /* Set the max link BW for sink */
+   intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
+
+   intel_dp->reset_link_params = false;
+   }
 
intel_dp_print_rates(intel_dp);
 
@@ -5010,6 +5014,8 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
if (lspcon->active)
lspcon_resume(lspcon);
 
+   intel_dp->reset_link_params = true;
+
pps_lock(intel_dp);
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
@@ -5079,6 +5085,7 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  long_hpd ? "long" : "short");
 
if (long_hpd) {
+   intel_dp->reset_link_params = true;
intel_dp->detect_done = false;
return IRQ_NONE;
}
@@ -5920,6 +5927,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 intel_dig_port->max_lanes, port_name(port)))
return false;
 
+   intel_dp->reset_link_params = true;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fbe5c72..f579776 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -923,6 +923,7 @@ struct intel_dp {
bool has_audio;
bool detect_done;
bool channel_eq_status;
+   bool reset_link_params;
enum hdmi_force_audio force_audio;
bool limited_color_range;
bool color_range_auto;
-- 
2.1.4

___
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/dp: Clean up/Get rid of detect_done flag

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915/dp: Clean up/Get rid of detect_done flag
URL   : https://patchwork.freedesktop.org/series/19276/
State : success

== Summary ==

Series 19276v1 drm/i915/dp: Clean up/Get rid of detect_done flag
https://patchwork.freedesktop.org/api/1.0/series/19276/revisions/1/mbox/


fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

7f1b128ee8d8cdd07a558d77e914dd99cc641b0f drm-tip: 2017y-02m-07d-21h-44m-07s UTC 
integration manifest
1525b8b drm/i915/dp: Clean up/Get rid of detect_done flag

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Emil Velikov

On 7 February 2017 at 14:49, Chris Wilson  wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
>> On 7 February 2017 at 14:29, Daniel Vetter  wrote:
>> > Noticed that everyone duplicates the same logic here and we could safe
>> > a few lines per driver. Yay for lots of drivers to make such tiny
>> > refactors worth-while!
>> >
>> > v2: Forgot to git add everything :(
>> >
>> Hmm afaict this patch inlines drm_fb_helper_release_fbi within
>> drm_fb_helper_fini yet it is missing:
>>  - removal of the (now unused ?) drm_fb_helper_release_fbi
>>  - the leaks which now occur in the error paths.
>
> The error cleanup is a bit unobvious. The fbi is allocated during the
> create/initial_fb callback, which is after a successful
> framebuffer_init. The caller must be prepared to do a framebuffer_fini
> (and so release_fbi will be handled if required) on failure or success.
Silly me was assuming that drm_fb_helper_init() executes the fb_probe
callback, while in fact it is drm_fb_helper_initial_config() that does
so.
I should read the docs more carefully ;-)

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

[Intel-gfx] [PATCH] drm/i915/dp: Clean up/Get rid of detect_done flag

2017-02-07 Thread Manasi Navare

Detect_done flag was added previously when intel_dp_long_pulse
was called from multiple places. However now it is called only
from intel_dp_detect(). So this flag becomes redundant.
Anyway now, we set this to false right away after intel_dp_long_pulse
so it calls long pulse handler always for all calls to .detect()

Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 10 +-
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 21924cf..2a2aaa3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4667,7 +4667,6 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp_set_edid(intel_dp);
if (is_edp(intel_dp) || intel_connector->detect_edid)
status = connector_status_connected;
-   intel_dp->detect_done = true;
 
/* Try to read the source of the interrupt */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
@@ -4701,11 +4700,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
 
-   /* If full detect is not performed yet, do a full detect */
-   if (!intel_dp->detect_done)
-   status = intel_dp_long_pulse(intel_dp->attached_connector);
-
-   intel_dp->detect_done = false;
+   status = intel_dp_long_pulse(intel_dp->attached_connector);
 
return status;
 }
@@ -5079,7 +5074,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  long_hpd ? "long" : "short");
 
if (long_hpd) {
-   intel_dp->detect_done = false;
return IRQ_NONE;
}
 
@@ -5097,14 +5091,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
intel_dp->is_mst = false;
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
-   intel_dp->detect_done = false;
goto put_power;
}
}
 
if (!intel_dp->is_mst) {
if (!intel_dp_short_pulse(intel_dp)) {
-   intel_dp->detect_done = false;
goto put_power;
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fbe5c72..ec264e5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -921,7 +921,6 @@ struct intel_dp {
uint8_t sink_count;
bool link_mst;
bool has_audio;
-   bool detect_done;
bool channel_eq_status;
enum hdmi_force_audio force_audio;
bool limited_color_range;
-- 
2.1.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Move calling engine->init_hw() to its own function

2017-02-07 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915: Move calling engine->init_hw() to 
its own function
URL   : https://patchwork.freedesktop.org/series/19263/
State : success

== Summary ==

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


fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

7f1b128ee8d8cdd07a558d77e914dd99cc641b0f drm-tip: 2017y-02m-07d-21h-44m-07s UTC 
integration manifest
92cda5a drm/i915: Move calling engine->init_hw() to its own function

== Logs ==

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

[Intel-gfx] linux-firmware pull request (bxt guc,huc; kbl guc,huc; skl huc)

2017-02-07 Thread Srivatsa, Anusha

Hi,

Please consider pulling i915 updates to linux-firmware.git.

The following changes since commit 6d3bc8886517d171068fd1263176b8b5c51df204:

  Fix permissions on ti-connectivity firmware from 05e9fe59 (2017-01-13 
10:14:07 -0500)

are available in the git repository at:

  https://github.com/anushasr/linux-firmware.git master

for you to fetch changes up to d7fe1272a38777a41ce9d1df80f58ace2d9e3d27:

  linux-firmware/i915: GuC firmware for Kabylake v9.14 (2017-02-07 11:48:05 
-0800)


Anusha Srivatsa (5):
  linux-firmware/i915: Add HuC 1.07.1398 for SKL
  linux-firmware/i915: Add HuC 1.07.1398 for broxton
  linux-firmware/i915: HuC on 2.0.1810 for Kabylake
  linux-firmware/i915: GuC firmware for Broxton v8.7
  linux-firmware/i915: GuC firmware for Kabylake v9.14

 WHENCE |  15 +++
 i915/bxt_guc_ver8_7.bin| Bin 0 -> 140927 bytes
 i915/bxt_huc_ver01_07_1398.bin | Bin 0 -> 154432 bytes
 i915/kbl_guc_ver9_14.bin   | Bin 0 -> 142655 bytes
 i915/kbl_huc_ver02_00_1810.bin | Bin 0 -> 218688 bytes
 i915/skl_huc_ver01_07_1398.bin | Bin 0 -> 140992 bytes
 6 files changed, 15 insertions(+)
 create mode 100644 i915/bxt_guc_ver8_7.bin
 create mode 100644 i915/bxt_huc_ver01_07_1398.bin
 create mode 100644 i915/kbl_guc_ver9_14.bin
 create mode 100644 i915/kbl_huc_ver02_00_1810.bin
 create mode 100644 i915/skl_huc_ver01_07_1398.bin


Thanks,
Anusha

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore context and pd for ringbuffer submission after reset

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 05:54:10PM +0200, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > Following a reset, the context and page directory registers are lost.
> > However, the queue of requests that we resubmit after the reset may
> > depend upon them - the registers are restored from a context image, but
> > that restore may be inhibited and may simply be absent from the request
> > if it was in the middle of a sequence using the same context. If we
> > prime the CCID/PD registers with the first request in the queue (even
> > for the hung request), we prevent invalid memory access for the
> > following requests (and continually hung engines).
> >
> > v2: Magic BIT(8), reserved for future use but still appears unused.
> > v3: Some commentary on handling innocent vs guilty requests
> > v4: Add a wait for PD_BASE fetch. The reload appears to be instant on my
> > Ivybridge, but this bit probably exists for a reason.
> >
> > Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete 
> > requests")
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> 
> Reviewed-by: Mika Kuoppala 

Thanks very much for the review, pushed as this fixes a reproducible
hang when combined with redundant MI_SET_CONTEXT elimination.
-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 2/3] drm/i915: Split GEM resetting into 3 phases

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 09:12:25PM +, Chris Wilson wrote:
> Currently we do a reset prepare/finish around the call to reset the GPU,
> but it looks like we need a later stage after the hw has been
> reinitialised to allow GEM to restart itself. Start by splitting the 2
> GEM phases into 3:
> 
>   prepare - before the reset, check if GEM recovered, then stop GEM
> 
>   reset - after the reset, update GEM bookkeeping
> 
>   finish - after the re-initialisation following the reset, restart GEM
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_gem.c | 11 ---
>  3 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index acbd772837b5..0aa4ac2b43ca 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1836,7 +1836,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
>   goto error;
>   }
>  
> - i915_gem_reset_finish(dev_priv);
> + i915_gem_reset(dev_priv);
>   intel_overlay_reset(dev_priv);
>  
>   /* Ok, now get things going again... */
> @@ -1859,6 +1859,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
>   goto error;
>   }
>  
> + i915_gem_reset_finish(dev_priv);
>   i915_queue_hangcheck(dev_priv);
>  
>  wakeup:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0cbd289da4ba..972d35259883 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3353,6 +3353,7 @@ static inline u32 i915_reset_count(struct 
> i915_gpu_error *error)
>  }
>  
>  int i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
> +void i915_gem_reset(struct drm_i915_private *dev_priv);
>  void i915_gem_reset_finish(struct drm_i915_private *dev_priv);
>  void i915_gem_set_wedged(struct drm_i915_private *dev_priv);
>  void i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 17bcec9f1321..e125c0d61ce9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2760,7 +2760,7 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   engine_skip_context(request);
>  }
>  
> -void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
> +void i915_gem_reset(struct drm_i915_private *dev_priv)
>  {
>   struct intel_engine_cs *engine;
>   enum intel_engine_id id;
> @@ -2772,8 +2772,6 @@ void i915_gem_reset_finish(struct drm_i915_private 
> *dev_priv)
>   for_each_engine(engine, dev_priv, id)
>   i915_gem_reset_engine(engine);
>  
> - i915_gem_restore_fences(dev_priv);

Restore fences has to be before the init_hw() for gen2/3 - otherwise we
may restart requests trying to access through the fences.

Imagine this patch just introduced the empty function and renamed the
pair.
-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 3/3] drm/i915: Disable engine->irq_tasklet around resets

2017-02-07 Thread Chris Wilson

When we restart the engines, and we have active requests, a request on
the first engine may complete and queue a request to the second engine
before we try to restart the second engine. That queueing of the
request may race with the engine to restart, and so may corrupt the
current state. Disabling the engine->irq_tasklet prevents the two paths
from writing into ELSP simultaneously (and modifyin the execlists_port[]
at the same time).

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Testcase: igt/gem_exec_fence/await-hang
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e125c0d61ce9..62fbc1d97ec5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2641,6 +2641,15 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
for_each_engine(engine, dev_priv, id) {
struct drm_i915_gem_request *request;
 
+   /* Prevent request submission to the hardware until we have
+* completed the reset in i915_gem_reset_finish(). If a request
+* is completed by one engine, it may then queue a request
+* to a second via its engine->irq_tasklet *just* as we are
+* calling engine->init_hw() and also writing the ELSP.
+* Turning off the engine->irq_tasklet until the reset is over
+* prevents the race.
+*/
+   tasklet_disable(&engine->irq_tasklet);
tasklet_kill(&engine->irq_tasklet);
 
if (engine_stalled(engine)) {
@@ -2782,9 +2791,15 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
 
 void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
 {
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
lockdep_assert_held(&dev_priv->drm.struct_mutex);
 
i915_gem_restore_fences(dev_priv);
+
+   for_each_engine(engine, dev_priv, id)
+   tasklet_enable(&engine->irq_tasklet);
 }
 
 static void nop_submit_request(struct drm_i915_gem_request *request)
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/3] drm/i915: Move calling engine->init_hw() to its own function

2017-02-07 Thread Chris Wilson

Just a simple refactor to move a loop and some support code out of
i915_gem_init_hw(). This is in preparation for avoiding a race between
the tasklet writing to ELSP whilst simultaneously being written by
engine->init_hw() following a GPU reset.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a510c7f6828..17bcec9f1321 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4369,11 +4369,24 @@ static void init_unused_rings(struct drm_i915_private 
*dev_priv)
}
 }
 
-int
-i915_gem_init_hw(struct drm_i915_private *dev_priv)
+static int __i915_gem_restart_engines(void *data)
 {
+   struct drm_i915_private *i915 = data;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   int err;
+
+   for_each_engine(engine, i915, id) {
+   err = engine->init_hw(engine);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
+int i915_gem_init_hw(struct drm_i915_private *dev_priv)
+{
int ret;
 
dev_priv->gt.last_init_time = ktime_get();
@@ -4419,11 +4432,9 @@ i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
 
/* Need to do basic initialisation of all rings first: */
-   for_each_engine(engine, dev_priv, id) {
-   ret = engine->init_hw(engine);
-   if (ret)
-   goto out;
-   }
+   ret = __i915_gem_restart_engines(dev_priv);
+   if (ret)
+   goto out;
 
intel_mocs_init_l3cc_table(dev_priv);
 
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/3] drm/i915: Split GEM resetting into 3 phases

2017-02-07 Thread Chris Wilson

Currently we do a reset prepare/finish around the call to reset the GPU,
but it looks like we need a later stage after the hw has been
reinitialised to allow GEM to restart itself. Start by splitting the 2
GEM phases into 3:

  prepare - before the reset, check if GEM recovered, then stop GEM

  reset - after the reset, update GEM bookkeeping

  finish - after the re-initialisation following the reset, restart GEM

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.c |  3 ++-
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 11 ---
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index acbd772837b5..0aa4ac2b43ca 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1836,7 +1836,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto error;
}
 
-   i915_gem_reset_finish(dev_priv);
+   i915_gem_reset(dev_priv);
intel_overlay_reset(dev_priv);
 
/* Ok, now get things going again... */
@@ -1859,6 +1859,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto error;
}
 
+   i915_gem_reset_finish(dev_priv);
i915_queue_hangcheck(dev_priv);
 
 wakeup:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0cbd289da4ba..972d35259883 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3353,6 +3353,7 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
 }
 
 int i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
+void i915_gem_reset(struct drm_i915_private *dev_priv);
 void i915_gem_reset_finish(struct drm_i915_private *dev_priv);
 void i915_gem_set_wedged(struct drm_i915_private *dev_priv);
 void i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 17bcec9f1321..e125c0d61ce9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2760,7 +2760,7 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
engine_skip_context(request);
 }
 
-void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
+void i915_gem_reset(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -2772,8 +2772,6 @@ void i915_gem_reset_finish(struct drm_i915_private 
*dev_priv)
for_each_engine(engine, dev_priv, id)
i915_gem_reset_engine(engine);
 
-   i915_gem_restore_fences(dev_priv);
-
if (dev_priv->gt.awake) {
intel_sanitize_gt_powersave(dev_priv);
intel_enable_gt_powersave(dev_priv);
@@ -2782,6 +2780,13 @@ void i915_gem_reset_finish(struct drm_i915_private 
*dev_priv)
}
 }
 
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
+{
+   lockdep_assert_held(&dev_priv->drm.struct_mutex);
+
+   i915_gem_restore_fences(dev_priv);
+}
+
 static void nop_submit_request(struct drm_i915_gem_request *request)
 {
dma_fence_set_error(&request->fence, -EIO);
-- 
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: failure for drm/i915: Always convert incoming exec offsets to non-canonical

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915: Always convert incoming exec offsets to non-canonical
URL   : https://patchwork.freedesktop.org/series/19259/
State : failure

== Summary ==

Series 19259v1 drm/i915: Always convert incoming exec offsets to non-canonical
https://patchwork.freedesktop.org/api/1.0/series/19259/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-snb-2520m)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> FAIL   (fi-skl-6770hq)

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:238  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:252  pass:220  dwarn:1   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

828426643736be75ecb9293d9de37cceeb3212ea drm-tip: 2017y-02m-07d-19h-09m-25s UTC 
integration manifest
fea6139 drm/i915: Always convert incoming exec offsets to non-canonical

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 01:37:52AM -0800, Oscar Mateo wrote:
> 
> 
> On 02/07/2017 09:25 AM, Chris Wilson wrote:
> >On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
> >>
> >>On 02/02/2017 11:33 PM, Chris Wilson wrote:
> >>>On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
> From: Michal Wajdeczko 
> 
> The GuC descriptor is big in size. If we use local definition of
> guc_desc we have a chance to overflow stack. Use allocated one.
> 
> v2: Rebased
> v3: Split
> v4: Handle ENOMEM, cover all uses of guc_context_desc, use kzalloc (Oscar)
> 
> Signed-off-by: Deepak S 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Oscar Mateo 
> ---
>   drivers/gpu/drm/i915/i915_guc_submission.c | 94 
>  ++
>   1 file changed, 57 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 8ced9e2..b4f14f3 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -102,9 +102,13 @@ static int guc_update_doorbell_id(struct intel_guc 
> *guc,
>   struct sg_table *sg = guc->ctx_pool_vma->pages;
>   void *doorbell_bitmap = guc->doorbell_bitmap;
>   struct guc_doorbell_info *doorbell;
> - struct guc_context_desc desc;
> + struct guc_context_desc *desc;
>   size_t len;
> + desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> + if (!desc)
> + return -ENOMEM;
> +
>   doorbell = client->vaddr + client->doorbell_offset;
>   if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
> @@ -116,15 +120,22 @@ static int guc_update_doorbell_id(struct intel_guc 
> *guc,
>   }
>   /* Update the GuC's idea of the doorbell ID */
> - len = sg_pcopy_to_buffer(sg->sgl, sg->nents, &desc, sizeof(desc),
> -  sizeof(desc) * client->ctx_index);
> - if (len != sizeof(desc))
> + len = sg_pcopy_to_buffer(sg->sgl, sg->nents, desc, sizeof(*desc),
> +  sizeof(*desc) * client->ctx_index);
> >>>This is silly. You are creating a pointer using kmalloc to copy into a
> >>>pointer created using alloc_page. Just write directly into the backing
> >>>store.
> >>I guess I deserve this for not digging any deeper. From what I can
> >>see, the backing store is an array of 1024 context descriptors. If
> >>the whole context descriptor fell in one page, I could kmap_atomic
> >>only that. As it is, I would need to vmap a couple of pages to make
> >>sure I always get a complete pointer to guc_context_desc. Would you
> >>be happy with that?
> >One of the suggested usecases for i915_gem_object_pin_map() was this code.
> >-Chris
> 
> I considered it, but with the current interface that would mean
> vmapping the whole thing (something like 70 pages). Isn't that a bit
> overkill?

The whole object is pinned into memory and occupies aperture space, and
all will be used at some point. Keeping a small vmap is not a huge cost
for a reasonably frequently used object.

> I know you are going to say it wastes memory, but (KISS) what about
> if I make guc_context_desc part of i915_guc_client, to be used for
> sg_pcopy operations?.
> Although I am getting the vibe that you have discussed the sg_pcopy
> thing in the past, and this is not only about avoiding potential
> stack overflows. Am I right?

More that I have an abhorence for scatterlist (since it appears so high
on profiles). At the very least use i915_gem_object_get_page() as that
will use the radixtree for a fast lookup.
-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: Always convert incoming exec offsets to non-canonical

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 08:55:59PM +0100, Michał Winiarski wrote:
> We're using non-canonical addresses in drm_mm, and we're making sure that
> userspace is using canonical addressing - both in case of softpin
> (verifying incoming offset) and when relocating (converting to canonical
> when updating offset returned to userspace).
> Unfortunately when considering the need for relocations, we're comparing
> offset from userspace (in canonical form) with drm_mm node (in
> non-canonical form), and as a result, we end up always relocating if our
> offsets are in the "problematic" range.
> Let's always convert the offsets to avoid the performance impact of
> relocations.
> 
> Fixes: a5f0edf63bdf ("drm/i915: Avoid writing relocs with addresses in 
> non-canonical form")
> Cc: Chris Wilson 
> Cc: Michel Thierry 
> Reported-by: Michał Pyrzowski 
> Signed-off-by: Michał Winiarski 

Matches what I have in my tree. Continual hint for review.
-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] ✗ Fi.CI.BAT: warning for drm/i915: Introduce intel_cdclk_state (rev12)

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915: Introduce intel_cdclk_state (rev12)
URL   : https://patchwork.freedesktop.org/series/16994/
State : warning

== Summary ==

Series 16994v12 drm/i915: Introduce intel_cdclk_state
https://patchwork.freedesktop.org/api/1.0/series/16994/revisions/12/mbox/

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

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:220  dwarn:1   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

828426643736be75ecb9293d9de37cceeb3212ea drm-tip: 2017y-02m-07d-19h-09m-25s UTC 
integration manifest
3536b05 drm/i915: Clean up the .get_cdclk() assignment if ladder
7e62691 drm/i915: s/get_display_clock_speed/get_cdclk/
384459c drm/i915: Nuke intel_mode_max_pixclk()
48f77a4 drm/i915: Store the pipe pixel rate in the crtc state

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 12/13] drm/i915/dp: localize link rate index variable more

2017-02-07 Thread Manasi Navare

This has been tested to correctly execute the compliance request.

Reviewed-by: Manasi Navare 

Manasi

On Fri, Feb 03, 2017 at 04:19:35PM +0200, Jani Nikula wrote:
> Localize link_rate_index to the if block, and rename to just index to
> reduce indent.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 58ec70f316c5..90ae95f2ecb2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1640,7 +1640,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   /* Conveniently, the link BW constants become indices with a shift...*/
>   int min_clock = 0;
>   int max_clock;
> - int link_rate_index;
>   int bpp, mode_rate;
>   int link_avail, link_clock;
>   int common_len;
> @@ -1684,11 +1683,13 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  
>   /* Use values requested by Compliance Test Request */
>   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> - link_rate_index = intel_dp_rate_index(intel_dp->common_rates,
> -   
> intel_dp->num_common_rates,
> -   
> intel_dp->compliance.test_link_rate);
> - if (link_rate_index >= 0)
> - min_clock = max_clock = link_rate_index;
> + int index;
> +
> + index = intel_dp_rate_index(intel_dp->common_rates,
> + intel_dp->num_common_rates,
> + 
> intel_dp->compliance.test_link_rate);
> + if (index >= 0)
> + min_clock = max_clock = index;
>   min_lane_count = max_lane_count = 
> intel_dp->compliance.test_lane_count;
>   }
>   DRM_DEBUG_KMS("DP link computation with max lane count %i "
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 00/13] drm/i915/dp: link rate and lane count refactoring

2017-02-07 Thread Manasi Navare

Hi Jani,

Thanks for this patch series. This definitely makes use
of lane count and link rate cleaner while handling the link failures.
I have tested these patches with compliance device along with my pending
DRM link-status patches and it does the fallback as expected.
It does not solve the problem of max link rate/lane count getting reset
through ->detect callback from fill_modes(), but that will be fixed in a
separate patch.

As far as these patches, the fallback and compliance works properly:

Tested-by: Manasi Navare 

Manasi


On Fri, Feb 03, 2017 at 04:19:23PM +0200, Jani Nikula wrote:
> v2 of [1], rebased and review addressed.
> 
> BR,
> Jani.
> 
> 
> [1] cover.1485459621.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1485459621.git.jani.nikula@intel.com
> 
> 
> Jani Nikula (13):
>   drm/i915/dp: use known correct array size in rate_to_index
>   drm/i915/dp: return errors from rate_to_index()
>   drm/i915/dp: rename rate_to_index() to intel_dp_rate_index() and reuse
>   drm/i915/dp: cache source rates at init
>   drm/i915/dp: generate and cache sink rate array for all DP, not just
> eDP 1.4
>   drm/i915/dp: use the sink rates array for max sink rates
>   drm/i915/dp: cache common rates with sink rates
>   drm/i915/dp: do not limit rate seek when not needed
>   drm/i915/dp: don't call the link parameters sink parameters
>   drm/i915/dp: add functions for max common link rate and lane count
>   drm/i915/mst: use max link not sink lane count
>   drm/i915/dp: localize link rate index variable more
>   drm/i915/dp: use readb and writeb calls for single byte DPCD access
> 
>  drivers/gpu/drm/i915/intel_dp.c   | 284 
> ++
>  drivers/gpu/drm/i915/intel_dp_link_training.c |   3 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |   4 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  20 +-
>  4 files changed, 173 insertions(+), 138 deletions(-)
> 
> -- 
> 2.1.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Always convert incoming exec offsets to non-canonical

2017-02-07 Thread Michał Winiarski

We're using non-canonical addresses in drm_mm, and we're making sure that
userspace is using canonical addressing - both in case of softpin
(verifying incoming offset) and when relocating (converting to canonical
when updating offset returned to userspace).
Unfortunately when considering the need for relocations, we're comparing
offset from userspace (in canonical form) with drm_mm node (in
non-canonical form), and as a result, we end up always relocating if our
offsets are in the "problematic" range.
Let's always convert the offsets to avoid the performance impact of
relocations.

Fixes: a5f0edf63bdf ("drm/i915: Avoid writing relocs with addresses in 
non-canonical form")
Cc: Chris Wilson 
Cc: Michel Thierry 
Reported-by: Michał Pyrzowski 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1298357..111b7f8 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1184,14 +1184,14 @@ validate_exec_list(struct drm_device *dev,
if (exec[i].offset !=
gen8_canonical_addr(exec[i].offset & PAGE_MASK))
return -EINVAL;
-
-   /* From drm_mm perspective address space is continuous,
-* so from this point we're always using non-canonical
-* form internally.
-*/
-   exec[i].offset = gen8_noncanonical_addr(exec[i].offset);
}
 
+   /* From drm_mm perspective address space is continuous,
+* so from this point we're always using non-canonical
+* form internally.
+*/
+   exec[i].offset = gen8_noncanonical_addr(exec[i].offset);
+
if (exec[i].alignment && !is_power_of_2(exec[i].alignment))
return -EINVAL;
 
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v1½ 03/13] drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse

2017-02-07 Thread Pandiyan, Dhinakaran

On Thu, 2017-02-02 at 10:44 +0200, Jani Nikula wrote:
> On Wed, 01 Feb 2017, "Pandiyan, Dhinakaran"  
> wrote:
> > On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> >> Rename the function, move it at the top, and reuse in
> >> intel_dp_link_rate_index(). If there was a reason in the past to use
> >> reverse search order here, there isn't now.
> >> 
> >> Cc: Manasi Navare 
> >> Cc: Ville Syrjälä 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dp.c | 33 ++---
> >>  1 file changed, 14 insertions(+), 19 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 1d66737a3a0f..f3068ff670a1 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -266,6 +266,17 @@ static int intersect_rates(const int *source_rates, 
> >> int source_len,
> >>return k;
> >>  }
> >>  
> >> +static int intel_dp_find_rate(const int *rates, int len, int rate)
> >
> > I wonder if the function name can be more intuitive. The argument is
> > rate and the function name indicates it also returns rate. I can't tell
> > what the function does by it's name. Feel free to ignore this comment as
> > I might be missing some context.
> 
> Naming is hard. intel_dp_rate_index?
> 
> BR,
> Jani.
> 
> 

That does sounds good.

Reviewed-by: Dhinakaran Pandiyan 
> >
> > -DK
> >
> >> +{
> >> +  int i;
> >> +
> >> +  for (i = 0; i < len; i++)
> >> +  if (rate == rates[i])
> >> +  return i;
> >> +
> >> +  return -1;
> >> +}
> >> +
> >>  static int intel_dp_common_rates(struct intel_dp *intel_dp,
> >> int *common_rates)
> >>  {
> >> @@ -284,15 +295,10 @@ static int intel_dp_link_rate_index(struct intel_dp 
> >> *intel_dp,
> >>int *common_rates, int link_rate)
> >>  {
> >>int common_len;
> >> -  int index;
> >>  
> >>common_len = intel_dp_common_rates(intel_dp, common_rates);
> >> -  for (index = 0; index < common_len; index++) {
> >> -  if (link_rate == common_rates[common_len - index - 1])
> >> -  return common_len - index - 1;
> >> -  }
> >>  
> >> -  return -1;
> >> +  return intel_dp_find_rate(common_rates, common_len, link_rate);
> >>  }
> >>  
> >>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> >> @@ -1542,17 +1548,6 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
> >>return true;
> >>  }
> >>  
> >> -static int rate_to_index(const int *rates, int len, int rate)
> >> -{
> >> -  int i;
> >> -
> >> -  for (i = 0; i < len; i++)
> >> -  if (rate == rates[i])
> >> -  return i;
> >> -
> >> -  return -1;
> >> -}
> >> -
> >>  int
> >>  intel_dp_max_link_rate(struct intel_dp *intel_dp)
> >>  {
> >> @@ -1568,8 +1563,8 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp)
> >>  
> >>  int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
> >>  {
> >> -  int i = rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates,
> >> -rate);
> >> +  int i = intel_dp_find_rate(intel_dp->sink_rates,
> >> + intel_dp->num_sink_rates, rate);
> >>  
> >>if (WARN_ON(i < 0))
> >>i = 0;
> >
> 

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

[Intel-gfx] [PATCH v4 07/14] drm/i915: Start moving the cdclk stuff into a distinct state structure

2017-02-07 Thread ville . syrjala

From: Ville Syrjälä 

Introduce intel_cdclk state which for now will track the cdclk
frequency, the vco frequency and the reference frequency (not sure we
want the last one, but I put it there anyway). We'll also make the
.get_cdclk() function fill out this state structure rather than
just returning the current cdclk frequency.

One immediate benefit is that calling .get_cdclk() will no longer
clobber state stored under dev_priv unless ex[plicitly told to do
so. Previously it clobbered the vco and reference clocks stored
there on some platforms.

We'll expand the use of this structure to actually precomputing the
state and whatnot later.

v2: Constify intel_cdclk_state_compare()
v3: Document intel_cdclk_state_compare()
v4: Deal with i945gm_get_cdclk()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Ander Conselvan de Oliveira 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-8-ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.h |  14 +-
 drivers/gpu/drm/i915/intel_audio.c  |   2 +-
 drivers/gpu/drm/i915/intel_cdclk.c  | 382 +++-
 drivers/gpu/drm/i915/intel_display.c|  18 +-
 drivers/gpu/drm/i915/intel_dp.c |   2 +-
 drivers/gpu/drm/i915/intel_drv.h|   3 +
 drivers/gpu/drm/i915/intel_fbc.c|   2 +-
 drivers/gpu/drm/i915/intel_panel.c  |   4 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   5 +-
 10 files changed, 258 insertions(+), 176 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 152f23db4ec2..5b98166595c4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1281,7 +1281,7 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_puts(m, "no P-state info available\n");
}
 
-   seq_printf(m, "Current CD clock frequency: %d kHz\n", 
dev_priv->cdclk_freq);
+   seq_printf(m, "Current CD clock frequency: %d kHz\n", 
dev_priv->cdclk.hw.cdclk);
seq_printf(m, "Max CD clock frequency: %d kHz\n", 
dev_priv->max_cdclk_freq);
seq_printf(m, "Max pixel clock frequency: %d kHz\n", 
dev_priv->max_dotclk_freq);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f41496405484..aa59b2153374 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -600,9 +600,11 @@ struct intel_initial_plane_config;
 struct intel_crtc;
 struct intel_limit;
 struct dpll;
+struct intel_cdclk_state;
 
 struct drm_i915_display_funcs {
-   int (*get_cdclk)(struct drm_i915_private *dev_priv);
+   void (*get_cdclk)(struct drm_i915_private *dev_priv,
+ struct intel_cdclk_state *cdclk_state);
int (*get_fifo_size)(struct drm_i915_private *dev_priv, int plane);
int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
int (*compute_intermediate_wm)(struct drm_device *dev,
@@ -2060,6 +2062,10 @@ struct i915_oa_ops {
bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };
 
+struct intel_cdclk_state {
+   unsigned int cdclk, vco, ref;
+};
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -2164,7 +2170,7 @@ struct drm_i915_private {
 
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
-   unsigned int cdclk_freq, max_cdclk_freq;
+   unsigned int max_cdclk_freq;
 
/*
 * For reading holding any crtc lock is sufficient,
@@ -2178,8 +2184,8 @@ struct drm_i915_private {
unsigned int czclk_freq;
 
struct {
-   unsigned int vco, ref;
-   } cdclk_pll;
+   struct intel_cdclk_state hw;
+   } cdclk;
 
/**
 * wq - Driver workqueue for GEM.
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index cd9d20763140..1ab401faed34 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -734,7 +734,7 @@ static int i915_audio_component_get_cdclk_freq(struct 
device *kdev)
if (WARN_ON_ONCE(!HAS_DDI(dev_priv)))
return -ENODEV;
 
-   return dev_priv->cdclk_freq;
+   return dev_priv->cdclk.hw.cdclk;
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index a0736b5f2d47..4e74e87a8676 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -51,37 +51,44 @@
  * dividers can be programmed correctly.
  */
 
-static int fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv)
+static void fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv,
+  struct intel_cdclk_state *cdclk_state)
 {
-   return 13;
+   cdclk_state->cdclk = 13;
 }
 
-static int fixed_200mhz_get_cdclk(struct drm_i915_private *dev_priv)
+static void fixed_200mhz_get_cdclk(struct drm_i915_priv

[Intel-gfx] [PATCH v4 05/14] drm/i915: Move most cdclk/rawclk related code to intel_cdclk.c

2017-02-07 Thread ville . syrjala

From: Ville Syrjälä 

Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk
stuff to a new file. It's all reasonably self contained so we don't
even have to add that many non-static symbols.

We'll also take the opportunity to shuffle around the functions a bit
to get things in a more consistent order based on the platform.

v2: Add kernel-docs (Ander)
v3: Deal with IS_GEN9_BC()
v4: Deal with i945gm_get_cdclk()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Ander Conselvan de Oliveira 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-6-ville.syrj...@linux.intel.com
---
 Documentation/gpu/i915.rst   |9 +
 drivers/gpu/drm/i915/Makefile|1 +
 drivers/gpu/drm/i915/intel_cdclk.c   | 1794 ++
 drivers/gpu/drm/i915/intel_display.c | 1697 +---
 drivers/gpu/drm/i915/intel_drv.h |9 +-
 5 files changed, 1816 insertions(+), 1694 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_cdclk.c

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 104296dffad1..1cd0ee518dee 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -213,6 +213,15 @@ Video BIOS Table (VBT)
 .. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h
:internal:
 
+Display clocks
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_cdclk.c
+   :doc: CDCLK / RAWCLK
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_cdclk.c
+   :internal:
+
 Display PLLs
 
 
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 74ca2e8b2494..e58fc8f1b83b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -72,6 +72,7 @@ i915-y += intel_audio.o \
  intel_atomic.o \
  intel_atomic_plane.o \
  intel_bios.o \
+ intel_cdclk.o \
  intel_color.o \
  intel_display.o \
  intel_dpio_phy.o \
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
new file mode 100644
index ..04a46c14c898
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -0,0 +1,1794 @@
+/*
+ * Copyright © 2006-2017 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.
+ */
+
+#include "intel_drv.h"
+
+/**
+ * DOC: CDCLK / RAWCLK
+ *
+ * The display engine uses several different clocks to do its work. There
+ * are two main clocks involved that aren't directly related to the actual
+ * pixel clock or any symbol/bit clock of the actual output port. These
+ * are the core display clock (CDCLK) and RAWCLK.
+ *
+ * CDCLK clocks most of the display pipe logic, and thus its frequency
+ * must be high enough to support the rate at which pixels are flowing
+ * through the pipes. Downscaling must also be accounted as that increases
+ * the effective pixel rate.
+ *
+ * On several platforms the CDCLK frequency can be changed dynamically
+ * to minimize power consumption for a given display configuration.
+ * Typically changes to the CDCLK frequency require all the display pipes
+ * to be shut down while the frequency is being changed.
+ *
+ * On SKL+ the DMC will toggle the CDCLK off/on during DC5/6 entry/exit.
+ * DMC will not change the active CDCLK frequency however, so that part
+ * will still be performed by the driver directly.
+ *
+ * RAWCLK is a fixed frequency clock, often used by various auxiliary
+ * blocks such as AUX CH or backlight PWM. Hence the only thing we
+ * really need to know about RAWCLK is its frequency so that various
+ * dividers can be programmed correctly.
+ */
+
+static int fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv)
+{
+   return 13;
+}
+
+static int fixed_200mhz_get_cdclk(struct drm_i915_private *dev_priv)
+{
+   return 20;
+}
+
+static int fixed_266mhz_get_cdclk(struct drm_i915_private *dev_priv)
+{
+   return 27;
+}
+
+static int fixe

[Intel-gfx] [PATCH v2 04/14] drm/i915: Clean up the .get_cdclk() assignment if ladder

2017-02-07 Thread ville . syrjala

From: Ville Syrjälä 

Let's clean up the mess we have in the if ladder that assigns the
.get_cdclk() hooks. The grouping of the platforms by the function
results in a thing that's not really legible, so let's do it the
other way around and order the if ladder by platform and duplicate
whatever assignments we need.

To further avoid confusion with the function names let's rename
them to just fixed__get_cdclk(). The other option would
be to duplicate the functions entirely but it seems quite
pointless to do that since each one just returns a fixed value.

v2: Deal with i945gm_get_cdclk()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Ander Conselvan de Oliveira 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-5-ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 39 
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8f560737c309..c407cc41c0c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7385,12 +7385,12 @@ static int valleyview_get_cdclk(struct drm_i915_private 
*dev_priv)
  CCK_DISPLAY_CLOCK_CONTROL);
 }
 
-static int ilk_get_cdclk(struct drm_i915_private *dev_priv)
+static int fixed_450mhz_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 45;
 }
 
-static int i945_get_cdclk(struct drm_i915_private *dev_priv)
+static int fixed_400mhz_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 40;
 }
@@ -7415,12 +7415,12 @@ static int i945gm_get_cdclk(struct drm_i915_private 
*dev_priv)
}
 }
 
-static int i915_get_cdclk(struct drm_i915_private *dev_priv)
+static int fixed_333mhz_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 33;
 }
 
-static int i9xx_misc_get_cdclk(struct drm_i915_private *dev_priv)
+static int fixed_200mhz_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 20;
 }
@@ -7470,7 +7470,7 @@ static int i915gm_get_cdclk(struct drm_i915_private 
*dev_priv)
}
 }
 
-static int i865_get_cdclk(struct drm_i915_private *dev_priv)
+static int fixed_266mhz_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 27;
 }
@@ -7513,7 +7513,7 @@ static int i85x_get_cdclk(struct drm_i915_private 
*dev_priv)
return 0;
 }
 
-static int i830_get_cdclk(struct drm_i915_private *dev_priv)
+static int fixed_133mhz_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 13;
 }
@@ -16249,34 +16249,39 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
dev_priv->display.get_cdclk = haswell_get_cdclk;
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->display.get_cdclk = valleyview_get_cdclk;
+   else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
+   dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
else if (IS_GEN5(dev_priv))
-   dev_priv->display.get_cdclk = ilk_get_cdclk;
-   else if (IS_I945G(dev_priv) || IS_I965G(dev_priv) ||
-IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv))
-   dev_priv->display.get_cdclk = i945_get_cdclk;
+   dev_priv->display.get_cdclk = fixed_450mhz_get_cdclk;
else if (IS_GM45(dev_priv))
dev_priv->display.get_cdclk = gm45_get_cdclk;
+   else if (IS_G4X(dev_priv))
+   dev_priv->display.get_cdclk = g33_get_cdclk;
else if (IS_I965GM(dev_priv))
dev_priv->display.get_cdclk = i965gm_get_cdclk;
+   else if (IS_I965G(dev_priv))
+   dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
else if (IS_PINEVIEW(dev_priv))
dev_priv->display.get_cdclk = pnv_get_cdclk;
-   else if (IS_G33(dev_priv) || IS_G4X(dev_priv))
+   else if (IS_G33(dev_priv))
dev_priv->display.get_cdclk = g33_get_cdclk;
-   else if (IS_I915G(dev_priv))
-   dev_priv->display.get_cdclk = i915_get_cdclk;
-   else if (IS_I845G(dev_priv))
-   dev_priv->display.get_cdclk = i9xx_misc_get_cdclk;
else if (IS_I945GM(dev_priv))
dev_priv->display.get_cdclk = i945gm_get_cdclk;
+   else if (IS_I945G(dev_priv))
+   dev_priv->display.get_cdclk = fixed_400mhz_get_cdclk;
else if (IS_I915GM(dev_priv))
dev_priv->display.get_cdclk = i915gm_get_cdclk;
+   else if (IS_I915G(dev_priv))
+   dev_priv->display.get_cdclk = fixed_333mhz_get_cdclk;
else if (IS_I865G(dev_priv))
-   dev_priv->display.get_cdclk = i865_get_cdclk;
+   dev_priv->display.get_cdclk = fixed_266mhz_get_cdclk;
else if (IS_I85X(dev_priv))
dev_priv->display.get_cdclk = i85x_get_cdclk;
+   else  if (IS_I845G(dev_priv))
+   dev_priv->display.get_cdclk = fixed_200mhz_get_cdclk;

[Intel-gfx] [PATCH v3 03/14] drm/i915: s/get_display_clock_speed/get_cdclk/

2017-02-07 Thread ville . syrjala

From: Ville Syrjälä 

Rename the .get_display_clock_speed() hook to .get_cdclk().
.get_cdclk() is more specific (which clock) and it's much
shorter.

v2: Deal with IS_GEN9_BC()
v3: Deal with i945gm_get_display_clock_speed()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Ander Conselvan de Oliveira 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-4-ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_display.c| 98 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +-
 3 files changed, 41 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6006694bffb5..f41496405484 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -602,7 +602,7 @@ struct intel_limit;
 struct dpll;
 
 struct drm_i915_display_funcs {
-   int (*get_display_clock_speed)(struct drm_i915_private *dev_priv);
+   int (*get_cdclk)(struct drm_i915_private *dev_priv);
int (*get_fifo_size)(struct drm_i915_private *dev_priv, int plane);
int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
int (*compute_intermediate_wm)(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 07d74e8e4ce7..8f560737c309 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5873,7 +5873,7 @@ static void intel_update_max_cdclk(struct 
drm_i915_private *dev_priv)
 
 static void intel_update_cdclk(struct drm_i915_private *dev_priv)
 {
-   dev_priv->cdclk_freq = 
dev_priv->display.get_display_clock_speed(dev_priv);
+   dev_priv->cdclk_freq = dev_priv->display.get_cdclk(dev_priv);
 
if (INTEL_GEN(dev_priv) >= 9)
DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d kHz, 
ref: %d kHz\n",
@@ -6411,8 +6411,7 @@ static void valleyview_set_cdclk(struct drm_device *dev, 
int cdclk)
struct drm_i915_private *dev_priv = to_i915(dev);
u32 val, cmd;
 
-   WARN_ON(dev_priv->display.get_display_clock_speed(dev_priv)
-   != dev_priv->cdclk_freq);
+   WARN_ON(dev_priv->display.get_cdclk(dev_priv) != dev_priv->cdclk_freq);
 
if (cdclk >= 32) /* jump to highest voltage for 400MHz too */
cmd = 2;
@@ -6476,8 +6475,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
struct drm_i915_private *dev_priv = to_i915(dev);
u32 val, cmd;
 
-   WARN_ON(dev_priv->display.get_display_clock_speed(dev_priv)
-   != dev_priv->cdclk_freq);
+   WARN_ON(dev_priv->display.get_cdclk(dev_priv) != dev_priv->cdclk_freq);
 
switch (cdclk) {
case 33:
@@ -7249,7 +7247,7 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
return 0;
 }
 
-static int skylake_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int skylake_get_cdclk(struct drm_i915_private *dev_priv)
 {
u32 cdctl;
 
@@ -7310,7 +7308,7 @@ static void bxt_de_pll_update(struct drm_i915_private 
*dev_priv)
dev_priv->cdclk_pll.ref;
 }
 
-static int broxton_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int broxton_get_cdclk(struct drm_i915_private *dev_priv)
 {
u32 divider;
int div, vco;
@@ -7345,7 +7343,7 @@ static int broxton_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return DIV_ROUND_CLOSEST(vco, div);
 }
 
-static int broadwell_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int broadwell_get_cdclk(struct drm_i915_private *dev_priv)
 {
uint32_t lcpll = I915_READ(LCPLL_CTL);
uint32_t freq = lcpll & LCPLL_CLK_FREQ_MASK;
@@ -7364,7 +7362,7 @@ static int broadwell_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return 675000;
 }
 
-static int haswell_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int haswell_get_cdclk(struct drm_i915_private *dev_priv)
 {
uint32_t lcpll = I915_READ(LCPLL_CTL);
uint32_t freq = lcpll & LCPLL_CLK_FREQ_MASK;
@@ -7381,23 +7379,23 @@ static int haswell_get_display_clock_speed(struct 
drm_i915_private *dev_priv)
return 54;
 }
 
-static int valleyview_get_display_clock_speed(struct drm_i915_private 
*dev_priv)
+static int valleyview_get_cdclk(struct drm_i915_private *dev_priv)
 {
return vlv_get_cck_clock_hpll(dev_priv, "cdclk",
  CCK_DISPLAY_CLOCK_CONTROL);
 }
 
-static int ilk_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int ilk_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 45;
 }
 
-static int i945_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int i945_get_cdclk(struct drm_i915_private *dev_priv)
 {
return 40

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Make intel_guc_send a function pointer (rev2)

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915/guc: Make intel_guc_send a function pointer (rev2)
URL   : https://patchwork.freedesktop.org/series/19024/
State : failure

== Summary ==

Series 19024v2 drm/i915/guc: Make intel_guc_send a function pointer
https://patchwork.freedesktop.org/api/1.0/series/19024/revisions/2/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
fail   -> PASS   (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-hsw-4770)

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:48   pass:41   dwarn:0   dfail:0   fail:0   skip:6  
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

b8157792b685dfcc86fa7dc23d66d663ad6fb93f drm-tip: 2017y-02m-07d-14h-55m-05s UTC 
integration manifest
852c39b drm/i915/guc: Make intel_guc_send a function pointer

== Logs ==

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

[Intel-gfx] [PATCH i-g-t] igt/core: Return condition result from igt_warn_on*()

2017-02-07 Thread Lyude

This allows us to be a little more flexible with how we use
igt_warn_on() and igt_warn_on_f() by allowing us to write statements
like this:

if (igt_warn_on(scary_condition)) {
/* some error handling... */
}

Signed-off-by: Lyude 
---
 lib/igt_core.h | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/lib/igt_core.h b/lib/igt_core.h
index b669de3..51b98d8 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -828,12 +828,16 @@ extern enum igt_log_level igt_log_level;
  * Should be used everywhere where a test checks results to decide about
  * printing warnings. This is useful to streamline the test logic since it
  * allows for a more flat code control flow, similar to igt_assert()
+ *
+ * This macro also returns the value of @condition.
  */
-#define igt_warn_on(condition) do {\
-   if (condition) \
-   igt_warn("Warning on condition %s in fucntion %s, file 
%s:%i\n", \
+#define igt_warn_on(condition) ({ \
+   typeof(condition) ret__ = (condition); \
+   if (ret__) \
+   igt_warn("Warning on condition %s in function %s, file 
%s:%i\n", \
 #condition, __func__, __FILE__, __LINE__); \
-   } while (0)
+   ret__; \
+   })
 
 /**
  * igt_warn_on_f:
@@ -850,15 +854,18 @@ extern enum igt_log_level igt_log_level;
  *
  * In addition to the plain igt_warn_on_f() helper this allows to print
  * additional information (again as warnings) to help debugging test failures.
+ *
+ * It also returns the value of @condition.
  */
-#define igt_warn_on_f(condition, f...) do {\
-   if (condition) {\
-   igt_warn("Warning on condition %s in fucntion %s, file 
%s:%i\n", \
+#define igt_warn_on_f(condition, f...) ({ \
+   typeof(condition) ret__ = (condition); \
+   if (ret__) {\
+   igt_warn("Warning on condition %s in function %s, file 
%s:%i\n", \
 #condition, __func__, __FILE__, __LINE__); \
igt_warn(f); \
} \
-   } while (0)
-
+   ret__; \
+   })
 
 void igt_set_timeout(unsigned int seconds,
 const char *op);
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915: Get correct display clock on 945gm

2017-02-07 Thread Ville Syrjälä

On Wed, Feb 01, 2017 at 12:50:26AM +0100, Arthur Heymans wrote:
> This is according to Mobile Intel® 945 Express Chipset
> Family datasheet.
> 
> Signed-off-by: Arthur Heymans 

Reviewed-by: Ville Syrjälä 

and pushed to dinq. Thanks for the patch.

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
>  drivers/gpu/drm/i915/intel_display.c | 27 +--
>  2 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 02a65ddae3a3..f0b7849ace17 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define GCFGC0xf0 /* 915+ only */
>  #define   GC_LOW_FREQUENCY_ENABLE(1 << 7)
>  #define   GC_DISPLAY_CLOCK_190_200_MHZ   (0 << 4)
> -#define   GC_DISPLAY_CLOCK_333_MHZ   (4 << 4)
> +#define   GC_DISPLAY_CLOCK_333_320_MHZ   (4 << 4)
>  #define   GC_DISPLAY_CLOCK_267_MHZ_PNV   (0 << 4)
>  #define   GC_DISPLAY_CLOCK_333_MHZ_PNV   (1 << 4)
>  #define   GC_DISPLAY_CLOCK_444_MHZ_PNV   (2 << 4)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ac25706b7d4d..998920ab3ec8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7407,6 +7407,26 @@ static int i945_get_display_clock_speed(struct 
> drm_i915_private *dev_priv)
>   return 40;
>  }
>  
> +static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv)
> +{
> + struct pci_dev *pdev = dev_priv->drm.pdev;
> + u16 gcfgc = 0;
> +
> + pci_read_config_word(pdev, GCFGC, &gcfgc);
> +
> + if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
> + return 13;
> + else {
> + switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
> + case GC_DISPLAY_CLOCK_333_320_MHZ:
> + return 32;
> + default:
> + case GC_DISPLAY_CLOCK_190_200_MHZ:
> + return 20;
> + }
> + }
> +}
> +
>  static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv)
>  {
>   return 33;
> @@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct 
> drm_i915_private *dev_priv)
>   return 13;
>   else {
>   switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
> - case GC_DISPLAY_CLOCK_333_MHZ:
> + case GC_DISPLAY_CLOCK_333_320_MHZ:
>   return 33;
>   default:
>   case GC_DISPLAY_CLOCK_190_200_MHZ:
> @@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct 
> drm_i915_private *dev_priv)
>   else if (IS_I915G(dev_priv))
>   dev_priv->display.get_display_clock_speed =
>   i915_get_display_clock_speed;
> - else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv))
> + else if (IS_I845G(dev_priv))
>   dev_priv->display.get_display_clock_speed =
>   i9xx_misc_get_display_clock_speed;
> + else if (IS_I945GM(dev_priv))
> + dev_priv->display.get_display_clock_speed =
> + i945gm_get_display_clock_speed;
>   else if (IS_I915GM(dev_priv))
>   dev_priv->display.get_display_clock_speed =
>   i915gm_get_display_clock_speed;
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-07 Thread Ville Syrjälä

On Tue, Feb 07, 2017 at 06:51:25PM +0100, Maarten Lankhorst wrote:
> Op 07-02-17 om 16:35 schreef Ville Syrjälä:
> > On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
> >> On 07/02/17 15:22, Uwe Kleine-König wrote:
> >>> Hello,
> >>>
> >>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
>  On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> > Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
> >> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
> >>> Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
> >>> Just curious, does this help?
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> >>> b/drivers/gpu/drm/i915/intel_pm.c
> >>> index ae2c0bb4b2e8..13de4c526ca6 100644
> >>> --- a/drivers/gpu/drm/i915/intel_pm.c
> >>> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >>> @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
> >>> intel_crtc_state *cstate,
> >>>* this is necessary to avoid flickering.
> >>>*/
> >>>   int cpp = 4;
> >>> - int width = pstate->base.visible ? pstate->base.crtc_w : 64;
> >>> + int width = 256;
> >>>
> >>>   if (!cstate->base.active)
> >>>   return 0;
> >>>
> >> On a kernel with this patch applied I cannot reproduce the flickering. 
> >> I
> >> keep that kernel running but expect that it also fixes the crash.
> > Ok that's good news.
> >
> > Maybe ville or matt can comment whether this patch is the right fix?
>  Well, it's just extending the hack even further. The right fix would be
>  to fix the wm programming sequence to respect the frame boundaries
>  correctly (ie. my old vblank based wm stuff).
> >>> so I wonder how this goes forward. The situation seems to be well
> >>> understood, but other than testing patches I don't know what to do (and
> >>> there is currently no patch to test).
> >>>
> >>> Best regards
> >>> Uwe
> >>>
> >> The way I understand this is that no-one wants to restrict the 
> >> capabilities exposed by the kernel and would like a proper fix for this. 
> >> However, I agree with Uwe, given the low priority status of Gen5 (people 
> >> would rather work on hw that is used by a lot of people), we should 
> >> probably accept the patch proposed by Maarten as it fixes someone's 
> >> workflow and does not regress anything meaningful.
> > The same code is used for ILK-BDW, so it's not just ILK. And other other
> > platform suffers from the same problem of cursor vs. watermarks. It just
> > seems that most people are lucky enough to not be seriously affected by
> > this problem.
> >
> > Also it can regress some things, at least theoretically. Power consumption
> > with < 256x256 for one, and potentially it could also end up rejecting
> > some display modes that previously used to work with smaller cursor
> > sizes (or no cursors). That last part may not be 100% true, but I was
> > too lazy to go through the math to see if the cursor FIFO could end up
> > being the limiting factor in some cases.
> >
> > I was thinking Maarten's intel_legacy_cursor_update() hack should have
> > "fixed" this, but now I'm not sure since it still sets the
> > legacy_cursor_update flag in the slow path, and the commit message
> > didn't quite manage to tell me what the purpose of this function 
> > was supposed to be. The logic for picking the slow path also seems a
> > little wonky to me (assuming I deduced the purpose of the function
> > correctly).
> Hey,
> 
> This patch shouldn't fix anything, maybe wait for a vblank on changing to a 
> smaller stride?

Hmm. If it doesn't fix anything, then why does it exist?

-- 
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 RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-07 Thread Maarten Lankhorst

Op 07-02-17 om 16:35 schreef Ville Syrjälä:
> On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
>> On 07/02/17 15:22, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
 On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
>> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
>>> Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
>>> Just curious, does this help?
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index ae2c0bb4b2e8..13de4c526ca6 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
>>> intel_crtc_state *cstate,
>>>  * this is necessary to avoid flickering.
>>>  */
>>> int cpp = 4;
>>> -   int width = pstate->base.visible ? pstate->base.crtc_w : 64;
>>> +   int width = 256;
>>>
>>> if (!cstate->base.active)
>>> return 0;
>>>
>> On a kernel with this patch applied I cannot reproduce the flickering. I
>> keep that kernel running but expect that it also fixes the crash.
> Ok that's good news.
>
> Maybe ville or matt can comment whether this patch is the right fix?
 Well, it's just extending the hack even further. The right fix would be
 to fix the wm programming sequence to respect the frame boundaries
 correctly (ie. my old vblank based wm stuff).
>>> so I wonder how this goes forward. The situation seems to be well
>>> understood, but other than testing patches I don't know what to do (and
>>> there is currently no patch to test).
>>>
>>> Best regards
>>> Uwe
>>>
>> The way I understand this is that no-one wants to restrict the 
>> capabilities exposed by the kernel and would like a proper fix for this. 
>> However, I agree with Uwe, given the low priority status of Gen5 (people 
>> would rather work on hw that is used by a lot of people), we should 
>> probably accept the patch proposed by Maarten as it fixes someone's 
>> workflow and does not regress anything meaningful.
> The same code is used for ILK-BDW, so it's not just ILK. And other other
> platform suffers from the same problem of cursor vs. watermarks. It just
> seems that most people are lucky enough to not be seriously affected by
> this problem.
>
> Also it can regress some things, at least theoretically. Power consumption
> with < 256x256 for one, and potentially it could also end up rejecting
> some display modes that previously used to work with smaller cursor
> sizes (or no cursors). That last part may not be 100% true, but I was
> too lazy to go through the math to see if the cursor FIFO could end up
> being the limiting factor in some cases.
>
> I was thinking Maarten's intel_legacy_cursor_update() hack should have
> "fixed" this, but now I'm not sure since it still sets the
> legacy_cursor_update flag in the slow path, and the commit message
> didn't quite manage to tell me what the purpose of this function 
> was supposed to be. The logic for picking the slow path also seems a
> little wonky to me (assuming I deduced the purpose of the function
> correctly).
Hey,

This patch shouldn't fix anything, maybe wait for a vblank on changing to a 
smaller stride?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

2017-02-07 Thread Oscar Mateo




On 02/07/2017 09:25 AM, Chris Wilson wrote:

On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:


On 02/02/2017 11:33 PM, Chris Wilson wrote:

On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:

From: Michal Wajdeczko 

The GuC descriptor is big in size. If we use local definition of
guc_desc we have a chance to overflow stack. Use allocated one.

v2: Rebased
v3: Split
v4: Handle ENOMEM, cover all uses of guc_context_desc, use kzalloc (Oscar)

Signed-off-by: Deepak S 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94 ++
  1 file changed, 57 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ced9e2..b4f14f3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -102,9 +102,13 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
struct sg_table *sg = guc->ctx_pool_vma->pages;
void *doorbell_bitmap = guc->doorbell_bitmap;
struct guc_doorbell_info *doorbell;
-   struct guc_context_desc desc;
+   struct guc_context_desc *desc;
size_t len;
+   desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+   if (!desc)
+   return -ENOMEM;
+
doorbell = client->vaddr + client->doorbell_offset;
if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
@@ -116,15 +120,22 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
}
/* Update the GuC's idea of the doorbell ID */
-   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, &desc, sizeof(desc),
-sizeof(desc) * client->ctx_index);
-   if (len != sizeof(desc))
+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, desc, sizeof(*desc),
+sizeof(*desc) * client->ctx_index);

This is silly. You are creating a pointer using kmalloc to copy into a
pointer created using alloc_page. Just write directly into the backing
store.

I guess I deserve this for not digging any deeper. From what I can
see, the backing store is an array of 1024 context descriptors. If
the whole context descriptor fell in one page, I could kmap_atomic
only that. As it is, I would need to vmap a couple of pages to make
sure I always get a complete pointer to guc_context_desc. Would you
be happy with that?

One of the suggested usecases for i915_gem_object_pin_map() was this code.
-Chris


I considered it, but with the current interface that would mean vmapping 
the whole thing (something like 70 pages). Isn't that a bit overkill?
I know you are going to say it wastes memory, but (KISS) what about if I 
make guc_context_desc part of i915_guc_client, to be used for sg_pcopy 
operations?.
Although I am getting the vibe that you have discussed the sg_pcopy 
thing in the past, and this is not only about avoiding potential stack 
overflows. Am I right?


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/fb-helper: Explain unload sequence a bit better (rev3)

2017-02-07 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/fb-helper: Explain unload sequence a bit 
better (rev3)
URL   : https://patchwork.freedesktop.org/series/19242/
State : failure

== Summary ==

  CC  drivers/acpi/acpica/uterror.o
  CC  drivers/acpi/acpica/utglobal.o
  CC  drivers/acpi/acpica/uteval.o
  CC  drivers/acpi/acpica/uthex.o
  CC  drivers/acpi/acpica/utids.o
  CC  drivers/acpi/acpica/utinit.o
  CC  drivers/acpi/acpica/utlock.o
  CC  drivers/acpi/acpica/utmath.o
  CC  drivers/acpi/acpica/utmisc.o
  CC  drivers/acpi/acpica/utmutex.o
  CC  drivers/acpi/acpica/utnonansi.o
  CC  drivers/acpi/acpica/utobject.o
  CC  drivers/acpi/acpica/utosi.o
  CC  drivers/acpi/acpica/utownerid.o
  CC  drivers/acpi/acpica/utpredef.o
  CC  drivers/acpi/acpica/utresrc.o
  CC  drivers/acpi/acpica/utstate.o
  CC  drivers/acpi/acpica/utstring.o
  CC  drivers/acpi/acpica/utstrtoul64.o
  CC  drivers/acpi/acpica/utxface.o
  CC  drivers/acpi/acpica/utxfinit.o
  CC  drivers/acpi/acpica/utxferror.o
  CC  drivers/acpi/acpica/utxfmutex.o
  LD  net/unix/unix.o
  LD  drivers/scsi/scsi_mod.o
  LD  net/unix/built-in.o
  LD  drivers/video/fbdev/core/fb.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/tty/serial/8250/8250.o
  LD  drivers/pci/pcie/aer/aerdriver.o
  LD  drivers/pci/pcie/aer/built-in.o
  LD  drivers/pci/pcie/built-in.o
  LD  kernel/events/built-in.o
  LD [M]  drivers/ssb/ssb.o
  LD  drivers/usb/storage/usb-storage.o
  LD  kernel/sched/built-in.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/thermal/thermal_sys.o
  LD  kernel/built-in.o
  LD  drivers/thermal/built-in.o
  LD  drivers/iommu/built-in.o
  LD  drivers/acpi/acpica/acpi.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  LD  drivers/video/fbdev/built-in.o
  LD  sound/pci/built-in.o
  LD  drivers/usb/gadget/libcomposite.o
  LD  lib/raid6/raid6_pq.o
  LD  drivers/acpi/acpica/built-in.o
  LD  lib/raid6/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD  sound/built-in.o
  LD  drivers/acpi/built-in.o
  LD  net/packet/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/video/console/built-in.o
  LD  drivers/spi/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  drivers/pci/built-in.o
  LD  drivers/usb/gadget/built-in.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/scsi/built-in.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD  net/xfrm/built-in.o
  LD  net/ipv6/ipv6.o
  LD  net/ipv6/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/usb/core/built-in.o
  AR  lib/lib.a
  CC  arch/x86/kernel/cpu/capflags.o
  EXPORTS lib/lib-ksyms.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  lib/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  drivers/tty/built-in.o
  LD  fs/btrfs/btrfs.o
  LD  arch/x86/built-in.o
  LD  fs/btrfs/built-in.o
  LD  drivers/md/md-mod.o
  LD  drivers/md/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  net/ipv4/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  fs/ext4/ext4.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD  net/core/built-in.o
  LD  net/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:988: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
> 
> 
> On 02/02/2017 11:33 PM, Chris Wilson wrote:
> >On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
> >>From: Michal Wajdeczko 
> >>
> >>The GuC descriptor is big in size. If we use local definition of
> >>guc_desc we have a chance to overflow stack. Use allocated one.
> >>
> >>v2: Rebased
> >>v3: Split
> >>v4: Handle ENOMEM, cover all uses of guc_context_desc, use kzalloc (Oscar)
> >>
> >>Signed-off-by: Deepak S 
> >>Signed-off-by: Michal Wajdeczko 
> >>Signed-off-by: Oscar Mateo 
> >>---
> >>  drivers/gpu/drm/i915/i915_guc_submission.c | 94 
> >> ++
> >>  1 file changed, 57 insertions(+), 37 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >>b/drivers/gpu/drm/i915/i915_guc_submission.c
> >>index 8ced9e2..b4f14f3 100644
> >>--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >>+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >>@@ -102,9 +102,13 @@ static int guc_update_doorbell_id(struct intel_guc 
> >>*guc,
> >>struct sg_table *sg = guc->ctx_pool_vma->pages;
> >>void *doorbell_bitmap = guc->doorbell_bitmap;
> >>struct guc_doorbell_info *doorbell;
> >>-   struct guc_context_desc desc;
> >>+   struct guc_context_desc *desc;
> >>size_t len;
> >>+   desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> >>+   if (!desc)
> >>+   return -ENOMEM;
> >>+
> >>doorbell = client->vaddr + client->doorbell_offset;
> >>if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
> >>@@ -116,15 +120,22 @@ static int guc_update_doorbell_id(struct intel_guc 
> >>*guc,
> >>}
> >>/* Update the GuC's idea of the doorbell ID */
> >>-   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, &desc, sizeof(desc),
> >>-sizeof(desc) * client->ctx_index);
> >>-   if (len != sizeof(desc))
> >>+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, desc, sizeof(*desc),
> >>+sizeof(*desc) * client->ctx_index);
> >This is silly. You are creating a pointer using kmalloc to copy into a
> >pointer created using alloc_page. Just write directly into the backing
> >store.
> 
> I guess I deserve this for not digging any deeper. From what I can
> see, the backing store is an array of 1024 context descriptors. If
> the whole context descriptor fell in one page, I could kmap_atomic
> only that. As it is, I would need to vmap a couple of pages to make
> sure I always get a complete pointer to guc_context_desc. Would you
> be happy with that?

One of the suggested usecases for i915_gem_object_pin_map() was this code.
-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] ✓ Fi.CI.BAT: success for drm/i915: Restart all engines atomically

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915: Restart all engines atomically
URL   : https://patchwork.freedesktop.org/series/19249/
State : success

== Summary ==

Series 19249v1 drm/i915: Restart all engines atomically
https://patchwork.freedesktop.org/api/1.0/series/19249/revisions/1/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
fail   -> PASS   (fi-bxt-j4205)

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

b8157792b685dfcc86fa7dc23d66d663ad6fb93f drm-tip: 2017y-02m-07d-14h-55m-05s UTC 
integration manifest
42d2b17 drm/i915: Restart all engines atomically

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Restart all engines atomically

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 05:58:58PM +0200, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > When we restart the engines, and we have active requests, a request on
> > the first engine may complete and queue a request to the second engine
> > before we try to restart the second engine. That queueing of the
> > request may itself cause the engine to restart, and so the subsequent
> > handling by engine->init_hw() will corrupt the current state.
> >
> > If we restart all the engines under stop_machine(), we will not process
> > any interrupts as we restart the engines, and all the engines will
> > appear to start simultaneously from the snapshot of state.
> >
> > Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete 
> > requests")
> > Testcase: igt/gem_exec_fence/await-hang
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 34 +++---
> >  1 file changed, 27 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 8a510c7f6828..65651a889813 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4369,11 +4369,30 @@ static void init_unused_rings(struct 
> > drm_i915_private *dev_priv)
> > }
> >  }
> >  
> > -int
> > -i915_gem_init_hw(struct drm_i915_private *dev_priv)
> > +static int __i915_gem_restart_engines(void *data)
> >  {
> > +   struct drm_i915_private *i915 = data;
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> > +   int err;
> > +
> > +   /* We want all the engines to restart from the same snapshot, the
> > +* restart has to be appear simultaneous (i.e. atomic). If one
> > +* request on the first engine completes and queues a request for
> > +* a secodn engine, *before* we call init_hw on that second engine,
> s/secodn/second.
> 
> > +* we may corrupt state.
> > +*/
> > +   for_each_engine(engine, i915, id) {
> > +   err = engine->init_hw(engine);
> > +   if (err)
> > +   return err;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +int i915_gem_init_hw(struct drm_i915_private *dev_priv)
> > +{
> > int ret;
> >  
> > dev_priv->gt.last_init_time = ktime_get();
> > @@ -4419,11 +4438,12 @@ i915_gem_init_hw(struct drm_i915_private *dev_priv)
> > }
> >  
> > /* Need to do basic initialisation of all rings first: */
> > -   for_each_engine(engine, dev_priv, id) {
> > -   ret = engine->init_hw(engine);
> > -   if (ret)
> > -   goto out;
> > -   }
> > +   if (dev_priv->gt.active_requests)
> 
> This should only increment while mutex is held, so
> 
> Reviewed-by: Mika Kuoppala 
> 
> > +   ret = stop_machine(__i915_gem_restart_engines, dev_priv, NULL);

The important thing here is preventing concurrent running of
engine->init_hw() with the tasklet - as I hope nothing will happen if we
write to ELSP whilst the engine is not in execlists mode. For that
stop_machine() may be overkill, and I wonder if just playing around with
tasklet will be enough. Let me try a second patch...
-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 v2] drm/i915/guc: Make intel_guc_send a function pointer

2017-02-07 Thread Oscar Mateo

From: Michal Wajdeczko 

Prepare for an alternate GuC communication interface.

v2: Make a few functions static and name them correctly while we are at it 
(Oscar)
v3: Leave an intel_guc_send_mmio interface for users that require old-style 
communication

Signed-off-by: Michel Thierry 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_uc.c | 25 +++--
 drivers/gpu/drm/i915/intel_uc.h | 10 +-
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index c46bc85..2fa70a9 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -25,16 +25,11 @@
 #include "i915_drv.h"
 #include "intel_uc.h"
 
-void intel_uc_init_early(struct drm_i915_private *dev_priv)
-{
-   mutex_init(&dev_priv->guc.send_mutex);
-}
-
 /*
  * Read GuC command/status register (SOFT_SCRATCH_0)
  * Return true if it contains a response rather than a command
  */
-static bool intel_guc_recv(struct intel_guc *guc, u32 *status)
+static bool guc_recv(struct intel_guc *guc, u32 *status)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
@@ -43,7 +38,10 @@ static bool intel_guc_recv(struct intel_guc *guc, u32 
*status)
return INTEL_GUC_RECV_IS_RESPONSE(val);
 }
 
-int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
+/*
+ * This function implements the MMIO based host to GuC interface.
+ */
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
@@ -71,9 +69,9 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, 
u32 len)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No inte_guc_send command should ever take longer than 10ms.
 */
-   ret = wait_for_us(intel_guc_recv(guc, &status), 10);
+   ret = wait_for_us(guc_recv(guc, &status), 10);
if (ret)
-   ret = wait_for(intel_guc_recv(guc, &status), 10);
+   ret = wait_for(guc_recv(guc, &status), 10);
if (status != INTEL_GUC_STATUS_SUCCESS) {
/*
 * Either the GuC explicitly returned an error (which
@@ -98,6 +96,14 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, 
u32 len)
return ret;
 }
 
+void intel_uc_init_early(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = &dev_priv->guc;
+
+   mutex_init(&guc->send_mutex);
+   guc->send = intel_guc_send_mmio;
+}
+
 int intel_guc_sample_forcewake(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -113,4 +119,3 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
 
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
-
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index d74f4d3..8a33a46 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -174,6 +174,9 @@ struct intel_guc {
 
/* To serialize the intel_guc_send actions */
struct mutex send_mutex;
+
+   /* GuC's FW specific send function */
+   int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
 };
 
 struct intel_huc {
@@ -185,9 +188,14 @@ struct intel_huc {
 
 /* intel_uc.c */
 void intel_uc_init_early(struct drm_i915_private *dev_priv);
-int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len);
 int intel_guc_sample_forcewake(struct intel_guc *guc);
 
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len);
+static inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 
len)
+{
+   return guc->send(guc, action, len);
+}
+
 /* intel_guc_loader.c */
 extern void intel_guc_init(struct drm_i915_private *dev_priv);
 extern int intel_guc_setup(struct drm_i915_private *dev_priv);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dynamically alloc GuC descriptor

2017-02-07 Thread Oscar Mateo




On 02/02/2017 11:33 PM, Chris Wilson wrote:

On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:

From: Michal Wajdeczko 

The GuC descriptor is big in size. If we use local definition of
guc_desc we have a chance to overflow stack. Use allocated one.

v2: Rebased
v3: Split
v4: Handle ENOMEM, cover all uses of guc_context_desc, use kzalloc (Oscar)

Signed-off-by: Deepak S 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94 ++
  1 file changed, 57 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ced9e2..b4f14f3 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -102,9 +102,13 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
struct sg_table *sg = guc->ctx_pool_vma->pages;
void *doorbell_bitmap = guc->doorbell_bitmap;
struct guc_doorbell_info *doorbell;
-   struct guc_context_desc desc;
+   struct guc_context_desc *desc;
size_t len;
  
+	desc = kzalloc(sizeof(*desc), GFP_KERNEL);

+   if (!desc)
+   return -ENOMEM;
+
doorbell = client->vaddr + client->doorbell_offset;
  
  	if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&

@@ -116,15 +120,22 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
}
  
  	/* Update the GuC's idea of the doorbell ID */

-   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, &desc, sizeof(desc),
-sizeof(desc) * client->ctx_index);
-   if (len != sizeof(desc))
+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, desc, sizeof(*desc),
+sizeof(*desc) * client->ctx_index);

This is silly. You are creating a pointer using kmalloc to copy into a
pointer created using alloc_page. Just write directly into the backing
store.
-Chris



I guess I deserve this for not digging any deeper. From what I can see, 
the backing store is an array of 1024 context descriptors. If the whole 
context descriptor fell in one page, I could kmap_atomic only that. As 
it is, I would need to vmap a couple of pages to make sure I always get 
a complete pointer to guc_context_desc. Would you be happy with that?

___
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: Restore context and pd for ringbuffer submission after reset (rev3)

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915: Restore context and pd for ringbuffer submission after reset 
(rev3)
URL   : https://patchwork.freedesktop.org/series/19110/
State : success

== Summary ==

Series 19110v3 drm/i915: Restore context and pd for ringbuffer submission after 
reset
https://patchwork.freedesktop.org/api/1.0/series/19110/revisions/3/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
fail   -> PASS   (fi-bxt-j4205)

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

b8157792b685dfcc86fa7dc23d66d663ad6fb93f drm-tip: 2017y-02m-07d-14h-55m-05s UTC 
integration manifest
0ee7e6a drm/i915: Restore context and pd for ringbuffer submission after reset

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Make intel_guc_send a function pointer

2017-02-07 Thread Oscar Mateo





On 02/03/2017 03:48 AM, Michal Wajdeczko wrote:

On Thu, Feb 02, 2017 at 07:42:46AM -0800, Oscar Mateo wrote:

From: Michal Wajdeczko 

Prepare for an alternate GuC communication interface.

v2: Make a few functions static and name them correctly while we are at it 
(Oscar)

Signed-off-by: Michel Thierry 
Signed-off-by: Michal Wajdeczko 
Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/intel_uc.c | 25 +++--
  drivers/gpu/drm/i915/intel_uc.h |  9 -
  2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index c46bc85..0e45ef0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -25,16 +25,11 @@
  #include "i915_drv.h"
  #include "intel_uc.h"
  
-void intel_uc_init_early(struct drm_i915_private *dev_priv)

-{
-   mutex_init(&dev_priv->guc.send_mutex);
-}
-
  /*
   * Read GuC command/status register (SOFT_SCRATCH_0)
   * Return true if it contains a response rather than a command
   */
-static bool intel_guc_recv(struct intel_guc *guc, u32 *status)
+static bool guc_recv(struct intel_guc *guc, u32 *status)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
  
@@ -43,7 +38,10 @@ static bool intel_guc_recv(struct intel_guc *guc, u32 *status)

return INTEL_GUC_RECV_IS_RESPONSE(val);
  }
  
-int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)

+/*
+ * This function implements the MMIO based host to GuC interface.
+ */
+static int guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len)

Btw, while this change is fine for now, what if in the future we will need
MMIO based interface for some kind of OOB communication to GuC that bypasses
alternate interface?
I see. So you'd prefer to have an intel_guc_send for normal 
communication with the GuC and an intel_guc_send_mmio for the few cases 
where you want to fallback to a MMIO style? I'll change this and resend.

  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
u32 status;
@@ -71,9 +69,9 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, 
u32 len)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No inte_guc_send command should ever take longer than 10ms.
 */
-   ret = wait_for_us(intel_guc_recv(guc, &status), 10);
+   ret = wait_for_us(guc_recv(guc, &status), 10);
if (ret)
-   ret = wait_for(intel_guc_recv(guc, &status), 10);
+   ret = wait_for(guc_recv(guc, &status), 10);
if (status != INTEL_GUC_STATUS_SUCCESS) {
/*
 * Either the GuC explicitly returned an error (which
@@ -98,6 +96,14 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, 
u32 len)
return ret;
  }
  
+void intel_uc_init_early(struct drm_i915_private *dev_priv)

+{
+   struct intel_guc *guc = &dev_priv->guc;
+
+   mutex_init(&dev_priv->guc.send_mutex);

No need to use dev_priv here, you can refer to the guc directly.

Regards,
Michal

ACK. I'll fix it in the next version.


+   guc->send = guc_send_mmio;
+}
+
  int intel_guc_sample_forcewake(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -113,4 +119,3 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
  
  	return intel_guc_send(guc, action, ARRAY_SIZE(action));

  }
-
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index d74f4d3..aed8653 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -174,6 +174,9 @@ struct intel_guc {
  
  	/* To serialize the intel_guc_send actions */

struct mutex send_mutex;
+
+   /* GuC's FW specific send function */
+   int (*send)(struct intel_guc *guc, const u32 *data, u32 len);
  };
  
  struct intel_huc {

@@ -185,9 +188,13 @@ struct intel_huc {
  
  /* intel_uc.c */

  void intel_uc_init_early(struct drm_i915_private *dev_priv);
-int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  
+static inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)

+{
+   return guc->send(guc, action, len);
+}
+
  /* intel_guc_loader.c */
  extern void intel_guc_init(struct drm_i915_private *dev_priv);
  extern int intel_guc_setup(struct drm_i915_private *dev_priv);
--
1.9.1




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

Re: [Intel-gfx] [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-02-07 Thread Thierry Reding

On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 2/7/2017 4:31 PM, Jose Abreu wrote:
> > Hi Shashank,
> > 
> > 
> > 
> > On 06-02-2017 13:59, Shashank Sharma wrote:
> > > This patch does following:
> > > - Adds a new structure (drm_hdmi_info) in drm_display_info.
> > >This structure will be used to save and indicate if sink
> > >supports advanced HDMI 2.0 features
> > > - Adds another structure drm_scdc within drm_hdmi_info, to
> > >reflect scdc support and capabilities in connected HDMI 2.0 sink.
> > > - Checks the HF-VSDB block for presence of SCDC, and marks it
> > >in scdc structure
> > > - If SCDC is present, checks if sink is capable of generating
> > >SCDC read request, and marks it in scdc structure.
> > > 
> > > V2: Addressed review comments
> > > Thierry:
> > > - Fix typos in commit message and make abbreviation consistent
> > >across the commit message.
> > > - Change structure object name from hdmi_info -> hdmi
> > > - Fix typos and abbreviations in description of structure drm_hdmi_info
> > >end the description with a full stop.
> > > - Create a structure drm_scdc, and keep all information related to SCDC
> > >register set (supported, read request supported) etc in it.
> > > 
> > > Ville:
> > > - Change rr -> read_request
> > > - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
> > >of HF-VSDB parsing can be kept in same function, in incremental
> > >patches.
> > > 
> > > Reviewed-by: Thierry Reding 
> > > Signed-off-by: Shashank Sharma 
> > > ---
> > >   drivers/gpu/drm/drm_edid.c  | 14 ++
> > >   include/drm/drm_connector.h | 33 +
> > >   2 files changed, 47 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 96d3e47..a487b80 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
> > >   }
> > >   EXPORT_SYMBOL(drm_default_rgb_quant_range);
> > > +static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> > > +  const u8 *hf_vsdb)
> > > +{
> > > + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> > > +
> > > + if (hf_vsdb[6] & 0x80) {
> > BIT(7) ?
> Yes, SCDC_present bit is bit 7, byte 6 in HF-VSDB. Am I missing something ?
> > 
> > > + hdmi->scdc.supported = true;
> > > + if (hf_vsdb[6] & 0x40)
> > BIT(6) ?
> Yes, RR_Capable bit is bit 6, byte 6 in HF-VSDB.

I think what Jose was trying to say is that you should be using BIT(7)
instead of 0x80 and BIT(6) instead of 0x40. That said, I think either is
fine, but perhaps another idea would be to define macros for these. I
know that most (all?) of the EDID parsing code uses literals, so this is
consistent with existing code. Also usually code will be like:

if (hf_vsdb[X] & 0xYZ)
foo_supported = true;

So the meaning of the bit is easy to read from the context. I think
literals are fine in this case.

Thierry


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

2017-02-07 Thread Patchwork

== Series Details ==

Series: drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)
URL   : https://patchwork.freedesktop.org/series/19240/
State : failure

== Summary ==

Series 19240v1 drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)
https://patchwork.freedesktop.org/api/1.0/series/19240/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-bxt-t5700)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> INCOMPLETE (fi-skl-6700k)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-ilk-650)
pass   -> INCOMPLETE (fi-hsw-4770r)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-bdw-5557u)

fi-bdw-5557u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bsw-n3050 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bxt-j4205 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-bxt-t5700 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-j1900 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-byt-n2820 total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770r total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ilk-650   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-ivb-3770  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7500u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6260u total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6700k total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-skl-6770hqtotal:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2520m total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  

b8157792b685dfcc86fa7dc23d66d663ad6fb93f drm-tip: 2017y-02m-07d-14h-55m-05s UTC 
integration manifest
23cf9f6 drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Sean Paul

On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
> 
> v2: Forgot to git add everything :(
> 
> v3: Actually remove release_fbi (Sean, Emil, Chris) ...
> 
> Cc: Chris Wilson 
> Cc: Sean Paul 
> Cc: Noralf Trønnes 
> Cc: Emil Velikov 

Reviewed-by: Sean Paul 

> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 +++
>  drivers/gpu/drm/armada/armada_fbdev.c |  2 --
>  drivers/gpu/drm/ast/ast_fb.c  |  9 ++
>  drivers/gpu/drm/bochs/bochs_fbdev.c   |  5 +--
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  1 -
>  drivers/gpu/drm/drm_fb_cma_helper.c   |  3 +-
>  drivers/gpu/drm/drm_fb_helper.c   | 39 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 --
>  drivers/gpu/drm/gma500/framebuffer.c  |  9 ++
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  2 --
>  drivers/gpu/drm/i915/intel_fbdev.c|  5 +--
>  drivers/gpu/drm/mgag200/mgag200_fb.c  |  5 +--
>  drivers/gpu/drm/msm/msm_fbdev.c   |  1 -
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  1 -
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  |  4 ---
>  drivers/gpu/drm/qxl/qxl_fb.c  |  5 +--
>  drivers/gpu/drm/radeon/radeon_fb.c| 11 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  9 ++
>  drivers/gpu/drm/tegra/fb.c|  5 +--
>  drivers/gpu/drm/udl/udl_fb.c  |  5 +--
>  drivers/gpu/drm/virtio/virtgpu_fb.c   |  5 +--
>  include/drm/drm_fb_helper.h   |  4 ---
>  22 files changed, 39 insertions(+), 104 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 838943d0962e..f4a2f1f0a6ca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>   info = drm_fb_helper_alloc_fbi(helper);
>   if (IS_ERR(info)) {
>   ret = PTR_ERR(info);
> - goto out_unref;
> + goto out;
>   }
>  
>   info->par = rfbdev;
> @@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>   ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd, 
> gobj);
>   if (ret) {
>   DRM_ERROR("failed to initialize framebuffer %d\n", ret);
> - goto out_destroy_fbi;
> + goto out;
>   }
>  
>   fb = &rfbdev->rfb.base;
> @@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>  
>   if (info->screen_base == NULL) {
>   ret = -ENOSPC;
> - goto out_destroy_fbi;
> + goto out;
>   }
>  
>   DRM_INFO("fb mappable at 0x%lX\n",  info->fix.smem_start);
> @@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>   vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
>   return 0;
>  
> -out_destroy_fbi:
> - drm_fb_helper_release_fbi(helper);
> -out_unref:
> +out:
>   if (abo) {
>  
>   }
> @@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev, 
> struct amdgpu_fbdev *rfb
>   struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
>  
>   drm_fb_helper_unregister_fbi(&rfbdev->helper);
> - drm_fb_helper_release_fbi(&rfbdev->helper);
>  
>   if (rfb->obj) {
>   amdgpufb_destroy_pinned_object(rfb->obj);
> diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
> b/drivers/gpu/drm/armada/armada_fbdev.c
> index 78335100cbc3..7f184a52594e 100644
> --- a/drivers/gpu/drm/armada/armada_fbdev.c
> +++ b/drivers/gpu/drm/armada/armada_fbdev.c
> @@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
>  
>   return 0;
>   err_fb_setup:
> - drm_fb_helper_release_fbi(fbh);
>   drm_fb_helper_fini(fbh);
>   err_fb_helper:
>   priv->fbdev = NULL;
> @@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
>  
>   if (fbh) {
>   drm_fb_helper_unregister_fbi(fbh);
> - drm_fb_helper_release_fbi(fbh);
>  
>   drm_fb_helper_fini(fbh);
>  
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index b085140fae95..f8421d23946a 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
>   info = drm_fb_helper_alloc_fbi(helper);
>   if (IS_ERR(info)) {
>   ret = PTR_ERR(info);
> - goto err_free_vram;
> + goto out;
>   }
>   info->par = afbdev;
>  
>   ret = ast_framebuffer_init(dev, &afbdev->afb,

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

2017-02-07 Thread Sharma, Shashank


Regards

Shashank


On 2/7/2017 4:44 PM, Jose Abreu wrote:

Hi Shashank,



On 06-02-2017 13:59, Shashank Sharma wrote:

HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.

This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.

V2: Addressed review comments from Thierry, Ville and Dhinakaran
Thierry:
- Mhz -> MHz in comments and commit message.
- i2c -> I2C in comments.
- Fix the function documentations, keep in sync with drm_scdc_helper.c
- drm_connector -> DRM connector.
- Create structure for SCDC, and save scrambling status inside that,
   in a sub-structure.
- Call this sub-structure scrambling instead of scr_info.
- low_rates -> low_clocks in scrambling status structure.
- Store the return value of I2C read/write and print the error code
 in case of failure.

Thierry and Ville:
- Move the scrambling enable/disable/query functions in
   drm_scdc_helper.c file.
- Add drm_SCDC prefix for the functions.
- Optimize the return statement from function
   drm_SCDC_check_scrambling_status.

Ville:
- Dont overwrite saved max TMDS clock value in display_info,
   if max tmds clock from HF-VSDB is not > 340 MHz.
- drm_detect_hdmi_scrambling -> drm_parse_hdmi_forum_vsdb.
- Remove dynamic tracking of SCDC status from DRM layer, force bool.
- Program clock ratio bit also, while enabling scrambling.

Dhinakaran:
  - Add a comment about *5000 while extracting max clock supported.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c|  33 -
  drivers/gpu/drm/drm_scdc_helper.c | 100 ++
  include/drm/drm_connector.h   |  19 
  include/drm/drm_edid.h|   6 ++-
  include/drm/drm_scdc_helper.h |  20 
  5 files changed, 176 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a487b80..dc85eb9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define version_greater(edid, maj, min) \

(((edid)->version > (maj)) || \
@@ -3805,13 +3806,43 @@ enum hdmi_quantization_range
  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
  {
-   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+   struct drm_display_info *display = &connector->display_info;
+   struct drm_hdmi_info *hdmi = &display->hdmi;
  
  	if (hf_vsdb[6] & 0x80) {

hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   /* max clock is 5000 KHz times block value */
+   u32 max_tmds_clock = hf_vsdb[5] * 5000;
+   struct drm_scdc *scdc = &hdmi->scdc;
+
+   if (max_tmds_clock > 34) {
+   display->max_tmds_clock = max_tmds_clock;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+   }
+
+   if (scdc->supported) {
+   scdc->scrambling.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))

BIT(3) ?
Yes, bit 3 is LTE_340Mcsc_scramble, indicating that the sink support 
scrambling at rates below 340Mhz too, isn't it ?



+   scdc->scrambling.low_rates = true;
+   }
+   }
  }
  
  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index fe0e121..311f62e 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
   */
  
  #include 

+#include 
  
  #include 

+#include 
  
  /**

   * DOC: scdc helpers
@@ -109,3 +111,101 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
offset,
return err;
  }
  EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambli

[Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Daniel Vetter

Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!

v2: Forgot to git add everything :(

v3: Actually remove release_fbi (Sean, Emil, Chris) ...

Cc: Chris Wilson 
Cc: Sean Paul 
Cc: Noralf Trønnes 
Cc: Emil Velikov 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 +++
 drivers/gpu/drm/armada/armada_fbdev.c |  2 --
 drivers/gpu/drm/ast/ast_fb.c  |  9 ++
 drivers/gpu/drm/bochs/bochs_fbdev.c   |  5 +--
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  1 -
 drivers/gpu/drm/drm_fb_cma_helper.c   |  3 +-
 drivers/gpu/drm/drm_fb_helper.c   | 39 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 --
 drivers/gpu/drm/gma500/framebuffer.c  |  9 ++
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  2 --
 drivers/gpu/drm/i915/intel_fbdev.c|  5 +--
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  5 +--
 drivers/gpu/drm/msm/msm_fbdev.c   |  1 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  1 -
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  4 ---
 drivers/gpu/drm/qxl/qxl_fb.c  |  5 +--
 drivers/gpu/drm/radeon/radeon_fb.c| 11 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  9 ++
 drivers/gpu/drm/tegra/fb.c|  5 +--
 drivers/gpu/drm/udl/udl_fb.c  |  5 +--
 drivers/gpu/drm/virtio/virtgpu_fb.c   |  5 +--
 include/drm/drm_fb_helper.h   |  4 ---
 22 files changed, 39 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..f4a2f1f0a6ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
-   goto out_unref;
+   goto out;
}
 
info->par = rfbdev;
@@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd, 
gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
-   goto out_destroy_fbi;
+   goto out;
}
 
fb = &rfbdev->rfb.base;
@@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
 
if (info->screen_base == NULL) {
ret = -ENOSPC;
-   goto out_destroy_fbi;
+   goto out;
}
 
DRM_INFO("fb mappable at 0x%lX\n",  info->fix.smem_start);
@@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
return 0;
 
-out_destroy_fbi:
-   drm_fb_helper_release_fbi(helper);
-out_unref:
+out:
if (abo) {
 
}
@@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev, 
struct amdgpu_fbdev *rfb
struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
 
drm_fb_helper_unregister_fbi(&rfbdev->helper);
-   drm_fb_helper_release_fbi(&rfbdev->helper);
 
if (rfb->obj) {
amdgpufb_destroy_pinned_object(rfb->obj);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 78335100cbc3..7f184a52594e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
 
return 0;
  err_fb_setup:
-   drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
  err_fb_helper:
priv->fbdev = NULL;
@@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
 
if (fbh) {
drm_fb_helper_unregister_fbi(fbh);
-   drm_fb_helper_release_fbi(fbh);
 
drm_fb_helper_fini(fbh);
 
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index b085140fae95..f8421d23946a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
-   goto err_free_vram;
+   goto out;
}
info->par = afbdev;
 
ret = ast_framebuffer_init(dev, &afbdev->afb, &mode_cmd, gobj);
if (ret)
-   goto err_release_fbi;
+   goto out;
 
afbdev->sysram = sysram;
afbdev->size = size;
@@ -250,9 +250,7 @@ static int astfb_create(struct drm_fb_helper *helper,
 
retur

Re: [Intel-gfx] [PATCH v2 3/6] drm/edid: detect SCDC support in HF-VSDB

2017-02-07 Thread Sharma, Shashank


Regards

Shashank


On 2/7/2017 4:31 PM, Jose Abreu wrote:

Hi Shashank,



On 06-02-2017 13:59, Shashank Sharma wrote:

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
   This structure will be used to save and indicate if sink
   supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
   reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
   in scdc structure
- If SCDC is present, checks if sink is capable of generating
   SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
   across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
   end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
   register set (supported, read request supported) etc in it.

Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
   of HF-VSDB parsing can be kept in same function, in incremental
   patches.

Reviewed-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 14 ++
  include/drm/drm_connector.h | 33 +
  2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 96d3e47..a487b80 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
  }
  EXPORT_SYMBOL(drm_default_rgb_quant_range);
  
+static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,

+const u8 *hf_vsdb)
+{
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+   if (hf_vsdb[6] & 0x80) {

BIT(7) ?

Yes, SCDC_present bit is bit 7, byte 6 in HF-VSDB. Am I missing something ?



+   hdmi->scdc.supported = true;
+   if (hf_vsdb[6] & 0x40)

BIT(6) ?

Yes, RR_Capable bit is bit 6, byte 6 in HF-VSDB.



+   hdmi->scdc.read_request = true;
+   }
+}
+
  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
   const u8 *hdmi)
  {
@@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
  
  		if (cea_db_is_hdmi_vsdb(db))

drm_parse_hdmi_vsdb_video(connector, db);
+   if (cea_db_is_hdmi_forum_vsdb(db))
+   drm_parse_hdmi_forum_vsdb(connector, db);
}
  }
  
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h

index e5e1edd..6d5304e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,34 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/*
+ * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
+ *
+ * Provides SCDC register support and capabilities related information on a
+ * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
+ */
+struct drm_scdc {
+   /**
+* @supported: status control & data channel present.
+*/
+   bool supported;
+   /**
+* @read_request: sink is capable of generating scdc read request.
+*/
+   bool read_request;
+};
+
+/**
+ * struct drm_hdmi_info - runtime information about the connected HDMI sink
+ *
+ * Describes if a given display supports advanced HDMI 2.0 features.
+ * This information is available in CEA-861-F extension blocks (like HF-VSDB).
+ */
+struct drm_hdmi_info {
+   struct drm_scdc scdc;
  };
  
  /**

@@ -188,6 +216,11 @@ struct drm_display_info {
 * @cea_rev: CEA revision of the HDMI sink.
 */
u8 cea_rev;
+
+   /**
+* @hdmi: advance features of a HDMI sink.

Maybe change to the same general description you used above:
"Runtime information about the connected HDMI sink" ?
Actually the description I used in patch set 1, was similar, but this is 
based on feedbacks from review set 1.

- Shashank

+*/
+   struct drm_hdmi_info hdmi;
  };
  
  int drm_display_info_set_bus_formats(struct drm_display_info *info,

Best regards,
Jose Miguel Abreu


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

Re: [Intel-gfx] [PATCH v2 1/6] drm: Add SCDC helpers

2017-02-07 Thread Sharma, Shashank


Thanks for the review Jose, my comments inline.


Regards

Shashank


On 2/7/2017 4:24 PM, Jose Abreu wrote:

Hi Shashank,


Sorry for the late review.


On 06-02-2017 13:59, Shashank Sharma wrote:

From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
---
  Documentation/gpu/drm-kms-helpers.rst |  12 
  drivers/gpu/drm/Makefile  |   3 +-
  drivers/gpu/drm/drm_scdc_helper.c | 111 
  include/drm/drm_scdc_helper.h | 132 ++
  4 files changed, 257 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
  create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
  .. kernel-doc:: drivers/gpu/drm/drm_edid.c
 :export:
  
+SCDC Helper Functions Reference

+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
  Rectangle Utilities Reference
  =
  
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile

index 92de399..ad91cd9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-   drm_simple_kms_helper.o drm_modeset_helper.o
+   drm_simple_kms_helper.o drm_modeset_helper.o \
+   drm_scdc_helper.o
  
  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o

  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..fe0e121
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * 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, sub license,
+ * 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 NON-INFRINGEMENT. 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.
+ */
+
+#include 
+
+#include 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * The number of bytes read from SCDC or a negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+   struct i2c_msg msgs[2] = {
+   {
+   .addr = SCDC_I2C_SLAVE_ADDRESS,
+   .flags = 0,
+   .len = 1,

.len = sizeof(offset) ?
Technically correct, but wouldn't that mean that we are expecting to 
have I2C offsets with length more than

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Daniel Vetter

On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> > On 7 February 2017 at 14:29, Daniel Vetter  wrote:
> > > Noticed that everyone duplicates the same logic here and we could safe
> > > a few lines per driver. Yay for lots of drivers to make such tiny
> > > refactors worth-while!
> > >
> > > v2: Forgot to git add everything :(
> > >
> > Hmm afaict this patch inlines drm_fb_helper_release_fbi within
> > drm_fb_helper_fini yet it is missing:
> >  - removal of the (now unused ?) drm_fb_helper_release_fbi

Uh right, somehow I forgot about that one ...

> >  - the leaks which now occur in the error paths.
> 
> The error cleanup is a bit unobvious. The fbi is allocated during the
> create/initial_fb callback, which is after a successful
> framebuffer_init. The caller must be prepared to do a framebuffer_fini
> (and so release_fbi will be handled if required) on failure or success.

Yup, Chris is right, and I updated the kerneldoc to explain this.
-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

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: enable scrambling

2017-02-07 Thread Sharma, Shashank


Regards

Shashank


On 2/7/2017 3:51 PM, Jani Nikula wrote:

On Mon, 06 Feb 2017, Shashank Sharma  wrote:

Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

Throughout this series, but particularly in this patch, I'd prefer using
the term "sink" instead of "monitor" everywhere. The HDMI specifications
use source and sink almost exclusively.

BR,
Jani.

Sure, can be done.
- Shashank



V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h   |  2 ++
  drivers/gpu/drm/i915/intel_ddi.c  | 26 +++
  drivers/gpu/drm/i915/intel_drv.h  | 11 ++
  drivers/gpu/drm/i915/intel_hdmi.c | 70 +++
  4 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 495b789..cc85892 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7807,6 +7807,8 @@ enum {
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
  #define  TRANS_DDI_BFI_ENABLE (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
  
  /* DisplayPort Transport Control */

  #define _DP_TP_CTL_A  0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a9a670..cc7e091 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (IS_GEMINILAKE(dev_priv))
+   temp = intel_hdmi_handle_source_scrambling(
+   intel_encoder,
+   &intel_crtc->config->base.adjusted_mode, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1845,6 +1850,21 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
  
+		if (IS_GEMINILAKE(dev_priv)) {

+   /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by monitor, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+   intel_hdmi_handle_monitor_scrambling(intel_encoder,
+   conn_state->connector,
+   intel_crtc->config,
+   true);
+   }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
@@ -1885,6 +1905,12 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder,
intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
}
  
+	if (type == INTEL_OUTPUT_HDMI) {

+   intel_hdmi_handle_monitor_scrambling(intel_encoder,
+   old_conn_state->connector,
+   intel_crtc->config, false);
+   }
+
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
  
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index 393f243..300353c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -681,6 +681,9 @@ struct intel_crtc_state {
  
  	/* Gamma mode programmed on the pipe */

uint32_t gamma_mode;
+
+   /* HDMI scrambling status (monitor) */
+   bool scrambling;
  };
  
  struct vlv_wm_state {

@@ -1588,6 +1591,14 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_co

Re: [Intel-gfx] [PATCH] drm/i915: Restart all engines atomically

2017-02-07 Thread Mika Kuoppala

Chris Wilson  writes:

> When we restart the engines, and we have active requests, a request on
> the first engine may complete and queue a request to the second engine
> before we try to restart the second engine. That queueing of the
> request may itself cause the engine to restart, and so the subsequent
> handling by engine->init_hw() will corrupt the current state.
>
> If we restart all the engines under stop_machine(), we will not process
> any interrupts as we restart the engines, and all the engines will
> appear to start simultaneously from the snapshot of state.
>
> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
> Testcase: igt/gem_exec_fence/await-hang
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 34 +++---
>  1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8a510c7f6828..65651a889813 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4369,11 +4369,30 @@ static void init_unused_rings(struct drm_i915_private 
> *dev_priv)
>   }
>  }
>  
> -int
> -i915_gem_init_hw(struct drm_i915_private *dev_priv)
> +static int __i915_gem_restart_engines(void *data)
>  {
> + struct drm_i915_private *i915 = data;
>   struct intel_engine_cs *engine;
>   enum intel_engine_id id;
> + int err;
> +
> + /* We want all the engines to restart from the same snapshot, the
> +  * restart has to be appear simultaneous (i.e. atomic). If one
> +  * request on the first engine completes and queues a request for
> +  * a secodn engine, *before* we call init_hw on that second engine,
s/secodn/second.

> +  * we may corrupt state.
> +  */
> + for_each_engine(engine, i915, id) {
> + err = engine->init_hw(engine);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +int i915_gem_init_hw(struct drm_i915_private *dev_priv)
> +{
>   int ret;
>  
>   dev_priv->gt.last_init_time = ktime_get();
> @@ -4419,11 +4438,12 @@ i915_gem_init_hw(struct drm_i915_private *dev_priv)
>   }
>  
>   /* Need to do basic initialisation of all rings first: */
> - for_each_engine(engine, dev_priv, id) {
> - ret = engine->init_hw(engine);
> - if (ret)
> - goto out;
> - }
> + if (dev_priv->gt.active_requests)

This should only increment while mutex is held, so

Reviewed-by: Mika Kuoppala 

> + ret = stop_machine(__i915_gem_restart_engines, dev_priv, NULL);
> + else
> + ret = __i915_gem_restart_engines(dev_priv);
> + if (ret)
> + goto out;
>  
>   intel_mocs_init_l3cc_table(dev_priv);
>  
> -- 
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Sean Paul

On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
> 
> Cc: Chris Wilson 
> Cc: Sean Paul 
> Cc: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 ---
>  drivers/gpu/drm/armada/armada_fbdev.c |  2 --
>  drivers/gpu/drm/ast/ast_fb.c  |  9 +++--
>  drivers/gpu/drm/bochs/bochs_fbdev.c   |  5 +
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  1 -
>  drivers/gpu/drm/drm_fb_cma_helper.c   |  3 +--
>  drivers/gpu/drm/drm_fb_helper.c   | 16 ++--
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 --
>  drivers/gpu/drm/gma500/framebuffer.c  |  9 +++--
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  3 +--
>  drivers/gpu/drm/i915/intel_fbdev.c|  5 +
>  drivers/gpu/drm/mgag200/mgag200_fb.c  |  5 +
>  drivers/gpu/drm/msm/msm_fbdev.c   |  1 -
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  1 -
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  |  4 
>  drivers/gpu/drm/qxl/qxl_fb.c  |  5 +
>  drivers/gpu/drm/radeon/radeon_fb.c| 11 ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  9 +++--
>  drivers/gpu/drm/tegra/fb.c|  5 +
>  drivers/gpu/drm/udl/udl_fb.c  |  5 +
>  drivers/gpu/drm/virtio/virtgpu_fb.c   |  5 +
>  include/drm/drm_fb_helper.h   |  4 
>  22 files changed, 40 insertions(+), 81 deletions(-)
> 

Driver changes look good. I'll echo Emil's comments about removing
drm_fb_helper_release_fbi() from drm_fb_helper.c

Sean




-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Restore context and pd for ringbuffer submission after reset

2017-02-07 Thread Mika Kuoppala

Chris Wilson  writes:

> Following a reset, the context and page directory registers are lost.
> However, the queue of requests that we resubmit after the reset may
> depend upon them - the registers are restored from a context image, but
> that restore may be inhibited and may simply be absent from the request
> if it was in the middle of a sequence using the same context. If we
> prime the CCID/PD registers with the first request in the queue (even
> for the hung request), we prevent invalid memory access for the
> following requests (and continually hung engines).
>
> v2: Magic BIT(8), reserved for future use but still appears unused.
> v3: Some commentary on handling innocent vs guilty requests
> v4: Add a wait for PD_BASE fetch. The reload appears to be instant on my
> Ivybridge, but this bit probably exists for a reason.
>
> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 18 --
>  drivers/gpu/drm/i915/i915_reg.h |  6 ++--
>  drivers/gpu/drm/i915/intel_lrc.c| 16 -
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 58 
> +++--
>  4 files changed, 81 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8a510c7f6828..b7632bbbafd8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2743,21 +2743,17 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   engine->irq_seqno_barrier(engine);
>  
>   request = i915_gem_find_active_request(engine);
> - if (!request)
> - return;
> -
> - if (!i915_gem_reset_request(request))
> - return;
> + if (request && i915_gem_reset_request(request)) {
> + DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
> 0x%x\n",
> +  engine->name, request->global_seqno);
>  
> - DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 0x%x\n",
> -  engine->name, request->global_seqno);
> + /* If this context is now banned, skip all pending requests. */
> + if (i915_gem_context_is_banned(request->ctx))
> + engine_skip_context(request);
> + }
>  
>   /* Setup the CS to resume from the breadcrumb of the hung request */
>   engine->reset_hw(engine, request);
> -
> - /* If this context is now banned, skip all of its pending requests. */
> - if (i915_gem_context_is_banned(request->ctx))
> - engine_skip_context(request);
>  }
>  
>  void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5bf36bdc5926..4a59091c0152 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3323,8 +3323,10 @@ enum skl_disp_power_wells {
>  /*
>   * Logical Context regs
>   */
> -#define CCID _MMIO(0x2180)
> -#define   CCID_EN(1<<0)
> +#define CCID _MMIO(0x2180)
> +#define   CCID_ENBIT(0)
> +#define   CCID_EXTENDED_STATE_RESTOREBIT(2)
> +#define   CCID_EXTENDED_STATE_SAVE   BIT(3)
>  /*
>   * Notes on SNB/IVB/VLV context size:
>   * - Power context is saved elsewhere (LLC or stolen)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index df8e6f74dc7e..e42990b56fa8 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1352,7 +1352,20 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
> struct drm_i915_gem_request *request)
>  {
>   struct execlist_port *port = engine->execlist_port;
> - struct intel_context *ce = &request->ctx->engine[engine->id];
> + struct intel_context *ce;
> +
> + /* If the request was innocent, we leave the request in the ELSP
> +  * and will try to replay it on restarting. The context image may
> +  * have been corrupted by the reset, in which case we may have
> +  * to service a new GPU hang, but more likely we can continue on
> +  * without impact.
> +  *
> +  * If the request was guilty, we presume the context is corrupt
> +  * and have to at least restore the RING register in the context
> +  * image back to the expected values to skip over the guilty request.
> +  */
> + if (!request || request->fence.error != -EIO)
> + return;
>  
>   /* We want a simple context + ring to execute the breadcrumb update.
>* We cannot rely on the context being intact across the GPU hang,
> @@ -1361,6 +1374,7 @@ static void reset_common_ring(struct intel_engine_cs 
> *engine,
>* future request will be after userspace has had

[Intel-gfx] [PATCH] drm/i915: Restart all engines atomically

2017-02-07 Thread Chris Wilson

When we restart the engines, and we have active requests, a request on
the first engine may complete and queue a request to the second engine
before we try to restart the second engine. That queueing of the
request may itself cause the engine to restart, and so the subsequent
handling by engine->init_hw() will corrupt the current state.

If we restart all the engines under stop_machine(), we will not process
any interrupts as we restart the engines, and all the engines will
appear to start simultaneously from the snapshot of state.

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Testcase: igt/gem_exec_fence/await-hang
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a510c7f6828..65651a889813 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4369,11 +4369,30 @@ static void init_unused_rings(struct drm_i915_private 
*dev_priv)
}
 }
 
-int
-i915_gem_init_hw(struct drm_i915_private *dev_priv)
+static int __i915_gem_restart_engines(void *data)
 {
+   struct drm_i915_private *i915 = data;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+   int err;
+
+   /* We want all the engines to restart from the same snapshot, the
+* restart has to be appear simultaneous (i.e. atomic). If one
+* request on the first engine completes and queues a request for
+* a secodn engine, *before* we call init_hw on that second engine,
+* we may corrupt state.
+*/
+   for_each_engine(engine, i915, id) {
+   err = engine->init_hw(engine);
+   if (err)
+   return err;
+   }
+
+   return 0;
+}
+
+int i915_gem_init_hw(struct drm_i915_private *dev_priv)
+{
int ret;
 
dev_priv->gt.last_init_time = ktime_get();
@@ -4419,11 +4438,12 @@ i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
 
/* Need to do basic initialisation of all rings first: */
-   for_each_engine(engine, dev_priv, id) {
-   ret = engine->init_hw(engine);
-   if (ret)
-   goto out;
-   }
+   if (dev_priv->gt.active_requests)
+   ret = stop_machine(__i915_gem_restart_engines, dev_priv, NULL);
+   else
+   ret = __i915_gem_restart_engines(dev_priv);
+   if (ret)
+   goto out;
 
intel_mocs_init_l3cc_table(dev_priv);
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

2017-02-07 Thread Imre Deak

On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes
> which parts of the main surface are compressed and which are not. The
> location of CCS is provided by userspace as just another plane with its
> own offset.
> 
> Add the required stuff to validate the user provided AUX plane metadata
> and convert the user provided linear offset into something the hardware
> can consume.
> 
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with NV12), so finding suitable
> offsets for both requires a bit of work. Assuming we still want keep
> playing tricks with the offsets. I've just gone with a dumb "search
> backward for suitable offsets" approach, which is far from optimal,
> but it works.
> 
> Also not all planes will be capable of scanning out compressed surfaces,
> and eg. 90/270 degree rotation is not supported in combination with
> decompression either.
> 
> This patch may contain work from at least the following people:
> * Vandana Kannan 
> * Daniel Vetter 
> * Ben Widawsky 
> 
> v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
> 
> Cc: Paulo Zanoni 
> Cc: Vandana Kannan 
> Cc: Daniel Vetter 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  23 
>  drivers/gpu/drm/i915/intel_display.c | 234 
> ---
>  drivers/gpu/drm/i915/intel_pm.c  |  29 -
>  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
>  4 files changed, 274 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa77afa..6849ba93f1d9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6209,6 +6209,28 @@ enum {
>   _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
>   _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>  
> +#define PLANE_AUX_DIST_1_A   0x701c0
> +#define PLANE_AUX_DIST_2_A   0x702c0
> +#define PLANE_AUX_DIST_1_B   0x711c0
> +#define PLANE_AUX_DIST_2_B   0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> +#define _PLANE_AUX_DIST_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane) \
> + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A 0x701c4
> +#define PLANE_AUX_OFFSET_2_A 0x702c4
> +#define PLANE_AUX_OFFSET_1_B 0x711c4
> +#define PLANE_AUX_OFFSET_2_B 0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe)   \
> + _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> +#define _PLANE_AUX_OFFSET_2(pipe)   \
> + _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> +#define PLANE_AUX_OFFSET(pipe, plane)   \
> + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
> +
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> @@ -6433,6 +6455,7 @@ enum {
>  # define CHICKEN3_DGMG_DONE_FIX_DISABLE  (1 << 2)
>  
>  #define CHICKEN_PAR1_1   _MMIO(0x42080)
> +#define  SKL_RC_HASH_OUTSIDE (1 << 15)
>  #define  DPA_MASK_VBLANK_SRD (1 << 15)
>  #define  FORCE_ARB_IDLE_PLANES   (1 << 14)
>  #define  SKL_EDP_PSR_FIX_RDWRAP  (1 << 3)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 38de9df0ec60..2236abebd8bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> *fb, int plane)
>   return 128;
>   else
>   return 512;
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + if (plane == 1)
> + return 64;
> + /* fall through */
>   case I915_FORMAT_MOD_Y_TILED:
>   if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
>   return 128;
>   else
>   return 512;
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + if (plane == 1)
> + return 64;
> + /* fall through */
>   case I915_FORMAT_MOD_Yf_TILED:
>   /*
>* Bspec seems to suggest that the Yf tile width would
> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 
> drm

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-07 Thread Ville Syrjälä

On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
> On 07/02/17 15:22, Uwe Kleine-König wrote:
> > Hello,
> >
> > On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> >> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> >>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
>  On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
> > Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
> > Just curious, does this help?
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ae2c0bb4b2e8..13de4c526ca6 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
> > intel_crtc_state *cstate,
> >  * this is necessary to avoid flickering.
> >  */
> > int cpp = 4;
> > -   int width = pstate->base.visible ? pstate->base.crtc_w : 64;
> > +   int width = 256;
> >
> > if (!cstate->base.active)
> > return 0;
> >
>  On a kernel with this patch applied I cannot reproduce the flickering. I
>  keep that kernel running but expect that it also fixes the crash.
> >>>
> >>> Ok that's good news.
> >>>
> >>> Maybe ville or matt can comment whether this patch is the right fix?
> >>
> >> Well, it's just extending the hack even further. The right fix would be
> >> to fix the wm programming sequence to respect the frame boundaries
> >> correctly (ie. my old vblank based wm stuff).
> >
> > so I wonder how this goes forward. The situation seems to be well
> > understood, but other than testing patches I don't know what to do (and
> > there is currently no patch to test).
> >
> > Best regards
> > Uwe
> >
> 
> The way I understand this is that no-one wants to restrict the 
> capabilities exposed by the kernel and would like a proper fix for this. 
> However, I agree with Uwe, given the low priority status of Gen5 (people 
> would rather work on hw that is used by a lot of people), we should 
> probably accept the patch proposed by Maarten as it fixes someone's 
> workflow and does not regress anything meaningful.

The same code is used for ILK-BDW, so it's not just ILK. And other other
platform suffers from the same problem of cursor vs. watermarks. It just
seems that most people are lucky enough to not be seriously affected by
this problem.

Also it can regress some things, at least theoretically. Power consumption
with < 256x256 for one, and potentially it could also end up rejecting
some display modes that previously used to work with smaller cursor
sizes (or no cursors). That last part may not be 100% true, but I was
too lazy to go through the math to see if the cursor FIFO could end up
being the limiting factor in some cases.

I was thinking Maarten's intel_legacy_cursor_update() hack should have
"fixed" this, but now I'm not sure since it still sets the
legacy_cursor_update flag in the slow path, and the commit message
didn't quite manage to tell me what the purpose of this function 
was supposed to be. The logic for picking the slow path also seems a
little wonky to me (assuming I deduced the purpose of the function
correctly).

So, we might want something like:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 88689a0b4183..307ee4f7bd58 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15053,8 +15053,7 @@ intel_legacy_cursor_update(struct drm_plane *plane,
old_plane_state->src_h != src_h ||
old_plane_state->crtc_w != crtc_w ||
old_plane_state->crtc_h != crtc_h ||
-   !old_plane_state->visible ||
-   old_plane_state->fb->modifier != fb->modifier)
+   !old_plane_state->fb != !fb)
goto slow;
 
new_plane_state = intel_plane_duplicate_state(plane);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ec16f3d6dd2e..660990a3f276 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1865,20 +1865,26 @@ static uint32_t ilk_compute_cur_wm(const struct 
intel_crtc_state *cstate,
   const struct intel_plane_state *pstate,
   uint32_t mem_value)
 {
+   int cpp;
+
/*
-* We treat the cursor plane as always-on for the purposes of watermark
-* calculation.  Until we have two-stage watermark programming merged,
-* this is necessary to avoid flickering.
+* Treat cursor with fb as always visible since
+* cursor updates can happen faster than the vrefresh
+* rate, and the current watermark code doesn't handle
+* that correctly. Cursor updates which set/clear the
+* fb are going to get throttled by
+* intel_legacy_cursor_update() to work around th

Re: [Intel-gfx] [PATCH 01/19] drm/i915: Micro-optimise i915_get_ggtt_vma_pages()

2017-02-07 Thread Mika Kuoppala

Chris Wilson  writes:

> The predominant VMA class is normal GTT, so allow gcc to emphasize that
> path and avoid unnecessary stack movement.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 61 
> +++--
>  1 file changed, 32 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index ec360ab939b8..f8cef51cf24c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2615,14 +2615,16 @@ static int ggtt_bind_vma(struct i915_vma *vma,
>  {
>   struct drm_i915_private *i915 = vma->vm->i915;
>   struct drm_i915_gem_object *obj = vma->obj;
> - u32 pte_flags = 0;
> - int ret;
> + u32 pte_flags;
>  
> - ret = i915_get_ggtt_vma_pages(vma);
> - if (ret)
> - return ret;
> + if (unlikely(!vma->pages)) {
> + int ret = i915_get_ggtt_vma_pages(vma);
> + if (ret)
> + return ret;
> + }
>  
>   /* Currently applicable only to VLV */
> + pte_flags = 0;
>   if (obj->gt_ro)
>   pte_flags |= PTE_READ_ONLY;
>  
> @@ -2647,18 +2649,18 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
>  {
>   struct drm_i915_private *i915 = vma->vm->i915;
>   u32 pte_flags;
> - int ret;
>  
> - ret = i915_get_ggtt_vma_pages(vma);
> - if (ret)
> - return ret;
> + if (unlikely(!vma->pages)) {
> + int ret = i915_get_ggtt_vma_pages(vma);
> + if (ret)
> + return ret;
> + }
>  
>   /* Currently applicable only to VLV */
>   pte_flags = 0;
>   if (vma->obj->gt_ro)
>   pte_flags |= PTE_READ_ONLY;
>  
> -
>   if (flags & I915_VMA_GLOBAL_BIND) {
>   intel_runtime_pm_get(i915);
>   vma->vm->insert_entries(vma->vm,
> @@ -3397,9 +3399,9 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
>   return sg;
>  }
>  
> -static struct sg_table *
> -intel_rotate_fb_obj_pages(const struct intel_rotation_info *rot_info,
> -   struct drm_i915_gem_object *obj)
> +static noinline struct sg_table *
> +intel_rotate_pages(struct intel_rotation_info *rot_info,
> +struct drm_i915_gem_object *obj)
>  {
>   const size_t n_pages = obj->base.size / PAGE_SIZE;
>   unsigned int size = intel_rotation_info_size(rot_info);
> @@ -3460,7 +3462,7 @@ intel_rotate_fb_obj_pages(const struct 
> intel_rotation_info *rot_info,
>   return ERR_PTR(ret);
>  }
>  
> -static struct sg_table *
> +static noinline struct sg_table *
>  intel_partial_pages(const struct i915_ggtt_view *view,
>   struct drm_i915_gem_object *obj)
>  {
> @@ -3514,7 +3516,7 @@ intel_partial_pages(const struct i915_ggtt_view *view,
>  static int
>  i915_get_ggtt_vma_pages(struct i915_vma *vma)
>  {
> - int ret = 0;
> + int ret;
>  
>   /* The vma->pages are only valid within the lifespan of the borrowed
>* obj->mm.pages. When the obj->mm.pages sg_table is regenerated, so
> @@ -3523,32 +3525,33 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
>*/
>   GEM_BUG_ON(!i915_gem_object_has_pinned_pages(vma->obj));
>  
> - if (vma->pages)
> + switch (vma->ggtt_view.type) {
> + case I915_GGTT_VIEW_NORMAL:
> + vma->pages = vma->obj->mm.pages;
>   return 0;
>  
> - if (vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL)
> - vma->pages = vma->obj->mm.pages;
> - else if (vma->ggtt_view.type == I915_GGTT_VIEW_ROTATED)
> + case I915_GGTT_VIEW_ROTATED:
>   vma->pages =
> - intel_rotate_fb_obj_pages(&vma->ggtt_view.rotated,
> -   vma->obj);
> - else if (vma->ggtt_view.type == I915_GGTT_VIEW_PARTIAL)
> + intel_rotate_pages(&vma->ggtt_view.rotated, vma->obj);
> + break;
> +
> + case I915_GGTT_VIEW_PARTIAL:
>   vma->pages = intel_partial_pages(&vma->ggtt_view, vma->obj);
> - else
> + break;
> +
> + default:
>   WARN_ONCE(1, "GGTT view %u not implemented!\n",
> vma->ggtt_view.type);
> + return -EINVAL;
> + }
>  
> - if (!vma->pages) {
> - DRM_ERROR("Failed to get pages for GGTT view type %u!\n",
> -   vma->ggtt_view.type);
> - ret = -EINVAL;
> - } else if (IS_ERR(vma->pages)) {
> + ret = 0;
> + if (unlikely(IS_ERR(vma->pages))) {
>   ret = PTR_ERR(vma->pages);
>   vma->pages = NULL;
>   DRM_ERROR("Failed to get pages for VMA view type %u (%d)!\n",
> vma->ggtt_view.type, ret);
>   }
> -
>   return ret;
>  }
>  
> -- 
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-

[Intel-gfx] [PATCH v4] drm/i915: Restore context and pd for ringbuffer submission after reset

2017-02-07 Thread Chris Wilson

Following a reset, the context and page directory registers are lost.
However, the queue of requests that we resubmit after the reset may
depend upon them - the registers are restored from a context image, but
that restore may be inhibited and may simply be absent from the request
if it was in the middle of a sequence using the same context. If we
prime the CCID/PD registers with the first request in the queue (even
for the hung request), we prevent invalid memory access for the
following requests (and continually hung engines).

v2: Magic BIT(8), reserved for future use but still appears unused.
v3: Some commentary on handling innocent vs guilty requests
v4: Add a wait for PD_BASE fetch. The reload appears to be instant on my
Ivybridge, but this bit probably exists for a reason.

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 18 --
 drivers/gpu/drm/i915/i915_reg.h |  6 ++--
 drivers/gpu/drm/i915/intel_lrc.c| 16 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 58 +++--
 4 files changed, 81 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a510c7f6828..b7632bbbafd8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2743,21 +2743,17 @@ static void i915_gem_reset_engine(struct 
intel_engine_cs *engine)
engine->irq_seqno_barrier(engine);
 
request = i915_gem_find_active_request(engine);
-   if (!request)
-   return;
-
-   if (!i915_gem_reset_request(request))
-   return;
+   if (request && i915_gem_reset_request(request)) {
+   DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 
0x%x\n",
+engine->name, request->global_seqno);
 
-   DRM_DEBUG_DRIVER("resetting %s to restart from tail of request 0x%x\n",
-engine->name, request->global_seqno);
+   /* If this context is now banned, skip all pending requests. */
+   if (i915_gem_context_is_banned(request->ctx))
+   engine_skip_context(request);
+   }
 
/* Setup the CS to resume from the breadcrumb of the hung request */
engine->reset_hw(engine, request);
-
-   /* If this context is now banned, skip all of its pending requests. */
-   if (i915_gem_context_is_banned(request->ctx))
-   engine_skip_context(request);
 }
 
 void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5bf36bdc5926..4a59091c0152 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3323,8 +3323,10 @@ enum skl_disp_power_wells {
 /*
  * Logical Context regs
  */
-#define CCID   _MMIO(0x2180)
-#define   CCID_EN  (1<<0)
+#define CCID   _MMIO(0x2180)
+#define   CCID_EN  BIT(0)
+#define   CCID_EXTENDED_STATE_RESTORE  BIT(2)
+#define   CCID_EXTENDED_STATE_SAVE BIT(3)
 /*
  * Notes on SNB/IVB/VLV context size:
  * - Power context is saved elsewhere (LLC or stolen)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index df8e6f74dc7e..e42990b56fa8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1352,7 +1352,20 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
  struct drm_i915_gem_request *request)
 {
struct execlist_port *port = engine->execlist_port;
-   struct intel_context *ce = &request->ctx->engine[engine->id];
+   struct intel_context *ce;
+
+   /* If the request was innocent, we leave the request in the ELSP
+* and will try to replay it on restarting. The context image may
+* have been corrupted by the reset, in which case we may have
+* to service a new GPU hang, but more likely we can continue on
+* without impact.
+*
+* If the request was guilty, we presume the context is corrupt
+* and have to at least restore the RING register in the context
+* image back to the expected values to skip over the guilty request.
+*/
+   if (!request || request->fence.error != -EIO)
+   return;
 
/* We want a simple context + ring to execute the breadcrumb update.
 * We cannot rely on the context being intact across the GPU hang,
@@ -1361,6 +1374,7 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
 * future request will be after userspace has had the opportunity
 * to recreate its own state.
 */
+   ce = &request->ctx->engine[engine->id];
execlists_init_reg_state(ce->lrc_reg_state,

[Intel-gfx] [PATCH i-g-t] lib: Add basic support for valgrind annotations.

2017-02-07 Thread Maarten Lankhorst

SIGRTMAX appears to be used by valgrind now for its internal tracking,
so avoid it in the helpers.

Also add some valgrind annotations in gem_mmap, to make sure that its
accesses are tracked correctly.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/configure.ac b/configure.ac
index 5bdd744a0750..562d5525e894 100644
--- a/configure.ac
+++ b/configure.ac
@@ -124,6 +124,11 @@ PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
 PKG_CHECK_MODULES(KMOD, [libkmod])
 PKG_CHECK_MODULES(PROCPS, [libprocps])
+PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
+
+if test x$have_valgrind = xyes; then
+   AC_DEFINE(HAVE_VALGRIND, 1, [Enable valgrind annotation support.])
+fi
 
 case "$target_cpu" in
x86*|i?86)
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 7030ea27dc27..c0ddf2986849 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -34,6 +34,7 @@ AM_CFLAGS = \
$(XMLRPC_CFLAGS) \
$(LIBUDEV_CFLAGS) \
$(PIXMAN_CFLAGS) \
+   $(VALGRIND_CFLAGS) \
-DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
-DIGT_DATADIR=\""$(pkgdatadir)"\" \
-DIGT_LOG_DOMAIN=\""$(subst _,-,$*)"\" \
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 763e997c5b83..eb4ca640128a 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -402,7 +402,7 @@ void igt_fork_hang_detector(int fd)
 
igt_assert(fstat(fd, &st) == 0);
 
-   signal(SIGRTMAX, sig_abort);
+   signal(SIGRTMAX - 1, sig_abort);
igt_fork_helper(&hang_detector)
hang_detector_process(getppid(), st.st_rdev);
 }
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 7ceb370b6fcb..bff67433b21d 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -220,7 +220,8 @@ void igt_spin_batch_set_timeout(igt_spin_t *spin, int64_t 
ns)
 
igt_assert(!spin->timer);
 
-   if (spin_signo == SIGRTMAX)
+   /* SIGRTMAX is used by valgrind, SIGRTMAX - 1 by igt_fork_hang_detector 
*/
+   if (spin_signo >= SIGRTMAX - 2)
spin_signo = SIGRTMIN;
spin->signo = ++spin_signo;
 
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index cd0c24ba871a..8b45967d3b76 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -56,6 +56,15 @@
 #include "igt_debugfs.h"
 #include "config.h"
 
+#ifdef HAVE_VALGRIND
+#include 
+#include 
+
+#define VG(x) x
+#else
+#define VG(x)
+#endif
+
 #include "ioctl_wrappers.h"
 
 /**
@@ -734,6 +743,8 @@ void *__gem_mmap__wc(int fd, uint32_t handle, uint64_t 
offset, uint64_t size, un
if (igt_ioctl(fd, LOCAL_IOCTL_I915_GEM_MMAP_v2, &arg))
return NULL;
 
+   VG(VALGRIND_MAKE_MEM_DEFINED(from_user_pointer(arg.addr_ptr), 
arg.size));
+
errno = 0;
return from_user_pointer(arg.addr_ptr);
 }
@@ -781,6 +792,8 @@ void *__gem_mmap__cpu(int fd, uint32_t handle, uint64_t 
offset, uint64_t size, u
if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP, &mmap_arg))
return NULL;
 
+   VG(VALGRIND_MAKE_MEM_DEFINED(from_user_pointer(mmap_arg.addr_ptr), 
mmap_arg.size));
+
errno = 0;
return from_user_pointer(mmap_arg.addr_ptr);
 }

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

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-07 Thread Martin Peres


On 07/02/17 15:22, Uwe Kleine-König wrote:

Hello,

On 02/01/2017 03:37 PM, Ville Syrjälä wrote:

On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:

Op 31-01-17 om 20:13 schreef Uwe Kleine-König:

On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:

Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
Just curious, does this help?

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ae2c0bb4b2e8..13de4c526ca6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
intel_crtc_state *cstate,
 * this is necessary to avoid flickering.
 */
int cpp = 4;
-   int width = pstate->base.visible ? pstate->base.crtc_w : 64;
+   int width = 256;

if (!cstate->base.active)
return 0;


On a kernel with this patch applied I cannot reproduce the flickering. I
keep that kernel running but expect that it also fixes the crash.


Ok that's good news.

Maybe ville or matt can comment whether this patch is the right fix?


Well, it's just extending the hack even further. The right fix would be
to fix the wm programming sequence to respect the frame boundaries
correctly (ie. my old vblank based wm stuff).


so I wonder how this goes forward. The situation seems to be well
understood, but other than testing patches I don't know what to do (and
there is currently no patch to test).

Best regards
Uwe



The way I understand this is that no-one wants to restrict the 
capabilities exposed by the kernel and would like a proper fix for this. 
However, I agree with Uwe, given the low priority status of Gen5 (people 
would rather work on hw that is used by a lot of people), we should 
probably accept the patch proposed by Maarten as it fixes someone's 
workflow and does not regress anything meaningful.


The proper fix for watermark computation can be worked on as time 
permits, later on.


Again, I would like to thanks Uwe for pushing hard for this, we are 
definitely not active-enough on this issue, flashing screens should be a 
big NO-NO, yet we seem to be OK with it :s


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

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

2017-02-07 Thread Jani Nikula

On Tue, 07 Feb 2017, Jose Abreu  wrote:
> Hi Jani,
>
>
> On 07-02-2017 13:35, Jani Nikula wrote:
>> On Tue, 07 Feb 2017, Jose Abreu  wrote:
 +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
 +{
 +  u8 status;
 +  int ret;
 +
 +  ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
 +  if (ret < 0) {
 +  DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
 +  return false;
 +  }
 +
 +  return status & SCDC_SCRAMBLING_STATUS;
>>> "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?
>> What's the point in that?
>>
>> BR,
>> Jani.
>>
>>
>
> Sorry, I didn't see the SCDC_SCRAMBLING_STATUS is BIT(0). Anyway,
> my intention was to return either 1 or 0 or else the value of the
> "and" would be returned. I think in x86 the bool is char, what
> could happen if SCDC_SCRAMBLING_STATUS was BIT(>7)? Does the cast
> work as expected?

The implicit type conversion works just fine.

BR,
Jani.

>
> Best regards,
> Jose Miguel Abreu
>

-- 
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 i-g-t v2] tests: Clean up shell scripts

2017-02-07 Thread Jani Nikula

On Tue, 07 Feb 2017, Joonas Lahtinen  wrote:
> On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote:
>> > On Tue, 07 Feb 2017, Joonas Lahtinen  
>> > wrote:
>> > 
>> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
>> > > 
>> > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
>> > > > 
>> > > > On Mon, 06 Feb 2017, Joonas Lahtinen  
>> > > > wrote:
>> > > > > 
>> > > > > Convert all scripts to use /bin/sh shebang and fix all shellcheck
>> > > > > reported problems.
>> > > > 
>> > > > Pro-tip, this is the place reserved in commit messages for describing
>> > > > *why* you think the change is needed or for the better. ;)
>> > > 
>> > > And this reply here seems to be the place where I'm asking why we don't
>> > > switch to C if we go through all this effort. I don't really see what sh
>> > > over bash buys us (and you can pretty much expect me to re-add bashism 
>> > > the
>> > > next time around I touch these ...).
>> > 
>> > Oh, totally forgot due to writing the huge RFC e-mail about it. One
>> > could amend the commit message with "to able to run on non-bash
>> > shells.", if it wasn't yet merged.
>> 
>> I learned this from the kids: Why?
>
> We can branch the dialog here, I have the ready answers ;)
>
> a) So you can avoid compiling bash. So you can build faster. Because
> faster is better.
>
> b) Also because you can avoid including bash in initrd. Because it
> results in a smaller image with less dependencies. Because smaller _is_
> better. Because it is faster to load over UEFI PXE. Because faster
> better.
>
> Did I mention faster is better?

And finally we're getting at the roots of the reason, you want to reduce
the size of the dependencies for environments where you have to
bootstrap the entire environment, e.g. initrd. Is that it? That *might*
have some merit.

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 v2 4/6] drm: scrambling support in drm layer

2017-02-07 Thread Jose Abreu

Hi Jani,


On 07-02-2017 13:35, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu  wrote:
>>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>>> +{
>>> +   u8 status;
>>> +   int ret;
>>> +
>>> +   ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>>> +   if (ret < 0) {
>>> +   DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
>>> +   return false;
>>> +   }
>>> +
>>> +   return status & SCDC_SCRAMBLING_STATUS;
>> "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?
> What's the point in that?
>
> BR,
> Jani.
>
>

Sorry, I didn't see the SCDC_SCRAMBLING_STATUS is BIT(0). Anyway,
my intention was to return either 1 or 0 or else the value of the
"and" would be returned. I think in x86 the bool is char, what
could happen if SCDC_SCRAMBLING_STATUS was BIT(>7)? Does the cast
work as expected?

Best regards,
Jose Miguel Abreu

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

Re: [Intel-gfx] [GIT PULL] GVT-g fixes for 4.11 merge

2017-02-07 Thread Jani Nikula

On Tue, 07 Feb 2017, Zhenyu Wang  wrote:
> Hi,
>
> These are GVT-g changes for 4.11 merge window, mostly for gvt init
> order fix that impacted resource handling for device model, the one
> i915 change has been reviewed and acked.
>
> I can't find good tag on dinf for this now, so base on current dinf.
> I can re-generate as required.

This is fine for dinf. Pulled, thanks.

BR,
Jani.


>
> thanks
> ---
>
> The following changes since commit 18566acac18f5784347bc5fe636a26897d1c963b:
>
>   Merge branch 'exynos-drm-next' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> drm-next (2017-02-01 08:43:42 +1000)
>
> are available in the git repository at:
>
>   https://github.com/01org/gvt-linux.git tags/gvt-next-2017-02-07
>
> for you to fetch changes up to 2d6ceb8e654a0ce998762b13f0ba2c275220a244:
>
>   drm/i915/gvt: fix vgpu type size init (2017-02-07 17:22:01 +0800)
>
> 
> Chuanxiao Dong (1):
>   drm/i915/gvt: add more resolutions in virtual edid
>
> Zhenyu Wang (5):
>   drm/i915: make intel_gvt_init() later instead of too early
>   drm/i915/gvt: move intel iommu detection to intel_gvt_init()
>   drm/i915/gvt: remove detect_host() MPT hook
>   drm/i915/gvt: use normal mmio read function for firmware exposure
>   drm/i915/gvt: fix vgpu type size init
>
>  drivers/gpu/drm/i915/gvt/display.c   | 19 +--
>  drivers/gpu/drm/i915/gvt/firmware.c  | 47 
> +++-
>  drivers/gpu/drm/i915/gvt/gvt.c   | 14 +--
>  drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 38 -
>  drivers/gpu/drm/i915/gvt/mpt.h   | 12 -
>  drivers/gpu/drm/i915/gvt/vgpu.c  | 13 +-
>  drivers/gpu/drm/i915/i915_drv.c  | 14 +--
>  drivers/gpu/drm/i915/intel_gvt.c |  5 
>  9 files changed, 42 insertions(+), 121 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

[Intel-gfx] [patch v2] drm/i915/gvt/kvmgt: remove some dead code

2017-02-07 Thread Dan Carpenter

"caps.buf" is always NULL here and "caps.size" is always zero.  The code
is a no-op and can be removed.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..773a45aa18f8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -965,11 +965,6 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
sparse->areas[0].offset =
PAGE_ALIGN(vgpu_aperture_offset(vgpu));
sparse->areas[0].size = vgpu_aperture_sz(vgpu);
-   if (!caps.buf) {
-   kfree(caps.buf);
-   caps.buf = NULL;
-   caps.size = 0;
-   }
break;
 
case VFIO_PCI_BAR3_REGION_INDEX ... VFIO_PCI_BAR5_REGION_INDEX:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> On 7 February 2017 at 14:29, Daniel Vetter  wrote:
> > Noticed that everyone duplicates the same logic here and we could safe
> > a few lines per driver. Yay for lots of drivers to make such tiny
> > refactors worth-while!
> >
> > v2: Forgot to git add everything :(
> >
> Hmm afaict this patch inlines drm_fb_helper_release_fbi within
> drm_fb_helper_fini yet it is missing:
>  - removal of the (now unused ?) drm_fb_helper_release_fbi
>  - the leaks which now occur in the error paths.

The error cleanup is a bit unobvious. The fbi is allocated during the
create/initial_fb callback, which is after a successful
framebuffer_init. The caller must be prepared to do a framebuffer_fini
(and so release_fbi will be handled if required) on failure or success.
-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/gvt/kvmgt: remove some dead code

2017-02-07 Thread Dan Carpenter

On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> > If "caps.buf" is already NULL then it doesn't need to be freed or set to
> > NULL.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> 
> 
> > @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> > unsigned int cmd,
> >     sparse->areas[0].offset =
> >     PAGE_ALIGN(vgpu_aperture_offset(vgpu));
> >     sparse->areas[0].size = vgpu_aperture_sz(vgpu);
> > -   if (!caps.buf) {
> 
> Looking at the code around, the right thing would be to just remove the
> negation? This currently seems like a memory leak.
> 
> > -   kfree(caps.buf);
> > -   caps.buf = NULL;
> > +   if (!caps.buf)
> >     caps.size = 0;
> > -   }
> 
> And quickly looking, the caps is pre-initialized but unused at this
> point, so the whole if could just be removed, right?

Hm...  Duh.  You're right.  Let me resend.

regards,
dan carpenter

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

Re: [Intel-gfx] [PATCH i-g-t v2] tests: Clean up shell scripts

2017-02-07 Thread Joonas Lahtinen

On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote:
> > On Tue, 07 Feb 2017, Joonas Lahtinen  
> > wrote:
> > 
> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
> > > 
> > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
> > > > 
> > > > On Mon, 06 Feb 2017, Joonas Lahtinen  
> > > > wrote:
> > > > > 
> > > > > Convert all scripts to use /bin/sh shebang and fix all shellcheck
> > > > > reported problems.
> > > > 
> > > > Pro-tip, this is the place reserved in commit messages for describing
> > > > *why* you think the change is needed or for the better. ;)
> > > 
> > > And this reply here seems to be the place where I'm asking why we don't
> > > switch to C if we go through all this effort. I don't really see what sh
> > > over bash buys us (and you can pretty much expect me to re-add bashism the
> > > next time around I touch these ...).
> > 
> > Oh, totally forgot due to writing the huge RFC e-mail about it. One
> > could amend the commit message with "to able to run on non-bash
> > shells.", if it wasn't yet merged.
> 
> I learned this from the kids: Why?

We can branch the dialog here, I have the ready answers ;)

a) So you can avoid compiling bash. So you can build faster. Because
faster is better.

b) Also because you can avoid including bash in initrd. Because it
results in a smaller image with less dependencies. Because smaller _is_
better. Because it is faster to load over UEFI PXE. Because faster
better.

Did I mention faster is better?

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

Re: [Intel-gfx] [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5220a7b5e6ff..074ab22a7cf3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -781,7 +781,9 @@ EXPORT_SYMBOL(drm_fb_helper_init);
>   * @fb_helper: driver-allocated fbdev helper
>   *
>   * A helper to alloc fb_info and the members cmap and apertures. Called
> - * by the driver within the fb_probe fb_helper callback function.
> + * by the driver within the fb_probe fb_helper callback function. Drivers do 
> not
> + * need to release the allocated fb_info structure themselves, this is
> + * automatically done when calling drm_fb_helper_fini().
>   *
>   * RETURNS:
>   * fb_info pointer if things went okay, pointer containing error code
> @@ -866,9 +868,19 @@ EXPORT_SYMBOL(drm_fb_helper_release_fbi);

I was expecting to see drm_fb_helper_release_fbi() removed.

>   */
>  void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
>  {
> - if (!drm_fbdev_emulation)
> + struct fb_info *info;
> +
> + if (!drm_fbdev_emulation || !fb_helper)
>   return;
>  
> + info = fb_helper->fbdev;
> + if (info) {
> + if (info->cmap.len)
> + fb_dealloc_cmap(&info->cmap);
> + framebuffer_release(info);
> + }
> + fb_helper->fbdev = NULL;
> +
>   mutex_lock(&kernel_fb_helper_lock);
>   if (!list_empty(&fb_helper->kernel_fb_list)) {
>   list_del(&fb_helper->kernel_fb_list);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c

-- 
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: Remove overzealous fence warn on runtime suspend

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 04:24:25PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote:
> > @@ -2024,8 +2024,16 @@ void i915_gem_runtime_suspend(struct 
> > drm_i915_private *dev_priv)
> >     for (i = 0; i < dev_priv->num_fence_regs; i++) {
> >     struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
> >  
> > -   if (WARN_ON(reg->pin_count))
> > -   continue;
> > +   /* Ideally we want to assert that the fence register is not
> > +    * live at this point (i.e. that no piece of code will is
> 
> s/will is/will be/
> 
> With that,
> 
> Reviewed-by: Joonas Lahtinen 

Fixed up and applied, thanks.
-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: Avoid BIT(max) - 1 and use GENMASK(max, 0)

2017-02-07 Thread Joonas Lahtinen

On ti, 2017-02-07 at 14:03 +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote:
> > 
> > "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> > We already have GENMASK for generating the mask, use it!
> > 
> > Signed-off-by: Joonas Lahtinen 
> > Cc: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> >  drivers/gpu/drm/i915/intel_fbdev.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_runtime_pm.c  | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index fcf8181..1c06fbb 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -234,7 +234,7 @@ static void broadwell_sseu_info_init(struct 
> > drm_i915_private *dev_priv)
> > > >      * The subslice disable field is global, i.e. it applies
> > > >      * to each of the enabled slices.
> > > >      */
> > > > -   sseu->subslice_mask = BIT(ss_max) - 1;
> > > > +   sseu->subslice_mask = GENMASK(ss_max, 0);
> 
> Too simple!
> 
>   BUILD_BUG_ON(BIT(ss_max)-1 != GENMASK(ss_max, 0));
> 
> Needs to be GENMASK(ss_max - 1, 0); the high bit is inclusive.
> 
> Otherwise, the list matches up with a quick grep for BIT*(x)-1.

Whoop, seem to have nucleared my kernel config. I think better check if
the same warning is triggered too, with GENMASK :)

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

Re: [Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Emil Velikov

On 7 February 2017 at 14:29, Daniel Vetter  wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
Hmm afaict this patch inlines drm_fb_helper_release_fbi within
drm_fb_helper_fini yet it is missing:
 - removal of the (now unused ?) drm_fb_helper_release_fbi
 - the leaks which now occur in the error paths.

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

Re: [Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

2017-02-07 Thread Joonas Lahtinen

On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> If "caps.buf" is already NULL then it doesn't need to be freed or set to
> NULL.
> 
> Signed-off-by: Dan Carpenter 



> @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   sparse->areas[0].offset =
>   PAGE_ALIGN(vgpu_aperture_offset(vgpu));
>   sparse->areas[0].size = vgpu_aperture_sz(vgpu);
> - if (!caps.buf) {

Looking at the code around, the right thing would be to just remove the
negation? This currently seems like a memory leak.

> - kfree(caps.buf);
> - caps.buf = NULL;
> + if (!caps.buf)
>   caps.size = 0;
> - }

And quickly looking, the caps is pre-initialized but unused at this
point, so the whole if could just be removed, right?

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

[Intel-gfx] [PATCH] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Daniel Vetter

Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!

v2: Forgot to git add everything :(

Cc: Chris Wilson 
Cc: Sean Paul 
Cc: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 ---
 drivers/gpu/drm/armada/armada_fbdev.c |  2 --
 drivers/gpu/drm/ast/ast_fb.c  |  9 +++--
 drivers/gpu/drm/bochs/bochs_fbdev.c   |  5 +
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  1 -
 drivers/gpu/drm/drm_fb_cma_helper.c   |  3 +--
 drivers/gpu/drm/drm_fb_helper.c   | 16 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 --
 drivers/gpu/drm/gma500/framebuffer.c  |  9 +++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  2 --
 drivers/gpu/drm/i915/intel_fbdev.c|  5 +
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  5 +
 drivers/gpu/drm/msm/msm_fbdev.c   |  1 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  1 -
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  4 
 drivers/gpu/drm/qxl/qxl_fb.c  |  5 +
 drivers/gpu/drm/radeon/radeon_fb.c| 11 ---
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  9 +++--
 drivers/gpu/drm/tegra/fb.c|  5 +
 drivers/gpu/drm/udl/udl_fb.c  |  5 +
 drivers/gpu/drm/virtio/virtgpu_fb.c   |  5 +
 include/drm/drm_fb_helper.h   |  4 
 22 files changed, 39 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..f4a2f1f0a6ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
-   goto out_unref;
+   goto out;
}
 
info->par = rfbdev;
@@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd, 
gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
-   goto out_destroy_fbi;
+   goto out;
}
 
fb = &rfbdev->rfb.base;
@@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
 
if (info->screen_base == NULL) {
ret = -ENOSPC;
-   goto out_destroy_fbi;
+   goto out;
}
 
DRM_INFO("fb mappable at 0x%lX\n",  info->fix.smem_start);
@@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
return 0;
 
-out_destroy_fbi:
-   drm_fb_helper_release_fbi(helper);
-out_unref:
+out:
if (abo) {
 
}
@@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev, 
struct amdgpu_fbdev *rfb
struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
 
drm_fb_helper_unregister_fbi(&rfbdev->helper);
-   drm_fb_helper_release_fbi(&rfbdev->helper);
 
if (rfb->obj) {
amdgpufb_destroy_pinned_object(rfb->obj);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 78335100cbc3..7f184a52594e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
 
return 0;
  err_fb_setup:
-   drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
  err_fb_helper:
priv->fbdev = NULL;
@@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
 
if (fbh) {
drm_fb_helper_unregister_fbi(fbh);
-   drm_fb_helper_release_fbi(fbh);
 
drm_fb_helper_fini(fbh);
 
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index b085140fae95..f8421d23946a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
-   goto err_free_vram;
+   goto out;
}
info->par = afbdev;
 
ret = ast_framebuffer_init(dev, &afbdev->afb, &mode_cmd, gobj);
if (ret)
-   goto err_release_fbi;
+   goto out;
 
afbdev->sysram = sysram;
afbdev->size = size;
@@ -250,9 +250,7 @@ static int astfb_create(struct drm_fb_helper *helper,
 
return 0;
 
-err_release_fbi:
-   drm_fb_helper_re

Re: [Intel-gfx] [PATCH 1/2] drm/fb-helper: Explain unload sequence a bit better

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote:
> While reviewing Chris' patches to properly cancel our async workers I
> checked that this happens after the fbdev is already unregistered.
> That's the case, but I found a small gap in our docs, fill that in.
> 
> Note that I don't explain what release_fbi does, because that function
> will disappear in the next patch ...
> 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 
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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Cancel drm_fb_helper_dirty_work on unload

2017-02-07 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm: Cancel drm_fb_helper_dirty_work on 
unload
URL   : https://patchwork.freedesktop.org/series/19230/
State : failure

== Summary ==

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

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (fi-hsw-4770)
Test gem_exec_fence:
Subgroup basic-await-default:
incomplete -> PASS   (fi-ilk-650)

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:5pass:4dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

11b0f8aad73502066375b56c92ab925dcdfc1994 drm-tip: 2017y-02m-07d-13h-26m-43s UTC 
integration manifest
4b6869f drm: Cancel drm_fb_helper_resume_work on unload
9ce0c3e drm: Cancel drm_fb_helper_dirty_work on unload

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove overzealous fence warn on runtime suspend

2017-02-07 Thread Joonas Lahtinen

On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote:
> The goal of the WARN was to catch when we are still actively using the
> fence as we go into the runtime suspend. However, the reg->pin_count is
> too coarse as it does not distinguish between exclusive ownership of the
> fence register from activity.
> 
> I've not improved on the WARN, nor have we captured this WARN in an
> exact igt, but it is showing up regularly in the wild:
> 
> [ 1915.935332] WARNING: CPU: 1 PID: 10861 at 
> drivers/gpu/drm/i915/i915_gem.c:2022 i915_gem_runtime_suspend+0x116/0x130 
> [i915]
> [ 1915.935383] WARN_ON(reg->pin_count)[ 1915.935399] Modules linked in:
>  snd_hda_intel i915 drm_kms_helper vgem netconsole scsi_transport_iscsi fuse 
> vfat fat x86_pkg_temp_thermal coretemp intel_cstate intel_uncore 
> snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core 
> snd_pcm snd_timer snd mei_me mei serio_raw intel_rapl_perf intel_pch_thermal 
> soundcore wmi acpi_pad i2c_algo_bit syscopyarea sysfillrect sysimgblt 
> fb_sys_fops drm r8169 mii video [last unloaded: drm_kms_helper]
> [ 1915.935785] CPU: 1 PID: 10861 Comm: kworker/1:0 Tainted: G U  W   
> 4.9.0-rc5+ #170
> [ 1915.935799] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 
> 12/01/2015
> [ 1915.935822] Workqueue: pm pm_runtime_work
> [ 1915.935845]  c900044fbbf0 ac3220bc c900044fbc40 
> 
> [ 1915.935890]  c900044fbc30 ac059bcb 07e6044fbc60 
> 8801626e3198
> [ 1915.935937]  8801626e 0002 c05e5d4e 
> 
> [ 1915.935985] Call Trace:
> [ 1915.936013]  [] dump_stack+0x4f/0x73
> [ 1915.936038]  [] __warn+0xcb/0xf0
> [ 1915.936060]  [] warn_slowpath_fmt+0x5f/0x80
> [ 1915.936158]  [] i915_gem_runtime_suspend+0x116/0x130 
> [i915]
> [ 1915.936251]  [] intel_runtime_suspend+0x64/0x280 [i915]
> [ 1915.936277]  [] ? dequeue_entity+0x241/0xbc0
> [ 1915.936298]  [] pci_pm_runtime_suspend+0x55/0x180
> [ 1915.936317]  [] ? pci_pm_runtime_resume+0xa0/0xa0
> [ 1915.936339]  [] __rpm_callback+0x32/0x70
> [ 1915.936356]  [] rpm_callback+0x24/0x80
> [ 1915.936375]  [] ? pci_pm_runtime_resume+0xa0/0xa0
> [ 1915.936392]  [] rpm_suspend+0x12d/0x680
> [ 1915.936415]  [] ? _raw_spin_unlock_irq+0x17/0x30
> [ 1915.936435]  [] ? finish_task_switch+0x88/0x220
> [ 1915.936455]  [] pm_runtime_work+0x6f/0xb0
> [ 1915.936477]  [] process_one_work+0x1f3/0x4d0
> [ 1915.936501]  [] worker_thread+0x48/0x4e0
> [ 1915.936523]  [] ? process_one_work+0x4d0/0x4d0
> [ 1915.936542]  [] ? process_one_work+0x4d0/0x4d0
> [ 1915.936559]  [] kthread+0xd9/0xf0
> [ 1915.936580]  [] ? kthread_park+0x60/0x60
> [ 1915.936600]  [] ret_from_fork+0x22/0x30
> 
> In the case the register is pinned, it should be present and we will
> need to invalidate them to be restored upon resume as we cannot expect
> the owner of the pin to call get_fence prior to use after resume.
> 
> Fixes: 7c108fd8feac ("drm/i915: Move fence cancellation to runtime suspend")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98804
> Reported-by: Lionel Landwerlin 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Imre Deak 
> Cc: Jani Nikula 
> Cc:  # v4.10-rc1+



> @@ -2024,8 +2024,16 @@ void i915_gem_runtime_suspend(struct drm_i915_private 
> *dev_priv)
>   for (i = 0; i < dev_priv->num_fence_regs; i++) {
>   struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i];
>  
> - if (WARN_ON(reg->pin_count))
> - continue;
> + /* Ideally we want to assert that the fence register is not
> +  * live at this point (i.e. that no piece of code will is

s/will is/will be/

With that,

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH] drm/i915: Rename conditional GEM execution macros

2017-02-07 Thread Joonas Lahtinen

On ti, 2017-02-07 at 10:23 +, Chris Wilson wrote:
> After a brief discussion, we settled on a naming convention for the
> conditional GEM debugging data that should be clearer to the casual
> user: GEM_DEBUG
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen  Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 

Rather fast merged if the introducing patch got in already :)

Anyway;

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] [PATCH 1/2] drm/fb-helper: Explain unload sequence a bit better

2017-02-07 Thread Daniel Vetter

While reviewing Chris' patches to properly cancel our async workers I
checked that this happens after the fbdev is already unregistered.
That's the case, but I found a small gap in our docs, fill that in.

Note that I don't explain what release_fbi does, because that function
will disappear in the next patch ...

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c7fafa175755..5220a7b5e6ff 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -63,7 +63,8 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * drm_fb_helper_init(), drm_fb_helper_single_add_all_connectors() and
  * drm_fb_helper_initial_config(). Drivers with fancier requirements than the
  * default behaviour can override the third step with their own code.
- * Teardown is done with drm_fb_helper_fini().
+ * Teardown is done with drm_fb_helper_fini() after the fbdev device is
+ * unregisters using drm_fb_helper_unregister_fbi().
  *
  * At runtime drivers should restore the fbdev console by calling
  * drm_fb_helper_restore_fbdev_mode_unlocked() from their &drm_driver.lastclose
@@ -709,7 +710,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
drm_fb_helper *helper,
 EXPORT_SYMBOL(drm_fb_helper_prepare);
 
 /**
- * drm_fb_helper_init - initialize a drm_fb_helper structure
+ * drm_fb_helper_init - initialize a &struct drm_fb_helper
  * @dev: drm device
  * @fb_helper: driver-allocated fbdev helper structure to initialize
  * @crtc_count: maximum number of crtcs to support in this fbdev emulation
@@ -823,7 +824,8 @@ EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
  * @fb_helper: driver-allocated fbdev helper
  *
  * A wrapper around unregister_framebuffer, to release the fb_info
- * framebuffer device
+ * framebuffer device. This must be called before releasing all resources for
+ * @fb_helper by calling drm_fb_helper_fini().
  */
 void drm_fb_helper_unregister_fbi(struct drm_fb_helper *fb_helper)
 {
@@ -855,6 +857,13 @@ void drm_fb_helper_release_fbi(struct drm_fb_helper 
*fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_release_fbi);
 
+/**
+ * drm_fb_helper_fini - finialize a &struct drm_fb_helper
+ * @fb_helper: driver-allocated fbdev helper
+ *
+ * This cleans up all remaining resources associated with @fb_helper. Must be
+ * called after drm_fb_helper_unlink_fbi() was called.
+ */
 void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
 {
if (!drm_fbdev_emulation)
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/2] drm/fb-helper: Automatically clean up fb_info

2017-02-07 Thread Daniel Vetter

Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!

Cc: Chris Wilson 
Cc: Sean Paul 
Cc: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 11 ---
 drivers/gpu/drm/armada/armada_fbdev.c |  2 --
 drivers/gpu/drm/ast/ast_fb.c  |  9 +++--
 drivers/gpu/drm/bochs/bochs_fbdev.c   |  5 +
 drivers/gpu/drm/cirrus/cirrus_fbdev.c |  1 -
 drivers/gpu/drm/drm_fb_cma_helper.c   |  3 +--
 drivers/gpu/drm/drm_fb_helper.c   | 16 ++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  2 --
 drivers/gpu/drm/gma500/framebuffer.c  |  9 +++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  3 +--
 drivers/gpu/drm/i915/intel_fbdev.c|  5 +
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  5 +
 drivers/gpu/drm/msm/msm_fbdev.c   |  1 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  1 -
 drivers/gpu/drm/omapdrm/omap_fbdev.c  |  4 
 drivers/gpu/drm/qxl/qxl_fb.c  |  5 +
 drivers/gpu/drm/radeon/radeon_fb.c| 11 ---
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  9 +++--
 drivers/gpu/drm/tegra/fb.c|  5 +
 drivers/gpu/drm/udl/udl_fb.c  |  5 +
 drivers/gpu/drm/virtio/virtgpu_fb.c   |  5 +
 include/drm/drm_fb_helper.h   |  4 
 22 files changed, 40 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..f4a2f1f0a6ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -224,7 +224,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
-   goto out_unref;
+   goto out;
}
 
info->par = rfbdev;
@@ -233,7 +233,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
ret = amdgpu_framebuffer_init(adev->ddev, &rfbdev->rfb, &mode_cmd, 
gobj);
if (ret) {
DRM_ERROR("failed to initialize framebuffer %d\n", ret);
-   goto out_destroy_fbi;
+   goto out;
}
 
fb = &rfbdev->rfb.base;
@@ -266,7 +266,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
 
if (info->screen_base == NULL) {
ret = -ENOSPC;
-   goto out_destroy_fbi;
+   goto out;
}
 
DRM_INFO("fb mappable at 0x%lX\n",  info->fix.smem_start);
@@ -278,9 +278,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
return 0;
 
-out_destroy_fbi:
-   drm_fb_helper_release_fbi(helper);
-out_unref:
+out:
if (abo) {
 
}
@@ -304,7 +302,6 @@ static int amdgpu_fbdev_destroy(struct drm_device *dev, 
struct amdgpu_fbdev *rfb
struct amdgpu_framebuffer *rfb = &rfbdev->rfb;
 
drm_fb_helper_unregister_fbi(&rfbdev->helper);
-   drm_fb_helper_release_fbi(&rfbdev->helper);
 
if (rfb->obj) {
amdgpufb_destroy_pinned_object(rfb->obj);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 78335100cbc3..7f184a52594e 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -157,7 +157,6 @@ int armada_fbdev_init(struct drm_device *dev)
 
return 0;
  err_fb_setup:
-   drm_fb_helper_release_fbi(fbh);
drm_fb_helper_fini(fbh);
  err_fb_helper:
priv->fbdev = NULL;
@@ -179,7 +178,6 @@ void armada_fbdev_fini(struct drm_device *dev)
 
if (fbh) {
drm_fb_helper_unregister_fbi(fbh);
-   drm_fb_helper_release_fbi(fbh);
 
drm_fb_helper_fini(fbh);
 
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index b085140fae95..f8421d23946a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -215,13 +215,13 @@ static int astfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
-   goto err_free_vram;
+   goto out;
}
info->par = afbdev;
 
ret = ast_framebuffer_init(dev, &afbdev->afb, &mode_cmd, gobj);
if (ret)
-   goto err_release_fbi;
+   goto out;
 
afbdev->sysram = sysram;
afbdev->size = size;
@@ -250,9 +250,7 @@ static int astfb_create(struct drm_fb_helper *helper,
 
return 0;
 
-err_release_fbi:
-   drm_fb_helper_release_fbi(helper);
-err_free_vram:
+

Re: [Intel-gfx] [PATCH 2/2] drm: Cancel drm_fb_helper_resume_work on unload

2017-02-07 Thread Daniel Vetter

On Tue, Feb 07, 2017 at 12:49:56PM +, Chris Wilson wrote:
> We can not allow the worker to run after its fbdev, or even the module,
> has been removed.
> 
> Fixes: cfe63423d9be ("drm/fb-helper: Add 
> drm_fb_helper_set_suspend_unlocked()")
> Signed-off-by: Chris Wilson 
> Cc: Noralf Trønnes 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: dri-de...@lists.freedesktop.org
> Cc:  # v4.9+

Both applied to drm-misc-next-fixes (since imo not that pressing that we
need to rush them in for 4.10 ...).
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 2d0810c9f3dc..842c461b0b21 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -860,6 +860,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
>   if (!drm_fbdev_emulation)
>   return;
>  
> + cancel_work_sync(&fb_helper->resume_work);
>   cancel_work_sync(&fb_helper->dirty_work);
>  
>   mutex_lock(&kernel_fb_helper_lock);
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

2017-02-07 Thread Chris Wilson

On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote:
> "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> We already have GENMASK for generating the mask, use it!
> 
> Signed-off-by: Joonas Lahtinen 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>  drivers/gpu/drm/i915/intel_fbdev.c   | 2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index fcf8181..1c06fbb 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -234,7 +234,7 @@ static void broadwell_sseu_info_init(struct 
> drm_i915_private *dev_priv)
>* The subslice disable field is global, i.e. it applies
>* to each of the enabled slices.
>*/
> - sseu->subslice_mask = BIT(ss_max) - 1;
> + sseu->subslice_mask = GENMASK(ss_max, 0);

Too simple!

BUILD_BUG_ON(BIT(ss_max)-1 != GENMASK(ss_max, 0));

Needs to be GENMASK(ss_max - 1, 0); the high bit is inclusive.

Otherwise, the list matches up with a quick grep for BIT*(x)-1.
-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] drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)

2017-02-07 Thread Joonas Lahtinen

"BIT(max) - 1" will overflow when max = 32, and GCC will complain.
We already have GENMASK for generating the mask, use it!

Signed-off-by: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_device_info.c | 2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   | 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index fcf8181..1c06fbb 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -234,7 +234,7 @@ static void broadwell_sseu_info_init(struct 
drm_i915_private *dev_priv)
 * The subslice disable field is global, i.e. it applies
 * to each of the enabled slices.
 */
-   sseu->subslice_mask = BIT(ss_max) - 1;
+   sseu->subslice_mask = GENMASK(ss_max, 0);
sseu->subslice_mask &= ~((fuse2 & GEN8_F2_SS_DIS_MASK) >>
 GEN8_F2_SS_DIS_SHIFT);
 
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 1b8ba2e..1a0eeb9 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -371,7 +371,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
return false;
 
memcpy(save_enabled, enabled, count);
-   mask = BIT(count) - 1;
+   mask = GENMASK(count, 0);
conn_configured = 0;
 retry:
for (i = 0; i < count; i++) {
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 66aa1bb..8258fd6 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1249,7 +1249,7 @@ static void vlv_dpio_cmn_power_well_disable(struct 
drm_i915_private *dev_priv,
vlv_set_power_well(dev_priv, power_well, false);
 }
 
-#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
+#define POWER_DOMAIN_MASK (GENMASK(POWER_DOMAIN_NUM, 0))
 
 static struct i915_power_well *lookup_power_well(struct drm_i915_private 
*dev_priv,
 int power_well_id)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Add i915_hpd_storm_ctl

2017-02-07 Thread Jani Nikula

On Sat, 04 Feb 2017, Lyude  wrote:
> This adds a file in i915's debugfs directory that allows userspace to
> manually control HPD storm detection. This is mainly for hotplugging
> tests, where we might want to test HPD storm functionality or disable
> storm detection to speed up hotplugging tests without breaking anything.
>
> Signed-off-by: Lyude 
> Cc: Tomeu Vizoso 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  | 102 
> ++-
>  drivers/gpu/drm/i915/i915_drv.h  |   2 +
>  drivers/gpu/drm/i915/i915_irq.c  |   2 +
>  drivers/gpu/drm/i915/intel_hotplug.c |   3 +-
>  4 files changed, 107 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3ae0656..b985c7b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4624,6 +4624,105 @@ static int i915_forcewake_create(struct dentry *root, 
> struct drm_minor *minor)
>   return drm_add_fake_info_node(minor, ent, &i915_forcewake_fops);
>  }
>  
> +static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *dev_priv = m->private;
> +
> + if (delayed_work_pending(&dev_priv->hotplug.reenable_work))
> + seq_printf(m, "detected\n");
> + else if (dev_priv->hotplug.hpd_storm_detect_enabled)
> + seq_printf(m, "on\n");
> + else
> + seq_printf(m, "off\n");
> +
> + return 0;
> +}
> +
> +static void i915_hpd_storm_reset(struct drm_i915_private *dev_priv)
> +{
> + int i;
> +
> + spin_lock_irq(&dev_priv->irq_lock);
> + for (i = 0; i < ARRAY_SIZE(dev_priv->hotplug.stats); i++) {
> + dev_priv->hotplug.stats[i].count = 0;
> + dev_priv->hotplug.stats[i].last_jiffies = jiffies;
> + }
> + spin_unlock_irq(&dev_priv->irq_lock);
> +
> + if (delayed_work_pending(&dev_priv->hotplug.reenable_work))
> + flush_delayed_work(&dev_priv->hotplug.reenable_work);
> + else
> + schedule_delayed_work(&dev_priv->hotplug.reenable_work, 0);
> +}
> +
> +static ssize_t i915_hpd_storm_ctl_write(struct file *file,
> + const char __user *ubuf, size_t len,
> + loff_t *offp)
> +{
> + struct seq_file *m = file->private_data;
> + struct drm_i915_private *dev_priv = m->private;
> + struct i915_hotplug *hotplug = &dev_priv->hotplug;
> + char tmp[16];
> + enum {
> + HPD_STORM_DISABLE = 0,
> + HPD_STORM_ENABLE,
> + HPD_STORM_RESET
> + } action;
> +
> + if (len >= sizeof(tmp))
> + return -EINVAL;
> +
> + if (copy_from_user(tmp, ubuf, len))
> + return -EFAULT;
> +
> + tmp[len] = '\0';
> +
> + if (strcmp(tmp, "off") == 0 || strcmp(tmp, "off\n") == 0)
> + action = HPD_STORM_DISABLE;
> + else if (strcmp(tmp, "on") == 0 || strcmp(tmp, "on\n") == 0)
> + action = HPD_STORM_ENABLE;
> + else if (strcmp(tmp, "reset") == 0 || strcmp(tmp, "reset\n") == 0)
> + action = HPD_STORM_RESET;
> + else
> + return -EINVAL;
> +
> + switch (action) {
> + case HPD_STORM_DISABLE:
> + DRM_DEBUG_KMS("Disabling HPD storm detection\n");
> +
> + WRITE_ONCE(hotplug->hpd_storm_detect_enabled, false);
> + i915_hpd_storm_reset(dev_priv);
> + break;
> + case HPD_STORM_ENABLE:
> + DRM_DEBUG_KMS("Enabling HPD storm detection\n");
> +
> + i915_hpd_storm_reset(dev_priv);
> + hotplug->hpd_storm_detect_enabled = true;
> + break;
> + case HPD_STORM_RESET:
> + DRM_DEBUG_KMS("Resetting HPD storm stats\n");
> +
> + i915_hpd_storm_reset(dev_priv);
> + break;
> + }
> +
> + return len;
> +}
> +
> +static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
> +}
> +
> +static const struct file_operations i915_hpd_storm_ctl_fops = {
> + .owner = THIS_MODULE,
> + .open = i915_hpd_storm_ctl_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = i915_hpd_storm_ctl_write
> +};
> +
>  static int i915_debugfs_create(struct dentry *root,
>  struct drm_minor *minor,
>  const char *name,
> @@ -4717,7 +4816,8 @@ static const struct i915_debugfs_files {
>   {"i915_dp_test_data", &i915_displayport_test_data_fops},
>   {"i915_dp_test_type", &i915_displayport_test_type_fops},
>   {"i915_dp_test_active", &i915_displayport_test_active_fops},
> - {"i915_guc_log_control", &i915_guc_log_control_fops}
> + {"i915_guc_log_control",

Re: [Intel-gfx] [PATCH v2 4/6] drm: scrambling support in drm layer

2017-02-07 Thread Jani Nikula

On Tue, 07 Feb 2017, Jose Abreu  wrote:
>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>> +{
>> +u8 status;
>> +int ret;
>> +
>> +ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>> +if (ret < 0) {
>> +DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
>> +return false;
>> +}
>> +
>> +return status & SCDC_SCRAMBLING_STATUS;
>
> "return (status & SCDC_SCRAMBLING_STATUS) > 0;" ?

What's the point in that?

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 i-g-t v2] tests: Clean up shell scripts

2017-02-07 Thread Jani Nikula

On Tue, 07 Feb 2017, Joonas Lahtinen  wrote:
> On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
>> On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
>> > 
>> > On Mon, 06 Feb 2017, Joonas Lahtinen  
>> > wrote:
>> > > 
>> > > Convert all scripts to use /bin/sh shebang and fix all shellcheck
>> > > reported problems.
>> > 
>> > Pro-tip, this is the place reserved in commit messages for describing
>> > *why* you think the change is needed or for the better. ;)
>> 
>> And this reply here seems to be the place where I'm asking why we don't
>> switch to C if we go through all this effort. I don't really see what sh
>> over bash buys us (and you can pretty much expect me to re-add bashism the
>> next time around I touch these ...).
>
> Oh, totally forgot due to writing the huge RFC e-mail about it. One
> could amend the commit message with "to able to run on non-bash
> shells.", if it wasn't yet merged.

I learned this from the kids: Why?

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

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_lowres: Add DRM_MODE_ATOMIC_ALLOW_MODESET test

2017-02-07 Thread Mika Kahola

When doing a full atomic modeset, kernel should fail if the flag
DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of
'kms_plane_lowres' testset. The testcases are 'pipe-x-allow-modeset' where
x stands for pipe in question.

For: VIZ-6955

Signed-off-by: Mika Kahola 
---
 tests/kms_plane_lowres.c | 51 +++-
 1 file changed, 37 insertions(+), 14 deletions(-)

diff --git a/tests/kms_plane_lowres.c b/tests/kms_plane_lowres.c
index 689c248..a127124 100644
--- a/tests/kms_plane_lowres.c
+++ b/tests/kms_plane_lowres.c
@@ -142,12 +142,16 @@ test_fini(data_t *data, igt_output_t *output)
 }
 
 static int
-display_commit_mode(data_t *data, enum pipe pipe, int flags, igt_crc_t *crc)
+display_commit_mode(data_t *data, enum pipe pipe, bool test_modeset, igt_crc_t 
*crc)
 {
char buf[256];
struct drm_event *e = (void *)buf;
unsigned int vblank_start, vblank_stop;
int n, ret;
+   int flags = DRM_MODE_PAGE_FLIP_EVENT;
+
+   if (!test_modeset)
+   flags |= DRM_MODE_ATOMIC_ALLOW_MODESET;
 
vblank_start = kmstest_get_vblank(data->display.drm_fd, pipe,
  DRM_VBLANK_NEXTONMISS);
@@ -155,6 +159,9 @@ display_commit_mode(data_t *data, enum pipe pipe, int 
flags, igt_crc_t *crc)
ret = igt_display_try_commit_atomic(&data->display,
flags,
NULL);
+   if (test_modeset)
+   return ret;
+
igt_skip_on(ret != 0);
 
igt_set_timeout(1, "Stuck on page flip");
@@ -181,8 +188,7 @@ check_mode(drmModeModeInfo *mode1, drmModeModeInfo *mode2)
 }
 
 static drmModeModeInfo *
-test_setup(data_t *data, enum pipe pipe, uint64_t modifier, int flags,
-  igt_output_t *output)
+test_setup(data_t *data, enum pipe pipe, uint64_t modifier, igt_output_t 
*output)
 {
struct kmstest_crtc crtc;
drmModeModeInfo *mode;
@@ -238,21 +244,21 @@ test_setup(data_t *data, enum pipe pipe, uint64_t 
modifier, int flags,
 
 static void
 test_plane_position_with_output(data_t *data, enum pipe pipe,
-   igt_output_t *output, uint64_t modifier)
+   igt_output_t *output, uint64_t modifier,
+   bool test_modeset)
 {
igt_crc_t *crc_hires1, *crc_hires2;
igt_crc_t *crc_lowres;
drmModeModeInfo mode_lowres;
drmModeModeInfo *mode1, *mode2, *mode3;
int ret, n;
-   int flags = DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_ALLOW_MODESET;
 
igt_info("Testing connector %s using pipe %s\n",
 igt_output_name(output), kmstest_pipe_name(pipe));
 
test_init(data, pipe);
 
-   mode1 = test_setup(data, pipe, modifier, flags, output);
+   mode1 = test_setup(data, pipe, modifier, output);
 
mode_lowres = get_lowres_mode(data->drm_fd, mode1);
 
@@ -273,7 +279,12 @@ test_plane_position_with_output(data_t *data, enum pipe 
pipe,
 
check_mode(&mode_lowres, mode2);
 
-   display_commit_mode(data, pipe, flags, crc_lowres);
+   ret = display_commit_mode(data, pipe, test_modeset, crc_lowres);
+
+   if (test_modeset) {
+   igt_assert(ret != 0);
+   goto out;
+   }
 
igt_assert_plane_visible(pipe, false);
 
@@ -285,17 +296,24 @@ test_plane_position_with_output(data_t *data, enum pipe 
pipe,
 
check_mode(mode1, mode3);
 
-   display_commit_mode(data, pipe, flags, crc_hires2);
+   ret = display_commit_mode(data, pipe, test_modeset, crc_hires2);
+
+   if (test_modeset) {
+   igt_assert(ret != 0);
+   goto out;
+   }
 
igt_assert_plane_visible(pipe, true);
 
+out:
igt_pipe_crc_stop(data->pipe_crc);
 
test_fini(data, output);
 }
 
 static void
-test_plane_position(data_t *data, enum pipe pipe, uint64_t modifier)
+test_plane_position(data_t *data, enum pipe pipe, uint64_t modifier,
+   bool test_modeset)
 {
igt_output_t *output;
int connected_outs;
@@ -310,7 +328,8 @@ test_plane_position(data_t *data, enum pipe pipe, uint64_t 
modifier)
 
connected_outs = 0;
for_each_valid_output_on_pipe(&data->display, pipe, output) {
-   test_plane_position_with_output(data, pipe, output, modifier);
+   test_plane_position_with_output(data, pipe, output, modifier,
+   test_modeset);
connected_outs++;
}
 
@@ -322,19 +341,23 @@ run_tests_for_pipe(data_t *data, enum pipe pipe)
 {
igt_subtest_f("pipe-%s-tiling-none",
  kmstest_pipe_name(pipe))
-   test_plane_position(data, pipe, LOCAL_DRM_FORMAT_MOD_NONE);
+   test_plane_position(data, pipe, LOCAL_DRM_FORMAT_MOD_NONE, 
false);
 
igt_subtest_f("pipe-%s-tiling-x",

[Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev4)

2017-02-07 Thread Patchwork

== Series Details ==

Series: GLK MIPI DSI VIDEO MODE PATCHES (rev4)
URL   : https://patchwork.freedesktop.org/series/16542/
State : failure

== Summary ==

Series 16542v4 GLK MIPI DSI VIDEO MODE PATCHES
https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/4/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (fi-hsw-4770)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> DMESG-WARN (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
dmesg-warn -> PASS   (fi-snb-2520m)

fi-bdw-5557u total:252  pass:238  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:230  dwarn:0   dfail:0   fail:0   skip:22 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:5pass:4dwarn:0   dfail:0   fail:0   skip:0  
fi-hsw-4770r total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-ilk-650   total:252  pass:199  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:252  pass:231  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:252  pass:229  dwarn:0   dfail:0   fail:2   skip:21 
fi-skl-6260u total:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:252  pass:232  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:252  pass:227  dwarn:4   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:252  pass:239  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:252  pass:220  dwarn:1   dfail:0   fail:0   skip:31 
fi-snb-2600  total:252  pass:220  dwarn:0   dfail:0   fail:0   skip:32 

4b60513d8a00fc960a2d837fcccf6a63c861d9ec drm-tip: 2017y-02m-06d-22h-40m-55s UTC 
integration manifest
19d6c91 drm/i915/glk: Validate only DSI PORT A PLL divider
148161b drm/i915/glk: Program txesc clock divider for GLK
0e319d9 drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT
0541e3b drm/i915/glk: Add DSI PLL divider range for glk
2ab172c drm/i915: Set the Z inversion overlap field
84af990 drm/i915/glk: Add MIPIIO Enable/disable sequence
dfa5542 drm/i915/glk: Program new MIPI DSI PHY registers for GLK
b8593e8 drm/i915/glk: Program dphy param reg for GLK

== Logs ==

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

Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware

2017-02-07 Thread Uwe Kleine-König

Hello,

On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
>>> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
 Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
 Just curious, does this help?

 diff --git a/drivers/gpu/drm/i915/intel_pm.c 
 b/drivers/gpu/drm/i915/intel_pm.c
 index ae2c0bb4b2e8..13de4c526ca6 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct 
 intel_crtc_state *cstate,
 * this is necessary to avoid flickering.
 */
int cpp = 4;
 -  int width = pstate->base.visible ? pstate->base.crtc_w : 64;
 +  int width = 256;
  
if (!cstate->base.active)
return 0;

>>> On a kernel with this patch applied I cannot reproduce the flickering. I
>>> keep that kernel running but expect that it also fixes the crash.
>>
>> Ok that's good news.
>>
>> Maybe ville or matt can comment whether this patch is the right fix?
> 
> Well, it's just extending the hack even further. The right fix would be
> to fix the wm programming sequence to respect the frame boundaries
> correctly (ie. my old vblank based wm stuff).

so I wonder how this goes forward. The situation seems to be well
understood, but other than testing patches I don't know what to do (and
there is currently no patch to test).

Best regards
Uwe



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Do RPM Wake during GuC/HuC status read

2017-02-07 Thread Arkadiusz Hiler

On Mon, Feb 06, 2017 at 10:34:31AM +0530, Kamble, Sagar A wrote:
> 
> 
> On 2/4/2017 7:40 PM, Arkadiusz Hiler wrote:
> > On Fri, Feb 03, 2017 at 01:58:33PM +0530, Sagar Arun Kamble wrote:
> > > HUC_STATUS, GUC_STATUS, SOFT_SCRATCH registers are read in debugfs
> > > and getparam ioctl. This patch covers those accesses by RPM get/put.
> > > 
> > > v2: Covering access in i915_getparam(I915_PARAM_HUC_STATUS) (ChrisW)
> > > 
> > > Cc: Arkadiusz Hiler 
> > > Cc: Anusha Srivatsa 
> > > Cc: Fiedorowicz, Lukasz 
> > > Signed-off-by: Sagar Arun Kamble 
> > > ---
> > >   drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
> > >   drivers/gpu/drm/i915/i915_drv.c | 5 ++---
> > >   2 files changed, 8 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 3ae0656..639ed12 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2374,7 +2374,9 @@ static int i915_huc_load_status_info(struct 
> > > seq_file *m, void *data)
> > >   seq_printf(m, "\tRSA: offset is %d; size = %d\n",
> > >   huc_fw->rsa_offset, huc_fw->rsa_size);
> > > + intel_runtime_pm_get(dev_priv);
> > >   seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
> > > + intel_runtime_pm_put(dev_priv);
> > >   return 0;
> > >   }
> > Are you sure that HUC_STATUS2 requires RPM get for reading?
> > 
> > I remember trying reading it with device forcefully asleep and it
> > succeed just fine.
> Hi Arek,
> 
> Faced following warning with device runtime_status=suspended.
> Also this register lies in media forcewake range and should have similar RPM
> get/put needs as other registers unless this has special behavior I am not
> aware of.

Reviewed-by: Arkadiusz Hiler 

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

[Intel-gfx] [patch] drm/i915/gvt/kvmgt: remove some dead code

2017-02-07 Thread Dan Carpenter

If "caps.buf" is already NULL then it doesn't need to be freed or set to
NULL.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..de2a55178a37 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
sparse->areas[0].offset =
PAGE_ALIGN(vgpu_aperture_offset(vgpu));
sparse->areas[0].size = vgpu_aperture_sz(vgpu);
-   if (!caps.buf) {
-   kfree(caps.buf);
-   caps.buf = NULL;
+   if (!caps.buf)
caps.size = 0;
-   }
break;
 
case VFIO_PCI_BAR3_REGION_INDEX ... VFIO_PCI_BAR5_REGION_INDEX:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm: Cancel drm_fb_helper_resume_work on unload

2017-02-07 Thread Chris Wilson

We can not allow the worker to run after its fbdev, or even the module,
has been removed.

Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Chris Wilson 
Cc: Noralf Trønnes 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: dri-de...@lists.freedesktop.org
Cc:  # v4.9+
---
 drivers/gpu/drm/drm_fb_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2d0810c9f3dc..842c461b0b21 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -860,6 +860,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return;
 
+   cancel_work_sync(&fb_helper->resume_work);
cancel_work_sync(&fb_helper->dirty_work);
 
mutex_lock(&kernel_fb_helper_lock);
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/2] drm: Cancel drm_fb_helper_dirty_work on unload

2017-02-07 Thread Chris Wilson

We can not allow the worker to run after its fbdev, or even the module,
has been removed.

Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support")
Signed-off-by: Chris Wilson 
Cc: Noralf Trønnes 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: dri-de...@lists.freedesktop.org
Cc:  # v4.7+
---
 drivers/gpu/drm/drm_fb_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ee7cbcd3cfeb..2d0810c9f3dc 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -860,6 +860,8 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return;
 
+   cancel_work_sync(&fb_helper->dirty_work);
+
mutex_lock(&kernel_fb_helper_lock);
if (!list_empty(&fb_helper->kernel_fb_list)) {
list_del(&fb_helper->kernel_fb_list);
-- 
2.11.0

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

[Intel-gfx] [GLK MIPI DSI V4 8/8] drm/i915/glk: Validate only DSI PORT A PLL divider

2017-02-07 Thread Madhav Chauhan

As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A.
Therefore only for PORT A PLL divider value should be validated.

Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index b1cc006..11c2a1c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -206,17 +206,24 @@ static bool bxt_dsi_pll_is_enabled(struct 
drm_i915_private *dev_priv)
return false;
 
/*
-* Both dividers must be programmed with valid values even if only one
-* of the PLL is used, see BSpec/Broxton Clocks. Check this here for
+* Dividers must be programmed with valid values. As per BSEPC, for
+* GEMINLAKE only PORT A divider values are checked while for BXT
+* both divider values are validated. Check this here for
 * paranoia, since BIOS is known to misconfigure PLLs in this way at
 * times, and since accessing DSI registers with invalid dividers
 * causes a system hang.
 */
val = I915_READ(BXT_DSI_PLL_CTL);
-   if (!(val & BXT_DSIA_16X_MASK) || !(val & BXT_DSIC_16X_MASK)) {
-   DRM_DEBUG_DRIVER("PLL is enabled with invalid divider settings 
(%08x)\n",
-val);
-   enabled = false;
+   if (IS_GEMINILAKE(dev_priv)) {
+   if (!(val & BXT_DSIA_16X_MASK)) {
+   DRM_DEBUG_DRIVER("Invalid PLL divider (%08x)\n", val);
+   enabled = false;
+   }
+   } else {
+   if (!(val & BXT_DSIA_16X_MASK) || !(val & BXT_DSIC_16X_MASK)) {
+   DRM_DEBUG_DRIVER("Invalid PLL divider (%08x)\n", val);
+   enabled = false;
+   }
}
 
return enabled;
-- 
1.9.1

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

[Intel-gfx] [GLK MIPI DSI V4 6/8] drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 2771c9c..462d42d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -491,8 +491,10 @@ static void bxt_enable_dsi_pll(struct intel_encoder 
*encoder,
POSTING_READ(BXT_DSI_PLL_CTL);
 
/* Program TX, RX, Dphy clocks */
-   for_each_dsi_port(port, intel_dsi->ports)
-   bxt_dsi_program_clocks(encoder->base.dev, port, config);
+   if (IS_BROXTON(dev_priv)) {
+   for_each_dsi_port(port, intel_dsi->ports)
+   bxt_dsi_program_clocks(encoder->base.dev, port, config);
+   }
 
/* Enable DSI PLL */
val = I915_READ(BXT_DSI_PLL_ENABLE);
@@ -556,19 +558,22 @@ void intel_disable_dsi_pll(struct intel_encoder *encoder)
bxt_disable_dsi_pll(encoder);
 }
 
-static void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port)
+static void gen9lp_dsi_reset_clocks(struct intel_encoder *encoder,
+   enum port port)
 {
u32 tmp;
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
/* Clear old configurations */
-   tmp = I915_READ(BXT_MIPI_CLOCK_CTL);
-   tmp &= ~(BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port));
-   tmp &= ~(BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port));
-   tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
-   tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
-   I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
+   if (IS_BROXTON(dev_priv)) {
+   tmp = I915_READ(BXT_MIPI_CLOCK_CTL);
+   tmp &= ~(BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port));
+   tmp &= ~(BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port));
+   tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
+   tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
+   I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
+   }
I915_WRITE(MIPI_EOT_DISABLE(port), CLOCKSTOP);
 }
 
@@ -577,7 +582,7 @@ void intel_dsi_reset_clocks(struct intel_encoder *encoder, 
enum port port)
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
 
if (IS_GEN9_LP(dev_priv))
-   bxt_dsi_reset_clocks(encoder, port);
+   gen9lp_dsi_reset_clocks(encoder, port);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
vlv_dsi_reset_clocks(encoder, port);
 }
-- 
1.9.1

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

[Intel-gfx] [GLK MIPI DSI V4 7/8] drm/i915/glk: Program txesc clock divider for GLK

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

v2: Addressed Jani's Review comments(renamed bit field macros)

Txesc clock divider is calculated and programmed
for geminilake platform.

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/i915_reg.h  |  5 +++
 drivers/gpu/drm/i915/intel_dsi_pll.c | 61 ++--
 2 files changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 92071d6..37121f5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8235,6 +8235,11 @@ enum {
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
 #define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
 
+#define MIPIO_TXESC_CLK_DIV1   _MMIO(0x160004)
+#define  GLK_TX_ESC_CLK_DIV1_MASK  0x3FF
+#define MIPIO_TXESC_CLK_DIV2   _MMIO(0x160008)
+#define  GLK_TX_ESC_CLK_DIV2_MASK  0x3FF
+
 /* BXT MIPI clock controls */
 #define BXT_MAX_VAR_OUTPUT_KHZ 39500
 
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 462d42d..b1cc006 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -372,6 +372,53 @@ static void vlv_dsi_reset_clocks(struct intel_encoder 
*encoder, enum port port)
ESCAPE_CLOCK_DIVIDER_SHIFT);
 }
 
+static void glk_dsi_program_esc_clock(struct drm_device *dev,
+  const struct intel_crtc_state *config)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   u32 dsi_rate = 0;
+   u32 pll_ratio = 0;
+   u32 ddr_clk = 0;
+   u32 div1_value = 0;
+   u32 div2_value = 0;
+   u32 txesc1_div = 0;
+   u32 txesc2_div = 0;
+
+   pll_ratio = config->dsi_pll.ctrl & BXT_DSI_PLL_RATIO_MASK;
+
+   dsi_rate = (BXT_REF_CLOCK_KHZ * pll_ratio) / 2;
+
+   ddr_clk = dsi_rate / 2;
+
+   /* Variable divider value */
+   div1_value = DIV_ROUND_CLOSEST(ddr_clk, 2);
+
+   /* Calculate TXESC1 divider */
+   if (div1_value <= 10)
+   txesc1_div = div1_value;
+   else if ((div1_value > 10) && (div1_value <= 20))
+   txesc1_div = DIV_ROUND_UP(div1_value, 2);
+   else if ((div1_value > 20) && (div1_value <= 30))
+   txesc1_div = DIV_ROUND_UP(div1_value, 4);
+   else if ((div1_value > 30) && (div1_value <= 40))
+   txesc1_div = DIV_ROUND_UP(div1_value, 6);
+   else if ((div1_value > 40) && (div1_value <= 50))
+   txesc1_div = DIV_ROUND_UP(div1_value, 8);
+   else
+   txesc1_div = 10;
+
+   /* Calculate TXESC2 divider */
+   div2_value = DIV_ROUND_UP(div1_value, txesc1_div);
+
+   if (div2_value < 10)
+   txesc2_div = div2_value;
+   else
+   txesc2_div = 10;
+
+   I915_WRITE(MIPIO_TXESC_CLK_DIV1, txesc1_div & GLK_TX_ESC_CLK_DIV1_MASK);
+   I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & GLK_TX_ESC_CLK_DIV2_MASK);
+}
+
 /* Program BXT Mipi clocks and dividers */
 static void bxt_dsi_program_clocks(struct drm_device *dev, enum port port,
   const struct intel_crtc_state *config)
@@ -476,7 +523,7 @@ static int gen9lp_compute_dsi_pll(struct intel_encoder 
*encoder,
return 0;
 }
 
-static void bxt_enable_dsi_pll(struct intel_encoder *encoder,
+static void gen9lp_enable_dsi_pll(struct intel_encoder *encoder,
   const struct intel_crtc_state *config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -494,6 +541,8 @@ static void bxt_enable_dsi_pll(struct intel_encoder 
*encoder,
if (IS_BROXTON(dev_priv)) {
for_each_dsi_port(port, intel_dsi->ports)
bxt_dsi_program_clocks(encoder->base.dev, port, config);
+   } else {
+   glk_dsi_program_esc_clock(encoder->base.dev, config);
}
 
/* Enable DSI PLL */
@@ -545,7 +594,7 @@ void intel_enable_dsi_pll(struct intel_encoder *encoder,
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
vlv_enable_dsi_pll(encoder, config);
else if (IS_GEN9_LP(dev_priv))
-   bxt_enable_dsi_pll(encoder, config);
+   gen9lp_enable_dsi_pll(encoder, config);
 }
 
 void intel_disable_dsi_pll(struct intel_encoder *encoder)
@@ -573,6 +622,14 @@ static void gen9lp_dsi_reset_clocks(struct intel_encoder 
*encoder,
tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
+   } else {
+   tmp = I915_READ(MIPIO_TXESC_CLK_DIV1);
+   tmp &= ~GLK_TX_ESC_CLK_DIV1_MASK;
+   I915_WRITE(MIPIO_TXESC_CLK_DIV1, tmp);
+
+   tmp = I915_READ(MIPIO_TXESC_CLK_DIV2);
+

[Intel-gfx] [GLK MIPI DSI V4 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Jani's Review comment for aligning code to platforms and added
wrapper functions.
v4: Corrected enable/disable seuqence as per BSPEC

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi.c | 206 ---
 1 file changed, 195 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index be81283..0def214 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
return true;
 }
 
+static void glk_dsi_device_ready(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+   enum port port;
+   u32 tmp, val;
+
+   /* Set the MIPI mode
+* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
+* Power ON MIPI IO first and then write into IO reset and LP wake bits
+*/
+   for_each_dsi_port(port, intel_dsi->ports) {
+   tmp = I915_READ(MIPI_CTRL(port));
+   I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
+   }
+
+   /* Put the IO into reset */
+   tmp = I915_READ(MIPI_CTRL(PORT_A));
+   tmp &= ~GLK_MIPIIO_RESET_RELEASED;
+   I915_WRITE(MIPI_CTRL(PORT_A), tmp);
+
+   /* Program LP Wake */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   tmp = I915_READ(MIPI_CTRL(port));
+   tmp |= GLK_LP_WAKE;
+   I915_WRITE(MIPI_CTRL(port), tmp);
+   }
+
+   /* Wait for Pwr ACK */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
+   GLK_MIPIIO_PORT_POWERED, 20))
+   DRM_ERROR("Power ACK not received\n");
+   }
+
+   /* Wait for MIPI PHY status bit to set */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
+   GLK_MIPIIO_PORT_POWERED, 20))
+   DRM_ERROR("PHY is not ON\n");
+   }
+
+   /* Get IO out of reset */
+   tmp = I915_READ(MIPI_CTRL(PORT_A));
+   I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
+
+   /* Get IO out of Low power state*/
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) {
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= DEVICE_READY;
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   usleep_range(10, 15);
+   }
+
+   /* Enter ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_ENTER | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+   /* Wait for ULPS Not active */
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
+   GLK_ULPS_NOT_ACTIVE, 20))
+
+   /* Exit ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_EXIT | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+   /* Enter Normal Mode */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+
+   tmp = I915_READ(MIPI_CTRL(port));
+   tmp &= ~GLK_LP_WAKE;
+   I915_WRITE(MIPI_CTRL(port), tmp);
+   }
+
+   /* Wait for Stop state */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE,
+   GLK_DATA_LANE_STOP_STATE, 20))
+   DRM_ERROR("Date lane not in STOP state\n");
+   }
+
+   /* Wait for AFE LATCH */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   if (intel_wait_for_register(dev_priv,
+   BXT_MIPI_PORT_CTRL(port), AFE_LATCHOUT,
+   AFE_LATCHOUT, 20))
+   DRM_ERROR("D-PHY not entering LP-11 state\n");
+   }
+}
+
 static void bxt_dsi_device_ready(struct intel_encoder *encoder)

[Intel-gfx] [GLK MIPI DSI V4 4/8] drm/i915: Set the Z inversion overlap field

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

Dual link Z-inversion overlap field is present
in MIPI_CTRL register unlike the older platforms,
hence setting the same in this patch.

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 0def214..bd2d180 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -561,12 +561,21 @@ static void intel_dsi_port_enable(struct intel_encoder 
*encoder)
 
if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
u32 temp;
-
-   temp = I915_READ(VLV_CHICKEN_3);
-   temp &= ~PIXEL_OVERLAP_CNT_MASK |
+   if (IS_GEN9_LP(dev_priv)) {
+   for_each_dsi_port(port, intel_dsi->ports) {
+   temp = I915_READ(MIPI_CTRL(port));
+   temp &= ~BXT_PIXEL_OVERLAP_CNT_MASK |
+   intel_dsi->pixel_overlap <<
+   BXT_PIXEL_OVERLAP_CNT_SHIFT;
+   I915_WRITE(MIPI_CTRL(port), temp);
+   }
+   } else {
+   temp = I915_READ(VLV_CHICKEN_3);
+   temp &= ~PIXEL_OVERLAP_CNT_MASK |
intel_dsi->pixel_overlap <<
PIXEL_OVERLAP_CNT_SHIFT;
-   I915_WRITE(VLV_CHICKEN_3, temp);
+   I915_WRITE(VLV_CHICKEN_3, temp);
+   }
}
 
for_each_dsi_port(port, intel_dsi->ports) {
-- 
1.9.1

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

[Intel-gfx] [GLK MIPI DSI V4 2/8] drm/i915/glk: Program new MIPI DSI PHY registers for GLK

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

Program the clk lane and tlpx time count registers
to configure DSI PHY.

v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Program clk lane timing reg same as dphy param reg.

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/i915_reg.h  | 8 
 drivers/gpu/drm/i915/intel_dsi.c | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 31e9583..80ba02a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8603,6 +8603,14 @@ enum {
 #define  LP_BYTECLK_SHIFT  0
 #define  LP_BYTECLK_MASK   (0x << 0)
 
+#define _MIPIA_TLPX_TIME_COUNT (dev_priv->mipi_mmio_base + 0xb0a4)
+#define _MIPIC_TLPX_TIME_COUNT (dev_priv->mipi_mmio_base + 0xb8a4)
+#define MIPI_TLPX_TIME_COUNT(port)  _MMIO_MIPI(port, 
_MIPIA_TLPX_TIME_COUNT, _MIPIC_TLPX_TIME_COUNT)
+
+#define _MIPIA_CLK_LANE_TIMING (dev_priv->mipi_mmio_base + 0xb098)
+#define _MIPIC_CLK_LANE_TIMING (dev_priv->mipi_mmio_base + 0xb898)
+#define MIPI_CLK_LANE_TIMING(port)  _MMIO_MIPI(port, 
_MIPIA_CLK_LANE_TIMING, _MIPIC_CLK_LANE_TIMING)
+
 /* bits 31:0 */
 #define _MIPIA_LP_GEN_DATA (dev_priv->mipi_mmio_base + 0xb064)
 #define _MIPIC_LP_GEN_DATA (dev_priv->mipi_mmio_base + 0xb864)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 16732e7..be81283 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1279,6 +1279,13 @@ static void intel_dsi_prepare(struct intel_encoder 
*intel_encoder,
 */
I915_WRITE(MIPI_LP_BYTECLK(port), intel_dsi->lp_byte_clk);
 
+   if (IS_GEMINILAKE(dev_priv)) {
+   I915_WRITE(MIPI_TLPX_TIME_COUNT(port),
+   intel_dsi->lp_byte_clk);
+   /* Shadow of DPHY reg */
+   I915_WRITE(MIPI_CLK_LANE_TIMING(port), 
intel_dsi->dphy_reg);
+   }
+
/* the bw essential for transmitting 16 long packets containing
 * 252 bytes meant for dcs write memory command is programmed in
 * this register in terms of byte clocks. based on dsi transfer
-- 
1.9.1

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

[Intel-gfx] [GLK MIPI DSI V4 1/8] drm/i915/glk: Program dphy param reg for GLK

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock count while for older platforms in terms of
HS ddr clk count.

v2: Added comments to clarify ddr clock count calculation

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 45 --
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 8f683b8..b3c495f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -674,11 +674,6 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
*intel_dsi, u16 panel_id)
break;
}
 
-   /*
-* ui(s) = 1/f [f in hz]
-* ui(ns) = 10^9 / (f*10^6) [f in Mhz] -> 10^3/f(Mhz)
-*/
-
/* in Kbps */
ui_num = NS_KHZ_RATIO;
ui_den = bitrate;
@@ -692,19 +687,32 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
*intel_dsi, u16 panel_id)
 */
intel_dsi->lp_byte_clk = DIV_ROUND_UP(tlpx_ns * ui_den, 8 * ui_num);
 
-   /* count values in UI = (ns value) * (bitrate / (2 * 10^6))
+   /* DDR clock period = 2 * UI
+* UI(sec) = 1/(bitrate * 10^3) (bitrate is in KHZ)
+* UI(nsec) = 10^6 / bitrate
+* DDR clock period (nsec) = 2 * UI = (2 * 10^6)/ bitrate
+* DDR clock count  = ns_value / DDR clock period
 *
-* Since txddrclkhs_i is 2xUI, all the count values programmed in
-* DPHY param register are divided by 2
+* For GEMINILAKE dphy_param_reg will be programmed in terms of
+* HS byte clock count for other platform in HS ddr clock count
 *
 * prepare count
 */
ths_prepare_ns = max(mipi_config->ths_prepare,
 mipi_config->tclk_prepare);
-   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 2);
+   if (IS_GEMINILAKE(dev_priv))
+   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 8);
+   else
+   prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 2);
 
/* exit zero count */
-   exit_zero_cnt = DIV_ROUND_UP(
+   if (IS_GEMINILAKE(dev_priv))
+   exit_zero_cnt = DIV_ROUND_UP(
+   (ths_prepare_hszero - ths_prepare_ns) * ui_den,
+   ui_num * 8
+   );
+   else
+   exit_zero_cnt = DIV_ROUND_UP(
(ths_prepare_hszero - ths_prepare_ns) * ui_den,
ui_num * 2
);
@@ -719,13 +727,22 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
*intel_dsi, u16 panel_id)
exit_zero_cnt += 1;
 
/* clk zero count */
-   clk_zero_cnt = DIV_ROUND_UP(
-   (tclk_prepare_clkzero - ths_prepare_ns)
-   * ui_den, 2 * ui_num);
+   if (IS_GEMINILAKE(dev_priv))
+   clk_zero_cnt = DIV_ROUND_UP(
+   (tclk_prepare_clkzero - ths_prepare_ns)
+   * ui_den, 8 * ui_num);
+   else
+   clk_zero_cnt = DIV_ROUND_UP(
+   (tclk_prepare_clkzero - ths_prepare_ns)
+   * ui_den, 2 * ui_num);
 
/* trail count */
tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
-   trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 2 * ui_num);
+
+   if (IS_GEMINILAKE(dev_priv))
+   trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 8 * ui_num);
+   else
+   trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 2 * ui_num);
 
if (prepare_cnt > PREPARE_CNT_MAX ||
exit_zero_cnt > EXIT_ZERO_CNT_MAX ||
-- 
1.9.1

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

[Intel-gfx] [GLK MIPI DSI V4 5/8] drm/i915/glk: Add DSI PLL divider range for glk

2017-02-07 Thread Madhav Chauhan

From: Deepak M 

PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.

Signed-off-by: Deepak M 
Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/i915_reg.h  |  4 
 drivers/gpu/drm/i915/intel_dsi_pll.c | 20 ++--
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 80ba02a..92071d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8321,10 +8321,12 @@ enum {
 #define  BXT_DSI_PLL_PVD_RATIO_SHIFT   16
 #define  BXT_DSI_PLL_PVD_RATIO_MASK(3 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
 #define  BXT_DSI_PLL_PVD_RATIO_1   (1 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
+#define  BXT_DSIC_16X_BY1  (0 << 10)
 #define  BXT_DSIC_16X_BY2  (1 << 10)
 #define  BXT_DSIC_16X_BY3  (2 << 10)
 #define  BXT_DSIC_16X_BY4  (3 << 10)
 #define  BXT_DSIC_16X_MASK (3 << 10)
+#define  BXT_DSIA_16X_BY1  (0 << 8)
 #define  BXT_DSIA_16X_BY2  (1 << 8)
 #define  BXT_DSIA_16X_BY3  (2 << 8)
 #define  BXT_DSIA_16X_BY4  (3 << 8)
@@ -8334,6 +8336,8 @@ enum {
 
 #define BXT_DSI_PLL_RATIO_MAX  0x7D
 #define BXT_DSI_PLL_RATIO_MIN  0x22
+#define GLK_DSI_PLL_RATIO_MAX  0x6F
+#define GLK_DSI_PLL_RATIO_MIN  0x22
 #define BXT_DSI_PLL_RATIO_MASK 0xFF
 #define BXT_REF_CLOCK_KHZ  19200
 
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 61440e5..2771c9c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -430,9 +430,10 @@ static void bxt_dsi_program_clocks(struct drm_device *dev, 
enum port port,
I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
 }
 
-static int bxt_compute_dsi_pll(struct intel_encoder *encoder,
+static int gen9lp_compute_dsi_pll(struct intel_encoder *encoder,
   struct intel_crtc_state *config)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
u8 dsi_ratio;
u32 dsi_clk;
@@ -446,11 +447,18 @@ static int bxt_compute_dsi_pll(struct intel_encoder 
*encoder,
 * round 'up' the result
 */
dsi_ratio = DIV_ROUND_UP(dsi_clk * 2, BXT_REF_CLOCK_KHZ);
-   if (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
-   dsi_ratio > BXT_DSI_PLL_RATIO_MAX) {
+
+   if (IS_BROXTON(dev_priv) && (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
+   dsi_ratio > BXT_DSI_PLL_RATIO_MAX)) {
DRM_ERROR("Cant get a suitable ratio from DSI PLL ratios\n");
return -ECHRNG;
-   }
+   } else if (IS_GEMINILAKE(dev_priv) &&
+   (dsi_ratio < GLK_DSI_PLL_RATIO_MIN ||
+   dsi_ratio > GLK_DSI_PLL_RATIO_MAX)) {
+   DRM_ERROR("Cant get a suitable ratio from DSI PLL ratios\n");
+   return -ECHRNG;
+   } else
+   DRM_DEBUG_KMS("DSI PLL calculation is Done!!\n");
 
/*
 * Program DSI ratio and Select MIPIC and MIPIA PLL output as 8x
@@ -462,7 +470,7 @@ static int bxt_compute_dsi_pll(struct intel_encoder 
*encoder,
/* As per recommendation from hardware team,
 * Prog PVD ratio =1 if dsi ratio <= 50
 */
-   if (dsi_ratio <= 50)
+   if (IS_BROXTON(dev_priv) && dsi_ratio <= 50)
config->dsi_pll.ctrl |= BXT_DSI_PLL_PVD_RATIO_1;
 
return 0;
@@ -522,7 +530,7 @@ int intel_compute_dsi_pll(struct intel_encoder *encoder,
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
return vlv_compute_dsi_pll(encoder, config);
else if (IS_GEN9_LP(dev_priv))
-   return bxt_compute_dsi_pll(encoder, config);
+   return gen9lp_compute_dsi_pll(encoder, config);
 
return -ENODEV;
 }
-- 
1.9.1

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

[Intel-gfx] [GLK MIPI DSI V4 0/8] GLK MIPI DSI VIDEO MODE PATCHES

2017-02-07 Thread Madhav Chauhan

The patches in this list enable MIPI DSI video mode
support for GLK platform. Tesed locally.
v2: Renamed bitfields macros as per review comments(Jani)
v3: Code alignment/abstraction as per arch (Jani review comments)
v4: Fix DSI disable sequence, pll divider checks. Review comments(Jani)

Deepak M (7):
  drm/i915/glk: Program dphy param reg for GLK
  drm/i915/glk: Program new MIPI DSI PHY registers for GLK
  drm/i915/glk: Add MIPIIO Enable/disable sequence
  drm/i915: Set the Z inversion overlap field
  drm/i915/glk: Add DSI PLL divider range for glk
  drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT
  drm/i915/glk: Program txesc clock divider for GLK

Madhav Chauhan (1):
  drm/i915/glk: Validate only DSI PORT A PLL divider

 drivers/gpu/drm/i915/i915_reg.h|  17 +++
 drivers/gpu/drm/i915/intel_dsi.c   | 230 +++--
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  45 --
 drivers/gpu/drm/i915/intel_dsi_pll.c   | 125 +---
 4 files changed, 364 insertions(+), 53 deletions(-)

-- 
1.9.1

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

1 2 >

1 - 100 of 129 matches

Mail list logo