Re: [Intel-gfx] screen update problems with Intel HD 4600 + virtual screen

[Krzysztof Halasa]

Chris Wilson  writes:

>> switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 7), 
>> rotation normal
>> 
>> Now I scroll down 1 pixel:
>> switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 8), 
>> rotation normal
>> 
>> and immediately screen isn't updated correctly. For example, an
>> application window is created normally, but when I move it (the app
>> window) down, the top part of the window, max 8 pixels, is left on the
>> screen (the moved window is ok). It almost looks like the code somewhere
>> adds the vertical screen offset twice.
>
> 8 is significant as it is the tile row height. The kernel tries to be
> smart and extract the panning from the surface address so that we can
> display a larger virtual framebuffer than the hardware can actually use.
>
> Can you reproduce the about sequence with drm.debug=6 dmesg (i.e.
> echo 6 > /sys/module/drm/parameters/debug ; xrandr --panning... ;
> dmesg)?

I'm panning with the mouse. Doesn't look like a lot of output:

no problem yet:
[617996.928] (II) intel(0): switch to mode 1920x1200@60.0 on pipe 0 using 
HDMI1, position (2176, 7), rotation normal

[618556.836459] [drm:drm_mode_setcrtc], [CRTC:3]
[618556.836472] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[618556.836478] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 7)
[618556.836484] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[618556.836489] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[618556.836500] [drm:ironlake_update_plane], Writing base 013CA000 D200 0 7 
16384
[618556.836511] [drm:i915_setup_compression], reserved 39583744 bytes of 
contiguous stolen space for FBC
[618556.836515] [drm:intel_update_fbc], disabling active FBC for update
[618556.836520] [drm:ironlake_disable_fbc], disabled FBC
[618556.836594] [drm:intel_crtc_cursor_set], cursor off
[618556.885876] [drm:gen7_enable_fbc], enabled fbc on plane A
[618565.988566] [drm:intel_crtc_cursor_set], cursor off


problems:
[618016.920] (II) intel(0): switch to mode 1920x1200@60.0 on pipe 0 using 
HDMI1, position (2176, 8), rotation normal

[618576.846085] [drm:drm_mode_setcrtc], [CRTC:3]
[618576.846094] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[618576.846098] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 8)
[618576.846103] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[618576.846106] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[618576.846114] [drm:ironlake_update_plane], Writing base 013CA000 
1200 0 0 16384
[618576.846122] [drm:i915_setup_compression], reserved 39583744 bytes of 
contiguous stolen space for FBC
[618576.846125] [drm:intel_update_fbc], disabling active FBC for update
[618576.846128] [drm:ironlake_disable_fbc], disabled FBC
[618576.846181] [drm:intel_crtc_cursor_set], cursor off
[618576.895986] [drm:gen7_enable_fbc], enabled fbc on plane A
[618588.640637] [drm:intel_crtc_cursor_set], cursor off

The kernel is a normal Fedora 20 - Linux 3.14.7-200.fc20.x86_64.

The sequence:
echo 6 > /sys/module/drm/parameters/debug; xrandr --output HDMI1 --panning 
4096x2404; dmesg
(i.e., only panning setup but no actual panning) produces:

[619598.009625] [drm:drm_mode_getconnector], [CONNECTOR:9:?]
[619598.009631] [drm:drm_helper_probe_single_connector_modes_merge_bits], 
[CONNECTOR:9:VGA-1]
[619598.009634] [drm:intel_crt_detect], [CONNECTOR:9:VGA-1] force=1
[619598.009638] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug 
adpa=0xf4, result 0
[619598.009639] [drm:intel_crt_detect], CRT not detected via hotplug
[619598.009807] [drm:gmbus_xfer], GMBUS [i915 gmbus vga] NAK for addr: 0050 r(1)
[619598.009810] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter 
i915 gmbus vga
[619598.009812] [drm:intel_crt_get_edid], CRT GMBUS EDID read failed, retry 
using GPIO bit-banging
[619598.009814] [drm:intel_gmbus_force_bit], enabling bit-banging on i915 gmbus 
vga. force bit now 1
[619598.010186] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter 
i915 gmbus vga
[619598.010188] [drm:intel_gmbus_force_bit], disabling bit-banging on i915 
gmbus vga. force bit now 0
[619598.010189] [drm:intel_crt_detect_ddc], CRT not detected via DDC:0x50 [no 
valid EDID found]
[619598.010191] [drm:drm_helper_probe_single_connector_modes_merge_bits], 
[CONNECTOR:9:VGA-1] disconnected
[619598.010202] [drm:drm_mode_getconnector], [CONNECTOR:12:?]
[619598.010204] [drm:drm_helper_probe_single_connector_modes_merge_bits], 
[CONNECTOR:12:HDMI-A-1]
[619598.010208] [drm:intel_hdmi_detect], [CONNECTOR:12:HDMI-A-1]
[619598.060006] [drm:drm_edid_to_eld], ELD monitor EA241WM
[619598.060008] [drm:drm_edid_to_eld], ELD size 7, SAD count 0
[619598.060022] [drm:drm_helper_probe_single_connector_modes_merge_bits], 
[CONNECTOR:12:HDMI-A-1] probed modes :
[6195

Re: [Intel-gfx] screen update problems with Intel HD 4600 + virtual screen

[Krzysztof Halasa]

Chris Wilson  writes:

> Hmm. Whilst it seems odd to have a negative linear offset, I have seen
> it work elsewhere. Could you try setting
>   options i915 i915_enable_fbc=0 enable_fbc=0
> in /etc/modprobe.conf/intel.conf and rebuilding your initramfs?

This fixed it.
The negative offset isn't exactly gone, though.
Many thanks.

Would you like me to try something else?

[  360.440312] [drm:drm_mode_setcrtc], [CRTC:3]
[  360.440325] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  360.440330] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 1)
[  360.440336] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  360.440342] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  360.440352] [drm:ironlake_update_plane], Writing base 013CA000 
5200 0 1 16384
[  360.440430] [drm:intel_crtc_cursor_set], cursor off
[  360.496349] [drm:drm_mode_setcrtc], [CRTC:3]
[  360.496361] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  360.496367] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 2)
[  360.496372] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  360.496378] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  360.496389] [drm:ironlake_update_plane], Writing base 013CA000 
9200 0 2 16384
[  360.496466] [drm:intel_crtc_cursor_set], cursor off
[  361.016807] [drm:drm_mode_setcrtc], [CRTC:3]
[  361.016819] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  361.016825] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 3)
[  361.016830] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  361.016835] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  361.016845] [drm:ironlake_update_plane], Writing base 013CA000 
D200 0 3 16384
[  361.016922] [drm:intel_crtc_cursor_set], cursor off
[  361.873562] [drm:drm_mode_setcrtc], [CRTC:3]
[  361.873576] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  361.873582] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 4)
[  361.873587] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  361.873592] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  361.873602] [drm:ironlake_update_plane], Writing base 013CA000 1200 0 4 
16384
[  361.873679] [drm:intel_crtc_cursor_set], cursor off
[  362.714307] [drm:drm_mode_setcrtc], [CRTC:3]
[  362.714319] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  362.714325] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 5)
[  362.714331] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  362.714336] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  362.714345] [drm:ironlake_update_plane], Writing base 013CA000 5200 0 5 
16384
[  362.714423] [drm:intel_crtc_cursor_set], cursor off
[  362.730326] [drm:drm_mode_setcrtc], [CRTC:3]
[  362.730338] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  362.730344] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 6)
[  362.730349] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  362.730354] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  362.730366] [drm:ironlake_update_plane], Writing base 013CA000 9200 0 6 
16384
[  362.730443] [drm:intel_crtc_cursor_set], cursor off
[  362.826347] [drm:drm_mode_setcrtc], [CRTC:3]
[  362.826356] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  362.826361] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 7)
[  362.826365] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  362.826369] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  362.826377] [drm:ironlake_update_plane], Writing base 013CA000 D200 0 7 
16384
[  362.826439] [drm:intel_crtc_cursor_set], cursor off
[  362.954525] [drm:drm_mode_setcrtc], [CRTC:3]
[  362.954536] [drm:drm_mode_setcrtc], [CONNECTOR:12:HDMI-A-1]
[  362.954542] [drm:intel_crtc_set_config], [CRTC:3] [FB:55] #connectors=1 (x 
y) (2176 8)
[  362.954548] [drm:intel_set_config_compute_mode_changes], computed changes 
for [CRTC:3], mode_changed=0, fb_changed=1
[  362.954553] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:HDMI-A-1] 
to [CRTC:3]
[  362.954564] [drm:ironlake_update_plane], Writing base 013CA000 
1200 0 0 16384
[  362.954641] [drm:intel_crtc_cursor_set], cursor off
-- 
Krzysztof Halasa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedeskt

Re: [Intel-gfx] screen update problems with Intel HD 4600 + virtual screen

[Krzysztof Halasa]

Chris Wilson  writes:

> I'll leave that to Daniel to try and combine FBC with CRTC viewports...

Let me know if you need more tests, this problems happens on both my
i5 4200M laptop and on a desktop PC with i7 4770k (this machine, now
fixed).
-- 
Krzysztof Halasa
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] Documentation: drm: describing rotation property for i915

[Damien Lespiau]

On Thu, Jun 19, 2014 at 11:41:27AM +0530, sonika.jin...@intel.com wrote:
> From: Sagar Kamble 
> 
> Signed-off-by: Sagar Kamble 
> 
> Cc: Daniel Vetter 
> Cc: "Ville Syrjälä" 
> Cc: linux-...@vger.kernel.org (open list:DOCUMENTATION)
> Cc: linux-ker...@vger.kernel.org (open list)
> ---
>  Documentation/DocBook/drm.tmpl | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7df3134..ce11fd7 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2664,11 +2664,13 @@ void intel_crt_init(struct drm_device *dev)
>   TBD
>   
>   
> - Standard name as in DRM
> - Standard type as in DRM
> - Standard value as in DRM
> - Standard Object as in DRM
> - TBD
> + “rotation”
> + BITMASK
> + { 0, "rotate-0" },
> + { 2, "rotate-180" }

Remove new line?

> + Plane
> + Used to set plane rotation. Only 0 and 180 degree
> + rotation supported as of now
>   
>   
>   SDVO-TV

So, you've spotted that weird line with "Standard * as in DRM". I agree
that it looks out of place. However if you want to make that change, you
need to fix the whole table (this line appears elsewhere as well) and
that's a separate change from adding the documentation for the rotation
propery (ie different patch).

Now can we as well:

  - Put the property under a Plane group
  - Your description doesn't add any information that isn't already in
the previous fields, might as well say nothing there.

Thanks,

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add 180 degree primary plane rotation support

[Damien Lespiau]

On Mon, Jun 23, 2014 at 11:06:00AM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal 
> 
> Primary planes support 180 degree rotation. Expose the feature
> through rotation drm property.
> 
> v2: Calculating linear/tiled offsets based on pipe source width and
> height. Added 180 degree rotation support in ironlake_update_plane.
> 
> v3: Checking if CRTC is active before issueing update_plane. Added
> wait for vblank to make sure we dont overtake page flips. Disabling
> FBC since it does not work with rotated planes.
> 
> v4: Updated rotation checks for pending flips, fbc disable. Creating
> rotation property only for Gen4 onwards. Property resetting as part
> of lastclose.
> 
> v5: Resetting property in i915_driver_lastclose properly for planes
> and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
> width in i9xx_update_plane and ironlake_update_plane. Removed tab
> based indentation and unnecessary braces in intel_crtc_set_property
> and intel_update_fbc. FBC and flip related checks should be done only
> for valid crtcs.
> 
> v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
> and positioning the disable code in intel_update_fbc.
> 
> v7: In case rotation property on inactive crtc is updated, we return
> successfully printing debug log as crtc is inactive and only property change
> is preserved.
> 
> v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
> crtc->primary->fb  and return value of update_primary_plane is ignored.
> 
> v9: added rotation property to primary plane instead of crtc. Removing reset
> of rotation property from lastclose. rotation_property is moved to 
> drm_plane,so
> drm layer will take care of resetting.
> 
> Testcase: igt/kms_rotation_crc
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: dri-de...@lists.freedesktop.org
> Cc: vijay.a.purushotha...@intel.com
> Signed-off-by: Uma Shankar 
> Signed-off-by: Sagar Kamble 
> Reviewed-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_dma.c  |5 --
>  drivers/gpu/drm/i915/i915_reg.h  |1 +
>  drivers/gpu/drm/i915/intel_display.c |   94 
> --
>  drivers/gpu/drm/i915/intel_pm.c  |8 +++
>  4 files changed, 98 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5e583a1..4b6b911 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1938,14 +1938,9 @@ int i915_driver_open(struct drm_device *dev, struct 
> drm_file *file)
>   */
>  void i915_driver_lastclose(struct drm_device *dev)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
>   /* On gen6+ we refuse to init without kms enabled, but then the drm core
>* goes right around and calls lastclose. Check for this and don't clean
>* up anything. */
> - if (!dev_priv)
> - return;
> -

Hum, I don't think this was supposed to be removed?

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add 180 degree primary plane rotation support

[Jindal, Sonika]

On 6/24/2014 3:44 PM, Damien Lespiau wrote:

On Mon, Jun 23, 2014 at 11:06:00AM +0530, sonika.jin...@intel.com wrote:

From: Sonika Jindal 

Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.

v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.

v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.

v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.

v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.

v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.

v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.

v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb  and return value of update_primary_plane is ignored.

