date:20120927

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

2012-09-27 Thread Jani Nikula

On Wed, 26 Sep 2012, Daniel Vetter  wrote:
> On Wed, Sep 26, 2012 at 07:07:35PM +0530, Vijay Purushothaman wrote:
>> 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.

Vijay, please check commit 0c96c65b in drm-intel-fixes.

BR,
Jani.

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

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

2012-09-27 Thread Jani Nikula

On Wed, 26 Sep 2012, 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, 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(-)

Looks good, and I also like the diffstat.

Reviewed-by: Jani Nikula 

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

[Intel-gfx] [PATCH] drm/i915: Detect invalid pages for SandyBridge

2012-09-27 Thread Chris Wilson

As SandyBridge returns garbage when decoding certain addresses through
the GTT (all memory below 1MiB and a very small number of individual
pages) we need to prevent the GPU from utilizing those pages. The
ultimate goal would be to prevent our allocator from handing us those
pages, but that is a longer term project. In the short term, we can
detect when we attempt to bind those pages to the GPU and return an
error to the application rather than hang the GPU and potentially the
system.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c |   40 ---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d9d3fc7..5c7ccfd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -306,17 +306,51 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
intel_gtt_chipset_flush();
 }
 
+static bool
+gen6_valid_addresses(struct drm_i915_gem_object *obj)
+{
+   struct scatterlist *sg;
+   int i;
+
+   for_each_sg(obj->pages->sgl, sg, obj->pages->nents, i) {
+   dma_addr_t addr = sg_dma_address(sg);
+   if (WARN(addr < 0x10 ||
+addr == 0x2005 ||
+addr == 0x2011 ||
+addr == 0x2013 ||
+addr == 0x20138000 ||
+addr == 0x40004000,
+"object references unaddressable physical pages: 
addr=%x",
+(u32)addr))
+   return false;
+   }
+
+   return true;
+}
+
 int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
 {
-   if (obj->has_dma_mapping)
-   return 0;
+   int ret;
 
-   if (!dma_map_sg(&obj->base.dev->pdev->dev,
+   if (!obj->has_dma_mapping &&
+   !dma_map_sg(&obj->base.dev->pdev->dev,
obj->pages->sgl, obj->pages->nents,
PCI_DMA_BIDIRECTIONAL))
return -ENOSPC;
 
+   if (IS_GEN6(obj->base.dev) && !gen6_valid_addresses(obj)) {
+   ret = -EFAULT;
+   goto unmap;
+   }
+
return 0;
+
+unmap:
+   if (!obj->has_dma_mapping)
+   dma_unmap_sg(&obj->base.dev->pdev->dev,
+obj->pages->sgl, obj->pages->nents,
+PCI_DMA_BIDIRECTIONAL);
+   return ret;
 }
 
 void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
-- 
1.7.10.4

___
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-27 Thread Charlie Good

This is great news. I will watch for the udpate.

Charlie

-Original Message-
From: Xiang, Haihao [mailto:haihao.xi...@intel.com] 
Sent: Wednesday, September 26, 2012 9:17 PM
To: Charlie Good
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Question regarding libva encoding


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-27 Thread Ben Guthro

FWIW, I am able to get graphics on the screen now - Apparently only the
hdmi port works on HSW right now - which I was unaware of.
This stack was a red-herring to that problem.

Thanks for the response.

Ben

On Thu, Sep 27, 2012 at 2:34 AM, Daniel Vetter  wrote:

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

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

2012-09-27 Thread Daniel Vetter

On Thu, Sep 27, 2012 at 10:39:53AM +0300, Jani Nikula wrote:
> On Wed, 26 Sep 2012, 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, 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(-)
> 
> Looks good, and I also like the diffstat.
> 
> Reviewed-by: Jani Nikula 

Picked up for -fixes, thanks for the patch.
-Daniel
> 
> >
> > 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)
> > struc

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

2012-09-27 Thread Daniel Vetter

On Wed, Sep 26, 2012 at 11:40:26AM -0700, Ben Widawsky wrote:
> 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.

Not genuinely opposed, but questioning the usefulness of such a script as
a tool to be used for end-users (which most of the i-g-t/tools programs
are for). If you want I think it'd make sense to move it to scripts as a
noinst_PYTHON thing (we have a few of those already). I'll merge such a
patch.

Cheers, 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: Detect invalid pages for SandyBridge

2012-09-27 Thread Daniel Vetter

On Thu, Sep 27, 2012 at 09:27:57AM +0100, Chris Wilson wrote:
> As SandyBridge returns garbage when decoding certain addresses through
> the GTT (all memory below 1MiB and a very small number of individual
> pages) we need to prevent the GPU from utilizing those pages. The
> ultimate goal would be to prevent our allocator from handing us those
> pages, but that is a longer term project. In the short term, we can
> detect when we attempt to bind those pages to the GPU and return an
> error to the application rather than hang the GPU and potentially the
> system.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c |   40 
> ---
>  1 file changed, 37 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index d9d3fc7..5c7ccfd 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -306,17 +306,51 @@ void i915_gem_restore_gtt_mappings(struct drm_device 
> *dev)
>   intel_gtt_chipset_flush();
>  }
>  
> +static bool
> +gen6_valid_addresses(struct drm_i915_gem_object *obj)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(obj->pages->sgl, sg, obj->pages->nents, i) {
> + dma_addr_t addr = sg_dma_address(sg);
> + if (WARN(addr < 0x10 ||
> +  addr == 0x2005 ||
> +  addr == 0x2011 ||
> +  addr == 0x2013 ||
> +  addr == 0x20138000 ||
> +  addr == 0x40004000,
> +  "object references unaddressable physical pages: 
> addr=%x",
> +  (u32)addr))
> + return false;

Iirc the bug is about the physical address, no the remapped one after
dmar. We'd need to check the windows code for that though ...
-Daniel

> + }
> +
> + return true;
> +}
> +
>  int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
>  {
> - if (obj->has_dma_mapping)
> - return 0;
> + int ret;
>  
> - if (!dma_map_sg(&obj->base.dev->pdev->dev,
> + if (!obj->has_dma_mapping &&
> + !dma_map_sg(&obj->base.dev->pdev->dev,
>   obj->pages->sgl, obj->pages->nents,
>   PCI_DMA_BIDIRECTIONAL))
>   return -ENOSPC;
>  
> + if (IS_GEN6(obj->base.dev) && !gen6_valid_addresses(obj)) {
> + ret = -EFAULT;
> + goto unmap;
> + }
> +
>   return 0;
> +
> +unmap:
> + if (!obj->has_dma_mapping)
> + dma_unmap_sg(&obj->base.dev->pdev->dev,
> +  obj->pages->sgl, obj->pages->nents,
> +  PCI_DMA_BIDIRECTIONAL);
> + return ret;
>  }
>  
>  void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
> -- 
> 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] drm/i915: Detect invalid pages for SandyBridge

2012-09-27 Thread Daniel Vetter

On Thu, Sep 27, 2012 at 02:14:22PM +0200, Daniel Vetter wrote:
> On Thu, Sep 27, 2012 at 09:27:57AM +0100, Chris Wilson wrote:
> > As SandyBridge returns garbage when decoding certain addresses through
> > the GTT (all memory below 1MiB and a very small number of individual
> > pages) we need to prevent the GPU from utilizing those pages. The
> > ultimate goal would be to prevent our allocator from handing us those
> > pages, but that is a longer term project. In the short term, we can
> > detect when we attempt to bind those pages to the GPU and return an
> > error to the application rather than hang the GPU and potentially the
> > system.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c |   40 
> > ---
> >  1 file changed, 37 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index d9d3fc7..5c7ccfd 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -306,17 +306,51 @@ void i915_gem_restore_gtt_mappings(struct drm_device 
> > *dev)
> > intel_gtt_chipset_flush();
> >  }
> >  
> > +static bool
> > +gen6_valid_addresses(struct drm_i915_gem_object *obj)
> > +{
> > +   struct scatterlist *sg;
> > +   int i;
> > +
> > +   for_each_sg(obj->pages->sgl, sg, obj->pages->nents, i) {
> > +   dma_addr_t addr = sg_dma_address(sg);
> > +   if (WARN(addr < 0x10 ||
> > +addr == 0x2005 ||
> > +addr == 0x2011 ||
> > +addr == 0x2013 ||
> > +addr == 0x20138000 ||
> > +addr == 0x40004000,
> > +"object references unaddressable physical pages: 
> > addr=%x",
> > +(u32)addr))
> > +   return false;
> 
> Iirc the bug is about the physical address, no the remapped one after
> dmar. We'd need to check the windows code for that though ...

Also maybe don't fail, but only smash some dirt into dmesg - otherwise
we'll score a neat regression report and probably angry users.
-Daniel

> 
> > +   }
> > +
> > +   return true;
> > +}
> > +
> >  int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
> >  {
> > -   if (obj->has_dma_mapping)
> > -   return 0;
> > +   int ret;
> >  
> > -   if (!dma_map_sg(&obj->base.dev->pdev->dev,
> > +   if (!obj->has_dma_mapping &&
> > +   !dma_map_sg(&obj->base.dev->pdev->dev,
> > obj->pages->sgl, obj->pages->nents,
> > PCI_DMA_BIDIRECTIONAL))
> > return -ENOSPC;
> >  
> > +   if (IS_GEN6(obj->base.dev) && !gen6_valid_addresses(obj)) {
> > +   ret = -EFAULT;
> > +   goto unmap;
> > +   }
> > +
> > return 0;
> > +
> > +unmap:
> > +   if (!obj->has_dma_mapping)
> > +   dma_unmap_sg(&obj->base.dev->pdev->dev,
> > +obj->pages->sgl, obj->pages->nents,
> > +PCI_DMA_BIDIRECTIONAL);
> > +   return ret;
> >  }
> >  
> >  void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
> > -- 
> > 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

-- 
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: Detect invalid pages for SandyBridge

2012-09-27 Thread Chris Wilson

On Thu, 27 Sep 2012 14:16:11 +0200, Daniel Vetter  wrote:
> On Thu, Sep 27, 2012 at 02:14:22PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 27, 2012 at 09:27:57AM +0100, Chris Wilson wrote:
> > > As SandyBridge returns garbage when decoding certain addresses through
> > > the GTT (all memory below 1MiB and a very small number of individual
> > > pages) we need to prevent the GPU from utilizing those pages. The
> > > ultimate goal would be to prevent our allocator from handing us those
> > > pages, but that is a longer term project. In the short term, we can
> > > detect when we attempt to bind those pages to the GPU and return an
> > > error to the application rather than hang the GPU and potentially the
> > > system.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem_gtt.c |   40 
> > > ---
> > >  1 file changed, 37 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > index d9d3fc7..5c7ccfd 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > @@ -306,17 +306,51 @@ void i915_gem_restore_gtt_mappings(struct 
> > > drm_device *dev)
> > >   intel_gtt_chipset_flush();
> > >  }
> > >  
> > > +static bool
> > > +gen6_valid_addresses(struct drm_i915_gem_object *obj)
> > > +{
> > > + struct scatterlist *sg;
> > > + int i;
> > > +
> > > + for_each_sg(obj->pages->sgl, sg, obj->pages->nents, i) {
> > > + dma_addr_t addr = sg_dma_address(sg);
> > > + if (WARN(addr < 0x10 ||
> > > +  addr == 0x2005 ||
> > > +  addr == 0x2011 ||
> > > +  addr == 0x2013 ||
> > > +  addr == 0x20138000 ||
> > > +  addr == 0x40004000,
> > > +  "object references unaddressable physical pages: 
> > > addr=%x",
> > > +  (u32)addr))
> > > + return false;
> > 
> > Iirc the bug is about the physical address, no the remapped one after
> > dmar. We'd need to check the windows code for that though ...

Hmm, we pass the remapped addresses to the GTT so I presumed that would
be what the decoder threw up over.

> Also maybe don't fail, but only smash some dirt into dmesg - otherwise
> we'll score a neat regression report and probably angry users.

I wouldn't consider that it was a regression, we go from either render
corruption, GPU hang or full system hang to absent rendering and lots of
noise.

I'd much rather take the latter. All in all though, I really want to see
if this is ever an issue and when.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending operations to the CRTC prior to modeset

2012-09-27 Thread Ville Syrjälä

On Thu, Sep 20, 2012 at 11:17:51AM +0200, Daniel Vetter wrote:
> On Thu, Sep 20, 2012 at 10:56 AM, Chris Wilson  
> wrote:
> > We need to wait for pending operations on the CRTC to retire before we
> > can modify the CRTC. For example, if userspace has queued a batch that
> > uses a WAIT_FOR_EVENT associated with the current FB, we can not modify
> > the pipe with that outstanding, as we may then prevent that
> > WAIT_FOR_EVENT from ever completing and so hanging the GPU. (Imagine a
> > scanline wait waiting for line 1024 and the pipe being adjusted to
> > 600-line mode.) There is also the sequencing issue of the immediate
> > update versus a pending pageflip.
> >
> > In both cases the function to serialise the modeset with the pending
> > operations existed but was simply not being called, or called after the
> > damage was already done.
> >
> > Signed-off-by: Chris Wilson 
> 
> I've looked at this situation again and we do have a
> wait_for_pending_flips already in per-platform crtc_disable functions,
> which are called for for switching off crtcs and also only just
> disabling them for a modeset.
> 
> So I think this finish_fb call in set_base is totally unnecessary and
> can be just removed. Moving it to the crtc_set_config function doesn't
> help (and this patch misses the case where we disable other crtcs than
> set->crtc).

This whole wait for pending flips mechanism looks iffy to me.

First, when we schedule a flip, we record the fact that there is a
pending flip into the old bo's pending_flip atomic mask thingy. When we
later want to wait for the CRTC operations to finish, we do
'intel_finish_fb(crtc->fb)'. But notice that 'crtc->fb' is now the fb we
flipped _to_, so it can't actually tell us whether there's still a flip
pending.

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

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

2012-09-27 Thread Vijay Purushothaman


On 9/26/2012 7:54 PM, Daniel Vetter wrote:

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.


Sure. I will move this hunk as a separate 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
)


Done.


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

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

2012-09-27 Thread Vijay Purushothaman


On 9/26/2012 8:08 PM, Daniel Vetter wrote:

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



I will change the commit headline. Thanks.


---
  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 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-27 Thread Vijay Purushothaman


On 9/26/2012 8:10 PM, Daniel Vetter wrote:

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


I've merged patch 5 and 9 and took care of your suggestions.

Thanks,
Vijay




---
  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);
-   POST

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

2012-09-27 Thread Vijay Purushothaman


On 9/26/2012 8:19 PM, Daniel Vetter wrote:

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


Thanks for the catch. I've removed this unconditional enabling of 6bpc 
for VLV eDP. For long term i believe, eDP handling in i9xx_crtc_mode_set 
should be changed along the lines of ironlake_crtc_mode_set for cleaner 
code. For now, this should unblock others with VLV enabling.







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


I've changed the detection order in intel_setup_outputs for valleyview. 
In intel_dp_init, I have added a comment to fix this in next patch series.


Thanks,
Vija

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

2012-09-27 Thread Vijay Purushothaman


On 9/27/2012 12:48 PM, Jani Nikula wrote:

On Wed, 26 Sep 2012, Daniel Vetter  wrote:

On Wed, Sep 26, 2012 at 07:07:35PM +0530, Vijay Purushothaman wrote:

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.


Vijay, please check commit 0c96c65b in drm-intel-fixes.

BR,
Jani.

Thanks Jani & Daniel for your review. I will send out the v2 of the 
patch set.


Thanks,
Vijay






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

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

2012-09-27 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.

v2: Addressed review comments from Daniel and Jani Nikula.

Gajanan Bhat (1):
  drm/i915: Add eDP support for Valleyview

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: Disable CRT hotplug detection for valleyview
  drm/i915: Enable DisplayPort in Valleyview
  drm/i915: panel power sequencing for VLV eDP
  drm/i915: Fixup HDMI output on Valleyview

 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 |  113 +
 drivers/gpu/drm/i915/intel_dp.c  |  152 --
 5 files changed, 211 insertions(+), 82 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 v2 1/9] drm/i915: Set aux clk to 100MHz for Valleyview

