Re: [Intel-gfx] [PATCH] [v5] drm/i915/bdw: Only use 2g GGTT for 32b platforms

[Yang, Guang A]

Tested-by: Yang, Guang A guang.a.y...@intel.com
With this patch, the 32 bit system can be able to boot normally.



Best Regards~~

Open Source Technology Center (OTC)
Terence Yang（杨光）
Tel: 86-021-61167360
iNet: 8821-7360

 -Original Message-
 From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
 Ben Widawsky
 Sent: Wednesday, May 28, 2014 7:53 AM
 To: Intel GFX
 Cc: Ben Widawsky; sta...@vger.kernel.org; Widawsky, Benjamin
 Subject: [Intel-gfx] [PATCH] [v5] drm/i915/bdw: Only use 2g GGTT for 32b
 platforms
 
 Daniel requested in the bug that I use a 3GB fallback size. Since this is not 
 in
 the spec as a valid size, I decided against it. We could potentially add a 
 patch to
 bump it to 3GB on top of this one.
 
 This probably should be CC: stable - but I'll let the powers that be decide 
 that
 one.
 
 Regression from a revert of the revert:
 commit 7907f45bf9f67a1c5e5d4ae05bab428d7c2f43b2
 Author: Ben Widawsky benjamin.widaw...@intel.com
 Date:   Wed Feb 19 22:05:46 2014 -0800
 
 Revert drm/i915/bdw: Limit GTT to 2GB
 
 v2: Change ifdef to 32b, instead of ifndef update comment
 
 v3. Update comment to not wrap (Daniel).
 Update commit message
 
 v4: s/CONFIG_32/CONFIG_X86_32 (Jani).
 
 v5: s/CONFIG_x86_32BIT/CONFIG_x86_32, as meant in v4 s/32B/32b (chris)
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76619
 Cc: sta...@vger.kernel.org
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
 b/drivers/gpu/drm/i915/i915_gem_gtt.c
 index 931b906..eec820a 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
 @@ -1775,6 +1775,13 @@ static inline unsigned int
 gen8_get_total_gtt_size(u16 bdw_gmch_ctl)
   bdw_gmch_ctl = BDW_GMCH_GGMS_MASK;
   if (bdw_gmch_ctl)
   bdw_gmch_ctl = 1  bdw_gmch_ctl;
 +
 +#ifdef CONFIG_X86_32
 + /* Limit 32b platforms to a 2GB GGTT: 4  20 / pte size * PAGE_SIZE */
 + if (bdw_gmch_ctl  4)
 + bdw_gmch_ctl = 4;
 +#endif
 +
   return bdw_gmch_ctl  20;
  }
 
 --
 1.9.3
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on bdw

[Daniel Vetter]

On Mon, Jun 02, 2014 at 09:51:27PM +, O'Rourke, Tom wrote:
 From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel 
 Vetter
 Sent: Monday, June 02, 2014 1:26 AM
 To: O'Rourke, Tom
 Cc: intel-gfx@lists.freedesktop.org; Ben Widawsky; Kristen Carlson Accardi
 Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on
 bdw
 
 On Fri, May 30, 2014 at 11:30:18PM +, O'Rourke, Tom wrote:
  On Wed, Apr 30, 2014 at 02:14:02PM -0700, Kristen Carlson Accardi wrote:
   On Thu, 01 May 2014 00:03:15 +0300
   Imre Deak imre.d...@intel.com wrote:
  
On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote:
 On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi
 wrote:
  On Tue, 29 Apr 2014 22:31:49 -0700 Ben Widawsky
  b...@bwidawsk.net wrote:
 
   On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
Higher RC6 residency is observed using timeout mode
instead of EI mode.  This applies to Broadwell only.
The difference is particularly noticeable with video
playback.
   
Issue: VIZ-3778
Change-Id: I62bb12e21caf19651034826b45cde7f73a80938d
Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com
  
   I've merged this one to my bdw-rc6 branch, and therefore my
   broadwell branch. Hopefully Kristen will see some improvement.
 
  Unfortunately, I built your bdw-rc6 branch along with the
  revert I need to get my panel to work, and I get zero rc6 
  residency.
  Do I have to explicitly enable it?

 I'm not actually sure. You can try it and let me know. I
 haven't had any time to verify the rebase. We can check my hack.
   
Note that in -nightly you also have to update
sanitize_rc6_option() along with intel_enable_gt_powersave() and
intel_disable_gt_powersave() since atm these keep RC6 disabled on BDW.
   
--Imre
   
  
  
   Yes, I reverted fb5ed3b201fe5670c9ffeec3b5f6ff044d543c9e and was
   able to see some rc6 residency.  With the idle workload, residency
   appears to be similar to before, so no regression.
  
  Thanks. I'll squash this in where appropriate.
  
  --
  Ben Widawsky, Intel Open Source Technology Center
 
  [TOR:] Can we get this patch merged now that RC6 is working on drm-intel-
 nightly?
 
 Needs some review from bdw people. Also some relative residency
 improvement date should be added to the commit message (yes, we're allowed
 to do that now officially).
 -Daniel
 --
 
 [TOR:] Hello bdw people, please review this patch.
 
 Is relative performance data now required in the commit message?  A week
 ago this would have been prohibited.

You might need to double-check with your own manager, but we're now again
allowed to officially add it to the commit message. It was kinda always
required, just had to be washed down more.
-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] [PATCH 10/11] drm/i915: Improve PSR debugfs status.

[Daniel Vetter]

On Mon, Jun 02, 2014 at 11:54:10PM +0530, Vijay Purushothaman wrote:
 On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:
 Now we have the active/inactive state for exit and this actually changes the
 HW enable bit the status was a bit confusing for users. So let's provide
 more info.
 
 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 ---
   drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 6636ca2..0ca9376 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -1975,10 +1975,12 @@ static int i915_edp_psr_status(struct seq_file *m, 
 void *data)
 
  seq_printf(m, Sink_Support: %s\n, yesno(dev_priv-psr.sink_support));
  seq_printf(m, Source_OK: %s\n, yesno(dev_priv-psr.source_ok));
 +seq_printf(m, Enabled: %s\n, yesno(dev_priv-psr.enabled));
 +seq_printf(m, Active: %s\n, yesno(dev_priv-psr.active));
 
  enabled = HAS_PSR(dev) 
  I915_READ(EDP_PSR_CTL(dev))  EDP_PSR_ENABLE;
 -seq_printf(m, Enabled: %s\n, yesno(enabled));
 +seq_printf(m, HW Enabled  Active bit: %s\n, yesno(enabled));
 
  if (HAS_PSR(dev))
  psrperf = I915_READ(EDP_PSR_PERF_CNT(dev)) 
 
 Please remove all references to PSR performance counter. This register is
 primarily meant as a debug register and its implementation is broken in the
 h/w. Whenever the cdclk is gated to save power, the performance counter is
 stopped. But when the clk is re-enabled it doesn't reset the counter. This
 unnecessarily confuses the end users.. When the system goes through suspend
 / resume cycle the performance counter most likely will transition from a
 non-zero value to zero.. I already received few queries from our customers
 related to this performance customer and they refuse to believe me when i
 tell them PSR is still functional when the performance counter reports 0 :-)

We expose other such perf registers and imo this is handy for debugging.
Also we have a big push to expose all this perf stuff recently ...

Imo we should keep this, if we can. If confused customers noodle around in
debugfs without clue, maybe they shouldn't.
-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] [alsa-devel] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)

[Daniel Vetter]

On Tue, Jun 03, 2014 at 01:42:03AM +, Lin, Mengdong wrote:
  -Original Message-
  From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] 
 
   Hi Daniel,
  
   Would you please share more info about your idea?
  
   - What would be an avsink device represent here?
E.g. on Intel platforms, will the whole display device have a child
   avsink device or multiple avsink devices for each DDI port?
  
  My idea would be to have one for each output pipe (i.e. the link between
  audio and gfx), not one per ddi. Gfx driver would then let audio know
  when a screen is connected and which one (e.g. exact model serial from
  edid).
  This is somewhat important for dp mst where there's no longer a fixed
  relationship between audio pin and screen
 
 Thanks. But if we use avsink device, I prefer to have an avsink device per 
 DDI or several avsink devices per DDI,
 It's because
 1. Without DP MST, there is a fixed mapping between each audio codec pin and 
 DDI;
 2. With DP MST, the above pin: DDI mapping is still valid (at least on Intel 
 platforms),
   and there is also a fixed mapping between each device (screen) connected to 
 a pin/DDI.  
 3. HD-Audio driver creates a PCM (audio stream) devices for each pin.
   Keeping this behavior can make audio driver works on platforms without 
 implementing the sound/gfx sync channel.
   And I guess in the future the audio driver will creates more than one PCM 
 devices for a DP MST-capable pin, according how many devices a DDI can 
 support.
 
 4. Display mode change can change the pipe connected to a DDI even if the 
 monitor stays on the same DDI, 
   If we have an avsink device per pipe, the audio driver will have to check 
 another avsink device for this case. It seems not convenient.

All this can also be solved by making the connector/avsink/sound pcm known
to userspace and let userspace figure it out. A few links in sysfs should
be good enough, plus exposing the full edid on the sound pcm side (so that
userspace can compare the serial number in the edid).

   - And for the relationship between audio driver and the avsink device,
   which would be the master and which would be the component?
  
  1:1 for avsink:alsa pin (iirc it's called a pin, not sure about the name).
  That way the audio driver has a clear point for getting at the eld and
  similar information.
 
 Since the audio driver usually already binds to some device (PCI or platform 
 device),
 I think the audio driver cannot bind to the new avsink devices created by 
 display driver, and we need a new driver to handle these device and 
 communication.
 
 While the display driver creates the new endpoint avsink devices, the audio 
 driver can also create the same number of audio endpoint devices.
 And we could let the audio endpoint device be the master and its peer display 
 endpoint device be the component.
 Thus the master/component framework can help us to bind/unbind each pair of 
 display/audio endpoint devices.
 
 Is it doable? If okay, I'll modify the RFC and see if there are other gaps.

Yeah, that should be doable. gfx creates avsink devices, audio binds to
them using the component framework.

   In addition, the component framework does not touch PM now.
   And introducing PM to the component framework seems not easy since
   there can be potential conflict caused by parent-child relationship of
   the involved devices.
  
  Yeah, the entire PM situation seems to be a bit bad. It also looks like on
  resume/suspend we still have problems, at least on the audio side since
  we need to coordinate between 2 completel different underlying devices.
  But at least with the parent-child relationship we have a guranatee that
  the avsink won't be suspended after the gfx device is already off.
  -Daniel
 
 Yes. You're right.
 And we could find a way to hide the Intel-specific display power well
 from the audio driver by using runtime PM API on these devices.

Yeah, that's one of the goals a I have here.

Cheers, Daneil
-- 
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] [PATCH] [v5] drm/i915/bdw: Only use 2g GGTT for 32b platforms

[Daniel Vetter]

On Tue, Jun 03, 2014 at 06:05:45AM +, Yang, Guang A wrote:
 Tested-by: Yang, Guang A guang.a.y...@intel.com
 With this patch, the 32 bit system can be able to boot normally.

I wonder what's going to happen on 64 bit kernels with 32 bit userspace.
Since that one's a really common thing with games. Whatever. Queued for
-next, thanks for the patch.
-Daniel
 
 
 
 Best Regards~~
 
 Open Source Technology Center (OTC)
 Terence Yang（杨光）
 Tel: 86-021-61167360
 iNet: 8821-7360
 
  -Original Message-
  From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
  Of
  Ben Widawsky
  Sent: Wednesday, May 28, 2014 7:53 AM
  To: Intel GFX
  Cc: Ben Widawsky; sta...@vger.kernel.org; Widawsky, Benjamin
  Subject: [Intel-gfx] [PATCH] [v5] drm/i915/bdw: Only use 2g GGTT for 32b
  platforms
  
  Daniel requested in the bug that I use a 3GB fallback size. Since this is 
  not in
  the spec as a valid size, I decided against it. We could potentially add a 
  patch to
  bump it to 3GB on top of this one.
  
  This probably should be CC: stable - but I'll let the powers that be decide 
  that
  one.
  
  Regression from a revert of the revert:
  commit 7907f45bf9f67a1c5e5d4ae05bab428d7c2f43b2
  Author: Ben Widawsky benjamin.widaw...@intel.com
  Date:   Wed Feb 19 22:05:46 2014 -0800
  
  Revert drm/i915/bdw: Limit GTT to 2GB
  
  v2: Change ifdef to 32b, instead of ifndef update comment
  
  v3. Update comment to not wrap (Daniel).
  Update commit message
  
  v4: s/CONFIG_32/CONFIG_X86_32 (Jani).
  
  v5: s/CONFIG_x86_32BIT/CONFIG_x86_32, as meant in v4 s/32B/32b (chris)
  
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76619
  Cc: sta...@vger.kernel.org
  Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
  Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
  Signed-off-by: Ben Widawsky b...@bwidawsk.net
  ---
   drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
   1 file changed, 7 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
  b/drivers/gpu/drm/i915/i915_gem_gtt.c
  index 931b906..eec820a 100644
  --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
  +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
  @@ -1775,6 +1775,13 @@ static inline unsigned int
  gen8_get_total_gtt_size(u16 bdw_gmch_ctl)
  bdw_gmch_ctl = BDW_GMCH_GGMS_MASK;
  if (bdw_gmch_ctl)
  bdw_gmch_ctl = 1  bdw_gmch_ctl;
  +
  +#ifdef CONFIG_X86_32
  +   /* Limit 32b platforms to a 2GB GGTT: 4  20 / pte size * PAGE_SIZE */
  +   if (bdw_gmch_ctl  4)
  +   bdw_gmch_ctl = 4;
  +#endif
  +
  return bdw_gmch_ctl  20;
   }
  
  --
  1.9.3
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] [PATCH] drm/i915: Drop unused lut tables from intel_plane

[Daniel Vetter]

On Mon, Jun 02, 2014 at 07:06:52PM +0100, Damien Lespiau wrote:
 On Mon, Jun 02, 2014 at 10:12:06AM -0700, Matt Roper wrote:
  Signed-off-by: Matt Roper matthew.d.ro...@intel.com
 
 The commit message is a bit terse and could do with some digging.
 Something like:
 
 Those LUT where defined in the original sprite patch introducing intel_plane,
 but were never used.
 
   commit b840d907fcf6d5d5ef91af4518b3dab3a5da0f75
   Author: Jesse Barnes jbar...@virtuousgeek.org
   Date:   Tue Dec 13 13:19:38 2011 -0800
 
 drm/i915: add SNB and IVB video sprite support v6

Added.

 Reviewed-by: Damien Lespiau damien.lesp...@intel.com

Queued for -next, thanks for the patch.
-Daniel

 
  ---
   drivers/gpu/drm/i915/intel_drv.h | 1 -
   1 file changed, 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 76de420..fea8e05 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -428,7 +428,6 @@ struct intel_plane {
  struct drm_i915_gem_object *obj;
  bool can_scale;
  int max_downscale;
  -   u32 lut_r[1024], lut_g[1024], lut_b[1024];
  int crtc_x, crtc_y;
  unsigned int crtc_w, crtc_h;
  uint32_t src_x, src_y;
  -- 
  1.8.5.1
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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

[Intel-gfx] [PATCH] drm/i915: Simplify intel_gpu_reset

[Daniel Vetter]

From: Robert Beckett robert.beck...@intel.com

Replaced ever growing switch for gen version with chained conditionals.
Futre gen's only need to add a new one if they require something different.

Reviewed-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Robert Beckett robert.beck...@intel.com
[danvet: Picked from internal tree and white-wash commit message.]
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_uncore.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b1dd880c3093..acffcecf79d4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1177,18 +1177,16 @@ static int gen6_do_reset(struct drm_device *dev)
 
 int intel_gpu_reset(struct drm_device *dev)
 {
-   switch (INTEL_INFO(dev)-gen) {
-   case 8:
-   case 7:
-   case 6: return gen6_do_reset(dev);
-   case 5: return ironlake_do_reset(dev);
-   case 4:
-   if (IS_G4X(dev))
-   return g4x_do_reset(dev);
-   else
-   return i965_do_reset(dev);
-   default: return -ENODEV;
-   }
+   if (INTEL_INFO(dev)-gen = 6)
+   return gen6_do_reset(dev);
+   else if (IS_GEN5(dev))
+   return ironlake_do_reset(dev);
+   else if (IS_G4X(dev))
+   return g4x_do_reset(dev);
+   else if (IS_GEN4(dev))
+   return i965_do_reset(dev);
+   else
+   return -ENODEV;
 }
 
 void intel_uncore_check_errors(struct drm_device *dev)
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: T12 eDP panel timing enforcement during reboot.

[Jani Nikula]

On Mon, 02 Jun 2014, clinton.a.tay...@intel.com wrote:
 From: Clint Taylor clinton.a.tay...@intel.com

 The panel power sequencer on vlv doesn't appear to accept changes to its
 T12 power down duration during warm reboots. This change forces a delay
 for warm reboots to the T12 panel timing as defined in the VBT table for
 the connected panel.

 Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg

 Ver3: moved SYS_RESTART check earlier, new name for pp_div.

 Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c  |   42 
 ++
  drivers/gpu/drm/i915/intel_drv.h |2 ++
  2 files changed, 44 insertions(+)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 5ca68aa9..fb7725a 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -28,6 +28,8 @@
  #include linux/i2c.h
  #include linux/slab.h
  #include linux/export.h
 +#include linux/notifier.h
 +#include linux/reboot.h
  #include drm/drmP.h
  #include drm/drm_crtc.h
  #include drm/drm_crtc_helper.h
 @@ -302,6 +304,38 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
   return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
  }
  
 +/* Reboot notifier handler to shutdown panel power to guarantee T12 timing */
 +static int edp_notify_handler(struct notifier_block *this, unsigned long 
 code,
 +   void *unused)
 +{
 + struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
 +  edp_notifier);
 + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 + struct drm_device *dev = intel_dig_port-base.base.dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + u32 pp_div;
 + u32 pp_ctrl_reg, pp_div_reg;
 + enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
 +
 + if ((!is_edp(intel_dp)) 
 + (code != SYS_RESTART ))