v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to drm_plane,so
drm layer will take care of resetting.

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: vijay.a.purushotha...@intel.com
Signed-off-by: Uma Shankar 
Signed-off-by: Sagar Kamble 
Reviewed-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_dma.c  |5 --
  drivers/gpu/drm/i915/i915_reg.h  |1 +
  drivers/gpu/drm/i915/intel_display.c |   94 --
  drivers/gpu/drm/i915/intel_pm.c  |8 +++
  4 files changed, 98 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1..4b6b911 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1938,14 +1938,9 @@ int i915_driver_open(struct drm_device *dev, struct 
drm_file *file)
   */
  void i915_driver_lastclose(struct drm_device *dev)
  {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
/* On gen6+ we refuse to init without kms enabled, but then the drm core
 * goes right around and calls lastclose. Check for this and don't clean
 * up anything. */
-   if (!dev_priv)
-   return;
-


Hum, I don't think this was supposed to be removed?


Yes, my mistake.. I will revert it and resend the patch.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm: Resetting rotation property

[Damien Lespiau]

On Mon, Jun 23, 2014 at 11:06:01AM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal 
> 
> Reset rotation property to 0 wherever applicable
> 
> v2: Also calling set_property of the plane to set the rotation in the plane
> structure. Removed few unused variables.
> 
> Cc: damien.lesp...@intel.com
> Signed-off-by: Sonika Jindal 
> ---
>  drivers/gpu/drm/drm_fb_helper.c  |   14 +-
>  drivers/gpu/drm/i915/intel_display.c |1 -
>  drivers/gpu/drm/i915/intel_sprite.c  |2 --
>  3 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d5d8cea..91e611a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -282,9 +282,21 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
> *fb_helper)
>  
>   drm_warn_on_modeset_not_all_locked(dev);
>  
> - list_for_each_entry(plane, &dev->mode_config.plane_list, head)
> + list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
> +
> + if (plane->rotation_property) {
> + int ret = 0;
> + if (plane->funcs->set_property)
> + ret = plane->funcs->set_property(plane,
> + plane->rotation_property, 
> BIT(DRM_ROTATE_0));
> + if (!ret)
> + drm_object_property_set_value(&plane->base,
> + plane->rotation_property, 
> BIT(DRM_ROTATE_0));
> + }
> +
>   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
>   drm_plane_force_disable(plane);
> + }
>  
>   for (i = 0; i < fb_helper->crtc_count; i++) {
>   struct drm_mode_set *mode_set = 
> &fb_helper->crtc_info[i].mode_set;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 85bd3b8..2006e91 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11405,7 +11405,6 @@ static struct drm_plane 
> *intel_primary_plane_create(struct drm_device *dev,
>  {
>   struct intel_plane *primary;
>   const uint32_t *intel_primary_formats;
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   int num_formats;
>  
>   primary = kzalloc(sizeof(*primary), GFP_KERNEL);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index aa94f67..aa63027 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1206,7 +1206,6 @@ static int intel_plane_set_property(struct drm_plane 
> *plane,
>   struct drm_property *prop,
>   uint64_t val)
>  {
> - struct drm_i915_private *dev_priv = plane->dev->dev_private;
>   struct intel_plane *intel_plane = to_intel_plane(plane);
>   uint64_t old_val;
>   int ret = -ENOENT;
> @@ -1289,7 +1288,6 @@ static uint32_t vlv_plane_formats[] = {
>  int
>  intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_plane *intel_plane;
>   unsigned long possible_crtcs;
>   const uint32_t *plane_formats;

The removal of dev_priv doesn't belong to this patch.

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add 180 degree primary plane rotation support

[Damien Lespiau]

On Mon, Jun 23, 2014 at 11:06:00AM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal 
> 
> Primary planes support 180 degree rotation. Expose the feature
> through rotation drm property.
> 
> v2: Calculating linear/tiled offsets based on pipe source width and
> height. Added 180 degree rotation support in ironlake_update_plane.
> 
> v3: Checking if CRTC is active before issueing update_plane. Added
> wait for vblank to make sure we dont overtake page flips. Disabling
> FBC since it does not work with rotated planes.
> 
> v4: Updated rotation checks for pending flips, fbc disable. Creating
> rotation property only for Gen4 onwards. Property resetting as part
> of lastclose.
> 
> v5: Resetting property in i915_driver_lastclose properly for planes
> and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
> width in i9xx_update_plane and ironlake_update_plane. Removed tab
> based indentation and unnecessary braces in intel_crtc_set_property
> and intel_update_fbc. FBC and flip related checks should be done only
> for valid crtcs.
> 
> v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
> and positioning the disable code in intel_update_fbc.
> 
> v7: In case rotation property on inactive crtc is updated, we return
> successfully printing debug log as crtc is inactive and only property change
> is preserved.
> 
> v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
> crtc->primary->fb  and return value of update_primary_plane is ignored.
> 
> v9: added rotation property to primary plane instead of crtc. Removing reset
> of rotation property from lastclose. rotation_property is moved to 
> drm_plane,so
> drm layer will take care of resetting.
> 
> Testcase: igt/kms_rotation_crc
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: dri-de...@lists.freedesktop.org
> Cc: vijay.a.purushotha...@intel.com
> Signed-off-by: Uma Shankar 
> Signed-off-by: Sagar Kamble 
> Reviewed-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_dma.c  |5 --
>  drivers/gpu/drm/i915/i915_reg.h  |1 +
>  drivers/gpu/drm/i915/intel_display.c |   94 
> --
>  drivers/gpu/drm/i915/intel_pm.c  |8 +++
>  4 files changed, 98 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5e583a1..4b6b911 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1938,14 +1938,9 @@ int i915_driver_open(struct drm_device *dev, struct 
> drm_file *file)
>   */
>  void i915_driver_lastclose(struct drm_device *dev)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
>   /* On gen6+ we refuse to init without kms enabled, but then the drm core
>* goes right around and calls lastclose. Check for this and don't clean
>* up anything. */
> - if (!dev_priv)
> - return;
> -
>   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>   intel_fbdev_restore_mode(dev);
>   vga_switcheroo_process_delayed_switch();
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c70c804..c600d3b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4087,6 +4087,7 @@ enum punit_power_well {
>  #define   DISPPLANE_NO_LINE_DOUBLE   0
>  #define   DISPPLANE_STEREO_POLARITY_FIRST0
>  #define   DISPPLANE_STEREO_POLARITY_SECOND   (1<<18)
> +#define   DISPPLANE_ROTATE_180 (1<<15)
>  #define   DISPPLANE_TRICKLE_FEED_DISABLE (1<<14) /* Ironlake */
>  #define   DISPPLANE_TILED(1<<10)
>  #define _DSPAADDR0x70184
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5e8e711..85bd3b8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc 
> *crtc,
>   unsigned long linear_offset;
>   u32 dspcntr;
>   u32 reg;
> + int pixel_size;
>  
> + pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
>   intel_fb = to_intel_framebuffer(fb);
>   obj = intel_fb->obj;
>  
> @@ -2422,6 +2424,8 @@ static void i9xx_update_primary_plane(struct drm_crtc 
> *crtc,
>   dspcntr = I915_READ(reg);
>   /* Mask out pixel format bits in case we change it */
>   dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
> + dspcntr &= ~DISPPLANE_ROTATE_180;
> +
>   switch (fb->pixel_format) {
>   case DRM_FORMAT_C8:
>   dspcntr |= DISPPLANE_8BPP;
> @@ -2463,8 +2467,6 @@ static void i9xx_update_primary_plane(struct drm_crtc 
> *crtc,
>   if (IS_G4X(dev))
>   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
>  
> - I915_WRITE(reg, dspcntr);
> -
>   linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
>  
>   if (INTEL_INFO(dev)->gen >= 4) {
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add 180 degree primary plane rotation support

[Jindal, Sonika]

On 6/24/2014 3:59 PM, Damien Lespiau wrote:

On Mon, Jun 23, 2014 at 11:06:00AM +0530, sonika.jin...@intel.com wrote:

From: Sonika Jindal 

Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.

v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.

v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.

v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.

v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.

v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.

v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.

v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb  and return value of update_primary_plane is ignored.

v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to drm_plane,so
drm layer will take care of resetting.

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: vijay.a.purushotha...@intel.com
Signed-off-by: Uma Shankar 
Signed-off-by: Sagar Kamble 
Reviewed-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/i915_dma.c  |5 --
  drivers/gpu/drm/i915/i915_reg.h  |1 +
  drivers/gpu/drm/i915/intel_display.c |   94 --
  drivers/gpu/drm/i915/intel_pm.c  |8 +++
  4 files changed, 98 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e583a1..4b6b911 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1938,14 +1938,9 @@ int i915_driver_open(struct drm_device *dev, struct 
drm_file *file)
   */
  void i915_driver_lastclose(struct drm_device *dev)
  {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
/* On gen6+ we refuse to init without kms enabled, but then the drm core
 * goes right around and calls lastclose. Check for this and don't clean
 * up anything. */
-   if (!dev_priv)
-   return;
-
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_fbdev_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c804..c600d3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4087,6 +4087,7 @@ enum punit_power_well {
  #define   DISPPLANE_NO_LINE_DOUBLE0
  #define   DISPPLANE_STEREO_POLARITY_FIRST 0
  #define   DISPPLANE_STEREO_POLARITY_SECOND(1<<18)
+#define   DISPPLANE_ROTATE_180 (1<<15)
  #define   DISPPLANE_TRICKLE_FEED_DISABLE  (1<<14) /* Ironlake */
  #define   DISPPLANE_TILED (1<<10)
  #define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..85bd3b8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+   int pixel_size;

+   pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;

@@ -2422,6 +2424,8 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
dspcntr = I915_READ(reg);
/* Mask out pixel format bits in case we change it */
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
+   dspcntr &= ~DISPPLANE_ROTATE_180;
+
switch (fb->pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2463,8 +2467,6 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;

-   I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);

if (INTEL_INFO(dev)->gen >= 4) {
@@ -2477,6 +2479,17 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
intel_crtc->dspaddr_offset =

[Intel-gfx] [PATCH] drm/i915: Wait for vblank after enabling the primary plane on BDW

[ville . syrjala]

From: Ville Syrjälä 

BDW signals the flip done interrupt immediately after the DSPSURF write
when the plane is disabled. This is true even if we've already armed
DSPCNTR to enable the plane at the next vblank. This causes major
problems for our page flip code which relies on the flip done interrupts
happening at vblank time.

So what happens is that we enable the plane, and immediately allow
userspace to submit a page flip. If the plane is still in the process
of being enabled when the page flip is issued, the flip done gets
signalled immediately. Our DSPSURFLIVE check catches this to prevent
premature flip completion, but it also means that we don't get a flip
done interrupt when the plane actually gets enabled, and so the page
flip is never completed.

Work around this by re-introducing blocking vblank waits on BDW
whenever we enable the primary plane.

I removed some of the vblank waits here:
 commit 6304cd91e7f05f8802ea6f91287cac09741d9c46
 Author: Ville Syrjälä 
 Date:   Fri Apr 25 13:30:12 2014 +0300

drm/i915: Drop the excessive vblank waits from modeset codepaths

To avoid these blocking vblank waits we should start using the vblank
interrupt instead of the flip done interrupt to complete page flips.
But that's material for another patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79354
Tested-by: Guo Jinxian 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 9 +
 drivers/gpu/drm/i915/intel_sprite.c  | 8 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9188fed..f92efc6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2087,6 +2087,7 @@ void intel_flush_primary_plane(struct drm_i915_private 
*dev_priv,
 static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
  enum plane plane, enum pipe pipe)
 {
+   struct drm_device *dev = dev_priv->dev;
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
int reg;
@@ -2106,6 +2107,14 @@ static void intel_enable_primary_hw_plane(struct 
drm_i915_private *dev_priv,
 
I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE);
intel_flush_primary_plane(dev_priv, plane);
+
+   /*
+* BDW signals flip done immediately if the plane
+* is disabled, even if the plane enable is already
+* armed to occur at the next vblank :(
+*/
+   if (IS_BROADWELL(dev))
+   intel_wait_for_vblank(dev, intel_crtc->pipe);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 1b66ddc..9a17b4e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -691,6 +691,14 @@ intel_post_enable_primary(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
/*
+* BDW signals flip done immediately if the plane
+* is disabled, even if the plane enable is already
+* armed to occur at the next vblank :(
+*/
+   if (IS_BROADWELL(dev))
+   intel_wait_for_vblank(dev, intel_crtc->pipe);
+
+   /*
 * FIXME IPS should be fine as long as one plane is
 * enabled, but in practice it seems to have problems
 * when going from primary only to sprite only and vice
-- 
1.8.5.5

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

Re: [Intel-gfx] Linux 3.16-rc2

[Jani Nikula]

On Tue, 24 Jun 2014, Thomas Meyer  wrote:
> the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> X server.

This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
[1]. Also related [2].

Chris, any fresh ideas?

Thomas, please consider filing a bug against DRM/Intel at [3]. They will
have a better chance of not being forgotten as the mail thread goes
cold.

Thanks,
Jani.


[1] http://thread.gmane.org/gmane.linux.kernel/1700872
[2] https://bugs.freedesktop.org/show_bug.cgi?id=76554
[3] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI


>
> First bad commit is:
>
> # first bad commit: [78f2975eec9faff353a6194e854d3d39907bab68] drm/i915: Move 
> all ring resets before setting the HWS page
>
> commit 78f2975eec9faff353a6194e854d3d39907bab68
> Author: Chris Wilson 
> Date:   Wed Apr 2 16:36:07 2014 +0100
>
> drm/i915: Move all ring resets before setting the HWS page
> 
> In commit a51435a3137ad8ae75c288c39bd2d8b2696bae8f
> Author: Naresh Kumar Kachhi 
> Date:   Wed Mar 12 16:39:40 2014 +0530
> 
> drm/i915: disable rings before HW status page setup
> 
> we reordered stopping the rings to do so before we set the HWS register.
> However, there is an extra workaround for g45 to reset the rings twice,
> and for consistency we should apply that workaround before setting the
> HWS to be sure that the rings are truly stopped.
> 
> Reference: http://lkml.kernel.org/r/20140423202248.ga3...@amd.pavel.ucw.cz
> Tested-by: Pavel Machek 
> Cc: Naresh Kumar Kachhi 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Jesse Barnes 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Jani Nikula 
>
> Above commit is not revertable anymore on 3.16-rc2 without conflict.
>
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] linux-next: Tree for Jun 19 (drm/i915)

[Jani Nikula]

On Thu, 19 Jun 2014, Randy Dunlap  wrote:
> On 06/18/14 23:16, Stephen Rothwell wrote:
>> Hi all,
>> 
>> The powerpc allyesconfig is again broken more than usual.
>> 
>> Changes since 20140618:
>> 
>
> on i386:
>
> CONFIG_ACPI is not enabled.
>
>   CC  drivers/gpu/drm/i915/i915_drv.o
> ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':
> ../drivers/gpu/drm/i915/i915_drv.c:547:2: error: implicit declaration of 
> function 'acpi_target_system_state' [-Werror=implicit-function-declaration]
> ../drivers/gpu/drm/i915/i915_drv.c:547:36: error: 'ACPI_STATE_S3' undeclared 
> (first use in this function)
> ../drivers/gpu/drm/i915/i915_drv.c:547:36: note: each undeclared identifier 
> is reported only once for each function it appears in
>   CC  net/dccp/qpolicy.o
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1

Thanks for the report, we'll fix it.

Can anyone explain why include/linux/acpi_bus.h has #ifdef
CONFIG_ACPI_SLEEP and conditional build for a dummy inline version of
acpi_target_system_state(), *but* that does not get included or used if
CONFIG_ACPI=n? Additionally, the combination of CONFIG_ACPI=y and
CONFIG_ACPI_SLEEP=n does not seem to work at all.

So we'll really have to sprinkle #ifdef CONFIG_ACPI all over, instead of
neatly using the dummy versions that someone has gone through the
trouble of adding?

BR,
Jani.


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

Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring submission mechanism

[Mateo Lozano, Oscar]

Ok, let´s try to extract something positive out of all this.

OPTION A (Ben´s proposal):

> I think the only solution for what Chris is asking for is to implement this 
> as 1
> context per engine, as opposed to 1 context with a context object per
> engine. As you correctly stated, I think we all agreed the latter was fine 
> when
> we met. Functionally, I see no difference, but it does allow you to always use
> a context as the sole mechanism for making any decisions and performing
> any operations. Now without writing all the code, I can't promise it actually
> will look better, but I think it's likely going to be a lot cleaner. Before 
> you do
> any changes though...

We agreed on this early on (v1), yes, but then the idea was frowned upon by 
Brad and then by Daniel. I cannot recall exactly why anymore, but one big 
reason was that the idr mechanism makes it difficult to track several contexts 
with the same id (and userspace only has one context handle) and something 
about ctx->hang_stats. From v2 on, we agreed to multiplex different engines 
inside one intel_context (and that´s why we renamed i915_hw_context to 
intel_context).

OPTION B (Brad´s proposal):

> So I suggested that we:
> 
> - Add a back pointer from struct intel_rinbuffer to intel_context (would only
>   be valid for lrc mode)
> - Move the intel_ringbuffer_get(engine, context) calls up to the callers
> - Pass (engine, ringbuf) instead of (engine, context) to intel_ring_* 
> functions
> - Have the vfunc implemenations get the context from the ringbuffer where
>   needed and ignore it where not
> 
> Looking again, we could probably add a back pointer to the intel_engine_cs
> as well and then just pass around the ringbuf.

Sounds fine by me: intel_ringbuffer is only related to exactly one 
intel_engine_cs and one intel_context, so having pointers to those two makes 
sense.
As before, this could be easily done within the existing code (passing 
intel_rinbgbuffer instead of intel_engine_cs), but Daniel wants a code split, 
so I can only do it for the logical ring functions.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Linux 3.16-rc2

[Chris Wilson]

On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> On Tue, 24 Jun 2014, Thomas Meyer  wrote:
> > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > X server.
> 
> This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> [1]. Also related [2].
> 
> Chris, any fresh ideas?

Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
everything we know and have tried is there. Which is not much more than
at time of the original incarnation:

commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
Author: Keith Packard 
Date:   Tue Oct 14 17:20:35 2008 -0700

i915: Fix up ring initialization to cover G45 oddities

G45 appears quite sensitive to ring initialization register writes,
sometimes leaving the HEAD register with the START register contents. Check
to make sure HEAD is reset correctly when START is written, and fix it up,
screaming loudly.
-Chris

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

[Intel-gfx] [PATCH 0/3] Moving rotation_property to drm_plane

[sonika . jindal]

From: Sonika Jindal 

As suggested by Daniel and Damien, moved rotation_property to drm_plane.
Also moved resetting of rotation_property to restore_fbdev_mode which will be
used in switching VT use case along with the driver lastclose path.

v2: Removing unused dev_priv from second patch instead of third (some mixup
due to earlier reformatting).

Sonika Jindal (2):
  drm/i915: Add 180 degree primary plane rotation support
  drm: Resetting rotation property

Ville Syrjälä (1):
  drm/i915: Add rotation property for sprites

 drivers/gpu/drm/drm_fb_helper.c  |   14 -
 drivers/gpu/drm/i915/i915_dma.c  |5 --
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   93 --
 drivers/gpu/drm/i915/intel_pm.c  |8 +++
 drivers/gpu/drm/i915/intel_sprite.c  |   40 ++-
 include/drm/drm_crtc.h   |1 +
 7 files changed, 150 insertions(+), 12 deletions(-)

-- 
1.7.10.4

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

[Intel-gfx] [PATCH 1/3] drm/i915: Add rotation property for sprites

[sonika . jindal]

From: Ville Syrjälä 

Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.

v2: Moving rotation_property to drm_plane

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
Signed-off-by: Sonika Jindal 
Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_sprite.c |   40 ++-
 include/drm/drm_crtc.h  |1 +
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index cbad738..aa63027 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,6 +1202,29 @@ out_unlock:
return ret;
 }
 
+static int intel_plane_set_property(struct drm_plane *plane,
+   struct drm_property *prop,
+   uint64_t val)
+{
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   uint64_t old_val;
+   int ret = -ENOENT;
+
+   if (prop == plane->rotation_property) {
+   /* exactly one rotation angle please */
+   if (hweight32(val & 0xf) != 1)
+   return -EINVAL;
+
+   old_val = intel_plane->rotation;
+   intel_plane->rotation = val;
+   ret = intel_plane_restore(plane);
+   if (ret)
+   intel_plane->rotation = old_val;
+   }
+
+   return ret;
+}
+
 int intel_plane_restore(struct drm_plane *plane)
 {
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -1228,6 +1251,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = intel_update_plane,
.disable_plane = intel_disable_plane,
.destroy = intel_destroy_plane,
+   .set_property = intel_plane_set_property,
 };
 
 static uint32_t ilk_plane_formats[] = {
@@ -1338,8 +1362,22 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, 
int plane)
 &intel_plane_funcs,
 plane_formats, num_plane_formats,
 false);
-   if (ret)
+   if (ret) {
kfree(intel_plane);
+   goto out;
+   }
+
+   if (!intel_plane->base.rotation_property)
+   intel_plane->base.rotation_property =
+   drm_mode_create_rotation_property(dev,
+ BIT(DRM_ROTATE_0) |
+ BIT(DRM_ROTATE_180));
+
+   if (intel_plane->base.rotation_property)
+   drm_object_attach_property(&intel_plane->base.base,
+  intel_plane->base.rotation_property,
+  intel_plane->rotation);
 
+ out:
return ret;
 }
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 08ed55e..6006c70 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -615,6 +615,7 @@ struct drm_plane {
 
const struct drm_plane_funcs *funcs;
 
+   struct drm_property *rotation_property;
struct drm_object_properties properties;
 
enum drm_plane_type type;
-- 
1.7.10.4

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

[Intel-gfx] [PATCH 2/3] drm/i915: Add 180 degree primary plane rotation support

[sonika . jindal]

From: Sonika Jindal 

Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.

v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.

v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.

v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.

v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.

v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.

v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.

v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb  and return value of update_primary_plane is ignored.

v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to drm_plane,so
drm layer will take care of resetting.

Testcase: igt/kms_rotation_crc

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: vijay.a.purushotha...@intel.com
Signed-off-by: Uma Shankar 
Signed-off-by: Sagar Kamble 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   94 --
 drivers/gpu/drm/i915/intel_pm.c  |7 +++
 3 files changed, 97 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c804..c600d3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4087,6 +4087,7 @@ enum punit_power_well {
 #define   DISPPLANE_NO_LINE_DOUBLE 0
 #define   DISPPLANE_STEREO_POLARITY_FIRST  0
 #define   DISPPLANE_STEREO_POLARITY_SECOND (1<<18)
+#define   DISPPLANE_ROTATE_180 (1<<15)
 #define   DISPPLANE_TRICKLE_FEED_DISABLE   (1<<14) /* Ironlake */
 #define   DISPPLANE_TILED  (1<<10)
 #define _DSPAADDR  0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..6d87e3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+   int pixel_size;
 
+   pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
 
@@ -2422,6 +2424,8 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
dspcntr = I915_READ(reg);
/* Mask out pixel format bits in case we change it */
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
+   dspcntr &= ~DISPPLANE_ROTATE_180;
+
switch (fb->pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2463,8 +2467,6 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
 
-   I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
 
if (INTEL_INFO(dev)->gen >= 4) {
@@ -2477,6 +2479,18 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
intel_crtc->dspaddr_offset = linear_offset;
}
 
+   if (to_intel_plane(crtc->primary)->rotation == BIT(DRM_ROTATE_180)) {
+   dspcntr |= DISPPLANE_ROTATE_180;
+
+   x += (intel_crtc->config.pipe_src_w - 1);
+   y += (intel_crtc->config.pipe_src_h - 1);
+   linear_offset += (intel_crtc->config.pipe_src_h - 1) *
+   fb->pitches[0] +
+   (intel_crtc->config.pipe_src_w - 1) * pixel_size;
+   }
+
+   I915_WRITE(reg, dspcntr);
+
DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
  i915_gem_obj_ggtt_offset(obj), linear_offset, x, y,
  fb->pitches[0]);
@@ -2487,7 +2501,8 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
I915_WRITE(DSPLINOFF(plane), linear_offset);
} else
-   I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) +

[Intel-gfx] [PATCH 3/3] drm: Resetting rotation property

[sonika . jindal]

From: Sonika Jindal 

Reset rotation property to 0 wherever applicable

v2: Also calling set_property of the plane to set the rotation in the plane
structure.

Cc: damien.lesp...@intel.com
Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/drm_fb_helper.c |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d5d8cea..30806b4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -282,9 +282,23 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
 
drm_warn_on_modeset_not_all_locked(dev);
 
-   list_for_each_entry(plane, &dev->mode_config.plane_list, head)
+   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+
+   if (plane->rotation_property) {
+   int ret = 0;
+   if (plane->funcs->set_property)
+   ret = plane->funcs->set_property(plane,
+   plane->rotation_property,
+   BIT(DRM_ROTATE_0));
+   if (!ret)
+   drm_object_property_set_value(&plane->base,
+   plane->rotation_property,
+   BIT(DRM_ROTATE_0));
+   }
+
if (plane->type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
+   }
 
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set = 
&fb_helper->crtc_info[i].mode_set;
-- 
1.7.10.4

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

Re: [Intel-gfx] Linux 3.16-rc2

[Thomas Meyer]

Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > On Tue, 24 Jun 2014, Thomas Meyer  wrote:
> > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > X server.
> > 
> > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > [1]. Also related [2].
> > 
> > Chris, any fresh ideas?
> 
> Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> everything we know and have tried is there. Which is not much more than
> at time of the original incarnation:
> 
> commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> Author: Keith Packard 
> Date:   Tue Oct 14 17:20:35 2008 -0700
> 
> i915: Fix up ring initialization to cover G45 oddities
> 
> G45 appears quite sensitive to ring initialization register writes,
> sometimes leaving the HEAD register with the START register contents. 
> Check
> to make sure HEAD is reset correctly when START is written, and fix it up,
> screaming loudly.
> -Chris
> 

Hi,

so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
Move all ring resets before setting the HWS page) ?

Without this commit 3.15 is super stable for me. This seems to be also
true for others according to above bug report.

thomas

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

Re: [Intel-gfx] Linux 3.16-rc2

[Chris Wilson]

On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> Am Dienstag, den 24.06.2014, 12:57 +0100 schrieb Chris Wilson:
> > On Tue, Jun 24, 2014 at 02:06:24PM +0300, Jani Nikula wrote:
> > > On Tue, 24 Jun 2014, Thomas Meyer  wrote:
> > > > the i915 driver is still broken in 3.16-rc2. Resume from ram crashes the
> > > > X server.
> > > 
> > > This is not new to 3.16-rc2; apparently we've had it since v3.15-rc4
> > > [1]. Also related [2].
> > > 
> > > Chris, any fresh ideas?
> > 
> > Nope. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554
> > everything we know and have tried is there. Which is not much more than
> > at time of the original incarnation:
> > 
> > commit 50aa253d820ad4577e2231202f2c8fd89f9dc4e6
> > Author: Keith Packard 
> > Date:   Tue Oct 14 17:20:35 2008 -0700
> > 
> > i915: Fix up ring initialization to cover G45 oddities
> > 
> > G45 appears quite sensitive to ring initialization register writes,
> > sometimes leaving the HEAD register with the START register contents. 
> > Check
> > to make sure HEAD is reset correctly when START is written, and fix it 
> > up,
> > screaming loudly.
> > -Chris
> > 
> 
> Hi,
> 
> so why not revert 78f2975eec9faff353a6194e854d3d39907bab68 (drm/i915:
> Move all ring resets before setting the HWS page) ?

Because that patch was in response to a boot time regression.
-Chris

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

Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring submission mechanism

[Mateo Lozano, Oscar]

> -Original Message-
> From: Volkin, Bradley D
> Sent: Monday, June 23, 2014 8:10 PM
> To: Mateo Lozano, Oscar
> Cc: Chris Wilson; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring
> submission mechanism
> 
> On Mon, Jun 23, 2014 at 07:35:38AM -0700, Mateo Lozano, Oscar wrote:
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Monday, June 23, 2014 2:42 PM
> > > To: Mateo Lozano, Oscar
> > > Cc: Volkin, Bradley D; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical
> > > ring submission mechanism
> > >
> > > On Mon, Jun 23, 2014 at 01:36:07PM +, Mateo Lozano, Oscar
> wrote:
> > > > > -Original Message-
> > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > Sent: Monday, June 23, 2014 2:27 PM
> > > > > To: Mateo Lozano, Oscar
> > > > > Cc: Volkin, Bradley D; intel-gfx@lists.freedesktop.org
> > > > > Subject: Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical
> > > > > ring submission mechanism
> > > > >
> > > > > On Mon, Jun 23, 2014 at 01:18:35PM +, Mateo Lozano, Oscar
> > > wrote:
> > > > > > > -Original Message-
> > > > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > > > Sent: Monday, June 23, 2014 2:14 PM
> > > > > > > To: Mateo Lozano, Oscar
> > > > > > > Cc: Volkin, Bradley D; intel-gfx@lists.freedesktop.org
> > > > > > > Subject: Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New
> > > > > > > logical ring submission mechanism
> > > > > > >
> > > > > > > On Mon, Jun 23, 2014 at 01:09:37PM +, Mateo Lozano,
> > > > > > > Oscar
> > > > > wrote:
> > > > > > > > So far, yes, but that´s only because I artificially made
> > > > > > > > intel_lrc.c self-
> > > > > > > contained, as Daniel requested. What if we need to execute
> > > > > > > commands from somewhere else, like in intel_gen7_queue_flip()?
> > > > > > > >
> > > > > > > > And this takes me to another discussion: this logical ring
> > > > > > > > vs legacy ring split
> > > > > > > is probably a good idea (time will tell), but we should
> > > > > > > provide a way of sending commands for execution without
> > > > > > > knowing if Execlists are enabled or not. In the early series
> > > > > > > that was easy because we reused the ring_begin, ring_emit &
> > > > > > > ring_advance functions, but this is not the case anymore.
> > > > > > > And without this, sooner or later somebody will break legacy
> > > > > > > or execlists (this already happened last week, when somebody
> > > > > > > here was implementing native sync without knowing
> > > > > about Execlists).
> > > > > > > >
> > > > > > > > So, the questions is: how do you feel about a dev_priv.gt
> > > > > > > > vfunc that takes a
> > > > > > > context, a ring, an array of DWORDS and a BB length and does
> > > > > > > the intel_(logical)_ring_begin/emit/advance based on
> > > i915.enable_execlists?
> 
> There are 3 cases of non-execbuffer submissions that I can think of: flips,
> render state, and clear-buffer (proposed patches on the list). I wonder if the
> right approach might be to use batchbuffers with a small wrapper around the
> dispatch_execbuffer/emit_bb_start vfuncs. Basically the rule would be to
> only touch a ringbuffer from within the intel_engine_cs vfuncs, which always
> know which set of functions to use.
> 
> For flips, we could use MMIO flips. Render state already uses the existing
> dispatch_execbuffer() and add_request(). The clear code could potentially do
> the same. There would obviously be some overhead in using a batch buffer
> for what could end up being just a few commands. Perhaps the batch buffer
> pool code from the command parser would help though.

This has another positive side-effect: the scheduler guys do not like things 
inside the ring without a proper batchbuffer & request, because it makes their 
life more complex.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check for a stalled page flip after each vblank

[Jani Nikula]

Chris, I'm lost with the state of this series. Patchwork and a mail from
Daniel claim that some of the patches were merged, but they are nowhere
to be found. Did Daniel first push and then change his mind?

BR,
Jani.


On Wed, 11 Jun 2014, Chris Wilson  wrote:
> Long ago, back in the racy haydays of 915gm interrupt handling, page
> flips would occasionally go astray and leave the hardware stuck, and the
> display not updating. This annoyed people who relied on their systems
> being able to display continuously updating information 24/7, and so
> some code to detect when the driver missed the page flip completion
> signal was added. Until recently, it was presumed that the interrupt
> handling was now flawless, but once again Simon Farnsworth has found a
> system whose display will stall. Reinstate the pageflip stall detection,
> which works by checking to see if the hardware has been updated to the
> new framebuffer address following each vblank. If the hardware is
> scanning out from the new framebuffer, but we still think the flip is
> pending, then we kick our driver into submision.
>
> This is a continuation of the effort started with
> commit 4e5359cd053bfb7d8dabe4a63624a5726848ffbc
> Author: Simon Farnsworth 
> Date:   Wed Sep 1 17:47:52 2010 +0100
>
> drm/i915: Avoid pageflipping freeze when we miss the flip prepare 
> interrupt
>
> This now includes a belt-and-braces approach to make sure the driver
> (or the hardware) doesn't miss an interrupt and cause us to stop
> updating the display should the unthinkable happen and the pageflip fail - 
> i.e.
> that the user is able to continue submitting flips.
>
> v2: Cleanup, refactor, and rename
> v3: Only start counting vblanks after the flip command has been seen by
> the hardware.
> v4: Record the seqno after we touch the ring, or else there may be no
> seqno allocated yet.
>
> Reported-by: Simon Farnsworth 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Reviewed-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  29 +---
>  drivers/gpu/drm/i915/i915_irq.c  |  85 +++-
>  drivers/gpu/drm/i915/intel_display.c | 124 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |   5 ++
>  4 files changed, 150 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e8ea1efd3810..eae1a184 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -581,6 +581,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>  {
>   struct drm_info_node *node = m->private;
>   struct drm_device *dev = node->minor->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   unsigned long flags;
>   struct intel_crtc *crtc;
>  
> @@ -595,6 +596,8 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   seq_printf(m, "No flip due on pipe %c (plane %c)\n",
>  pipe, plane);
>   } else {
> + u32 addr;
> +
>   if (atomic_read(&work->pending) < INTEL_FLIP_COMPLETE) {
>   seq_printf(m, "Flip queued on pipe %c (plane 
> %c)\n",
>  pipe, plane);
> @@ -602,23 +605,29 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Flip pending (waiting for vsync) 
> on pipe %c (plane %c)\n",
>  pipe, plane);
>   }
> + seq_printf(m, "Flip queued on %s at seqno %u, now %u\n",
> +work->ring->name,
> +work->flip_queued_seqno,
> +work->ring->get_seqno(work->ring, true));
> + seq_printf(m, "Flip queued on frame %d, (was ready on 
> frame %d), now %d\n",
> +work->flip_queued_vblank,
> +work->flip_ready_vblank,
> +drm_vblank_count(dev, crtc->pipe));
>   if (work->enable_stall_check)
>   seq_puts(m, "Stall check enabled, ");
>   else
>   seq_puts(m, "Stall check waiting for page flip 
> ioctl, ");
>   seq_printf(m, "%d prepares\n", 
> atomic_read(&work->pending));
>  
> - if (work->old_fb_obj) {
> - struct drm_i915_gem_object *obj = 
> work->old_fb_obj;
> - if (obj)
> - seq_printf(m, "Old framebuffer 
> gtt_offset 0x%08lx\n",
> -
> i915_gem_obj_ggtt_offset(obj));
> 

Re: [Intel-gfx] [PATCH] drm/i915: Check for a stalled page flip after each vblank

[Chris Wilson]

On Tue, Jun 24, 2014 at 03:44:19PM +0300, Jani Nikula wrote:
> 
> Chris, I'm lost with the state of this series. Patchwork and a mail from
> Daniel claim that some of the patches were merged, but they are nowhere
> to be found. Did Daniel first push and then change his mind?

There was a conflict with the mmio flips that he merged, so he dropped them.
Updated patches are on mailing list waiting for an r-b.
-Chris

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

[Intel-gfx] [PATCH] drm/i915: vlv_prepare_pll is only needed in case of non DSI interfaces

[Shobhit Kumar]

For MIPI, DSI PLL is configured separately in vlv_configure_dsi_pll
during the DSI enable sequence

Causing WARN dump otherwise in dpio_reads

Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fa77557..2fa7152 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4629,7 +4629,10 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
if (intel_crtc->active)
return;
 
-   vlv_prepare_pll(intel_crtc);
+   is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
+
+   if (!is_dsi)
+   vlv_prepare_pll(intel_crtc);
 
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -4663,8 +4666,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
if (encoder->pre_pll_enable)
encoder->pre_pll_enable(encoder);
 
-   is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
-
if (!is_dsi) {
if (IS_CHERRYVIEW(dev))
chv_enable_pll(intel_crtc);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Hold the table lock whilst walking the file's idr and counting the objects in debugfs

[Jani Nikula]

On Tue, 17 Jun 2014, Daniel Vetter  wrote:
> On Tue, Jun 17, 2014 at 09:56:24AM +0100, Chris Wilson wrote:
>> Fixes an issue whereby we may race with the table updates (before the
>> core takes the struct_mutex) and so risk dereferencing a stale pointer in
>> the iterator for /debugfs/.../i915_gem_objects. For example,
>> 
>> [ 1524.757545] BUG: unable to handle kernel paging request at f53af748
>> [ 1524.757572] IP: [] per_file_stats+0x12/0x100
>> [ 1524.757599] *pdpt = 01b13001 *pde = 379fb067 *pte = 
>> 8000353af060
>> [ 1524.757621] Oops:  [#1] SMP DEBUG_PAGEALLOC
>> [ 1524.757637] Modules linked in: ctr ccm arc4 ath9k ath9k_common ath9k_hw 
>> ath snd_hda_codec_conexant mac80211 snd_hda_codec_generic snd_hda_intel 
>> snd_hda_controller snd_hda_codec bnep snd_hwdep rfcomm snd_pcm gpio_ich 
>> dell_wmi sparse_keymap snd_seq_midi hid_multitouch uvcvideo 
>> snd_seq_midi_event dell_laptop snd_rawmidi dcdbas snd_seq videobuf2_vmalloc 
>> videobuf2_memops videobuf2_core usbhid videodev snd_seq_device coretemp 
>> snd_timer hid joydev kvm_intel cfg80211 ath3k kvm btusb bluetooth serio_raw 
>> snd microcode soundcore lpc_ich wmi mac_hid parport_pc ppdev lp parport 
>> psmouse ahci libahci
>> [ 1524.757825] CPU: 3 PID: 1911 Comm: intel-gpu-overl Tainted: GW  
>> OE 3.15.0-rc3+ #96
>> [ 1524.757840] Hardware name: Dell Inc. Inspiron 1090/Inspiron 1090, BIOS 
>> A06 08/23/2011
>> [ 1524.757855] task: f52f36c0 ti: f4cbc000 task.ti: f4cbc000
>> [ 1524.757869] EIP: 0060:[] EFLAGS: 00210202 CPU: 3
>> [ 1524.757884] EIP is at per_file_stats+0x12/0x100
>> [ 1524.757896] EAX: 002d EBX:  ECX: f4cbdefc EDX: f53af700
>> [ 1524.757909] ESI: c1406970 EDI: f53af700 EBP: f4cbde6c ESP: f4cbde5c
>> [ 1524.757922]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> [ 1524.757934] CR0: 80050033 CR2: f53af748 CR3: 356af000 CR4: 07f0
>> [ 1524.757945] Stack:
>> [ 1524.757957]  f4cbdefc  c1406970 f53af700 f4cbdea8 c12e5f15 
>> f4cbdefc c1406970
>> [ 1524.757993]   f4cbde90 002d f5dc5cd0 e4e80438 c1181d59 
>> f4cbded8 f4d89900
>> [ 1524.758027]  f5631b40 e5131074 c1903f37 f4cbdf28 c14068e6 f52648a0 
>> c1927748 c1903f37
>> [ 1524.758062] Call Trace:
>> [ 1524.758084]  [] ? i915_gem_object_info+0x510/0x510
>> [ 1524.758106]  [] idr_for_each+0xa5/0x100
>> [ 1524.758126]  [] ? i915_gem_object_info+0x510/0x510
>> [ 1524.758148]  [] ? seq_vprintf+0x29/0x50
>> [ 1524.758168]  [] i915_gem_object_info+0x486/0x510
>> [ 1524.758189]  [] seq_read+0xd6/0x380
>> [ 1524.758208]  [] ? final_putname+0x1d/0x40
>> [ 1524.758227]  [] ? seq_hlist_next_percpu+0x90/0x90
>> [ 1524.758246]  [] vfs_read+0x82/0x150
>> [ 1524.758265]  [] SyS_read+0x46/0x90
>> [ 1524.758285]  [] sysenter_do_call+0x12/0x22
>> [ 1524.758298] Code: f5 8f 2a 00 83 c4 6c 31 c0 5b 5e 5f 5d c3 8d 74 26 00 
>> 8d bc 27 00 00 00 00 55 89 e5 57 56 53 83 ec 04 3e 8d 74 26 00 83 41 04 01 
>> <8b> 42 48 01 41 08 8b 42 4c 89 d7 85 c0 75 07 8b 42 60 85 c0 74
>> [ 1524.758461] EIP: [] per_file_stats+0x12/0x100 SS:ESP 
>> 0068:f4cbde5c
>> [ 1524.758485] CR2: f53af748
>> 
>> Reported-by: Sam Jansen 
>> Signed-off-by: Chris Wilson 
>> Cc: Sam Jansen 
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Daniel Vetter 

Pushed to -fixes, thanks for the patch and review.

BR,
Jani.


>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index a8b81407338a..d2610a5f4efe 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -446,7 +446,9 @@ static int i915_gem_object_info(struct seq_file *m, 
>> void* data)
>>  
>>  memset(&stats, 0, sizeof(stats));
>>  stats.file_priv = file->driver_priv;
>> +spin_lock(&file->table_lock);
>>  idr_for_each(&file->object_idr, per_file_stats, &stats);
>> +spin_unlock(&file->table_lock);
>>  /*
>>   * Although we have a valid reference on file->pid, that does
>>   * not guarantee that the task_struct who called get_pid() is
>> -- 
>> 2.0.0
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: BDW: Adding Reserved PCI IDs.

[Jani Nikula]

On Fri, 13 Jun 2014, Rodrigo Vivi  wrote:
> Hi Daniel,
>
> please consider to merge the first version. So we can move fwd with ddx
> patche followed by proper marketing names.

Pushed v1 to -fixes, thanks for the patch and review.

BR,
Jani.



>
> Thanks,
> Rodrigo.
>
>
> On Wed, Jun 11, 2014 at 10:47 AM, Ben Widawsky  wrote:
>
>> On Tue, Jun 10, 2014 at 10:41:07AM -0700, Rodrigo Vivi wrote:
>> > These PCI IDs are reserved on BSpec and can be used at any time in the
>> future.
>> > So let's add this now in order to avoid issues that we already faced on
>> previous
>> > platforms, like finding out about new ids when user reported
>> accelaration weren't
>> > enabled.
>> >
>> > v2: Reserved IDs doesn't have GT defined. So, creating a separated list.
>> (Ben)
>> >
>> > Cc: Ben Widawsky 
>> > Signed-off-by: Rodrigo Vivi 
>> > ---
>> >  include/drm/i915_pciids.h | 16 ++--
>> >  1 file changed, 14 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
>> > index 0572035..0968478 100644
>> > --- a/include/drm/i915_pciids.h
>> > +++ b/include/drm/i915_pciids.h
>> > @@ -237,13 +237,25 @@
>> >  #define INTEL_BDW_GT3D_IDS(info) \
>> >   _INTEL_BDW_D_IDS(3, info)
>> >
>> > +#define INTEL_BDW_RSVDM_IDS(info) \
>> > + INTEL_VGA_DEVICE(0x1632, info), \
>> > + INTEL_VGA_DEVICE(0x1636, info), \
>> > + INTEL_VGA_DEVICE(0x163B, info), \
>> > + INTEL_VGA_DEVICE(0x163A, info)
>> > +
>> > +#define INTEL_BDW_RSVDD_IDS(info) \
>> > + INTEL_VGA_DEVICE(0x163D, info), \
>> > + INTEL_VGA_DEVICE(0x163E, info)
>> > +
>> >  #define INTEL_BDW_M_IDS(info) \
>> >   INTEL_BDW_GT12M_IDS(info), \
>> > - INTEL_BDW_GT3M_IDS(info)
>> > + INTEL_BDW_GT3M_IDS(info), \
>> > + INTEL_BDW_RSVDM_IDS(info)
>> >
>> >  #define INTEL_BDW_D_IDS(info) \
>> >   INTEL_BDW_GT12D_IDS(info), \
>> > - INTEL_BDW_GT3D_IDS(info)
>> > + INTEL_BDW_GT3D_IDS(info), \
>> > + INTEL_BDW_RSVDD_IDS(info)
>> >
>> >  #define INTEL_CHV_IDS(info) \
>> >   INTEL_VGA_DEVICE(0x22b0, info), \
>>
>> I thought we saved off the GT info, but now that I actually look at the
>> code, we do not. Therefore, I actually think v1 is a better patch.
>>
>> In either case, both v1 and v2 are:
>> Reviewed-by: Ben Widawsky 
>>
>> I apologize for the extra work.
>>
>> --
>> Ben Widawsky, Intel Open Source Technology Center
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>
>
>
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Only mark the ctx as initialised after a SET_CONTEXT operation

[Jani Nikula]

On Mon, 23 Jun 2014, Ben Widawsky  wrote:
> On Mon, Jun 23, 2014 at 12:55:47PM +0300, Jani Nikula wrote:
>> On Fri, 30 May 2014, Chris Wilson  wrote:
>> > Fallout from
>> >
>> > commit 46470fc932ac8a0e8317a220b3f4ea4ed903338e
>> > Author: Mika Kuoppala 
>> > Date:   Wed May 21 19:01:06 2014 +0300
>> >
>> > drm/i915: Add null state batch to active list
>> >
>> > undid the earlier fix of only marking the ctx as initialised after it is
>> > saved by the hardware during a SET_CONTEXT operation.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: Ville Syrjälä 
>> > Cc: Damien Lespiau 
>> > Cc: Mika Kuoppala 
>> > Cc: Ben Widawsky 
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79108
>> 
>
> Daniel put his IRC r-b on this on IIRC.

Pushed to -fixes, thanks for the patch and review.

BR,
Jani.


>
> [snip]
>
> -- 
> Ben Widawsky, Intel Open Source Technology Center

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

Re: [Intel-gfx] [PATCH] drm/i915: default to having backlight if VBT not available

[Jani Nikula]

On Wed, 18 Jun 2014, Daniel Vetter  wrote:
> On Tue, Jun 17, 2014 at 03:47:05PM +0300, Jani Nikula wrote:
>> Apparently there are Apple laptops with magic smoke for a VBIOS, which
>> we fail to find and use. Default to having and setting up backlight in
>> this case.
>> 
>> This fixes a regression introduced by
>> commit c675949ec58ca50d5a3ae3c757892f1560f6e896
>> Author: Jani Nikula 
>> Date:   Wed Apr 9 11:31:37 2014 +0300
>> 
>> drm/i915: do not setup backlight if not available according to VBT
>> 
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77831
>> Reported-by: Matteo Cypriani 
>> Cc: sta...@vger.kernel.org # 3.15+
>> Signed-off-by: Jani Nikula 
>
> Tested-by: Matteo Cypriani 

Pushed to -fixes with Imre's IRC r-b.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/intel_bios.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 1ee98f121a00..827498e081df 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -315,9 +315,6 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv, 
>> struct bdb_header *bdb)
>>  const struct bdb_lfp_backlight_data *backlight_data;
>>  const struct bdb_lfp_backlight_data_entry *entry;
>>  
>> -/* Err to enabling backlight if no backlight block. */
>> -dev_priv->vbt.backlight.present = true;
>> -
>>  backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
>>  if (!backlight_data)
>>  return;
>> @@ -1088,6 +1085,9 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
>>  
>>  dev_priv->vbt.crt_ddc_pin = GMBUS_PORT_VGADDC;
>>  
>> +/* Default to having backlight */
>> +dev_priv->vbt.backlight.present = true;
>> +
>>  /* LFP panel data */
>>  dev_priv->vbt.lvds_dither = 1;
>>  dev_priv->vbt.lvds_vbt = 0;
>> -- 
>> 1.9.1
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Only mark the ctx as initialised after a SET_CONTEXT operation

[Jani Nikula]

On Tue, 24 Jun 2014, Ben Widawsky  wrote:
> From: Chris Wilson 
>
> Fallout from
>
> commit 46470fc932ac8a0e8317a220b3f4ea4ed903338e
> Author: Mika Kuoppala 
> Date:   Wed May 21 19:01:06 2014 +0300
>
> drm/i915: Add null state batch to active list
>
> undid the earlier fix of only marking the ctx as initialised after it is
> saved by the hardware during a SET_CONTEXT operation.
>
> Signed-off-by: Chris Wilson 
> Reviewed-by: Ben Widawsky 
> Cc: Ville Syrjälä 
> Cc: Damien Lespiau 
> Cc: Mika Kuoppala 

I've pushed this one patch to -fixes.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/i915_gem_context.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 21eda88..0d2c75b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -598,6 +598,7 @@ static int do_switch(struct intel_engine_cs *ring,
>   struct intel_context *from = ring->last_context;
>   struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(to);
>   u32 hw_flags = 0;
> + bool uninitialized = false;
>   int ret, i;
>  
>   if (from != NULL && ring == &dev_priv->ring[RCS]) {
> @@ -696,18 +697,19 @@ static int do_switch(struct intel_engine_cs *ring,
>   i915_gem_context_unreference(from);
>   }
>  
> + uninitialized = !to->is_initialized && from == NULL;
> + to->is_initialized = true;
> +
>  done:
>   i915_gem_context_reference(to);
>   ring->last_context = to;
>  
> - if (ring->id == RCS && !to->is_initialized && from == NULL) {
> + if (uninitialized) {
>   ret = i915_gem_render_state_init(ring);
>   if (ret)
>   DRM_ERROR("init render state: %d\n", ret);
>   }
>  
> - to->is_initialized = true;
> -
>   return 0;
>  
>  unpin_out:
> -- 
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: vlv_prepare_pll is only needed in case of non DSI interfaces

[Ville Syrjälä]

On Tue, Jun 24, 2014 at 06:51:39PM +0530, Shobhit Kumar wrote:
> For MIPI, DSI PLL is configured separately in vlv_configure_dsi_pll
> during the DSI enable sequence
> 
> Causing WARN dump otherwise in dpio_reads
> 
> Signed-off-by: Shobhit Kumar 

Yeah, the DPIO power wells might be down when enabling a DSI display so
we shouldn't go poking at DPIO registers.

But please add a !IS_CHERRYVIEW check there also, and then you can add:
Reviewed-by: Ville Syrjälä 

Looks like I need to split up chv_update_pll() in a similar fasion.

> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index fa77557..2fa7152 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4629,7 +4629,10 @@ static void valleyview_crtc_enable(struct drm_crtc 
> *crtc)
>   if (intel_crtc->active)
>   return;
>  
> - vlv_prepare_pll(intel_crtc);
> + is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
> +
> + if (!is_dsi)
> + vlv_prepare_pll(intel_crtc);
>  
>   /* Set up the display plane register */
>   dspcntr = DISPPLANE_GAMMA_ENABLE;
> @@ -4663,8 +4666,6 @@ static void valleyview_crtc_enable(struct drm_crtc 
> *crtc)
>   if (encoder->pre_pll_enable)
>   encoder->pre_pll_enable(encoder);
>  
> - is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
> -
>   if (!is_dsi) {
>   if (IS_CHERRYVIEW(dev))
>   chv_enable_pll(intel_crtc);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP

[Jani Nikula]

On Mon, 23 Jun 2014, Imre Deak  wrote:
> To achieve further power savings during system freeze (aka connected
> standby, or s0ix) we have to send a PCI_D1 opregion notification. As
> the information about the state we're entering (system freeze,
> suspend to ram or suspend to disk) is only available through the ACPI
> subsystem, make this support depend on the relevant kconfig option.
> Things will still work if this option isn't set, albeit with less than
> optimial power saving.
>
> This also fixes a compile breakage when the option is not set introduced
> in
>
> commit e5747e3adcd67ae27105003ec99fb58cba180105
> Author: Jesse Barnes 
> Date:   Thu Jun 12 08:35:47 2014 -0700
>
> drm/i915: send proper opregion notifications on suspend/resume
>
> Reported-by: Randy Dunlap 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7ae4e2a..43dc8f7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev)
>  
>   i915_save_state(dev);
>  
> - if (acpi_target_system_state() >= ACPI_STATE_S3)
> - opregion_target_state = PCI_D3cold;
> - else
> + opregion_target_state = PCI_D3cold;
> +#if IS_ENABLED(CONFIG_ACPI_SLEEP)

Maybe this should just check for CONFIG_ACPI?

BR,
Jani.

> + if (acpi_target_system_state() < ACPI_STATE_S3)
>   opregion_target_state = PCI_D1;
> +#endif
>   intel_opregion_notify_adapter(dev, opregion_target_state);
>  
>   intel_uncore_forcewake_reset(dev, false);
> -- 
> 1.8.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP

[Imre Deak]

On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote:
> On Mon, 23 Jun 2014, Imre Deak  wrote:
> > To achieve further power savings during system freeze (aka connected
> > standby, or s0ix) we have to send a PCI_D1 opregion notification. As
> > the information about the state we're entering (system freeze,
> > suspend to ram or suspend to disk) is only available through the ACPI
> > subsystem, make this support depend on the relevant kconfig option.
> > Things will still work if this option isn't set, albeit with less than
> > optimial power saving.
> >
> > This also fixes a compile breakage when the option is not set introduced
> > in
> >
> > commit e5747e3adcd67ae27105003ec99fb58cba180105
> > Author: Jesse Barnes 
> > Date:   Thu Jun 12 08:35:47 2014 -0700
> >
> > drm/i915: send proper opregion notifications on suspend/resume
> >
> > Reported-by: Randy Dunlap 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 7ae4e2a..43dc8f7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev)
> >  
> > i915_save_state(dev);
> >  
> > -   if (acpi_target_system_state() >= ACPI_STATE_S3)
> > -   opregion_target_state = PCI_D3cold;
> > -   else
> > +   opregion_target_state = PCI_D3cold;
> > +#if IS_ENABLED(CONFIG_ACPI_SLEEP)
> 
> Maybe this should just check for CONFIG_ACPI?

I wanted to send the PCI_D1 signal only if we are sure that the target
sleep state is S0ix (or S1/2) and fall back to the old behavior to send
PCI_D3cold in all other cases.

But you are right, it would make much sense if CONFIG_ACPI_SLEEP=n the
target state would be always S0ix. Rafael could you confirm this?

--Imre

> 
> BR,
> Jani.
> 
> > +   if (acpi_target_system_state() < ACPI_STATE_S3)
> > opregion_target_state = PCI_D1;
> > +#endif
> > intel_opregion_notify_adapter(dev, opregion_target_state);
> >  
> > intel_uncore_forcewake_reset(dev, false);
> > -- 
> > 1.8.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring submission mechanism

[Volkin, Bradley D]

On Tue, Jun 24, 2014 at 04:45:05AM -0700, Mateo Lozano, Oscar wrote:
> Ok, let´s try to extract something positive out of all this.
> 
> OPTION A (Ben´s proposal):
> 
> > I think the only solution for what Chris is asking for is to implement this 
> > as 1
> > context per engine, as opposed to 1 context with a context object per
> > engine. As you correctly stated, I think we all agreed the latter was fine 
> > when
> > we met. Functionally, I see no difference, but it does allow you to always 
> > use
> > a context as the sole mechanism for making any decisions and performing
> > any operations. Now without writing all the code, I can't promise it 
> > actually
> > will look better, but I think it's likely going to be a lot cleaner. Before 
> > you do
> > any changes though...
> 
> We agreed on this early on (v1), yes, but then the idea was frowned upon by 
> Brad and then by Daniel. I cannot recall exactly why anymore, but one big 
> reason was that the idr mechanism makes it difficult to track several 
> contexts with the same id (and userspace only has one context handle) and 
> something about ctx->hang_stats. From v2 on, we agreed to multiplex different 
> engines inside one intel_context (and that´s why we renamed i915_hw_context 
> to intel_context).

Yeah, at least for me, the reason was that the multiple structs per context id
code felt awkward given that most/all of the fields in a struct intel_context 
are
logically per-context rather than per-engine (vm, hang_stats, etc). It didn't
seem like the right approach to me at the time.

Brad

> 
> OPTION B (Brad´s proposal):
> 
> > So I suggested that we:
> > 
> > - Add a back pointer from struct intel_rinbuffer to intel_context (would 
> > only
> >   be valid for lrc mode)
> > - Move the intel_ringbuffer_get(engine, context) calls up to the callers
> > - Pass (engine, ringbuf) instead of (engine, context) to intel_ring_* 
> > functions
> > - Have the vfunc implemenations get the context from the ringbuffer where
> >   needed and ignore it where not
> > 
> > Looking again, we could probably add a back pointer to the intel_engine_cs
> > as well and then just pass around the ringbuf.
> 
> Sounds fine by me: intel_ringbuffer is only related to exactly one 
> intel_engine_cs and one intel_context, so having pointers to those two makes 
> sense.
> As before, this could be easily done within the existing code (passing 
> intel_rinbgbuffer instead of intel_engine_cs), but Daniel wants a code split, 
> so I can only do it for the logical ring functions.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP

[Jani Nikula]

On Tue, 24 Jun 2014, Imre Deak  wrote:
> On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote:
>> On Mon, 23 Jun 2014, Imre Deak  wrote:
>> > To achieve further power savings during system freeze (aka connected
>> > standby, or s0ix) we have to send a PCI_D1 opregion notification. As
>> > the information about the state we're entering (system freeze,
>> > suspend to ram or suspend to disk) is only available through the ACPI
>> > subsystem, make this support depend on the relevant kconfig option.
>> > Things will still work if this option isn't set, albeit with less than
>> > optimial power saving.
>> >
>> > This also fixes a compile breakage when the option is not set introduced
>> > in
>> >
>> > commit e5747e3adcd67ae27105003ec99fb58cba180105
>> > Author: Jesse Barnes 
>> > Date:   Thu Jun 12 08:35:47 2014 -0700
>> >
>> > drm/i915: send proper opregion notifications on suspend/resume
>> >
>> > Reported-by: Randy Dunlap 
>> > Signed-off-by: Imre Deak 
>> > ---
>> >  drivers/gpu/drm/i915/i915_drv.c | 7 ---
>> >  1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> > b/drivers/gpu/drm/i915/i915_drv.c
>> > index 7ae4e2a..43dc8f7 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.c
>> > +++ b/drivers/gpu/drm/i915/i915_drv.c
>> > @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev)
>> >  
>> >i915_save_state(dev);
>> >  
>> > -  if (acpi_target_system_state() >= ACPI_STATE_S3)
>> > -  opregion_target_state = PCI_D3cold;
>> > -  else
>> > +  opregion_target_state = PCI_D3cold;
>> > +#if IS_ENABLED(CONFIG_ACPI_SLEEP)
>> 
>> Maybe this should just check for CONFIG_ACPI?
>
> I wanted to send the PCI_D1 signal only if we are sure that the target
> sleep state is S0ix (or S1/2) and fall back to the old behavior to send
> PCI_D3cold in all other cases.
>
> But you are right, it would make much sense if CONFIG_ACPI_SLEEP=n the
> target state would be always S0ix. Rafael could you confirm this?

intel_opregion_notify_adapter() is a NOP for CONFIG_ACPI=n anyway. And
AFAICT CONFIG_ACPI=y && CONFIG_ACPI_SLEEP=n is broken.

BR,
Jani.


>
> --Imre
>
>> 
>> BR,
>> Jani.
>> 
>> > +  if (acpi_target_system_state() < ACPI_STATE_S3)
>> >opregion_target_state = PCI_D1;
>> > +#endif
>> >intel_opregion_notify_adapter(dev, opregion_target_state);
>> >  
>> >intel_uncore_forcewake_reset(dev, false);
>> > -- 
>> > 1.8.4
>> >
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>

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

Re: [Intel-gfx] [PATCH] drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP

[Imre Deak]

On Tue, 2014-06-24 at 17:53 +0300, Jani Nikula wrote:
> On Tue, 24 Jun 2014, Imre Deak  wrote:
> > On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote:
> >> On Mon, 23 Jun 2014, Imre Deak  wrote:
> >> > To achieve further power savings during system freeze (aka connected
> >> > standby, or s0ix) we have to send a PCI_D1 opregion notification. As
> >> > the information about the state we're entering (system freeze,
> >> > suspend to ram or suspend to disk) is only available through the ACPI
> >> > subsystem, make this support depend on the relevant kconfig option.
> >> > Things will still work if this option isn't set, albeit with less than
> >> > optimial power saving.
> >> >
> >> > This also fixes a compile breakage when the option is not set introduced
> >> > in
> >> >
> >> > commit e5747e3adcd67ae27105003ec99fb58cba180105
> >> > Author: Jesse Barnes 
> >> > Date:   Thu Jun 12 08:35:47 2014 -0700
> >> >
> >> > drm/i915: send proper opregion notifications on suspend/resume
> >> >
> >> > Reported-by: Randy Dunlap 
> >> > Signed-off-by: Imre Deak 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_drv.c | 7 ---
> >> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >> > b/drivers/gpu/drm/i915/i915_drv.c
> >> > index 7ae4e2a..43dc8f7 100644
> >> > --- a/drivers/gpu/drm/i915/i915_drv.c
> >> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> >> > @@ -544,10 +544,11 @@ static int i915_drm_freeze(struct drm_device *dev)
> >> >  
> >> >  i915_save_state(dev);
> >> >  
> >> > -if (acpi_target_system_state() >= ACPI_STATE_S3)
> >> > -opregion_target_state = PCI_D3cold;
> >> > -else
> >> > +opregion_target_state = PCI_D3cold;
> >> > +#if IS_ENABLED(CONFIG_ACPI_SLEEP)
> >> 
> >> Maybe this should just check for CONFIG_ACPI?
> >
> > I wanted to send the PCI_D1 signal only if we are sure that the target
> > sleep state is S0ix (or S1/2) and fall back to the old behavior to send
> > PCI_D3cold in all other cases.
> >
> > But you are right, it would make much sense if CONFIG_ACPI_SLEEP=n the
> > target state would be always S0ix. Rafael could you confirm this?
> 
> intel_opregion_notify_adapter() is a NOP for CONFIG_ACPI=n anyway.

Ok, but the question for me is what's the target sleep state in case of
CONFIG_ACPI=y and CONFIG_ACPI_SLEEP=n.

>  And AFAICT CONFIG_ACPI=y && CONFIG_ACPI_SLEEP=n is broken.

But it seems like a valid configuration. So it needs to be fixed
separately.

--Imre


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

[Jani Nikula]

Historically we've exposed the full backlight PWM duty cycle range to
the userspace, in the name of "mechanism, not policy". However, it turns
out there are both panels and board designs where there is a minimum
duty cycle that is required for proper operation. The minimum duty cycle
is available in the VBT.

The backlight class sysfs interface does not make any promises to the
userspace about the physical meaning of the range
0..max_brightness. Specifically there is no guarantee that 0 means off;
indeed for acpi_backlight 0 usually is not off, but the minimum
acceptable value.

Respect the minimum backlight, and expose the range acceptable to the
hardware as 0..max_brightness to the userspace via the backlight class
device; 0 means the minimum acceptable enabled value. To switch off the
backlight, the user must disable the encoder.

As a side effect, make the backlight class device max brightness and
physical PWM modulation frequency (i.e. max duty cycle)
independent. This allows a follow-up patch to virtualize the max value
exposed to the userspace.

Signed-off-by: Jani Nikula 

---

This version turned out uglier than I anticipated because the requests
through opregion in range 0..255 already have the minimum limit bundled
in. Scaling that would be wrong. Ideas welcome.
---
 drivers/gpu/drm/i915/intel_drv.h  |   5 +-
 drivers/gpu/drm/i915/intel_opregion.c |   2 +-
 drivers/gpu/drm/i915/intel_panel.c| 158 ++
 3 files changed, 146 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5f7c7bd94d90..2651e2ff7c05 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -165,6 +165,7 @@ struct intel_panel {
struct {
bool present;
u32 level;
+   u32 min;
u32 max;
bool enabled;
bool combination_mode;  /* gen 2/4 only */
@@ -948,8 +949,8 @@ void intel_pch_panel_fitting(struct intel_crtc *crtc,
 void intel_gmch_panel_fitting(struct intel_crtc *crtc,
  struct intel_crtc_config *pipe_config,
  int fitting_mode);
-void intel_panel_set_backlight(struct intel_connector *connector, u32 level,
-  u32 max);
+void intel_panel_set_backlight_acpi(struct intel_connector *connector,
+   u32 level, u32 max);
 int intel_panel_setup_backlight(struct drm_connector *connector);
 void intel_panel_enable_backlight(struct intel_connector *connector);
 void intel_panel_disable_backlight(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 2e2c71fcc9ed..5a979b70e3cf 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -418,7 +418,7 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
 */
DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
list_for_each_entry(intel_connector, &dev->mode_config.connector_list, 
base.head)
-   intel_panel_set_backlight(intel_connector, bclp, 255);
+   intel_panel_set_backlight_acpi(intel_connector, bclp, 255);
iowrite32(DIV_ROUND_UP(bclp * 100, 255) | ASLE_CBLV_VALID, &asle->cblv);
 
drm_modeset_unlock(&dev->mode_config.connection_mutex);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 38a98570d10c..4924c5e07b07 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -398,6 +398,69 @@ intel_panel_detect(struct drm_device *dev)
}
 }
 
+/**
+ * scale - scale values from one range to another
+ *
+ * @source_val: value in range [@source_min..@source_max]
+ *
+ * Return @source_val in range [@source_min..@source_max] scaled to range
+ * [@target_min..@target_max].
+ */
+static uint32_t scale(uint32_t source_val,
+ uint32_t source_min, uint32_t source_max,
+ uint32_t target_min, uint32_t target_max)
+{
+   uint64_t target_val;
+
+   BUG_ON(source_min > source_max);
+   BUG_ON(target_min > target_max);
+
+   /* defensive */
+   source_val = clamp(source_val, source_min, source_max);
+
+   /* avoid overflows */
+   target_val = (uint64_t)(source_val - source_min) *
+   (target_max - target_min);
+   do_div(target_val, source_max - source_min);
+   target_val += target_min;
+
+   return target_val;
+}
+
+/* Scale user_level in range [0..user_max] to [hw_min..hw_max]. */
+static inline u32 scale_user_to_hw(struct intel_connector *connector,
+  u32 user_level, u32 user_max)
+{
+   struct intel_panel *panel = &connector->panel;
+
+   return scale(user_level, 0, user_max,
+panel->backlight.min, panel->backlight.max);
+}
+
+/* S

[Intel-gfx] [PATCH 1/2] drm/i915: extract backlight minimum brightness from VBT

[Jani Nikula]

Reviewed-by: Jesse Barnes 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h   | 1 +
 drivers/gpu/drm/i915/intel_bios.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cea59649ef2..81e8d17063d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1230,6 +1230,7 @@ struct intel_vbt_data {
u16 pwm_freq_hz;
bool present;
bool active_low_pwm;
+   u8 min_brightness;  /* min_brightness/255 of max */
} backlight;
 
/* MIPI DSI */
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 827498e081df..608ed302f24d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -336,11 +336,12 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv, 
struct bdb_header *bdb)
 
dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
+   dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
DRM_DEBUG_KMS("VBT backlight PWM modulation frequency %u Hz, "
  "active %s, min brightness %u, level %u\n",
  dev_priv->vbt.backlight.pwm_freq_hz,
  dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
- entry->min_brightness,
+ dev_priv->vbt.backlight.min_brightness,
  backlight_data->level[panel_type]);
 }
 
-- 
2.0.0

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

Re: [Intel-gfx] [PATCH] drm/i915: BDW: Adding Reserved PCI IDs.

[Chris Wilson]

On Tue, Jun 24, 2014 at 04:19:38PM +0300, Jani Nikula wrote:
> On Fri, 13 Jun 2014, Rodrigo Vivi  wrote:
> > Hi Daniel,
> >
> > please consider to merge the first version. So we can move fwd with ddx
> > patche followed by proper marketing names.
> 
> Pushed v1 to -fixes, thanks for the patch and review.

Hey Rodrigo, I spotted another place we have identifier strings... In
xf86-video-intel/README. :|
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.

[Jani Nikula]

On Mon, 23 Jun 2014, "Wang, Quanxian"  wrote:
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Tuesday, June 17, 2014 11:38 PM
>> To: Wang, Quanxian
>> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
>> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
>> for valleyview platform.
>> 
>> On Tue, 17 Jun 2014, "Wang, Quanxian"  wrote:
>> > File dmesg_normal_20140617.log will contain dmesg log when boot the
>> > machine and start weston. (Previous is overwrite, but it is enough for
>> graphics boot message) File dmesg_error_20140617.log contains dmesg log
>> after Weston exit when it found no connector available.
>> >
>> > I disable log for  hotplug event from valleyview_irq_handler. There are so
>> many. Maybe you can find some private debug log. Don't need to care that.
>> 
>> Per DP spec we need to read the SINK_COUNT. Perhaps your problem is the
>> hotplug irqs?
> [Wang, Quanxian] Hi, Jani
> The log event is about the transaction event instead of hotplug event. It is 
> general since they will use I2c to read byte one by one. It will generate 
> many transaction.
>
> But the root cause is really about hotplug(intel_hpd_irq_handler). When we 
> switch to console, there will be a hotplug event happens after a while. After 
> that, the system will continually get the hotplug event to switch sink device 
> on and off periodly.  With DisplayPort 1.2 spec, '' This bit is used for 
> either monitor hotplug/unplug or for notification of a sink event.", I am not 
> sure if it is notification of  a sink event or real hotplug event. We have no 
> code to identify the difference between hotplug/unplug  and notification of a 
> sink event. I check display port spec and also not found how to identify them 
> differently.
>
> Question is: 
> In function intel_dp_detect_dpcd, before checking SINK_COUNT, we will use 
> intel_dp_get_dpcd to get the dpcd. Could we think there is an active sink 
> device attached to branch device if dpcd content is not null.
> According to the display port spec, only sink device has dpcd, if we get one, 
> there must be a sink device attached to branch device or source device. Right?

No. From your logs, the DPCD has bit 0 set in address 5h, which means
downstream port present, which is only allowed in branch devices.

BR,
Jani.




>
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>> >
>> > Thanks
>> >
>> > Regards
>> >
>> > Quanxian Wang
>> >
>> >
>> >> -Original Message-
>> >> From: Wang, Quanxian
>> >> Sent: Tuesday, June 17, 2014 10:14 AM
>> >> To: 'Jani Nikula'
>> >> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
>> >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not
>> >> reliable for valleyview platform.
>> >>
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >> > Sent: Monday, June 16, 2014 4:18 PM
>> >> > To: Wang, Quanxian; Daniel Vetter
>> >> > Cc: intel-gfx@lists.freedesktop.org
>> >> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not
>> >> > reliable for valleyview platform.
>> >> >
>> >> > On Mon, 16 Jun 2014, "Wang, Quanxian" 
>> >> wrote:
>> >> > >> -Original Message-
>> >> > >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >> > >> Sent: Friday, June 13, 2014 5:12 PM
>> >> > >> To: Daniel Vetter; Wang, Quanxian
>> >> > >> Cc: intel-gfx@lists.freedesktop.org
>> >> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is
>> >> > >> not reliable for valleyview platform.
>> >> > >>
>> >> > >> On Fri, 13 Jun 2014, Daniel Vetter  wrote:
>> >> > >> > On Fri, Jun 13, 2014 at 02:52:04PM +0800, Quanxian Wang wrote:
>> >> > >> >> DP connector will be disconnected after chvt to another
>> >> > >> >> console for
>> >> > >> >> 10 minutes or more on valleyview platform VTC1010.
>> >> > >> >
>> >> > >> > This needs _much_ more detail, really.
>> >> > >> >
>> >> > >> > Also it smells like we work around a sink issue, which means
>> >> > >> > the correct quirk is to use some sink id (like OUI), _not_ the
>> platform.
>> >> > >> > Since this way you break all DP1.1+ stuff on vlv and if
>> >> > >> > someone puts this panel onto a different platform it still doesn't
>> work.
>> >> > >>
>> >> > >> Furthermore you should end up in this code path *only* if you
>> >> > >> have a DP branch device. This shouldn't happen for eDP or native
>> >> > >> DP displays. Please confirm what kind of setup you're
>> >> > >> experiencing issues
>> >> > with.
>> >> > >>
>> >> > >> Frankly I wouldn't be surpised if we do have issues with branch
>> >> > >> devices, but this is not the fix.
>> >> > > [Wang, Quanxian] Any idea how to do it? Currently in VTC1010
>> >> > > device, we use native DP to connect HDMI monitor.(DP2HDMI) This
>> >> > > case will
>> >> > happen.
>> >> >
>> >> > So it's an active adapter?
>> >> [Wang, Quanxian] yes.
>> >> >
>> >> > Please send full dmesg from early booth with drm.debug=0xe modu

[Intel-gfx] [PATCH v4 maintainer-tools] qf: Use git remote rm instead of git remote remove

[Damien Lespiau]

'remove' is not recognized is a slightly older git (1.7.9.5) on a
slightly older distro. Use 'rm' instead, which also work on the git
version listing 'remove' in git remote help (1.8.3.1).

Signed-off-by: Damien Lespiau 
---
 qf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qf b/qf
index 67a3ba6..adf95ca 100755
--- a/qf
+++ b/qf
@@ -125,7 +125,7 @@ function repo_init
# setup for quilt patch repo
git clone --local --no-checkout -- . patches
cd patches
-   git remote remove origin
+   git remote rm origin
 
# include remotes and branches and all that from parent repo
git config include.path ../../.git/config
-- 
1.8.3.1

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

[Intel-gfx] [PATCH] BDW: Adding Marketing names.

[Rodrigo Vivi]

Even the unknown/reserved ones might stay with HD Graphics.

v2: Add missing names to intel.man and README files as well. (Chris)

Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
 README |  3 +++
 man/intel.man  |  7 +--
 src/intel_module.c | 32 +---
 3 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/README b/README
index dc64ff7..386e07d 100644
--- a/README
+++ b/README
@@ -15,6 +15,9 @@ Intel graphics chipsets including:
G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
PineView-M (Atom N400 series)
PineView-D (Atom D400/D500 series)
+   Intel(R) HD Graphics: 2000-6000,
+   Intel(R) Iris(TM) Graphics: 5100/6100, and
+   Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
 
 Where to get more information about the driver
 --
diff --git a/man/intel.man b/man/intel.man
index 9deac41..917f7f8 100644
--- a/man/intel.man
+++ b/man/intel.man
@@ -25,8 +25,11 @@ the 830M and later.
 .B intel
 supports the i810, i810-DC100, i810e, i815, i830M, 845G, 852GM, 855GM,
 865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME,
-G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, and Pineview-M in
-Atom N400 series, Pineview-D in Atom D400/D500 series.
+G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in
+Atom N400 series, Pineview-D in Atom D400/D500 series,
+Intel(R) HD Graphics: 2000-6000,
+Intel(R) Iris(TM) Graphics: 5100/6100, and
+Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
 
 .SH CONFIGURATION DETAILS
 Please refer to __xconfigfile__(__filemansuffix__) for general configuration
diff --git a/src/intel_module.c b/src/intel_module.c
index a47427a..35c24a2 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -224,6 +224,32 @@ static const SymTabRec intel_chipsets[] = {
{0x0155, "HD Graphics"},
{0x0157, "HD Graphics"},
 
+   /* Broadwell Marketing names */
+   {0x1602, "HD graphics"},
+   {0x1606, "HD graphics"},
+   {0x160B, "HD graphics"},
+   {0x160A, "HD graphics"},
+   {0x160D, "HD graphics"},
+   {0x160E, "HD graphics"},
+   {0x1612, "HD graphics 5600"},
+   {0x1616, "HD graphics 5500"},
+   {0x161B, "HD graphics"},
+   {0x161A, "HD graphics"},
+   {0x161D, "HD graphics"},
+   {0x161E, "HD graphics 5300"},
+   {0x1622, "Iris Pro graphics 6200"},
+   {0x1626, "HD graphics 6000"},
+   {0x162B, "Iris graphics 6100"},
+   {0x162A, "Iris Pro graphics P6300"},
+   {0x162D, "HD graphics"},
+   {0x162E, "HD graphics"},
+   {0x1632, "HD graphics"},
+   {0x1636, "HD graphics"},
+   {0x163B, "HD graphics"},
+   {0x163A, "HD graphics"},
+   {0x163D, "HD graphics"},
+   {0x163E, "HD graphics"},
+
/* When adding new identifiers, also update:
 * 1. intel_identify()
 * 2. man/intel.man
@@ -407,9 +433,9 @@ static void intel_identify(int flags)
if (unique != stack)
free(unique);
 
-   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
2000-5000\n");
-   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Graphics: 
5100\n");
-   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
Graphics: 5200\n");
+   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
2000-6000\n");
+   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Graphics: 
5100, 6100\n");
+   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
Graphics: 5200, 6200, P6300\n");
 }
 
 static Bool intel_driver_func(ScrnInfoPtr pScrn,
-- 
1.9.3

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

Re: [Intel-gfx] [PATCH 26/53] drm/i915/bdw: New logical ring submission mechanism

[Jesse Barnes]

On Mon, 23 Jun 2014 14:13:55 +0100
Chris Wilson  wrote:

> On Mon, Jun 23, 2014 at 01:09:37PM +, Mateo Lozano, Oscar wrote:
> > So far, yes, but that´s only because I artificially made
> > intel_lrc.c self-contained, as Daniel requested. What if we need to
> > execute commands from somewhere else, like in
> > intel_gen7_queue_flip()?
> > 
> > And this takes me to another discussion: this logical ring vs
> > legacy ring split is probably a good idea (time will tell), but we
> > should provide a way of sending commands for execution without
> > knowing if Execlists are enabled or not. In the early series that
> > was easy because we reused the ring_begin, ring_emit & ring_advance
> > functions, but this is not the case anymore. And without this,
> > sooner or later somebody will break legacy or execlists (this
> > already happened last week, when somebody here was implementing
> > native sync without knowing about Execlists).
> > 
> > So, the questions is: how do you feel about a dev_priv.gt vfunc
> > that takes a context, a ring, an array of DWORDS and a BB length
> > and does the intel_(logical)_ring_begin/emit/advance based on
> > i915.enable_execlists?
> 
> I'm still baffled by the design. intel_ring_begin() and friends should
> be able to find their context (logical or legacy) from the ring and
> dtrt.

To me, given that the LRC contains the ring, the right thing to do
would be to do what Oscar did in the first place: pass the context
around everywhere.  If there were cases where that wasn't ideal (the
layering violations you mention later?) we should fix them up instead.

But given that this is a standalone file, it's easy to fix up however
we want incrementally, as long as things work well to begin with and
it's reasonably easy to review it...

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

Re: [Intel-gfx] [PATCH] BDW: Adding Marketing names.

[Chris Wilson]

On Tue, Jun 24, 2014 at 03:14:54AM -0700, Rodrigo Vivi wrote:
> Even the unknown/reserved ones might stay with HD Graphics.
> 
> v2: Add missing names to intel.man and README files as well. (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Rodrigo Vivi 

Thanks, pushed with a refreshed i915_pciids.h
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.

[Dave Airlie]

On 23 June 2014 20:37, Wang, Quanxian  wrote:
>
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Tuesday, June 17, 2014 11:38 PM
>> To: Wang, Quanxian
>> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
>> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
>> for valleyview platform.
>>
>> On Tue, 17 Jun 2014, "Wang, Quanxian"  wrote:
>> > File dmesg_normal_20140617.log will contain dmesg log when boot the
>> > machine and start weston. (Previous is overwrite, but it is enough for
>> graphics boot message) File dmesg_error_20140617.log contains dmesg log
>> after Weston exit when it found no connector available.
>> >
>> > I disable log for  hotplug event from valleyview_irq_handler. There are so
>> many. Maybe you can find some private debug log. Don't need to care that.
>>
>> Per DP spec we need to read the SINK_COUNT. Perhaps your problem is the
>> hotplug irqs?
> [Wang, Quanxian] Hi, Jani
> The log event is about the transaction event instead of hotplug event. It is 
> general since they will use I2c to read byte one by one. It will generate 
> many transaction.
>
> But the root cause is really about hotplug(intel_hpd_irq_handler). When we 
> switch to console, there will be a hotplug event happens after a while. After 
> that, the system will continually get the hotplug event to switch sink device 
> on and off periodly.  With DisplayPort 1.2 spec, '' This bit is used for 
> either monitor hotplug/unplug or for notification of a sink event.", I am not 
> sure if it is notification of  a sink event or real hotplug event. We have no 
> code to identify the difference between hotplug/unplug  and notification of a 
> sink event. I check display port spec and also not found how to identify them 
> differently.
>
There are patches on the list to distinguish between short and long
hpd irqs, they are need of review.

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add #defines for short/long pulse on gmch platforms

[Todd Previte]

These look like they're already integrated into -nightly? But for the 
record...


Reviewed-by: Todd Previte 

-T


Dave Airlie 
Tuesday, June 17, 2014 6:29 PM
From: Daniel Vetter 

For no reason at all the public docs lack them, and Dave needs them
for his hpd interrupt rework.

Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h 
b/drivers/gpu/drm/i915/i915_reg.h

index 5122254..5d8ba0c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2526,8 +2526,14 @@ enum punit_power_well {
#define PORTC_HOTPLUG_LIVE_STATUS_VLV (1 << 28)
#define PORTB_HOTPLUG_LIVE_STATUS_VLV (1 << 29)
#define PORTD_HOTPLUG_INT_STATUS (3 << 21)
+#define PORTD_HOTPLUG_INT_LONG_PULSE (2 << 21)
+#define PORTD_HOTPLUG_INT_SHORT_PULSE (1 << 21)
#define PORTC_HOTPLUG_INT_STATUS (3 << 19)
+#define PORTC_HOTPLUG_INT_LONG_PULSE (2 << 19)
+#define PORTC_HOTPLUG_INT_SHORT_PULSE (1 << 19)
#define PORTB_HOTPLUG_INT_STATUS (3 << 17)
+#define PORTB_HOTPLUG_INT_LONG_PULSE (2 << 17)
+#define PORTB_HOTPLUG_INT_SHORT_PLUSE (1 << 17)
/* CRT/TV common between gen3+ */
#define CRT_HOTPLUG_INT_STATUS (1 << 11)
#define TV_HOTPLUG_INT_STATUS (1 << 10)
Dave Airlie 
Tuesday, June 17, 2014 6:29 PM
Can we get these merged or even looked at?, they are blocking the 
whole MST progress,

and I don't have any insight to secret Intel review process. :-)

Dave.

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


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: rework digital port IRQ handling (v2)

[Todd Previte]

This looks like it's good to go.

As an aside, I don't *think* any of the compliance testing stuff I'm 
working on cares whether it's short of long pulse (1.1a compliance), but 
it will be interesting to see if/when/where it might have an effect.


Reviewed-by: Todd Previte 


Dave Airlie 
Tuesday, June 17, 2014 6:29 PM
From: Dave Airlie 

The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.

However with DP 1.2 MST we need to handle the short irqs on their
own outside the modesetting locking the long hpd's involve. This
patch adds the framework to distinguish between short/long to the
current code base, to lay the basis for future DP 1.2 MST work.

This should mean we get better bisectability in case of regression
due to the new irq handling.

v2: add GM45 support (untested, due to lack of hw)

Signed-off-by: Dave Airlie 
---
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/i915_irq.c | 160 
+--

drivers/gpu/drm/i915/intel_ddi.c | 3 +
drivers/gpu/drm/i915/intel_dp.c | 20 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
5 files changed, 182 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 8f68678..5fd5bf3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1551,6 +1551,11 @@ struct drm_i915_private {

struct i915_runtime_pm pm;

+ struct intel_digital_port *hpd_irq_port[I915_MAX_PORTS];
+ u32 long_hpd_port_mask;
+ u32 short_hpd_port_mask;
+ struct work_struct dig_port_work;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_irq.c 
b/drivers/gpu/drm/i915/i915_irq.c

index cbf31cb..9913c08 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1096,6 +1096,53 @@ static bool intel_hpd_irq_event(struct 
drm_device *dev,

return true;
}

+static void i915_digport_work_func(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private, dig_port_work);
+ unsigned long irqflags;
+ u32 long_port_mask, short_port_mask;
+ struct intel_digital_port *intel_dig_port;
+ int i, ret;
+ u32 old_bits = 0;
+
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+ long_port_mask = dev_priv->long_hpd_port_mask;
+ dev_priv->long_hpd_port_mask = 0;
+ short_port_mask = dev_priv->short_hpd_port_mask;
+ dev_priv->short_hpd_port_mask = 0;
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+
+ for (i = 0; i < I915_MAX_PORTS; i++) {
+ bool valid = false;
+ bool long_hpd = false;
+ intel_dig_port = dev_priv->hpd_irq_port[i];
+ if (!intel_dig_port || !intel_dig_port->hpd_pulse)
+ continue;
+
+ if (long_port_mask & (1 << i)) {
+ valid = true;
+ long_hpd = true;
+ } else if (short_port_mask & (1 << i))
+ valid = true;
+
+ if (valid) {
+ ret = intel_dig_port->hpd_pulse(intel_dig_port, long_hpd);
+ if (ret == true) {
+ /* if we get true fallback to old school hpd */
+ old_bits |= (1 << intel_dig_port->base.hpd_pin);
+ }
+ }
+ }
+
+ if (old_bits) {
+ spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+ dev_priv->hpd_event_bits |= old_bits;
+ spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+ schedule_work(&dev_priv->hotplug_work);
+ }
+}
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
@@ -1520,23 +1567,104 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_device *dev,

#define HPD_STORM_DETECT_PERIOD 1000
#define HPD_STORM_THRESHOLD 5

+static int ilk_port_to_hotplug_shift(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ case PORT_E:
+ default:
+ return -1;
+ case PORT_B:
+ return 0;
+ case PORT_C:
+ return 8;
+ case PORT_D:
+ return 16;
+ }
+}
+
+static int g4x_port_to_hotplug_shift(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ case PORT_E:
+ default:
+ return -1;
+ case PORT_B:
+ return 17;
+ case PORT_C:
+ return 19;
+ case PORT_D:
+ return 21;
+ }
+}
+
+static inline enum port get_port_from_pin(enum hpd_pin pin)
+{
+ switch (pin) {
+ case HPD_PORT_B:
+ return PORT_B;
+ case HPD_PORT_C:
+ return PORT_C;
+ case HPD_PORT_D:
+ return PORT_D;
+ default:
+ return PORT_A; /* no hpd */
+ }
+}
+
static inline void intel_hpd_irq_handler(struct drm_device *dev,
u32 hotplug_trigger,
+ u32 dig_hotplug_reg,
const u32 *hpd)
{
struct drm_i915_private *dev_priv = dev->dev_private;
int i;
+ enum port port;
bool storm_detected = false;
+ bool queue_dig = false, queue_hp = false;
+ u32 dig_shift;
+ u32 dig_port_mask = 0;

if (!hotplug_trigger)
return;

- DRM_DEBUG_DRIVER("hotplug event received, stat 0x%08x\n",
- hotplug_trigger);
+ DRM_DEBUG_DRIVER("hotplug event received, stat 0x%08x, dig 0x%08x\n",
+ hotplug_trigger, dig_hotplug_reg);

spin_lock(&dev_priv->irq_lock);
for (i =

[Intel-gfx] [PATCH 1/6] drm/i915: Add automated testing support for Displayport compliance testing

[Todd Previte]

Add the skeleton framework for supporting automation for Displayport compliance 
testing. This patch
adds the necessary framework for the source device to appropriately responded 
to test automation
requests from a sink device.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 84 -
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b5ec489..3bd1780 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3328,11 +3328,91 @@ intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 
*sink_irq_vector)
   sink_irq_vector, 1) == 1;
 }
 
+/* Displayport compliance testing - Link training */
+static uint8_t
+intel_dp_autotest_link_training(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+/* Displayport compliance testing - Video pattern testing */
+static uint8_t
+intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+/* Displayport compliance testing - EDID operations */
+static uint8_t
+intel_dp_autotest_edid(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+/* Displayport compliance testing - PHY pattern testing */
+static uint8_t
+intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+/* Displayport compliance testing - Fast AUX transactions (optional) */
+static uint8_t
+intel_dp_autotest_faux_pattern(struct intel_dp *intel_dp)
+{
+uint8_t test_result = DP_TEST_NAK;
+   printk("Displayport: Fast AUX (FAUX) not supported.\n");
+return test_result;
+}
+
 static void
 intel_dp_handle_test_request(struct intel_dp *intel_dp)
 {
-   /* NAK by default */
-   drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_RESPONSE, DP_TEST_NAK);
+   uint8_t response = DP_TEST_NAK;
+   uint8_t rxdata = 0;
+   int ret = 0;
+
+   DRM_DEBUG_KMS("Displayport: Received automated test request\n");
+   /* Read DP_TEST_REQUEST register to identify the requested test */
+   ret = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_REQUEST, &rxdata, 1);
+
+   /* Determine which test has been requested */
+   switch (rxdata) {
+   /* ACK/NAK response based on test function response
+  Unimplemented/unsupported tests will NAK */
+   case DP_TEST_LINK_TRAINING:
+   DRM_DEBUG_KMS("Displayport: Executing LINK_TRAINING 
request\n");
+   response = intel_dp_autotest_link_training(intel_dp);
+   break;
+   case DP_TEST_LINK_VIDEO_PATTERN:
+   DRM_DEBUG_KMS("Displayport: Executing TEST_PATTERN 
request\n");
+   response = intel_dp_autotest_video_pattern(intel_dp);
+   break;
+   case DP_TEST_LINK_EDID_READ:
+   DRM_DEBUG_KMS("Displayport: Executing EDID request\n");
+   response = intel_dp_autotest_edid(intel_dp);
+   break;
+   case DP_TEST_LINK_PHY_TEST_PATTERN:
+   DRM_DEBUG_KMS("Displayport: Executing PHY_PATTERN 
request\n");
+   response = intel_dp_autotest_phy_pattern(intel_dp);
+   break;
+   /* FAUX is optional in DP 1.2*/
+   case DP_TEST_LINK_FAUX_PATTERN:
+   DRM_DEBUG_KMS("Displayport: Executing FAUX_PATTERN 
request \n");
+   response = intel_dp_autotest_faux_pattern(intel_dp);
+   break;
+   /* Unsupported test case or something went wrong */
+   default:
+   /* Log error here for unhandled test request */
+   DRM_DEBUG_KMS("Displayport: Error - unhandled automated 
test request\n");
+   break;
+   }
+   /* Send the response from the test result */
+   ret = drm_dp_dpcd_write(&intel_dp->aux, DP_TEST_RESPONSE, &response, 1);
 }
 
 /*
-- 
1.9.1

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

[Intel-gfx] [PATCH 5/6] drm/i915: Update Displayport compliance testing for link training

[Todd Previte]

Adds basic link training test functionality for Displayport compliance.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4c5d229..95bd27a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3405,6 +3405,30 @@ static uint8_t
 intel_dp_autotest_link_training(struct intel_dp *intel_dp)
 {
uint8_t test_result = DP_TEST_NAK;
+   uint8_t rxdata[2];
+   uint8_t link_status[DP_LINK_STATUS_SIZE];
+   int bytes_ret = 0;
+
+   /* Read test parameters */
+   bytes_ret = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_LINK_RATE, rxdata, 
2);
+
+   /* Set link rate directly */
+   intel_dp->link_bw = rxdata[0];
+   /* Preserve 7:5 when setting lane count */
+   intel_dp->lane_count &= 0xE0;
+   intel_dp->lane_count |= rxdata[1];
+
+   DRM_DEBUG_KMS("Displayport: Link training testing - %d lanes @ %02x 
link rate\n", intel_dp->lane_count, intel_dp->link_bw);
+
+   /* Train the link */
+   intel_dp_start_link_train(intel_dp);
+   intel_dp_complete_link_train(intel_dp);
+   intel_dp_stop_link_train(intel_dp);
+
+   // Check link status for successful completion
+   if (drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))
+   test_result = true;
+
return test_result;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 6/6] drm/i915: Update intel_dp_check_link_status() for Displayport compliance testing

[Todd Previte]

Move the DPCD read to the top and check for an interrupt from the sink to catch
Displayport automated testing requests necessary to support Displayport 
compliance
testing. The checks for active connectors and link status are moved below the
check for the interrupt.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 95bd27a..b58fc25 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3579,22 +3579,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];
 
-   /* FIXME: This access isn't protected by any locks. */
-   if (!intel_encoder->connectors_active)
-   return;
-
-   if (WARN_ON(!intel_encoder->base.crtc))
-   return;
-
-   /* Try to read receiver status if the link appears to be up */
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   return;
-   }
-
-   /* Now read the DPCD to see if it's actually running */
-   if (!intel_dp_get_dpcd(intel_dp)) {
+   /* Attempt to read the DPCD */
+   if (!intel_dp_get_dpcd(intel_dp))
return;
-   }
 
/* Try to read the source of the interrupt */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
@@ -3604,12 +3591,25 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
   DP_DEVICE_SERVICE_IRQ_VECTOR,
   sink_irq_vector);
 
-   if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
+   if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST) {
+   DRM_DEBUG_KMS("Displayport: Received automated test 
request\n");
intel_dp_handle_test_request(intel_dp);
+   }
if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
+   /* FIXME: This access isn't protected by any locks. */
+   if (!intel_encoder->connectors_active)
+   return;
+
+   if (WARN_ON(!intel_encoder->base.crtc))
+   return;
+
+   /* Try to read receiver status if the link appears to be up */
+   if (!intel_dp_get_link_status(intel_dp, link_status))
+   return;
+
if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
  intel_encoder->base.name);
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/6] drm/i915: Add a delay in Displayport AUX transactions for compliance testing

[Todd Previte]

Several compliance tests require that follow-up AUX transactions (after a
failure or no response) are not resent sooner than 400us later. Add a 400us
delay to the response time of any failed transaction to account for this.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3bd1780..43fcabe 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -561,8 +561,12 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
   DP_AUX_CH_CTL_RECEIVE_ERROR);
 
if (status & (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+ DP_AUX_CH_CTL_RECEIVE_ERROR)) {
+   /* 400us delay between transactions for 
errors/timeouts
+  required for DP compliance testing */
+   udelay(400);
continue;
+   }
if (status & DP_AUX_CH_CTL_DONE)
break;
}
-- 
1.9.1

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

[Intel-gfx] i915 Displayport Compliance Testing

[Todd Previte]

This patch set adds the foundational support for Displayport compliance testing 
in the
i915 driver. It implements the framework for automated test support that 
preclude the
need (most) for operator input during testing. Tests for AUX transactions, EDID 
reads
and basic link training have also been included, along with any support and 
utility
functions required. Some changes have also been made to existing code to 
accommodate 
compliance testing.

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

[Intel-gfx] [PATCH 4/6] drm/i915: Update Displayport compliance test for EDID operations

[Todd Previte]

Adds additional functionality to the EDID compliance testing operations to
further enhance Displayport compliance. Specifically this patch adds the
ability to search through the probed EDID modes and select an appropriate
mode based on the test requirements. A stub function for actually setting
the mode is included as well.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 100 +---
 1 file changed, 93 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d060853..4c5d229 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -82,6 +82,15 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
 };
 