2012-09-27 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 v2 2/9] drm/i915: Fix SDVO IER and status bits for Valleyview

2012-09-27 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 v2 4/9] drm/i915: Program correct m n tu register for Valleyview

2012-09-27 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 v2 3/9] drm/i915: Add Valleyview lane control definitions

2012-09-27 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 v2 6/9] drm/i915: Enable DisplayPort in Valleyview

2012-09-27 Thread Vijay Purushothaman

In valleyview voltageswing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric.

Cleaned up DPLL calculations for Valleyview to support multi display
configurations.

v2: Based on Daniel's feedbacak, moved crt hotplug detect work around as 
separate
patch. Also moved i9xx_update_pll_dividers to i8xx_update_pll and
i9xx_update_pll.

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

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3f75ee6..0fe4aad 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 68828e7..ed749c4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4017,7 +4017,7 @@ 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)
+  int num_connectors)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -4025,9 +4025,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_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
+   intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
 
-   is_hdmi = 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;
@@ -4035,12 +4045,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 registers 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));
@@ -4051,12 +4059,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);
@@ -4064,21 +4073,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);

[Intel-gfx] [PATCH v2 5/9] drm/i915: Disable CRT hotplug detection for valleyview

2012-09-27 Thread Vijay Purushothaman

Temporary work around to avoid spurious crt hotplug interrupts.

