[Intel-gfx] [pull] last drm-intel-next pull for 3.7

2012-09-26 Thread Daniel Vetter
Hi Dave,

Last pile of stuff for 3.7, essentially just a bunch of bigger fixes and a
few less intrusive features:

- cpu freq interface in sysfs from Ben
- cpu edp fixes and some related cleanups
- write-combining ptes for pre-gen6 (Chris)
- basic CADL support (Peter Wu), this fixes quite a few issues with
  backlights ...
- rework of the gem backing pages handling (preps for stolen mem handling)
  from Chris
- some more cleanup-fallout from the modeset-rework

On top of that I've done a backmerge of -rc7(since the conflicts got too
messy and I've pushed out broken merged trees too often). I've also
included 3 fixes on top of what QA beat on:

- Fix for a infoframe handling regression in 3.5 - infoframe blows up too
  often and 3.6 is pretty much done, so I'd like to merge that through
  -next and the stable process and give it more exposure before it lands
  in a stable tree.
- ioctl cosmetics^Wspelling fix in the structs (userspace won't be
  affected, since all existing userspace uses private copies of the ioctl
  struct definitions, and the struct layout itself is abi compatible).
- Bugfix for a regression introduced in this pull's testing cycle.

Besides the regression in the ilk debugfs code QA reported new DP issues,
but afact all old stuff, just new variations of existing bugs. I hope we
can pour quite some manpower into our DP code from Intel's sides for the
next cycle. Maybe even extract some shared logic, since it sounds like
we'll eventually need quircks like for edid in dp-land :(

Cheers, Daniel

PS: Note that due to the backmerge I've manually frobbed the shortlog
again to exclude anything merged through Linus' tree.

The following changes since commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d:

  drm/i915: fix OOPS in lid_notify (2012-09-18 00:59:37 +0200)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel for-airlied

for you to fetch changes up to f531dcb23f9a5c6ad77e451459df965dc9a0c0c8:

  drm/i915: Wrap external callers to IPS state with appropriate locks 
(2012-09-26 09:24:54 +0200)



Ben Widawsky (10):
  drm/i915: placeholder getparam
  drm/i915: variable renames
  drm/i915: #define gpu freq multipler
  drm/i915: Add current/max/min GPU freq to sysfs
  drm/i915: POSTING_READ the new rps value
  drm/i915: Error checks in gen6_set_rps
  drm/i915: Add setters for min/max frequency
  drm/i915: Show render P state thresholds in sysfs
  drm/i915: Fix !CONFIG_PM sysfs for real this time
  drm/i915: s/cacheing/caching/

Chris Wilson (11):
  drm/i915: Introduce drm_i915_gem_object_ops
  drm/i915: Pin backing pages whilst exporting through a dmabuf vmap
  drm/i915: Pin backing pages for pwrite
  drm/i915: Pin backing pages for pread
  drm/i915: Replace the array of pages with a scatterlist
  drm/i915: Drop the misleading cast to the wrong user pointer type
  drm/i915: Limit the ioremap of the PCI bar to the registers
  agp/intel: Use a write-combining map for updating PTEs
  drm/i915: Convert the dmabuf object to use the new i915_gem_object_ops
  drm/i915: Assert that the exec object lookup table is a power-of-two
  drm/i915: Wrap external callers to IPS state with appropriate locks

Daniel Vetter (12):
  drm/i915: rip out early dp port write for gm45/ilk
  drm/i915: add encoder->pre_enable/post_disable
  drm/i915: clean up the cpu edp pll special case
  drm/i915: robustify edp_pll_on/off
  drm/i915: rip out dp port enabling cludges^Wchecks
  drm/i915: disable the cpu edp port after the cpu pipe
  drm/i915: rip out edp special case from dp_link_down
  drm/i915: rip out intel_disable_pch_ports
  drm/i915: don't disable fdi links harder in ilk_crtc_enable
  drm/i915: don't call dpms funcs after set_mode
  drm/i915: update dpms property in set_mode
  Merge tag 'v3.6-rc7' into drm-intel-next-queued

Lekensteyn (1):
  i915: initialize CADL in opregion

Paulo Zanoni (5):
  drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_set
  drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_set
  drm/i915: extract compute_clocks from ironlake_crtc_mode_set
  drm/i915: BUG() on unexpected HDMI register
  drm/i915: make sure we write all the DIP data bytes

Wang Xingchao (1):
  drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally

-- 
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: Wrap external callers to IPS state with appropriate locks

2012-09-26 Thread Daniel Vetter
On Tue, Sep 25, 2012 at 10:16:12AM +0100, Chris Wilson wrote:
> Finishes commit 02d719562ef40483648b2cc46899d4a2ff5953bb
> Author: Daniel Vetter 
> Date:   Thu Aug 9 16:44:54 2012 +0200
> 
> drm/i915: properly guard ilk ips state
> 
> The core functions were annotated with their locking requirements, but
> we overlooked that they were exported, without any control over the
> locking, to debugfs. So in order to enable debugfs to read the registers
> without triggering sanity checks, we change the exported entry points to
> properly take the required locks before calling the core routines.
> 
> Reported-by: yangguang 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304
> Signed-off-by: Chris Wilson 

Merged, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_pm.c |   40 
> +++
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4e16cc1..f459e30 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2735,7 +2735,7 @@ static const struct cparams {
>   { 0, 800, 231, 23784 },
>  };
>  
> -unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
> +static unsigned long __i915_chipset_val(struct drm_i915_private *dev_priv)
>  {
>   u64 total_count, diff, ret;
>   u32 count1, count2, count3, m = 0, c = 0;
> @@ -2789,6 +2789,22 @@ unsigned long i915_chipset_val(struct drm_i915_private 
> *dev_priv)
>   return ret;
>  }
>  
> +unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
> +{
> + unsigned long val;
> +
> + if (dev_priv->info->gen != 5)
> + return 0;
> +
> + spin_lock_irq(&mchdev_lock);
> +
> + val = __i915_chipset_val(dev_priv);
> +
> + spin_unlock_irq(&mchdev_lock);
> +
> + return val;
> +}
> +
>  unsigned long i915_mch_val(struct drm_i915_private *dev_priv)
>  {
>   unsigned long m, x, b;
> @@ -2992,7 +3008,7 @@ void i915_update_gfx_val(struct drm_i915_private 
> *dev_priv)
>   spin_unlock_irq(&mchdev_lock);
>  }
>  
> -unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
> +static unsigned long __i915_gfx_val(struct drm_i915_private *dev_priv)
>  {
>   unsigned long t, corr, state1, corr2, state2;
>   u32 pxvid, ext_v;
> @@ -3029,6 +3045,22 @@ unsigned long i915_gfx_val(struct drm_i915_private 
> *dev_priv)
>   return dev_priv->ips.gfx_power + state2;
>  }
>  
> +unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
> +{
> + unsigned long val;
> +
> + if (dev_priv->info->gen != 5)
> + return 0;
> +
> + spin_lock_irq(&mchdev_lock);
> +
> + val = __i915_gfx_val(dev_priv);
> +
> + spin_unlock_irq(&mchdev_lock);
> +
> + return val;
> +}
> +
>  /**
>   * i915_read_mch_val - return value for IPS use
>   *
> @@ -3045,8 +3077,8 @@ unsigned long i915_read_mch_val(void)
>   goto out_unlock;
>   dev_priv = i915_mch_dev;
>  
> - chipset_val = i915_chipset_val(dev_priv);
> - graphics_val = i915_gfx_val(dev_priv);
> + chipset_val = __i915_chipset_val(dev_priv);
> + graphics_val = __i915_gfx_val(dev_priv);
>  
>   ret = chipset_val + graphics_val;
>  
> -- 
> 1.7.10.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] [PATCH 1/2] drm/i915: s/cacheing/caching/

2012-09-26 Thread Daniel Vetter
On Tue, Sep 25, 2012 at 09:55:35AM -0700, Ben Widawsky wrote:
> On Tue, 25 Sep 2012 10:43:55 +0100
> Chris Wilson  wrote:
> 
> > On Tue, 25 Sep 2012 10:32:17 +0200, Daniel Vetter  wrote:
> > > On Sat, Sep 22, 2012 at 2:01 AM, Ben Widawsky  wrote:
> > > > From: Ben Widawsky 
> > > >
> > > > Signed-off-by: Ben Widawsky 
> > > 
> > > IIrc we're already including this header in shipping libdrm, and we
> > > have already users for it ... Have you checked whether this doesn't
> > > break anything once copied over to libdrm? Maybe we just need a few
> > > #defines for the old names ...
> > 
> > It doesn't affect the ddx since it is still using its own prototype, and
> > there has yet to be a patch for Mesa to use this knowledge.
> > -Chris
> > 
> 
> Quickly!

Done!

I think I'll punt on the hsw pte stuff a bit, prod me on (internal) irc
for the reasons ... (and to prove me wrong).
-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] [RFC] [PATCH] quick_dump: A dump utility different than reg_dumper

2012-09-26 Thread Daniel Vetter
On Sat, Sep 22, 2012 at 01:58:37PM -0700, Ben Widawsky wrote:
> On 2012-09-22 11:05, Daniel Vetter wrote:
> >And a quick comment on your approach here: I'm not too sure
> >whether the
> >file-base register block approach scales, respectively why exactly
> >this is
> >better than frobbing the reg_dumper tool. Since that one has the
> >concept
> >of register blocks already, too.
> 
> It doesn't scale. It scales better than reg_dumper was my goal and
> point (IMO).
> 
> The exact problem that was trying to be solved is Valleyview (and I
> assure you there will be more such products coming). Valleyview took
> a huge chunk of well known registers, and changed their offsets.
> Modifying this in reg dumper is of course possible, but it's
> tedious. I wanted to have easy to modify text files with an easy
> python front end (the offsets could even be applied in the script
> extremely easily).

If the issue is just the base-address moving around, I think we could
solve that with some refactoring ...
-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] drm/i915: Valleyview doesn't have rc6+ or rc6++

2012-09-26 Thread Daniel Vetter
On Mon, Sep 17, 2012 at 05:10:15PM -0700, Ben Widawsky wrote:
> I do not currently have a VLV to test this on, but hopefully it only
> removes information from debugfs, sysfs, and prevents enabling an
> unsupported mode.
> 
> CC: Jesse Barnes 
> Signed-off-by: Ben Widawsky 

Haswell seems to have a similar issue ...
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 5 +
>  drivers/gpu/drm/i915/i915_sysfs.c   | 3 +++
>  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>  3 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7a4b3f3..4e74a6a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1144,11 +1144,16 @@ static int gen6_drpc_info(struct seq_file *m)
>  I915_READ(GEN6_GT_GFX_RC6_LOCKED));
>   seq_printf(m, "RC6 residency since boot: %u\n",
>  I915_READ(GEN6_GT_GFX_RC6));
> +
> + if (IS_VALLEYVIEW(dev))
> + goto out;
> +
>   seq_printf(m, "RC6+ residency since boot: %u\n",
>  I915_READ(GEN6_GT_GFX_RC6p));
>   seq_printf(m, "RC6++ residency since boot: %u\n",
>  I915_READ(GEN6_GT_GFX_RC6pp));
>  
> +out:
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index a253515..4717a42 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -41,6 +41,9 @@ static u32 calc_residency(struct drm_device *dev, const u32 
> reg)
>   if (!intel_enable_rc6(dev))
>   return 0;
>  
> + if (IS_VALLEYVIEW(dev) && reg != GEN6_GT_GFX_RC6)
> + return 0;
> +
>   raw_time = I915_READ(reg) * 128ULL;
>   return DIV_ROUND_UP_ULL(raw_time, 10);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 82ca172..ccd50d7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2389,8 +2389,8 @@ int intel_enable_rc6(const struct drm_device *dev)
>   }
>  
>   /* snb/ivb have more than one rc6 state. */
> - if (INTEL_INFO(dev)->gen == 6) {
> - DRM_DEBUG_DRIVER("Sandybridge: deep RC6 disabled\n");
> + if (INTEL_INFO(dev)->gen == 6 || IS_VALLEYVIEW(dev)) {
> + DRM_DEBUG_DRIVER("HW doesn't support deep RC6 (disabling)\n");
>   return INTEL_RC6_ENABLE;
>   }
>  
> -- 
> 1.7.12
> 
> ___
> 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 3/4] drm/i915/dp: Fetch downstream port info if needed during DPCD fetch

2012-09-26 Thread Daniel Vetter
On Thu, Sep 20, 2012 at 03:28:45PM +0300, Jani Nikula wrote:
> On Tue, 18 Sep 2012, Adam Jackson  wrote:
> > v2: Fix parenthesis mismatch, spotted by Jani Nikula
> >
> > Tested-by: Takashi Iwai 
> > Signed-off-by: Adam Jackson 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |   25 -
> >  1 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ace757a..098119e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -39,6 +39,7 @@
> >  #include "drm_dp_helper.h"
> >  
> >  #define DP_RECEIVER_CAP_SIZE   0xf
> > +#define DP_MAX_DOWNSTREAM_PORTS 0xf
> 
> That should be 0x10. It doesn't matter in this series, but would be nice
> to fix it for correctness. Sorry I didn't spot this the first time
> around.
> 
> Otherwise, on the series,
> 
> Reviewed-by: Jani Nikula 

Ok, I've merged these 4 patches, with the #define fixed and a small merge
conflict resolved. Please yell if I've botched things up ...

Thanks, Daniel
> 
> 
> >  #define DP_LINK_STATUS_SIZE6
> >  #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
> >  
> > @@ -56,6 +57,7 @@ struct intel_dp {
> > uint8_t link_bw;
> > uint8_t lane_count;
> > uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> > +   uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> > struct i2c_adapter adapter;
> > struct i2c_algo_dp_aux_data algo;
> > bool is_pch_edp;
> > @@ -1968,12 +1970,25 @@ static bool
> >  intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >  {
> > if (intel_dp_aux_native_read_retry(intel_dp, 0x000, intel_dp->dpcd,
> > -  sizeof(intel_dp->dpcd)) &&
> > -   (intel_dp->dpcd[DP_DPCD_REV] != 0)) {
> > -   return true;
> > -   }
> > +  sizeof(intel_dp->dpcd)) == 0)
> > +   return false; /* aux transfer failed */
> >  
> > -   return false;
> > +   if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> > +   return false; /* DPCD not present */
> > +
> > +   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > + DP_DWN_STRM_PORT_PRESENT))
> > +   return true; /* native DP sink */
> > +
> > +   if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
> > +   return true; /* no per-port downstream info */
> > +
> > +   if (intel_dp_aux_native_read_retry(intel_dp, DP_DOWNSTREAM_PORT_0,
> > +  intel_dp->downstream_ports,
> > +  DP_MAX_DOWNSTREAM_PORTS) == 0)
> > +   return false; /* downstream port status fetch failed */
> > +
> > +   return true;
> >  }
> >  
> >  static void
> > -- 
> > 1.7.7.6
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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: Disallow preallocation of requests

2012-09-26 Thread Chris Wilson
The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba1ed5198a2c1dfaac4f3c95459930d84a
Author: Chris Wilson 
Date:   Fri Jul 20 12:40:59 2012 +0100

drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/i915_gem.c  |   20 +-
 drivers/gpu/drm/i915/intel_overlay.c |   72 +++---
 3 files changed, 25 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dddc3dc..d8d4736 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,7 +1468,7 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
 int __must_check i915_gem_idle(struct drm_device *dev);
 int i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request);
+u32 *seqno);
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2effab..82f7f03 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2087,10 +2087,10 @@ i915_gem_next_request_seqno(struct intel_ring_buffer 
*ring)
 int
 i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request)
