[Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable

2013-10-24 Thread Chuansheng Liu 

In our platform, we hit the the stolen region initialization failure case,
such as below log:
[drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: 
[0x7b00]

And it causes the dev_priv-mm.stolen_base is NULL, in this case, we should
avoid accessing it any more.

Here is possible call trace:
intel_enable_gt_powersave -- 
valleyview_enable_rps -- 
valleyview_setup_pctx

Cc: Li Fei fei...@intel.com
Signed-off-by: Liu, Chuansheng chuansheng@intel.com
---
 drivers/gpu/drm/i915/intel_pm.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 26c2ea3..1069b24 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,9 @@ static void valleyview_setup_pctx(struct drm_device *dev)
u32 pcbr;
int pctx_size = 24*1024;
 
+   if (!dev_priv-mm.stolen_base)
+   return;
+
pcbr = I915_READ(VLV_PCBR);
if (pcbr) {
/* BIOS set it up already, grab the pre-alloc'd space */
-- 
1.7.9.5



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

Re: [Intel-gfx] HPD flood warning since b8f102e8b

2013-10-24 Thread Jiri Kosina 
On Mon, 21 Oct 2013, Egbert Eich wrote:

   On Thu, 3 Oct 2013, Daniel Vetter wrote:
   
Can you please attach full dmesg from boot up to the first WARN with
drm.debug=0xe? This really shouldn't happen and indicates a bug
somewhere ...
   
   A bit difficult ... I originally thought that it was reliably 
   reproducible, but now I didn't get it after 10 suspend/resume cycles. Will 
   keep following it, and once it appears, will send you the dmesg.
   
 Could you check if you get any messages regarding HPD storms after 
 suspend/resume ie messages like:
 [drm] HPD interrupt storm detected on connector HDMI-A-1
 but without the annouing warn messages?

I have this:

[357128.184113] [drm] HPD interrupt storm detected on connector DP-3: switching 
from hotplug detection to polling

It appeared in the log approximately 5 seconds after resume has been 
completed.

Thanks,

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

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

2013-10-24 Thread Aaron Lu 
On 10/16/2013 07:33 AM, Rafael J. Wysocki wrote:
 On Friday, October 11, 2013 09:27:42 PM Aaron Lu wrote:
 v5:
 1 Introduce video.use_native_backlight module parameter and set its
   value to false by default as suggested by Rafael. For Win8 systems
   which have broken ACPI video backlight control, the parameter can be
   set to 1 in kernel cmdline to skip registering ACPI video's backlight
   interface. Due to this change, the acpi_video_verify_backlight_support
   is moved from video_detect.c to video.c - patch 3/4;
 2 Rename bd_list_head and bd_list_mutex in backlight.c to
   backlight_dev_list and backlight_dev_list_mutex as suggested by Rafael
   - patch 1/4.

 v4:
 Remove decleration and stub for acpi_video_unregister_backlight in
 video.h of patch 2/4 since that function doesn't exist anymore in v3.

 v3:
 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module;
 2 Remove unnecessary function acpi_video_unregister_backlight introduced
   in patch 2/4 as pointed out by Jani Nikula.

 v2:
 v1 has the subject of Rework ACPI video driver and is posted here:
 http://lkml.org/lkml/2013/9/9/74
 Since the objective is really to fix Win8 backlight issues, I changed
 the subject in this version, sorry about that.

 This patchset has four patches, the first introduced a new API named
 backlight_device_registered in backlight layer that can be used for
 backlight interface provider module to check if a specific type backlight
 interface has been registered, see changelog for patch 1/4 for details.
 Then patch 2/4 does the cleanup to sepeate the backlight control and
 event delivery functionality in the ACPI video module and patch 3/4
 solves some Win8 backlight control problems by avoiding register ACPI
 video's backlight interface if:
 1 Kernel cmdline option acpi_backlight=video is not given;
 2 This is a Win8 system;
 3 Native backlight control interface exists.
 Patch 4/4 fixes some problems in thinkpad-acpi module.

 Technically, patch 2/4 is not required to fix the issue here. So if you
 think it is not necessary, I can remove it from the series.

 Aaron Lu (4):
   backlight: introduce backlight_device_registered
   ACPI / video: seperate backlight control and event interface
   ACPI / video: Do not register backlight if win8 and native interface
 exists
   thinkpad-acpi: fix handle locate for video and query of _BCL

  drivers/acpi/internal.h  |   4 +-
  drivers/acpi/video.c | 457 
 ---
  drivers/acpi/video_detect.c  |   4 +-
  drivers/platform/x86/thinkpad_acpi.c |  31 ++-
  drivers/video/backlight/backlight.c  |  31 +++
  include/linux/backlight.h|   4 +
  6 files changed, 326 insertions(+), 205 deletions(-)
 
 I've added this series to my queue for 3.13.
 
 Since the next step will be to introduce a list of systems that need
 video.use_native_backlight=1 *and* don't break in that configuration, I don't
 see much point adding another Kconfig option for the default.
 
 Hopefully, in the future we'll be able to fix the problems causing
 video.use_native_backlight=1 to fail of the systems where it fails and then
 we'll be able to make that the default behavior and drop the option 
 altogether.

I've prepared a patch(at the end of the mail) to set use_native_backlight
by default for some systems. There are 3 systems currently that I'm
kind of sure that should be added:

The ThinkPad T430s and X230 is:
Reported-by: Theodore Tso ty...@mit.edu
Reported-and-tested-by: Peter Weber b...@ttyhoney.com
Reported-by: Igor Gnatenko i.gnatenko.br...@gmail.com
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231

The Lenovo Yoga is:
Reported-by: Lennart Poettering lenn...@poettering.net
Reference: https://lkml.org/lkml/2013/10/13/178

From: Aaron Lu aaron...@intel.com
Subject: [PATCH] ACPI / video: Add systems that should favor native backlight
 interface

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

Reported-by: Theodore Tso ty...@mit.edu
Reported-and-tested-by: Peter Weber b...@ttyhoney.com
Reported-by: Lennart Poettering lenn...@poettering.net
Reported-by: Igor Gnatenko i.gnatenko.br...@gmail.com
Signed-off-by: Aaron Lu aaron...@intel.com
---
 drivers/acpi/video.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index d020df5..9a80a94 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -412,6 +412,12 @@ static int video_ignore_initial_backlight(const struct 
dmi_system_id *d)
return 0;
 }
 
+static int __init video_set_use_native_backlight(const struct dmi_system_id *d)
+{
+   use_native_backlight = true;
+

[Intel-gfx] [QA] Testing report for `drm-intel-testing` (was: Updated -next) on ww43

2013-10-24 Thread Yang, Guang A 
Summary
We covered the platform: Baytrail-M, Haswell mobile, HSW desktop, HSW ULT, 
IvyBridge, SandyBridge, IronLake.
In this circle, 10 new bugs are filed, 35 bugs are still opened, no WONTFIX 
bugs, 2 NOTABUG bugs, 1 NOTOURBUG bugs, 1 Duplicated bugs, no REOPENED bugs, 4 
bugs are fixed, 4 bugs are closed.



Test Environment

Kernel: (drm-intel-testing)d1b2b826f0969182f055d11c991f90fdc6a4924a

Some additional commit info:

Merge: d9a1100 14c8d11

Author: Daniel Vetter daniel.vet...@ffwll.ch

Date:   Fri Oct 18 16:04:02 2013 +0200

Finding

New Bugs:   10 bugs

Bug 70795https://bugs.freedesktop.org/show_bug.cgi?id=70795 - [HSW 
mobile]System hung while resuming from S3

Bug 70794https://bugs.freedesktop.org/show_bug.cgi?id=70794 - [HSW]s3 fail 
and call trace

Bug 70791https://bugs.freedesktop.org/show_bug.cgi?id=70791 - [HSW ULT]eDP 
brightness is zero after the computer start

Bug 70788https://bugs.freedesktop.org/show_bug.cgi?id=70788 - 
igt/kms_cursor_crc/cursor-white-visible-offscreen fails

Bug 70787https://bugs.freedesktop.org/show_bug.cgi?id=70787 - 
igt/kms_flip/nonexisting-fb fail

Bug 70598https://bugs.freedesktop.org/show_bug.cgi?id=70598 - 
[PNV/945]igt/gen3_mixed_blits randomly causes [drm:i915_report_and_clear_eir] 
*ERROR* EIR stuck: 0x0010, masking

Bug 70573https://bugs.freedesktop.org/show_bug.cgi?id=70573 - [BYT]S3 failed 
to suspend

Bug 70570https://bugs.freedesktop.org/show_bug.cgi?id=70570 - 
[BYT]igt/kms_flip/wf_vblank-vs-modeset cause WARNING: CPU: 0 PID: 3716 at 
drivers/gpu/drm/i915/intel_dp.c:2653 intel_dp_link_down+0x5b/0x18d [i915]()

Bug 70558https://bugs.freedesktop.org/show_bug.cgi?id=70558 - 
[BYT]igt/gem_suspend/fence-restore-tiled2untiled test failed

Bug 70523https://bugs.freedesktop.org/show_bug.cgi?id=70523 - [ NFO: 
possible circular locking dependency detected ] when running module_reload



Opened Bugs:   35 bugs

Bug 70334https://bugs.freedesktop.org/show_bug.cgi?id=70334 - 
[bisected]igt/module_reload causes system hang on queued branch

Bug 69868https://bugs.freedesktop.org/show_bug.cgi?id=69868 - 
[Bisected]igt/kms_render/gpu_blit aborted

Bug 69838https://bugs.freedesktop.org/show_bug.cgi?id=69838 - [HSW 
ULT]igt/pc8 skipped