Signed-off-by: Vijay Purushothaman 
Signed-off-by: Gajanan Bhat 
---
 drivers/gpu/drm/i915/intel_crt.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index c42b980..5f30364 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 crashses 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);
 
-- 
1.7.9.5

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

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

2012-09-27 Thread Vijay Purushothaman

From: Gajanan Bhat 

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
v4: removed unconditional enabling of 6bpc dithering based on comments
from Daniel & Jani Nikula. Also changed the display enabling order to
force eDP detection first.

Signed-off-by: Gajanan Bhat 
Signed-off-by: Vijay Purushothaman 
---
 drivers/gpu/drm/i915/intel_display.c |   15 ---
 drivers/gpu/drm/i915/intel_dp.c  |   17 -
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ed749c4..0362c80 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4413,6 +4413,14 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
}
}
 
+   if (IS_VALLEYVIEW(dev) && intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
+   if (adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC) {
+   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);
 
@@ -7623,6 +7631,10 @@ static void intel_setup_outputs(struct drm_device *dev)
} else if (IS_VALLEYVIEW(dev)) {
int found;
 
+   /* Check for built-in panel first. Shares lanes with HDMI on 
SDVOC */
+   if (I915_READ(DP_C) & DP_DETECTED)
+   intel_dp_init(dev, DP_C, PORT_C);
+
if (I915_READ(SDVOB) & PORT_DETECTED) {
/* SDVOB multiplex with HDMIB */
found = intel_sdvo_init(dev, SDVOB, true);
@@ -7635,9 +7647,6 @@ static void intel_setup_outputs(struct drm_device *dev)
if (I915_READ(SDVOC) & PORT_DETECTED)
intel_hdmi_init(dev, SDVOC, PORT_C);
 
-   /* Shares lanes with HDMI on SDVOC */
-   if (I915_READ(DP_C) & DP_DETECTED)
-   intel_dp_init(dev, DP_C, PORT_C);
} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
bool found = false;
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c111c3f..867c568 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,14 @@ 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)) {
+   /*
+* FIXME : We need to initialize built-in panels before external panels.
+* For X0, DP_C is fixed as e

[Intel-gfx] [PATCH v2 9/9] drm/i915: Fixup HDMI output on Valleyview

2012-09-27 Thread Vijay Purushothaman

Fixed correct min, max vco limits and dip ctl reg

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 0e6258a..71aa0a7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3683,7 +3683,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 0362c80..64c94ca 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 v2 8/9] drm/i915: panel power sequencing for VLV eDP

2012-09-27 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 0fe4aad..0e6258a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3977,6 +3977,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 867c568..c58535b 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;
+

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

2012-09-27 Thread Daniel Vetter

On Thu, Sep 27, 2012 at 07:08:41PM +0530, Vijay Purushothaman wrote:
> On 9/26/2012 8:19 PM, Daniel Vetter wrote:
> >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
> 
> Thanks for the catch. I've removed this unconditional enabling of
> 6bpc for VLV eDP. For long term i believe, eDP handling in
> i9xx_crtc_mode_set should be changed along the lines of
> ironlake_crtc_mode_set for cleaner code. For now, this should
> unblock others with VLV enabling.

My Big Plan (tm) for handling bpc, bandwidth, dotclocks and clocks in
general (e.g. pll sharing) is to move all this stuff out of the ->mode_set
callbacks and into a new preparation step at the beginning of the modeset
sequence (i.e. before we start touching the hw). Essentially I want to
extend the current ->mode_adjust callbacks and move all these calculations
in there. Aims for this are
- should allow us to move a lot of the encoder specific code that
  currently sits in the xxx_crtc_mode_set functions into encoder callbacks
- allows us to fail a modeset that won't work (e.g. due to pll sharing
  limits or fdi link bw limits) _before_ we touch the hw
- prepares for the global modeset stuff, where we want to make clever
  decision about shared resources (e.g. enable 6bpc dithering if there are
  not enough fdi lanes availbale in 3 pipe configs).

So the ironlake bpc code is a bit cleaner, but imho still gets it wrong.

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

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

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:01 +0530
Vijay Purushothaman  wrote:

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

Acked-by: Jesse Barnes 

Hopefully I'll get a chance to test later today.  I'm tracking down a
regression in the gmbus based edid probing in the -next based tree I'm
using...

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

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

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:02 +0530
Vijay Purushothaman  wrote:

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

Reviewed-by: Jesse Barnes 

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

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

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:03 +0530
Vijay Purushothaman  wrote:

> 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_SHIFT21 /* 3 bits, always 0x7 */
>  #define   DPIO_PLL_REFCLK_SEL_SHIFT  16 /* 2 bits */
> +#define   DPIO_PLL_REFCLK_SEL_MASK   3
>  #define   DPIO_DRIVER_CTL_SHIFT  12 /* always set to 0x8 */
>  #define   DPIO_CLK_BIAS_CTL_SHIFT8 /* 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
>   */

The lane regs don't match what I have in one of my docs (it has 120,
220, 2320, 2420), but I think it's for CDV, so I'll take your word
for it.