+u32 *seqno)
 {
drm_i915_private_t *dev_priv = ring->dev->dev_private;
-   uint32_t seqno;
+   struct drm_i915_gem_request *request;
u32 request_ring_position;
int was_empty;
int ret;
@@ -2106,13 +2106,11 @@ i915_add_request(struct intel_ring_buffer *ring,
if (ret)
return ret;
 
-   if (request == NULL) {
-   request = kmalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL)
-   return -ENOMEM;
-   }
+   request = kmalloc(sizeof(*request), GFP_KERNEL);
+   if (request == NULL)
+   return -ENOMEM;
 
-   seqno = i915_gem_next_request_seqno(ring);
+   *seqno = i915_gem_next_request_seqno(ring);
 
/* Record the position of the start of the request so that
 * should we detect the updated seqno part-way through the
@@ -2121,15 +2119,15 @@ i915_add_request(struct intel_ring_buffer *ring,
 */
request_ring_position = intel_ring_get_tail(ring);
 
-   ret = ring->add_request(ring, &seqno);
+   ret = ring->add_request(ring, seqno);
if (ret) {
kfree(request);
return ret;
}
 
-   trace_i915_gem_request_add(ring, seqno);
+   trace_i915_gem_request_add(ring, *seqno);
 
-   request->seqno = seqno;
+   request->seqno = *seqno;
request->ring = ring;
request->tail = request_ring_position;
request->emitted_jiffies = jiffies;
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 2fa20a4..ebcbf48 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -210,7 +210,6 @@ static void intel_overlay_unmap_regs(struct intel_overlay 
*overlay,
 }
 
 static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
-struct drm_i915_gem_request *request,
 void (*tail)(struct intel_overlay *))
 {
struct drm_device *dev = overlay->dev;
@@ -219,12 +218,10 @@ static int intel_overlay_do_wait_request(struct 
intel_overlay *overlay,
int ret;
 
BUG_ON(overlay->last_flip_req);
-   ret = i915_add_request(ring, NULL, request);
-   if (ret) {
-   kfree(request);
-   return ret;
-   }
-   overlay->last_flip_req = request->seqno;
+   ret = i915_add_request(ring, NULL, &overlay->last_flip_req);
+   if (ret)
+   return ret;
+
overlay->flip_tail = tail;
ret = i915_wait_seqno(ring, overlay->last_flip_req);
if (ret)
@@ -241,7 +238,6 @@ static int intel_overlay_on(struct intel_overlay *overlay)
struct drm_device *dev = overlay->dev;
struct

Re: [Intel-gfx] [PATCH] drm/i915: Disallow preallocation of requests

2012-09-26 Thread Chris Wilson
On Wed, 26 Sep 2012 13:35:33 +0100, Chris Wilson  
wrote:
> The intention was to allow the caller to avoid a failure to queue a
> request having already written commands to the ring. However, this is a
> moot point as the i915_add_request() can fail for other reasons than a
> mere allocation failure and those failure cases are more likely than
> ENOMEM. So the overlay code already had to handle i915_add_request()
> failures, and due to
> 
> commit 3bb73aba1ed5198a2c1dfaac4f3c95459930d84a
> Author: Chris Wilson 
> Date:   Fri Jul 20 12:40:59 2012 +0100
> 
> drm/i915: Allow late allocation of request for i915_add_request()
> 
> the error handling code in intel_overlay.c was subject to causing
> double-frees.
> 
> Rather than further complicate i915_add_request() and callers, realise
> the battle is lost and adapt intel_overlay.c to take advantage of the
> late allocation of requests.

Ah crap. Compile tested, obviously not run.
-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 2/2] drm/dp: Make sink count DP 1.2 aware

2012-09-26 Thread Daniel Vetter
On Thu, Sep 20, 2012 at 06:45:29PM -0300, Paulo Zanoni wrote:
> 2012/9/20 Adam Jackson :
> > Signed-off-by: Adam Jackson 
> 
> Reviewed-by: Paulo Zanoni 

Both patches merged to dinq (again with Dave's irc-ack for the common
stuff).

Thanks, Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |9 -
> >  include/drm/drm_dp_helper.h |3 ++-
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 813b771..00f99e5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2106,13 +2106,12 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> > /* If we're HPD-aware, SINK_COUNT changes dynamically */
> > hpd = !!(intel_dp->downstream_ports[0] & DP_DS_PORT_HPD);
> > if (hpd) {
> > -   uint8_t sink_count;
> > +   uint8_t reg;
> > if (!intel_dp_aux_native_read_retry(intel_dp, DP_SINK_COUNT,
> > -   &sink_count, 1))
> > +   ®, 1))
> > return connector_status_unknown;
> > -   sink_count &= DP_SINK_COUNT_MASK;
> > -   return sink_count ? connector_status_connected
> > - : connector_status_disconnected;
> > +   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> > + : 
> > connector_status_disconnected;
> > }
> >
> > /* If no HPD, poke DDC gently */
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index 38ffcb4..fe06148 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -221,7 +221,8 @@
> >  # define DP_PSR_FRAME_CAPTURE  (1 << 3)
> >
> >  #define DP_SINK_COUNT  0x200
> > -# define DP_SINK_COUNT_MASK(31 << 0)
> > +/* prior to 1.2 bit 7 was reserved mbz */
> > +# define DP_GET_SINK_COUNT(x)  x) & 0x80) >> 1) | ((x) & 
> > 0x3f))
> >  # define DP_SINK_CP_READY  (1 << 6)
> >
> >  #define DP_DEVICE_SERVICE_IRQ_VECTOR   0x201
> > --
> > 1.7.7.6
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
> -- 
> Paulo Zanoni
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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: Disallow preallocation of requests

2012-09-26 Thread Chris Wilson
The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba1ed5198a2c1dfaac4f3c95459930d84a
Author: Chris Wilson 
Date:   Fri Jul 20 12:40:59 2012 +0100

drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

v2: handle callers passing in a NULL seqno

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/i915_gem.c  |   14 +++
 drivers/gpu/drm/i915/intel_overlay.c |   72 +++---
 3 files changed, 23 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dddc3dc..d8d4736 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,7 +1468,7 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
 int __must_check i915_gem_idle(struct drm_device *dev);
 int i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request);
+u32 *seqno);
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2effab..489d32d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2087,11 +2087,12 @@ i915_gem_next_request_seqno(struct intel_ring_buffer 
*ring)
 int
 i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request)
+u32 *out_seqno)
 {
drm_i915_private_t *dev_priv = ring->dev->dev_private;
-   uint32_t seqno;
+   struct drm_i915_gem_request *request;
u32 request_ring_position;
+   u32 seqno;
int was_empty;
int ret;
 
@@ -2106,11 +2107,9 @@ i915_add_request(struct intel_ring_buffer *ring,
if (ret)
return ret;
 
-   if (request == NULL) {
-   request = kmalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL)
-   return -ENOMEM;
-   }
+   request = kmalloc(sizeof(*request), GFP_KERNEL);
+   if (request == NULL)
+   return -ENOMEM;
 
seqno = i915_gem_next_request_seqno(ring);
 
@@ -2162,6 +2161,7 @@ i915_add_request(struct intel_ring_buffer *ring,
}
}
 
+   *out_seqno = seqno;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 2fa20a4..ebcbf48 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -210,7 +210,6 @@ static void intel_overlay_unmap_regs(struct intel_overlay 
*overlay,
 }
 
 static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
-struct drm_i915_gem_request *request,
 void (*tail)(struct intel_overlay *))
 {
struct drm_device *dev = overlay->dev;
@@ -219,12 +218,10 @@ static int intel_overlay_do_wait_request(struct 
intel_overlay *overlay,
int ret;
 
BUG_ON(overlay->last_flip_req);
-   ret = i915_add_request(ring, NULL, request);
-   if (ret) {
-   kfree(request);
-   return ret;
-   }
-   overlay->last_flip_req = request->seqno;
+   ret = i915_add_request(ring, NULL, &overlay->last_flip_req);
+   if (ret)
+   return ret;
+
overlay->flip_tail = tail;
ret = i915_wait_seqno(ring, overlay->last_flip_req);
if (ret)
@@ -241,7 +238,6 @@ static int intel_overlay_on(struct intel_overlay *overlay)
struct drm_device *dev = overlay->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_ring_buffer *ring = &dev_priv->ring[RCS];
-   struct drm_i915_gem_request *request;
int ret;
 
BUG_ON(overlay->active);
@@ -249,17 +245,9 @@ static int intel_overlay_on(struct intel_overlay *overlay)
 
WARN_ON(IS_I830(dev) && !(dev_priv->quirks & QUIRK_PIPEA_FORCE));
 
-   request = kzalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
ret = intel_ring_begin(ring, 4);
-   if (ret) {
- 

[Intel-gfx] [PATCH] drm/i915: Disallow preallocation of requests

2012-09-26 Thread Chris Wilson
The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba1ed5198a2c1dfaac4f3c95459930d84a
Author: Chris Wilson 
Date:   Fri Jul 20 12:40:59 2012 +0100

drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees, as found by coverity.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

v2: handle callers passing in a NULL seqno

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/i915_gem.c  |   14 +++
 drivers/gpu/drm/i915/intel_overlay.c |   72 +++---
 3 files changed, 23 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dddc3dc..d8d4736 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,7 +1468,7 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
 int __must_check i915_gem_idle(struct drm_device *dev);
 int i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request);
+u32 *seqno);
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2effab..489d32d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2087,11 +2087,12 @@ i915_gem_next_request_seqno(struct intel_ring_buffer 
*ring)
 int
 i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request)
+u32 *out_seqno)
 {
drm_i915_private_t *dev_priv = ring->dev->dev_private;
-   uint32_t seqno;
+   struct drm_i915_gem_request *request;
u32 request_ring_position;
+   u32 seqno;
int was_empty;
int ret;
 
@@ -2106,11 +2107,9 @@ i915_add_request(struct intel_ring_buffer *ring,
if (ret)
return ret;
 
-   if (request == NULL) {
-   request = kmalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL)
-   return -ENOMEM;
-   }
+   request = kmalloc(sizeof(*request), GFP_KERNEL);
+   if (request == NULL)
+   return -ENOMEM;
 
seqno = i915_gem_next_request_seqno(ring);
 
@@ -2162,6 +2161,7 @@ i915_add_request(struct intel_ring_buffer *ring,
}
}
 
+   *out_seqno = seqno;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 2fa20a4..ebcbf48 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -210,7 +210,6 @@ static void intel_overlay_unmap_regs(struct intel_overlay 
*overlay,
 }
 
 static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
-struct drm_i915_gem_request *request,
 void (*tail)(struct intel_overlay *))
 {
struct drm_device *dev = overlay->dev;
@@ -219,12 +218,10 @@ static int intel_overlay_do_wait_request(struct 
intel_overlay *overlay,
int ret;
 
BUG_ON(overlay->last_flip_req);
-   ret = i915_add_request(ring, NULL, request);
-   if (ret) {
-   kfree(request);
-   return ret;
-   }
-   overlay->last_flip_req = request->seqno;
+   ret = i915_add_request(ring, NULL, &overlay->last_flip_req);
+   if (ret)
+   return ret;
+
overlay->flip_tail = tail;
ret = i915_wait_seqno(ring, overlay->last_flip_req);
if (ret)
@@ -241,7 +238,6 @@ static int intel_overlay_on(struct intel_overlay *overlay)
struct drm_device *dev = overlay->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_ring_buffer *ring = &dev_priv->ring[RCS];
-   struct drm_i915_gem_request *request;
int ret;
 
BUG_ON(overlay->active);
@@ -249,17 +245,9 @@ static int intel_overlay_on(struct intel_overlay *overlay)
 
WARN_ON(IS_I830(dev) && !(dev_priv->quirks & QUIRK_PIPEA_FORCE));
 
-   request = kzalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
ret = intel_ring_begin(ring, 4);

Re: [Intel-gfx] [PATCH] Add option -o , which can test only one specified mode.

2012-09-26 Thread Daniel Vetter
On Tue, Sep 25, 2012 at 05:13:17PM +0800, Yi Sun wrote:
> Each mode line has a number just like '[i]'. So we can only test the 
> specified mode with giving the number of mode to '-o' parameter.
> 
> Signed-off-by: Yi Sun 

Merged, thanks for the patch.
-Daniel
> 
> diff --git a/tests/testdisplay.c b/tests/testdisplay.c
> index c52bb2f..39c4265 100644
> --- a/tests/testdisplay.c
> +++ b/tests/testdisplay.c
> @@ -72,6 +72,7 @@ int dump_info = 0, test_all_modes =0, test_preferred_mode = 
> 0, force_mode = 0,
>  int sleep_between_modes = 5;
>  uint32_t depth = 24, stride, bpp;
>  int qr_code = 0;
> +int only_one_mode = 0, specified_mode_num = 0;
>  
>  drmModeModeInfo force_timing;
>  
> @@ -193,8 +194,10 @@ static void dump_connectors_fd(int drmfd)
>   printf("  modes:\n");
>   printf("  name refresh (Hz) hdisp hss hse htot vdisp "
>  "vss vse vtot flags type clock\n");
> - for (j = 0; j < connector->count_modes; j++)
> + for (j = 0; j < connector->count_modes; j++){
> + fprintf(stdout, "[%d]", j );
>   kmstest_dump_mode(&connector->modes[j]);
> + }
>  
>   drmModeFreeConnector(connector);
>   }
> @@ -275,6 +278,12 @@ static void connector_find_preferred_mode(struct 
> connector *c)
>   }
>   }
>  
> + if ( only_one_mode ){
> + c->mode = connector->modes[specified_mode_num];
> + if (c->mode.type & DRM_MODE_TYPE_PREFERRED)
> + c->mode_valid = 1;
> + }
> +
>   if (!c->mode_valid) {
>   if (connector->count_modes > 0) {
>   /* use the first mode as test mode */
> @@ -318,7 +327,7 @@ static void connector_find_preferred_mode(struct 
> connector *c)
>   c->crtc = resources->crtcs[i];
>   c->pipe = i;
>  
> - if(test_preferred_mode || force_mode)
> + if(test_preferred_mode || force_mode || only_one_mode)
>   resources->crtcs[i] = 0;
>  
>   c->connector = connector;
> @@ -525,7 +534,7 @@ set_mode(struct connector *c)
>  
>   gem_close(drm_fd, fb_info.gem_handle);
>  
> - fprintf(stdout, "CRTS(%u):",c->crtc);
> + fprintf(stdout, "CRTS(%u):[%d]",c->crtc, j);
>   kmstest_dump_mode(&c->mode);
>   if (drmModeSetCrtc(drm_fd, c->crtc, fb_id, 0, 0,
>  &c->id, 1, &c->mode)) {
> @@ -585,7 +594,7 @@ int update_display(void)
>   dump_crtcs_fd(drm_fd);
>   }
>  
> - if (test_preferred_mode || test_all_modes || force_mode) {
> + if (test_preferred_mode || test_all_modes || force_mode || 
> only_one_mode) {
>   /* Find any connected displays */
>   for (c = 0; c < resources->count_connectors; c++) {
>   connectors[c].id = resources->connectors[c];
> @@ -596,7 +605,7 @@ int update_display(void)
>   return 1;
>  }
>  
> -static char optstr[] = "hiaf:s:d:p:mrt";
> +static char optstr[] = "hiaf:s:d:p:mrto:";
>  
>  static void __attribute__((noreturn)) usage(char *name)
>  {
> @@ -609,6 +618,7 @@ static void __attribute__((noreturn)) usage(char *name)
>   fprintf(stderr, "\t-m\ttest the preferred mode\n");
>   fprintf(stderr, "\t-t\tuse a tiled framebuffer\n");
>   fprintf(stderr, "\t-r\tprint a QR code on the screen whose content is 
> \"pass\" for the automatic test\n");
> + fprintf(stderr, "\t-o\t\tonly test specified 
> mode\n");
>   fprintf(stderr, "\t-f\t MHz>,\n");
>   fprintf(stderr, "\t\t,,,\n");
>   fprintf(stderr, "\t\ttest force mode\n");
> @@ -701,6 +711,10 @@ int main(int argc, char **argv)
>   case 'r':
>   qr_code = 1;
>   break;
> + case 'o':
> + only_one_mode = 1;
> + specified_mode_num = atoi(optarg);
> + break;
>   default:
>   fprintf(stderr, "unknown option %c\n", c);
>   /* fall through */
> @@ -710,7 +724,7 @@ int main(int argc, char **argv)
>   }
>   }
>   if (!test_all_modes && !force_mode && !dump_info &&
> - !test_preferred_mode)
> + !test_preferred_mode && !only_one_mode)
>   test_all_modes = 1;
>  
>   drm_fd = drm_open_any();
> -- 
> 1.7.6.4
> 

-- 
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: Disallow preallocation of requests

2012-09-26 Thread Chris Wilson
The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba1ed5198a2c1dfaac4f3c95459930d84a
Author: Chris Wilson 
Date:   Fri Jul 20 12:40:59 2012 +0100

drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees, as found by coverity.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

v2: Handle callers passing in a NULL seqno.
v3: Ditto. This time for sure.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/i915_gem.c  |   15 +++
 drivers/gpu/drm/i915/intel_overlay.c |   72 +++---
 3 files changed, 24 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dddc3dc..d8d4736 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1468,7 +1468,7 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
 int __must_check i915_gem_idle(struct drm_device *dev);
 int i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request);
+u32 *seqno);
 int __must_check i915_wait_seqno(struct intel_ring_buffer *ring,
 uint32_t seqno);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2effab..014b95e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2087,11 +2087,12 @@ i915_gem_next_request_seqno(struct intel_ring_buffer 
*ring)
 int
 i915_add_request(struct intel_ring_buffer *ring,
 struct drm_file *file,
-struct drm_i915_gem_request *request)
+u32 *out_seqno)
 {
drm_i915_private_t *dev_priv = ring->dev->dev_private;
-   uint32_t seqno;
+   struct drm_i915_gem_request *request;
u32 request_ring_position;
+   u32 seqno;
int was_empty;
int ret;
 
@@ -2106,11 +2107,9 @@ i915_add_request(struct intel_ring_buffer *ring,
if (ret)
return ret;
 
-   if (request == NULL) {
-   request = kmalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL)
-   return -ENOMEM;
-   }
+   request = kmalloc(sizeof(*request), GFP_KERNEL);
+   if (request == NULL)
+   return -ENOMEM;
 
seqno = i915_gem_next_request_seqno(ring);
 
@@ -2162,6 +2161,8 @@ i915_add_request(struct intel_ring_buffer *ring,
}
}
 
+   if (out_seqno)
+   *out_seqno = seqno;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index 2fa20a4..ebcbf48 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -210,7 +210,6 @@ static void intel_overlay_unmap_regs(struct intel_overlay 
*overlay,
 }
 
 static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