Bug 69784https://bugs.freedesktop.org/show_bug.cgi?id=69784 - 
[HSW]igt/gem_tiled_swapping randomly causes OOM killer

Bug 69747https://bugs.freedesktop.org/show_bug.cgi?id=69747 - [HSW 
ULT]igt/kms_flip/flip-vs-panning-vs-hang-interruptible causes 
[drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt

Bug 69693https://bugs.freedesktop.org/show_bug.cgi?id=69693 - 
[BYT]igt/kms_flip causes [drm:intel_dp_complete_link_train] *ERROR* failed to 
train DP, aborting

Bug 69247https://bugs.freedesktop.org/show_bug.cgi?id=69247 - 
[ILK/SNB]igt/gem_evict_everything/forked-swapping-multifd-mempressure-normal 
causes OOM killer

Bug 69161https://bugs.freedesktop.org/show_bug.cgi?id=69161 - 
igt/kms_flip/2x-flip-vs-absolute-wf_vblank fail with 2-pipe

Bug 69130https://bugs.freedesktop.org/show_bug.cgi?id=69130 - 
[Baytrail-M]I-G-T/kms_flip subtest：'flip_rcs-flip-vs-panning' fail

Bug 69128https://bugs.freedesktop.org/show_bug.cgi?id=69128 - [IVB Apple 
MacBook pro] miniDP-to-DP cause machine boot up with ERROR

Bug 69012https://bugs.freedesktop.org/show_bug.cgi?id=69012 - 
[Bisected]igt/kms_flip/flip-vs-absolute-wf_vblank fails

Bug 68643https://bugs.freedesktop.org/show_bug.cgi?id=68643 - [SNB DP]Some 
modes can't light up

Bug 68640https://bugs.freedesktop.org/show_bug.cgi?id=68640 - [HSW 
nv]igt/prime_nv_pcopy/test3_1 timeout with debug kernel

Bug 68638https://bugs.freedesktop.org/show_bug.cgi?id=68638 - [HSW 
nv]igt/prime_nv_test/i915_import_cpu_mmap fails with debug kernel

Bug 68004https://bugs.freedesktop.org/show_bug.cgi?id=68004 - 
igt/prime_self_import/with_one_bo_two_files aborted

Bug 67891https://bugs.freedesktop.org/show_bug.cgi?id=67891 - 
igt/prime_self_import/export-vs-gem_close-race fail and causes call trace

Bug 67813https://bugs.freedesktop.org/show_bug.cgi?id=67813 - [HSW 
bisected]igt/module_reload causes [drm:hsw_unclaimed_reg_check] *ERROR* 
Unclaimed write to 44004 and system hang with headless, with power well disabled

Bug 67462https://bugs.freedesktop.org/show_bug.cgi?id=67462 - [SNB] Call 
trace appears after system boots with DP

Bug 67243https://bugs.freedesktop.org/show_bug.cgi?id=67243 - 
[ILK]igt/kms_render/gpu-blit randomly causes system hang

Bug 67030https://bugs.freedesktop.org/show_bug.cgi?id=67030 - [HSW] no modes 
bigger than 1080p in the parsed EDID for 4k TV on both HDMI/VGA

Bug 67027https://bugs.freedesktop.org/show_bug.cgi?id=67027 - [HSW] some 
modes oversan, on a 4K HDMI TV

Bug 65995https://bugs.freedesktop.org/show_bug.cgi?id=65995 - [HSW mobile] 
eDP can't light up when boot up

Bug 65927https://bugs.freedesktop.org/show_bug.cgi?id=65927 - [HSW] crash 
when vga output set to mirror mode

Bug 65700https://bugs.freedesktop.org/show_bug.cgi?id=65700 -

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add more dev ops for MIPI sub encoder

2013-10-24 Thread Jani Nikula 
On Thu, 24 Oct 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
 On 10/23/2013 07:52 PM, Jani Nikula wrote:
 So I think let's keep trying to find the right abstractions to separate
 the DSI core and the panel drivers, make it possible to support several
 panels with one driver, and make it possible to have independent drivers
 for panels that don't fit the assumptions of the generic panel driver.

 Does that conflict with your goals? Are we in agreement here?

 Definetely we are in agreement and perfectly aligns with my goals.

That's relieving, I'm happy we're on the same page now. :)

 But is it okay to work towards pushing sub-encoder based design for
 immidiate short term and then work to convert on drm_bridge because I
 can see that drm_bridge callbacks will need additions defintely and it
 might take some time to get that done. In the meantime can we push
 current driver with already suggested changes to get atleast a working
 base ?

I'm okay with this. Daniel is pushing for drm_bridge, and I'm also
optimistic about that, but perhaps we have to see what we really need
first. The current sub-encoder model is more flexible for that in the
short term.

However I, and others, will need to know where we are heading, so please
do pay attention to splitting up the patches and explaining why they are
needed. Sometimes it's helpful to provide draft/RFC patches on top just
for that.

Finally, I am glad you're contributing directly to upstream now. It
makes a huge difference in the long run.


BR,
Jani.


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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: set HDMI pixel clock in audio configuration

2013-10-24 Thread Jasper Smet 
Although i know it also happens in windows, the one particular thing i am
'fiddling' with is that when i try the receiver with an nvidia or amd apu
(ion, e-450 trough hdmi) with my pioneer receiver audio works fine with
44100hz at the 1080p@50/60 modes. Only with intel i need to force
upstreaming to 48000hz.

So are we really sure this is a bug with the receiver or still something
wrong with the driver / pixel clock issue?

Is there anything else we i do to help ?