Reviewed-by: Jesse Barnes 

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

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

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:04 +0530
Vijay Purushothaman  wrote:

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

Acked-by: Jesse Barnes 

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

Re: [Intel-gfx] [PATCH v2 5/9] drm/i915: Disable CRT hotplug detection for valleyview

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:05 +0530
Vijay Purushothaman  wrote:

> Temporary work around to avoid spurious crt hotplug interrupts.
> 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Gajanan Bhat 
> ---
>  drivers/gpu/drm/i915/intel_crt.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index c42b980..5f30364 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 crashses 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);
>  

Not sure about this one; your platform seems to be less stable than
mine when it comes to both VGA port handling and legacy VGA I/O...  But
I have no problem with it either, I just know it works ok on at least
some of the SDVs, probably depending on board rework and firmware
status.

Acked-by: Jesse Barnes 

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

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Enable DisplayPort in Valleyview

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:06 +0530
Vijay Purushothaman  wrote:

> In valleyview voltageswing, pre-emphasis and lane control registers can
> be programmed only through the h/w side band fabric.
> 
> Cleaned up DPLL calculations for Valleyview to support multi display
> configurations.
> 
> v2: Based on Daniel's feedbacak, moved crt hotplug detect work around as 
> separate
> patch. Also moved i9xx_update_pll_dividers to i8xx_update_pll and
> i9xx_update_pll.
> 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Gajanan Bhat 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |8 +--
>  drivers/gpu/drm/i915/intel_display.c |   90 
> --
>  2 files changed, 66 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3f75ee6..0fe4aad 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 68828e7..ed749c4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4017,7 +4017,7 @@ 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)
> +int num_connectors)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -4025,9 +4025,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_sdvo = intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI);
>  
> - is_hdmi = 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;
> @@ -4035,12 +4045,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 registers 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));
> @@ -4051,12 +4059,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);
> @@ -4064,21 +4073,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_d

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

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:07 +0530
Vijay Purushothaman  wrote:

> From: Gajanan Bhat 
> 
> 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
> v4: removed unconditional enabling of 6bpc dithering based on comments
> from Daniel & Jani Nikula. Also changed the display enabling order to
> force eDP detection first.
> 
> Signed-off-by: Gajanan Bhat 
> Signed-off-by: Vijay Purushothaman 
> ---
>  drivers/gpu/drm/i915/intel_display.c |   15 ---
>  drivers/gpu/drm/i915/intel_dp.c  |   17 -
>  2 files changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ed749c4..0362c80 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4413,6 +4413,14 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>   }
>   }
>  
> + if (IS_VALLEYVIEW(dev) && intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)) {
> + if (adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC) {
> + 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);
>  
> @@ -7623,6 +7631,10 @@ static void intel_setup_outputs(struct drm_device *dev)
>   } else if (IS_VALLEYVIEW(dev)) {
>   int found;
>  
> + /* Check for built-in panel first. Shares lanes with HDMI on 
> SDVOC */
> + if (I915_READ(DP_C) & DP_DETECTED)
> + intel_dp_init(dev, DP_C, PORT_C);
> +
>   if (I915_READ(SDVOB) & PORT_DETECTED) {
>   /* SDVOB multiplex with HDMIB */
>   found = intel_sdvo_init(dev, SDVOB, true);
> @@ -7635,9 +7647,6 @@ static void intel_setup_outputs(struct drm_device *dev)
>   if (I915_READ(SDVOC) & PORT_DETECTED)
>   intel_hdmi_init(dev, SDVOC, PORT_C);
>  
> - /* Shares lanes with HDMI on SDVOC */
> - if (I915_READ(DP_C) & DP_DETECTED)
> - intel_dp_init(dev, DP_C, PORT_C);
>   } else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
>   bool found = false;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c111c3f..867c568 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,14 @@ 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;
>  
>

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Fixup HDMI output on Valleyview

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:09 +0530
Vijay Purushothaman  wrote:

> Fixed correct min, max vco limits and dip ctl reg
> 
> 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 0e6258a..71aa0a7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3683,7 +3683,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 0362c80..64c94ca 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 },