Should be:

if (!is_edp(intel_dp) || code != SYS_RESTART)

 + return 0;
 +
 + if (IS_VALLEYVIEW(dev)) {
 + pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
 + pp_div_reg  = VLV_PIPE_PP_DIVISOR(pipe);
 + pp_div = I915_READ(VLV_PIPE_PP_DIVISOR(pipe));
 + pp_div = PP_REFERENCE_DIVIDER_MASK;
 +
 + /* 0x1F write to PP_DIV_REG sets max cycle delay */
 + I915_WRITE(pp_div_reg , pp_div | 0x1F);

Superfluous space before comma.

 + I915_WRITE(pp_ctrl_reg,
 +PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
 + msleep(intel_dp-panel_power_cycle_delay);
 + }

A blank line before final return statement is customary.

 + return 0;
 +}
 +
  static bool edp_have_panel_power(struct intel_dp *intel_dp)
  {
   struct drm_device *dev = intel_dp_to_dev(intel_dp);
 @@ -3344,6 +3378,10 @@ void intel_dp_encoder_destroy(struct drm_encoder 
 *encoder)
   mutex_lock(dev-mode_config.mutex);
   edp_panel_vdd_off_sync(intel_dp);
   mutex_unlock(dev-mode_config.mutex);
 + if (intel_dp-edp_notifier.notifier_call) {
 + unregister_reboot_notifier(intel_dp-edp_notifier);
 + intel_dp-edp_notifier.notifier_call = NULL;
 + }
   }
   kfree(intel_dig_port);
  }
 @@ -3782,6 +3820,10 @@ intel_dp_init_connector(struct intel_digital_port 
 *intel_dig_port,
   if (is_edp(intel_dp)) {
   intel_dp_init_panel_power_timestamps(intel_dp);
   intel_dp_init_panel_power_sequencer(dev, intel_dp, power_seq);
 + if (IS_VALLEYVIEW(dev)) {
 + intel_dp-edp_notifier.notifier_call = 
 edp_notify_handler;
 + register_reboot_notifier(intel_dp-edp_notifier);
 + }
   }
  
   intel_dp_aux_init(intel_dp, intel_connector);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 328b1a7..ea2cc07 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -510,6 +510,8 @@ struct intel_dp {
   unsigned long last_power_on;
   unsigned long last_backlight_off;
   bool psr_setup_done;
 + struct notifier_block  edp_notifier;

Use only one space between type and name.

With all of the above fixed it's

Reviewed-by: Jani Nikula jani.nik...@intel.com


 +
   bool use_tps3;
   struct intel_connector *attached_connector;
  
 -- 
 1.7.9.5

 ___
 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 03/11] drm/i915: Use HAS_PSR to avoid unecessary interactions.

[Vijay Purushothaman]

On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:

Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
  drivers/gpu/drm/i915/intel_dp.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34e8f7a..58537b7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1739,11 +1739,6 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)

dev_priv-psr.source_ok = false;

-   if (!HAS_PSR(dev)) {
-   DRM_DEBUG_KMS(PSR not supported on this platform\n);
-   return false;
-   }
-
if ((intel_encoder-type != INTEL_OUTPUT_EDP) ||
(dig_port-port != PORT_A)) {
DRM_DEBUG_KMS(HSW ties PSR to DDI A (eDP)\n);
@@ -1816,6 +1811,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);

+   if (!HAS_PSR(dev)) {
+   DRM_DEBUG_KMS(PSR not supported on this platform\n);
+   return;
+   }
+
if (intel_edp_psr_match_conditions(intel_dp) 
!intel_edp_is_psr_enabled(dev))
intel_edp_psr_do_enable(intel_dp);
@@ -1843,6 +1843,9 @@ void intel_edp_psr_update(struct drm_device *dev)
struct intel_encoder *encoder;
struct intel_dp *intel_dp = NULL;

+   if (!HAS_PSR(dev))
+   return;
+
list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
if (encoder-type == INTEL_OUTPUT_EDP) {
intel_dp = enc_to_intel_dp(encoder-base);



Reviewed-by: Vijay Purushothaman vijay.a.purushotha...@intel.com


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

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Don't let update_psr function actually enable PSR.

[Vijay Purushothaman]

On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:

Being more conservative by enabling PSR only on psr_enable function.

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
  drivers/gpu/drm/i915/intel_dp.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58537b7..fe28eb7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1797,9 +1797,6 @@ static void intel_edp_psr_do_enable(struct intel_dp 
*intel_dp)
intel_edp_is_psr_enabled(dev))
return;

-   /* Setup PSR once */
-   intel_edp_psr_setup(intel_dp);
-
/* Enable PSR on the panel */
intel_edp_psr_enable_sink(intel_dp);

@@ -1816,6 +1813,9 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
return;
}

+   /* Setup PSR once */
+   intel_edp_psr_setup(intel_dp);
+
if (intel_edp_psr_match_conditions(intel_dp) 
!intel_edp_is_psr_enabled(dev))
intel_edp_psr_do_enable(intel_dp);
@@ -1840,12 +1840,16 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)

  void intel_edp_psr_update(struct drm_device *dev)
  {
+   struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *encoder;
struct intel_dp *intel_dp = NULL;

if (!HAS_PSR(dev))
return;

+   if (!dev_priv-psr.setup_done)
+   return;
+
list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
if (encoder-type == INTEL_OUTPUT_EDP) {
intel_dp = enc_to_intel_dp(encoder-base);



Reviewed-by: Vijay Purushothaman vijay.a.purushotha...@intel.com


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

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Force PSR exit by inactivating it.

[Vijay Purushothaman]

On 5/16/2014 10:12 PM, Rodrigo Vivi wrote:




On Fri, May 16, 2014 at 3:23 AM, Chris Wilson ch...@chris-wilson.co.uk
mailto:ch...@chris-wilson.co.uk wrote:

On Thu, May 15, 2014 at 08:13:05PM -0400, Rodrigo Vivi wrote:
  The perfect solution for psr_exit is the hardware tracking the
changes and
  doing the psr exit by itself. This scenario works for HSW and BDW
with some
  environments like Gnome and Wayland.
 
  However there are many other scenarios that this isn't true.
Mainly one right
  now is KDE users on HSW and BDW with PSR on. User would miss many
screen
  updates. For instances any key typed could be seen only when
mouse cursor is
  moved. So this patch introduces the ability of trigger PSR exit
on kernel side
  on some common cases that.

You know that userspace has been waiting for a PSR flag for over a year
now so that it can use the more efficient rendering paths when it makes
sense.


yeah... this item is lingering on my to do list... but reaching a point
where I won't be able to continue postponing it ;)


What happened to the front buffer tracking?


What front buffer tracking? hehe
I'm wondering about this since I started looking to fbc and psr and
could never find a reliable way.

FBC should cover most of the scenarios except cursor planes.. When ever 
cursor planes are enabled you can fall back to s/w controlled exit path.


If you can elaborate on the exact issue that you are facing with FBC and 
PSR may be i can help..


Thanks,
Vijay



-Chris

--
Chris Wilson, Intel Open Source Technology Centre




--
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



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

Re: [Intel-gfx] [PATCH 08/11] drm/i915: BDW PSR: Remove limitations that aren't valid for BDW.

[Vijay Purushothaman]

On 5/16/2014 5:43 AM, Rodrigo Vivi wrote:

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
  drivers/gpu/drm/i915/intel_dp.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28144d3..9421b0b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1768,6 +1768,10 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)
return false;
}

+   /* Below limitations aren't valid for Broadwell */
+   if (IS_BROADWELL(dev))
+   goto out;


I couldn't figure out any sprite related restrictions for HSW as well. 
Is this because FBC logic doesn't track sprites in HSW?


Thanks,
Vijay



+
if (I915_READ(SPRCTL(intel_crtc-pipe))  SPRITE_ENABLE) {
DRM_DEBUG_KMS(PSR condition failed: Sprite is Enabled\n);
return false;
@@ -1784,6 +1788,7 @@ static bool intel_edp_psr_match_conditions(struct 
intel_dp *intel_dp)
return false;
}

+ out:
dev_priv-psr.source_ok = true;
return true;
  }



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

[Intel-gfx] [PATCH v2 2/8] drm/i915: replace drm_get_connector_name() with direct name field use

[Jani Nikula]

Generated using semantic patches:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E.name

@@
expression E;
@@

- drm_get_connector_name(E)
+ E-name

v2: Turn drm_get_connector_name(E) into E.name instead of (E)-name.

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 ++--
 drivers/gpu/drm/i915/i915_irq.c  |  8 
 drivers/gpu/drm/i915/intel_crt.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 16 
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/intel_dvo.c |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
 drivers/gpu/drm/i915/intel_lvds.c|  2 +-
 drivers/gpu/drm/i915/intel_panel.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c|  8 
 drivers/gpu/drm/i915/intel_tv.c  |  2 +-
 12 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 18b3565f431a..6f2cad83e2f4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2161,7 +2161,7 @@ static void intel_encoder_info(struct seq_file *m,
struct drm_connector *connector = intel_connector-base;
seq_printf(m, \t\tconnector %d: type: %s, status: %s,
   connector-base.id,
-  drm_get_connector_name(connector),
+  connector-name,
   drm_get_connector_status_name(connector-status));
if (connector-status == connector_status_connected) {
struct drm_display_mode *mode = crtc-mode;
@@ -2232,7 +2232,7 @@ static void intel_connector_info(struct seq_file *m,
struct drm_display_mode *mode;
 
seq_printf(m, connector %d: type %s, status: %s\n,
-  connector-base.id, drm_get_connector_name(connector),
+  connector-base.id, connector-name,
   drm_get_connector_status_name(connector-status));
if (connector-status == connector_status_connected) {
seq_printf(m, \tname: %s\n, connector-display_info.name);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2d7618366b75..8c516be8e206 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -949,7 +949,7 @@ static bool intel_hpd_irq_event(struct drm_device *dev,
 
DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %s to %s\n,
  connector-base.id,
- drm_get_connector_name(connector),
+ connector-name,
  drm_get_connector_status_name(old_status),
  drm_get_connector_status_name(connector-status));
 
@@ -994,7 +994,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
connector-polled == DRM_CONNECTOR_POLL_HPD) {
DRM_INFO(HPD interrupt storm detected on connector %s: 

 switching from hotplug detection to 
polling\n,
-   drm_get_connector_name(connector));
+   connector-name);
dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark = 
HPD_DISABLED;
connector-polled = DRM_CONNECTOR_POLL_CONNECT
| DRM_CONNECTOR_POLL_DISCONNECT;
@@ -1002,7 +1002,7 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
}
if (hpd_event_bits  (1  intel_encoder-hpd_pin)) {
DRM_DEBUG_KMS(Connector %s (pin %i) received hotplug 
event.\n,
- drm_get_connector_name(connector), 
intel_encoder-hpd_pin);
+ connector-name, intel_encoder-hpd_pin);
}
}
 /* if there were no outputs to poll, poll was disabled,
@@ -3993,7 +3993,7 @@ static void intel_hpd_irq_reenable(unsigned long data)
if (intel_connector-encoder-hpd_pin == i) {
if (connector-polled != 
intel_connector-polled)
DRM_DEBUG_DRIVER(Reenabling HPD on 
connector %s\n,
-
drm_get_connector_name(connector));
+connector-name);
connector-polled = intel_connector-polled;
if (!connector-polled)
connector-polled = 
DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 22d8347f7838..1fc91df58296 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -634,7 +634,7 @@ intel_crt_detect(struct 

[Intel-gfx] [PATCH v2 5/8] drm: replace drm_get_connector_name() with direct name field use

[Jani Nikula]

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E-name

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/drm_crtc.c |  4 ++--
 drivers/gpu/drm/drm_crtc_helper.c  |  6 +++---
 drivers/gpu/drm/drm_edid.c |  6 +++---
 drivers/gpu/drm/drm_edid_load.c|  2 +-
 drivers/gpu/drm/drm_fb_helper.c|  6 +++---
 drivers/gpu/drm/drm_probe_helper.c | 10 +-
 drivers/gpu/drm/drm_sysfs.c|  6 +++---
 7 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index edee61bccd14..242937c76638 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1663,7 +1663,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
head) {
DRM_DEBUG_KMS([CONNECTOR:%d:%s]\n,
connector-base.id,
-   drm_get_connector_name(connector));
+   connector-name);
if (put_user(connector-base.id,
 connector_id + copied)) {
ret = -EFAULT;
@@ -2458,7 +2458,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector = obj_to_connector(obj);
DRM_DEBUG_KMS([CONNECTOR:%d:%s]\n,
connector-base.id,
-   drm_get_connector_name(connector));
+   connector-name);
 
connector_set[i] = connector;
}
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 54e8fdba02b4..d31659f7dfaa 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -600,11 +600,11 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
}
if (new_crtc) {
DRM_DEBUG_KMS([CONNECTOR:%d:%s] to [CRTC:%d]\n,
-   connector-base.id, 
drm_get_connector_name(connector),
+   connector-base.id, connector-name,
new_crtc-base.id);
} else {
DRM_DEBUG_KMS([CONNECTOR:%d:%s] to [NOCRTC]\n,
-   connector-base.id, 
drm_get_connector_name(connector));
+   connector-base.id, connector-name);
}
}
 
@@ -630,7 +630,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
DRM_DEBUG_KMS(Setting connector DPMS state to on\n);
for (i = 0; i  set-num_connectors; i++) {
DRM_DEBUG_KMS(\t[CONNECTOR:%d:%s] set DPMS 
on\n, set-connectors[i]-base.id,
- 
drm_get_connector_name(set-connectors[i]));
+ set-connectors[i]-name);

set-connectors[i]-funcs-dpms(set-connectors[i], DRM_MODE_DPMS_ON);
}
}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d74239fec291..ab8aa6d462e6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1227,7 +1227,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
if (i == 4  print_bad_edid) {
dev_warn(connector-dev-dev,
 %s: Ignoring invalid EDID block %d.\n,
-drm_get_connector_name(connector), j);
+connector-name, j);
 
connector-bad_edid_counter++;
}
@@ -1247,7 +1247,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
 carp:
if (print_bad_edid) {
dev_warn(connector-dev-dev, %s: EDID block %d invalid.\n,
-drm_get_connector_name(connector), j);
+connector-name, j);
}
connector-bad_edid_counter++;
 
@@ -3517,7 +3517,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
}
if (!drm_edid_is_valid(edid)) {
dev_warn(connector-dev-dev, %s: EDID invalid.\n,
-drm_get_connector_name(connector));
+connector-name);
return 0;
}
 
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 6e09f615ebc9..0a235fe61c9b 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -261,7 +261,7 @@ out:
 
 int drm_load_edid_firmware(struct drm_connector *connector)
 {
-   const char *connector_name = 

[Intel-gfx] [PATCH v2 4/8] drm/radeon: replace drm_get_connector_name() with direct name field use

[Jani Nikula]

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E-name

Acked-by: Alex Deucher alexander.deuc...@amd.com
Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 19 ---
 drivers/gpu/drm/radeon/radeon_display.c|  2 +-
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index ea50e0ae7bf7..19e733d5a7a4 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -260,13 +260,17 @@ radeon_connector_analog_encoder_conflict_solve(struct 
drm_connector *connector,
continue;
 
if (priority == true) {
-   DRM_DEBUG_KMS(1: conflicting encoders 
switching off %s\n, drm_get_connector_name(conflict));
-   DRM_DEBUG_KMS(in favor of %s\n, 
drm_get_connector_name(connector));
+   DRM_DEBUG_KMS(1: conflicting encoders 
switching off %s\n,
+ conflict-name);
+   DRM_DEBUG_KMS(in favor of %s\n,
+ connector-name);
conflict-status = 
connector_status_disconnected;

radeon_connector_update_scratch_regs(conflict, connector_status_disconnected);
} else {
-   DRM_DEBUG_KMS(2: conflicting encoders 
switching off %s\n, drm_get_connector_name(connector));
-   DRM_DEBUG_KMS(in favor of %s\n, 
drm_get_connector_name(conflict));
+   DRM_DEBUG_KMS(2: conflicting encoders 
switching off %s\n,
+ connector-name);
+   DRM_DEBUG_KMS(in favor of %s\n,
+ conflict-name);
current_status = 
connector_status_disconnected;
}
break;
@@ -787,7 +791,7 @@ radeon_vga_detect(struct drm_connector *connector, bool 
force)
 
if (!radeon_connector-edid) {
DRM_ERROR(%s: probed a monitor but no|invalid EDID\n,
-   drm_get_connector_name(connector));
+   connector-name);
ret = connector_status_connected;
} else {
radeon_connector-use_digital = 
!!(radeon_connector-edid-input  DRM_EDID_INPUT_DIGITAL);
@@ -1010,12 +1014,13 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)
 
if (!radeon_connector-edid) {
DRM_ERROR(%s: probed a monitor but no|invalid EDID\n,
-   drm_get_connector_name(connector));
+   connector-name);
/* rs690 seems to have a problem with connectors not 
existing and always
 * return a block of 0's. If we see this just stop 
polling on this output */
if ((rdev-family == CHIP_RS690 || rdev-family == 
CHIP_RS740)  radeon_connector-base.null_edid_counter) {
ret = connector_status_disconnected;
-   DRM_ERROR(%s: detected RS690 floating bus bug, 
stopping ddc detect\n, drm_get_connector_name(connector));
+   DRM_ERROR(%s: detected RS690 floating bus bug, 
stopping ddc detect\n,
+ connector-name);
radeon_connector-ddc_bus = NULL;
} else {
ret = connector_status_connected;
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 8d99d5ee8014..7a1a70a04d5a 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -657,7 +657,7 @@ static void radeon_print_display_setup(struct drm_device 
*dev)
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
radeon_connector = to_radeon_connector(connector);
DRM_INFO(Connector %d:\n, i);
-   DRM_INFO(  %s\n, drm_get_connector_name(connector));
+   DRM_INFO(  %s\n, connector-name);
if (radeon_connector-hpd.hpd != RADEON_HPD_NONE)
DRM_INFO(  %s\n, 
hpd_names[radeon_connector-hpd.hpd]);
if (radeon_connector-ddc_bus) {
-- 
1.9.1

[Intel-gfx] [PATCH v2 0/8] drm drivers: kill drm_get_connector_name() and drm_get_encoder_name()

[Jani Nikula]

Hi all, this is v2 of [1] to remove drm_get_connector_name() and
drm_get_encoder_name(), adding patch 1 for imx in staging and making
some dereferences less of an eye sore. This is based on Dave's drm-next
branch.

BR,
Jani.


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


Jani Nikula (8):
  staging: imx-drm-core: replace drm_get_connector_name() with direct
name field use
  drm/i915: replace drm_get_connector_name() with direct name field use
  drm/nouveau: replace drm_get_connector_name() with direct name field
use
  drm/radeon: replace drm_get_connector_name() with direct name field
use
  drm: replace drm_get_connector_name() with direct name field use
  drm/i915: replace drm_get_encoder_name() with direct name field use
  drm: replace drm_get_encoder_name() with direct name field use
  drm: drop drm_get_connector_name() and drm_get_encoder_name()

 drivers/gpu/drm/drm_crtc.c  | 26 +++
 drivers/gpu/drm/drm_crtc_helper.c   |  8 
 drivers/gpu/drm/drm_edid.c  |  6 +++---
 drivers/gpu/drm/drm_edid_load.c |  2 +-
 drivers/gpu/drm/drm_fb_helper.c |  6 +++---
 drivers/gpu/drm/drm_probe_helper.c  | 10 -
 drivers/gpu/drm/drm_sysfs.c |  6 +++---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 +++---
 drivers/gpu/drm/i915/i915_irq.c |  8 
 drivers/gpu/drm/i915/intel_crt.c|  2 +-
 drivers/gpu/drm/i915/intel_display.c| 32 ++---
 drivers/gpu/drm/i915/intel_dp.c |  4 ++--
 drivers/gpu/drm/i915/intel_dvo.c|  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c  |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c   |  2 +-
 drivers/gpu/drm/i915/intel_lvds.c   |  2 +-
 drivers/gpu/drm/i915/intel_panel.c  |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |  8 
 drivers/gpu/drm/i915/intel_tv.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/dac.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c  |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.c |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c   |  3 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   |  3 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c |  8 
 drivers/gpu/drm/nouveau/nv50_display.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_connectors.c  | 19 ++---
 drivers/gpu/drm/radeon/radeon_display.c |  2 +-
 drivers/staging/imx-drm/imx-drm-core.c  |  2 +-
 include/drm/drm_crtc.h  |  2 --
 30 files changed, 83 insertions(+), 100 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v2 1/8] staging: imx-drm-core: replace drm_get_connector_name() with direct name field use

[Jani Nikula]

Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E-name

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/staging/imx-drm/imx-drm-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 53ff005245c5..6543b349bfb6 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -298,7 +298,7 @@ static int imx_drm_driver_load(struct drm_device *drm, 
unsigned long flags)
dev_err(drm-dev,
[CONNECTOR:%d:%s] drm_sysfs_connector_add 
failed: %d\n,
connector-base.id,
-   drm_get_connector_name(connector), ret);
+   connector-name, ret);
goto err_unbind;
}
}
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 7/8] drm: replace drm_get_encoder_name() with direct name field use