On Wed, Oct 16, 2013 at 11:34 AM, Jani Nikula jani.nik...@intel.com wrote:

 The HDMI audio expects HDMI pixel clock to be set in the audio
 configuration. We've currently just set 0, using 25.2 / 1.001 kHz
 frequency, which fails with some modes.

 v2: Now with a commit message.

 Reference:
 http://mid.gmane.org/cagpeb3ep1lrzetpxhgrfbdqr5ts2tac8gcukwwuguf1u5ny...@mail.gmail.com
 Reference: http://mid.gmane.org/20130206213533.ga16...@hardeman.nu
 Reported-by: David Härdeman da...@hardeman.nu
 Reported-by: Jasper Smet josb...@gmail.com
 Tested-by: Jasper Smet josb...@gmail.com
 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h  |   12 -
  drivers/gpu/drm/i915/intel_display.c |   48
 +++---
  2 files changed, 55 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h
 index 13153c3..3266819 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -4875,7 +4875,17 @@
  #define   AUD_CONFIG_LOWER_N_SHIFT 4
  #define   AUD_CONFIG_LOWER_N_VALUE (0xfff  4)
  #define   AUD_CONFIG_PIXEL_CLOCK_HDMI_SHIFT16
 -#define   AUD_CONFIG_PIXEL_CLOCK_HDMI  (0xf  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK (0xf  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_25175(0  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_25200(1  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_27000(2  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_27027(3  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_54000(4  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_54054(5  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_74176(6  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_74250(7  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_148352   (8  16)
 +#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_148500   (9  16)
  #define   AUD_CONFIG_DISABLE_NCTS  (1  3)

  /* HSW Audio */
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 55740f2..a097f84 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -6722,6 +6722,44 @@ static int intel_crtc_mode_set(struct drm_crtc
 *crtc,
 return 0;
  }

 +static struct {
 +   int clock;
 +   u32 config;
 +} hdmi_audio_clock[] = {
 +   { DIV_ROUND_UP(25200 * 1000, 1001),
 AUD_CONFIG_PIXEL_CLOCK_HDMI_25175 },
 +   { 25200, AUD_CONFIG_PIXEL_CLOCK_HDMI_25200 }, /* default per bspec
 */
 +   { 27000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27000 },
 +   { 27000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27027 },
 +   { 54000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54000 },
 +   { 54000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54054 },
 +   { DIV_ROUND_UP(74250 * 1000, 1001),
 AUD_CONFIG_PIXEL_CLOCK_HDMI_74176 },
 +   { 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
 +   { DIV_ROUND_UP(148500 * 1000, 1001),
 AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 },
 +   { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
 +};
 +
 +/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
 +static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
 +{
 +   int i;
 +
 +   for (i = 0; i  ARRAY_SIZE(hdmi_audio_clock); i++) {
 +   if (mode-clock == hdmi_audio_clock[i].clock)
 +   break;
 +   }
 +
 +   if (i == ARRAY_SIZE(hdmi_audio_clock)) {
 +   DRM_DEBUG_KMS(HDMI audio pixel clock setting for %d not
 found, falling back to defaults\n, mode-clock);
 +   i = 1;
 +   }
 +
 +   DRM_DEBUG_KMS(Configuring HDMI audio for pixel clock %d
 (0x%08x)\n,
 + hdmi_audio_clock[i].clock,
 + hdmi_audio_clock[i].config);
 +
 +   return hdmi_audio_clock[i].config;
 +}
 +
  static bool intel_eld_uptodate(struct drm_connector *connector,
int reg_eldv, uint32_t bits_eldv,
int reg_elda, uint32_t bits_elda,
 @@ -6847,8 +6885,9 @@ static void haswell_write_eld(struct drm_connector
 *connector,
 DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
 eld[5] |= (1  2); /* Conn_Type, 0x1 = DisplayPort */
 I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 =
 DP */
 -   } else
 -   I915_WRITE(aud_config, 0);
 +   } else {
 +   I915_WRITE(aud_config,
 audio_config_hdmi_pixel_clock(mode));
 +   }

 if

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add more dev ops for MIPI sub encoder

2013-10-24 Thread Shobhit Kumar 

On 10/24/2013 01:54 PM, Jani Nikula wrote:

On Thu, 24 Oct 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:

On 10/23/2013 07:52 PM, Jani Nikula wrote:

So I think let's keep trying to find the right abstractions to separate
the DSI core and the panel drivers, make it possible to support several
panels with one driver, and make it possible to have independent drivers
for panels that don't fit the assumptions of the generic panel driver.

Does that conflict with your goals? Are we in agreement here?


Definetely we are in agreement and perfectly aligns with my goals.


That's relieving, I'm happy we're on the same page now. :)


Me too :)




But is it okay to work towards pushing sub-encoder based design for
immidiate short term and then work to convert on drm_bridge because I
can see that drm_bridge callbacks will need additions defintely and it
might take some time to get that done. In the meantime can we push
current driver with already suggested changes to get atleast a working
base ?


I'm okay with this. Daniel is pushing for drm_bridge, and I'm also
optimistic about that, but perhaps we have to see what we really need
first. The current sub-encoder model is more flexible for that in the
short term.

However I, and others, will need to know where we are heading, so please
do pay attention to splitting up the patches and explaining why they are
needed. Sometimes it's helpful to provide draft/RFC patches on top just
for that.


I will push updated smaller patches with clear reasoning for them.



Finally, I am glad you're contributing directly to upstream now. It
makes a huge difference in the long run.



Yeah, I wanted to do earlier but sometimes its all matter of bandwidth 
and priorities. Hopefully I will be able to continue to do so, now that 
I have started.


Thanks for all your inputs.

Regards
Shobhit


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

Re: [Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable

2013-10-24 Thread Chris Wilson 
On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote:
 
 In our platform, we hit the the stolen region initialization failure case,
 such as below log:
 [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: 
 [0x7b00]
 
 And it causes the dev_priv-mm.stolen_base is NULL, in this case, we should
 avoid accessing it any more.
 
 Here is possible call trace:
 intel_enable_gt_powersave -- 
 valleyview_enable_rps -- 
 valleyview_setup_pctx

The two create_stolen routines are no-ops in that case so all that
happens instead is that we read VLV_PCBR. However, really if
i915_gem_object_create_stolen_for_preallocated() fails we should abort
loading the driver as it means we have a hardware conflict and undefined
behaviour.
-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] HPD flood warning since b8f102e8b

2013-10-24 Thread Jiri Kosina 
On Thu, 24 Oct 2013, Jiri Kosina wrote:

 I have this:
 
 [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: 
 switching from hotplug detection to polling
 
 It appeared in the log approximately 5 seconds after resume has been 
 completed.

Okay, and it just happened during resume from RAM (it was a very long 
series of repeating the same trace, I am putting here just the last 
portion):

[362634.813953] [ cut here ]
[362634.813980] WARNING: CPU: 0 PID: 666 at 
drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]()
[362634.813981] Received HPD interrupt although disabled
[362634.814021] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun 
iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter 
ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep 
cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt 
iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage 
snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm 
cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi 
lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e 
soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 
uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_helper drm i2c_algo_bit video 
button edd fan processor ata_generic thermal thermal_sys
[362634.814028] CPU: 0 PID: 666 Comm: rs:main Q:Reg Tainted: GW
3.12.0-rc4-6-g162bdaf-dirty #1
[362634.814029] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 
12/19/2008
[362634.814033]  03e9 88007c203d18 81583863 
88007c203d58
[362634.814035]  8104d297 88007c203d98 0010 
0002
[362634.814038]  88003718 0005 88003718 
88007c203db8
[362634.814039] Call Trace:
[362634.814044]  IRQ  [81583863] dump_stack+0x7a/0x97
[362634.814048]  [8104d297] warn_slowpath_common+0x87/0xb0
[362634.814051]  [8104d361] warn_slowpath_fmt+0x41/0x50
[362634.814067]  [a00c7be2] i965_irq_handler+0x492/0x680 [i915]
[362634.814072]  [810a41bc] handle_irq_event_percpu+0xac/0x220
[362634.814074]  [810a4379] handle_irq_event+0x49/0x70
[362634.814077]  [810a7bef] handle_edge_irq+0x7f/0x150
[362634.814080]  [81004a89] handle_irq+0x59/0x150
[362634.814083]  [81052b06] ? irq_enter+0x16/0x90
[362634.814085]  [8100403b] do_IRQ+0x5b/0xe0
[362634.814089]  [81589def] common_interrupt+0x6f/0x6f
[362634.814093]  EOI  [810bc850] ? lock_acquire+0x110/0x130
[362634.814096]  [8158dae0] ? notifier_call_chain+0xa0/0xa0
[362634.814098]  [8158db4a] __atomic_notifier_call_chain+0x6a/0xc0
[362634.814101]  [8158dae0] ? notifier_call_chain+0xa0/0xa0
[362634.814103]  [8158dbb1] atomic_notifier_call_chain+0x11/0x20
[362634.814106]  [813b607f] do_con_write+0x22f/0xa10
[362634.814109]  [81585e6f] ? mutex_lock_nested+0x2ef/0x370
[362634.814111]  [810bb2bd] ? trace_hardirqs_on_caller+0x13d/0x1e0
[362634.814115]  [8139df7d] ? process_output_block+0x3d/0x1e0
[362634.814118]  [813b68b9] con_write+0x19/0x30
[362634.814120]  [8139e010] process_output_block+0xd0/0x1e0
[362634.814123]  [8139ee0b] n_tty_write+0x18b/0x370
[362634.814126]  [810834a0] ? try_to_wake_up+0x240/0x240
[362634.814129]  [8139c67c] do_tty_write+0xbc/0x200
[362634.814131]  [8139ec80] ? n_tty_ioctl+0x110/0x110
[362634.814134]  [8139c884] tty_write+0xc4/0xf0
[362634.814137]  [81190bf7] vfs_write+0xe7/0x190
[362634.814139]  [81191560] SyS_write+0x60/0xb0
[362634.814142]  [81591fa2] system_call_fastpath+0x16/0x1b
[362634.814144] ---[ end trace f54ed427593b8ca0 ]---
[362634.894446] [ cut here ]
[362634.894476] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:1001 
i965_irq_handler+0x492/0x680 [i915]()
[362634.894479] Received HPD interrupt although disabled
[362634.894481] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun 
iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter 
ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep 
cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt 
iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage 
snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm 
cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi 
lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e 
soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 
uhci_hcd ehci_hcd usbcore usb_common

Re: [Intel-gfx] gem_render_copy

2013-10-24 Thread Damien Lespiau 
On Wed, Oct 23, 2013 at 04:05:11PM +0100, Damien Lespiau wrote:
 A few moons ago, Chris suggested to create a small, standalone, render copy
 test to add aub file support and help enabling new platforms instead of
 hijacking gem_render_linear_blits.
 
 So here it is.

A whole day without comment, pushed :)

As always, shout if needed.

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

Re: [Intel-gfx] [PATCH] drm/i915: Sanitize the PPT fdi lane bifurcate state on ivb

2013-10-24 Thread Daniel Vetter 
On Wed, Oct 23, 2013 at 12:58 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
 I'm thinking the crtc-base.enabled check is actually pointless.
 AFAICS we should never get here with crtc-base.enabled==false and
 crtc-active==true

Hm yeah. I was kinda shooting for the minimal thing here.

 We anyway re-enable the bifurcation bit when we do the mode_set.
 Actually that in itself could be a maybe a bug. We'd turn off the
 bifurcation bit when both pipes B and C are disabled based on
 prepare_pipes, but we only do the mode_set based on modeset_pipes.
 But currently we are saved by the fact that those two bitmasks are
 the same.

The current logic (after this patch) is to
- always clear the bit when both pipes are off.
- always set if if we either enable pipe B or C and we'd need it to
allow the other pipe to be lit up. If pipe B uses 4 lanes then we
can't light pipe C up anymore, so we don't set the bit.

There is a potential issue though with all pipes disabled with dpms
off now. I think conceptually I need to precompute the desired state
of the bifurcate bit in the compute config stage and then only set it
here.

 Another potential bug I found is that we always set the bifurcation
 bit in mode_set, even if we're not using FDI. So if we have eg.
 pipe B enabled w/ FDI using 4 lanes, and then we enable pipe C w/ EDP,
 we'd still flip the bifurcation bit in pipe C's mode_set and destroy pipe
 B's output. The fix would be to call ivybridge_update_fdi_bc_bifurcation()
 only when has_pch_encoder==true.

has_pch_encoder should only be true if we have fdi_lanes  0. So we
shouldn't actually enable this stuff (and iirc I've tested the edp on
pipe C with pipe B using 4 lanes). The actual configuration checks all
happen in the pipe configuration computation stage. I'll rework the
patch a bit (but that'll take a while).

Thanks for the review,
Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] HPD flood warning since b8f102e8b