Reviewed-by: Jesse Barnes 

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

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

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:08 +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 
> ---
>  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 0fe4aad..0e6258a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3977,6 +3977,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 867c568..c58535b 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 = i

Re: [Intel-gfx] [PATCH v2 5/9] drm/i915: Disable CRT hotplug detection for valleyview

2012-09-27 Thread Jesse Barnes

On Thu, 27 Sep 2012 19:13:05 +0530
Vijay Purushothaman  wrote:

> Temporary work around to avoid spurious crt hotplug interrupts.
> 
> Signed-off-by: Vijay Purushothaman 
> Signed-off-by: Gajanan Bhat 
> ---
>  drivers/gpu/drm/i915/intel_crt.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index c42b980..5f30364 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 crashses 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);
>  

Oh and since this is a vlv specific function, the IS_VLV check is
unnecessary.

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

Re: [Intel-gfx] [PATCH] drm/i915: Valleyview doesn't have rc6+ or rc6++

2012-09-27 Thread Ben Widawsky

On Wed, 26 Sep 2012 14:06:36 +0200
Daniel Vetter  wrote:

> 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

I've not found such information. Can you tell me where you see that?

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

Re: [Intel-gfx] [PATCH] drm/i915: Valleyview doesn't have rc6+ or rc6++

2012-09-27 Thread Daniel Vetter

On Thu, Sep 27, 2012 at 5:34 PM, Ben Widawsky  wrote:
> On Wed, 26 Sep 2012 14:06:36 +0200
> Daniel Vetter  wrote:
>
>> 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
>
> I've not found such information. Can you tell me where you see that?

Haswell doesn't have the additional rc6 levels either, but on a quick
look through the code we still expose them, like on vlv.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

2012-09-27 Thread Daniel Vetter

On Thu, Sep 27, 2012 at 08:26:15AM -0700, Jesse Barnes wrote:
> On Thu, 27 Sep 2012 19:13:08 +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 
> > ---
> >  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 0fe4aad..0e6258a 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3977,6 +3977,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 867c568..c58535b 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 ironl

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

2012-09-27 Thread Jesse Barnes

On Wed, 26 Sep 2012 10:34:00 -0700
Ben Widawsky  wrote:

> 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");
>   }
>  
>   gen

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

2012-09-27 Thread Jesse Barnes

On Wed, 26 Sep 2012 10:34:01 -0700
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_PARAMS0xc
>  #define   GEN6_PCODE_WRITE_MIN_FREQ_TABLE0x8
>  #define   GEN6_PCODE_READ_MIN_FREQ_TABLE 0x9
> +#defineGEN6_PCODE_WRITE_RC6VIDS  0x4
> +#defineGEN6_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_DATA  0x138128
>  #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);
>  }
>  

Reviewed-by: Jesse Barnes 

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

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

2012-09-27 Thread Jesse Barnes

On Wed, 26 Sep 2012 10:34:02 -0700
Ben Widawsky  wrote:

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

Nice.

Reviewed-by: Jesse Barnes 

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

[Intel-gfx] Stereo 3D modes support v2

2012-09-27 Thread Damien Lespiau

This series is the second revison of:
  http://lists.freedesktop.org/archives/intel-gfx/2012-September/020457.html

It changes the way 3d modes are exposed to user-space:

- An "expose 3D modes" property can be installed on connectors that support
  stereo 3D
- User space can indicate through that property if it wants to receive the
  list of modes with the supported 3D layouts information
- In that case, the EDID parsing code adds the list of supported 3D layouts
  in mode->flags
- When setting a 3D mode, user space can select which layout it wants by
  clearing the list of supported layouts and setting the one it has selected
  (still through mode->flags).

The rationale behind all that is:

- Setting the 3d mode should atomic and not 1/ set the mode, 2/ then set
  the 3d layout through a connector property.
- To do that, mode->flags can be used, but current user space would not
  do the correct thing with those extra added flags, hence the need for that
  knob on the connector.

Updated kernel and intel-gpu-tools patches follow. This time, I've split the
patch adding the test images (i-g-t) in a separate commit and it won't be sent
to the mailing list. This commit can be grabbed from:
http://cgit.freedesktop.org/~damien/intel-gpu-tools/commit/?h=stereo-3d

-- 
Damien

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

[Intel-gfx] [PATCH 1/3] drm: Add an "expose 3d modes" property

2012-09-27 Thread Damien Lespiau

From: Damien Lespiau 

The "expose 3D modes" property can be attached to connectors to allow
user space to indicate it can deal with 3D modes and that the drm driver
should expose those 3D modes.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc.c | 35 ++-
 include/drm/drm_crtc.h |  6 ++
 include/drm/drm_mode.h |  4 
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..10a289c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -841,6 +841,35 @@ int drm_mode_create_tv_properties(struct drm_device *dev, 
int num_modes,
 }
 EXPORT_SYMBOL(drm_mode_create_tv_properties);
 