[Jani Nikula]

Generated using semantic patch:

@@
expression E;
@@

- drm_get_encoder_name(E)
+ E-name

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/drm_crtc.c| 2 +-
 drivers/gpu/drm/drm_crtc_helper.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 242937c76638..986531395872 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1631,7 +1631,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
dev-mode_config.encoder_list,
head) {
DRM_DEBUG_KMS([ENCODER:%d:%s]\n, 
encoder-base.id,
-   drm_get_encoder_name(encoder));
+   encoder-name);
if (put_user(encoder-base.id, encoder_id +
 copied)) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index d31659f7dfaa..231c9433341f 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -330,7 +330,7 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
continue;
 
DRM_DEBUG_KMS([ENCODER:%d:%s] set [MODE:%d:%s]\n,
-   encoder-base.id, drm_get_encoder_name(encoder),
+   encoder-base.id, encoder-name,
mode-base.id, mode-name);
encoder_funcs = encoder-helper_private;
encoder_funcs-mode_set(encoder, mode, adjusted_mode);
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 3/8] drm/nouveau: replace drm_get_connector_name() with direct name field use

[Jani Nikula]

Generated using semantic patches:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E.name

@@
expression E;
@@

- drm_get_connector_name(E)
+ E-name

v2: Turn drm_get_connector_name(E) into E.name instead of (E)-name.

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/nouveau/dispnv04/dac.c  | 2 +-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c  | 2 +-
 drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c   | 3 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c   | 3 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c | 8 
 drivers/gpu/drm/nouveau/nv50_display.c  | 2 +-
 7 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c 
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 434b920f6bd4..a96dda48718e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -414,7 +414,7 @@ static void nv04_dac_commit(struct drm_encoder *encoder)
helper-dpms(encoder, DRM_MODE_DPMS_ON);
 
NV_DEBUG(drm, Output %s is running on CRTC %d using output %c\n,
-
drm_get_connector_name(nouveau_encoder_connector_get(nv_encoder)-base),
+nouveau_encoder_connector_get(nv_encoder)-base.name,
 nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
 }
 
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c 
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index a2d669b4acf2..e57babb206d3 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -477,7 +477,7 @@ static void nv04_dfp_commit(struct drm_encoder *encoder)
helper-dpms(encoder, DRM_MODE_DPMS_ON);
 
NV_DEBUG(drm, Output %s is running on CRTC %d using output %c\n,
-
drm_get_connector_name(nouveau_encoder_connector_get(nv_encoder)-base),
+nouveau_encoder_connector_get(nv_encoder)-base.name,
 nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
 }
 
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 2f1ed61f7c8c..4342fdaee707 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -115,7 +115,7 @@ nv04_display_create(struct drm_device *dev)
 dev-mode_config.connector_list, head) {
if (!connector-encoder_ids[0]) {
NV_WARN(drm, %s has no encoders, removing\n,
-   drm_get_connector_name(connector));
+   connector-name);
connector-funcs-destroy(connector);
}
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
index 244822df8ffc..8667620b703a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
@@ -171,7 +171,8 @@ static void nv04_tv_commit(struct drm_encoder *encoder)
helper-dpms(encoder, DRM_MODE_DPMS_ON);
 
NV_DEBUG(drm, Output %s is running on CRTC %d using output %c\n,
-
drm_get_connector_name(nouveau_encoder_connector_get(nv_encoder)-base), 
nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
+nouveau_encoder_connector_get(nv_encoder)-base.name,
+nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
 }
 
 static void nv04_tv_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index acef48f4a4ea..195bd8e86c6a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -612,8 +612,7 @@ static void nv17_tv_commit(struct drm_encoder *encoder)
helper-dpms(encoder, DRM_MODE_DPMS_ON);
 
NV_INFO(drm, Output %s is running on CRTC %d using output %c\n,
-   drm_get_connector_name(
-   nouveau_encoder_connector_get(nv_encoder)-base),
+   nouveau_encoder_connector_get(nv_encoder)-base.name,
nv_crtc-index, '@' + ffs(nv_encoder-dcb-or));
 }
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index d07ce028af51..6ecea9b2b15a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -265,14 +265,14 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
nv_connector-edid);
if (!nv_connector-edid) {
NV_ERROR(drm, DDC responded, but no EDID for %s\n,
-drm_get_connector_name(connector));
+connector-name);
goto detect_analog;
}
 
if (nv_encoder-dcb-type == DCB_OUTPUT_DP 

[Intel-gfx] [PATCH v2 8/8] drm: drop drm_get_connector_name() and drm_get_encoder_name()

[Jani Nikula]

No longer used or needed as the structs have a name field.

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/drm_crtc.c | 20 
 include/drm/drm_crtc.h |  2 --
 2 files changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 986531395872..f6664a75ad57 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -257,26 +257,6 @@ void drm_connector_ida_destroy(void)
 }
 
 /**
- * drm_get_encoder_name - return a string for encoder
- * @encoder: the encoder to get name for
- */
-const char *drm_get_encoder_name(const struct drm_encoder *encoder)
-{
-   return encoder-name;
-}
-EXPORT_SYMBOL(drm_get_encoder_name);
-
-/**
- * drm_get_connector_name - return a string for connector
- * @connector: the connector to get name for
- */
-const char *drm_get_connector_name(const struct drm_connector *connector)
-{
-   return connector-name;
-}
-EXPORT_SYMBOL(drm_get_connector_name);
-
-/**
  * drm_get_connector_status_name - return a string for connector status
  * @status: connector status to compute name of
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c1c31cc11cd..e8fe9d8e135c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -909,7 +909,6 @@ extern int drm_crtc_check_viewport(const struct drm_crtc 
*crtc,
 
 extern void drm_encoder_cleanup(struct drm_encoder *encoder);
 
-extern const char *drm_get_connector_name(const struct drm_connector 
*connector);
 extern const char *drm_get_connector_status_name(enum drm_connector_status 
status);
 extern const char *drm_get_subpixel_order_name(enum subpixel_order order);
 extern const char *drm_get_dpms_name(int val);
@@ -972,7 +971,6 @@ extern int drm_mode_create_tv_properties(struct drm_device 
*dev, int num_formats
 char *formats[]);
 extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
-extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
 
 extern int drm_mode_connector_attach_encoder(struct drm_connector *connector,
 struct drm_encoder *encoder);
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 6/8] drm/i915: replace drm_get_encoder_name() with direct name field use

[Jani Nikula]

Generated using semantic patches:

@@
expression E;
@@

- drm_get_encoder_name(E)
+ E.name

@@
expression E;
@@

- drm_get_encoder_name(E)
+ E-name

v2: Turn drm_get_encoder_name(E) into E.name instead of (E)-name.

Acked-by: David Herrmann dh.herrm...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 16 
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6f2cad83e2f4..d092b087b99f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2156,7 +2156,7 @@ static void intel_encoder_info(struct seq_file *m,
 
encoder = intel_encoder-base;
seq_printf(m, \tencoder %d: type: %s, connectors:\n,
-  encoder-base.id, drm_get_encoder_name(encoder));
+  encoder-base.id, encoder-name);
for_each_connector_on_encoder(dev, encoder, intel_connector) {
struct drm_connector *connector = intel_connector-base;
seq_printf(m, \t\tconnector %d: type: %s, status: %s,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 87e5a586457e..9d8ad7e55d47 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7206,7 +7206,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
for_each_encoder_on_crtc(dev, crtc, encoder) {
DRM_DEBUG_KMS([ENCODER:%d:%s] set [MODE:%d:%s]\n,
encoder-base.base.id,
-   drm_get_encoder_name(encoder-base),
+   encoder-base.name,
mode-base.id, mode-name);
 
if (encoder-mode_set)
@@ -7518,7 +7518,7 @@ void intel_write_eld(struct drm_encoder *encoder,
 connector-base.id,
 connector-name,
 connector-encoder-base.id,
-drm_get_encoder_name(connector-encoder));
+connector-encoder-name);
 
connector-eld[6] = drm_av_sync_delay(connector, mode) / 2;
 
@@ -7986,7 +7986,7 @@ bool intel_get_load_detect_pipe(struct drm_connector 
*connector,
 
DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n,
  connector-base.id, connector-name,
- encoder-base.id, drm_get_encoder_name(encoder));
+ encoder-base.id, encoder-name);
 
/*
 * Algorithm gets a little messy:
@@ -8098,7 +8098,7 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
 
DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n,
  connector-base.id, connector-name,
- encoder-base.id, drm_get_encoder_name(encoder));
+ encoder-base.id, encoder-name);
 
if (old-load_detect_temp) {
to_intel_connector(connector)-new_encoder = NULL;
@@ -9701,7 +9701,7 @@ check_encoder_state(struct drm_device *dev)
 
DRM_DEBUG_KMS([ENCODER:%d:%s]\n,
  encoder-base.base.id,
- drm_get_encoder_name(encoder-base));
+ encoder-base.name);
 
WARN(encoder-new_crtc-base != encoder-base.crtc,
 encoder's stage crtc doesn't match current crtc\n);
@@ -11526,7 +11526,7 @@ static void intel_sanitize_encoder(struct intel_encoder 
*encoder)
if (encoder-connectors_active  !has_active_crtc) {
DRM_DEBUG_KMS([ENCODER:%d:%s] has active connectors but no 
active pipe!\n,
  encoder-base.base.id,
- drm_get_encoder_name(encoder-base));
+ encoder-base.name);
 
/* Connector is active, but has no active pipe. This is
 * fallout from our resume register restoring. Disable
@@ -11534,7 +11534,7 @@ static void intel_sanitize_encoder(struct intel_encoder 
*encoder)
if (encoder-base.crtc) {
DRM_DEBUG_KMS([ENCODER:%d:%s] manually disabled\n,
  encoder-base.base.id,
- drm_get_encoder_name(encoder-base));
+ encoder-base.name);
encoder-disable(encoder);
}
 
@@ -11654,7 +11654,7 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
encoder-connectors_active = false;
DRM_DEBUG_KMS([ENCODER:%d:%s] hw state readout: %s, pipe %c\n,
  encoder-base.base.id,
- drm_get_encoder_name(encoder-base),
+ encoder-base.name,
  

Re: [Intel-gfx] [PATCH] drm/i915: Make intel_dsi_init() return void

[Jani Nikula]

On Wed, 28 May 2014, Damien Lespiau damien.lesp...@intel.com wrote:
 Functions that can't fail are such a bliss to work with, it'd be shame
 to miss the occasion. The failure mode is the DSI connector not being
 created, the rest of the initialization can carry on happily.

 We weren't even checking that value anyway.

 Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
 Suggested-by: Shobhit Kumar shobhit.ku...@intel.com
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Cc: Shobhit Kumar shobhit.ku...@intel.com
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/intel_drv.h |  2 +-
  drivers/gpu/drm/i915/intel_dsi.c | 12 ++--
  2 files changed, 7 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index edecf89..62686b2 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -831,7 +831,7 @@ void intel_edp_psr_update(struct drm_device *dev);
  void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
  
  /* intel_dsi.c */
 -bool intel_dsi_init(struct drm_device *dev);
 +void intel_dsi_init(struct drm_device *dev);
  
  
  /* intel_dvo.c */
 diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
 b/drivers/gpu/drm/i915/intel_dsi.c
 index e73bec6..4dbd160 100644
 --- a/drivers/gpu/drm/i915/intel_dsi.c
 +++ b/drivers/gpu/drm/i915/intel_dsi.c
 @@ -646,7 +646,7 @@ static const struct drm_connector_funcs 
 intel_dsi_connector_funcs = {
   .fill_modes = drm_helper_probe_single_connector_modes,
  };
  
 -bool intel_dsi_init(struct drm_device *dev)
 +void intel_dsi_init(struct drm_device *dev)
  {
   struct intel_dsi *intel_dsi;
   struct intel_encoder *intel_encoder;
 @@ -662,12 +662,12 @@ bool intel_dsi_init(struct drm_device *dev)
  
   intel_dsi = kzalloc(sizeof(*intel_dsi), GFP_KERNEL);
   if (!intel_dsi)
 - return false;
 + return;
  
   intel_connector = kzalloc(sizeof(*intel_connector), GFP_KERNEL);
   if (!intel_connector) {
   kfree(intel_dsi);
 - return false;
 + return;
   }
  
   intel_encoder = intel_dsi-base;
 @@ -678,7 +678,7 @@ bool intel_dsi_init(struct drm_device *dev)
   dev_priv-mipi_mmio_base = VLV_MIPI_BASE;
   } else {
   DRM_ERROR(Unsupported Mipi device to reg base);
 - return false;
 + return;
   }
  
   connector = intel_connector-base;
 @@ -738,12 +738,12 @@ bool intel_dsi_init(struct drm_device *dev)
   fixed_mode-type |= DRM_MODE_TYPE_PREFERRED;
   intel_panel_init(intel_connector-panel, fixed_mode, NULL);
  
 - return true;
 + return;
  
  err:
   drm_encoder_cleanup(intel_encoder-base);
   kfree(intel_dsi);
   kfree(intel_connector);
  
 - return false;
 + return;

Okay this went in already, but I find return statements at the end of
void functions like that a bit silly...

...but hey, you can send a fix removing that! ;)

BR,
Jani.


  }
 -- 
 1.8.3.1

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

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