2013-10-24 Thread Egbert Eich 
Jiri Kosina writes:
  On Mon, 21 Oct 2013, Egbert Eich wrote:
  
 On Thu, 3 Oct 2013, Daniel Vetter wrote:
 
  Can you please attach full dmesg from boot up to the first WARN with
  drm.debug=0xe? This really shouldn't happen and indicates a bug
  somewhere ...
 
 A bit difficult ... I originally thought that it was reliably 
 reproducible, but now I didn't get it after 10 suspend/resume cycles. 
   Will 
 keep following it, and once it appears, will send you the dmesg.
 
   Could you check if you get any messages regarding HPD storms after 
   suspend/resume ie messages like:
   [drm] HPD interrupt storm detected on connector HDMI-A-1
   but without the annouing warn messages?
  
  I have this:
  
  [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: 
  switching from hotplug detection to polling
  
  It appeared in the log approximately 5 seconds after resume has been 
  completed.
  

:( You seem to get this on different connector.

Any chance for a 'lspci -n' output?

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

Re: [Intel-gfx] HPD flood warning since b8f102e8b

2013-10-24 Thread Jiri Kosina 
On Thu, 24 Oct 2013, Egbert Eich wrote:

   Can you please attach full dmesg from boot up to the first WARN with
   drm.debug=0xe? This really shouldn't happen and indicates a bug
   somewhere ...
  
  A bit difficult ... I originally thought that it was reliably 
  reproducible, but now I didn't get it after 10 suspend/resume cycles. 
 Will 
  keep following it, and once it appears, will send you the dmesg.
  
Could you check if you get any messages regarding HPD storms after 
suspend/resume ie messages like:
[drm] HPD interrupt storm detected on connector HDMI-A-1
but without the annouing warn messages?
   
   I have this:
   
   [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: 
 switching from hotplug detection to polling
   
   It appeared in the log approximately 5 seconds after resume has been 
   completed.
   
 
 :( You seem to get this on different connector.
 
 Any chance for a 'lspci -n' output?

00:00.0 0600: 8086:2a40 (rev 07)
00:02.0 0300: 8086:2a42 (rev 07)
00:02.1 0380: 8086:2a43 (rev 07)
00:03.0 0780: 8086:2a44 (rev 07)
00:03.2 0101: 8086:2a46 (rev 07)
00:03.3 0700: 8086:2a47 (rev 07)
00:19.0 0200: 8086:10f5 (rev 03)
00:1a.0 0c03: 8086:2937 (rev 03)
00:1a.1 0c03: 8086:2938 (rev 03)
00:1a.2 0c03: 8086:2939 (rev 03)
00:1a.7 0c03: 8086:293c (rev 03)
00:1b.0 0403: 8086:293e (rev 03)
00:1c.0 0604: 8086:2940 (rev 03)
00:1c.1 0604: 8086:2942 (rev 03)
00:1c.3 0604: 8086:2946 (rev 03)
00:1d.0 0c03: 8086:2934 (rev 03)
00:1d.1 0c03: 8086:2935 (rev 03)
00:1d.2 0c03: 8086:2936 (rev 03)
00:1d.7 0c03: 8086:293a (rev 03)
00:1e.0 0604: 8086:2448 (rev 93)
00:1f.0 0601: 8086:2917 (rev 03)
00:1f.2 0106: 8086:2929 (rev 03)
00:1f.3 0c05: 8086:2930 (rev 03)
03:00.0 0280: 8086:4237

I (and the computer in question) am in Edinburgh till friday, in case 
someone wants to have a look.

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

[Intel-gfx] Using render nodes in i-g-t

2013-10-24 Thread Damien Lespiau 
Hi,

This small series add the possibility for a test to ask for a render device.
This allows us to run render tests as a regular users.

-- 
Damien

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

[Intel-gfx] [PATCH 3/5] lib: Add a drm_open_any_render() that will try to use render nodes

2013-10-24 Thread Damien Lespiau 
I was fedup with having to run my tests as root and not being able to
use my usual setup for tests that only exercise the GT part of the GPU.

Render nodes to the rescue!

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 lib/drmtest.c | 58 ++
 lib/drmtest.h |  1 +
 2 files changed, 59 insertions(+)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 3b80920..8164ef9 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -222,6 +222,35 @@ static int __drm_open_any(void)
return fd;
 }
 
+static int __drm_open_any_render(void)
+{
+   char *name;
+   int i, fd;
+
+   for (i = 128; i  (128 + 16); i++) {
+   int ret;
+
+   ret = asprintf(name, /dev/dri/renderD%u, i);
+   igt_assert(ret != -1);
+
+   fd = open(name, O_RDWR);
+   free(name);
+
+   if (fd == -1)
+   continue;
+
+   if (!is_intel(fd)) {
+   close(fd);
+   fd = -1;
+   continue;
+   }
+
+   return fd;
+   }
+
+   return fd;
+}
+
 static void quiescent_gpu_at_exit(int sig)
 {
int fd;
@@ -233,6 +262,17 @@ static void quiescent_gpu_at_exit(int sig)
}
 }
 
+static void quiescent_gpu_at_exit_render(int sig)
+{
+   int fd;
+
+   fd = __drm_open_any_render();
+   if (fd = 0) {
+   gem_quiescent_gpu(fd);
+   close(fd);
+   }
+}
+
 int drm_open_any(void)
 {
static int open_count;
@@ -249,6 +289,24 @@ int drm_open_any(void)
return fd;
 }
 
+int drm_open_any_render(void)
+{
+   static int open_count;
+   int fd = __drm_open_any_render();
+
+   /* no render nodes, fallback to drm_open_any() */
+   if (fd == -1)
+   return drm_open_any();
+
+   if (__sync_fetch_and_add(open_count, 1))
+   return fd;
+
+   gem_quiescent_gpu(fd);
+   igt_install_exit_handler(quiescent_gpu_at_exit_render);
+
+   return fd;
+}
+
 int __gem_set_tiling(int fd, uint32_t handle, int tiling, int stride)
 {
struct drm_i915_gem_set_tiling st;
diff --git a/lib/drmtest.h b/lib/drmtest.h
index 609e7d8..f5e2708 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -50,6 +50,7 @@ drm_intel_bo * gem_handle_to_libdrm_bo(drm_intel_bufmgr 
*bufmgr, int fd,
 
 int drm_get_card(void);
 int drm_open_any(void);
+int drm_open_any_render(void);
 
 void gem_quiescent_gpu(int fd);
 
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 4/5] tests/gem_render_copy: Use render nodes

2013-10-24 Thread Damien Lespiau 
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 tests/gem_render_copy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c
index 40c37f4..e481733 100644
--- a/tests/gem_render_copy.c
+++ b/tests/gem_render_copy.c
@@ -104,7 +104,7 @@ int main(int argc, char **argv)
}
 
igt_fixture {
-   data.drm_fd = drm_open_any();
+   data.drm_fd = drm_open_any_render();
data.devid = intel_get_drm_devid(data.drm_fd);
 
data.bufmgr = drm_intel_bufmgr_gem_init(data.drm_fd, 4096);
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 5/5] tests: Convert the ctx test to use render nodes when possible

2013-10-24 Thread Damien Lespiau 
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 tests/gem_ctx_bad_destroy.c | 2 +-
 tests/gem_ctx_bad_exec.c| 2 +-
 tests/gem_ctx_basic.c   | 4 ++--
 tests/gem_ctx_create.c  | 2 +-
 tests/gem_ctx_exec.c| 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/gem_ctx_bad_destroy.c b/tests/gem_ctx_bad_destroy.c
index 7852618..e93642f 100644
--- a/tests/gem_ctx_bad_destroy.c
+++ b/tests/gem_ctx_bad_destroy.c
@@ -62,7 +62,7 @@ int main(int argc, char *argv[])
 
igt_skip_on_simulation();
 
-   fd = drm_open_any();
+   fd = drm_open_any_render();
 
ctx_id = gem_context_create(fd);
 
diff --git a/tests/gem_ctx_bad_exec.c b/tests/gem_ctx_bad_exec.c
index dadd663..c60e693 100644
--- a/tests/gem_ctx_bad_exec.c
+++ b/tests/gem_ctx_bad_exec.c
@@ -91,7 +91,7 @@ int main(int argc, char *argv[])
igt_subtest_init(argc, argv);
 
igt_fixture {
-   fd = drm_open_any();
+   fd = drm_open_any_render();
 
ctx_id = gem_context_create(fd);
 
diff --git a/tests/gem_ctx_basic.c b/tests/gem_ctx_basic.c
index 47f4b4b..bc21a8a 100644
--- a/tests/gem_ctx_basic.c
+++ b/tests/gem_ctx_basic.c
@@ -64,7 +64,7 @@ static void *work(void *arg)
int i;
 
if (multiple_fds)
-   td_fd = fd = drm_open_any();
+   td_fd = fd = drm_open_any_render();
else
td_fd = fd;
 
@@ -133,7 +133,7 @@ int main(int argc, char *argv[])
 {
int i;
 
-   fd = drm_open_any();
+   fd = drm_open_any_render();
devid = intel_get_drm_devid(fd);
 
if (igt_run_in_simulation()) {
diff --git a/tests/gem_ctx_create.c b/tests/gem_ctx_create.c
index f22522b..1d9ff86 100644
--- a/tests/gem_ctx_create.c
+++ b/tests/gem_ctx_create.c
@@ -47,7 +47,7 @@ int main(int argc, char *argv[])
create.ctx_id = rand();
create.pad = rand();
 
-   fd = drm_open_any();
+   fd = drm_open_any_render();
 
ret = drmIoctl(fd, CONTEXT_CREATE_IOCTL, create);
if (ret != 0  (errno == ENODEV || errno == EINVAL)) {
diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c
index 5f2c59f..620a944 100644
--- a/tests/gem_ctx_exec.c
+++ b/tests/gem_ctx_exec.c
@@ -102,7 +102,7 @@ int main(int argc, char *argv[])
 
igt_skip_on_simulation();
 
-   fd = drm_open_any();
+   fd = drm_open_any_render();
 
ctx_id = gem_context_create(fd);
handle = gem_create(fd, 4096);
-- 
1.8.3.1

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

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

2013-10-24 Thread Daniel Vetter 
Hi Dave,

drm-intel-next-2013-10-18:
- CRC support from Damien and He Shuang. Long term this should allow us to
  test an awful lot modesetting corner cases automatically. So for me as
  the maintainer this is really big.
- HDMI audio fix from Jani.
- VLV dpll computation code refactoring from Ville.
- Fixups for the gpu booster from last time around (Chris).
- Some cleanups in the context code from Ben.
- More watermark work from Ville (we'll be getting there ...).
- vblank timestamp improvements from Ville.
- CONFIG_FB=n support, including drm core changes to make the fbdev
  helpers optional.
- DP link training improvements (Jani).
- mmio vtable from Ben, prep work for future hw.

There shouldn't be a conflict with drm-next (but I haven't done an
explicit test-merge). But there's quite a bit of fun with -fixes going on.
Maybe we need some backmerge ...

Cheers, Daniel


The following changes since commit 967ad7f1489da7babbe0746f81c283458ecd3f84:

  Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next
(2013-10-10 12:44:43 +0200)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-10-18

for you to fetch changes up to 6da7f10d296f4ac625f96b39eef22c41398727e3:

  drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp
(2013-10-18 16:00:06 +0200)


Artem Bityutskiy (1):
  drm/i915: preserve dispaly init order on ByT

Ben Widawsky (12):
  drm/i915: Use the real cpu max frequency for ring scaling
  drm/i915: Prevent using uninitialized MMIO funcs
  drm/i915: Move edram detection early_sanitize
  drm/i915: Create MMIO virtual functions
  drm/i915: Extract common MMIO lines
  drm/i915: Create GEN specific read MMIO
  drm/i915: Create GEN specific write MMIO
  drm/i915: Remove gen specific checks in MMIO
  drm/i915: Do PCH and uncore init earlier
  drm/i915: Do a fuller init after reset
  drm/i915: cleanup context fini
  drm/i915: Replace has_bsd/blt/vebox with a mask

Chon Ming Lee (1):
  drm/i915: Move some hdmi enable function name to vlv specific.

Chris Wilson (7):
  drm/i915: Call io_schedule() whilst whilsting for the GPU
  drm/i915: Fix type mismatch and accounting in i915_gem_shrink
  drm/i915: Undo the PIPEA quirk for i845
  drm/i915: Capture the initial error-state when kicking stuck rings
  drm/i915: Avoid tweaking RPS before it is enabled
  drm/i915: Add breadcrumbs for why the backlight is being set
  drm/i915: Disable all GEM timers and work on unload

Damien Lespiau (16):
  drm/i915: Remove yet another unused define
  drm/i915: Keep the CRC values into a circular buffer
  drm/i915: Sample the frame counter instead of a timestamp for CRCs
  drm/i915: Make switching to the same CRC source a no-op
  drm/i915: Enforce going back to none before changing CRC source
  drm/i915: Empty the circular buffer when asked for a new source
  drm/i915: Dynamically allocate the CRC circular buffer
  drm/i915: Generalize the CRC command format for future work
  drm/i915: Rename i915_pipe_crc_ctl to i915_display_crc_ctl
  drm/i915: Warn if we receive an interrupt after freeing the buffer
  drm/i915: Add log messages when CRCs collection is started/stopped
  drm/i915: Move drm_add_fake_info_node() higher in the file
  drm/i915: Implement blocking read for pipe CRC files
  drm/i915: Only one open() allowed on pipe CRC result files
  drm/i915: Enable pipe CRCs
  drm/i915: Use pipe_name() instead of the pipe number

Daniel Vetter (24):
  drm/i915: check that the i965g/gm 4G limit is really obeyed
  drm/i915: rip out gen2 reset code
  drm/i915: Keep intel_drv.h tidy
  drm/i915: Educate users in dmesg about reporting gpu hangs
  drm: Add separate Kconfig option for fbdev helpers
  drm/i915: Kconfig option to disable the legacy fbdev support
  drm/i915: rename intel_fb.c to intel_fbdev.c
  drm/i915: Add a control file for pipe CRCs
  drm/i915: static inline for dummy crc functions
  drm/i915: constify harder
  drm/i915: grab dev-struct_mutex around framebuffer_init
  drm/i915: prevent tiling changes on framebuffer backing storage
  drm/i915: Use unsigned long for obj-user_pin_count
  drm/i915: check gem bo size when creating framebuffers
  cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n
  drm/i915: don't Oops in debugfs for I915_FBDEV=n
  drm/i915: extract display_pipe_crc_update
  drm/i915: add CRC #defines for ilk/snb
  drm/i915: wire up CRC interrupt for ilk/snb
  drm/i915: use -get_vblank_counter for the crc frame counter
  drm/i915: wait one vblank when disabling CRCs
  drm/i915: fix CRC debugfs setup
  drm/i915: crc support for hsw
  drm/i915: remove dead code in ironlake_crtc_mode_set

Imre Deak (1):

[Intel-gfx] [PATCH 1/4] drm/i915: Remove WaFbcDisableDpfcClockGating on IVB

2013-10-24 Thread Ben Widawsky 
Production IVB does not need it. I confirmed this with Art.

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/intel_pm.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d4dd543..33ad028 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -254,12 +254,6 @@ static void ironlake_disable_fbc(struct drm_device *dev)
dpfc_ctl = ~DPFC_CTL_EN;
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
 
-   if (IS_IVYBRIDGE(dev))
-   /* WaFbcDisableDpfcClockGating:ivb */
-   I915_WRITE(ILK_DSPCLK_GATE_D,
-  I915_READ(ILK_DSPCLK_GATE_D) 
-  ~ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
-
if (IS_HASWELL(dev))
/* WaFbcDisableDpfcClockGating:hsw */
I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
@@ -295,10 +289,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, 
unsigned long interval)
if (IS_IVYBRIDGE(dev)) {
/* WaFbcAsynchFlipDisableFbcQueue:ivb */
I915_WRITE(ILK_DISPLAY_CHICKEN1, ILK_FBCQ_DIS);
-   /* WaFbcDisableDpfcClockGating:ivb */
-   I915_WRITE(ILK_DSPCLK_GATE_D,
-  I915_READ(ILK_DSPCLK_GATE_D) |
-  ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
} else {
/* WaFbcAsynchFlipDisableFbcQueue:hsw */
I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc-pipe),
-- 
1.8.4.1

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

[Intel-gfx] [PATCH 2/4] drm/i915: Remove WaFbcDisableDpfcClockGating on HSW

2013-10-24 Thread Ben Widawsky 
Production HSW does not need it. I confirmed this with Art.

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/i915_reg.h |  3 ---
 drivers/gpu/drm/i915/intel_pm.c | 10 --
 2 files changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6c98238..6799d53 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1110,9 +1110,6 @@
 _HSW_PIPE_SLICE_CHICKEN_1_A, + \
 _HSW_PIPE_SLICE_CHICKEN_1_B)
 
-#define HSW_CLKGATE_DISABLE_PART_1 0x46500
-#define   HSW_DPFC_GATING_DISABLE  (123)
-
 /*
  * GPIO regs
  */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 33ad028..686699c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -254,12 +254,6 @@ static void ironlake_disable_fbc(struct drm_device *dev)
dpfc_ctl = ~DPFC_CTL_EN;
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
 
-   if (IS_HASWELL(dev))
-   /* WaFbcDisableDpfcClockGating:hsw */
-   I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
-  I915_READ(HSW_CLKGATE_DISABLE_PART_1) 
-  ~HSW_DPFC_GATING_DISABLE);
-
DRM_DEBUG_KMS(disabled FBC\n);
}
 }
@@ -293,10 +287,6 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, 
unsigned long interval)
/* WaFbcAsynchFlipDisableFbcQueue:hsw */
I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc-pipe),
   HSW_BYPASS_FBC_QUEUE);