+static const struct drm_prop_enum_list expose_3d_modes_list[] =
+{
+   { DRM_MODE_EXPOSE_3D_MODES_OFF, "Off" },
+   { DRM_MODE_EXPOSE_3D_MODES_ON, "On" }
+};
+
+/**
+ * drm_mode_create_s3d_properties - create stereo 3D properties
+ * @dev: DRM device
+ *
+ * This functions create properties that are used by the stereo 3D code. Those
+ * properties must be attached to the desired connectors afterwards.
+ */
+int drm_mode_create_s3d_properties(struct drm_device *dev)
+{
+   struct drm_property *prop;
+
+   if (dev->mode_config.s3d_expose_modes_property)
+   return 0;
+
+   prop = drm_property_create_enum(dev, 0, "expose 3D modes",
+   expose_3d_modes_list,
+   ARRAY_SIZE(expose_3d_modes_list));
+   dev->mode_config.s3d_expose_modes_property = prop;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_s3d_properties);
+
 /**
  * drm_mode_create_scaling_mode_property - create scaling mode property
  * @dev: DRM device
@@ -3170,12 +3199,16 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_mode_object *obj,
 {
int ret = -EINVAL;
struct drm_connector *connector = obj_to_connector(obj);
+   struct drm_device *dev = connector->dev;
 
/* Do DPMS ourselves */
-   if (property == connector->dev->mode_config.dpms_property) {
+   if (property == dev->mode_config.dpms_property) {
if (connector->funcs->dpms)
(*connector->funcs->dpms)(connector, (int)value);
ret = 0;
+   } else if (property == dev->mode_config.s3d_expose_modes_property) {
+   connector->expose_3d_modes = value;
+   ret = 0;
} else if (connector->funcs->set_property)
ret = connector->funcs->set_property(connector, property, 
value);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..34372cb 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -578,6 +578,8 @@ struct drm_connector {
/* requested DPMS state */
int dpms;
 
+   int expose_3d_modes;
+
void *helper_private;
 
/* forced on connector */
@@ -802,6 +804,9 @@ struct drm_mode_config {
struct drm_property *tv_saturation_property;
struct drm_property *tv_hue_property;
 
+   /* Stereo 3D properties */
+   struct drm_property *s3d_expose_modes_property;
+
/* Optional properties */
struct drm_property *scaling_mode_property;
struct drm_property *dithering_mode_property;
@@ -950,6 +955,7 @@ extern int drm_property_add_enum(struct drm_property 
*property, int index,
 extern int drm_mode_create_dvi_i_properties(struct drm_device *dev);
 extern int drm_mode_create_tv_properties(struct drm_device *dev, int 
num_formats,
 char *formats[]);
+extern int drm_mode_create_s3d_properties(struct drm_device *dev);
 extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 extern int drm_mode_create_dithering_property(struct drm_device *dev);
 extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 3d6301b..45b19c6 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -83,6 +83,10 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+/* Expose 3D modes */
+#define DRM_MODE_EXPOSE_3D_MODES_OFF   0
+#define DRM_MODE_EXPOSE_3D_MODES_ON1
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay, hsync_start, hsync_end, htotal, hskew;
-- 
1.7.11.4

___
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 HDMI vendor info frame support

2012-09-27 Thread Damien Lespiau

From: Damien Lespiau 

When scanning out a 3D framebuffer, send the corresponding infoframe to
the HDMI sink.

See http://www.hdmi.org/manufacturer/specification.aspx for details.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/intel_drv.h   | 14 +++
 drivers/gpu/drm/i915/intel_hdmi.c  | 49 +-
 drivers/gpu/drm/i915/intel_modes.c | 12 ++
 3 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd54cf8..c326d30e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,13 @@ struct cxsr_latency {
 #define DIP_SPD_BD 0xa
 #define DIP_SPD_SCD0xb
 
+#define DIP_TYPE_VENDOR0x81
+#define DIP_VERSION_VENDOR 0x1
+#define DIP_HDMI_3D_PRESENT(0x2<<5)
+#define DIP_HDMI_3D_STRUCT_FP  (0x0<<4)
+#define DIP_HDMI_3D_STRUCT_TB  (0x6<<4)
+#define DIP_HDMI_3D_STRUCT_SBSH(0x8<<4)
+
 struct dip_infoframe {
uint8_t type;   /* HB0 */
uint8_t ver;/* HB1 */
@@ -292,6 +299,12 @@ struct dip_infoframe {
uint8_t pd[16];
uint8_t sdi;
} __attribute__ ((packed)) spd;
+   struct {
+   uint8_t vendor_id[3];
+   uint8_t video_format;
+   uint8_t s3d_struct;
+   uint8_t s3d_ext_data;
+   } __attribute__ ((packed)) hdmi;
uint8_t payload[27];
} __attribute__ ((packed)) body;
 } __attribute__((packed));
@@ -348,6 +361,7 @@ int intel_ddc_get_modes(struct drm_connector *c, struct 
i2c_adapter *adapter);
 
 extern void intel_attach_force_audio_property(struct drm_connector *connector);
 extern void intel_attach_broadcast_rgb_property(struct drm_connector 
*connector);
+extern void intel_attach_expose_3d_modes_property(struct drm_connector 
*connector);
 
 extern void intel_crt_init(struct drm_device *dev);
 extern void intel_hdmi_init(struct drm_device *dev, int sdvox_reg);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 98f6024..2d51b7e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -83,6 +83,8 @@ static u32 g4x_infoframe_index(struct dip_infoframe *frame)
return VIDEO_DIP_SELECT_AVI;
case DIP_TYPE_SPD:
return VIDEO_DIP_SELECT_SPD;
+   case DIP_TYPE_VENDOR:
+   return VIDEO_DIP_SELECT_VENDOR;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
return 0;
@@ -96,6 +98,8 @@ static u32 g4x_infoframe_enable(struct dip_infoframe *frame)
return VIDEO_DIP_ENABLE_AVI;
case DIP_TYPE_SPD:
return VIDEO_DIP_ENABLE_SPD;
+   case DIP_TYPE_VENDOR:
+   return VIDEO_DIP_ENABLE_VENDOR;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
return 0;
@@ -338,6 +342,42 @@ static void intel_hdmi_set_spd_infoframe(struct 
drm_encoder *encoder)
intel_set_infoframe(encoder, &spd_if);
 }
 
+static void intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder,
+ struct drm_display_mode 
*adjusted_mode)
+{
+   struct dip_infoframe hdmi_if;
+
+   /* We really only need to send a HDMI vendor info frame when having
+* a 3D format to describe */
+   if (!(adjusted_mode->flags & DRM_MODE_FLAG_3D_MASK))
+   return;
+
+   memset(&hdmi_if, 0, sizeof(hdmi_if));
+   hdmi_if.type = DIP_TYPE_VENDOR;
+   hdmi_if.ver = DIP_VERSION_VENDOR;
+   /* HDMI IEEE registration id, least significant bit first */
+   hdmi_if.body.hdmi.vendor_id[0] = 0x03;
+   hdmi_if.body.hdmi.vendor_id[1] = 0x0c;
+   hdmi_if.body.hdmi.vendor_id[2] = 0x00;
+   hdmi_if.body.hdmi.video_format = DIP_HDMI_3D_PRESENT;
+   if (adjusted_mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING)
+   hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_FP;
+   else if (adjusted_mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM)
+   hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_TB;
+   else if (adjusted_mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
+   hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_SBSH;
+   /* len is the payload len, not including checksum. Side by side (half)
+* has an extra byte for 3D_Ext_Data */
+   if (adjusted_mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF) {
+   hdmi_if.len = 6;
+   /* SBSH is subsampled by a factor of 2 */
+   hdmi_if.body.hdmi.s3d_ext_data = 2 << 4;
+   } else
+   hdmi_if.len = 5;
+
+   intel_set_infoframe(encoder, &hdmi_if);
+}
+
 static void g4x_set_infoframes(struct drm_encoder *encoder,

[Intel-gfx] [PATCH 2/3] drm: Parse the HDMI cea vendor block for 3D present

2012-09-27 Thread Damien Lespiau

From: Damien Lespiau 

For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.

See the HDMI 1.4a 3D extraction for detail:
  http://www.hdmi.org/manufacturer/specification.aspx

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_edid.c | 87 --
 include/drm/drm_mode.h | 35 +++
 2 files changed, 105 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..7eecfa0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1522,21 +1522,102 @@ do_cea_modes (struct drm_connector *connector, u8 *db, 
u8 len)
return modes;
 }
 
+static bool cea_hdmi_3d_present(u8 *hdmi)
+{
+   u8 len, skip = 0;
+
+   len = hdmi[0] & 0x1f;
+
+   if (len < 8)
+   return false;
+
+   /* no HDMI_Video_present */
+   if (!(hdmi[8] & (1<<5)))
+   return false;
+
+   /* Latency_fields_present */
+   if (hdmi[8] & (1 << 7))
+   skip += 2;
+
+   /* I_Latency_fields_present */
+   if (hdmi[8] & (1 << 6))
+   skip += 2;
+
+   /* the declared length is not long enough */
+   if (len < (9 + skip))
+   return false;
+
+   return (hdmi[9 + skip] & (1 << 7)) != 0;
+}
+
+static const struct {
+   int width, height, freq;
+   unsigned int select, value;
+   unsigned int formats;
+} s3d_mandatory_modes[] = {
+   { 1920, 1080, 24, DRM_MODE_FLAG_INTERLACE, 0,
+ DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+   { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
+ DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+   { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
+ DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+   { 1280, 720,  50, DRM_MODE_FLAG_INTERLACE, 0,
+ DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+   { 1280, 720,  60, DRM_MODE_FLAG_INTERLACE, 0,
+ DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+};
+
+static void cea_hdmi_patch_mandatory_3d_mode(struct drm_display_mode *mode)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(s3d_mandatory_modes); i++) {
+   if (mode->hdisplay == s3d_mandatory_modes[i].width &&
+   mode->vdisplay == s3d_mandatory_modes[i].height &&
+   (mode->flags & s3d_mandatory_modes[i].select) ==
+   s3d_mandatory_modes[i].value &&
+   drm_mode_vrefresh(mode) == s3d_mandatory_modes[i].freq) {
+   mode->flags |= s3d_mandatory_modes[i].formats;
+   }
+   }
+}
+
+static void cea_hdmi_patch_mandatory_3d_modes(struct drm_connector *connector)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, &connector->probed_modes, head)
+   cea_hdmi_patch_mandatory_3d_mode(mode);
+}
+
 static int
 add_cea_modes(struct drm_connector *connector, struct edid *edid)
 {
u8 * cea = drm_find_cea_extension(edid);
-   u8 * db, dbl;
-   int modes = 0;
+   u8 * db, *hdmi = NULL, dbl;
+   int modes = 0, vendor_id;
 
+   /* let's find the cea modes before looking at the hdmi vendor block
+* as the 3d_present flag needs to know about the supported modes
+* to infer the 3D modes */
if (cea && cea[1] >= 3) {
for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
dbl = db[0] & 0x1f;
-   if (((db[0] & 0xe0) >> 5) == VIDEO_BLOCK)
+   switch ((db[0] & 0xe0) >> 5) {
+   case VIDEO_BLOCK:
modes += do_cea_modes (connector, db+1, dbl);
+   break;
+   case VENDOR_BLOCK:
+   vendor_id = db[1] | db[2] << 8 | db[3] << 16;
+   if (vendor_id == HDMI_IDENTIFIER)
+   hdmi = db;
+   }
}
}
 
+   if (connector->expose_3d_modes && hdmi && cea_hdmi_3d_present(hdmi))
+   cea_hdmi_patch_mandatory_3d_modes(connector);
+
return modes;
 }
 
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 45b19c6..d5d22de 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -44,20 +44,27 @@
 
 /* Video mode flags */
 /* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC   (1<<0)
-#define DRM_MODE_FLAG_NHSYNC   (1<<1)
-#define DRM_MODE_FLAG_PVSYNC   (1<<2)
-#define DRM_MODE_FLAG_NVSYNC   (1<<3)
-#define DRM_MODE_FLAG_INTERLACE(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN  (1<<5)
-#define DRM_MODE_FLAG_CSYNC(1<<6)
-#define DRM_MODE_FLAG_PCSYNC   (1<<7)
-#define DRM_MODE_FLAG_NCSYNC   (1<<8)
-#define DR

[Intel-gfx] [PATCH 1/2] lib: Dump information about the supported 3D stereo formats

2012-09-27 Thread Damien Lespiau

From: Damien Lespiau 

When dumping the details of a mode, let's add the 3D formats the mode
supports.

Signed-off-by: Damien Lespiau 
---
 lib/drmtest.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 8df9797..4d5a67c 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -812,7 +812,15 @@ unsigned int kmstest_create_fb(int fd, int width, int 
height, int bpp,
 
 void kmstest_dump_mode(drmModeModeInfo *mode)
 {
-   printf("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d\n",
+   bool stereo_3d = mode->flags & DRM_MODE_FLAG_3D_MASK;
+   char flags_str[32];
+
+   snprintf(flags_str, sizeof(flags_str), " (3D:%s%s%s)",
+mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM ? " TB": "",
+mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF ? " SBSH": "",
+mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING ? " FP": "");
+
+   printf("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s\n",
   mode->name,
   mode->vrefresh,
   mode->hdisplay,
@@ -825,7 +833,8 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
   mode->vtotal,
   mode->flags,
   mode->type,
-  mode->clock);
+  mode->clock,
+  stereo_3d ? flags_str : "");
fflush(stdout);
 }
 
-- 
1.7.11.4

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

[Intel-gfx] [PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

2012-09-27 Thread Damien Lespiau

From: Damien Lespiau 

Now that modes have flags to describe which 3d formats the sink
supports, it's time to test them.

The new test cycles through the supported 3D formats and paint 3D
stereoscopic images taken from publicly available samples:
  http://www.quantumdata.com/apps/3D/sample_BMP.asp

Signed-off-by: Damien Lespiau 
---
 tests/testdisplay.c | 226 ++--
 1 file changed, 221 insertions(+), 5 deletions(-)

diff --git a/tests/testdisplay.c b/tests/testdisplay.c
index c52bb2f..e179c83 100644
--- a/tests/testdisplay.c
+++ b/tests/testdisplay.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -68,7 +69,7 @@
 drmModeRes *resources;
 int drm_fd, modes;
 int dump_info = 0, test_all_modes =0, test_preferred_mode = 0, force_mode = 0,
-   test_plane, enable_tiling;
+   test_plane, test_3d_modes, enable_tiling;
 int sleep_between_modes = 5;
 uint32_t depth = 24, stride, bpp;
 int qr_code = 0;
@@ -153,8 +154,51 @@ struct connector {
drmModeConnector *connector;
int crtc;
int pipe;
+
+   /* stereo 3d */
+   int s3d_format;
+   char s3d_image[32];
 };
 
+static bool connector_expose_3d(uint32_t connector_id, bool enable)
+{
+   drmModeConnector *connector;
+   drmModePropertyRes *property;
+   bool status = false;
+   int i;
+
+   connector = drmModeGetConnector(drm_fd, connector_id);
+   if (connector->count_props == 0)
+   return false;
+
+   for (i = 0; i < connector->count_props; i++) {
+   property = drmModeGetProperty(drm_fd, connector->props[i]);
+   if (!property)
+   continue;
+
+   if (strcmp(property->name, "expose 3D modes") == 0) {
+   if (drmModeConnectorSetProperty(drm_fd,
+   connector_id,
+   property->prop_id,
+   enable))
+   fprintf(stderr, "failed to set the \"expose 3D "
+   "modes\" property on connector %d: 
%s\n",
+   connector_id, strerror(errno));
+   else
+   status = true;
+   drmModeFreeProperty(property);
+   goto out;
+   }
+
+   drmModeFreeProperty(property);
+   property = NULL;
+   }
+
+out:
+   drmModeFreeConnector(connector);
+   return status;
+}
+
 static void dump_connectors_fd(int drmfd)
 {
int i, j;
@@ -172,11 +216,13 @@ static void dump_connectors_fd(int drmfd)
for (i = 0; i < mode_resources->count_connectors; i++) {
drmModeConnector *connector;
 
+   connector_expose_3d(mode_resources->connectors[i], TRUE);
+
connector = drmModeGetConnector(drmfd, 
mode_resources->connectors[i]);
if (!connector) {
fprintf(stderr, "could not get connector %i: %s\n",
mode_resources->connectors[i], strerror(errno));
-   continue;
+   goto next;
}
 
printf("%d\t%d\t%s\t%s\t%dx%d\t\t%d\n",
@@ -188,7 +234,7 @@ static void dump_connectors_fd(int drmfd)
   connector->count_modes);
 
if (!connector->count_modes)
-   continue;
+   goto next;
 
printf("  modes:\n");
printf("  name refresh (Hz) hdisp hss hse htot vdisp "
@@ -197,6 +243,9 @@ static void dump_connectors_fd(int drmfd)
kmstest_dump_mode(&connector->modes[j]);
 
drmModeFreeConnector(connector);
+
+next:
+   connector_expose_3d(mode_resources->connectors[i], FALSE);
}
printf("\n");
 
@@ -554,6 +603,154 @@ set_mode(struct connector *c)
drmModeFreeConnector(c->connector);
 }
 
+static void
+paint_3d_image(cairo_t *cr, int l_width, int l_height, void *priv)
+{
+   struct connector *c = priv;
+   cairo_surface_t *image;
+
+   image = cairo_image_surface_create_from_png(c->s3d_image);
+
+   cairo_set_source_surface(cr, image, 0, 0);
+   cairo_paint(cr);
+
+   cairo_surface_destroy(image);
+}
+
+static void adjust_3d_timings(drmModeModeInfo *mode, unsigned int format)
+{
+   uint16_t vdisplay, vactive_space;
+
+   /* just set the 3D format we are setting (this is not used by the
+* kernel, it's just for kmstest_dump_mode()) */
+   mode->flags &= ~DRM_MODE_FLAG_3D_MASK;
+   mode->flags |= format;
+
+   switch (format) {
+   case DRM_MODE_FLAG_3D_TOP_BOTTOM:
+   case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
+   return;
+   case DRM_MODE_FLAG_3D_FRAME_PACKIN

[Intel-gfx] [PATCH] drm/i915: Flush the pending flips on the CRTC before modification

2012-09-27 Thread Chris Wilson

This was meant to be the purpose of the
intel_crtc_wait_for_pending_flips() function which is called whilst
preparing the CRTC for a modeset or before disabling. However, as Ville
Syrjala pointed out, we set the pending flip notification on the old
framebuffer that is no longer attached to the CRTC by the time we come
to flush the pending operations. Instead, we can simply wait on the
pending unpin work to be finished on this CRTC, knowning that the
hardware has therefore finished modifying the registers, before proceeding
with our direct access.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_display.c |   24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a262326..39df185 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2896,15 +2896,36 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
udelay(100);
 }
 
+static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   unsigned long flags;
+   bool pending;
+
+   if (atomic_read(&dev_priv->mm.wedged))
+   return false;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+   pending = to_intel_crtc(crtc)->unpin_work != NULL;
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+
+   return pending;
+}
+
 static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
 
flush_work_sync(&to_intel_crtc(crtc)->vblank_work.work);
 
if (crtc->fb == NULL)
return;
 
+   wait_event(dev_priv->pending_flip_queue,
+  !intel_crtc_has_pending_flip(crtc));
+
mutex_lock(&dev->struct_mutex);
intel_finish_fb(crtc->fb);
mutex_unlock(&dev->struct_mutex);
@@ -6388,9 +6409,8 @@ static void do_intel_finish_page_flip(struct drm_device 
*dev,
 
atomic_clear_mask(1 << intel_crtc->plane,
  &obj->pending_flip.counter);
-   if (atomic_read(&obj->pending_flip) == 0)
-   wake_up(&dev_priv->pending_flip_queue);
 
+   wake_up(&dev_priv->pending_flip_queue);
queue_work(dev_priv->wq, &work->work);
 
trace_i915_flip_complete(intel_crtc->plane, work->pending_flip_obj);
-- 
1.7.10.4

___
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-27 Thread Dave Airlie

On Fri, Sep 28, 2012 at 4:05 AM, Jesse Barnes  wrote:
> On Wed, 26 Sep 2012 10:34:01 -0700
> 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.

Yeah drop the DRM_ERROR, it should be DRM_INFO at worst, and
non-existant at best.

Who gives a shit if you have to upgrade your BIOS, lots of vendors
won't provide updates and I don't see Intel doing anything to solve
that.

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

51 matches

Mail list logo