[Intel-gfx] hsw edp regression (was: Re: World's worst bug report :)

[Jani Nikula]

Kenneth, please file a bug report on DRM/Intel at [1], with the below
information, and attach dmesg from boot with drm.debug=0xe module
parameter set.

Please find a further question below inline.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI

On Wed, 28 May 2014, Kenneth R. Crudup ke...@panix.com wrote:
 I tend to run the tip of Linus' master branch, and that's been working
 well. After merging in master about 3 weeks ago though, I'd often come
 back to a hard-hung laptop after being gone for 15-20 mins or so, i.e.,
 after the (blank-screen) screensaver had kicked in, but only when I'm
 at the office and I had a higher-res monitor (2560x1440) plugged in.

 I started going thru the i915 commit logs and after ruling out stuff
 that doesn't appear to apply to my laptop, I'd reverted:

   eeb6324d (drm/i915: consider the source max DP lane count too)
 and
   56071a20 (drm/i915: use lane count and link rate from VBT as minimums for 
 eDP)

 ... and when I'd come in this morning, my laptop was still up and came
 up from the screen saver (it stays on when I'm away from it and not
 suspended). Due to the sporadic nature of the hangs (not always
 reproducible) and time constraints on my part, I haven't narrowed down
 which commit seems to have broken things, but I hope this does help
 you guys to perhaps have an A-ha! moment.

 My laptop's a Toshiba Satellite P75-A7200 with a Haswell CPU and fairly
 standard i915 graphics:

 
 processor   : 0
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 60
 model name  : Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
 stepping: 3
 microcode   : 0x16
 cpu MHz : 886.500
 cache size  : 6144 KB
 physical id : 0
 siblings: 8
 core id : 0
 cpu cores   : 4
 apicid  : 0
 initial apicid  : 0
 fpu : yes
 fpu_exception   : yes
 cpuid level : 13
 wp  : yes
 
 00:02.0 0300: 8086:0416 (rev 06) (prog-if 00 [VGA controller])
 Subsystem: 1179:fa72
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 40
 Region 0: Memory at b200 (64-bit, non-prefetchable) [size=4M]
 Region 2: Memory at a000 (64-bit, prefetchable) [size=256M]
 Region 4: I/O ports at 5000 [size=64]
 Expansion ROM at unassigned [disabled]
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Address: feeff00c  Data: 4181
 Capabilities: [d0] Power Management version 2
 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
 PME(D0-,D1-,D2-,D3hot-,D3cold-)
 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [a4] PCI Advanced Features
 AFCap: TP+ FLR+
 AFCtrl: FLR-
 AFStatus: TP-
 Kernel driver in use: i915
 
 eDP1 connected primary 1920x1080+0+360 (normal left inverted right x axis y 
 axis) 381mm x 214mm
1920x1080  60.5*+   59.9 40.3
 
 HDMI1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 
 597mm x 336mm
 ...
 2560x1440_40   40.0*
 

 If you need any other information from me, please don't hesitate to ask.

 Thanks,

   -Kenny

 -- 
 Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Los Angeles


On Thu, 29 May 2014, Kenneth R. Crudup ke...@panix.com wrote:
 On Wed, 28 May 2014, Kenneth R. Crudup wrote:

 [I'd get] back to a hard-hung laptop after being gone for 15-20 mins
 ... after the (blank-screen) screensaver had kicked in, but only when I'm
 at the office and I had a higher-res monitor (2560x1440) plugged in.
 ...
   56071a20 (drm/i915: use lane count and link rate from VBT as minimums for 
 eDP)

 It's apparently this commit; reverting it (which also pulls f4cdbc214
 (drm/i915/dp: force eDP lane count to max available lanes on BDW) as
 a side-effect, which doesn't matter on my non-Broadwell machine anyway)
 seems to have stopped the panic-after-screen-off issue for me.

You refer both to a hard hang and a panic, which one is it? What
happens? Do you get a backtrace? Does the machine stop responding to
ping? Can you ssh in and get dmesg?

BR,
Jani.


 HTH someone,

   -Kenny

 -- 
 Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Los Angeles


-- 
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 intel_dsi_init() return void

[Damien Lespiau]

On Tue, Jun 03, 2014 at 03:05:14PM +0300, Jani Nikula wrote:
  -   return false;
  +   return;
 
 Okay this went in already, but I find return statements at the end of
 void functions like that a bit silly...
 
 ...but hey, you can send a fix removing that! ;)

Sigh, will do, thanks for pointed it out. 

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

[Intel-gfx] [PATCH] drm/i915: Remove return; at the end of a function returning void

[Damien Lespiau]

intel_dsi_init() lost its return value in:

  Damien Lespiau damien.lesp...@intel.com
  Date:   Wed May 28 12:30:56 2014 +0100

 drm/i915: Make intel_dsi_init() return void

However, I left a return; at the end of the function and, as Jani noticed, it
looks silly.

Suggested-by: Jani Nikula jani.nik...@linux.intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/i915/intel_dsi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 9d789b3..bd89de5 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -759,6 +759,4 @@ err:
drm_encoder_cleanup(intel_encoder-base);
kfree(intel_dsi);
kfree(intel_connector);
-
-   return;
 }
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove return; at the end of a function returning void

[Jani Nikula]

On Tue, 03 Jun 2014, Damien Lespiau damien.lesp...@intel.com wrote:
 intel_dsi_init() lost its return value in:

   Damien Lespiau damien.lesp...@intel.com
   Date:   Wed May 28 12:30:56 2014 +0100

  drm/i915: Make intel_dsi_init() return void

 However, I left a return; at the end of the function and, as Jani noticed, it
 looks silly.

Thanks. R-b and all that if Daniel needs it.

 Suggested-by: Jani Nikula jani.nik...@linux.intel.com
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dsi.c | 2 --
  1 file changed, 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
 b/drivers/gpu/drm/i915/intel_dsi.c
 index 9d789b3..bd89de5 100644
 --- a/drivers/gpu/drm/i915/intel_dsi.c
 +++ b/drivers/gpu/drm/i915/intel_dsi.c
 @@ -759,6 +759,4 @@ err:
   drm_encoder_cleanup(intel_encoder-base);
   kfree(intel_dsi);
   kfree(intel_connector);
 -
 - return;
  }
 -- 
 1.8.3.1


-- 
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: Remove return; at the end of a function returning void

[Damien Lespiau]

On Tue, Jun 03, 2014 at 04:35:01PM +0300, Jani Nikula wrote:
 On Tue, 03 Jun 2014, Damien Lespiau damien.lesp...@intel.com wrote:
  intel_dsi_init() lost its return value in:
 
Damien Lespiau damien.lesp...@intel.com
Date:   Wed May 28 12:30:56 2014 +0100
 
   drm/i915: Make intel_dsi_init() return void
 
  However, I left a return; at the end of the function and, as Jani noticed, 
  it
  looks silly.
 
 Thanks. R-b and all that if Daniel needs it.

If it's not too late to rewrite history, please consider squashing it
with:
drm/i915: Make intel_dsi_init() return void

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

[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko

[Daniel Vetter]

The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.

Cc: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 48e38ba22783..863db8415c22 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,8 +13,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
-   drm_rect.o drm_vma_manager.o drm_flip_work.o \
-   drm_plane_helper.o
+   drm_rect.o drm_vma_manager.o drm_flip_work.o
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
@@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 
 drm-usb-y   := drm_usb.o
 
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
+   drm_plane_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
-- 
2.0.0

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

[Intel-gfx] [PATCH] intel-gpu-tools: re-enable gem_exec_params on Android

[tim . gore]

From: Tim Gore tim.g...@intel.com

The missing macro that was preventing the gem_exec_params
test from building is now in i915_drm.h, in ABT at least,
and this test can now build. So I have removed it from the
skip list in Android.mk

For Gmin I have added a patch for i915_drm.h to the Wiki

Signed-off-by: Tim Gore tim.g...@intel.com
---
 tests/Android.mk | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/Android.mk b/tests/Android.mk
index dde2cd2..6e9dc67 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -32,7 +32,6 @@ skip_tests_list += gem_seqno_wrap
 skip_tests_list += testdisplay# needs glib.h
 skip_tests_list += pm_rpm
 skip_tests_list += kms_render # needs glib.h
-skip_tests_list += gem_exec_params# needs macro that's missing from 
external/PRIVATE/drm/include/drmi915_drm.h
 
 # set local compilation flags for IGT tests
 IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG
-- 
1.9.2

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

[Intel-gfx] [PATCH] intel-gpu-tools: remove testdisplay.h from kms_render.c

[tim . gore]

From: Tim Gore tim.g...@intel.com

kms_render.c included testdisplay.h but did not need it.
This was preventing it from building on Android due to the
lack of a Glib port. So I have removed this #include and
changed Android.mk so that kms_render is built if we have
cairo.

Signed-off-by: Tim Gore tim.g...@intel.com
---
 tests/Android.mk   | 4 ++--
 tests/kms_render.c | 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/tests/Android.mk b/tests/Android.mk
index 6e9dc67..3fd32f5 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -31,7 +31,6 @@ skip_tests_list :=
 skip_tests_list += gem_seqno_wrap
 skip_tests_list += testdisplay# needs glib.h
 skip_tests_list += pm_rpm
-skip_tests_list += kms_render # needs glib.h
 
 # set local compilation flags for IGT tests
 IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG
@@ -69,7 +68,8 @@ else
 gem_render_copy \
 pm_lpsp \
 kms_fence_pin_leak \
-kms_mmio_vs_cs_flip
+kms_mmio_vs_cs_flip \
+kms_render
 IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0
 endif
 
diff --git a/tests/kms_render.c b/tests/kms_render.c
index d9c0a58..6c742e2 100644
--- a/tests/kms_render.c
+++ b/tests/kms_render.c
@@ -31,7 +31,6 @@
 #include sys/time.h
 
 #include drmtest.h
-#include testdisplay.h
 #include intel_bufmgr.h
 #include intel_batchbuffer.h
 #include intel_io.h
-- 
1.9.2

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

[Intel-gfx] [PATCH] configure: Don't link the driver against libX11

[Adam Jackson]

78dc0c04745ad4485b994f67833f4a155749f01d added REQUIRED_MODULES to the
driver link line for... some reason.  That pulled in the libs from the
XF86DRI check, which near as I can tell has always been wrong, all of
the other extension checks just look for the protocol module and
xextproto doesn't define dri1 protocol in any case.

Signed-off-by: Adam Jackson a...@redhat.com
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 353f942..30bed3e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -330,7 +330,7 @@ fi
 # Store the list of server defined optional extensions in REQUIRED_MODULES
 XORG_DRIVER_CHECK_EXT(RANDR, randrproto)
 XORG_DRIVER_CHECK_EXT(RENDER, renderproto)
-XORG_DRIVER_CHECK_EXT(XF86DRI, xextproto x11)
+XORG_DRIVER_CHECK_EXT(XF86DRI, xf86driproto)
 XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
 
 # Obtain compiler/linker options for the driver dependencies
-- 
1.9.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove return; at the end of a function returning void

[Daniel Vetter]

On Tue, Jun 03, 2014 at 02:37:27PM +0100, Damien Lespiau wrote:
 On Tue, Jun 03, 2014 at 04:35:01PM +0300, Jani Nikula wrote:
  On Tue, 03 Jun 2014, Damien Lespiau damien.lesp...@intel.com wrote:
   intel_dsi_init() lost its return value in:
  
 Damien Lespiau damien.lesp...@intel.com
 Date:   Wed May 28 12:30:56 2014 +0100
  
drm/i915: Make intel_dsi_init() return void
  
   However, I left a return; at the end of the function and, as Jani 
   noticed, it
   looks silly.
  
  Thanks. R-b and all that if Daniel needs it.
 
 If it's not too late to rewrite history, please consider squashing it
 with:
   drm/i915: Make intel_dsi_init() return void

History is rectified.
-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] Breaking suspend/resume by the Pipe A quirk

[Thomas Richter]

Hi Daniel, dear intel experts,


We've put a crtc restriction on VGA (it needs to be crtc 0) to work around
some issues. DVI/LVDS should work on crtc 1. You can set this with the
--crtc knob for xrandr.

Unfortunately, I cannot. Whenever I put DVI1 (which is connected to the 
internal screen) on crt1,
the internal screen stays blank. Where would I need to modify the 
sources to test whether I could try

the reverse, i.e. drive VGA with crt1? (That's not possibly, as you say).

I neither found a way to un-clone the screens, i.e. you can say that 
xrandr should place VGA1 to the left
of DVI1, but xrandr --verbose still claims that VGA1 and DVI1 are clones 
of each other. The best you get is
a blank screen on DVI1, and a high-resolution display on VGA1, but not 
two independent monitors with

differing resolutions.

Here is the configuration when booting. It clones the monitors, even 
though the bios says internal only. Never mind,

this works:

(p.s. any news from the watermark-alignment patch? Is this acceptable?)

Screen 0: minimum 320 x 200, current 2048 x 1536, maximum 2048 x 2048
VGA1 disconnected 2048x1536+0+0 (0x48) normal (normal left inverted 
right x axis y axis) 0mm x 0mm panning 2048x1536+0+0

Identifier: 0x41
Timestamp:  463642
Subpixel:   unknown
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones: DVI1
CRTC:   0
CRTCs:  0
Panning:2048x1536+0+0
Tracking:   0x0+0+0
Border: 0/0/0/0
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter:
DVI1 connected 2048x1536+0+0 (0x48) normal (normal left inverted right x 
axis y axis) 0mm x 0mm panning 2048x1536+0+0

Identifier: 0x42
Timestamp:  463642
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones: VGA1
CRTC:   0
CRTCs:  0 1
Panning:2048x1536+0+0
Tracking:   0x0+0+0
Border: 0/0/0/0
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter:
  1024x768 (0x48)   65.0MHz -HSync -VSync *current
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   
48.4KHz
v: height  768 start  771 end  777 total  806   clock   
60.0Hz

  800x600 (0x4c)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   
37.9KHz
v: height  600 start  601 end  605 total  628   clock   
60.3Hz

  800x600 (0x4d)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   
35.2KHz
v: height  600 start  601 end  603 total  625   clock   
56.2Hz

  640x480 (0x52)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   
31.5KHz
v: height  480 start  489 end  492 total  525   clock   
59.9Hz


--

And this is the register dump:

 DCC: 0x (`7rbFtndu)
   CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh 
disabled, ch0 enh disabled, flex disabled, ep not present)

  C0DRB0: 0x (0x)
  C0DRB1: 0x (0x)
  C0DRB2: 0x (0x)
  C0DRB3: 0x (0x)
  C1DRB0: 0x (0x)
  C1DRB1: 0x (0x)
  C1DRB2: 0x (0x)
  C1DRB3: 0x (0x)
 C0DRA01: 0x (0x)
 C0DRA23: 0x (0x)
 C1DRA01: 0x (0x)
 C1DRA23: 0x (0x)
  PGETBL_CTL: 0x3ff60001
   VCLK_DIVISOR_VGA0: 0x00021207 (n = 2, m1 = 18, m2 = 7)
   VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6)
   VCLK_POST_DIV: 0x888b (vga0 p1 = 13, p2 = 4, vga1 p1 = 10, 
p2 = 4)
   DPLL_TEST: 0x (, DPLLA input buffer disabled, DPLLB 
input buffer disabled)

CACHE_MODE_0: 0x
 D_STATE: 0x
   DSPCLK_GATE_D: 0x0008 (clock gates disabled: OVRUNIT)
  RENCLK_GATE_D1: 0x
  RENCLK_GATE_D2: 0x
   SDVOB: 0x80004084 (enabled, pipe A, stall disabled, 
detected)
   SDVOC: 0x90004084 (enabled, pipe A, stall disabled, 
detected)

 SDVOUDI: 0x
  DSPARB: 0x00017e5f
  DSPFW1: 0x
  DSPFW2: 0x
  DSPFW3: 0x
ADPA: 0x8000 (enabled, pipe A, -hsync, -vsync)
LVDS: 0x (disabled, pipe A, 18 bit, 1 channel)
DVOA: 0x (disabled, pipe A, no stall, -hsync, 
-vsync)
DVOB: 0x80004084 (enabled, pipe A, no stall, -hsync, 
-vsync)

DVOC: 0x90004084 (enabled, pipe A, stall, -hsync, -vsync)
 DVOA_SRCDIM: 0x
 DVOB_SRCDIM: 0x
 DVOC_SRCDIM: 

Re: [Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko

[Matt Roper]

On Tue, Jun 03, 2014 at 03:38:56PM +0200, Daniel Vetter wrote:
 The drm core shouldn't depend upon any helpers, and we make sure this
 doesn't accidentally happen by moving them into the helper-only
 drm_kms_helper.ko module.
 
 Cc: Matt Roper matthew.d.ro...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Are there any KMS drivers that don't 'select DRM_KMS_HELPER' in their
Kconfig today?  From a quick grep + cscope it looks like radeon and
vmwgfx don't select the helper library.

Since drm_crtc_init() is part of the helper library now (since it
creates a helper-created primary plane), I think those drivers either
need to select the helper in their Kconfig to get a proper build, or
they need to be updated to provide their own primary planes and call
drm_crtc_init_with_planes(), right?


Matt

 ---
  drivers/gpu/drm/Makefile | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index 48e38ba22783..863db8415c22 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -13,8 +13,7 @@ drm-y   :=  drm_auth.o drm_buffer.o drm_bufs.o 
 drm_cache.o \
   drm_crtc.o drm_modes.o drm_edid.o \
   drm_info.o drm_debugfs.o drm_encoder_slave.o \
   drm_trace_points.o drm_global.o drm_prime.o \
 - drm_rect.o drm_vma_manager.o drm_flip_work.o \
 - drm_plane_helper.o
 + drm_rect.o drm_vma_manager.o drm_flip_work.o
  
  drm-$(CONFIG_COMPAT) += drm_ioc32.o
  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
  
  drm-usb-y   := drm_usb.o
  
 -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
 +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
 + drm_plane_helper.o
  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
  drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
 -- 
 2.0.0
 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling  Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk

[Daniel Vetter]

On Tue, Jun 03, 2014 at 04:38:40PM +0200, Thomas Richter wrote:
 Hi Daniel, dear intel experts,
 
 We've put a crtc restriction on VGA (it needs to be crtc 0) to work around
 some issues. DVI/LVDS should work on crtc 1. You can set this with the
 --crtc knob for xrandr.
 
 Unfortunately, I cannot. Whenever I put DVI1 (which is connected to the
 internal screen) on crt1,
 the internal screen stays blank. Where would I need to modify the sources to
 test whether I could try
 the reverse, i.e. drive VGA with crt1? (That's not possibly, as you say).


diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 22d8347f7838..80e3f1fc1ad6 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -833,10 +833,7 @@ void intel_crt_init(struct drm_device *dev)
 
crt-base.type = INTEL_OUTPUT_ANALOG;
crt-base.cloneable = (1  INTEL_OUTPUT_DVO) | (1  
INTEL_OUTPUT_HDMI);
-   if (IS_I830(dev))
-   crt-base.crtc_mask = (1  0);
-   else
-   crt-base.crtc_mask = (1  0) | (1  1) | (1  2);
+   crt-base.crtc_mask = (1  0) | (1  1) | (1  2);
 
if (IS_GEN2(dev))
connector-interlace_allowed = 0;

 I neither found a way to un-clone the screens, i.e. you can say that xrandr
 should place VGA1 to the left
 of DVI1, but xrandr --verbose still claims that VGA1 and DVI1 are clones of
 each other. The best you get is
 a blank screen on DVI1, and a high-resolution display on VGA1, but not two
 independent monitors with
 differing resolutions.

Yeah, if you can't move the panel to the crtc 1 only cloning will be
possible.

 Here is the configuration when booting. It clones the monitors, even though
 the bios says internal only. Never mind,
 this works:

Yeah, both connectors use CRTC 0. Have you tried what happens if you:
- disable DVI1 first (--off)
- then enable it on crtc 1?

Cheers, Daniel

 
 (p.s. any news from the watermark-alignment patch? Is this acceptable?)
 
 Screen 0: minimum 320 x 200, current 2048 x 1536, maximum 2048 x 2048
 VGA1 disconnected 2048x1536+0+0 (0x48) normal (normal left inverted right x
 axis y axis) 0mm x 0mm panning 2048x1536+0+0
 Identifier: 0x41
 Timestamp:  463642
 Subpixel:   unknown
 Gamma:  1.0:1.0:1.0
 Brightness: 1.0
 Clones: DVI1
 CRTC:   0
 CRTCs:  0
 Panning:2048x1536+0+0
 Tracking:   0x0+0+0
 Border: 0/0/0/0
 Transform:  1.00 0.00 0.00
 0.00 1.00 0.00
 0.00 0.00 1.00
filter:
 DVI1 connected 2048x1536+0+0 (0x48) normal (normal left inverted right x
 axis y axis) 0mm x 0mm panning 2048x1536+0+0
 Identifier: 0x42
 Timestamp:  463642
 Subpixel:   horizontal rgb
 Gamma:  1.0:1.0:1.0
 Brightness: 1.0
 Clones: VGA1
 CRTC:   0
 CRTCs:  0 1
 Panning:2048x1536+0+0
 Tracking:   0x0+0+0
 Border: 0/0/0/0
 Transform:  1.00 0.00 0.00
 0.00 1.00 0.00
 0.00 0.00 1.00
filter:
   1024x768 (0x48)   65.0MHz -HSync -VSync *current
 h: width  1024 start 1048 end 1184 total 1344 skew0 clock
 48.4KHz
 v: height  768 start  771 end  777 total  806   clock
 60.0Hz
   800x600 (0x4c)   40.0MHz +HSync +VSync
 h: width   800 start  840 end  968 total 1056 skew0 clock
 37.9KHz
 v: height  600 start  601 end  605 total  628   clock
 60.3Hz
   800x600 (0x4d)   36.0MHz +HSync +VSync
 h: width   800 start  824 end  896 total 1024 skew0 clock
 35.2KHz
 v: height  600 start  601 end  603 total  625   clock
 56.2Hz
   640x480 (0x52)   25.2MHz -HSync -VSync
 h: width   640 start  656 end  752 total  800 skew0 clock
 31.5KHz
 v: height  480 start  489 end  492 total  525   clock
 59.9Hz
 
 --
 
 And this is the register dump:
 
  DCC: 0x (`7rbFtndu)
CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled,
 ch0 enh disabled, flex disabled, ep not present)
   C0DRB0: 0x (0x)
   C0DRB1: 0x (0x)
   C0DRB2: 0x (0x)
   C0DRB3: 0x (0x)
   C1DRB0: 0x (0x)
   C1DRB1: 0x (0x)
   C1DRB2: 0x (0x)
   C1DRB3: 0x (0x)
  C0DRA01: 0x (0x)
  C0DRA23: 0x (0x)
  C1DRA01: 0x (0x)
  C1DRA23: 0x (0x)
   PGETBL_CTL: 0x3ff60001