-   /* WaFbcDisableDpfcClockGating:hsw */
-   I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
-  I915_READ(HSW_CLKGATE_DISABLE_PART_1) |
-  HSW_DPFC_GATING_DISABLE);
}
 
I915_WRITE(SNB_DPFC_CTL_SA,
-- 
1.8.4.1

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

[Intel-gfx] [PATCH 3/4] drm/i915: WaFbcDisableDpfcrClockGating only with fbc

2013-10-24 Thread Ben Widawsky 
We were turning this on for ILK regardless of whether or not we use FBC.
We can save the slightest amount of power if we don't disable it when
not using FBC.

The workaround should be bit 8 for ILK. Notice it is 1 bit difference
from SNB. This is actually DPFCR unit as we've defined it.

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/intel_pm.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 686699c..bbcf100 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -238,6 +238,11 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc, 
unsigned long interval)
   SNB_CPU_FENCE_ENABLE | obj-fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
sandybridge_blit_fbc_update(dev);
+   } else {
+   /* WaFbcDisableDpfcClockGating:ilk */
+   I915_WRITE(ILK_DSPCLK_GATE_D,
+  I915_READ(ILK_DSPCLK_GATE_D) |
+  ILK_DPFCRUNIT_CLOCK_GATE_DISABLE);
}
 