-struct drm_i915_gem_request *request,
 void (*tail)(struct intel_overlay *))
 {
struct drm_device *dev = overlay->dev;
@@ -219,12 +218,10 @@ static int intel_overlay_do_wait_request(struct 
intel_overlay *overlay,
int ret;
 
BUG_ON(overlay->last_flip_req);
-   ret = i915_add_request(ring, NULL, request);
-   if (ret) {
-   kfree(request);
-   return ret;
-   }
-   overlay->last_flip_req = request->seqno;
+   ret = i915_add_request(ring, NULL, &overlay->last_flip_req);
+   if (ret)
+   return ret;
+
overlay->flip_tail = tail;
ret = i915_wait_seqno(ring, overlay->last_flip_req);
if (ret)
@@ -241,7 +238,6 @@ static int intel_overlay_on(struct intel_overlay *overlay)
struct drm_device *dev = overlay->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_ring_buffer *ring = &dev_priv->ring[RCS];
-   struct drm_i915_gem_request *request;
int ret;
 
BUG_ON(overlay->active);
@@ -249,17 +245,9 @@ static int intel_overlay_on(struct intel_overlay *overlay)
 
WARN_ON(IS_I830(dev) && !(dev_priv->quirks & QUIRK_PIPEA_FORCE));
 
-   request = kzalloc(sizeof(*request), GFP_KERNEL);
-   if (request == NULL) {
-   ret = -ENOMEM;
-  

[Intel-gfx] [PATCH 0/9] Enable all display interfaces in Valleyview

2012-09-26 Thread Vijay Purushothaman
This patch set enables all supported display interfaces like HDMI, DisplayPort 
and eDP for Valleyview. This also enables support for multi-display 
configurations.

Jesse, Ben : Since this patch set was reviewed in internal mailing lists, could 
you please add your reviewed-by & tested-by tags?

Bhat, Gajanan (1):
  drm/i915: Enable multi display support in VLV

Vijay Purushothaman (8):
  drm/i915: Set aux clk to 100MHz for Valleyview
  drm/i915: Fix SDVO IER and status bits for Valleyview
  drm/i915: Add Valleyview lane control definitions
  drm/i915: Program correct m n tu register for Valleyview
  drm/i915: Fix lanecontrol, vswing, preemp for Valleyview DisplayPort
  drm/i915: Add eDP support for Valleyview
  drm/i915: panel power sequencing for VLV eDP
  drm/i915: Reverse min,max vco limits for VLV HDMI

 drivers/gpu/drm/i915/i915_irq.c  |6 +-
 drivers/gpu/drm/i915/i915_reg.h  |   15 +++-
 drivers/gpu/drm/i915/intel_crt.c |7 ++
 drivers/gpu/drm/i915/intel_display.c |  103 ---
 drivers/gpu/drm/i915/intel_dp.c  |  148 --
 5 files changed, 200 insertions(+), 79 deletions(-)

-- 
1.7.9.5

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


[Intel-gfx] [PATCH 2/9] drm/i915: Fix SDVO IER and status bits for Valleyview

2012-09-26 Thread Vijay Purushothaman
Fixed SDVOB and SDVOC bit definitions for Valleyview.

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d915126..1a974d9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2020,7 +2020,6 @@ static int valleyview_irq_postinstall(struct drm_device 
*dev)
 #endif
 
I915_WRITE(VLV_MASTER_IER, MASTER_INTERRUPT_ENABLE);
-#if 0 /* FIXME: check register definitions; some have moved */
/* Note HDMI and DP share bits */
if (dev_priv->hotplug_supported_mask & HDMIB_HOTPLUG_INT_STATUS)
hotplug_en |= HDMIB_HOTPLUG_INT_EN;
@@ -2028,15 +2027,14 @@ static int valleyview_irq_postinstall(struct drm_device 
*dev)
hotplug_en |= HDMIC_HOTPLUG_INT_EN;
if (dev_priv->hotplug_supported_mask & HDMID_HOTPLUG_INT_STATUS)
hotplug_en |= HDMID_HOTPLUG_INT_EN;
-   if (dev_priv->hotplug_supported_mask & SDVOC_HOTPLUG_INT_STATUS)
+   if (dev_priv->hotplug_supported_mask & SDVOC_HOTPLUG_INT_STATUS_I915)
hotplug_en |= SDVOC_HOTPLUG_INT_EN;
-   if (dev_priv->hotplug_supported_mask & SDVOB_HOTPLUG_INT_STATUS)
+   if (dev_priv->hotplug_supported_mask & SDVOB_HOTPLUG_INT_STATUS_I915)
hotplug_en |= SDVOB_HOTPLUG_INT_EN;
if (dev_priv->hotplug_supported_mask & CRT_HOTPLUG_INT_STATUS) {
hotplug_en |= CRT_HOTPLUG_INT_EN;
hotplug_en |= CRT_HOTPLUG_VOLTAGE_COMPARE_50;
}
-#endif
 
I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
 
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 1/9] drm/i915: Set aux clk to 100MHz for Valleyview

2012-09-26 Thread Vijay Purushothaman
Set hrawclk to 200 MHz and aux divider clock to 100 MHz for Valleyview.
This enables the aux transactions in Valleyview.

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_dp.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a69d9a2..de8092a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -285,6 +285,10 @@ intel_hrawclk(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t clkcfg;
 
+   /* There is no CLKCFG reg in Valleyview. VLV hrawclk is 200 MHz */
+   if (IS_VALLEYVIEW(dev))
+   return 200;
+
clkcfg = I915_READ(CLKCFG);
switch (clkcfg & CLKCFG_FSB_MASK) {
case CLKCFG_FSB_400:
@@ -365,7 +369,9 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 * clock divider.
 */
if (is_cpu_edp(intel_dp)) {
-   if (IS_GEN6(dev) || IS_GEN7(dev))
+   if (IS_VALLEYVIEW(dev))
+   aux_clock_divider = 100;
+   else if (IS_GEN6(dev) || IS_GEN7(dev))
aux_clock_divider = 200; /* SNB & IVB eDP input clock 
at 400Mhz */
else
aux_clock_divider = 225; /* eDP input clock at 450Mhz */
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 3/9] drm/i915: Add Valleyview lane control definitions

2012-09-26 Thread Vijay Purushothaman
Added DPIO data lane register definitions for Valleyview

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a828e90..3f75ee6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -369,6 +369,7 @@
 #define   DPIO_PLL_MODESEL_SHIFT   24 /* 3 bits */
 #define   DPIO_BIAS_CURRENT_CTL_SHIFT  21 /* 3 bits, always 0x7 */
 #define   DPIO_PLL_REFCLK_SEL_SHIFT16 /* 2 bits */
+#define   DPIO_PLL_REFCLK_SEL_MASK 3
 #define   DPIO_DRIVER_CTL_SHIFT12 /* always set to 0x8 */
 #define   DPIO_CLK_BIAS_CTL_SHIFT  8 /* always set to 0x5 */
 #define _DPIO_REFSFR_B 0x8034
@@ -384,6 +385,13 @@
 
 #define DPIO_FASTCLK_DISABLE   0x8100
 
+#define _DPIO_DATA_LANE0   0x0220
+#define _DPIO_DATA_LANE1   0x0420
+#define _DPIO_DATA_LANE2   0x2620
+#define _DPIO_DATA_LANE3   0x2820
+#define DPIO_DATA_LANE_A(pipe) _PIPE(pipe, _DPIO_DATA_LANE0, _DPIO_DATA_LANE2)
+#define DPIO_DATA_LANE_B(pipe) _PIPE(pipe, _DPIO_DATA_LANE1, _DPIO_DATA_LANE3)
+
 /*
  * Fence registers
  */
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 5/9] drm/i915: Fix lanecontrol, vswing, preemp for Valleyview DisplayPort

2012-09-26 Thread Vijay Purushothaman
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Also use
i9xx_update_pll to program the correct DPLL sequence.

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Gajanan Bhat 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_crt.c |7 ++
 drivers/gpu/drm/i915/intel_display.c |   44 --
 2 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index c42b980..bd23bdf 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -308,6 +308,13 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)
bool ret;
u32 save_adpa;
 
+   /*
+* Disable crt detect hotplug for VLV X0. spurious hot plug
+* detect calls crashes the X0 system
+*/
+   if (IS_VALLEYVIEW(dev))
+   return false;
+
save_adpa = adpa = I915_READ(ADPA);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 68828e7..a8a81d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3944,6 +3944,10 @@ static void i9xx_update_pll_dividers(struct drm_crtc 
*crtc,
int pipe = intel_crtc->pipe;
u32 fp, fp2 = 0;
 
+   /* Disable FP0 register programming for VLV X0 */
+   if (IS_VALLEYVIEW(dev))
+   return;
+
if (IS_PINEVIEW(dev)) {
fp = (1 << clock->n) << 16 | clock->m1 << 8 | clock->m2;
if (reduced_clock)
@@ -4051,12 +4055,13 @@ static void vlv_update_pll(struct drm_crtc *crtc,
 
intel_dpio_write(dev_priv, DPIO_CORE_CLK(pipe), 0x0100);
 
-   pdiv = DPIO_REFSEL_OVERRIDE | (5 << DPIO_PLL_MODESEL_SHIFT) |
+   pdiv = (1 << DPIO_REFSEL_OVERRIDE) | (5 << DPIO_PLL_MODESEL_SHIFT) |
(3 << DPIO_BIAS_CURRENT_CTL_SHIFT) | (1<<20) |
-   (8 << DPIO_DRIVER_CTL_SHIFT) | (5 << DPIO_CLK_BIAS_CTL_SHIFT);
+   (7 << DPIO_PLL_REFCLK_SEL_SHIFT) | (8 << DPIO_DRIVER_CTL_SHIFT) 
|
+   (5 << DPIO_CLK_BIAS_CTL_SHIFT);
intel_dpio_write(dev_priv, DPIO_REFSFR(pipe), pdiv);
 
-   intel_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe), 0x009f0051);
+   intel_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe), 0x005f003b);
 
dpll |= DPLL_VCO_ENABLE;
I915_WRITE(DPLL(pipe), dpll);
@@ -4076,7 +4081,7 @@ static void vlv_update_pll(struct drm_crtc *crtc,
POSTING_READ(DPLL_MD(pipe));
}
 
-   intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x641); /* ??? */
+   intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x620);
 }
 
 static void i9xx_update_pll(struct drm_crtc *crtc,
@@ -4112,6 +4117,12 @@ static void i9xx_update_pll(struct drm_crtc *crtc,
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
dpll |= DPLL_DVO_HIGH_SPEED;
 
+   if (IS_VALLEYVIEW(dev)) {
+   dpll |= DPLL_EXT_BUFFER_ENABLE_VLV;
+   dpll |= DPLL_REFA_CLK_ENABLE_VLV;
+   dpll |= DPLL_INTEGRATED_CLOCK_VLV;
+   }
+
/* compute bitmask from p1 value */
if (IS_PINEVIEW(dev))
dpll |= (1 << (clock->p1 - 1)) << 
DPLL_FPA01_P1_POST_DIV_SHIFT_PINEVIEW;
@@ -4152,6 +4163,17 @@ static void i9xx_update_pll(struct drm_crtc *crtc,
dpll |= DPLL_VCO_ENABLE;
I915_WRITE(DPLL(pipe), dpll & ~DPLL_VCO_ENABLE);
POSTING_READ(DPLL(pipe));
+
+   /*
+* In Valleyview PLL and program lane counter registes are exposed
+* through DPIO interface
+*/
+   if (IS_VALLEYVIEW(dev)) {
+   int refclk;
+   refclk = i9xx_get_refclk(crtc, num_connectors);
+   vlv_update_pll(crtc, mode, adjusted_mode, clock, NULL, refclk,
+   num_connectors);
+   }
udelay(150);
 
/* The LVDS pin pair needs to be on before the DPLLs are enabled.
@@ -4170,6 +4192,17 @@ static void i9xx_update_pll(struct drm_crtc *crtc,
POSTING_READ(DPLL(pipe));
udelay(150);
 
+   /* Now program lane control registers for Valleyview */
+   if (IS_VALLEYVIEW(dev)) {
+   u32 temp = 0;
+   temp = intel_dpio_read(dev_priv, DPIO_DATA_LANE_A(pipe));
+   temp |= (1 << 20);
+   intel_dpio_write(dev_priv, DPIO_DATA_LANE_A(pipe), temp);
+   temp = intel_dpio_read(dev_priv, DPIO_DATA_LANE_B(pipe));
+   temp |= (1 << 20);
+   intel_dpio_write(dev_priv, DPIO_DATA_LANE_B(pipe), temp);
+   }
+
if (INTEL_INFO(dev)->gen >= 4) {
u32 temp = 0;
if (is_sdvo) {
@@ -4332,9 +4365,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
 
if (IS_GEN2(dev))
i8xx_u

[Intel-gfx] [PATCH 4/9] drm/i915: Program correct m n tu register for Valleyview

2012-09-26 Thread Vijay Purushothaman
m n tu register offset has changed in Valleyview. Also fixed DP limit
frequencies.

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c |6 +++---
 drivers/gpu/drm/i915/intel_dp.c  |5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 947c97d..68828e7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -393,10 +393,10 @@ static const intel_limit_t intel_limits_vlv_hdmi = {
 };
 
 static const intel_limit_t intel_limits_vlv_dp = {
-   .dot = { .min = 162000, .max = 27 },
-   .vco = { .min = 5994000, .max = 400 },
+   .dot = { .min = 25000, .max = 27 },
+   .vco = { .min = 400, .max = 600 },
.n = { .min = 1, .max = 7 },
-   .m = { .min = 60, .max = 300 }, /* guess */
+   .m = { .min = 22, .max = 450 },
.m1 = { .min = 2, .max = 3 },
.m2 = { .min = 11, .max = 156 },
.p = { .min = 10, .max = 30 },
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index de8092a..c111c3f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -804,6 +804,11 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
I915_WRITE(TRANSDATA_N1(pipe), m_n.gmch_n);
I915_WRITE(TRANSDPLINK_M1(pipe), m_n.link_m);
I915_WRITE(TRANSDPLINK_N1(pipe), m_n.link_n);
+   } else if (IS_VALLEYVIEW(dev)) {
+   I915_WRITE(PIPE_DATA_M1(pipe), TU_SIZE(m_n.tu) | m_n.gmch_m);
+   I915_WRITE(PIPE_DATA_N1(pipe), m_n.gmch_n);
+   I915_WRITE(PIPE_LINK_M1(pipe), m_n.link_m);
+   I915_WRITE(PIPE_LINK_N1(pipe), m_n.link_n);
} else {
I915_WRITE(PIPE_GMCH_DATA_M(pipe),
   ((m_n.tu - 1) << PIPE_GMCH_DATA_M_TU_SIZE_SHIFT) |
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 7/9] drm/i915: panel power sequencing for VLV eDP

2012-09-26 Thread Vijay Purushothaman
PPS register offsets have changed in Valleyview.

Signed-off-by: Gajanan Bhat 
Signed-off-by: Vijay Purushothaman 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h |9 +++
 drivers/gpu/drm/i915/intel_dp.c |  122 +++
 2 files changed, 93 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3f75ee6..e421847 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3981,6 +3981,15 @@
 #define PIPEB_PP_ON_DELAYS  0x61308
 #define PIPEB_PP_OFF_DELAYS 0x6130c
 #define PIPEB_PP_DIVISOR0x61310
+#define VLV_PIPE_PP_STATUS(pipe) _PIPE(pipe, PIPEA_PP_STATUS, PIPEB_PP_STATUS)
+#define VLV_PIPE_PP_CONTROL(pipe) _PIPE(pipe, PIPEA_PP_CONTROL, 
PIPEB_PP_CONTROL)
+#define VLV_PIPE_PP_ON_DELAYS(pipe) \
+   _PIPE(pipe, PIPEA_PP_ON_DELAYS, PIPEB_PP_ON_DELAYS)
+#define VLV_PIPE_PP_OFF_DELAYS(pipe) \
+   _PIPE(pipe, PIPEA_PP_OFF_DELAYS, PIPEB_PP_OFF_DELAYS)
+#define VLV_PIPE_PP_DIVISOR(pipe) \
+   _PIPE(pipe, PIPEA_PP_DIVISOR, PIPEB_PP_DIVISOR)
+
 
 #define PCH_PP_STATUS  0xc7200
 #define PCH_PP_CONTROL 0xc7204
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index af57027..b944529 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -316,16 +316,20 @@ static bool ironlake_edp_have_panel_power(struct intel_dp 
*intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 pp_stat_reg;
 
-   return (I915_READ(PCH_PP_STATUS) & PP_ON) != 0;
+   pp_stat_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_STATUS : PCH_PP_STATUS;
+   return (I915_READ(pp_stat_reg) & PP_ON) != 0;
 }
 
 static bool ironlake_edp_have_panel_vdd(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 pp_ctrl_reg;
 
-   return (I915_READ(PCH_PP_CONTROL) & EDP_FORCE_VDD) != 0;
+   pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
+   return (I915_READ(pp_ctrl_reg) & EDP_FORCE_VDD) != 0;
 }
 
 static void
@@ -333,14 +337,19 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 pp_stat_reg, pp_ctrl_reg;
 
if (!is_edp(intel_dp))
return;
+
+   pp_stat_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_STATUS : PCH_PP_STATUS;
+   pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
+
if (!ironlake_edp_have_panel_power(intel_dp) && 
!ironlake_edp_have_panel_vdd(intel_dp)) {
WARN(1, "eDP powered off while attempting aux channel 
communication.\n");
DRM_DEBUG_KMS("Status 0x%08x Control 0x%08x\n",
- I915_READ(PCH_PP_STATUS),
- I915_READ(PCH_PP_CONTROL));
+   I915_READ(pp_stat_reg),
+   I915_READ(pp_ctrl_reg));
}
 }
 
@@ -944,16 +953,20 @@ static void ironlake_wait_panel_status(struct intel_dp 
*intel_dp,
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 pp_stat_reg, pp_ctrl_reg;
+
+   pp_stat_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_STATUS : PCH_PP_STATUS;
+   pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
 
DRM_DEBUG_KMS("mask %08x value %08x status %08x control %08x\n",
- mask, value,
- I915_READ(PCH_PP_STATUS),
- I915_READ(PCH_PP_CONTROL));
+   mask, value,
+   I915_READ(pp_stat_reg),
+   I915_READ(pp_ctrl_reg));
 
-   if (_wait_for((I915_READ(PCH_PP_STATUS) & mask) == value, 5000, 10)) {
+   if (_wait_for((I915_READ(pp_stat_reg) & mask) == value, 5000, 10)) {
DRM_ERROR("Panel status timeout: status %08x control %08x\n",
- I915_READ(PCH_PP_STATUS),
- I915_READ(PCH_PP_CONTROL));
+   I915_READ(pp_stat_reg),
+   I915_READ(pp_ctrl_reg));
}
 }
 
@@ -980,9 +993,15 @@ static void ironlake_wait_panel_power_cycle(struct 
intel_dp *intel_dp)
  * is locked
  */
 
-static  u32 ironlake_get_pp_control(struct drm_i915_private *dev_priv)
+static  u32 ironlake_get_pp_control(struct intel_dp *intel_dp)
 {
-   u32 control = I915_READ(PCH_PP_CONTROL);
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 control;
+   u32 pp_ctrl_reg;
+
+   pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
+   

[Intel-gfx] [PATCH 6/9] drm/i915: Add eDP support for Valleyview

2012-09-26 Thread Vijay Purushothaman
Eventhough Valleyview display block is derived from Cantiga, VLV
supports eDP. So, added eDP checks in i9xx_crtc_mode_set path.

v2: use different DPIO_DIVISOR values for VGA, DP and eDP
v3: fix DPIO value calculation to use same values for all display
interfaces

Signed-off-by: Gajanan Bhat 
Signed-off-by: Vijay Purushothaman 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c |6 ++
 drivers/gpu/drm/i915/intel_dp.c  |   13 -
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a8a81d1..aee6151 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4405,6 +4405,12 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
}
}
 
+   if (IS_VALLEYVIEW(dev) && intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
+   pipeconf |= PIPECONF_BPP_6 |
+   PIPECONF_ENABLE |
+   I965_PIPECONF_ACTIVE;
+   }
+
DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe == 0 ? 'A' : 'B');
drm_mode_debug_printmodeline(mode);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c111c3f..af57027 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -885,7 +885,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
 
/* Split out the IBX/CPU vs CPT settings */
 
-   if (is_cpu_edp(intel_dp) && IS_GEN7(dev)) {
+   if (is_cpu_edp(intel_dp) && IS_GEN7(dev) && !IS_VALLEYVIEW(dev)) {
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
intel_dp->DP |= DP_SYNC_HS_HIGH;
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
@@ -1474,7 +1474,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
uint8_t voltage_swing)
 {
struct drm_device *dev = intel_dp->base.base.dev;
 
-   if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
+   if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && !IS_VALLEYVIEW(dev)) {
switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
case DP_TRAIN_VOLTAGE_SWING_400:
return DP_TRAIN_PRE_EMPHASIS_6;
@@ -1773,7 +1773,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
uint32_tsignal_levels;
 
 
-   if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
+   if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && 
!IS_VALLEYVIEW(dev)) {
signal_levels = 
intel_gen7_edp_signal_levels(intel_dp->train_set[0]);
DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_IVB) | 
signal_levels;
} else if (IS_GEN6(dev) && is_cpu_edp(intel_dp)) {
@@ -1859,7 +1859,7 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
break;
}
 
-   if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
+   if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && 
!IS_VALLEYVIEW(dev)) {
signal_levels = 
intel_gen7_edp_signal_levels(intel_dp->train_set[0]);
DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_IVB) | 
signal_levels;
} else if (IS_GEN6(dev) && is_cpu_edp(intel_dp)) {
@@ -2471,7 +2471,10 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
if (intel_dpd_is_edp(dev))
intel_dp->is_pch_edp = true;
 
-   if (output_reg == DP_A || is_pch_edp(intel_dp)) {
+   if (IS_VALLEYVIEW(dev) && output_reg == DP_C) {
+   type = DRM_MODE_CONNECTOR_eDP;
+   intel_encoder->type = INTEL_OUTPUT_EDP;
+   } else if (output_reg == DP_A || is_pch_edp(intel_dp)) {
type = DRM_MODE_CONNECTOR_eDP;
intel_encoder->type = INTEL_OUTPUT_EDP;
} else {
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 8/9] drm/i915: Reverse min, max vco limits for VLV HDMI

2012-09-26 Thread Vijay Purushothaman
Fixed min, max vco limits for VLV HDMI. Also fixed correct register
offset for VLV_VIDEO_DIP_CTL_A

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Gajanan Bhat 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h  |2 +-
 drivers/gpu/drm/i915/intel_display.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e421847..d4ed30e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3687,7 +3687,7 @@
 #define TVIDEO_DIP_DATA(pipe) _PIPE(pipe, _VIDEO_DIP_DATA_A, _VIDEO_DIP_DATA_B)
 #define TVIDEO_DIP_GCP(pipe) _PIPE(pipe, _VIDEO_DIP_GCP_A, _VIDEO_DIP_GCP_B)
 
-#define VLV_VIDEO_DIP_CTL_A0x60220
+#define VLV_VIDEO_DIP_CTL_A0x60200
 #define VLV_VIDEO_DIP_DATA_A   0x60208
 #define VLV_VIDEO_DIP_GDCP_PAYLOAD_A   0x60210
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index aee6151..647e311 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -380,7 +380,7 @@ static const intel_limit_t intel_limits_vlv_dac = {
 
 static const intel_limit_t intel_limits_vlv_hdmi = {
.dot = { .min = 2, .max = 165000 },
-   .vco = { .min = 5994000, .max = 400 },
+   .vco = { .min = 400, .max = 5994000},
.n = { .min = 1, .max = 7 },
.m = { .min = 60, .max = 300 }, /* guess */
.m1 = { .min = 2, .max = 3 },
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 9/9] drm/i915: Enable multi display support in VLV

2012-09-26 Thread Vijay Purushothaman
From: "Bhat, Gajanan" 

Clened up DPLL calculations for Valleyview. Moved DPLL register and DPIO
programming to vlv_update_pll function. With all the changes multi
display (clone, extended desktop) should work for VLV.

Signed-off-by: Gajanan Bhat 
---
 drivers/gpu/drm/i915/i915_reg.h  |8 +--
 drivers/gpu/drm/i915/intel_display.c |  105 ++
 2 files changed, 58 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4ed30e..71aa0a7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -385,12 +385,8 @@
 
 #define DPIO_FASTCLK_DISABLE   0x8100
 
-#define _DPIO_DATA_LANE0   0x0220
-#define _DPIO_DATA_LANE1   0x0420
-#define _DPIO_DATA_LANE2   0x2620
-#define _DPIO_DATA_LANE3   0x2820
-#define DPIO_DATA_LANE_A(pipe) _PIPE(pipe, _DPIO_DATA_LANE0, _DPIO_DATA_LANE2)
-#define DPIO_DATA_LANE_B(pipe) _PIPE(pipe, _DPIO_DATA_LANE1, _DPIO_DATA_LANE3)
+#define DPIO_DATA_CHANNEL1 0x8220
+#define DPIO_DATA_CHANNEL2 0x8420
 
 /*
  * Fence registers
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 647e311..e933031 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4018,10 +4018,10 @@ static void intel_update_lvds(struct drm_crtc *crtc, 
intel_clock_t *clock,
 }
 
 static void vlv_update_pll(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode,
-  intel_clock_t *clock, intel_clock_t *reduced_clock,
-  int refclk, int num_connectors)
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode,
+   intel_clock_t *clock, intel_clock_t *reduced_clock,
+   int num_connectors)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -4029,9 +4029,19 @@ static void vlv_update_pll(struct drm_crtc *crtc,
int pipe = intel_crtc->pipe;
u32 dpll, mdiv, pdiv;
u32 bestn, bestm1, bestm2, bestp1, bestp2;
-   bool is_hdmi;
+   bool is_sdvo;
+   u32 temp;
 
-   is_hdmi = intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
+   is_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
+   intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
+
+   dpll = DPLL_VGA_MODE_DIS;
+   dpll |= DPLL_EXT_BUFFER_ENABLE_VLV;
+   dpll |= DPLL_REFA_CLK_ENABLE_VLV;
+   dpll |= DPLL_INTEGRATED_CLOCK_VLV;
+
+   I915_WRITE(DPLL(pipe), dpll);
+   POSTING_READ(DPLL(pipe));
 
bestn = clock->n;
bestm1 = clock->m1;
@@ -4039,12 +4049,10 @@ static void vlv_update_pll(struct drm_crtc *crtc,
bestp1 = clock->p1;
bestp2 = clock->p2;
 
-   /* Enable DPIO clock input */
-   dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
-   DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
-   I915_WRITE(DPLL(pipe), dpll);
-   POSTING_READ(DPLL(pipe));
-
+   /*
+* In Valleyview PLL and program lane counter registes are exposed
+* through DPIO interface
+*/
mdiv = ((bestm1 << DPIO_M1DIV_SHIFT) | (bestm2 & DPIO_M2DIV_MASK));
mdiv |= ((bestp1 << DPIO_P1_SHIFT) | (bestp2 << DPIO_P2_SHIFT));
mdiv |= ((bestn << DPIO_N_SHIFT));
@@ -4069,21 +4077,47 @@ static void vlv_update_pll(struct drm_crtc *crtc,
if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
DPLL_LOCK_VLV), 1))
DRM_ERROR("DPLL %d failed to lock\n", pipe);
 
-   if (is_hdmi) {
-   u32 temp = intel_mode_get_pixel_multiplier(adjusted_mode);
+   intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x620);
+
+   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
+   intel_dp_set_m_n(crtc, mode, adjusted_mode);
+
+   I915_WRITE(DPLL(pipe), dpll);
+
+   /* Wait for the clocks to stabilize. */
+   POSTING_READ(DPLL(pipe));
+   udelay(150);
 
+   temp = 0;
+   if (is_sdvo) {
+   temp = intel_mode_get_pixel_multiplier(adjusted_mode);
if (temp > 1)
temp = (temp - 1) << DPLL_MD_UDI_MULTIPLIER_SHIFT;
else
temp = 0;
-
-   I915_WRITE(DPLL_MD(pipe), temp);
-   POSTING_READ(DPLL_MD(pipe));
}
+   I915_WRITE(DPLL_MD(pipe), temp);
+   POSTING_READ(DPLL_MD(pipe));
 
-   intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x620);
+   /* Now program lane control registers */
+   if(intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)
+   || intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
+   {
+   temp = 0x10

[Intel-gfx] Question regarding libva encoding

2012-09-26 Thread Charlie Good
Hello my name is Charlie Good and I am the CTO of Wowza Media System. We are 
the authors of Wowza Media Server. Our product includes a transcoder for 
transcoding incoming streams to adaptive bitrate stream sets. We are only using 
the AVC/H.264 encoder at this time. We are looking to use libva for accelerated 
encoding on Linux leveraging the Quick Sync technology. We are already doing 
this on Windows using the Intel Media SDK. I have an implementation that is 
currently working when using the baseline profile. I would also like to support 
main and high profile. It looks like these profiles are not yet implemented. I 
can see this in gen6_mfc.c in the pipeline code where it looks like only 
baseline encoding is supported:

VAStatus
gen6_mfc_pipeline(VADriverContextP ctx,
  VAProfile profile,
  struct encode_state *encode_state,
  struct gen6_encoder_context *gen6_encoder_context)
{
VAStatus vaStatus;

switch (profile) {
case VAProfileH264Baseline:
vaStatus = gen6_mfc_avc_encode_picture(ctx, encode_state, 
gen6_encoder_context);
break;

/* FIXME: add for other profile */
default:
vaStatus = VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
break;
}

return vaStatus;
}

Is there a plan to add support for main and high encoding in a future release? 
Do you have any estimate of when this might be added?

BTW, I am a huge fan of Intel Quick Sync. Very cool technology. Amazing 
performance and quality.

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


Re: [Intel-gfx] [PATCH 7/9] drm/i915: limit VLV IRQ enables to those we use

2012-09-26 Thread Daniel Vetter
On Wed, Sep 19, 2012 at 01:29:01PM -0700, Jesse Barnes wrote:
> To match IVB.
> 
> Signed-off-by: Jesse Barnes 
Queued for -next, thanks for the patch.
-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 5/9] drm/i915: Fix lanecontrol, vswing, preemp for Valleyview DisplayPort

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 07:07:34PM +0530, Vijay Purushothaman wrote:
> In Valleyview voltage swing, pre-emphasis and lane control registers can
> be programmed only through the h/w side band fabric. Also use
> i9xx_update_pll to program the correct DPLL sequence.
> 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Gajanan Bhat 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/intel_crt.c |7 ++
>  drivers/gpu/drm/i915/intel_display.c |   44 
> --
>  2 files changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index c42b980..bd23bdf 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -308,6 +308,13 @@ static bool valleyview_crt_detect_hotplug(struct 
> drm_connector *connector)
>   bool ret;
>   u32 save_adpa;
>  
> + /*
> +  * Disable crt detect hotplug for VLV X0. spurious hot plug
> +  * detect calls crashes the X0 system
> +  */
> + if (IS_VALLEYVIEW(dev))
> + return false;