VCLK_DIVISOR_VGA0: 0x00021207 (n = 2, m1 = 18, m2 = 7)
VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6)
VCLK_POST_DIV: 0x888b (vga0 p1 = 13, p2 = 4, vga1 p1 = 10, p2 =
 4)
DPLL_TEST: 0x (, DPLLA input buffer 

[Intel-gfx] [PATCH] quick_dump: make autodetect the default option

[Imre Deak]

Signed-off-by: Imre Deak imre.d...@intel.com
---
 tools/quick_dump/quick_dump.py | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
index 523f675..2eb7724 100755
--- a/tools/quick_dump/quick_dump.py
+++ b/tools/quick_dump/quick_dump.py
@@ -75,9 +75,6 @@ if __name__ == __main__:
 parser.add_argument('-b', '--baseless',
 action='store_true', default=False,
 help='baseless mode, ignore files starting with base_')
-parser.add_argument('-a', '--autodetect',
-action='store_true', default=False,
-help='autodetect chipset')
 parser.add_argument('-f', '--file',
 type=argparse.FileType('r'), default=None)
 parser.add_argument('profile', nargs='?',
@@ -101,7 +98,7 @@ if __name__ == __main__:
 if args.baseless == False:
 walk_base_files()
 
-if args.autodetect:
+if args.profile == None:
 args.profile = autodetect_chipset()
 
 if args.profile == None:
-- 
1.8.4

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

Re: [Intel-gfx] [PATCH] intel-gpu-tools: remove testdisplay.h from kms_render.c

[Daniel Vetter]

On Tue, Jun 03, 2014 at 03:18:31PM +0100, tim.g...@intel.com wrote:
 From: Tim Gore tim.g...@intel.com
 
 kms_render.c included testdisplay.h but did not need it.
 This was preventing it from building on Android due to the
 lack of a Glib port. So I have removed this #include and
 changed Android.mk so that kms_render is built if we have
 cairo.
 
 Signed-off-by: Tim Gore tim.g...@intel.com

Both patches merged, thanks.
-Daniel

 ---
  tests/Android.mk   | 4 ++--
  tests/kms_render.c | 1 -
  2 files changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/tests/Android.mk b/tests/Android.mk
 index 6e9dc67..3fd32f5 100644
 --- a/tests/Android.mk
 +++ b/tests/Android.mk
 @@ -31,7 +31,6 @@ skip_tests_list :=
  skip_tests_list += gem_seqno_wrap
  skip_tests_list += testdisplay# needs glib.h
  skip_tests_list += pm_rpm
 -skip_tests_list += kms_render # needs glib.h
  
  # set local compilation flags for IGT tests
  IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG
 @@ -69,7 +68,8 @@ else
  gem_render_copy \
  pm_lpsp \
  kms_fence_pin_leak \
 -kms_mmio_vs_cs_flip
 +kms_mmio_vs_cs_flip \
 +kms_render
  IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0
  endif
  
 diff --git a/tests/kms_render.c b/tests/kms_render.c
 index d9c0a58..6c742e2 100644
 --- a/tests/kms_render.c
 +++ b/tests/kms_render.c
 @@ -31,7 +31,6 @@
  #include sys/time.h
  
  #include drmtest.h
 -#include testdisplay.h
  #include intel_bufmgr.h
  #include intel_batchbuffer.h
  #include intel_io.h
 -- 
 1.9.2
 
 ___
 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

Re: [Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko

[Daniel Vetter]

On Tue, Jun 3, 2014 at 4:44 PM, Matt Roper matthew.d.ro...@intel.com wrote:
 On Tue, Jun 03, 2014 at 03:38:56PM +0200, Daniel Vetter wrote:
 The drm core shouldn't depend upon any helpers, and we make sure this
 doesn't accidentally happen by moving them into the helper-only
 drm_kms_helper.ko module.

 Cc: Matt Roper matthew.d.ro...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

 Are there any KMS drivers that don't 'select DRM_KMS_HELPER' in their
 Kconfig today?  From a quick grep + cscope it looks like radeon and
 vmwgfx don't select the helper library.

 Since drm_crtc_init() is part of the helper library now (since it
 creates a helper-created primary plane), I think those drivers either
 need to select the helper in their Kconfig to get a proper build, or
 they need to be updated to provide their own primary planes and call
 drm_crtc_init_with_planes(), right?

Radeon definitely uses the crtc helpers, so should have the dependency
somewhere. vmwgfx might indeed be broken now a bit. I'll wait for the
0-day kernel test build farm to confirm that ;-)
-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] [PATCH] configure: Don't link the driver against libX11

[Chris Wilson]

On Tue, Jun 03, 2014 at 10:26:46AM -0400, Adam Jackson wrote:
 78dc0c04745ad4485b994f67833f4a155749f01d added REQUIRED_MODULES to the
 driver link line for... some reason.  That pulled in the libs from the
 XF86DRI check, which near as I can tell has always been wrong, all of
 the other extension checks just look for the protocol module and
 xextproto doesn't define dri1 protocol in any case.
 
 Signed-off-by: Adam Jackson a...@redhat.com

Thanks, pushed. I then took it a step further and dropped xf86driproto
from our `pkg-config $REQUIRED_MODULES` check and made it only required
for DRI support with i810.
-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: Move plane helpers into drm_kms_helper.ko

[Matt Roper]

On Tue, Jun 03, 2014 at 04:49:25PM +0200, Daniel Vetter wrote:
 On Tue, Jun 3, 2014 at 4:44 PM, Matt Roper matthew.d.ro...@intel.com wrote:
  On Tue, Jun 03, 2014 at 03:38:56PM +0200, Daniel Vetter wrote:
  The drm core shouldn't depend upon any helpers, and we make sure this
  doesn't accidentally happen by moving them into the helper-only
  drm_kms_helper.ko module.
 
  Cc: Matt Roper matthew.d.ro...@intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
  Are there any KMS drivers that don't 'select DRM_KMS_HELPER' in their
  Kconfig today?  From a quick grep + cscope it looks like radeon and
  vmwgfx don't select the helper library.
 
  Since drm_crtc_init() is part of the helper library now (since it
  creates a helper-created primary plane), I think those drivers either
  need to select the helper in their Kconfig to get a proper build, or
  they need to be updated to provide their own primary planes and call
  drm_crtc_init_with_planes(), right?
 
 Radeon definitely uses the crtc helpers, so should have the dependency
 somewhere. vmwgfx might indeed be broken now a bit. I'll wait for the
 0-day kernel test build farm to confirm that ;-)
 -Daniel

Yeah, you're right; now that I look closer radeon pulls it in from the
main drm directory Kconfig and only has ums stuff in its driver
directory Kconfig.  But I think vmwgfx probably still needs to select
the helper library.

If vmwgfx gets a kconfig update to pull in the helper library, then this
is
Reviewed-by: Matt Roper matthew.d.ro...@intel.com


Matt


 -- 
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling  Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko

[Daniel Vetter]

The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.

v2: Don't break the build for vmwgfx, spotted by Matt.

Cc: Matt Roper matthew.d.ro...@intel.com
Cc: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/Makefile   | 6 +++---
 drivers/gpu/drm/vmwgfx/Kconfig | 3 +++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 48e38ba22783..863db8415c22 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,8 +13,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
-   drm_rect.o drm_vma_manager.o drm_flip_work.o \
-   drm_plane_helper.o
+   drm_rect.o drm_vma_manager.o drm_flip_work.o
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
@@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 
 drm-usb-y   := drm_usb.o
 
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
+   drm_plane_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
index b71bcd0bfbbf..653800e7bc7a 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -6,6 +6,9 @@ config DRM_VMWGFX
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select DRM_TTM
+   # Only needed for the transitional use of drm_crtc_init - can be removed
+   # again once vmwgfx sets up the primary plane itself.
+   select DRM_KMS_HELPER
help
  Choose this option if you would like to run 3D acceleration
  in a VMware virtual machine.
-- 
2.0.0

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

Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk

[Thomas Richter]

Am 03.06.2014 16:45, schrieb Daniel Vetter:



Yeah, both connectors use CRTC 0. Have you tried what happens if you:
- disable DVI1 first (--off)
- then enable it on crtc 1?


Same difference, internal screen goes blank with --off, and stays blank 
after moving it to crtc 1 if I try to re-enable it with --auto or --mode.


I'll try the above patch and then report again my findings, thanks!

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

Re: [Intel-gfx] [PATCH] quick_dump: make autodetect the default option

[Daniel Vetter]

On Tue, Jun 03, 2014 at 05:46:40PM +0300, Imre Deak wrote:
 Signed-off-by: Imre Deak imre.d...@intel.com

Very-much-wanted-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  tools/quick_dump/quick_dump.py | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)
 
 diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
 index 523f675..2eb7724 100755
 --- a/tools/quick_dump/quick_dump.py
 +++ b/tools/quick_dump/quick_dump.py
 @@ -75,9 +75,6 @@ if __name__ == __main__:
  parser.add_argument('-b', '--baseless',
  action='store_true', default=False,
  help='baseless mode, ignore files starting with base_')
 -parser.add_argument('-a', '--autodetect',
 -action='store_true', default=False,
 -help='autodetect chipset')
  parser.add_argument('-f', '--file',
  type=argparse.FileType('r'), default=None)
  parser.add_argument('profile', nargs='?',
 @@ -101,7 +98,7 @@ if __name__ == __main__:
  if args.baseless == False:
  walk_base_files()
  
 -if args.autodetect:
 +if args.profile == None:
  args.profile = autodetect_chipset()
  
  if args.profile == None:
 -- 
 1.8.4
 
 ___
 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

Re: [Intel-gfx] Fwd: __i915_gem_shrink / mm_find_pmd hogging CPU, then out of memory

[Chris Wilson]

On Mon, Jun 02, 2014 at 02:18:14PM +0100, Sam Jansen wrote:
Hello intel-gfx,
I'm working on an application using VA-API for H264 encode+decode, and
JPEG decode on an Atom E3815. Unfortunately we've hit what I believe is a
kernel bug, and the perf top output is pointing at i915 DRM code.
After some amount of time running my application, the system will become
unresponsive (userspace applications get very little CPU, system CPU will
go up to 80+%), and sometimes the system will appear out of memory for a
period (the OOM killer is sometimes invoked), even though there is a lot
of free memory on the system. I noticed this first on kernel 3.14.5, so I
moved to drm-intel-nightly, built on Friday (2014-05-30), from
[1]http://cgit.freedesktop.org/drm-intel. The results are the same.
Using perf top, I have gathered the following traces showing high system
CPU at the time when the system was encountering this problem:

It's a buffer leak in the userspace va-api application. The buffers
appear as cached memory, they are not yet accounted against the
applications that have a reference to them. Look at
/sys/kernel/debug/dri/0/i915_gem_objects for a breakdown of users.
-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] Breaking suspend/resume by the Pipe A quirk

[Thomas Richter]

Am 03.06.2014 17:14, schrieb Chris Wilson:

On Tue, Jun 03, 2014 at 05:04:52PM +0200, Thomas Richter wrote:

Am 03.06.2014 16:45, schrieb Daniel Vetter:



Yeah, both connectors use CRTC 0. Have you tried what happens if you:
- disable DVI1 first (--off)
- then enable it on crtc 1?


Same difference, internal screen goes blank with --off, and stays
blank after moving it to crtc 1 if I try to re-enable it with --auto
or --mode.


The oddity in the config is that the LVDS is reported as disconnected.
That should not be happening unless there is some sharing going on
inside the DVO chip.


Please note that on this specific notebook, the internal screen is 
connected via DVI, not via LVDS. I don't know what they did with the 
LVDS output, it's probably - as said - just disconnected.


The R31 has its panel connected via LVDS, and here I can set resolutions 
independently just fine.