DRM_DEBUG_KMS(enabled fbc on plane %c\n, 
plane_name(intel_crtc-plane));
@@ -254,6 +259,12 @@ static void ironlake_disable_fbc(struct drm_device *dev)
dpfc_ctl = ~DPFC_CTL_EN;
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
 
+   if (IS_GEN5(dev))
+   /* WaFbcDisableDpfcClockGating:ilk */
+   I915_WRITE(ILK_DSPCLK_GATE_D,
+  I915_READ(ILK_DSPCLK_GATE_D) 
+  ~ILK_DPFCRUNIT_CLOCK_GATE_DISABLE);
+
DRM_DEBUG_KMS(disabled FBC\n);
}
 }
@@ -4932,9 +4943,9 @@ static void ironlake_init_clock_gating(struct drm_device 
*dev)
 
/*
 * Required for FBC
-* WaFbcDisableDpfcClockGating:ilk
+* WaFbcDisableDpfcClockGating:snb
 */
-   dspclk_gate |= ILK_DPFCRUNIT_CLOCK_GATE_DISABLE |
+   dspclk_gate |=
   ILK_DPFCUNIT_CLOCK_GATE_DISABLE |
   ILK_DPFDUNIT_CLOCK_GATE_ENABLE;
 
-- 
1.8.4.1

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

[Intel-gfx] [PATCH 4/4] drm/i915: WaFbcDisableDpfcClockGating only with fbc

2013-10-24 Thread Ben Widawsky 
We were turning this on for SNB regardless of whether or not we use FBC.
We can save the slightest amount of power if we don't disable it when
not using FBC.

The workaround should be bit 9 for SNB.

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/intel_pm.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bbcf100..4ebbe65 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -237,6 +237,12 @@ static void ironlake_enable_fbc(struct drm_crtc *crtc, 
unsigned long interval)
I915_WRITE(SNB_DPFC_CTL_SA,
   SNB_CPU_FENCE_ENABLE | obj-fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
+
+   /* WaFbcDisableDpfcClockGating:snb */
+   I915_WRITE(ILK_DSPCLK_GATE_D,
+  I915_READ(ILK_DSPCLK_GATE_D) |
+  ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
+
sandybridge_blit_fbc_update(dev);
} else {
/* WaFbcDisableDpfcClockGating:ilk */
@@ -259,7 +265,12 @@ static void ironlake_disable_fbc(struct drm_device *dev)
dpfc_ctl = ~DPFC_CTL_EN;
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
 
-   if (IS_GEN5(dev))
+   if (IS_GEN6(dev))
+   /* WaFbcDisableDpfcClockGating:snb */
+   I915_WRITE(ILK_DSPCLK_GATE_D,
+  I915_READ(ILK_DSPCLK_GATE_D) 
+  ~ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
+   else if (IS_GEN5(dev))
/* WaFbcDisableDpfcClockGating:ilk */
I915_WRITE(ILK_DSPCLK_GATE_D,
   I915_READ(ILK_DSPCLK_GATE_D) 
@@ -4939,15 +4950,9 @@ static void g4x_disable_trickle_feed(struct drm_device 
*dev)
 static void ironlake_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
-   uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
-
-   /*
-* Required for FBC
-* WaFbcDisableDpfcClockGating:snb
-*/
-   dspclk_gate |=
-  ILK_DPFCUNIT_CLOCK_GATE_DISABLE |
-  ILK_DPFDUNIT_CLOCK_GATE_ENABLE;
+   uint32_t dspclk_gate =
+   ILK_VRHUNIT_CLOCK_GATE_DISABLE |
+   ILK_DPFDUNIT_CLOCK_GATE_ENABLE;
 
I915_WRITE(PCH_3DCGDIS0,
   MARIUNIT_CLOCK_GATE_DISABLE |
-- 
1.8.4.1

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

[Intel-gfx] [PATCH] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication

2013-10-24 Thread Rodrigo Vivi 
If Userspace isn't using MI_PREDICATE all slices must be enabled for
backward compatibility.

If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will 
force
all slices on.

v2: fix the inverted logic for backwards compatibility
USE_PREDICATE unset force gt_full when defaul is half
instead of GT_FULL flag.

v3: Accepting Chris's suggestions: better variable names;
better logic around state_default x legacy_userspace_busy;
remove unecessary mutex;

v4: Accepting more suggestions from Chris:
* Send all LRIs in only one block and don't ignore if it fails.
* function name and cleaner code on forcing_full.

CC: Chris Wilson ch...@chris-wilson.co.uk
CC: Eric Anholt e...@anholt.net
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
 drivers/gpu/drm/i915/i915_drv.h|  8 
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 63 ++
 drivers/gpu/drm/i915/i915_reg.h| 11 ++
 drivers/gpu/drm/i915/i915_sysfs.c  |  3 ++
 drivers/gpu/drm/i915/intel_display.c   |  5 +++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_pm.c| 45 -
 include/uapi/drm/i915_drm.h|  8 +++-
 8 files changed, 141 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 685fb1d..67bbbce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1219,6 +1219,12 @@ struct i915_package_c8 {
} regsave;
 };
 
+struct i915_gt_slices {
+   int state_default;
+   int legacy_userspace_busy;
+   struct mutex lock; /* locks access to this scruct and slice registers */
+};
+
 typedef struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1418,6 +1424,8 @@ typedef struct drm_i915_private {
 
struct i915_package_c8 pc8;
 
+   struct i915_gt_slices gt_slices;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
 * here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ce0d47..7a362a2 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -922,6 +922,62 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
return 0;
 }
 
+static int gt_legacy_userspace_busy(struct intel_ring_buffer *ring)
+{
+   int ret;
+
+   ret = intel_ring_begin(ring, 18);
+   if (ret)
+   return ret;
+
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, HSW_GT_SLICE_INFO);
+   intel_ring_emit(ring, SLICE_SEL_BOTH);
+
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, MI_PREDICATE_RESULT_2);
+   intel_ring_emit(ring, LOWER_SLICE_ENABLED);
+
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, HSW_SLICESHUTDOWN);
+   intel_ring_emit(ring, ~SLICE_SHUTDOWN);
+
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+   intel_ring_emit(ring, CS_IDLE_COUNT_1US);
+
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, WAIT_FOR_RC6_EXIT);
+   intel_ring_emit(ring, _MASKED_BIT_ENABLE(WAIT_RC6_EXIT));
+
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+   intel_ring_emit(ring, CS_IDLE_COUNT_5US);
+
+   intel_ring_advance(ring);
+   return 0;
+}
+
+static bool gt_legacy_userspace(struct intel_ring_buffer *ring,
+   struct drm_i915_gem_execbuffer2 *args)
+{
+   drm_i915_private_t *dev_priv = ring-dev-dev_private;
+
+   if (ring-id == BCS)
+   return false;
+
+   if (!HAS_SLICE_SHUTDOWN(ring-dev))
+   return false;
+
+   if (dev_priv-gt_slices.state_default == 1)
+   return false;
+
+   if (dev_priv-gt_slices.legacy_userspace_busy)
+   return false;
+
+   return (args-flags  I915_EXEC_USE_PREDICATE) == 0;
+}
+
 static int
 i915_gem_do_execbuffer(struct drm_device *dev, void *data,
   struct drm_file *file,
@@ -999,6 +1055,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
}
 
+   if (gt_legacy_userspace(ring, args)) {
+   ret = gt_legacy_userspace_busy(ring);
+   if (ret)
+   return ret;
+   dev_priv-gt_slices.legacy_userspace_busy = true;
+   }
+
mode = args-flags  I915_EXEC_CONSTANTS_MASK;
mask = I915_EXEC_CONSTANTS_MASK;
switch (mode) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 497c441..0146bef 100644
---