This hunk here belongs into a different patch.

> +
>   save_adpa = adpa = I915_READ(ADPA);
>   DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 68828e7..a8a81d1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3944,6 +3944,10 @@ static void i9xx_update_pll_dividers(struct drm_crtc 
> *crtc,
>   int pipe = intel_crtc->pipe;
>   u32 fp, fp2 = 0;
>  
> + /* Disable FP0 register programming for VLV X0 */
> + if (IS_VALLEYVIEW(dev))
> + return;

This patch folds back the vlv_update_pll function into the i9xx_update_pll
function, which is imo the wrong approach (since you add quite some if
(IS_VLV) blocks). Better would be to move the i9xx_update_pll_dividers
into i8xx_update_pll and i9xx_update_pll and then keep the vlv_update_pll
(and only apply the necessary fixes there.
-Daniel
)
> +
>   if (IS_PINEVIEW(dev)) {
>   fp = (1 << clock->n) << 16 | clock->m1 << 8 | clock->m2;
>   if (reduced_clock)
> @@ -4051,12 +4055,13 @@ static void vlv_update_pll(struct drm_crtc *crtc,
>  
>   intel_dpio_write(dev_priv, DPIO_CORE_CLK(pipe), 0x0100);
>  
> - pdiv = DPIO_REFSEL_OVERRIDE | (5 << DPIO_PLL_MODESEL_SHIFT) |
> + pdiv = (1 << DPIO_REFSEL_OVERRIDE) | (5 << DPIO_PLL_MODESEL_SHIFT) |
>   (3 << DPIO_BIAS_CURRENT_CTL_SHIFT) | (1<<20) |
> - (8 << DPIO_DRIVER_CTL_SHIFT) | (5 << DPIO_CLK_BIAS_CTL_SHIFT);
> + (7 << DPIO_PLL_REFCLK_SEL_SHIFT) | (8 << DPIO_DRIVER_CTL_SHIFT) 
> |
> + (5 << DPIO_CLK_BIAS_CTL_SHIFT);
>   intel_dpio_write(dev_priv, DPIO_REFSFR(pipe), pdiv);
>  
> - intel_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe), 0x009f0051);
> + intel_dpio_write(dev_priv, DPIO_LFP_COEFF(pipe), 0x005f003b);
>  
>   dpll |= DPLL_VCO_ENABLE;
>   I915_WRITE(DPLL(pipe), dpll);
> @@ -4076,7 +4081,7 @@ static void vlv_update_pll(struct drm_crtc *crtc,
>   POSTING_READ(DPLL_MD(pipe));
>   }
>  
> - intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x641); /* ??? */
> + intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x620);
>  }
>  
>  static void i9xx_update_pll(struct drm_crtc *crtc,
> @@ -4112,6 +4117,12 @@ static void i9xx_update_pll(struct drm_crtc *crtc,
>   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
>   dpll |= DPLL_DVO_HIGH_SPEED;
>  
> + if (IS_VALLEYVIEW(dev)) {
> + dpll |= DPLL_EXT_BUFFER_ENABLE_VLV;
> + dpll |= DPLL_REFA_CLK_ENABLE_VLV;
> + dpll |= DPLL_INTEGRATED_CLOCK_VLV;
> + }
> +
>   /* compute bitmask from p1 value */
>   if (IS_PINEVIEW(dev))
>   dpll |= (1 << (clock->p1 - 1)) << 
> DPLL_FPA01_P1_POST_DIV_SHIFT_PINEVIEW;
> @@ -4152,6 +4163,17 @@ static void i9xx_update_pll(struct drm_crtc *crtc,
>   dpll |= DPLL_VCO_ENABLE;
>   I915_WRITE(DPLL(pipe), dpll & ~DPLL_VCO_ENABLE);
>   POSTING_READ(DPLL(pipe));
> +
> + /*
> +  * In Valleyview PLL and program lane counter registes are exposed
> +  * through DPIO interface
> +  */
> + if (IS_VALLEYVIEW(dev)) {
> + int refclk;
> + refclk = i9xx_get_refclk(crtc, num_connectors);
> + vlv_update_pll(crtc, mode, adjusted_mode, clock, NULL, refclk,
> + num_connectors);
> + }
>   udelay(150);
>  
>   /* The LVDS pin pair needs to be on before the DPLLs are enabled.
> @@ -4170,6 +4192,17 @@ static void i9xx_update_pll(struct drm_crtc *crtc,
>   POSTING_READ(DPLL(pipe));
>   udelay(150);
>  
> + /* Now program lane control registers for Valleyview */
> + if (IS_VALLEYVIEW(dev)) {
> + u32 temp = 0;
> + temp = intel_dpio_re

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Add eDP support for Valleyview

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 07:07:35PM +0530, Vijay Purushothaman wrote:
> Eventhough Valleyview display block is derived from Cantiga, VLV
> supports eDP. So, added eDP checks in i9xx_crtc_mode_set path.
> 
> v2: use different DPIO_DIVISOR values for VGA, DP and eDP
> v3: fix DPIO value calculation to use same values for all display
>   interfaces
> 
> Signed-off-by: Gajanan Bhat 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/intel_display.c |6 ++
>  drivers/gpu/drm/i915/intel_dp.c  |   13 -
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a8a81d1..aee6151 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4405,6 +4405,12 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>   }
>   }
>  
> + if (IS_VALLEYVIEW(dev) && intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
> + pipeconf |= PIPECONF_BPP_6 |
> + PIPECONF_ENABLE |
> + I965_PIPECONF_ACTIVE;
> + }

No.

Jani Nikula and me just figured out that we have a giant mess with 6bpc
dithering on DP outputs, but unconditionally enabling 6bpc on vlv eDP only
papers over issues.

> +
>   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe == 0 ? 'A' : 'B');
>   drm_mode_debug_printmodeline(mode);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c111c3f..af57027 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -885,7 +885,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
> drm_display_mode *mode,
>  
>   /* Split out the IBX/CPU vs CPT settings */
>  
> - if (is_cpu_edp(intel_dp) && IS_GEN7(dev)) {
> + if (is_cpu_edp(intel_dp) && IS_GEN7(dev) && !IS_VALLEYVIEW(dev)) {
>   if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
>   intel_dp->DP |= DP_SYNC_HS_HIGH;
>   if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
> @@ -1474,7 +1474,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
> uint8_t voltage_swing)
>  {
>   struct drm_device *dev = intel_dp->base.base.dev;
>  
> - if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
> + if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && !IS_VALLEYVIEW(dev)) {
>   switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
>   case DP_TRAIN_VOLTAGE_SWING_400:
>   return DP_TRAIN_PRE_EMPHASIS_6;
> @@ -1773,7 +1773,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>   uint32_tsignal_levels;
>  
>  
> - if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
> + if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && 
> !IS_VALLEYVIEW(dev)) {
>   signal_levels = 
> intel_gen7_edp_signal_levels(intel_dp->train_set[0]);
>   DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_IVB) | 
> signal_levels;
>   } else if (IS_GEN6(dev) && is_cpu_edp(intel_dp)) {
> @@ -1859,7 +1859,7 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
>   break;
>   }
>  
> - if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
> + if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && 
> !IS_VALLEYVIEW(dev)) {
>   signal_levels = 
> intel_gen7_edp_signal_levels(intel_dp->train_set[0]);
>   DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_IVB) | 
> signal_levels;
>   } else if (IS_GEN6(dev) && is_cpu_edp(intel_dp)) {
> @@ -2471,7 +2471,10 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
> enum port port)
>   if (intel_dpd_is_edp(dev))
>   intel_dp->is_pch_edp = true;
>  
> - if (output_reg == DP_A || is_pch_edp(intel_dp)) {
> + if (IS_VALLEYVIEW(dev) && output_reg == DP_C) {
> + type = DRM_MODE_CONNECTOR_eDP;
> + intel_encoder->type = INTEL_OUTPUT_EDP;

You need to be a notch more careful, since since

commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson 
Date:   Fri Jul 16 14:46:29 2010 -0400

drm/i915: Initialize LVDS and eDP outputs before anything else

We initialize built-in panels before external outputs. Hence you need to
adjust intel_setup_outputs for vlv eDP, too, so that the eDP output comes
first. A bit a mess, I know.

Cheers, Daniel

> + } else if (output_reg == DP_A || is_pch_edp(intel_dp)) {
>   type = DRM_MODE_CONNECTOR_eDP;
>   intel_encoder->type = INTEL_OUTPUT_EDP;
>   } else {
> -- 
> 1.7.9.5
> 
> ___
> 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
_

Re: [Intel-gfx] [PATCH 7/9] drm/i915: panel power sequencing for VLV eDP

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 07:07:36PM +0530, Vijay Purushothaman wrote:
> PPS register offsets have changed in Valleyview.
> 
> Signed-off-by: Gajanan Bhat 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Ben Widawsky 

I have a feeling that we need to add some panel power sequencer
abstraction, especially if we want to support the 2nd panel power sequence
on vlv, too. I'm trying to volunteer some of the Helsinki guys here to
brush up Chris' panel refactoring (which combines lvds and edp panel
handling a bit), that would fit in. But for now this quick&dirty way looks
good enough.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_reg.h |9 +++
>  drivers/gpu/drm/i915/intel_dp.c |  122 
> +++
>  2 files changed, 93 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3f75ee6..e421847 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3981,6 +3981,15 @@
>  #define PIPEB_PP_ON_DELAYS  0x61308
>  #define PIPEB_PP_OFF_DELAYS 0x6130c
>  #define PIPEB_PP_DIVISOR0x61310
> +#define VLV_PIPE_PP_STATUS(pipe) _PIPE(pipe, PIPEA_PP_STATUS, 
> PIPEB_PP_STATUS)
> +#define VLV_PIPE_PP_CONTROL(pipe) _PIPE(pipe, PIPEA_PP_CONTROL, 
> PIPEB_PP_CONTROL)
> +#define VLV_PIPE_PP_ON_DELAYS(pipe) \
> + _PIPE(pipe, PIPEA_PP_ON_DELAYS, PIPEB_PP_ON_DELAYS)
> +#define VLV_PIPE_PP_OFF_DELAYS(pipe) \
> + _PIPE(pipe, PIPEA_PP_OFF_DELAYS, PIPEB_PP_OFF_DELAYS)
> +#define VLV_PIPE_PP_DIVISOR(pipe) \
> + _PIPE(pipe, PIPEA_PP_DIVISOR, PIPEB_PP_DIVISOR)
> +
>  
>  #define PCH_PP_STATUS0xc7200
>  #define PCH_PP_CONTROL   0xc7204
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index af57027..b944529 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -316,16 +316,20 @@ static bool ironlake_edp_have_panel_power(struct 
> intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pp_stat_reg;
>  
> - return (I915_READ(PCH_PP_STATUS) & PP_ON) != 0;
> + pp_stat_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_STATUS : PCH_PP_STATUS;
> + return (I915_READ(pp_stat_reg) & PP_ON) != 0;
>  }
>  
>  static bool ironlake_edp_have_panel_vdd(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pp_ctrl_reg;
>  
> - return (I915_READ(PCH_PP_CONTROL) & EDP_FORCE_VDD) != 0;
> + pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
> + return (I915_READ(pp_ctrl_reg) & EDP_FORCE_VDD) != 0;
>  }
>  
>  static void
> @@ -333,14 +337,19 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pp_stat_reg, pp_ctrl_reg;
>  
>   if (!is_edp(intel_dp))
>   return;
> +
> + pp_stat_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_STATUS : PCH_PP_STATUS;
> + pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
> +
>   if (!ironlake_edp_have_panel_power(intel_dp) && 
> !ironlake_edp_have_panel_vdd(intel_dp)) {
>   WARN(1, "eDP powered off while attempting aux channel 
> communication.\n");
>   DRM_DEBUG_KMS("Status 0x%08x Control 0x%08x\n",
> -   I915_READ(PCH_PP_STATUS),
> -   I915_READ(PCH_PP_CONTROL));
> + I915_READ(pp_stat_reg),
> + I915_READ(pp_ctrl_reg));
>   }
>  }
>  
> @@ -944,16 +953,20 @@ static void ironlake_wait_panel_status(struct intel_dp 
> *intel_dp,
>  {
>   struct drm_device *dev = intel_dp->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pp_stat_reg, pp_ctrl_reg;
> +
> + pp_stat_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_STATUS : PCH_PP_STATUS;
> + pp_ctrl_reg = IS_VALLEYVIEW(dev) ? PIPEA_PP_CONTROL : PCH_PP_CONTROL;
>  
>   DRM_DEBUG_KMS("mask %08x value %08x status %08x control %08x\n",
> -   mask, value,
> -   I915_READ(PCH_PP_STATUS),
> -   I915_READ(PCH_PP_CONTROL));
> + mask, value,
> + I915_READ(pp_stat_reg),
> + I915_READ(pp_ctrl_reg));
>  
> - if (_wait_for((I915_READ(PCH_PP_STATUS) & mask) == value, 5000, 10)) {
> + if (_wait_for((I915_READ(pp_stat_reg) & mask) == value, 5000, 10)) {
>   DRM_ERROR("Panel status timeout: status %08x control %08x\n",
> -   I915_READ(PCH_PP_STATUS),
> -   I915_READ(PCH_PP_CONTROL));
> + I915_READ(pp_stat_reg),
> + I915_READ(pp_ctrl_

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Reverse min, max vco limits for VLV HDMI

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 07:07:37PM +0530, Vijay Purushothaman wrote:
> Fixed min, max vco limits for VLV HDMI. Also fixed correct register
> offset for VLV_VIDEO_DIP_CTL_A
> 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Gajanan Bhat 
> Signed-off-by: Ben Widawsky 

Patch splitup bikeshed: Either split up the dip reg fix into its own
patch, or make the commit headline more generic (e.g "fixup HDMI output on
vlv") with the details of the fix ("fixup vco limits and dip ctl reg") in
the commit message. I'll bikeshed the headline when applying.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |2 +-
>  drivers/gpu/drm/i915/intel_display.c |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e421847..d4ed30e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3687,7 +3687,7 @@
>  #define TVIDEO_DIP_DATA(pipe) _PIPE(pipe, _VIDEO_DIP_DATA_A, 
> _VIDEO_DIP_DATA_B)
>  #define TVIDEO_DIP_GCP(pipe) _PIPE(pipe, _VIDEO_DIP_GCP_A, _VIDEO_DIP_GCP_B)
>  
> -#define VLV_VIDEO_DIP_CTL_A  0x60220
> +#define VLV_VIDEO_DIP_CTL_A  0x60200
>  #define VLV_VIDEO_DIP_DATA_A 0x60208
>  #define VLV_VIDEO_DIP_GDCP_PAYLOAD_A 0x60210
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index aee6151..647e311 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -380,7 +380,7 @@ static const intel_limit_t intel_limits_vlv_dac = {
>  
>  static const intel_limit_t intel_limits_vlv_hdmi = {
>   .dot = { .min = 2, .max = 165000 },
> - .vco = { .min = 5994000, .max = 400 },
> + .vco = { .min = 400, .max = 5994000},
>   .n = { .min = 1, .max = 7 },
>   .m = { .min = 60, .max = 300 }, /* guess */
>   .m1 = { .min = 2, .max = 3 },
> -- 
> 1.7.9.5
> 
> ___
> 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 9/9] drm/i915: Enable multi display support in VLV

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 07:07:38PM +0530, Vijay Purushothaman wrote:
> From: "Bhat, Gajanan" 
> 
> Clened up DPLL calculations for Valleyview. Moved DPLL register and DPIO
> programming to vlv_update_pll function. With all the changes multi
> display (clone, extended desktop) should work for VLV.
> 
> Signed-off-by: Gajanan Bhat 

I guess this patch will look much better once we don't disable the
vlv_update_pll function in between (and apply my other suggestion to move
i9xx_update_pll_divisors into the !vlv pll functions).
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |8 +--
>  drivers/gpu/drm/i915/intel_display.c |  105 
> ++
>  2 files changed, 58 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d4ed30e..71aa0a7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -385,12 +385,8 @@
>  
>  #define DPIO_FASTCLK_DISABLE 0x8100
>  
> -#define _DPIO_DATA_LANE0 0x0220
> -#define _DPIO_DATA_LANE1 0x0420
> -#define _DPIO_DATA_LANE2 0x2620
> -#define _DPIO_DATA_LANE3 0x2820
> -#define DPIO_DATA_LANE_A(pipe) _PIPE(pipe, _DPIO_DATA_LANE0, 
> _DPIO_DATA_LANE2)
> -#define DPIO_DATA_LANE_B(pipe) _PIPE(pipe, _DPIO_DATA_LANE1, 
> _DPIO_DATA_LANE3)
> +#define DPIO_DATA_CHANNEL1   0x8220
> +#define DPIO_DATA_CHANNEL2   0x8420
>  
>  /*
>   * Fence registers
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 647e311..e933031 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4018,10 +4018,10 @@ static void intel_update_lvds(struct drm_crtc *crtc, 
> intel_clock_t *clock,
>  }
>  
>  static void vlv_update_pll(struct drm_crtc *crtc,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode,
> -intel_clock_t *clock, intel_clock_t *reduced_clock,
> -int refclk, int num_connectors)
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode,
> + intel_clock_t *clock, intel_clock_t *reduced_clock,
> + int num_connectors)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -4029,9 +4029,19 @@ static void vlv_update_pll(struct drm_crtc *crtc,
>   int pipe = intel_crtc->pipe;
>   u32 dpll, mdiv, pdiv;
>   u32 bestn, bestm1, bestm2, bestp1, bestp2;
> - bool is_hdmi;
> + bool is_sdvo;
> + u32 temp;
>  
> - is_hdmi = intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
> + is_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
> +
> + dpll = DPLL_VGA_MODE_DIS;
> + dpll |= DPLL_EXT_BUFFER_ENABLE_VLV;
> + dpll |= DPLL_REFA_CLK_ENABLE_VLV;
> + dpll |= DPLL_INTEGRATED_CLOCK_VLV;
> +
> + I915_WRITE(DPLL(pipe), dpll);
> + POSTING_READ(DPLL(pipe));
>  
>   bestn = clock->n;
>   bestm1 = clock->m1;
> @@ -4039,12 +4049,10 @@ static void vlv_update_pll(struct drm_crtc *crtc,
>   bestp1 = clock->p1;
>   bestp2 = clock->p2;
>  
> - /* Enable DPIO clock input */
> - dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
> - DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
> - I915_WRITE(DPLL(pipe), dpll);
> - POSTING_READ(DPLL(pipe));
> -
> + /*
> +  * In Valleyview PLL and program lane counter registes are exposed
> +  * through DPIO interface
> +  */
>   mdiv = ((bestm1 << DPIO_M1DIV_SHIFT) | (bestm2 & DPIO_M2DIV_MASK));
>   mdiv |= ((bestp1 << DPIO_P1_SHIFT) | (bestp2 << DPIO_P2_SHIFT));
>   mdiv |= ((bestn << DPIO_N_SHIFT));
> @@ -4069,21 +4077,47 @@ static void vlv_update_pll(struct drm_crtc *crtc,
>   if (wait_for(((I915_READ(DPLL(pipe)) & DPLL_LOCK_VLV) == 
> DPLL_LOCK_VLV), 1))
>   DRM_ERROR("DPLL %d failed to lock\n", pipe);
>  
> - if (is_hdmi) {
> - u32 temp = intel_mode_get_pixel_multiplier(adjusted_mode);
> + intel_dpio_write(dev_priv, DPIO_FASTCLK_DISABLE, 0x620);
> +
> + if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
> + intel_dp_set_m_n(crtc, mode, adjusted_mode);
> +
> + I915_WRITE(DPLL(pipe), dpll);
> +
> + /* Wait for the clocks to stabilize. */
> + POSTING_READ(DPLL(pipe));
> + udelay(150);
>  
> + temp = 0;
> + if (is_sdvo) {
> + temp = intel_mode_get_pixel_multiplier(adjusted_mode);
>   if (temp > 1)
>   temp = (temp - 1) << DPLL_MD_UDI_MULTIPLIER_SHIFT;
>   else
>   temp = 0;
> -
> - I915_WRITE(DPLL_MD(pipe), temp);
> - POSTING_READ(DPLL_MD

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Add eDP support for Valleyview

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 04:31:46PM +0200, Daniel Vetter wrote:
> On Wed, Sep 26, 2012 at 07:07:35PM +0530, Vijay Purushothaman wrote:
> > Eventhough Valleyview display block is derived from Cantiga, VLV
> > supports eDP. So, added eDP checks in i9xx_crtc_mode_set path.
> > 
> > v2: use different DPIO_DIVISOR values for VGA, DP and eDP
> > v3: fix DPIO value calculation to use same values for all display
> > interfaces
> > 
> > Signed-off-by: Gajanan Bhat 
> > Signed-off-by: Vijay Purushothaman 
> > Signed-off-by: Ben Widawsky 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |6 ++
> >  drivers/gpu/drm/i915/intel_dp.c  |   13 -
> >  2 files changed, 14 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a8a81d1..aee6151 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4405,6 +4405,12 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
> > }
> > }
> >  
> > +   if (IS_VALLEYVIEW(dev) && intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
> > +   pipeconf |= PIPECONF_BPP_6 |
> > +   PIPECONF_ENABLE |
> > +   I965_PIPECONF_ACTIVE;
> > +   }
> 
> No.
> 
> Jani Nikula and me just figured out that we have a giant mess with 6bpc
> dithering on DP outputs, but unconditionally enabling 6bpc on vlv eDP only
> papers over issues.

Forgotten to put Jani on cc.
-Daniel

> 
> > +
> > DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe == 0 ? 'A' : 'B');
> > drm_mode_debug_printmodeline(mode);
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index c111c3f..af57027 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -885,7 +885,7 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
> > drm_display_mode *mode,
> >  
> > /* Split out the IBX/CPU vs CPT settings */
> >  
> > -   if (is_cpu_edp(intel_dp) && IS_GEN7(dev)) {
> > +   if (is_cpu_edp(intel_dp) && IS_GEN7(dev) && !IS_VALLEYVIEW(dev)) {
> > if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
> > intel_dp->DP |= DP_SYNC_HS_HIGH;
> > if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
> > @@ -1474,7 +1474,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
> > uint8_t voltage_swing)
> >  {
> > struct drm_device *dev = intel_dp->base.base.dev;
> >  
> > -   if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
> > +   if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && !IS_VALLEYVIEW(dev)) {
> > switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> > case DP_TRAIN_VOLTAGE_SWING_400:
> > return DP_TRAIN_PRE_EMPHASIS_6;
> > @@ -1773,7 +1773,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> > uint32_tsignal_levels;
> >  
> >  
> > -   if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
> > +   if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && 
> > !IS_VALLEYVIEW(dev)) {
> > signal_levels = 
> > intel_gen7_edp_signal_levels(intel_dp->train_set[0]);
> > DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_IVB) | 
> > signal_levels;
> > } else if (IS_GEN6(dev) && is_cpu_edp(intel_dp)) {
> > @@ -1859,7 +1859,7 @@ intel_dp_complete_link_train(struct intel_dp 
> > *intel_dp)
> > break;
> > }
> >  
> > -   if (IS_GEN7(dev) && is_cpu_edp(intel_dp)) {
> > +   if (IS_GEN7(dev) && is_cpu_edp(intel_dp) && 
> > !IS_VALLEYVIEW(dev)) {
> > signal_levels = 
> > intel_gen7_edp_signal_levels(intel_dp->train_set[0]);
> > DP = (DP & ~EDP_LINK_TRAIN_VOL_EMP_MASK_IVB) | 
> > signal_levels;
> > } else if (IS_GEN6(dev) && is_cpu_edp(intel_dp)) {
> > @@ -2471,7 +2471,10 @@ intel_dp_init(struct drm_device *dev, int 
> > output_reg, enum port port)
> > if (intel_dpd_is_edp(dev))
> > intel_dp->is_pch_edp = true;
> >  
> > -   if (output_reg == DP_A || is_pch_edp(intel_dp)) {
> > +   if (IS_VALLEYVIEW(dev) && output_reg == DP_C) {
> > +   type = DRM_MODE_CONNECTOR_eDP;
> > +   intel_encoder->type = INTEL_OUTPUT_EDP;
> 
> You need to be a notch more careful, since since
> 
> commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> Author: Adam Jackson 
> Date:   Fri Jul 16 14:46:29 2010 -0400
> 
> drm/i915: Initialize LVDS and eDP outputs before anything else
> 
> We initialize built-in panels before external outputs. Hence you need to
> adjust intel_setup_outputs for vlv eDP, too, so that the eDP output comes
> first. A bit a mess, I know.
> 
> Cheers, Daniel
> 
> > +   } else if (output_reg == DP_A || is_pch_edp(intel_dp)) {
> > type = DRM_MODE_CONNECTOR_eDP;
> > intel_encoder->type = INTEL_OUTPUT_EDP;
> > } else {
> > -- 
> > 1.7.9.5
> > 
> > __

[Intel-gfx] [PATCH] drm/i915: pass adjusted_mode instead of mode to intel_choose_pipe_bpp_dither

2012-09-26 Thread Jani Nikula
The dithering introduced in

commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
Author: Adam Jackson 
Date:   Tue Dec 13 15:41:00 2011 -0800

drm/i915/dp: Dither down to 6bpc if it makes the mode fit

stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
adjusted mode, while intel_choose_pipe_bpp_dither() determining the color
depth was passed the original mode, without the flag, so it would never
have any effect. However, the BPC was clamped by VBT settings, making
things work by coincidence, until that part was removed in

commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter 
Date:   Fri Aug 10 11:10:20 2012 +0200

Pass adjusted_mode instead of mode to intel_choose_pipe_bpp_dither() to
make INTEL_MODE_DP_FORCE_6BPC have effect.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
CC: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 08c3f69..0a9802a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4936,7 +4936,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
intel_crtc_update_cursor(crtc, true);
 
/* determine panel color depth */
-   dither = intel_choose_pipe_bpp_dither(crtc, fb, &intel_crtc->bpp, mode);
+   dither = intel_choose_pipe_bpp_dither(crtc, fb, &intel_crtc->bpp,
+ adjusted_mode);
if (is_lvds && dev_priv->lvds_dither)
dither = true;
 
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH] drm/i915: pass adjusted_mode instead of mode to intel_choose_pipe_bpp_dither

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 06:27:51PM +0300, Jani Nikula wrote:
> The dithering introduced in
> 
> commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
> Author: Adam Jackson 
> Date:   Tue Dec 13 15:41:00 2011 -0800
> 
> drm/i915/dp: Dither down to 6bpc if it makes the mode fit
> 
> stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
> adjusted mode, while intel_choose_pipe_bpp_dither() determining the color
> depth was passed the original mode, without the flag, so it would never
> have any effect. However, the BPC was clamped by VBT settings, making
> things work by coincidence, until that part was removed in
> 
> commit 4344b813f105a19f793f1fd93ad775b784648b95
> Author: Daniel Vetter 
> Date:   Fri Aug 10 11:10:20 2012 +0200
> 
> Pass adjusted_mode instead of mode to intel_choose_pipe_bpp_dither() to
> make INTEL_MODE_DP_FORCE_6BPC have effect.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
> CC: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula 

Awesome piece of debugging here. But can I point you to
i9xx_crtc_mode_set, where the same bug exists an ask for v2?

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 08c3f69..0a9802a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4936,7 +4936,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
>   intel_crtc_update_cursor(crtc, true);
>  
>   /* determine panel color depth */
> - dither = intel_choose_pipe_bpp_dither(crtc, fb, &intel_crtc->bpp, mode);
> + dither = intel_choose_pipe_bpp_dither(crtc, fb, &intel_crtc->bpp,
> +   adjusted_mode);
>   if (is_lvds && dev_priv->lvds_dither)
>   dither = true;
>  
> -- 
> 1.7.9.5
> 

-- 
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: use adjusted_mode instead of mode for checking the 6bpc force flag

2012-09-26 Thread Jani Nikula
The dithering introduced in

commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
Author: Adam Jackson 
Date:   Tue Dec 13 15:41:00 2011 -0800

drm/i915/dp: Dither down to 6bpc if it makes the mode fit

stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
the original mode, without the flag, so it would never have any
effect. However, the BPC was clamped by VBT settings, making things work by
coincidence, until that part was removed in

commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter 
Date:   Fri Aug 10 11:10:20 2012 +0200

Use adjusted_mode instead of mode when checking for
INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.

v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
Daniel both before and after sending the first patch.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621
CC: Adam Jackson 
CC: sta...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_display.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 08c3f69..16a0895 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4370,7 +4370,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
/* default to 8bpc */
pipeconf &= ~(PIPECONF_BPP_MASK | PIPECONF_DITHER_EN);
if (is_dp) {
-   if (mode->private_flags & INTEL_MODE_DP_FORCE_6BPC) {
+   if (adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC) {
pipeconf |= PIPECONF_BPP_6 |
PIPECONF_DITHER_EN |
PIPECONF_DITHER_TYPE_SP;
@@ -4936,7 +4936,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
intel_crtc_update_cursor(crtc, true);
 
/* determine panel color depth */
-   dither = intel_choose_pipe_bpp_dither(crtc, fb, &intel_crtc->bpp, mode);
+   dither = intel_choose_pipe_bpp_dither(crtc, fb, &intel_crtc->bpp,
+ adjusted_mode);
if (is_lvds && dev_priv->lvds_dither)
dither = true;
 
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH] drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag

2012-09-26 Thread Adam Jackson
On Wed, 2012-09-26 at 18:43 +0300, Jani Nikula wrote:
> The dithering introduced in
> 
> commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
> Author: Adam Jackson 
> Date:   Tue Dec 13 15:41:00 2011 -0800
> 
> drm/i915/dp: Dither down to 6bpc if it makes the mode fit
> 
> stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
> adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
> the original mode, without the flag, so it would never have any
> effect. However, the BPC was clamped by VBT settings, making things work by
> coincidence, until that part was removed in
> 
> commit 4344b813f105a19f793f1fd93ad775b784648b95
> Author: Daniel Vetter 
> Date:   Fri Aug 10 11:10:20 2012 +0200
> 
> Use adjusted_mode instead of mode when checking for
> INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.
> 
> v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
> Daniel both before and after sending the first patch.

Reviewed-by: Adam Jackson 

- ajax


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


[Intel-gfx] [PATCH] drm/i915: Try harder to complete DP training pattern 1

2012-09-26 Thread Chris Wilson
In commit cdb0e95bf571dccc1f75fef9bdad21b167ef0b37
Author: Keith Packard 
Date:   Tue Nov 1 20:00:06 2011 -0700

drm/i915: Try harder during dp pattern 1 link training

extra passes were made to retry the same voltage and then retry a full
clock reset. However, as coverity pointed out, we never tried the full
clock reset as we broke out of the loop early.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_dp.c |   15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a6ef745..46897f0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1827,8 +1827,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
if ((intel_dp->train_set[i] & 
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
if (i == intel_dp->lane_count && voltage_tries == 5) {
-   ++loop_tries;
-   if (loop_tries == 5) {
+   if (++loop_tries == 5) {
DRM_DEBUG_KMS("too many full retries, give 
up\n");
break;
}
@@ -1838,15 +1837,11 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
}
 
/* Check to see if we've tried the same voltage 5 times */
-   if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) == 
voltage) {
-   ++voltage_tries;
-   if (voltage_tries == 5) {
-   DRM_DEBUG_KMS("too many voltage retries, give 
up\n");
-   break;
-   }
-   } else
+   if ((intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) != 
voltage) {
+   voltage = intel_dp->train_set[0] & 
DP_TRAIN_VOLTAGE_SWING_MASK;
voltage_tries = 0;
-   voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
+   } else
+   ++voltage_tries;
 
/* Compute new intel_dp->train_set as requested by target */
intel_get_adjust_train(intel_dp, link_status);
-- 
1.7.10.4

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


[Intel-gfx] triple-buffering on Arrandale?

2012-09-26 Thread Charles G Waldman

 Hi.  I've got a Thinkpad X201 with Integrated Graphics Controller
(rev 02), Intel(R) Arrandale running Gentoo Linux.  The documentation
mentions   Option "TripleBuffer" "boolean"
but when I try to use this to control triple-buffering, the 
Xorg.0.log shows
  (WW) intel(0): Option "TripleBuffer" is not used

This posting -  https://bbs.archlinux.org/viewtopic.php?id=149323

shows an Xorg.log, also with Arrandale,  with

  (**) intel(0): Triple buffering? enabled

which leaves me wondering as to the actual status of 
triple-buffering with this driver and the differences
in log-file output.  I'm running x11-drivers/xf86-video-intel-2.20.8









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


[Intel-gfx] [PATCH] intel_infoframes: Dump HDMI vendor infoframes

2012-09-26 Thread Damien Lespiau
From: Damien Lespiau 

Those infoframes are programmed when using stereo 3D modes.

Signed-off-by: Damien Lespiau 
---
 tools/intel_infoframes.c |   63 +-
 1 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/tools/intel_infoframes.c b/tools/intel_infoframes.c
index d74df64..66351ac 100644
--- a/tools/intel_infoframes.c
+++ b/tools/intel_infoframes.c
@@ -125,6 +125,8 @@ typedef enum {
 #define SPD_INFOFRAME_VERSION 0x01
 #define SPD_INFOFRAME_LENGTH  0x19
 
+#define VENDOR_ID_HDMI 0x000c03
+
 typedef struct {
uint8_t type;
uint8_t version;
@@ -175,6 +177,21 @@ typedef union {
} __attribute__((packed)) spd;
struct {
DipInfoFrameHeader header;
+   uint8_t checksum;
+
+   uint8_t id[3];
+
+   uint8_t Rsvd0:5;
+   uint8_t video_format :3;
+
+   uint8_t Rsvd1 :4;
+   uint8_t s3d_structure :4;
+
+   uint8_t Rsvd2:4;
+   uint8_t s3d_ext_data :4;
+   } __attribute__((packed)) vendor;
+   struct {
+   DipInfoFrameHeader header;
uint8_t body[27];
} generic;
uint8_t data8[128];
@@ -424,10 +441,45 @@ static void dump_avi_info(Transcoder transcoder)
printf("Invalid InfoFrame checksum!\n");
 }
 
+static const char *vendor_id_to_string(uint32_t id)
+{
+   switch (id) {
+   case VENDOR_ID_HDMI:
+   return "HDMI";
+   default:
+   return "Unknown";
+   }
+}
+
+static const char *s3d_structure_to_string(int format)
+{
+   switch (format) {
+   case 0:
+   return "Frame Packing";
+   case 6:
+   return "Top Bottom";
+   case 8:
+   return "Side By Side (half)";
+   default:
+   return "Reserved";
+   }
+}
+
+static void dump_vendor_hdmi(DipInfoFrame *frame)
+{
+   int s3d_present = frame->vendor.video_format & 0x2;
+
+   printf("- video format: 0x%03x %s\n", frame->vendor.video_format,
+  s3d_present ? "(3D)" : "");
+   if (s3d_present)
+   printf("- 3D Format: %s\n",
+  s3d_structure_to_string(frame->vendor.s3d_structure));
+}
+
 static void dump_vendor_info(Transcoder transcoder)
 {
Register reg = get_dip_ctl_reg(transcoder);
-   uint32_t val;
+   uint32_t val, vendor_id;
DipFrequency freq;
DipInfoFrame frame;
 
@@ -446,6 +498,15 @@ static void dump_vendor_info(Transcoder transcoder)
 
dump_raw_infoframe(&frame);
 
+   vendor_id = frame.vendor.id[2] << 16 | frame.vendor.id[1] << 8 |
+   frame.vendor.id[0];
+
+   printf("- vendor Id: 0x%06x (%s)\n", vendor_id,
+  vendor_id_to_string(vendor_id));
+
+   if (vendor_id == VENDOR_ID_HDMI)
+   dump_vendor_hdmi(&frame);
+
if (!infoframe_valid_checksum(&frame))
printf("Invalid InfoFrame checksum!\n");
 }
-- 
1.7.7.5

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


[Intel-gfx] [PATCH 1/3] drm/i915: Extract PCU communication

2012-09-26 Thread Ben Widawsky
There is a special mechanism for communicating with the PCU already
being used for the ring frequency stuff. As we'll be needing this for
other commands, extract it now to make future code less error prone and
the current code more reusable.

I'm not entirely sure if this code matches 1:1 with the previous code
behaviorally. Functionally however, it should be the same.

CC: Jesse Barnes 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 13 ++---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_pm.c | 94 +++--
 3 files changed, 67 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a4b3f3..6647585 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1283,15 +1283,10 @@ static int i915_ring_freq_table(struct seq_file *m, 
void *unused)
for (gpu_freq = dev_priv->rps.min_delay;
 gpu_freq <= dev_priv->rps.max_delay;
 gpu_freq++) {
-   I915_WRITE(GEN6_PCODE_DATA, gpu_freq);
-   I915_WRITE(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY |
-  GEN6_PCODE_READ_MIN_FREQ_TABLE);
-   if (wait_for((I915_READ(GEN6_PCODE_MAILBOX) &
- GEN6_PCODE_READY) == 0, 10)) {
-   DRM_ERROR("pcode read of freq table timed out\n");
-   continue;
-   }
-   ia_freq = I915_READ(GEN6_PCODE_DATA);
+   ia_freq = gpu_freq;
+   sandybridge_pcode_read(dev_priv,
+  GEN6_PCODE_READ_MIN_FREQ_TABLE,
+  &ia_freq);
seq_printf(m, "%d\t\t%d\n", gpu_freq * GT_FREQUENCY_MULTIPLIER, 
ia_freq * 100);
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index af5ceb4..b75a7b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1622,6 +1622,9 @@ void gen6_gt_force_wake_get(struct drm_i915_private 
*dev_priv);
 void gen6_gt_force_wake_put(struct drm_i915_private *dev_priv);
 int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv);
 
+int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u8 mbox, u32 
*val);
+int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u8 mbox, u32 
val);
+
 #define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a3e4f8b..6488cd0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2503,30 +2503,16 @@ static void gen6_enable_rps(struct drm_device *dev)
   GEN6_RP_UP_BUSY_AVG |
   (IS_HASWELL(dev) ? GEN7_RP_DOWN_IDLE_AVG : 
GEN6_RP_DOWN_IDLE_CONT));
 
-   if (wait_for((I915_READ(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY) == 0,
-500))
-   DRM_ERROR("timeout waiting for pcode mailbox to become idle\n");
-
-   I915_WRITE(GEN6_PCODE_DATA, 0);
-   I915_WRITE(GEN6_PCODE_MAILBOX,
-  GEN6_PCODE_READY |
-  GEN6_PCODE_WRITE_MIN_FREQ_TABLE);
-   if (wait_for((I915_READ(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY) == 0,
-500))
-   DRM_ERROR("timeout waiting for pcode mailbox to finish\n");
-
-   /* Check for overclock support */
-   if (wait_for((I915_READ(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY) == 0,
-500))
-   DRM_ERROR("timeout waiting for pcode mailbox to become idle\n");
-   I915_WRITE(GEN6_PCODE_MAILBOX, GEN6_READ_OC_PARAMS);
-   pcu_mbox = I915_READ(GEN6_PCODE_DATA);
-   if (wait_for((I915_READ(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY) == 0,
-500))
-   DRM_ERROR("timeout waiting for pcode mailbox to finish\n");
-   if (pcu_mbox & (1<<31)) { /* OC supported */
-   dev_priv->rps.max_delay = pcu_mbox & 0xff;
-   DRM_DEBUG_DRIVER("overclocking supported, adjusting frequency 
max to %dMHz\n", pcu_mbox * 50);
+   ret = sandybridge_pcode_write(dev_priv, 
GEN6_PCODE_WRITE_MIN_FREQ_TABLE, 0);
+   if (!ret) {
+   pcu_mbox = 0;
+   ret = sandybridge_pcode_read(dev_priv, GEN6_READ_OC_PARAMS, 
&pcu_mbox);
+   if (ret && pcu_mbox & (1<<31)) { /* OC supported */
+   dev_priv->rps.max_delay = pcu_mbox & 0xff;
+   DRM_DEBUG_DRIVER("overclocking supported, adjusting 
frequency max to %dMHz\n", pcu_mbox * 50);
+   }
+   } else {
+   DRM_DEBUG_DRIVER("Failed to set the min frequency\n");
}
 
gen6_set_rps(dev_priv->dev, (gt_perf_status & 0xff00) >> 8);
@@ -2581,17 +2567,11 @@ static void gen6_update_ring_freq(struct drm_device 
*dev)
else

[Intel-gfx] [PATCH 2/3] drm/i915: Workaround to bump rc6 voltage to 450

2012-09-26 Thread Ben Widawsky
BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or
buggy BIOSen may not be doing this, so we correct it for them. Ideally
customers should update the BIOS as only it would know the optimal
values for the platform, so we leave that fact as a DRM_ERROR for the
user to see.

Unfortunately this isn't fixing any of the issues it was targeted to
fix, but it is documented that we must do it.

CC: Jesse Barnes 
CC: Matt Turner 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h |  4 
 drivers/gpu/drm/i915/intel_pm.c | 18 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a828e90..13aafa5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4213,6 +4213,10 @@
 #define   GEN6_READ_OC_PARAMS  0xc
 #define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
 #define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
+#define  GEN6_PCODE_WRITE_RC6VIDS  0x4
+#define  GEN6_PCODE_READ_RC6VIDS   0x5
+#define   GEN6_ENCODE_RC6_VID(mv)  (((mv) / 5) - 245) < 0 ?: 0
+#define   GEN6_DECODE_RC6_VID(vids)(((vids) * 5) > 0 ? ((vids) * 
5) + 245 : 0)
 #define GEN6_PCODE_DATA0x138128
 #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT   8
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6488cd0..9a6edf0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2404,10 +2404,10 @@ static void gen6_enable_rps(struct drm_device *dev)
struct intel_ring_buffer *ring;
u32 rp_state_cap;
u32 gt_perf_status;
-   u32 pcu_mbox, rc6_mask = 0;
+   u32 rc6vids, pcu_mbox, rc6_mask = 0;
u32 gtfifodbg;
int rc6_mode;
-   int i;
+   int i, ret;
 
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
 
@@ -2526,6 +2526,20 @@ static void gen6_enable_rps(struct drm_device *dev)
/* enable all PM interrupts */
I915_WRITE(GEN6_PMINTRMSK, 0);
 
+   rc6vids = 0;
+   ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, 
&rc6vids);
+   if (IS_GEN6(dev) && ret) {
+   DRM_DEBUG_DRIVER("Couldn't check for BIOS workaround\n");
+   } else if (IS_GEN6(dev) && (GEN6_DECODE_RC6_VID(rc6vids & 0xff) < 450)) 
{
+   DRM_ERROR("You should update your BIOS. Correcting minimum rc6 
voltage (%dmV->%dmV)\n",
+ GEN6_DECODE_RC6_VID(rc6vids & 0xff), 450);
+   rc6vids &= 0x00;
+   rc6vids |= GEN6_ENCODE_RC6_VID(450);
+   ret = sandybridge_pcode_write(dev_priv, 
GEN6_PCODE_WRITE_RC6VIDS, rc6vids);
+   if (ret)
+   DRM_ERROR("Couldn't fix incorrect rc6 voltage\n");
+   }
+
gen6_gt_force_wake_put(dev_priv);
 }
 
-- 
1.7.12.1

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


[Intel-gfx] [PATCH 3/3] drm/i915: Add rc6vids to debugfs

2012-09-26 Thread Ben Widawsky
CC: Jesse Barnes 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6647585..3c5710f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1069,7 +1069,7 @@ static int gen6_drpc_info(struct seq_file *m)
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 rpmodectl1, gt_core_status, rcctl1;
+   u32 rpmodectl1, gt_core_status, rcctl1, rc6vids = 0;
unsigned forcewake_count;
int count=0, ret;
 
@@ -1097,6 +1097,7 @@ static int gen6_drpc_info(struct seq_file *m)
 
rpmodectl1 = I915_READ(GEN6_RP_CONTROL);
rcctl1 = I915_READ(GEN6_RC_CONTROL);
+   sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, &rc6vids);
mutex_unlock(&dev->struct_mutex);
 
seq_printf(m, "Video Turbo Mode: %s\n",
@@ -1149,6 +1150,12 @@ static int gen6_drpc_info(struct seq_file *m)
seq_printf(m, "RC6++ residency since boot: %u\n",
   I915_READ(GEN6_GT_GFX_RC6pp));
 
+   seq_printf(m, "RC6   voltage: %dmV\n",
+  GEN6_DECODE_RC6_VID(((rc6vids >> 0) & 0xff)));
+   seq_printf(m, "RC6+  voltage: %dmV\n",
+  GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
+   seq_printf(m, "RC6++ voltage: %dmV\n",
+  GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
return 0;
 }
 
-- 
1.7.12.1

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Workaround to bump rc6 voltage to 450

2012-09-26 Thread Matt Turner
On Wed, Sep 26, 2012 at 10:34 AM, Ben Widawsky  wrote:
> BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or
> buggy BIOSen may not be doing this, so we correct it for them. Ideally
> customers should update the BIOS as only it would know the optimal
> values for the platform, so we leave that fact as a DRM_ERROR for the
> user to see.
>
> Unfortunately this isn't fixing any of the issues it was targeted to
> fix, but it is documented that we must do it.
>
> CC: Jesse Barnes 
> CC: Matt Turner 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  4 
>  drivers/gpu/drm/i915/intel_pm.c | 18 --
>  2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a828e90..13aafa5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4213,6 +4213,10 @@
>  #define   GEN6_READ_OC_PARAMS  0xc
>  #define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE  0x8
>  #define   GEN6_PCODE_READ_MIN_FREQ_TABLE   0x9
> +#define  GEN6_PCODE_WRITE_RC6VIDS  0x4
> +#define  GEN6_PCODE_READ_RC6VIDS   0x5
> +#define   GEN6_ENCODE_RC6_VID(mv)  (((mv) / 5) - 245) < 0 ?: 0
> +#define   GEN6_DECODE_RC6_VID(vids)(((vids) * 5) > 0 ? ((vids) * 
> 5) + 245 : 0)
>  #define GEN6_PCODE_DATA0x138128
>  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT   8
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6488cd0..9a6edf0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2404,10 +2404,10 @@ static void gen6_enable_rps(struct drm_device *dev)
> struct intel_ring_buffer *ring;
> u32 rp_state_cap;
> u32 gt_perf_status;
> -   u32 pcu_mbox, rc6_mask = 0;
> +   u32 rc6vids, pcu_mbox, rc6_mask = 0;
> u32 gtfifodbg;
> int rc6_mode;
> -   int i;
> +   int i, ret;
>
> WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>
> @@ -2526,6 +2526,20 @@ static void gen6_enable_rps(struct drm_device *dev)
> /* enable all PM interrupts */
> I915_WRITE(GEN6_PMINTRMSK, 0);
>
> +   rc6vids = 0;
> +   ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, 
> &rc6vids);
> +   if (IS_GEN6(dev) && ret) {
> +   DRM_DEBUG_DRIVER("Couldn't check for BIOS workaround\n");
> +   } else if (IS_GEN6(dev) && (GEN6_DECODE_RC6_VID(rc6vids & 0xff) < 
> 450)) {
> +   DRM_ERROR("You should update your BIOS. Correcting minimum 
> rc6 voltage (%dmV->%dmV)\n",
> + GEN6_DECODE_RC6_VID(rc6vids & 0xff), 450);
> +   rc6vids &= 0x00;
> +   rc6vids |= GEN6_ENCODE_RC6_VID(450);
> +   ret = sandybridge_pcode_write(dev_priv, 
> GEN6_PCODE_WRITE_RC6VIDS, rc6vids);
> +   if (ret)
> +   DRM_ERROR("Couldn't fix incorrect rc6 voltage\n");
> +   }
> +
> gen6_gt_force_wake_put(dev_priv);
>  }
>
> --
> 1.7.12.1
>

Tested-by: Matt Turner 

(feel free to apply that to the whole series)

Too bad it's not this bug that affects my system. :(
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC] [PATCH] quick_dump: A dump utility different than reg_dumper

2012-09-26 Thread Ben Widawsky
On Wed, 26 Sep 2012 13:51:01 +0200
Daniel Vetter  wrote:

> On Sat, Sep 22, 2012 at 01:58:37PM -0700, Ben Widawsky wrote:
> > On 2012-09-22 11:05, Daniel Vetter wrote:
> > >And a quick comment on your approach here: I'm not too sure
> > >whether the
> > >file-base register block approach scales, respectively why exactly
> > >this is
> > >better than frobbing the reg_dumper tool. Since that one has the
> > >concept
> > >of register blocks already, too.
> > 
> > It doesn't scale. It scales better than reg_dumper was my goal and
> > point (IMO).
> > 
> > The exact problem that was trying to be solved is Valleyview (and I
> > assure you there will be more such products coming). Valleyview took
> > a huge chunk of well known registers, and changed their offsets.
> > Modifying this in reg dumper is of course possible, but it's
> > tedious. I wanted to have easy to modify text files with an easy
> > python front end (the offsets could even be applied in the script
> > extremely easily).
> 
> If the issue is just the base-address moving around, I think we could
> solve that with some refactoring ...
> -Daniel

That's exactly an example of the problem it's trying to solve. When
working on new platforms (which is happening much more frequently then
it used to), we shouldn't have to refactor an existing tool to make it
do what we want in preparation for power-on, or even worse, during
power-on. I want something quick, and dirty that gets the information I
need, and migrate it over time to intel_reg_dumper. Furthermore, doing
the range dump can be trivially added with your scripting language of
choice.

Almost as important, it takes away from the maintenance burden on a
useful tool like reg_dumper for one off platforms like the stupid vlv
we are currently working with (ie. things which will never ship).

I'm not sure at this point if you're genuinely opposed, or just looking
for holes to poke. Maybe you can clarify, because frankly, I'm using
this tool for my own needs, and whether or not I push it is fairly
don't care.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] intel_infoframes: Dump HDMI vendor infoframes

2012-09-26 Thread Rodrigo Vivi
Reviewed-by: Rodrigo Vivi 

On Wed, Sep 26, 2012 at 2:17 PM, Damien Lespiau
 wrote:
> From: Damien Lespiau 
>
> Those infoframes are programmed when using stereo 3D modes.
>
> Signed-off-by: Damien Lespiau 
> ---
>  tools/intel_infoframes.c |   63 
> +-
>  1 files changed, 62 insertions(+), 1 deletions(-)
>
> diff --git a/tools/intel_infoframes.c b/tools/intel_infoframes.c
> index d74df64..66351ac 100644
> --- a/tools/intel_infoframes.c
> +++ b/tools/intel_infoframes.c
> @@ -125,6 +125,8 @@ typedef enum {
>  #define SPD_INFOFRAME_VERSION 0x01
>  #define SPD_INFOFRAME_LENGTH  0x19
>
> +#define VENDOR_ID_HDMI 0x000c03
> +
>  typedef struct {
> uint8_t type;
> uint8_t version;
> @@ -175,6 +177,21 @@ typedef union {
> } __attribute__((packed)) spd;
> struct {
> DipInfoFrameHeader header;
> +   uint8_t checksum;
> +
> +   uint8_t id[3];
> +
> +   uint8_t Rsvd0:5;
> +   uint8_t video_format :3;
> +
> +   uint8_t Rsvd1 :4;
> +   uint8_t s3d_structure :4;
> +
> +   uint8_t Rsvd2:4;
> +   uint8_t s3d_ext_data :4;
> +   } __attribute__((packed)) vendor;
> +   struct {
> +   DipInfoFrameHeader header;
> uint8_t body[27];
> } generic;
> uint8_t data8[128];
> @@ -424,10 +441,45 @@ static void dump_avi_info(Transcoder transcoder)
> printf("Invalid InfoFrame checksum!\n");
>  }
>
> +static const char *vendor_id_to_string(uint32_t id)
> +{
> +   switch (id) {
> +   case VENDOR_ID_HDMI:
> +   return "HDMI";
> +   default:
> +   return "Unknown";
> +   }
> +}
> +
> +static const char *s3d_structure_to_string(int format)
> +{
> +   switch (format) {
> +   case 0:
> +   return "Frame Packing";
> +   case 6:
> +   return "Top Bottom";
> +   case 8:
> +   return "Side By Side (half)";
> +   default:
> +   return "Reserved";
> +   }
> +}
> +
> +static void dump_vendor_hdmi(DipInfoFrame *frame)
> +{
> +   int s3d_present = frame->vendor.video_format & 0x2;
> +
> +   printf("- video format: 0x%03x %s\n", frame->vendor.video_format,
> +  s3d_present ? "(3D)" : "");
> +   if (s3d_present)
> +   printf("- 3D Format: %s\n",
> +  s3d_structure_to_string(frame->vendor.s3d_structure));
> +}
> +
>  static void dump_vendor_info(Transcoder transcoder)
>  {
> Register reg = get_dip_ctl_reg(transcoder);
> -   uint32_t val;
> +   uint32_t val, vendor_id;
> DipFrequency freq;
> DipInfoFrame frame;
>
> @@ -446,6 +498,15 @@ static void dump_vendor_info(Transcoder transcoder)
>
> dump_raw_infoframe(&frame);
>
> +   vendor_id = frame.vendor.id[2] << 16 | frame.vendor.id[1] << 8 |
> +   frame.vendor.id[0];
> +
> +   printf("- vendor Id: 0x%06x (%s)\n", vendor_id,
> +  vendor_id_to_string(vendor_id));
> +
> +   if (vendor_id == VENDOR_ID_HDMI)
> +   dump_vendor_hdmi(&frame);
> +
> if (!infoframe_valid_checksum(&frame))
> printf("Invalid InfoFrame checksum!\n");
>  }
> --
> 1.7.7.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Fix set_caching locking

2012-09-26 Thread Ben Widawsky
On the EINVAL case we don't release struct_mutex. It should be safe to
grab the lock after checking the parameters, which also resolves the
issues.

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_gem.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 365a7dc..76bbb37 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3218,10 +3218,6 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
enum i915_cache_level level;
int ret;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
switch (args->caching) {
case I915_CACHING_NONE:
level = I915_CACHE_NONE;
@@ -3233,6 +3229,10 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
return -EINVAL;
}
 
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   return ret;
+
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
if (&obj->base == NULL) {
ret = -ENOENT;
-- 
1.7.12.1

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


Re: [Intel-gfx] Question regarding libva encoding

2012-09-26 Thread Xiang, Haihao

The support for Main/High profile has been done in the staging branch.
We will merge the interfaces for Main/High profile back into the master
branch.

Thanks
Haihao


> Hello my name is Charlie Good and I am the CTO of Wowza Media System.
> We are the authors of Wowza Media Server. Our product includes a
> transcoder for transcoding incoming streams to adaptive bitrate stream
> sets. We are only using the AVC/H.264 encoder at this time. We are
> looking to use libva for accelerated encoding on Linux leveraging the
> Quick Sync technology. We are already doing this on Windows using the
> Intel Media SDK. I have an implementation that is currently working
> when using the baseline profile. I would also like to support main and
> high profile. It looks like these profiles are not yet implemented. I
> can see this in gen6_mfc.c in the pipeline code where it looks like
> only baseline encoding is supported:
> 
>  
> 
> VAStatus
> 
> gen6_mfc_pipeline(VADriverContextP ctx,
> 
>   VAProfile profile,
> 
>   struct encode_state *encode_state,
> 
>   struct gen6_encoder_context *gen6_encoder_context)
> 
> {
> 
> VAStatus vaStatus;
> 
>  
> 
> switch (profile) {
> 
> case VAProfileH264Baseline:
> 
> vaStatus = gen6_mfc_avc_encode_picture(ctx, encode_state,
> gen6_encoder_context);
> 
> break;
> 
>  
> 
> /* FIXME: add for other profile */
> 
> default:
> 
> vaStatus = VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
> 
> break;
> 
> }
> 
>  
> 
> return vaStatus;
> 
> }
> 
>  
> 
> Is there a plan to add support for main and high encoding in a future
> release? Do you have any estimate of when this might be added?
> 
>  
> 
> BTW, I am a huge fan of Intel Quick Sync. Very cool technology.
> Amazing performance and quality.
> 
>  
> 
> Charlie
> 
> 
> ___
> 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] assertion on intel_disable_transcoder

2012-09-26 Thread Wang, Xingchao
Hi Ben,

I have no idea about the resolution, maybe Paulo and Daniel know more details?

Thanks
--xingchao

From: ben.gut...@gmail.com [mailto:ben.gut...@gmail.com] On Behalf Of Ben Guthro
Sent: Wednesday, September 26, 2012 4:43 AM
To: Wang, Xingchao
Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R; Fu, Michael; Wu, Fengguang
Subject: Re: [Intel-gfx] assertion on intel_disable_transcoder

I am seeing this same trace (and no video) on multiple Haswell SDP's, with 
3.6-rc7 (and earlier kernels)

Was there ever a resolution on this?



On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao 
mailto:xingchao.w...@intel.com>> wrote:
Hi,

Some update related to this warning.
Ironlake_crtc_dpms() will enable/disable crtc which pipe was enabled/disabled 
there.
Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and crtc 
was disabled, that causes intel_wait_for_vblank() timeout and some assertions.

I think it's a bug but I have no clue where/when to enable crtc again.

Here's part of dmesg before the warning and the message showing dpms off.

[   19.332220] [drm:intel_lvds_init], LVDS is not present in VBT
[   19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4
[   19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B
[   19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
[   19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
[   19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
[   19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
[   19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off
[   19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
[   19.351826] [ cut here ]
[   19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118 
assert_fdi_tx+0x87/0x90 [i915]()
[   19.351849] Hardware name: Shark Bay Client platform
[   19.351850] FDI TX state assertion failure (expected off, current on)
[   19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek 
snd_hda_codec_hdmi drm_kms_helper
 drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel 
snd_seq_midi snd_rawmidi snd_s
eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830 psmouse 
snd_seq_device usbnet
 snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc lpc_ich 
microcode mac_hid video
 lp parport e1000e usbhid hid
[   19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+ #29
[   19.351870] Call Trace:
[   19.351876]  [] warn_slowpath_common+0x7f/0xc0

thanks
--xingchao


> -Original Message-
> From: Wang, Xingchao
> Sent: Tuesday, August 07, 2012 3:26 PM
> To: Daniel Vetter; Zanoni, Paulo R
> Cc: intel-gfx@lists.freedesktop.org; 
> Fu, Michael; Wu, Fengguang; 'Zhenyu
> Wang (zhen...@linux.intel.com)'; Zhao, Yakui
> Subject: assertion on intel_disable_transcoder
>
> Hi Daniel/Paulo,
>
> It's easy to see such WARNING in dmesg, the DDI port is not disabled prior to
> disable transcoder.
> I am not sure it will impact the Pipe/transcoder/DDI-port configurations,
> anyway after some times WARNING, I could not make HDMI audio work
> anymore.
> With intel_audio_dump I could see the related configurations was totally
> disabled.
>
> DDI_BUF_CTL_A 0x0080  DDI Buffer Controler A
> DDI_BUF_CTL_B 0x  DDI Buffer Controler B
> DDI_BUF_CTL_C 0x0080  DDI Buffer Controler C
> DDI_BUF_CTL_D 0x  DDI Buffer Controler D
> DDI_BUF_CTL_E 0x8002  DDI Buffer Controler E
> PIPE_CONF_A   0x  PIPE Configuration A
> PIPE_CONF_B   0x  PIPE Configuration B
> PIPE_CONF_C   0x  PIPE Configuration C
> PIPE_CONF_EDP 0x  PIPE Configuration EDP
> PIPE_DDI_FUNC_CTL_A   0xc4034002  PIPE DDI Function Control A
> PIPE_DDI_FUNC_CTL_B   0xa0035000  PIPE DDI Function Control B
> PIPE_DDI_FUNC_CTL_C   0x0003  PIPE DDI Function Control C
> PIPE_DDI_FUNC_CTL_EDP 0x0003  PIPE DDI Function Control EDP
> TRANS_CONF0x  Transcoder Configuration
>
> Thanks
> --xingchao
>
> [   16.835658] [ cut here ]
> [   16.835690] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
> assert_fdi_tx+0x87/0x90 [i915]()
> [   16.835691] Hardware name: Shark Bay Client platform
> [   16.835692] FDI TX state assertion failure (expected off, current on)
> [   16.835706] Modules linked in: snd_seq_midi_event i915(+) snd_seq
> snd_timer drm_kms_helper snd_seq
> _device ghash_clmulni_intel drm aesni_intel snd cryptd mcs7830 usbnet joydev
> aes_x86_64 soundcore psm ouse snd_page_alloc hid_generic i2c_algo_bit
> serio_raw video mac_hid microcode lpc_ich lp parport e10 00e usbhid hid
> [   16.835708] Pid: 470, comm: modprobe Not tainted 3.5.0-rc46patches+ #12
> [   16.835709] Call Trace:
> [   16.835715]  [] warn_slowpath_common+0x7f/0xc0
> [   16.835718]  [] warn_slowpath_fmt+0x46/0x50
> 

Re: [Intel-gfx] assertion on intel_disable_transcoder

2012-09-26 Thread Daniel Vetter
On Thu, Sep 27, 2012 at 06:32:06AM +, Wang, Xingchao wrote:
> Hi Ben,
> 
> I have no idea about the resolution, maybe Paulo and Daniel know more details?

Oh, it's just an older assert for pre-hsw that we haven't properly
disabled yet. Since this code will change quite a bit with Paulo's new
way of handling ddi/fdi on haswell, we somehow never bothered with the
real fix. Should be quite as soon as Paulo's patchbomb lands.
-Daniel

> 
> Thanks
> --xingchao
> 
> From: ben.gut...@gmail.com [mailto:ben.gut...@gmail.com] On Behalf Of Ben 
> Guthro
> Sent: Wednesday, September 26, 2012 4:43 AM
> To: Wang, Xingchao
> Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R; Fu, Michael; Wu, 
> Fengguang
> Subject: Re: [Intel-gfx] assertion on intel_disable_transcoder
> 
> I am seeing this same trace (and no video) on multiple Haswell SDP's, with 
> 3.6-rc7 (and earlier kernels)
> 
> Was there ever a resolution on this?
> 
> 
> 
> On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao 
> mailto:xingchao.w...@intel.com>> wrote:
> Hi,
> 
> Some update related to this warning.
> Ironlake_crtc_dpms() will enable/disable crtc which pipe was enabled/disabled 
> there.
> Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and crtc 
> was disabled, that causes intel_wait_for_vblank() timeout and some assertions.
> 
> I think it's a bug but I have no clue where/when to enable crtc again.
> 
> Here's part of dmesg before the warning and the message showing dpms off.
> 
> [   19.332220] [drm:intel_lvds_init], LVDS is not present in VBT
> [   19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4
> [   19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B
> [   19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
> [   19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> [   19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
> [   19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
> [   19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off
> [   19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
> [   19.351826] [ cut here ]
> [   19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118 
> assert_fdi_tx+0x87/0x90 [i915]()
> [   19.351849] Hardware name: Shark Bay Client platform
> [   19.351850] FDI TX state assertion failure (expected off, current on)
> [   19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek 
> snd_hda_codec_hdmi drm_kms_helper
>  drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel 
> snd_seq_midi snd_rawmidi snd_s
> eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830 
> psmouse snd_seq_device usbnet
>  snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc lpc_ich 
> microcode mac_hid video
>  lp parport e1000e usbhid hid
> [   19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+ #29
> [   19.351870] Call Trace:
> [   19.351876]  [] warn_slowpath_common+0x7f/0xc0
> 
> thanks
> --xingchao
> 
> 
> > -Original Message-
> > From: Wang, Xingchao
> > Sent: Tuesday, August 07, 2012 3:26 PM
> > To: Daniel Vetter; Zanoni, Paulo R
> > Cc: 
> > intel-gfx@lists.freedesktop.org; 
> > Fu, Michael; Wu, Fengguang; 'Zhenyu
> > Wang (zhen...@linux.intel.com)'; Zhao, Yakui
> > Subject: assertion on intel_disable_transcoder
> >
> > Hi Daniel/Paulo,
> >
> > It's easy to see such WARNING in dmesg, the DDI port is not disabled prior 
> > to
> > disable transcoder.
> > I am not sure it will impact the Pipe/transcoder/DDI-port configurations,
> > anyway after some times WARNING, I could not make HDMI audio work
> > anymore.
> > With intel_audio_dump I could see the related configurations was totally
> > disabled.
> >
> > DDI_BUF_CTL_A 0x0080  DDI Buffer Controler A
> > DDI_BUF_CTL_B 0x  DDI Buffer Controler B
> > DDI_BUF_CTL_C 0x0080  DDI Buffer Controler C
> > DDI_BUF_CTL_D 0x  DDI Buffer Controler D
> > DDI_BUF_CTL_E 0x8002  DDI Buffer Controler E
> > PIPE_CONF_A   0x  PIPE Configuration A
> > PIPE_CONF_B   0x  PIPE Configuration B
> > PIPE_CONF_C   0x  PIPE Configuration C
> > PIPE_CONF_EDP 0x  PIPE Configuration EDP
> > PIPE_DDI_FUNC_CTL_A   0xc4034002  PIPE DDI Function Control A
> > PIPE_DDI_FUNC_CTL_B   0xa0035000  PIPE DDI Function Control B
> > PIPE_DDI_FUNC_CTL_C   0x0003  PIPE DDI Function Control C
> > PIPE_DDI_FUNC_CTL_EDP 0x0003  PIPE DDI Function Control EDP
> > TRANS_CONF0x  Transcoder Configuration
> >
> > Thanks
> > --xingchao
> >
> > [   16.835658] [ cut here ]
> > [   16.835690] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
> > assert_fdi_tx+0x87/0x90 [i915]()
> > [   16.835691] Hardware name: Shark Bay Client platform
> > [   16.835692] FDI TX state assertion 

Re: [Intel-gfx] [PATCH] drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 11:50:36AM -0400, Adam Jackson wrote:
> On Wed, 2012-09-26 at 18:43 +0300, Jani Nikula wrote:
> > The dithering introduced in
> > 
> > commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
> > Author: Adam Jackson 
> > Date:   Tue Dec 13 15:41:00 2011 -0800
> > 
> > drm/i915/dp: Dither down to 6bpc if it makes the mode fit
> > 
> > stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
> > adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
> > the original mode, without the flag, so it would never have any
> > effect. However, the BPC was clamped by VBT settings, making things work by
> > coincidence, until that part was removed in
> > 
> > commit 4344b813f105a19f793f1fd93ad775b784648b95
> > Author: Daniel Vetter 
> > Date:   Fri Aug 10 11:10:20 2012 +0200
> > 
> > Use adjusted_mode instead of mode when checking for
> > INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.
> > 
> > v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
> > Daniel both before and after sending the first patch.
> 
> Reviewed-by: Adam Jackson 
Picked up for -fixes, thanks for the patch.
-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] intel_infoframes: Dump HDMI vendor infoframes

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 08:01:09PM -0300, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi 
> 
> On Wed, Sep 26, 2012 at 2:17 PM, Damien Lespiau
>  wrote:
> > From: Damien Lespiau 
> >
> > Those infoframes are programmed when using stereo 3D modes.
> >
> > Signed-off-by: Damien Lespiau 
Applied, thanks for the patch.
-Daniel

> > ---
> >  tools/intel_infoframes.c |   63 
> > +-
> >  1 files changed, 62 insertions(+), 1 deletions(-)
> >
> > diff --git a/tools/intel_infoframes.c b/tools/intel_infoframes.c
> > index d74df64..66351ac 100644
> > --- a/tools/intel_infoframes.c
> > +++ b/tools/intel_infoframes.c
> > @@ -125,6 +125,8 @@ typedef enum {
> >  #define SPD_INFOFRAME_VERSION 0x01
> >  #define SPD_INFOFRAME_LENGTH  0x19
> >
> > +#define VENDOR_ID_HDMI 0x000c03
> > +
> >  typedef struct {
> > uint8_t type;
> > uint8_t version;
> > @@ -175,6 +177,21 @@ typedef union {
> > } __attribute__((packed)) spd;
> > struct {
> > DipInfoFrameHeader header;
> > +   uint8_t checksum;
> > +
> > +   uint8_t id[3];
> > +
> > +   uint8_t Rsvd0:5;
> > +   uint8_t video_format :3;
> > +
> > +   uint8_t Rsvd1 :4;
> > +   uint8_t s3d_structure :4;
> > +
> > +   uint8_t Rsvd2:4;
> > +   uint8_t s3d_ext_data :4;
> > +   } __attribute__((packed)) vendor;
> > +   struct {
> > +   DipInfoFrameHeader header;
> > uint8_t body[27];
> > } generic;
> > uint8_t data8[128];
> > @@ -424,10 +441,45 @@ static void dump_avi_info(Transcoder transcoder)
> > printf("Invalid InfoFrame checksum!\n");
> >  }
> >
> > +static const char *vendor_id_to_string(uint32_t id)
> > +{
> > +   switch (id) {
> > +   case VENDOR_ID_HDMI:
> > +   return "HDMI";
> > +   default:
> > +   return "Unknown";
> > +   }
> > +}
> > +
> > +static const char *s3d_structure_to_string(int format)
> > +{
> > +   switch (format) {
> > +   case 0:
> > +   return "Frame Packing";
> > +   case 6:
> > +   return "Top Bottom";
> > +   case 8:
> > +   return "Side By Side (half)";
> > +   default:
> > +   return "Reserved";
> > +   }
> > +}
> > +
> > +static void dump_vendor_hdmi(DipInfoFrame *frame)
> > +{
> > +   int s3d_present = frame->vendor.video_format & 0x2;
> > +
> > +   printf("- video format: 0x%03x %s\n", frame->vendor.video_format,
> > +  s3d_present ? "(3D)" : "");
> > +   if (s3d_present)
> > +   printf("- 3D Format: %s\n",
> > +  
> > s3d_structure_to_string(frame->vendor.s3d_structure));
> > +}
> > +
> >  static void dump_vendor_info(Transcoder transcoder)
> >  {
> > Register reg = get_dip_ctl_reg(transcoder);
> > -   uint32_t val;
> > +   uint32_t val, vendor_id;
> > DipFrequency freq;
> > DipInfoFrame frame;
> >
> > @@ -446,6 +498,15 @@ static void dump_vendor_info(Transcoder transcoder)
> >
> > dump_raw_infoframe(&frame);
> >
> > +   vendor_id = frame.vendor.id[2] << 16 | frame.vendor.id[1] << 8 |
> > +   frame.vendor.id[0];
> > +
> > +   printf("- vendor Id: 0x%06x (%s)\n", vendor_id,
> > +  vendor_id_to_string(vendor_id));
> > +
> > +   if (vendor_id == VENDOR_ID_HDMI)
> > +   dump_vendor_hdmi(&frame);
> > +
> > if (!infoframe_valid_checksum(&frame))
> > printf("Invalid InfoFrame checksum!\n");
> >  }
> > --
> > 1.7.7.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: Fix set_caching locking

2012-09-26 Thread Daniel Vetter
On Wed, Sep 26, 2012 at 04:15:20PM -0700, Ben Widawsky wrote:
> On the EINVAL case we don't release struct_mutex. It should be safe to
> grab the lock after checking the parameters, which also resolves the
> issues.
> 
> Signed-off-by: Ben Widawsky 

Nice catch, thanks for the patch, applied to fixes.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 365a7dc..76bbb37 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3218,10 +3218,6 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
> void *data,
>   enum i915_cache_level level;
>   int ret;
>  
> - ret = i915_mutex_lock_interruptible(dev);
> - if (ret)
> - return ret;
> -
>   switch (args->caching) {
>   case I915_CACHING_NONE:
>   level = I915_CACHE_NONE;
> @@ -3233,6 +3229,10 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
> void *data,
>   return -EINVAL;
>   }
>  
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + return ret;
> +
>   obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
>   if (&obj->base == NULL) {
>   ret = -ENOENT;
> -- 
> 1.7.12.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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