Currently compiling the patch, takes a while on a 1GHhz/1GB P-3 machine. (-;

Greetings,
Thomas

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

Re: [Intel-gfx] [PATCH] quick_dump: make autodetect the default option

[Jani Nikula]

On Tue, 03 Jun 2014, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Jun 03, 2014 at 05:46:40PM +0300, Imre Deak wrote:
 Signed-off-by: Imre Deak imre.d...@intel.com

 Very-much-wanted-by: Daniel Vetter daniel.vet...@ffwll.ch

AOL'd-by: Jani Nikula jani.nik...@intel.com

 ---
  tools/quick_dump/quick_dump.py | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)
 
 diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
 index 523f675..2eb7724 100755
 --- a/tools/quick_dump/quick_dump.py
 +++ b/tools/quick_dump/quick_dump.py
 @@ -75,9 +75,6 @@ if __name__ == __main__:
  parser.add_argument('-b', '--baseless',
  action='store_true', default=False,
  help='baseless mode, ignore files starting with base_')
 -parser.add_argument('-a', '--autodetect',
 -action='store_true', default=False,
 -help='autodetect chipset')
  parser.add_argument('-f', '--file',
  type=argparse.FileType('r'), default=None)
  parser.add_argument('profile', nargs='?',
 @@ -101,7 +98,7 @@ if __name__ == __main__:
  if args.baseless == False:
  walk_base_files()
  
 -if args.autodetect:
 +if args.profile == None:
  args.profile = autodetect_chipset()
  
  if args.profile == None:
 -- 
 1.8.4
 
 ___
 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] Breaking suspend/resume by the Pipe A quirk

[Chris Wilson]

On Tue, Jun 03, 2014 at 05:19:26PM +0200, Thomas Richter wrote:
 Am 03.06.2014 17:14, schrieb Chris Wilson:
 On Tue, Jun 03, 2014 at 05:04:52PM +0200, Thomas Richter wrote:
 Am 03.06.2014 16:45, schrieb Daniel Vetter:
 
 
 Yeah, both connectors use CRTC 0. Have you tried what happens if you:
 - disable DVI1 first (--off)
 - then enable it on crtc 1?
 
 Same difference, internal screen goes blank with --off, and stays
 blank after moving it to crtc 1 if I try to re-enable it with --auto
 or --mode.
 
 The oddity in the config is that the LVDS is reported as disconnected.
 That should not be happening unless there is some sharing going on
 inside the DVO chip.
 
 Please note that on this specific notebook, the internal screen is
 connected via DVI, not via LVDS. I don't know what they did with the
 LVDS output, it's probably - as said - just disconnected.

I should have said VGA. Thinking about it, it is likely a shared DDC line
so that only a single EDID can be read.
-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] Breaking suspend/resume by the Pipe A quirk

[Thomas Richter]

Am 03.06.2014 17:26, schrieb Chris Wilson:



I should have said VGA. Thinking about it, it is likely a shared DDC line
so that only a single EDID can be read.


Actually, it gets the EDID from the VGA panel just fine, also shows me 
the modes it supports. DVI1 has no edit, though it gets its allowable 
modes from the dvo_ds2501 module.


I now tried to relocate VGA1 to crtc 1, with Daniel's patch. Results are 
even weirder. I can *set* the resolution to 1280x1024 on VGA1, just that 
it does not deliver this resolution. My monitor claims (and my vision 
confirms) that this is still the same 1024x768 mode as on the internal 
panel.


I can again turn VGA off, relocate it to crtc 1, turn it on again, still 
says its a clone of DVI1 even though it's on a different crtc.


Chipset (lspci) says its a 82830M/MG graphics controller, PCI id 
8086:3577. This *should* be a true 830MG (specs agree), thus I *believe* 
it should have two display pipes. The R31 is built around the very same 
chipset and has no problems with independent output. Looks like they 
shared the VGA and DVI output,and left the other output just dangling. 
Weird.


Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048
VGA1 connected 1280x1024+0+0 (0xa7) normal (normal left inverted right x 
axis y axis) 338mm x 270mm

Identifier: 0x41
Timestamp:  504191
Subpixel:   unknown
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones: DVI1
CRTC:   1
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter:
EDID:
00004c2d1d0037314847
1a0c01030f221b8cea6f8ba25a4d9424
1a5156bfef8081806140454031400101
010101010101302a009851002a403070
1300520e111e00fd0038551e
510e000a20202020202000fc0053
796e634d61737465720a202000ff
0048344c543630343930380a20200054
  1280x1024 (0xa7)  108.0MHz +HSync +VSync *current +preferred
h: width  1280 start 1328 end 1440 total 1688 skew0 clock 
 64.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock 
 60.0Hz

  1280x1024 (0xa8)  135.0MHz +HSync +VSync
h: width  1280 start 1296 end 1440 total 1688 skew0 clock 
 80.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock 
 75.0Hz

  1152x864 (0xa9)  108.0MHz +HSync +VSync
h: width  1152 start 1216 end 1344 total 1600 skew0 clock 
 67.5KHz
v: height  864 start  865 end  868 total  900   clock 
 75.0Hz

  1024x768 (0xaa)   78.8MHz +HSync +VSync
h: width  1024 start 1040 end 1136 total 1312 skew0 clock 
 60.1KHz
v: height  768 start  769 end  772 total  800   clock 
 75.1Hz

  1024x768 (0xab)   75.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1328 skew0 clock 
 56.5KHz
v: height  768 start  771 end  777 total  806   clock 
 70.1Hz

  1024x768 (0x43)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock 
 48.4KHz
v: height  768 start  771 end  777 total  806   clock 
 60.0Hz

  832x624 (0xac)   57.3MHz -HSync -VSync
h: width   832 start  864 end  928 total 1152 skew0 clock 
 49.7KHz
v: height  624 start  625 end  628 total  667   clock 
 74.6Hz

  800x600 (0xad)   50.0MHz +HSync +VSync
h: width   800 start  856 end  976 total 1040 skew0 clock 
 48.1KHz
v: height  600 start  637 end  643 total  666   clock 
 72.2Hz

  800x600 (0xae)   49.5MHz +HSync +VSync
h: width   800 start  816 end  896 total 1056 skew0 clock 
 46.9KHz
v: height  600 start  601 end  604 total  625   clock 
 75.0Hz

  800x600 (0x44)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock 
 37.9KHz
v: height  600 start  601 end  605 total  628   clock 
 60.3Hz

  800x600 (0x45)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock 
 35.2KHz
v: height  600 start  601 end  603 total  625   clock 
 56.2Hz

  640x480 (0xaf)   31.5MHz -HSync -VSync
h: width   640 start  656 end  720 total  840 skew0 clock 
 37.5KHz
v: height  480 start  481 end  484 total  500   clock 
 75.0Hz

  640x480 (0xb0)   31.5MHz -HSync -VSync
h: width   640 start  664 end  704 total  832 skew0 clock 
 37.9KHz
v: height  480 start  489 end  491 total  520   clock 
 72.8Hz

  640x480 (0xb1)   30.2MHz -HSync -VSync
h: width   640 start  704 end  768 total  864 skew0 clock 
 35.0KHz
v: height  480 start  483 end  486 total  525   clock 
 66.7Hz

  640x480 (0xb2)   25.2MHz -HSync -VSync
h: width  

Re: [Intel-gfx] Breaking suspend/resume by the Pipe A quirk

[Chris Wilson]

On Tue, Jun 03, 2014 at 05:50:06PM +0200, Thomas Richter wrote:
 Am 03.06.2014 17:26, schrieb Chris Wilson:
 
 
 I should have said VGA. Thinking about it, it is likely a shared DDC line
 so that only a single EDID can be read.
 
 Actually, it gets the EDID from the VGA panel just fine, also shows
 me the modes it supports. DVI1 has no edit, though it gets its
 allowable modes from the dvo_ds2501 module.
 
 I now tried to relocate VGA1 to crtc 1, with Daniel's patch. Results
 are even weirder. I can *set* the resolution to 1280x1024 on VGA1,
 just that it does not deliver this resolution. My monitor claims
 (and my vision confirms) that this is still the same 1024x768 mode
 as on the internal panel.
 
 I can again turn VGA off, relocate it to crtc 1, turn it on again,
 still says its a clone of DVI1 even though it's on a different crtc.
 
 Chipset (lspci) says its a 82830M/MG graphics controller, PCI id
 8086:3577. This *should* be a true 830MG (specs agree), thus I
 *believe* it should have two display pipes. The R31 is built around
 the very same chipset and has no problems with independent output.
 Looks like they shared the VGA and DVI output,and left the other
 output just dangling. Weird.
 
 Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048
 VGA1 connected 1280x1024+0+0 (0xa7) normal (normal left inverted
 right x axis y axis) 338mm x 270mm
   Identifier: 0x41
   Timestamp:  504191
   Subpixel:   unknown
   Gamma:  1.0:1.0:1.0
   Brightness: 1.0
   Clones: DVI1
^

This is short for Allowed Clones:, not Active Clones:.

   1280x1024 (0xa7)  108.0MHz +HSync +VSync *current +preferred
 h: width  1280 start 1328 end 1440 total 1688 skew0
 clock  64.0KHz
 v: height 1024 start 1025 end 1028 total 1066
 clock  60.0Hz

 DSPBCNTR: 0x9900 (enabled, pipe B)
   DSPBSTRIDE: 0x2000 (8192 bytes)
  DSPBPOS: 0x (0, 0)
 DSPBSIZE: 0x0257031f (800, 600)
 DSPBBASE: 0x04001000
 DSPBSURF: 0x
  DSPBTILEOFF: 0x
PIPEBCONF: 0x8000 (enabled, single-wide)
 PIPEBSRC: 0x031f0257 (800, 600)