Re: [Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable

2013-10-24 Thread Ben Widawsky 
On Thu, Oct 24, 2013 at 01:17:06PM +0100, Chris Wilson wrote:
 On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote:
  
  In our platform, we hit the the stolen region initialization failure case,
  such as below log:
  [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: 
  [0x7b00]
  
  And it causes the dev_priv-mm.stolen_base is NULL, in this case, we should
  avoid accessing it any more.
  
  Here is possible call trace:
  intel_enable_gt_powersave -- 
  valleyview_enable_rps -- 
  valleyview_setup_pctx
 
 The two create_stolen routines are no-ops in that case so all that
 happens instead is that we read VLV_PCBR. However, really if
 i915_gem_object_create_stolen_for_preallocated() fails we should abort
 loading the driver as it means we have a hardware conflict and undefined
 behaviour.
 -Chris
 
 -- 
 Chris Wilson, Intel Open Source Technology Centre

I agree. We should start treating these things as errors since no
RPS/RC6 is essentially not what anyone wants.

For another immediate solution it seems you can demote the DRM_ERROR to
DRM_DEBUG_DRIVER, and add a check in valleyview_enable_rps for the pctx
value.

-- 
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 3/5] lib: Add a drm_open_any_render() that will try to use render nodes

2013-10-24 Thread Damien Lespiau 
On Thu, Oct 24, 2013 at 01:43:22PM -0700, Ben Widawsky wrote:
 On Thu, Oct 24, 2013 at 03:40:54PM +0100, Damien Lespiau wrote:
  I was fedup with having to run my tests as root and not being able to
  use my usual setup for tests that only exercise the GT part of the GPU.
  
  Render nodes to the rescue!
 
 I think usually this is a bad idea except for pretty isolated proof of
 concept kind of things. Mostly intel-gpu-tools is testing our kernel
 driver, and therefore running without a reboot anyway is sort of
 unusual.

Hum? I fail to see the link. It should be strickly equivalent, with the
added bonus that you can write and execute a test as a normal user.

Actually, as Daniel said on IRC, we'd most likely want to run quite a
few of the tests with both a fd from card0 and a fd from the render node
to ensure that we can function correctly from the render node 

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

Re: [Intel-gfx] [PATCH 3/5] lib: Add a drm_open_any_render() that will try to use render nodes

2013-10-24 Thread Damien Lespiau 
On Thu, Oct 24, 2013 at 10:01:21PM +0100, Damien Lespiau wrote:
 On Thu, Oct 24, 2013 at 01:43:22PM -0700, Ben Widawsky wrote:
  On Thu, Oct 24, 2013 at 03:40:54PM +0100, Damien Lespiau wrote:
   I was fedup with having to run my tests as root and not being able to
   use my usual setup for tests that only exercise the GT part of the GPU.
   
   Render nodes to the rescue!
  
  I think usually this is a bad idea except for pretty isolated proof of
  concept kind of things. Mostly intel-gpu-tools is testing our kernel
  driver, and therefore running without a reboot anyway is sort of
  unusual.
 
 Hum? I fail to see the link. It should be strickly equivalent, with the
 added bonus that you can write and execute a test as a normal user.

By normal user I mean with a DRM master running and without having to
do the authentification dance.

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

Re: [Intel-gfx] [PATCH igt] module_reload: remove snd_hda_intel

2013-10-24 Thread Ben Widawsky 
On Wed, Oct 23, 2013 at 09:42:06PM +0300, Jani Nikula wrote:
 On Wed, 23 Oct 2013, Paulo Zanoni przan...@gmail.com wrote:
  2013/10/23 Ben Widawsky b...@bwidawsk.net:
  On Mon, Oct 21, 2013 at 11:56:09AM -0200, Paulo Zanoni wrote:
  From: Paulo Zanoni paulo.r.zan...@intel.com
 
  The audio driver uses the power well provided by our driver, so on
  Haswell we can't rmmod i915 if we don't rmmod snd_hda_intel first.
 
  The problem with removing snd_hda_intel is that we also need to kill
  its users. On the specific machine I tested, the only user seem to be
  alsactl, but on other machines this may change. IMHO we should leave
  the kill user space step to whoever is running the script, but
  Daniel asked me to put it here so we have a better chance of Just
  Working on QA's machines.
 
  Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
  ---
   tests/module_reload | 6 ++
   1 file changed, 6 insertions(+)
 
  diff --git a/tests/module_reload b/tests/module_reload
  index 3d8cb85..c1fd395 100755
  --- a/tests/module_reload
  +++ b/tests/module_reload
  @@ -18,6 +18,10 @@ if ! echo 0  /sys/class/vtconsole/vtcon1/bind ; then
exit 77
   fi
 
  +# The sound driver uses our power well
  +pkill alsactl
  +rmmod snd_hda_intel  /dev/null
  +
   #ignore errors in ips - gen5 only
   rmmod intel_ips  /dev/null
   rmmod i915
  @@ -38,6 +42,8 @@ fi
   modprobe i915
   echo 1  /sys/class/vtconsole/vtcon1/bind
 
  +modprobe snd_hda_intel
  +
   # try to run something
   $SOURCE_DIR/gem_exec_nop  /dev/null  echo module successfully loaded 
  again
 
 
  I don't really pretend to understand how module dependencies are
  calculated. However, I would think the dependency should be *somewhere*
  and so modprobe -r i915 should work.
 
  It's the opposite: modprobe -r i915 will remove drm.ko,
  drm_kms_helper, i2c-algo-bit and video, but won't remove snd_hda_intel
  (and if you don't remove it first, it will complain that i915.ko is
  still in use).
 
 
  Don't read that as a nak. Rather, a wtf is with the existing stuff?
 
  I think the dependency is magically tracked by depmod when it sees the
  Audio driver uses a symbol exported by i915.ko. But a modinfo
  snd_hda_intel doesn't show i915.ko on the depends section, which is
  strange. I'm also not an expert on this area...
 
 This is because snd_hda_intel does not depend on i915, to make it
 possible to use snd_hda_intel without i915. Which makes sense. Instead,
 it uses symbol_request() to be able to call a couple of i915 functions
 when available.
 
 I don't know if there's a way to check this runtime dependency from
 userspace. But obviously you can't remove i915 while snd_hda_intel holds
 function pointers to i915. (In fact, intel_ips is the same.)
 
 BR,
 Jani.
 
 
 -- 
 Jani Nikula, Intel Open Source Technology Center

Looking around it seems a fairly common idiom is to do the
symbol_(get|request) when you need to call the function, and release it
when you're no longer using it. Since these functions we're talking
about require waking the GPU, I think speed shouldn't be a concern.

As you say, it makes sense to be able to load audio without i915 -
however looking at the code, it seems like audio will fail if i915 is
not loaded.

Also, it looks like there should be a way to make userspace aware of the
dependency since it calls back in to userspace (I find it funny that the
name of the function uses 4 underscores: call_usermodehelper).


-- 
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] drm/i915: Avoid accessing the stolen address when it is unavailable

2013-10-24 Thread Liu, Chuansheng 
Hello Chris and Ben,

 -Original Message-
 From: Ben Widawsky [mailto:b...@bwidawsk.net]
 Sent: Friday, October 25, 2013 4:57 AM
 To: Chris Wilson; Liu, Chuansheng; daniel.vet...@ffwll.ch; airl...@linux.ie;
 intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
 linux-ker...@vger.kernel.org; Li, Fei
 Subject: Re: [Intel-gfx] drm/i915: Avoid accessing the stolen address when it 
 is
 unavailable
 
 On Thu, Oct 24, 2013 at 01:17:06PM +0100, Chris Wilson wrote:
  On Fri, Oct 25, 2013 at 12:33:47AM +0800, Chuansheng Liu wrote:
  
   In our platform, we hit the the stolen region initialization failure case,
   such as below log:
   [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen
 region: [0x7b00]
  
   And it causes the dev_priv-mm.stolen_base is NULL, in this case, we
 should
   avoid accessing it any more.
  
   Here is possible call trace:
   intel_enable_gt_powersave -- 
   valleyview_enable_rps -- 
   valleyview_setup_pctx
 
  The two create_stolen routines are no-ops in that case so all that
  happens instead is that we read VLV_PCBR. However, really if
  i915_gem_object_create_stolen_for_preallocated() fails we should abort
  loading the driver as it means we have a hardware conflict and undefined
  behaviour.
In case of dev_priv-mm.stolen_base == NULL, and the valleyview_setup_pctx() is 
called
at the first time, it will call 
i915_gem_object_create_stolen_for_preallocated(), which should
should return NULL always due to (!drm_mm_initialized(dev_priv-mm.stolen)).

After that, every time specially when doing pm operation, the above scenario 
will
be called again and again.

Here this patch is to save some time for PM operation, we do not need to read
VLV_PCBR and pcbr_offset calculation in case of stolen_base == NULL.

Is it making sense? Thanks.

 
 I agree. We should start treating these things as errors since no
 RPS/RC6 is essentially not what anyone wants.
 
 DRM_DEBUG_DRIVER, and add a check in valleyview_enable_rps for the pctx
 value.
The pctx is already checked in valleyview_disable_rps().
Do we need more checking in case of pctx == NULL?

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

[Intel-gfx] [PATCH v3] drm/i915/vlv: enable HDA display audio for Valleyview2

2013-10-24 Thread mengdong . lin 
From: Mengdong Lin mengdong@intel.com

This patch defines HD-Audio configuration registers and enables display audio
from HDA controller for Valleyview2.

Signed-off-by: Mengdong Lin mengdong@intel.com
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9538502..2a4c33f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4844,6 +4844,18 @@
CPT_AUD_CNTL_ST_B)
 #define CPT_AUD_CNTRL_ST2  0xE50C0
 