+/* Enum for selecting EDID preferred or failsafe display mode
+   during DP compliance testing */
+typedef enum
+{
+   DP_COMPLIANCE_MODE_FAILSAFE = 0,
+   DP_COMPLIANCE_MODE_PREFERRED = 1
+} dp_compliance_mode;
+
+
 /**
  * is_edp - is the given port attached to an eDP panel (either CPU or PCH)
  * @intel_dp: DP struct
@@ -3332,6 +3341,65 @@ intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 
*sink_irq_vector)
   sink_irq_vector, 1) == 1;
 }
 
+/* Displayport compliance - internal modeset function */
+static int
+intel_dp_set_mode_for_compliance(struct intel_dp* intel_dp,
+struct 
drm_display_mode *comp_mode)
+{
+   int status = 0;
+   /* FIXME: Implementation TBD - necessary for DP compliance */
+   return status;
+}
+
+/* Displayport compliance - find the correct display mode */
+static struct drm_display_mode*
+intel_dp_get_compliance_mode(struct intel_dp *intel_dp, dp_compliance_mode 
compliance_mode)
+{
+   struct drm_display_mode *found_mode = NULL;
+   struct drm_connector *connector = &intel_dp->attached_connector->base;
+   int mode_count = 0;
+   char *comp_mode_string = NULL;
+
+   switch (compliance_mode) {
+   case DP_COMPLIANCE_MODE_FAILSAFE:
+   /* Failsafe is 640x480 @ 60Hz, 6bpc */
+   list_for_each_entry(found_mode, 
&connector->probed_modes, head) {
+   if (found_mode->hdisplay == 640 &&
+  found_mode->vdisplay == 480 &&
+  found_mode->vrefresh == 60) {
+  // Found the failsafe mode, return it
+  DRM_DEBUG_KMS("Displayport: Found 
failsafe mode '%s'\n",
+
found_mode->name);
+  goto exit_with_mode;
+   }
+   mode_count++;
+   }
+   comp_mode_string = "Failsafe";
+   break;
+   case DP_COMPLIANCE_MODE_PREFERRED:
+   list_for_each_entry(found_mode, 
&connector->probed_modes, head) {
+   // Check for a preferred mode
+   if (found_mode->type & DRM_MODE_TYPE_PREFERRED) 
{
+  // Found the preferred mode, return 
it
+  DRM_DEBUG_KMS("Displayport: Found 
preferred mode '%s'\n",
+
found_mode->name);
+  goto exit_with_mode;
+   }
+   mode_count++;
+   }
+   comp_mode_string = "Preferred";
+   break;
+   default:
+   DRM_DEBUG_KMS("Displayport: Invalid compliance mode 
type specified\n");
+   break;
+   }
+   /* No mode found, report the error */
+   DRM_DEBUG_KMS("Displayport: Could not find %s mode in %d modes\n", 
comp_mode_string, mode_count);
+
+exit_with_mode:
+   return found_mode;
+}
+
 /* Displayport compliance testing - Link training */
 static uint8_t
 intel_dp_autotest_link_training(struct intel_dp *intel_dp)
@@ -3362,30 +3430,48 @@ intel_dp_autotest_edid(struct intel_dp *intel_dp)
dp_compliance_mode comp_mode_type = DP_COMPLIANCE_MODE_PREFERRED;
int mode_count = 0;
 
+   DRM_DEBUG_KMS("Displayport: EDID automated test\n");
+
+   /* FIXME: Need a complete DPCD read here
+ Need to read out branch device information */
+
+   /* Now read out the EDID */
edid_read = drm_get_edid(connector, adapter);
 
-   DRM_DEBUG_KMS("Displayport: EDID automated test\n");
+   /* FIXME: Need to determine how to detect E-DDC here */
+
 
if (edid_read) {
test_result

[Intel-gfx] [PATCH 3/6] drm/i915: Implement basic Displayport automated testing function for EDID operations

[Todd Previte]

Implements some of the basic EDID tests for Displayport compliance. These tests
include reading the EDID, verifying the checksum and writing the test responses
back to the sink device.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 43fcabe..d060853 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3352,8 +3352,42 @@ intel_dp_autotest_video_pattern(struct intel_dp 
*intel_dp)
 static uint8_t
 intel_dp_autotest_edid(struct intel_dp *intel_dp)
 {
+   struct drm_connector *connector = &intel_dp->attached_connector->base;
+   struct i2c_adapter *adapter = &intel_dp->aux.ddc;
+   struct edid *edid_read = NULL;
+   uint8_t *edid_data = NULL;
uint8_t test_result = DP_TEST_NAK;
-   return test_result;
+   uint32_t i = 0, ret = 0, checksum = 0;
+   struct drm_display_mode *use_mode = NULL;
+   dp_compliance_mode comp_mode_type = DP_COMPLIANCE_MODE_PREFERRED;
+   int mode_count = 0;
+
+   edid_read = drm_get_edid(connector, adapter);
+
+   DRM_DEBUG_KMS("Displayport: EDID automated test\n");
+
+   if (edid_read) {
+   test_result = true;
+   edid_data = (uint8_t*) edid_read;
+   // Compute checksum
+   for (i = 0; i < 128; i++)
+   checksum += edid_data[i];
+
+   DRM_DEBUG_KMS("Displayport: EDID test - computed byte sum = 
%02x\n", checksum);
+   // Verify EDID checksum
+   if (checksum % 256 == 0) {
+   /* Write the checksum to EDID checksum register */
+   ret = drm_dp_dpcd_write(&intel_dp->aux, 
DP_TEST_EDID_CHECKSUM, &edid_read->checksum, 1);
+   // Reponse is ACK and and checksum written
+   test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
+   DRM_DEBUG_KMS("Displayport: EDID test - checksum = 
%02x\n", edid_read->checksum);
+   }
+   else {
+   // Invalid checksum, set for failsafe mode
+   comp_mode_type = DP_COMPLIANCE_MODE_FAILSAFE;
+   }
+   }
+return test_result;
 }
 
 /* Displayport compliance testing - PHY pattern testing */
-- 
1.9.1

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

Re: [Intel-gfx] linux-next: Tree for Jun 19 (drm/i915)

[Rafael J. Wysocki]

On Tuesday, June 24, 2014 02:43:02 PM Jani Nikula wrote:
> On Thu, 19 Jun 2014, Randy Dunlap  wrote:
> > On 06/18/14 23:16, Stephen Rothwell wrote:
> >> Hi all,
> >> 
> >> The powerpc allyesconfig is again broken more than usual.
> >> 
> >> Changes since 20140618:
> >> 
> >
> > on i386:
> >
> > CONFIG_ACPI is not enabled.
> >
> >   CC  drivers/gpu/drm/i915/i915_drv.o
> > ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze':
> > ../drivers/gpu/drm/i915/i915_drv.c:547:2: error: implicit declaration of 
> > function 'acpi_target_system_state' [-Werror=implicit-function-declaration]
> > ../drivers/gpu/drm/i915/i915_drv.c:547:36: error: 'ACPI_STATE_S3' 
> > undeclared (first use in this function)
> > ../drivers/gpu/drm/i915/i915_drv.c:547:36: note: each undeclared identifier 
> > is reported only once for each function it appears in
> >   CC  net/dccp/qpolicy.o
> > cc1: some warnings being treated as errors
> > make[5]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1
> 
> Thanks for the report, we'll fix it.
> 
> Can anyone explain why include/linux/acpi_bus.h has #ifdef
> CONFIG_ACPI_SLEEP and conditional build for a dummy inline version of
> acpi_target_system_state(), *but* that does not get included or used if
> CONFIG_ACPI=n? Additionally, the combination of CONFIG_ACPI=y and
> CONFIG_ACPI_SLEEP=n does not seem to work at all.

These two things look like bugs to me.  Most likely not tested thoruoughly
enough.

> So we'll really have to sprinkle #ifdef CONFIG_ACPI all over, instead of
> neatly using the dummy versions that someone has gone through the
> trouble of adding?

No, we don't have to.

Rafael

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

[Intel-gfx] [PATCH] drm/i915: Don't try to look up object for non-existent fb

[Matt Roper]

crtc->primary->fb may be NULL upon entry to intel_pipe_set_base() if the
primary plane has previously been disabled via the universal plane
interface.  We need to check for NULL before trying to reference
old_fb's obj.

This fixes a regression introduced in

commit a071fa00647bc9a3c53f917b236fff9aea175e3a
Author: Daniel Vetter 
Date:   Wed Jun 18 23:28:09 2014 +0200

drm/i915: Introduce accurate frontbuffer tracking

Testcase: igt/kms_universal_plane
Cc: Daniel Vetter 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fa77557..539ac3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2690,6 +2690,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
enum pipe pipe = intel_crtc->pipe;
struct drm_framebuffer *old_fb;
struct drm_i915_gem_object *obj = to_intel_framebuffer(fb)->obj;
+   struct drm_i915_gem_object *old_obj;
int ret;
 
if (intel_crtc_has_pending_flip(crtc)) {
@@ -2711,11 +2712,12 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
}
 
old_fb = crtc->primary->fb;
+   old_obj = old_fb ? to_intel_framebuffer(old_fb)->obj : NULL;
 
mutex_lock(&dev->struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret == 0)
-   i915_gem_track_fb(to_intel_framebuffer(old_fb)->obj, obj,
+   i915_gem_track_fb(old_obj, obj,
  INTEL_FRONTBUFFER_PRIMARY(pipe));
mutex_unlock(&dev->struct_mutex);
if (ret != 0) {
-- 
1.8.5.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't BUG_ON in i915_gem_obj_offset

[Ben Widawsky]

On Wed, Jun 18, 2014 at 12:04:46AM +0200, Daniel Vetter wrote:
> On Tue, Jun 17, 2014 at 10:34:38PM +0200, Daniel Vetter wrote:
> > A WARN_ON is perfectly fine.
> > 
> > The BUG in here seems to be the cause behind hard-hangs when I cat the
> > i915_gem_pageflip debugfs file (which calls this from an irq
> > spinlock). But only while running a full igt run after a while. I
> > still need to root cause the underlying issue.
> > 
> > I'll also start reject patches which add new BUG_ON but don't come
> > with a really good justification for it. The general rule really
> > should be to just WARN and hope the driver survives for long enough.
> > 
> > Signed-off-by: Daniel Vetter 
> 
> Both patches merged, this one improved per Chris' suggestions on irc.
> -Daniel
> 

Hey, here's an idea. How about we root cause bugs instead of making
blanket statements about the validity of real assertions? If the callers
of ggtt_offset are calling it on unbound objects, it's a violation of
the design. And in the other cases, it's a real bug.

I'd NAK this patch if it wasn't already merged, and my NAK meant
something.

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't BUG_ON in i915_gem_obj_offset

[Dave Airlie]

On 25 June 2014 11:30, Ben Widawsky  wrote:
> On Wed, Jun 18, 2014 at 12:04:46AM +0200, Daniel Vetter wrote:
>> On Tue, Jun 17, 2014 at 10:34:38PM +0200, Daniel Vetter wrote:
>> > A WARN_ON is perfectly fine.
>> >
>> > The BUG in here seems to be the cause behind hard-hangs when I cat the
>> > i915_gem_pageflip debugfs file (which calls this from an irq
>> > spinlock). But only while running a full igt run after a while. I
>> > still need to root cause the underlying issue.
>> >
>> > I'll also start reject patches which add new BUG_ON but don't come
>> > with a really good justification for it. The general rule really
>> > should be to just WARN and hope the driver survives for long enough.
>> >
>> > Signed-off-by: Daniel Vetter 
>>
>> Both patches merged, this one improved per Chris' suggestions on irc.
>> -Daniel
>>
>
> Hey, here's an idea. How about we root cause bugs instead of making
> blanket statements about the validity of real assertions? If the callers
> of ggtt_offset are calling it on unbound objects, it's a violation of
> the design. And in the other cases, it's a real bug.
>
> I'd NAK this patch if it wasn't already merged, and my NAK meant
> something.
>

Its kinda hard to debug an assert if it takes the whole box down, and you
never see the assert printed anywhere. Any why should the whole
kernel die because the GPU driver stuffed up.

Maybe you confused this with userspace.

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

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

On 2014/6/24 10:59, Zhenyu Wang wrote:

On 2014.06.19 17:53:51 +0800, Tiejun Chen wrote:

Originally the reason to probe ISA bridge instead of Dev31:Fun0
is to make graphics device passthrough work easy for VMM, that
only need to expose ISA bridge to let driver know the real
hardware underneath. This is a requirement from virtualization
team. Especially in that virtualized environments, XEN, there
is irrelevant ISA bridge in the system with that legacy qemu
version specific to xen, qemu-xen-traditional. So to work
reliably, we should scan through all the ISA bridge devices
and check for the first match, instead of only checking the
first one.

But actually, qemu-xen-traditional, is always enumerated with
Dev31:Fun0, 00:1f.0 as follows:

hw/pt-graphics.c:

intel_pch_init()
 |
 + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);

so this mean that isa bridge is still represented with Dev31:Func0
like the native OS. Furthermore, currently we're pushing VGA
passthrough support into qemu upstream, and with some discussion,
we wouldn't set the bridge class type and just expose this devfn.

So we just go back to check devfn to make life normal.

Signed-off-by: Tiejun Chen 


This was added historically when supporting graphics device passthrough.
Looks qemu upstream can't accept multiple ISA bridge and our PCH is always
on device 31: func0 as far as I know. Looks good to me.

Reviewed-by: Zhenyu Wang 



Thanks for your review.

Do you know when this can be applied?

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't BUG_ON in i915_gem_obj_offset

[Ben Widawsky]

On Wed, Jun 25, 2014 at 12:00:35PM +1000, Dave Airlie wrote:
> On 25 June 2014 11:30, Ben Widawsky  wrote:
> > On Wed, Jun 18, 2014 at 12:04:46AM +0200, Daniel Vetter wrote:
> >> On Tue, Jun 17, 2014 at 10:34:38PM +0200, Daniel Vetter wrote:
> >> > A WARN_ON is perfectly fine.
> >> >
> >> > The BUG in here seems to be the cause behind hard-hangs when I cat the
> >> > i915_gem_pageflip debugfs file (which calls this from an irq
> >> > spinlock). But only while running a full igt run after a while. I
> >> > still need to root cause the underlying issue.
> >> >
> >> > I'll also start reject patches which add new BUG_ON but don't come
> >> > with a really good justification for it. The general rule really
> >> > should be to just WARN and hope the driver survives for long enough.
> >> >
> >> > Signed-off-by: Daniel Vetter 
> >>
> >> Both patches merged, this one improved per Chris' suggestions on irc.
> >> -Daniel
> >>
> >
> > Hey, here's an idea. How about we root cause bugs instead of making
> > blanket statements about the validity of real assertions? If the callers
> > of ggtt_offset are calling it on unbound objects, it's a violation of
> > the design. And in the other cases, it's a real bug.
> >
> > I'd NAK this patch if it wasn't already merged, and my NAK meant
> > something.
> >
> 
> Its kinda hard to debug an assert if it takes the whole box down, and you
> never see the assert printed anywhere. Any why should the whole
> kernel die because the GPU driver stuffed up.
> 
> Maybe you confused this with userspace.
> 
> Dave.

I shouldn't have said this. I was really pissed off that our PPGTT code
(which was relatively stable with some missing corner cases on merge) is
bit-rotting. It's essentially unusable on BDW, and has cost me more than
a week straight. Many of the original checks I had in place are now gone
for what usually appears to be laziness.

I have a very long-going fundamental disagreement with Daniel about
invariants (and apparently you as well). In either event, the snide
sarcasm was inappropriate of me.

So let's please nip this thread in the bud here.

Thanks.

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

[Intel-gfx] [PATCH 2/2] Documentation: drm: describing rotation property for i915

[sonika . jindal]

From: Sagar Kamble 

Cc: damien.lesp...@intel.com
Cc: daniel.vet...@ffwll.ch
Cc: ville.syrj...@linux.intel.com
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Sagar Kamble 
---
 Documentation/DocBook/drm.tmpl | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 3adb6be..3bd8ae8 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2648,7 +2648,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   i915
+   i915
Generic
"Broadcast RGB"
ENUM
@@ -2664,6 +2664,14 @@ void intel_crt_init(struct drm_device *dev)
TBD


+   Plane
+   “rotation”
+   BITMASK
+   { 0, "rotate-0" }, { 2, "rotate-180" }
+   Plane
+   TBD
+   
+   
SDVO-TV
“mode”
ENUM
-- 
1.8.5

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

[Intel-gfx] [PATCH 1/2] Documentation: drm: Removing placeholders for generic drm properties description

[sonika . jindal]

From: Sagar Kamble 

These property descriptions were kept as placeholder. Removing them for 
simplicity.

Cc: damien.lesp...@intel.com
Cc: daniel.vet...@ffwll.ch
Cc: ville.syrj...@linux.intel.com
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Sagar Kamble 
---
 Documentation/DocBook/drm.tmpl | 64 +++---
 1 file changed, 10 insertions(+), 54 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b314a42..3adb6be 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2648,8 +2648,8 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   i915
-   Generic
+   i915
+   Generic
"Broadcast RGB"
ENUM
{ "Automatic", "Full", "Limited 16:235" }
@@ -2664,13 +2664,6 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   Standard name as in DRM
-   Standard type as in DRM
-   Standard value as in DRM
-   Standard Object as in DRM
-   TBD
-   
-   
SDVO-TV
“mode”
ENUM
@@ -2799,8 +2792,8 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   CDV gma-500
-   Generic
+   CDV gma-500
+   Generic
"Broadcast RGB"
ENUM
{ “Full”, “Limited 16:235” }
@@ -2815,15 +2808,8 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   Standard name as in DRM
-   Standard type as in DRM
-   Standard value as in DRM
-   Standard Object as in DRM
-   TBD
-   
-   
-   Poulsbo
-   Generic
+   Poulsbo
+   Generic
“backlight”
RANGE
Min=0, Max=100
@@ -2831,13 +2817,6 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   Standard name as in DRM
-   Standard type as in DRM
-   Standard value as in DRM
-   Standard Object as in DRM
-   TBD
-   
-   
SDVO-TV
“mode”
ENUM
@@ -3064,7 +3043,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   i2c/ch7006_drv
+   i2c/ch7006_drv
Generic
“scale”
RANGE
@@ -3073,14 +3052,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   TV
-   Standard names as in DRM
-   Standard types as in DRM
-   Standard Values as in DRM
-   Standard object as in DRM
-   TBD
-   
-   
+   TV
“mode”
ENUM
{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
@@ -3089,7 +3061,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   nouveau
+   nouveau
NV10 Overlay
"colorkey"
RANGE
@@ -3198,14 +3170,6 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   Generic
-   Standard name as in DRM
-   Standard type as in DRM
-   Standard value as in DRM
-   Standard Object as in DRM
-   TBD
-   
-   
omap
Generic
“rotation”
@@ -3236,7 +3200,7 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   radeon
+   radeon
DVI-I
“coherent”
RANGE
@@ -3308,14 +3272,6 @@ void intel_crt_init(struct drm_device *dev)
TBD


-   Generic
-   Standard name as in DRM
-   Standard type as in DRM
-   Standard value as in DRM
-   Standard Object as in DRM
-   TBD
-   
-   
rcar-du
Generic
"alpha"
-- 
1.8.5

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

Re: [Intel-gfx] [PATCH 11/11] tests/kms_rotation_crc: IGT for 180 degree HW rotation

[Jindal, Sonika]

On 6/18/2014 5:09 PM, Chris Wilson wrote:

On Wed, Jun 18, 2014 at 12:32:00PM +0100, Damien Lespiau wrote:

On Wed, Jun 18, 2014 at 02:27:27PM +0530, sonika.jin...@intel.com wrote:

From: Sonika Jindal 

Testcase for 180 degree HW rotation

Cc: sagar.a.kam...@intel.com

Signed-off-by: Sonika Jindal 


The test looks good to me (I haven't checked in details, the bar for igt
is quite a bit lower). It shows two gaps in the igt kms API:

   - Retrieving the primary plane (there's a series from Matt fixing this
 and exposing the primary plane through igt_output_get_plane())
   - Adding a set_property() convenience function
 (ala igt_plane_set_property("rotation", BIT(DRM_ROTATE_180)))
 (no-one is working on that just yet, can de done later)

A small question before pushing this, have you checked that the test
correctly skips when running with a kernel without rotation support?


Note: don't push userspace using new ABI until that ABI has been
agreed upon and committed to the kernel.
-Chris


Hi Chris,
Are you referring to igt kms APIs? In this igt we are not using any API 
which is not merged.

-Sonika

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

Re: [Intel-gfx] [PATCH 11/11] tests/kms_rotation_crc: IGT for 180 degree HW rotation

[Chris Wilson]

On Wed, Jun 25, 2014 at 11:24:27AM +0530, Jindal, Sonika wrote:
> 
> 
> On 6/18/2014 5:09 PM, Chris Wilson wrote:
> >On Wed, Jun 18, 2014 at 12:32:00PM +0100, Damien Lespiau wrote:
> >>On Wed, Jun 18, 2014 at 02:27:27PM +0530, sonika.jin...@intel.com wrote:
> >>>From: Sonika Jindal 
> >>>
> >>>Testcase for 180 degree HW rotation
> >>>
> >>>Cc: sagar.a.kam...@intel.com
> >>>
> >>>Signed-off-by: Sonika Jindal 
> >>
> >>The test looks good to me (I haven't checked in details, the bar for igt
> >>is quite a bit lower). It shows two gaps in the igt kms API:
> >>
> >>   - Retrieving the primary plane (there's a series from Matt fixing this
> >> and exposing the primary plane through igt_output_get_plane())
> >>   - Adding a set_property() convenience function
> >> (ala igt_plane_set_property("rotation", BIT(DRM_ROTATE_180)))
> >> (no-one is working on that just yet, can de done later)
> >>
> >>A small question before pushing this, have you checked that the test
> >>correctly skips when running with a kernel without rotation support?
> >
> >Note: don't push userspace using new ABI until that ABI has been
> >agreed upon and committed to the kernel.
> >-Chris
> >
> Hi Chris,
> Are you referring to igt kms APIs? In this igt we are not using any
> API which is not merged.

API also includes property names. If you are happy that everything is
upstream, then it cannot change and is ready to be used. Otherwise we
just end up with broken tests.
-Chris

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

Re: [Intel-gfx] [PATCH 11/11] tests/kms_rotation_crc: IGT for 180 degree HW rotation

[Jindal, Sonika]

On 6/25/2014 11:27 AM, Chris Wilson wrote:

On Wed, Jun 25, 2014 at 11:24:27AM +0530, Jindal, Sonika wrote:



On 6/18/2014 5:09 PM, Chris Wilson wrote:

On Wed, Jun 18, 2014 at 12:32:00PM +0100, Damien Lespiau wrote:

On Wed, Jun 18, 2014 at 02:27:27PM +0530, sonika.jin...@intel.com wrote:

From: Sonika Jindal 

Testcase for 180 degree HW rotation

Cc: sagar.a.kam...@intel.com

Signed-off-by: Sonika Jindal 


The test looks good to me (I haven't checked in details, the bar for igt
is quite a bit lower). It shows two gaps in the igt kms API:

   - Retrieving the primary plane (there's a series from Matt fixing this
 and exposing the primary plane through igt_output_get_plane())
   - Adding a set_property() convenience function
 (ala igt_plane_set_property("rotation", BIT(DRM_ROTATE_180)))
 (no-one is working on that just yet, can de done later)

A small question before pushing this, have you checked that the test
correctly skips when running with a kernel without rotation support?


Note: don't push userspace using new ABI until that ABI has been
agreed upon and committed to the kernel.
-Chris


Hi Chris,
Are you referring to igt kms APIs? In this igt we are not using any
API which is not merged.


API also includes property names. If you are happy that everything is
upstream, then it cannot change and is ready to be used. Otherwise we
just end up with broken tests.
-Chris

Ok, got it. This test will not be merged unless the rotation patches and 
the documentation is merged.

-Sonika

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

[Intel-gfx] [v2] drm/i915: vlv_prepare_pll is only needed in case of non DSI interfaces

[Shobhit Kumar]

For MIPI, DSI PLL is configured separately in vlv_configure_dsi_pll
during the DSI enable sequence

Causing WARN dump otherwise in dpio_reads

v2: Add IS_CHERRYVIEW check as suggested by Ville

Signed-off-by: Shobhit Kumar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fa77557..2af7b6f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4629,7 +4629,10 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
if (intel_crtc->active)
return;
 
-   vlv_prepare_pll(intel_crtc);
+   is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
+
+   if (!is_dsi && !IS_CHERRYVIEW(dev))
+   vlv_prepare_pll(intel_crtc);
 
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -4663,8 +4666,6 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
if (encoder->pre_pll_enable)
encoder->pre_pll_enable(encoder);
 
-   is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
-
if (!is_dsi) {
if (IS_CHERRYVIEW(dev))
chv_enable_pll(intel_crtc);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add a delay in Displayport AUX transactions for compliance testing

[Chris Wilson]

On Tue, Jun 24, 2014 at 03:12:50PM -0700, Todd Previte wrote:
> Several compliance tests require that follow-up AUX transactions (after a
> failure or no response) are not resent sooner than 400us later. Add a 400us
> delay to the response time of any failed transaction to account for this.
> 
> Signed-off-by: Todd Previte 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3bd1780..43fcabe 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -561,8 +561,12 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  DP_AUX_CH_CTL_RECEIVE_ERROR);
>  
>   if (status & (DP_AUX_CH_CTL_TIME_OUT_ERROR |
> -   DP_AUX_CH_CTL_RECEIVE_ERROR))
> +   DP_AUX_CH_CTL_RECEIVE_ERROR)) {

I think "required for DP compliance testing" is a little verbose and can
be shortened to "DP requires". If you have a spec reference handy, that
would be useful.

/* 10.2.1: DP requires 400us delay after an error. */
> + /* 400us delay between transactions for 
> errors/timeouts
> +required for DP compliance testing */
> + udelay(400);
>   continue;
> + }
>   if (status & DP_AUX_CH_CTL_DONE)
>   break;

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

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Paolo Bonzini]

Il 22/06/2014 10:25, Chen, Tiejun ha scritto:

In qemu-upstream, as you commented we can't create this as a ISA class
type explicitly.


Note I didn't say that QEMU doesn't like having two ISA bridges.

I commented that the firmware will see two ISA bridges and will try to 
initialize both of them.  It currently doesn't just because it only 
knows of two southbridge PCI IDs, and both of them are old or relatively 
old (PIIX3/4 and ICH9).


But what would happen if you did graphics passthrough on a machine with 
an ICH9 southbridge?  Your code will create the PIIX4 ISA bridge, and 
will create an ICH9 southbridge just to please the i915 driver.  The 
BIOS will recognize the ICH9's vendor/device ids and try to initialize 
it.  It will write to the configuration space to set up PCI PIRQ[A-H] 
routing, for example, which makes no sense since your ICH9 is just a 
dummy device.


Second problem.  Your IGD passthrough code currently works with QEMU's 
PIIX4-based machine.  But what happens if you try to extend it, so that 
it works with QEMU's ICH9-based machine?  That's a more modern machine 
that has a PCIe chipset and hence has its ISA bridge at 00:1f.0.  Now 
you have a conflict.


In other words, if you want IGD passthrough in QEMU, you need a solution 
that is future-proof.



So we compromise by faking this ISA bridge without ISA
class type setting (as I recall you already said this way is slightly
better).


It is only slightly better, but the right solution is to fix the driver. 
 There is absolutely zero reason why a graphics driver should know 
about the vendor/device ids of the PCH.


The right way could be to make QEMU add a vendor-specific capability to 
the video device. The driver can probe for that capability before 
looking at the PCI bus.  QEMU can add the capability to the list, it is 
easy because all accesses to the video device's configuration space trap 
to QEMU.  Then you do not need to add fake devices to the machine.


In fact, it would be nice if Intel added such a capability on the next 
generation of integrated graphics, too.  On real hardware, ACPI or some 
other kind of firmware can probe the PCH at 00:1f.0 and initialize that 
vendor-specific capability.  QEMU would just forward the value from the 
host, so that virtualized guests never depend on the PCH at 00:1f.0.


Paolo


Maybe we will figure better way in the future. But anyway, this
is always registered as 00:15.0, right? So I think the i915 driver can
go back to probe the devfn like the native environment.


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