PIPEBSTAT: 0x1206 (status: CRC_DONE_ENABLE
 HTOTAL_B: 0x041f031f (800 active, 1056 total)
 HBLANK_B: 0x041f031f (800 start, 1056 end)
  HSYNC_B: 0x03c70347 (840 start, 968 end)
 VTOTAL_B: 0x02730257 (600 active, 628 total)
 VBLANK_B: 0x02730257 (600 start, 628 end)
  VSYNC_B: 0x025c0258 (601 start, 605 end)

It's even worse than you thought. Somewhere between userspace passing in
the mode, and the kernel setting it, it got lost.

   CRTC:   1
   CRTCs:  0 1
   Transform:  1.00 0.00 0.00
   0.00 1.00 0.00
   0.00 0.00 1.00
  filter:
   1280x1024 (0xa7)  108.0MHz +HSync +VSync *current +preferred
 h: width  1280 start 1328 end 1440 total 1688 skew0
 clock  64.0KHz
 v: height 1024 start 1025 end 1028 total 1066

 DVI1 connected 1280x1024+0+0 (0x43) normal (normal left inverted
 ^

This means you have configured the two outputs in a mirrored mode, both
reading from the same portion of the framebuffer. So it just looks like
a cloned setup, with upset displays.

 right x axis y axis) 0mm x 0mm panning 1280x1024+0+0
   Identifier: 0x42
   Timestamp:  504191
   Subpixel:   horizontal rgb
   Gamma:  1.0:1.0:1.0
   Brightness: 1.0
   Clones: VGA1
   CRTC:   0
   CRTCs:  0 1
   Panning:1280x1024+0+0
   Tracking:   0x0+0+0
   Border: 0/0/0/0
   Transform:  1.00 0.00 0.00
   0.00 1.00 0.00
   0.00 0.00 1.00
  filter:
   1024x768 (0x43)   65.0MHz -HSync -VSync *current
 h: width  1024 start 1048 end 1184 total 1344 skew0
 clock  48.4KHz
 v: height  768 start  771 end  777 total  806
PIPEASTAT: 0x1207 (status: CRC_DONE_ENABLE

 DSPACNTR: 0x9800 (enabled, pipe A)
   DSPASTRIDE: 0x2000 (8192 bytes)
  DSPAPOS: 0x (0, 0)
 DSPASIZE: 0x02ff03ff (1024, 768)
 DSPABASE: 0x0400
 DSPASURF: 0x
  DSPATILEOFF: 0x
PIPEACONF: 0x8000 (enabled, single-wide)
 PIPEASRC: 0x03ff02ff (1024, 768)
 HTOTAL_A: 0x051f03ff (1024 active, 1312 total)
 HBLANK_A: 0x051f03ff (1024 start, 1312 end)
  HSYNC_A: 0x046f040f (1040 start, 1136 end)
 VTOTAL_A: 0x031f02ff (768 active, 800 total)
 VBLANK_A: 0x031f02ff (768 start, 800 end)
  VSYNC_A: 0x03030300 (769 start, 772 end)

At least this is sane.
-Chris

-- 
Chris Wilson, Intel Open 

[Intel-gfx] [PATCH] drm/i915/vlv: T12 eDP panel timing enforcement during reboot.

[clinton . a . taylor]

From: Clint Taylor clinton.a.tay...@intel.com

The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.

Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg

Ver3: moved SYS_RESTART check earlier, new name for pp_div.

Ver4: Minor issue changes

Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  |   42 ++
 drivers/gpu/drm/i915/intel_drv.h |2 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ca68aa9..cede9bc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -28,6 +28,8 @@
 #include linux/i2c.h
 #include linux/slab.h
 #include linux/export.h
+#include linux/notifier.h
+#include linux/reboot.h
 #include drm/drmP.h
 #include drm/drm_crtc.h
 #include drm/drm_crtc_helper.h
@@ -302,6 +304,38 @@ static u32 _pp_stat_reg(struct intel_dp *intel_dp)
return VLV_PIPE_PP_STATUS(vlv_power_sequencer_pipe(intel_dp));
 }
 
+/* Reboot notifier handler to shutdown panel power to guarantee T12 timing */
+static int edp_notify_handler(struct notifier_block *this, unsigned long code,
+ void *unused)
+{
+   struct intel_dp *intel_dp = container_of(this, typeof(* intel_dp),
+edp_notifier);
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = intel_dig_port-base.base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   u32 pp_div;
+   u32 pp_ctrl_reg, pp_div_reg;
+   enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+
+   if (!is_edp(intel_dp) || code != SYS_RESTART )
+   return 0;
+
+   if (IS_VALLEYVIEW(dev)) {
+   pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
+   pp_div_reg  = VLV_PIPE_PP_DIVISOR(pipe);
+   pp_div = I915_READ(VLV_PIPE_PP_DIVISOR(pipe));
+   pp_div = PP_REFERENCE_DIVIDER_MASK;
+
+   /* 0x1F write to PP_DIV_REG sets max cycle delay */
+   I915_WRITE(pp_div_reg, pp_div | 0x1F);
+   I915_WRITE(pp_ctrl_reg,
+  PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+   msleep(intel_dp-panel_power_cycle_delay);
+   }
+
+   return 0;
+}
+
 static bool edp_have_panel_power(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -3344,6 +3378,10 @@ void intel_dp_encoder_destroy(struct drm_encoder 
*encoder)
mutex_lock(dev-mode_config.mutex);
edp_panel_vdd_off_sync(intel_dp);
mutex_unlock(dev-mode_config.mutex);
+   if (intel_dp-edp_notifier.notifier_call) {
+   unregister_reboot_notifier(intel_dp-edp_notifier);
+   intel_dp-edp_notifier.notifier_call = NULL;
+   }
}
kfree(intel_dig_port);
 }
@@ -3782,6 +3820,10 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
if (is_edp(intel_dp)) {
intel_dp_init_panel_power_timestamps(intel_dp);
intel_dp_init_panel_power_sequencer(dev, intel_dp, power_seq);
+   if (IS_VALLEYVIEW(dev)) {
+   intel_dp-edp_notifier.notifier_call = 
edp_notify_handler;
+   register_reboot_notifier(intel_dp-edp_notifier);
+   }
}
 
intel_dp_aux_init(intel_dp, intel_connector);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 328b1a7..6d0d96e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -510,6 +510,8 @@ struct intel_dp {
unsigned long last_power_on;
unsigned long last_backlight_off;
bool psr_setup_done;
+   struct notifier_block edp_notifier;
+
bool use_tps3;
struct intel_connector *attached_connector;
 
-- 
1.7.9.5

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

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

[Stéphane Marchesin]

On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula jani.nik...@intel.com wrote:
 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.

This is the part we've been relying on in Chrome OS (we assume that 0
means off). It seems to me that i915 would be the first, or one of the
first drivers to violate this rule (in particular you can find a lot
of backlight drivers trying hard to ensure that 0 means off in the
backlight drivers directory).

For context, we use backlight = 0 as a quick turn the panel off
function where possible. This allows us to avoid the panel off delay
where possible. Breaking this assumption means that we'd pay the panel
off delay penalty everywhere, not just with BYT.

Stéphane


 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.

 Signed-off-by: Jani Nikula jani.nik...@intel.com

 ---

 UNTESTED!
 ---
  drivers/gpu/drm/i915/i915_drv.h|  1 +
  drivers/gpu/drm/i915/intel_bios.c  |  3 +-
  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_panel.c | 97 
 +++---
  4 files changed, 85 insertions(+), 17 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 50dfc3a1a9d1..d9dad3498b87 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1164,6 +1164,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 2945f57c53ee..1a3e172029b3 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -339,11 +339,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]);
  }

 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index d8b540b891d1..2af74dd03e31 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 */
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index 776249bab488..360ae203aacb 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -398,6 +398,30 @@ intel_panel_detect(struct drm_device *dev)
 }
  }

 +/* Scale user_level in range [0..user_max] to [hw_min..hw_max]. */
 +static u32 scale_user_to_hw(struct intel_connector *connector,
 +   u32 user_level, u32 user_max)
 +{
 +   struct intel_panel *panel = connector-panel;
 +
 +   user_level = clamp(user_level, 0U, user_max);
 +
 +   return panel-backlight.min + user_level *
 +   (panel-backlight.max - panel-backlight.min) / user_max;
 +}
 +
 +/* Scale hw_level in range [hw_min..hw_max] to [0..user_max]. */
 +static u32 scale_hw_to_user(struct intel_connector *connector,
 +   u32 hw_level, u32 user_max)
 +{
 +   struct intel_panel *panel = connector-panel;
 +
 +   hw_level = clamp(hw_level, panel-backlight.min, 
 panel-backlight.max);
 +
 +   return (hw_level - 

[Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko

[Daniel Vetter]

The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.

v2: Don't break the build for vmwgfx, spotted by Matt.

v3: Unbreak the depency loop around CONFIG_FB (not actually a loop
since it involves select). Reported by Chris.

Cc: Matt Roper matthew.d.ro...@intel.com
Cc: Thomas Hellstrom thellst...@vmware.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/Makefile   | 6 +++---
 drivers/gpu/drm/vmwgfx/Kconfig | 7 +--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 48e38ba22783..863db8415c22 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,8 +13,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
-   drm_rect.o drm_vma_manager.o drm_flip_work.o \
-   drm_plane_helper.o
+   drm_rect.o drm_vma_manager.o drm_flip_work.o
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
@@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 
 drm-usb-y   := drm_usb.o
 
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
+   drm_plane_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
index b71bcd0bfbbf..67720f70fe29 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -1,11 +1,14 @@
 config DRM_VMWGFX
tristate DRM driver for VMware Virtual GPU
-   depends on DRM  PCI  FB
+   depends on DRM  PCI
select FB_DEFERRED_IO
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select DRM_TTM
+   # Only needed for the transitional use of drm_crtc_init - can be removed
+   # again once vmwgfx sets up the primary plane itself.
+   select DRM_KMS_HELPER
help
  Choose this option if you would like to run 3D acceleration
  in a VMware virtual machine.
@@ -14,7 +17,7 @@ config DRM_VMWGFX
  The compiled module will be called vmwgfx.ko.
 
 config DRM_VMWGFX_FBCON
-   depends on DRM_VMWGFX
+   depends on DRM_VMWGFX  FB
bool Enable framebuffer console under vmwgfx by default
help
   Choose this option if you are shipping a new vmwgfx
-- 
2.0.0

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

Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Add vblank based delayed watermark update mechanism

[Paulo Zanoni]

2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
 From: Ville Syrjälä ville.syrj...@linux.intel.com

 Add a mechanism by which you can queue up watermark update to happen
 after the vblank counter has reached a certain value. The vblank
 interrupt handler will schedule a work which will do the actual
 watermark programming in process context.

 v2: Rebase and s/intel_crtc/crtc/

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/i915_irq.c  |  12 ++-
  drivers/gpu/drm/i915/intel_display.c |   1 +
  drivers/gpu/drm/i915/intel_drv.h |  27 +++
  drivers/gpu/drm/i915/intel_pm.c  | 144 
 +++
  5 files changed, 183 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index a2302a7..c90d5ac 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1541,6 +1541,8 @@ struct drm_i915_private {
  * state as well as the actual hardware registers
  */
 struct mutex mutex;
 +
 +   struct work_struct work;
 } wm;

 struct i915_runtime_pm pm;
 diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
 index 304f86a..c680020 100644
 --- a/drivers/gpu/drm/i915/i915_irq.c
 +++ b/drivers/gpu/drm/i915/i915_irq.c
 @@ -2067,8 +2067,10 @@ static void ilk_display_irq_handler(struct drm_device 
 *dev, u32 de_iir)
 DRM_ERROR(Poison interrupt\n);

 for_each_pipe(pipe) {
 -   if (de_iir  DE_PIPE_VBLANK(pipe))
 +   if (de_iir  DE_PIPE_VBLANK(pipe)) {
 intel_pipe_handle_vblank(dev, pipe);
 +   ilk_update_pipe_wm(dev, pipe);
 +   }

 if (de_iir  DE_PIPE_FIFO_UNDERRUN(pipe))
 if (intel_set_cpu_fifo_underrun_reporting(dev, pipe, 
 false))
 @@ -2117,8 +2119,10 @@ static void ivb_display_irq_handler(struct drm_device 
 *dev, u32 de_iir)
 intel_opregion_asle_intr(dev);

 for_each_pipe(pipe) {
 -   if (de_iir  (DE_PIPE_VBLANK_IVB(pipe)))
 +   if (de_iir  (DE_PIPE_VBLANK_IVB(pipe))) {
 intel_pipe_handle_vblank(dev, pipe);
 +   ilk_update_pipe_wm(dev, pipe);
 +   }

 /* plane/pipes map 1:1 on ilk+ */
 if (de_iir  DE_PLANE_FLIP_DONE_IVB(pipe)) {
 @@ -2260,8 +2264,10 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
 continue;

 pipe_iir = I915_READ(GEN8_DE_PIPE_IIR(pipe));
 -   if (pipe_iir  GEN8_PIPE_VBLANK)
 +   if (pipe_iir  GEN8_PIPE_VBLANK) {
 intel_pipe_handle_vblank(dev, pipe);
 +   ilk_update_pipe_wm(dev, pipe);
 +   }

 if (pipe_iir  GEN8_PIPE_PRIMARY_FLIP_DONE) {
 intel_prepare_page_flip(dev, pipe);
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index a11bd78..408b238 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -10961,6 +10961,7 @@ static void intel_crtc_init(struct drm_device *dev, 
 int pipe)
 intel_crtc-plane = !pipe;
 }

 +   spin_lock_init(intel_crtc-wm.lock);
 init_waitqueue_head(intel_crtc-vbl_wait);

 BUG_ON(pipe = ARRAY_SIZE(dev_priv-plane_to_crtc_mapping) ||
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index d75cc2b..72f01b1 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -409,6 +409,32 @@ struct intel_crtc {
  * protected by dev_priv-wm.mutex
  */
 struct intel_pipe_wm active;
 +   /*
 +* watermarks queued for next vblank
 +* protected by dev_priv-wm.mutex
 +*/
 +   struct intel_pipe_wm pending;
 +
 +   /*
 +* the vblank count after which we can switch over to 
 'pending'
 +* protected by intel_crtc-wm.lock
 +*/
 +   u32 pending_vbl_count;
 +   /*
 +* indicates that 'pending' contains changed watermarks
 +* protected by intel_crtc-wm.lock
 +*/
 +   bool dirty;
 +   /*
 +* watermark update has a vblank reference?
 +* protected by intel_crtc-wm.lock
 +*/
 +   bool vblank;

I would rename this variable. Maybe has_vblank_ref?


 +
 +   /*
 +* protects some intel_crtc-wm state

Please be more precise on what some actually means, since it's easy
to guess that a spinlock protects some 

Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Add vblank based delayed watermark update mechanism

[Ville Syrjälä]

On Tue, Jun 03, 2014 at 03:50:12PM -0300, Paulo Zanoni wrote:
 2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  Add a mechanism by which you can queue up watermark update to happen
  after the vblank counter has reached a certain value. The vblank
  interrupt handler will schedule a work which will do the actual
  watermark programming in process context.
 
  v2: Rebase and s/intel_crtc/crtc/
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/i915_drv.h  |   2 +
   drivers/gpu/drm/i915/i915_irq.c  |  12 ++-
   drivers/gpu/drm/i915/intel_display.c |   1 +
   drivers/gpu/drm/i915/intel_drv.h |  27 +++
   drivers/gpu/drm/i915/intel_pm.c  | 144 
  +++
   5 files changed, 183 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h
  index a2302a7..c90d5ac 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -1541,6 +1541,8 @@ struct drm_i915_private {
   * state as well as the actual hardware registers
   */
  struct mutex mutex;
  +
  +   struct work_struct work;
  } wm;
 
  struct i915_runtime_pm pm;
  diff --git a/drivers/gpu/drm/i915/i915_irq.c 
  b/drivers/gpu/drm/i915/i915_irq.c
  index 304f86a..c680020 100644
  --- a/drivers/gpu/drm/i915/i915_irq.c
  +++ b/drivers/gpu/drm/i915/i915_irq.c
  @@ -2067,8 +2067,10 @@ static void ilk_display_irq_handler(struct 
  drm_device *dev, u32 de_iir)
  DRM_ERROR(Poison interrupt\n);
 
  for_each_pipe(pipe) {
  -   if (de_iir  DE_PIPE_VBLANK(pipe))
  +   if (de_iir  DE_PIPE_VBLANK(pipe)) {
  intel_pipe_handle_vblank(dev, pipe);
  +   ilk_update_pipe_wm(dev, pipe);
  +   }
 
  if (de_iir  DE_PIPE_FIFO_UNDERRUN(pipe))
  if (intel_set_cpu_fifo_underrun_reporting(dev, 
  pipe, false))
  @@ -2117,8 +2119,10 @@ static void ivb_display_irq_handler(struct 
  drm_device *dev, u32 de_iir)
  intel_opregion_asle_intr(dev);
 
  for_each_pipe(pipe) {
  -   if (de_iir  (DE_PIPE_VBLANK_IVB(pipe)))
  +   if (de_iir  (DE_PIPE_VBLANK_IVB(pipe))) {
  intel_pipe_handle_vblank(dev, pipe);
  +   ilk_update_pipe_wm(dev, pipe);
  +   }
 
  /* plane/pipes map 1:1 on ilk+ */
  if (de_iir  DE_PLANE_FLIP_DONE_IVB(pipe)) {
  @@ -2260,8 +2264,10 @@ static irqreturn_t gen8_irq_handler(int irq, void 
  *arg)
  continue;
 
  pipe_iir = I915_READ(GEN8_DE_PIPE_IIR(pipe));
  -   if (pipe_iir  GEN8_PIPE_VBLANK)
  +   if (pipe_iir  GEN8_PIPE_VBLANK) {
  intel_pipe_handle_vblank(dev, pipe);
  +   ilk_update_pipe_wm(dev, pipe);
  +   }
 
  if (pipe_iir  GEN8_PIPE_PRIMARY_FLIP_DONE) {
  intel_prepare_page_flip(dev, pipe);
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index a11bd78..408b238 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -10961,6 +10961,7 @@ static void intel_crtc_init(struct drm_device *dev, 
  int pipe)
  intel_crtc-plane = !pipe;
  }
 
  +   spin_lock_init(intel_crtc-wm.lock);
  init_waitqueue_head(intel_crtc-vbl_wait);
 
  BUG_ON(pipe = ARRAY_SIZE(dev_priv-plane_to_crtc_mapping) ||
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index d75cc2b..72f01b1 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -409,6 +409,32 @@ struct intel_crtc {
   * protected by dev_priv-wm.mutex
   */
  struct intel_pipe_wm active;
  +   /*
  +* watermarks queued for next vblank
  +* protected by dev_priv-wm.mutex
  +*/
  +   struct intel_pipe_wm pending;
  +
  +   /*
  +* the vblank count after which we can switch over to 
  'pending'
  +* protected by intel_crtc-wm.lock
  +*/
  +   u32 pending_vbl_count;
  +   /*
  +* indicates that 'pending' contains changed watermarks
  +* protected by intel_crtc-wm.lock
  +*/
  +   bool dirty;
  +   /*
  +* watermark update has a vblank reference?
  +* protected by intel_crtc-wm.lock
  +*/
  +   bool vblank;
 
 I would rename this variable. Maybe 

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

[Daniel Vetter]

On Tue, Jun 3, 2014 at 6:40 PM, Stéphane Marchesin marc...@chromium.org wrote:
 On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula jani.nik...@intel.com wrote:
 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.

 This is the part we've been relying on in Chrome OS (we assume that 0
 means off). It seems to me that i915 would be the first, or one of the
 first drivers to violate this rule (in particular you can find a lot
 of backlight drivers trying hard to ensure that 0 means off in the
 backlight drivers directory).

 For context, we use backlight = 0 as a quick turn the panel off
 function where possible. This allows us to avoid the panel off delay
 where possible. Breaking this assumption means that we'd pay the panel
 off delay penalty everywhere, not just with BYT.

Well kde is the opposite and I've had users yelling at me that they
can't use their system, since acpi pretty much always leaves the
backlight on when set to 0. And acpi kinda rules on intel platforms.
So I think I'll merge this one since black screens trumps a slight
functional degration and we didn't duct-tape over the kde assumptions
either. Essentially you can't assume anything about backlight values
besides that bigger values tends to mean brigther. Linearity, absolute
values and endpoints are kinda all off.

If we want to specifically expose an intermediate panel off level
because the full link training is too expensive we imo should do this
as an intermediate dpms level, e.g. dpms standby.
-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] [PATCH v2 08/16] drm/i915: Split watermark programming into pre and post steps

[Paulo Zanoni]

2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
 From: Ville Syrjälä ville.syrj...@linux.intel.com

 We need to perform watermark programming before and after changing the
 plane configuration. Add two new vfuncs to do that. The pre phase is
 supposed to switch over to the intermediate watermarks which are
 computed so that they can deal with both the old and new plane
 configurations. The post phase will arm the vblank based update
 systems to switch over to the optimal target watermarks after the
 plane configuration has for sure changed.

 v2: Pass around intel_crtc and s/intel_crtc/crtc/

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.h  |  5 +++
  drivers/gpu/drm/i915/intel_drv.h | 11 +
  drivers/gpu/drm/i915/intel_pm.c  | 88 
 
  3 files changed, 104 insertions(+)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index c90d5ac..d4f8ae8 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -407,6 +407,7 @@ struct intel_plane_config;
  struct intel_crtc;
  struct intel_limit;
  struct dpll;
 +struct intel_crtc_wm_config;

  struct drm_i915_display_funcs {
 bool (*fbc_enabled)(struct drm_device *dev);
 @@ -437,6 +438,10 @@ struct drm_i915_display_funcs {
  struct drm_crtc *crtc,
  uint32_t sprite_width, int pixel_size,
  bool enable, bool scaled);
 +   void (*program_wm_pre)(struct intel_crtc *crtc,
 +  const struct intel_crtc_wm_config *config);
 +   void (*program_wm_post)(struct intel_crtc *crtc,
 +   const struct intel_crtc_wm_config *config);
 void (*modeset_global_resources)(struct drm_device *dev);
 /* Returns the active state of the crtc, and if the crtc is active,
  * fills out the pipe-config with the hw state. */
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 72f01b1..4b59be3 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -358,6 +358,13 @@ struct intel_pipe_wm {
 bool sprites_scaled;
  };

 +struct intel_crtc_wm_config {
 +   /* target watermarks for the pipe */
 +   struct intel_pipe_wm target;
 +   /* intermediate watermarks for pending/active-target transition */
 +   struct intel_pipe_wm intm;

It seems you always prefer shorter names such as intm, and I usually
prefer the longer ones like intermediate. Looks like this is a
common topic for my bikesheddings on your patches. When I read intm
my brain parses it as Int M and then aborts execution =P

With or without that changed: Reviewed-by: Paulo Zanoni
paulo.r.zan...@intel.com

 +};
 +
  struct intel_crtc {
 struct drm_crtc base;
 enum pipe pipe;
 @@ -1001,6 +1008,10 @@ void intel_init_runtime_pm(struct drm_i915_private 
 *dev_priv);
  void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
  void ilk_wm_get_hw_state(struct drm_device *dev);
  void ilk_update_pipe_wm(struct drm_device *dev, enum pipe pipe);
 +void intel_program_watermarks_pre(struct intel_crtc *crtc,
 + const struct intel_crtc_wm_config *config);
 +void intel_program_watermarks_post(struct intel_crtc *crtc,
 +  const struct intel_crtc_wm_config *config);


  /* intel_sdvo.c */
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 6fc6416..ccf920a 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2950,6 +2950,20 @@ void ilk_update_pipe_wm(struct drm_device *dev, enum 
 pipe pipe)
 spin_unlock(crtc-wm.lock);
  }

 +static void ilk_wm_cancel(struct intel_crtc *crtc)
 +{
 +   struct drm_device *dev = crtc-base.dev;
 +
 +   assert_spin_locked(crtc-wm.lock);
 +
 +   crtc-wm.dirty = false;
 +
 +   if (crtc-wm.vblank) {
 +   drm_vblank_put(dev, crtc-pipe);
 +   crtc-wm.vblank = false;
 +   }
 +}
 +
  static void ilk_update_sprite_wm(struct drm_plane *plane,
  struct drm_crtc *crtc,
  uint32_t sprite_width, int pixel_size,
 @@ -3084,6 +3098,24 @@ void intel_update_sprite_watermarks(struct drm_plane 
 *plane,
pixel_size, enabled, 
 scaled);
  }

 +void intel_program_watermarks_pre(struct intel_crtc *crtc,
 + const struct intel_crtc_wm_config *config)
 +{
 +   struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
 +
 +   if (dev_priv-display.program_wm_pre)
 +   dev_priv-display.program_wm_pre(crtc, config);
 +}
 +
 +void intel_program_watermarks_post(struct intel_crtc *crtc,
 +  const struct 

[Intel-gfx] [PATCH] rendercopy/gen8: Also emit 3DSTATE_WM_DEPTH_STENCIL.

[Kenneth Graunke]

rendercopy was failing to emit 3DSTATE_WM_DEPTH_STENCIL, which is a new
packet on Broadwell.  Mesa emits this packet.

This appears to fix various tests on a fresh boot, when Mesa has never
run.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78890
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78935
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78936
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78937
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78938
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Ben Widawsky b...@bwidawsk.net
---
 lib/gen8_render.h | 1 +
 lib/rendercopy_gen8.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/lib/gen8_render.h b/lib/gen8_render.h
index fffc100..0eec80c 100644
--- a/lib/gen8_render.h
+++ b/lib/gen8_render.h
@@ -48,6 +48,7 @@
GEN6_3D(3, 0, 0x21)
 #define GEN8_3DSTATE_PS_BLEND  GEN6_3D(3, 0, 0x4d)
 # define GEN8_PS_BLEND_HAS_WRITEABLE_RT(1  30)
+#define GEN8_3DSTATE_WM_DEPTH_STENCIL  GEN6_3D(3, 0, 0x4e)
 #define GEN8_3DSTATE_PS_EXTRA  GEN6_3D(3,0, 0x4f)
 # define GEN8_PSX_PIXEL_SHADER_VALID   (1  31)
 # define GEN8_PSX_ATTRIBUTE_ENABLE (1  8)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 6f5a698..e7567d2 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -816,6 +816,10 @@ gen8_emit_ps(struct intel_batchbuffer *batch, uint32_t 
kernel) {
 
 static void
 gen8_emit_depth(struct intel_batchbuffer *batch) {
+   OUT_BATCH(GEN8_3DSTATE_WM_DEPTH_STENCIL | (3 - 2));
+   OUT_BATCH(0);
+   OUT_BATCH(0);
+
OUT_BATCH(GEN7_3DSTATE_DEPTH_BUFFER | (8-2));
OUT_BATCH(0);
OUT_BATCH(0);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] rendercopy/gen8: Also emit 3DSTATE_WM_DEPTH_STENCIL.

[Ben Widawsky]

On Tue, Jun 03, 2014 at 02:52:30PM -0700, Kenneth Graunke wrote:
 rendercopy was failing to emit 3DSTATE_WM_DEPTH_STENCIL, which is a new
 packet on Broadwell.  Mesa emits this packet.
 
 This appears to fix various tests on a fresh boot, when Mesa has never
 run.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78890
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78891
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78935
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78936
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78937
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78938
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 Cc: Ben Widawsky b...@bwidawsk.net

I sat with Ken all day today (after a few days of debugging myself) and
it does what it purport to do, and fixes a bunch of tests.

Reviewed-by: Ben Widawsky b...@bwidawsk.net

FWIW: I don't think we need to update the null state in the kernel. It's
actually kind of nice for finding userspace bugs.

-- 
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 v2 09/16] drm/i915: Actually perform the watermark update in two phases

[Paulo Zanoni]

2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
 From: Ville Syrjälä ville.syrj...@linux.intel.com

 Switch the code over to using the two phase watermark update. The steps
 generally follow this pattern:

 1. Calculate new plane parameters for changed planes
 2. Calculate new target and intermediate watermarks
 3. Check that both the target and intermediate watermarks are valid
 4. Program the hardware with the intermediate watermarks
 5. Program the plane registers
 6. Arm the vblank watermark update machinery for the next vblank
 7. Program the hardware with the target watermarks (after vblank)

 v2: Rebased, pass intel_crtc around, s/intel_crtc/crtc/

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

This patch is huge. If we bisect any regression to it, we will be
completely lost and hopeless. Also, my tiny little brain doesn't have
enough power to do a proper review of this patch with so many changes
happening all at the same place. I tried, but I gave up in the middle.

Please try to convert this patch into many smaller patches. I don't
know if the following idea is actually possible, but it is what I
could extract from what I read of your patch:
- I'd start with the way you update watermarks parameters. Start by
patching ilk_compute_wm_parameters() and making it directly call your
new update_xxx_params() functions. You can even do separate patches
for _pri, _cur and _spr patches since it seems the _spr code is
different for most of your patch due to the old
intel_update_sprite_watermarks() function.
- Then you change the way you use to set your parameters (there's a
comment below mentioning the specific line which I'm talking about
here)
- Then you can patch intel_display.c so you will only update the WM
params when you actually change the HW (the _hw_plane and
update_cursor functions). Again, you can even split _pri, _cur and
_spr on separate patches.
- Then you can introduce the update_cursor_wm() and
update_primary_wm() functions, but still make them call the old-style
intel_update_watermarks() or something similar.
- You can also add the functions to deal with intermediate watermarks,
but without using them. Or you could, for example, make the
intermediate watermarks just be the same as the old ones, so the
only real update will be the final one (which, I believe, will mean
the code still behaves as it does today, no regressions).
- Then you can add the final piece of the code that uses all the new
infrastructure to actually generate and use the intermediate
watermarks. And this would be a much smaller patch.

There are still some comments below:

 ---
  drivers/gpu/drm/i915/i915_drv.h  |  14 ++-
  drivers/gpu/drm/i915/intel_display.c |  58 -
  drivers/gpu/drm/i915/intel_drv.h |  35 --
  drivers/gpu/drm/i915/intel_pm.c  | 229 
 +++
  drivers/gpu/drm/i915/intel_sprite.c  | 119 --
  5 files changed, 347 insertions(+), 108 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index d4f8ae8..5b1404e 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -405,9 +405,12 @@ struct intel_connector;
  struct intel_crtc_config;
  struct intel_plane_config;
  struct intel_crtc;
 +struct intel_plane;
  struct intel_limit;
  struct dpll;
  struct intel_crtc_wm_config;
 +struct intel_plane_wm_parameters;
 +struct intel_crtc_wm_config;

  struct drm_i915_display_funcs {
 bool (*fbc_enabled)(struct drm_device *dev);
 @@ -434,10 +437,13 @@ struct drm_i915_display_funcs {
   struct dpll *match_clock,
   struct dpll *best_clock);
 void (*update_wm)(struct drm_crtc *crtc);
 -   void (*update_sprite_wm)(struct drm_plane *plane,
 -struct drm_crtc *crtc,
 -uint32_t sprite_width, int pixel_size,
 -bool enable, bool scaled);
 +   int (*update_primary_wm)(struct intel_crtc *crtc,
 +struct intel_crtc_wm_config *config);
 +   int (*update_cursor_wm)(struct intel_crtc *crtc,
 +   struct intel_crtc_wm_config *config);
 +   int (*update_sprite_wm)(struct intel_plane *plane,
 +   struct intel_crtc *crtc,
 +   struct intel_crtc_wm_config *config);
 void (*program_wm_pre)(struct intel_crtc *crtc,
const struct intel_crtc_wm_config *config);
 void (*program_wm_post)(struct intel_crtc *crtc,
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 408b238..5bf1633 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -2078,6 +2078,19 @@ void intel_flush_primary_plane(struct drm_i915_private 
 *dev_priv,
 POSTING_READ(reg);
  }

 +static 

[Intel-gfx] [PATCH] drm/i915: Kick out vga console

[Daniel Vetter]

From: Chris Wilson ch...@chris-wilson.co.uk

Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.

Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.

Also, we want this to make I915_FBDEV=n safe.

v2: Rebase and pimp commit message.

v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann dh.herrm...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_dma.c  | 34 +-
 drivers/video/console/dummycon.c |  1 +
 drivers/video/console/vgacon.c   |  1 +
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b9159ade5e85..a4df80740b37 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -36,6 +36,8 @@
 #include i915_drv.h
 #include i915_trace.h
 #include linux/pci.h
+#include linux/console.h
+#include linux/vt.h
 #include linux/vgaarb.h
 #include linux/acpi.h
 #include linux/pnp.h
@@ -1450,6 +1452,29 @@ static void i915_kick_out_firmware_fb(struct 
drm_i915_private *dev_priv)
 }
 #endif
 
+static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
+{
+#if !defined(CONFIG_VGA_CONSOLE)
+   return 0;
+#else
+   int ret;
+
+#if !defined(CONFIG_DUMMY_CONSOLE)
+   return -ENODEV;
+#endif
+
+   DRM_INFO(Replacing VGA console driver\n);
+
+   console_lock();
+   ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
+   if (ret == 0)
+   ret = do_unregister_con_driver(vga_con);
+   console_unlock();
+
+   return ret;
+#endif
+}
+
 static void i915_dump_device_info(struct drm_i915_private *dev_priv)
 {
const struct intel_device_info *info = dev_priv-info;
@@ -1623,8 +1648,15 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
goto out_regs;
 
-   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+   ret = i915_kick_out_vgacon(dev_priv);
+   if (ret) {
+   DRM_ERROR(failed to remove conflicting VGA console\n);
+   goto out_gtt;
+   }
+
i915_kick_out_firmware_fb(dev_priv);
+   }
 
pci_set_master(dev-pdev);
 
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f7beab..40bec8d64b0a 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -77,3 +77,4 @@ const struct consw dummy_con = {
 .con_set_palette = DUMMY,
 .con_scrolldelta = DUMMY,
 };
+EXPORT_SYMBOL_GPL(dummy_con);
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9d8feac67637..84acd6223dc5 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1440,5 +1440,6 @@ const struct consw vga_con = {
.con_build_attr = vgacon_build_attr,
.con_invert_region = vgacon_invert_region,
 };
+EXPORT_SYMBOL(vga_con);
 
 MODULE_LICENSE(GPL);
-- 
1.8.1.4

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

[Intel-gfx] [PATCH] igt_core: Add PCI ID to the test spew

[Ben Widawsky]

makes sure the platform match what is expected.

Sample output:
bwidawsk@ironside ~/intel-gfx/intel-gpu-tools (master)$ sudo 
./tests/gem_exec_nop
PCI ID: 0x0a16 IGT-Version: 1.6-g21bcc3f (x86_64) (Linux: 3.14.4-1-ARCH x86_64)

Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 lib/igt_core.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 6e553cf..097ae62 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -254,18 +254,29 @@ static void check_igt_exit(int sig)
assert(sig != 0 || igt_exit_called);
 }
 
+#define PCI_ID_PATH /sys/devices/pci:00/:00:02.0/device
 static void print_version(void)
 {
struct utsname uts;
+   char pci_id[] = 0x;
+   FILE *file;
 
if (list_subtests)
return;
 
uname(uts);
 
-   fprintf(stdout, IGT-Version: %s-%s (%s) (%s: %s %s)\n, 
PACKAGE_VERSION,
-   IGT_GIT_SHA1, TARGET_CPU_PLATFORM,
-   uts.sysname, uts.release, uts.machine);
+   file = fopen(PCI_ID_PATH, r);
+   if (file != NULL) {
+   fgets(pci_id, strlen(pci_id) + 1, file);
+   fclose(file);
+   }
+
+   fprintf(stdout, PCI ID: %s IGT-Version: %s-%s (%s) (%s: %s %s)\n,
+   pci_id,
+   PACKAGE_VERSION,
+   IGT_GIT_SHA1, TARGET_CPU_PLATFORM,
+   uts.sysname, uts.release, uts.machine);
 }
 
 static void print_usage(const char *command_str, const char *help_str,
-- 
2.0.0

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

Re: [Intel-gfx] [PATCH v2 0/8] drm drivers: kill drm_get_connector_name() and drm_get_encoder_name()

[Dave Airlie]

On 3 June 2014 21:56, Jani Nikula jani.nik...@intel.com wrote:
 Hi all, this is v2 of [1] to remove drm_get_connector_name() and
 drm_get_encoder_name(), adding patch 1 for imx in staging and making
 some dereferences less of an eye sore. This is based on Dave's drm-next
 branch.

I pushed these, after regenerating a couple of bits for new radeon and
edid code.

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

Re: [Intel-gfx] [PATCH] drm: Move plane helpers into drm_kms_helper.ko

[Dave Airlie]

On 4 June 2014 03:30, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 The drm core shouldn't depend upon any helpers, and we make sure this
 doesn't accidentally happen by moving them into the helper-only
 drm_kms_helper.ko module.

 v2: Don't break the build for vmwgfx, spotted by Matt.

 v3: Unbreak the depency loop around CONFIG_FB (not actually a loop
 since it involves select). Reported by Chris.

 Cc: Matt Roper matthew.d.ro...@intel.com
 Cc: Thomas Hellstrom thellst...@vmware.com
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/Makefile   | 6 +++---
  drivers/gpu/drm/vmwgfx/Kconfig | 7 +--
  2 files changed, 8 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index 48e38ba22783..863db8415c22 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -13,8 +13,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
 drm_cache.o \
 drm_crtc.o drm_modes.o drm_edid.o \
 drm_info.o drm_debugfs.o drm_encoder_slave.o \
 drm_trace_points.o drm_global.o drm_prime.o \
 -   drm_rect.o drm_vma_manager.o drm_flip_work.o \
 -   drm_plane_helper.o
 +   drm_rect.o drm_vma_manager.o drm_flip_work.o

  drm-$(CONFIG_COMPAT) += drm_ioc32.o
  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 @@ -23,7 +22,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o

  drm-usb-y   := drm_usb.o

 -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
 +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
 +   drm_plane_helper.o
  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
  drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
 diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
 index b71bcd0bfbbf..67720f70fe29 100644
 --- a/drivers/gpu/drm/vmwgfx/Kconfig
 +++ b/drivers/gpu/drm/vmwgfx/Kconfig
 @@ -1,11 +1,14 @@
  config DRM_VMWGFX
 tristate DRM driver for VMware Virtual GPU
 -   depends on DRM  PCI  FB
 +   depends on DRM  PCI
 select FB_DEFERRED_IO
 select FB_CFB_FILLRECT
 select FB_CFB_COPYAREA
 select FB_CFB_IMAGEBLIT
 select DRM_TTM
 +   # Only needed for the transitional use of drm_crtc_init - can be 
 removed
 +   # again once vmwgfx sets up the primary plane itself.
 +   select DRM_KMS_HELPER
 help
   Choose this option if you would like to run 3D acceleration
   in a VMware virtual machine.
 @@ -14,7 +17,7 @@ config DRM_VMWGFX
   The compiled module will be called vmwgfx.ko.

  config DRM_VMWGFX_FBCON
 -   depends on DRM_VMWGFX
 +   depends on DRM_VMWGFX  FB
 bool Enable framebuffer console under vmwgfx by default
 help
Choose this option if you are shipping a new vmwgfx

Applied thanks,

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

Re: [Intel-gfx] [PATCH v3] drm/i915: Added write-enable pte bit support

[Akash Goel]

On Mon, 2014-06-02 at 10:19 +0200, Daniel Vetter wrote:
 On Sun, Jun 01, 2014 at 12:12:50PM +0530, Akash Goel wrote:
  On Mon, 2014-05-19 at 13:03 +0530, Akash Goel wrote:
   On Mon, 2014-05-19 at 08:56 +0200, Daniel Vetter wrote:
On Sun, May 18, 2014 at 11:27:00AM +0530, Akash Goel wrote:
 On Wed, 2014-05-14 at 10:14 +0200, Daniel Vetter wrote:
  On Tue, May 13, 2014 at 03:43:12PM -0700, Jesse Barnes wrote:
   On Wed, 14 May 2014 00:30:34 +0200
   Daniel Vetter dan...@ffwll.ch wrote:
   
On Tue, May 13, 2014 at 03:05:24PM -0700, Jesse Barnes wrote:
 On Tue, 11 Feb 2014 14:19:03 +0530
 akash.g...@intel.com wrote:
 
  @@ -810,6 +815,7 @@ static void 
  gen6_ppgtt_insert_entries(struct i915_address_space *vm,
  pt_vaddr[act_pte] =
  
  vm-pte_encode(sg_page_iter_dma_address(sg_iter),
 cache_level, true);
  +
  if (++act_pte == I915_PPGTT_PT_ENTRIES) {
  kunmap_atomic(pt_vaddr);
  pt_vaddr = NULL;
 
 Some extra whitespace here.
 
 Thanks, will remove this.
 
 
 Otherwise:
 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

Hm, looking at the patch again encoding this into the 
cache_level enum is
fraught with fun. And due to IS_VLV aliasing chv this will blow 
up on chv
very likely. My old idea was to eventually add a pte_flags 
param all over
for this stuff with additional bits.
   
   That works too; and yeah CHV is all different here isn't it.  But 
   won't
   it go through the gen8 paths anyway?
  
  Yes, but we have a switch on the cache_level in the gen8 pte encode
  function. Since the bit31 gets or'ed in for VLV, it'll hit also chv 
  and
  wreak havoc in that specific switch - we'll hit the default case 
  when we
  don't expect to.
  
  cache_level = functional behaviour relevant for the kernel's 
  clflushing
  code
  
 
 As the 'IS_VALLEYVIEW' check will alias with CHV also, can I just 
 update
 the condition here, to include 'GEN7' also (IS_GEN7) in the check.

Adding new random bits to an enum which is used all over the place (and
not just in the pte encoding functions) makes the code much harder to
read. Also the code that deals with enum cache_level is all about cache
coherency, which has rather tricky logic.

Hence I expect this choice to cause further bugs down the road, which is
why I don't really like it. My apologies for not spotting this earlier.
-Daniel
   
   Hi Daniel,
   
   I understand your concern, but actually (as of now) this bit is only VLV
   specific. As per an earlier suggestion from Chris, I decided to
   overload the cache_level enum itself, in lieu of adding a new parameter
   to all the respective 'xxx_insert_entries'  'xxx_pte_encode' functions.
   
   And this is being done just before calling the 'xxx_insert_entries'
   function, which simply passes the flag as it is to 'xxx_pte_encode'
   function. So there may not be any risk here, if we use the appropriate
   VLV check.
  
  Please can you provide your inputs here.
 
 I guess you've run into a case where ChrisI disagree. I still think
 wiring up a flags parameter to all the pte encode functions is the sane
 option to pick here.

Hi Daniel,

Yes I just followed Chris's suggestion, which I also felt was
reasonable. But it's fine, will implement it as per your suggestion
only. I hope that will be acceptable to all.

Best regards
Akash

 -Daniel


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

[Intel-gfx] [PATCH] drm/i915: rework digital port IRQ handling

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

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.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/i915/i915_drv.h  |   5 ++
 drivers/gpu/drm/i915/i915_irq.c  | 138 ---
 drivers/gpu/drm/i915/intel_ddi.c |   3 +
 drivers/gpu/drm/i915/intel_dp.c  |  22 +++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 5 files changed, 162 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..1817eaa 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,82 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_device *dev,
 #define HPD_STORM_DETECT_PERIOD 1000
 #define HPD_STORM_THRESHOLD 5
 
+static int 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 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,