+#define VLV_HDMIW_HDMIEDID_A   (VLV_DISPLAY_BASE + 0x62050)
+#define VLV_HDMIW_HDMIEDID_B   (VLV_DISPLAY_BASE + 0x62150)
+#define VLV_HDMIW_HDMIEDID(pipe) _PIPE(pipe, \
+   VLV_HDMIW_HDMIEDID_A, \
+   VLV_HDMIW_HDMIEDID_B)
+#define VLV_AUD_CNTL_ST_A  (VLV_DISPLAY_BASE + 0x620B4)
+#define VLV_AUD_CNTL_ST_B  (VLV_DISPLAY_BASE + 0x621B4)
+#define VLV_AUD_CNTL_ST(pipe) _PIPE(pipe, \
+   VLV_AUD_CNTL_ST_A, \
+   VLV_AUD_CNTL_ST_B)
+#define VLV_AUD_CNTL_ST2   (VLV_DISPLAY_BASE + 0x620C0)
+
 /* These are the 4 32-bit write offset registers for each stream
  * output buffer.  It determines the offset from the
  * 3DSTATE_SO_BUFFERs that the next streamed vertex output goes to.
@@ -4860,6 +4872,12 @@
 #define CPT_AUD_CFG(pipe) _PIPE(pipe, \
CPT_AUD_CONFIG_A, \
CPT_AUD_CONFIG_B)
+#define VLV_AUD_CONFIG_A   (VLV_DISPLAY_BASE + 0x62000)
+#define VLV_AUD_CONFIG_B   (VLV_DISPLAY_BASE + 0x62100)
+#define VLV_AUD_CFG(pipe) _PIPE(pipe, \
+   VLV_AUD_CONFIG_A, \
+   VLV_AUD_CONFIG_B)
+
 #define   AUD_CONFIG_N_VALUE_INDEX (1  29)
 #define   AUD_CONFIG_N_PROG_ENABLE (1  28)
 #define   AUD_CONFIG_UPPER_N_SHIFT 20
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ebe5d08..25abba96 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6896,6 +6896,11 @@ static void ironlake_write_eld(struct drm_connector 
*connector,
aud_config = IBX_AUD_CFG(pipe);
aud_cntl_st = IBX_AUD_CNTL_ST(pipe);
aud_cntrl_st2 = IBX_AUD_CNTL_ST2;
+   } else if (IS_VALLEYVIEW(connector-dev)) {
+   hdmiw_hdmiedid = VLV_HDMIW_HDMIEDID(pipe);
+   aud_config = VLV_AUD_CFG(pipe);
+   aud_cntl_st = VLV_AUD_CNTL_ST(pipe);
+   aud_cntrl_st2 = VLV_AUD_CNTL_ST2;
} else {
hdmiw_hdmiedid = CPT_HDMIW_HDMIEDID(pipe);
aud_config = CPT_AUD_CFG(pipe);
@@ -6905,8 +6910,19 @@ static void ironlake_write_eld(struct drm_connector 
*connector,
 
DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
 
-   i = I915_READ(aud_cntl_st);
-   i = (i  29)  DIP_PORT_SEL_MASK;  /* DIP_Port_Select, 0x1 
= PortB */
+   if (IS_VALLEYVIEW(connector-dev))  {
+   struct intel_encoder *intel_encoder;
+   int port = 0;
+   intel_encoder = intel_attached_encoder(connector);
+   if (intel_encoder)
+   port = intel_ddi_get_encoder_port(intel_encoder);
+   i = port;
+   } else {
+   i = I915_READ(aud_cntl_st);
+   i = (i  29)  DIP_PORT_SEL_MASK;
+   /* DIP_Port_Select, 0x1 = PortB */
+   }
+
if (!i) {
DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
/* operate blindly on all ports */
@@ -10195,7 +10211,8 @@ static void intel_init_display(struct drm_device *dev)
}
} else if (IS_G4X(dev)) {
dev_priv-display.write_eld = g4x_write_eld;
-   }
+   } else if (IS_VALLEYVIEW(dev))
+   dev_priv-display.write_eld = ironlake_write_eld;
 
/* Default just returns -ENODEV to indicate unsupported */
dev_priv-display.queue_flip = intel_default_queue_flip;
-- 
1.8.1.2

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

[Intel-gfx] [PATCH] drm/i915: Make the vlv_dpio_read/vlv_dpio_write more PHY centric

2013-10-24 Thread Chon Ming Lee 
vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index.  This should better to gather for upcoming platform.

Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h   |   13 +
 drivers/gpu/drm/i915/i915_reg.h   |2 ++
 drivers/gpu/drm/i915/intel_display.c  |   16 
 drivers/gpu/drm/i915/intel_dp.c   |9 -
 drivers/gpu/drm/i915/intel_drv.h  |7 ---
 drivers/gpu/drm/i915/intel_hdmi.c |9 -
 drivers/gpu/drm/i915/intel_sideband.c |   13 ++---
 7 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80957ca..0ccfdc8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -88,6 +88,18 @@ enum port {
 };
 #define port_name(p) ((p) + 'A')
 
+#define I915_NUM_PHYS_VLV 1
+
+enum dpio_channel {
+   DPIO_CH0,
+   DPIO_CH1
+};
+
+enum dpio_phy {
+   DPIO_PHY0,
+   DPIO_PHY1
+};
+
 enum intel_display_power_domain {
POWER_DOMAIN_PIPE_A,
POWER_DOMAIN_PIPE_B,
@@ -1390,6 +1402,7 @@ typedef struct drm_i915_private {
int num_shared_dpll;
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
struct intel_ddi_plls ddi_plls;
+   int vlv_phy[I915_NUM_PHYS_VLV];
 
/* Reclocking support */
bool render_reclock_avail;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2b4f7b1..1fedde9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -447,6 +447,8 @@
 #define DPIO_TX3_SWING_CTL4(pipe) _PIPE(pipe, _DPIO_TX_SWING_CTL4_A, \
_DPIO_TX3_SWING_CTL4_B)
 
+#define DPIO_PHY_PORT(pipe)(dev_priv-vlv_phy[pipe  1])
+
 /*
  * Per pipe/PLL DPIO regs
  */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e79a2a..b401dbf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1361,6 +1361,7 @@ static void intel_init_dpio(struct drm_device *dev)
if (!IS_VALLEYVIEW(dev))
return;
 
+   dev_priv-vlv_phy[DPIO_PHY0] = IOSF_PORT_DPIO;
/*
 * From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx -
 *  6.  De-assert cmn_reset/side_reset. Same as VLV X0.
@@ -1494,18 +1495,25 @@ static void vlv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
 }
 
-void vlv_wait_port_ready(struct drm_i915_private *dev_priv, int port)
+void vlv_wait_port_ready(struct drm_i915_private *dev_priv,
+   struct intel_digital_port *dport)
 {
u32 port_mask;
 
-   if (!port)
+   switch (dport-port) {
+   case PORT_B:
port_mask = DPLL_PORTB_READY_MASK;
-   else
+   break;
+   case PORT_C:
port_mask = DPLL_PORTC_READY_MASK;
+   break;
+   default:
+   BUG();
+   }
 
if (wait_for((I915_READ(DPLL(0))  port_mask) == 0, 1000))
WARN(1, timed out waiting for port %c ready: 0x%08x\n,
-'B' + port, I915_READ(DPLL(0)));
+'B' + dport-port, I915_READ(DPLL(0)));
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 749c605..4e72bc3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1831,7 +1831,7 @@ static void vlv_pre_enable_dp(struct intel_encoder 
*encoder)
struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
-   int port = vlv_dport_to_channel(dport);
+   enum dpio_channel port = vlv_dport_to_channel(dport);
int pipe = intel_crtc-pipe;
struct edp_power_seq power_seq;
u32 val;
@@ -1839,7 +1839,6 @@ static void vlv_pre_enable_dp(struct intel_encoder 
*encoder)
mutex_lock(dev_priv-dpio_lock);
 
val = vlv_dpio_read(dev_priv, pipe, DPIO_DATA_LANE_A(port));
-   val = 0;
if (pipe)
val |= (121);
else
@@ -1858,7 +1857,7 @@ static void vlv_pre_enable_dp(struct intel_encoder 
*encoder)
 
intel_enable_dp(encoder);
 
-   vlv_wait_port_ready(dev_priv, port);
+   vlv_wait_port_ready(dev_priv, dport);
 }
 
 static void vlv_dp_pre_pll_enable(struct intel_encoder *encoder)
@@ -1868,7 +1867,7 @@ static void vlv_dp_pre_pll_enable(struct intel_encoder 
*encoder)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc =
to_intel_crtc(encoder-base.crtc);
-   int port = vlv_dport_to_channel(dport);
+

Re: [Intel-gfx] Patch for crashing intel server

2013-10-24 Thread Bas Wijnen 
On Wed, Oct 23, 2013 at 09:28:28AM +0100, Chris Wilson wrote:
 No worries, if you can run
 
 addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215
 
 that should give me the information needed to pinpoint the crash.

$ addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79
0xf8215
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel.h:138
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/i915_video.c:156
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel_video.c:1584

Note that I'm running the unpatched Debian version again (so not with
your or my patch), which is why it was crashing.

In case you have different sources, here's some context for those lines:

intel.h:138 is
 static inline Bool intel_pixmap_tiled(PixmapPtr pixmap)
 {
return intel_get_pixmap_private(pixmap)-tiling != I915_TILING_NONE;
 }

i915_video.c:156 is
/* front buffer, pitch, offset */
   if (intel_pixmap_tiled(target)) {
tiling = BUF_3D_TILED_SURFACE;

and intel_video.c:1584 is
} else {
   I915DisplayVideoTextured(scrn, adaptor_priv, id, clipBoxes,
width, height, dstPitch, dstPitch2,
src_w, src_h, drw_w, drw_h,
pixmap);
}

Thanks,
Bas


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