date:20130805

https://bugs.freedesktop.org/show_bug.cgi?id=66940

--- Comment #9 from Konstantin Shcherban  ---
(In reply to comment #7)
> Can you try with my drm-fixes-3.11 branch:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11

Resume now works for me as well with drm-fixes-3.11 branch, thanks Alex.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the akpm tree with the drm-intel tree

2013-08-05 Thread Stephen Rothwell

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit a70a3148b0c6 ("drm/i915:
Make proper functions for VMs") from the drm-intel tree and commit
e6950216e0af ("drivers: convert shrinkers to new count/scan API") from
the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem.c
index d31e15d,49db617..000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4642,10 -4626,10 +4650,9 @@@ i915_gem_inactive_count(struct shrinke
 struct drm_i915_private,
 mm.inactive_shrinker);
struct drm_device *dev = dev_priv->dev;
 -  struct i915_address_space *vm = &dev_priv->gtt.base;
struct drm_i915_gem_object *obj;
-   int nr_to_scan = sc->nr_to_scan;
bool unlock = true;
-   int cnt;
+   long cnt;
  
if (!mutex_trylock(&dev->struct_mutex)) {
if (!mutex_is_locked_by(&dev->struct_mutex, current))
@@@ -4683,75 -4653,36 +4681,109 @@@
mutex_unlock(&dev->struct_mutex);
return cnt;
  }
 +
+ static long
+ i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
+ {
+   struct drm_i915_private *dev_priv =
+   container_of(shrinker,
+struct drm_i915_private,
+mm.inactive_shrinker);
+   struct drm_device *dev = dev_priv->dev;
+   int nr_to_scan = sc->nr_to_scan;
+   long freed;
+   bool unlock = true;
+ 
+   if (!mutex_trylock(&dev->struct_mutex)) {
+   if (!mutex_is_locked_by(&dev->struct_mutex, current))
+   return 0;
+ 
+   if (dev_priv->mm.shrinker_no_lock_stealing)
+   return 0;
+ 
+   unlock = false;
+   }
+ 
+   freed = i915_gem_purge(dev_priv, nr_to_scan);
+   if (freed < nr_to_scan)
+   freed += __i915_gem_shrink(dev_priv, nr_to_scan,
+   false);
+   if (freed < nr_to_scan)
+   freed += i915_gem_shrink_all(dev_priv);
+ 
+   if (unlock)
+   mutex_unlock(&dev->struct_mutex);
+   return freed;
+ }
++
 +/* All the new VM stuff */
 +unsigned long i915_gem_obj_offset(struct drm_i915_gem_object *o,
 +struct i915_address_space *vm)
 +{
 +  struct drm_i915_private *dev_priv = o->base.dev->dev_private;
 +  struct i915_vma *vma;
 +
 +  if (vm == &dev_priv->mm.aliasing_ppgtt->base)
 +  vm = &dev_priv->gtt.base;
 +
 +  BUG_ON(list_empty(&o->vma_list));
 +  list_for_each_entry(vma, &o->vma_list, vma_link) {
 +  if (vma->vm == vm)
 +  return vma->node.start;
 +
 +  }
 +  return -1;
 +}
 +
 +bool i915_gem_obj_bound(struct drm_i915_gem_object *o,
 +  struct i915_address_space *vm)
 +{
 +  struct i915_vma *vma;
 +
 +  list_for_each_entry(vma, &o->vma_list, vma_link)
 +  if (vma->vm == vm)
 +  return true;
 +
 +  return false;
 +}
 +
 +bool i915_gem_obj_bound_any(struct drm_i915_gem_object *o)
 +{
 +  struct drm_i915_private *dev_priv = o->base.dev->dev_private;
 +  struct i915_address_space *vm;
 +
 +  list_for_each_entry(vm, &dev_priv->vm_list, global_link)
 +  if (i915_gem_obj_bound(o, vm))
 +  return true;
 +
 +  return false;
 +}
 +
 +unsigned long i915_gem_obj_size(struct drm_i915_gem_object *o,
 +  struct i915_address_space *vm)
 +{
 +  struct drm_i915_private *dev_priv = o->base.dev->dev_private;
 +  struct i915_vma *vma;
 +
 +  if (vm == &dev_priv->mm.aliasing_ppgtt->base)
 +  vm = &dev_priv->gtt.base;
 +
 +  BUG_ON(list_empty(&o->vma_list));
 +
 +  list_for_each_entry(vma, &o->vma_list, vma_link)
 +  if (vma->vm == vm)
 +  return vma->node.size;
 +
 +  return 0;
 +}
 +
 +struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
 +   struct i915_address_space *vm)
 +{
 +  struct i915_vma *vma;
 +  list_for_each_entry(vma, &obj->vma_list, vma_link)
 +  if (vma->vm == vm)
 +  return vma;
 +
 +  return NULL;
 +}


pgpvIpt5wE7qe.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/exynos: Add fallback option to get non physically continous memory for fb

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0

To address the cases where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non physically
continous memory for fb if IOMMU is supported and if CONTIG memory allocation
fails.

Signed-off-by: Vikas Sajjan 
Signed-off-by: Arun Kumar 
Reviewed-by: Rob Clark 
---
changes since v2:
- addressed comments given by Tomasz Figa .

changes since v1:
 - Modified to add the fallback patch if CONTIG alloc fails as suggested
 by Rob Clark robdcl...@gmail.com and Tomasz Figa 
.

 - changed the commit message.
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..faec77e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
@@ -165,8 +166,17 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
 
size = mode_cmd.pitches[0] * mode_cmd.height;
 
-   /* 0 means to allocate physically continuous memory */
-   exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
+   /*
+* If IOMMU is supported then try to get buffer from non physically
+* continous memory area.
+*/
+   if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
+   dev_warn(&pdev->dev, "contiguous FB allocation failed, falling 
back to non-contiguous\n");
+   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG,
+   size);
+   }
+
if (IS_ERR(exynos_gem_obj)) {
ret = PTR_ERR(exynos_gem_obj);
goto err_release_framebuffer;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Intel-gfx] [PATCH] drm/i915: Sync the hotplug work when device suspending

2013-08-05 Thread Liu, Chuansheng



> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, August 05, 2013 1:42 PM
> To: Chris Wilson; Liu, Chuansheng; daniel.vet...@ffwll.ch; airl...@linux.ie;
> intel-...@lists.freedesktop.org; Li, Fei; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Sync the hotplug work when device
> suspending
> 
> On Sat, Jul 27, 2013 at 10:40:14AM +0100, Chris Wilson wrote:
> > On Sun, Jul 28, 2013 at 01:43:02AM +0800, Chuansheng Liu wrote:
> > >
> > > It is possible that during i915 device suspending with one pending
> > > hotplug work, one of cases is the device resume/suspend quickly.
> > >
> > > At this case, the hotplug work will be executed even after device
> > > is OFF, in Intel Android platform, it will cause system hang.
> >
> > See
> >
> >   1343070574-23917-1-git-send-email-ch...@chris-wilson.co.uk
> >   http://lists.freedesktop.org/archives/intel-gfx/2012-July/019144.html
> >
> > which is in response to the bug raised here
> >
> >   s5hlilr4s9h.wl%ti...@suse.de
> >   http://lists.freedesktop.org/archives/intel-gfx/2012-April/016738.html
> 
> Oops, I fail. And since your patch also has the required
> flush_scheduled_work (this will annoy Jesse since we flush system-wide,
> but alas) and is older ... can you please resubmit with References: for
> this new thread and the above two added and Chuanshen Lui cc'ed?
Yes, we really need this fix otherwise will cause some system hanging issue.
Thanks.

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

[PATCH 8/8] drm/tilcdc fixup mode to workaound sync for tda998x

From: Darren Etheridge 

Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.

Signed-off-by: Darren Etheridge 
---
Changelog:
for v1:
- reword comment

Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c  |7 ++-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c |   27 ++-
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 7418dcd..6d05240 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -379,7 +379,12 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
else
tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG, LCDC_SYNC_EDGE);
 
-   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+   /*
+* use value from adjusted_mode here as this might have been
+* changed as part of the fixup for slave encoders to solve the
+* issue where tilcdc timings are not VESA compliant
+*/
+   if (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC)
tilcdc_set(dev, LCDC_RASTER_TIMING_2_REG, LCDC_INVERT_HSYNC);
else
tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG, LCDC_INVERT_HSYNC);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 0bf5999..f6e9c26 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -73,13 +73,38 @@ static void slave_encoder_prepare(struct drm_encoder 
*encoder)
tilcdc_crtc_set_panel_info(encoder->crtc, &slave_info);
 }
 
+static bool slave_encoder_fixup(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   /*
+* tilcdc does not generate VESA-complient sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to let the slave encoder fix it up.
+*/
+   adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+   adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+   adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+   } else {
+   adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+   }
+
+   return drm_i2c_encoder_mode_fixup(encoder, mode, adjusted_mode);
+}
+
+
 static const struct drm_encoder_funcs slave_encoder_funcs = {
.destroy= slave_encoder_destroy,
 };
 
 static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = {
.dpms   = drm_i2c_encoder_dpms,
-   .mode_fixup = drm_i2c_encoder_mode_fixup,
+   .mode_fixup = slave_encoder_fixup,
.prepare= slave_encoder_prepare,
.commit = drm_i2c_encoder_commit,
.mode_set   = drm_i2c_encoder_mode_set,
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/8] drm/i2c: tda998x: prepare for broken sync workaround

From: Darren Etheridge 

Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.

Signed-off-by: Darren Etheridge 
Signed-off-by: Sebastian Hesselbarth 
---
Changelog:
for v1:
- reword comment

Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 7bf227a..7dc5650 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -784,6 +784,15 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
n_line   = mode->vtotal;
 
ref_pix  = 3 + mode->hsync_start - mode->hdisplay;
+
+   /*
+* Attached LCD controllers may generate broken sync. Allow
+* those to adjust the position of the rising VS edge by adding
+* HSKEW to ref_pix.
+*/
+   if (adjusted_mode->flags & DRM_MODE_FLAG_HSKEW)
+   ref_pix += adjusted_mode->hskew;
+
de_pix_s = mode->htotal - mode->hdisplay;
de_pix_e = de_pix_s + mode->hdisplay;
hs_pix_s = mode->hsync_start - mode->hdisplay;
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/8] drm/i2c: tda998x: fix sync generation and calculation

This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |  181 +++--
 1 file changed, 115 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index da04939..7bf227a 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -140,8 +140,12 @@ struct tda998x_priv {
 #define REG_VS_LINE_END_1_LSB REG(0x00, 0xae) /* write */
 #define REG_VS_PIX_END_1_MSB  REG(0x00, 0xaf) /* write */
 #define REG_VS_PIX_END_1_LSB  REG(0x00, 0xb0) /* write */
+#define REG_VS_LINE_STRT_2_MSBREG(0x00, 0xb1) /* write */
+#define REG_VS_LINE_STRT_2_LSBREG(0x00, 0xb2) /* write */
 #define REG_VS_PIX_STRT_2_MSB REG(0x00, 0xb3) /* write */
 #define REG_VS_PIX_STRT_2_LSB REG(0x00, 0xb4) /* write */
+#define REG_VS_LINE_END_2_MSB REG(0x00, 0xb5) /* write */
+#define REG_VS_LINE_END_2_LSB REG(0x00, 0xb6) /* write */
 #define REG_VS_PIX_END_2_MSB  REG(0x00, 0xb7) /* write */
 #define REG_VS_PIX_END_2_LSB  REG(0x00, 0xb8) /* write */
 #define REG_HS_PIX_START_MSB  REG(0x00, 0xb9) /* write */
@@ -152,21 +156,29 @@ struct tda998x_priv {
 #define REG_VWIN_START_1_LSB  REG(0x00, 0xbe) /* write */
 #define REG_VWIN_END_1_MSBREG(0x00, 0xbf) /* write */
 #define REG_VWIN_END_1_LSBREG(0x00, 0xc0) /* write */
+#define REG_VWIN_START_2_MSB  REG(0x00, 0xc1) /* write */
+#define REG_VWIN_START_2_LSB  REG(0x00, 0xc2) /* write */
+#define REG_VWIN_END_2_MSBREG(0x00, 0xc3) /* write */
+#define REG_VWIN_END_2_LSBREG(0x00, 0xc4) /* write */
 #define REG_DE_START_MSB  REG(0x00, 0xc5) /* write */
 #define REG_DE_START_LSB  REG(0x00, 0xc6) /* write */
 #define REG_DE_STOP_MSB   REG(0x00, 0xc7) /* write */
 #define REG_DE_STOP_LSB   REG(0x00, 0xc8) /* write */
 #define REG_TBG_CNTRL_0   REG(0x00, 0xca) /* write */
+# define TBG_CNTRL_0_TOP_TGL  (1 << 0)
+# define TBG_CNTRL_0_TOP_SEL  (1 << 1)
+# define TBG_CNTRL_0_DE_EXT   (1 << 2)
+# define TBG_CNTRL_0_TOP_EXT  (1 << 3)
 # define TBG_CNTRL_0_FRAME_DIS(1 << 5)
 # define TBG_CNTRL_0_SYNC_MTHD(1 << 6)
 # define TBG_CNTRL_0_SYNC_ONCE(1 << 7)
 #define REG_TBG_CNTRL_1   REG(0x00, 0xcb) /* write */
-# define TBG_CNTRL_1_VH_TGL_0 (1 << 0)
-# define TBG_CNTRL_1_VH_TGL_1 (1 << 1)
-# define TBG_CNTRL_1_VH_TGL_2 (1 << 2)
-# define TBG_CNTRL_1_VHX_EXT_DE   (1 << 3)
-# define TBG_CNTRL_1_VHX_EXT_HS   (1 << 4)
-# define TBG_CNTRL_1_VHX_EXT_VS   (1 << 5)
+# define TBG_CNTRL_1_H_TGL(1 << 0)
+# define TBG_CNTRL_1_V_TGL(1 << 1)
+# define TBG_CNTRL_1_TGL_EN   (1 << 2)
+# define TBG_CNTRL_1_X_EXT(1 << 3)
+# define TBG_CNTRL_1_H_EXT(1 << 4)
+# define TBG_CNTRL_1_V_EXT(1 << 5)
 # define TBG_CNTRL_1_DWIN_DIS (1 << 6)
 #define REG_ENABLE_SPACE  REG(0x00, 0xd6) /* write */
 #define REG_HVF_CNTRL_0   REG(0x00, 0xe4) /* write */
@@ -742,43 +754,70 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   uint16_t hs_start, hs_end, line_start, line_end;
-   uint16_t vwin_start, vwin_end, de_start, de_end;
-   uint16_t ref_pix, ref_line, pix_start2;
+   uint16_t ref_pix, ref_line, n_pix, n_line;
+   uint16_t hs_pix_s, hs_pix_e;
+   uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
+   uint16_t vs2_pix_s, vs2_pix_e, vs2_line_s, vs2_line_e;
+   uint16_t vwin1_line_s, vwin1_line_e;
+   uint16_t vwin2_line_s, vwin2_line_e;
+   uint16_t de_pix_s, de_pix_e;
uint8_t reg, div, rep;
 
-   hs_start   = mode->hsync_start - mode->hdisplay;
-   hs_end = mode->hsync_end - mode->hdisplay;
-   line_start = 1;
-   line_end   = 1 + mode->vsync_end - mode->vsync_start;
-   vwin_start = mode->vtotal - mode->vsync_start;
-   vwin_end   = vwin_start + mode->vdisplay;
-   de_start   = mode->htotal - mode->hdisplay;
-   de_end = mode->htotal;
-
-   pix_start2 = 0;
-   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   pix_start2 = (mode->htotal / 2) + hs_start;
-
-   /* TODO how is this value calculated?  It is 2 for all common
-* formats in the tables in out of tree nxp driver (assuming
-* I've properly deciphered their byzantine table system)
+   /*
+* Internally TDA998x is using ITU-R BT.656 style sync but
+* we get VESA style sync.

[Intel-gfx] [PATCH] drm/i915: add fast boot support for Haswell

[Now without the confidential header which shouldn't have spilled to
public lists, please reply to this one here.]

On Mon, Aug 05, 2013 at 01:24:15PM -0700, Furquan Shaikh wrote:
> We tested the submitted patch on several systems here and it seems to be
> working fine. So, I'm not sure I understand your comment. Can you please
> provide more details?

You check for the bit DP_PLL_FREQ_160MHZ in the register DP_A when
calculating the reference frequence for port A eDP panels (i.e. the
assignement of pipe_config->port_clock). This bit is valid on port A
for ivb, snb & ilk, but not on hsw. Haswell has a complete new way for
assigning the pll to the port. For solid fastboot support I think we
need to support them all (i.e. also the hdmi wrpll clocks and while at
it we might as well write the fdi dotclock readout code, it should be
almost the same as the DP dotclock computation).
-Daniel

> 
> Thanks,
> Furquan
> 
> 
> On Mon, Aug 5, 2013 at 12:24 AM, Daniel Vetter  wrote:
> 
> > On Thu, Aug 01, 2013 at 02:12:22PM -0700, Furquan Shaikh wrote:
> > > Enables getting correct mode clock when reading pipe config
> > >
> > > Signed-off-by: Furquan Shaikh 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 8 
> > >  drivers/gpu/drm/i915/intel_display.c | 9 -
> > >  2 files changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 931b4bb..fa0af9b 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct
> > intel_encoder *encoder,
> > >   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > >   enum transcoder cpu_transcoder = intel_crtc->config.cpu_transcoder;
> > > + int port = intel_ddi_get_encoder_port(encoder);
> > >   u32 temp, flags = 0;
> > >
> > >   temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > > @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct
> > intel_encoder *encoder,
> > >   flags |= DRM_MODE_FLAG_NVSYNC;
> > >
> > >   pipe_config->adjusted_mode.flags |= flags;
> > > +
> > > + if (port == PORT_A) {
> > > + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) ==
> > DP_PLL_FREQ_160MHZ)
> > > + pipe_config->port_clock = 162000;
> > > + else
> > > + pipe_config->port_clock = 27;
> > > + }
> >
> > I don't think this works correctly since for DP we have new clocks on
> > haswell, see intel_ddi_pll_mode_set. Also I think it'd be good to go right
> > ahead and implement clock readout support for all hsw clock sources, not
> > just DP.
> > -Daniel
> >
> > >  }
> > >
> > >  static void intel_ddi_destroy(struct drm_encoder *encoder)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > > index 3e66f05..681c99a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct intel_crtc
> > *crtc,
> > >   pipe_config->pixel_multiplier;
> > >  }
> > >
> > > +#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
> > > +
> > >  static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
> > >   struct intel_crtc_config *pipe_config)
> > >  {
> > > @@ -7218,7 +7220,11 @@ static void ironlake_crtc_clock_get(struct
> > intel_crtc *crtc,
> > >   return;
> > >
> > >   clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
> > > - do_div(clock, link_n);
> > > + /* This is required because the value comes out to be in fraction
> > > +(eg. 70699.54). Need to round it up since values are compared in
> > > +drm_mode_equal
> > > + */
> > > + clock = div_ceil(clock, link_n);
> > >
> > >   pipe_config->adjusted_mode.clock = clock;
> > >  }
> > > @@ -9588,6 +9594,7 @@ static void intel_init_display(struct drm_device
> > *dev)
> > >
> > >   if (HAS_DDI(dev)) {
> > >   dev_priv->display.get_pipe_config =
> > haswell_get_pipe_config;
> > > + dev_priv->display.get_clock = ironlake_crtc_clock_get;
> > >   dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> > >   dev_priv->display.crtc_enable = haswell_crtc_enable;
> > >   dev_priv->display.crtc_disable = haswell_crtc_disable;
> > > --
> > > 1.8.3
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >

> ___
> Intel-gfx mailing list
> Inte

[PATCH 5/8] drm/i2c: tda998x: add video and audio input configuration

From: Russell King 

This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.

Signed-off-by: Russell King 
Signed-off-by: Sebastian Hesselbarth 
---
Changelog:
for v1:
- set AUDIO_DIV to SERCLK/16 for modes with pixclk >100MHz
- also calculate CTS

Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |  315 -
 include/drm/i2c/tda998x.h |   23 +++
 2 files changed, 330 insertions(+), 8 deletions(-)
 create mode 100644 include/drm/i2c/tda998x.h

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d6afd02..da04939 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-
+#include 
 
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 
@@ -32,9 +32,11 @@ struct tda998x_priv {
uint16_t rev;
uint8_t current_page;
int dpms;
+   bool is_hdmi_sink;
u8 vip_cntrl_0;
u8 vip_cntrl_1;
u8 vip_cntrl_2;
+   struct tda998x_encoder_params params;
 };
 
 #define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
@@ -71,10 +73,13 @@ struct tda998x_priv {
 # define I2C_MASTER_DIS_MM(1 << 0)
 # define I2C_MASTER_DIS_FILT  (1 << 1)
 # define I2C_MASTER_APP_STRT_LAT  (1 << 2)
+#define REG_FEAT_POWERDOWNREG(0x00, 0x0e) /* read/write */
+# define FEAT_POWERDOWN_SPDIF (1 << 3)
 #define REG_INT_FLAGS_0   REG(0x00, 0x0f) /* read/write */
 #define REG_INT_FLAGS_1   REG(0x00, 0x10) /* read/write */
 #define REG_INT_FLAGS_2   REG(0x00, 0x11) /* read/write */
 # define INT_FLAGS_2_EDID_BLK_RD  (1 << 1)
+#define REG_ENA_ACLK  REG(0x00, 0x16) /* read/write */
 #define REG_ENA_VP_0  REG(0x00, 0x18) /* read/write */
 #define REG_ENA_VP_1  REG(0x00, 0x19) /* read/write */
 #define REG_ENA_VP_2  REG(0x00, 0x1a) /* read/write */
@@ -113,6 +118,7 @@ struct tda998x_priv {
 #define REG_VIP_CNTRL_5   REG(0x00, 0x25) /* write */
 # define VIP_CNTRL_5_CKCASE   (1 << 0)
 # define VIP_CNTRL_5_SP_CNT(x)(((x) & 3) << 1)
+#define REG_MUX_APREG(0x00, 0x26) /* read/write */
 #define REG_MUX_VP_VIP_OUTREG(0x00, 0x27) /* read/write */
 #define REG_MAT_CONTRLREG(0x00, 0x80) /* write */
 # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
@@ -175,6 +181,12 @@ struct tda998x_priv {
 # define HVF_CNTRL_1_PAD(x)   (((x) & 3) << 4)
 # define HVF_CNTRL_1_SEMI_PLANAR  (1 << 6)
 #define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
+#define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
+# define I2S_FORMAT(x)(((x) & 3) << 0)
+#define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
+# define AIP_CLKSEL_FS(x) (((x) & 3) << 0)
+# define AIP_CLKSEL_CLK_POL(x)(((x) & 1) << 2)
+# define AIP_CLKSEL_AIP(x)(((x) & 7) << 3)
 
 
 /* Page 02h: PLL settings */
@@ -198,6 +210,12 @@ struct tda998x_priv {
 #define REG_PLL_SCGR1 REG(0x02, 0x09) /* read/write */
 #define REG_PLL_SCGR2 REG(0x02, 0x0a) /* read/write */
 #define REG_AUDIO_DIV REG(0x02, 0x0e) /* read/write */
+# define AUDIO_DIV_SERCLK_1   0
+# define AUDIO_DIV_SERCLK_2   1
+# define AUDIO_DIV_SERCLK_4   2
+# define AUDIO_DIV_SERCLK_8   3
+# define AUDIO_DIV_SERCLK_16  4
+# define AUDIO_DIV_SERCLK_32  5
 #define REG_SEL_CLK   REG(0x02, 0x11) /* read/write */
 # define SEL_CLK_SEL_CLK1 (1 << 0)
 # define SEL_CLK_SEL_VRF_CLK(x)   (((x) & 3) << 1)
@@ -216,6 +234,11 @@ struct tda998x_priv {
 
 
 /* Page 10h: information frames and packets */
+#define REG_IF1_HB0   REG(0x10, 0x20) /* read/write */
+#define REG_IF2_HB0   REG(0x10, 0x40) /* read/write */
+#define REG_IF3_HB0   REG(0x10, 0x60) /* read/write */
+#define REG_IF4_HB0   REG(0x10, 0x80) /* read/write */
+#define REG_IF5_HB0   REG(0x10, 0xa0) /* read/write */
 
 
 /* Page 11h: audio settings and content info packets */
@@ -225,10 +248,33 @@ struct tda998x_priv {
 # define AIP_CNTRL_0_LAYOUT   (1 << 2)
 # define AIP_CNTRL_0_ACR_MAN  (1 << 5)
 # define AIP_CNTRL_0_RST_CTS  (1 << 6)
+#define REG_CA_I2SREG(0x11, 0x01) /* read/write */
+# define CA_I2S_CA_I2S(x) (((x) & 31) << 0)
+# define CA_I2S_HBR_CHSTAT(1 << 6)
+#define REG_LATENCY_RDREG(0x11, 0x04) /* read/write */
+#define REG_ACR_CTS_0 REG(0x11, 0x05) /* read/write */
+#define REG_ACR

[PATCH 2/8] drm/i2c: tda998x: ensure VIP output mux is properly set

From: Russell King 

When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation.  One such case encountered is the VIP output
mux register.  This defaults to 0x24 on powerup, but other drivers may
set this to 0x12.  This results in incorrect colours.

Fix this by ensuring that the register is always set to the power on
default setting.

Signed-off-by: Russell King 
Tested-by: Sebastian Hesselbarth 
---
Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d71c408..4b4db95 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -110,6 +110,7 @@ struct tda998x_priv {
 #define REG_VIP_CNTRL_5   REG(0x00, 0x25) /* write */
 # define VIP_CNTRL_5_CKCASE   (1 << 0)
 # define VIP_CNTRL_5_SP_CNT(x)(((x) & 3) << 1)
+#define REG_MUX_VP_VIP_OUTREG(0x00, 0x27) /* read/write */
 #define REG_MAT_CONTRLREG(0x00, 0x80) /* write */
 # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
 # define MAT_CONTRL_MAT_BP(1 << 2)
@@ -438,6 +439,8 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
 
switch (mode) {
case DRM_MODE_DPMS_ON:
+   /* Write the default value MUX register */
+   reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
/* enable audio and video ports */
reg_write(encoder, REG_ENA_AP, 0xff);
reg_write(encoder, REG_ENA_VP_0, 0xff);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/i2c: tda998x: prepare for video input configuration

From: Russell King 

The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.

Signed-off-by: Russell King 
Tested-by: Sebastian Hesselbarth 
---
Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index da2917b..d6afd02 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -32,6 +32,9 @@ struct tda998x_priv {
uint16_t rev;
uint8_t current_page;
int dpms;
+   u8 vip_cntrl_0;
+   u8 vip_cntrl_1;
+   u8 vip_cntrl_2;
 };
 
 #define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
@@ -447,12 +450,9 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
reg_write(encoder, REG_ENA_VP_1, 0xff);
reg_write(encoder, REG_ENA_VP_2, 0xff);
/* set muxing after enabling ports: */
-   reg_write(encoder, REG_VIP_CNTRL_0,
-   VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3));
-   reg_write(encoder, REG_VIP_CNTRL_1,
-   VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1));
-   reg_write(encoder, REG_VIP_CNTRL_2,
-   VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5));
+   reg_write(encoder, REG_VIP_CNTRL_0, priv->vip_cntrl_0);
+   reg_write(encoder, REG_VIP_CNTRL_1, priv->vip_cntrl_1);
+   reg_write(encoder, REG_VIP_CNTRL_2, priv->vip_cntrl_2);
break;
case DRM_MODE_DPMS_OFF:
/* disable audio and video ports */
@@ -822,6 +822,10 @@ tda998x_encoder_init(struct i2c_client *client,
if (!priv)
return -ENOMEM;
 
+   priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
+   priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
+   priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
+
priv->current_page = 0;
priv->cec = i2c_new_dummy(client->adapter, 0x34);
priv->dpms = DRM_MODE_DPMS_OFF;
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/8] Several NXP TDA998x patches

This patch set picks up several patches sent during the past months
related with NXP TDA998x HDMI transmitter driver. The patches have
been tested on Marvell Dove (Armada DRM) on several HDMI modes with
audio playing on S/PDIF. I have also quickly tested on Beaglebone
Black (tilcdc) for one DVI mode.

As I squashed some patches and fixed some audio issues, it would
be great to have a formal Tested-by or Acked-by from Russell and
Darren for the whole patch set.

Darren Etheridge (2):
  drm/i2c: tda998x: prepare for broken sync workaround
  drm/tilcdc fixup mode to workaound sync for tda998x

Russell King (5):
  drm/i2c: tda998x: fix EDID reading on TDA19988 devices
  drm/i2c: tda998x: ensure VIP output mux is properly set
  drm/i2c: tda998x: fix npix/nline programming
  drm/i2c: tda998x: prepare for video input configuration
  drm/i2c: tda998x: add video and audio input configuration

Sebastian Hesselbarth (1):
  drm/i2c: tda998x: fix sync generation and calculation

 arch/arm/boot/dts/am335x-boneblack.dts |2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c  |  526 +++-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |7 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  |   27 +-
 include/drm/i2c/tda998x.h  |   23 ++
 5 files changed, 507 insertions(+), 78 deletions(-)
 create mode 100644 include/drm/i2c/tda998x.h

---
Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: add fast boot support for Haswell

v_priv->display.get_clock = ironlake_crtc_clock_get;
> >   dev_priv->display.crtc_mode_set =
> haswell_crtc_mode_set;
> >   dev_priv->display.crtc_enable = haswell_crtc_enable;
> >   dev_priv->display.crtc_disable = haswell_crtc_disable;
> > --
> > 1.8.3
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> <mailto:dri-devel at lists.freedesktop.org>
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
>     Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48  -
> http://blog.ffwll.ch
>
>

Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: World Trade Center, Leutschenbachstrasse 95, 8050 Zurich, 
Switzerland

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/9c23f73f/attachment-0001.html>

[PATCH 3/8] drm/i2c: tda998x: fix npix/nline programming

From: Russell King 

The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.

Signed-off-by: Russell King 
Tested-by: Sebastian Hesselbarth 
---
Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 4b4db95..da2917b 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -586,8 +586,8 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
reg_set(encoder, REG_VIP_CNTRL_3, VIP_CNTRL_3_H_TGL);
 
reg_write(encoder, REG_VIDFORMAT, 0x00);
-   reg_write16(encoder, REG_NPIX_MSB, mode->hdisplay - 1);
-   reg_write16(encoder, REG_NLINE_MSB, mode->vdisplay - 1);
+   reg_write16(encoder, REG_NPIX_MSB, mode->htotal);
+   reg_write16(encoder, REG_NLINE_MSB, mode->vtotal);
reg_write16(encoder, REG_VS_LINE_STRT_1_MSB, line_start);
reg_write16(encoder, REG_VS_LINE_END_1_MSB, line_end);
reg_write16(encoder, REG_VS_PIX_STRT_1_MSB, hs_start);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/8] drm/i2c: tda998x: fix EDID reading on TDA19988 devices

From: Russell King 

TDA19988 devices need their RAM enabled in order to read EDID
information.  Add support for this.

Signed-off-by: Russell King 
Tested-by: Sebastian Hesselbarth 
---
Cc: David Airlie 
Cc: Darren Etheridge 
Cc: Rob Clark 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index e68b58a..d71c408 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -229,6 +229,8 @@ struct tda998x_priv {
 
 /* Page 12h: HDCP and OTP */
 #define REG_TX3   REG(0x12, 0x9a) /* read/write */
+#define REG_TX4   REG(0x12, 0x9b) /* read/write */
+# define TX4_PD_RAM   (1 << 1)
 #define REG_TX33  REG(0x12, 0xb8) /* read/write */
 # define TX33_HDMI(1 << 1)
 
@@ -673,6 +675,7 @@ read_edid_block(struct drm_encoder *encoder, uint8_t *buf, 
int blk)
 static uint8_t *
 do_get_edid(struct drm_encoder *encoder)
 {
+   struct tda998x_priv *priv = to_tda998x_priv(encoder);
int j = 0, valid_extensions = 0;
uint8_t *block, *new;
bool print_bad_edid = drm_debug & DRM_UT_KMS;
@@ -680,6 +683,9 @@ do_get_edid(struct drm_encoder *encoder)
if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
 
+   if (priv->rev == TDA19988)
+   reg_clear(encoder, REG_TX4, TX4_PD_RAM);
+
/* base block fetch */
if (read_edid_block(encoder, block, 0))
goto fail;
@@ -689,7 +695,7 @@ do_get_edid(struct drm_encoder *encoder)
 
/* if there's no extensions, we're done */
if (block[0x7e] == 0)
-   return block;
+   goto done;
 
new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
@@ -716,9 +722,15 @@ do_get_edid(struct drm_encoder *encoder)
block = new;
}
 
+done:
+   if (priv->rev == TDA19988)
+   reg_set(encoder, REG_TX4, TX4_PD_RAM);
+
return block;
 
 fail:
+   if (priv->rev == TDA19988)
+   reg_set(encoder, REG_TX4, TX4_PD_RAM);
dev_warn(encoder->dev->dev, "failed to read EDID\n");
kfree(block);
return NULL;
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: add fast boot support for Haswell


On 05/08/2013 22:24, Furquan Shaikh wrote:
We tested the submitted patch on several systems here and it seems to 
be working fine. So, I'm not sure I understand your comment. Can you 
please provide more details?


You check for the bit DP_PLL_FREQ_160MHZ in the register DP_A when 
calculating the reference frequence for port A eDP panels (i.e. the 
assignement of pipe_config->port_clock). This bit is valid on port A for 
ivb, snb & ilk, but not on hsw. Haswell has a complete new way for 
assigning the pll to the port. For solid fastboot support I think we 
need to support them all (i.e. also the hdmi wrpll clocks and while at 
it we might as well write the fdi dotclock readout code, it should be 
almost the same as the DP dotclock computation).

-Daniel


Thanks,
Furquan


On Mon, Aug 5, 2013 at 12:24 AM, Daniel Vetter > wrote:


On Thu, Aug 01, 2013 at 02:12:22PM -0700, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
>
> Signed-off-by: Furquan Shaikh mailto:furq...@google.com>>
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 8 
>  drivers/gpu/drm/i915/intel_display.c | 9 -
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
> index 931b4bb..fa0af9b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct
intel_encoder *encoder,
>   struct drm_i915_private *dev_priv =
encoder->base.dev->dev_private;
>   struct intel_crtc *intel_crtc =
to_intel_crtc(encoder->base.crtc);
>   enum transcoder cpu_transcoder =
intel_crtc->config.cpu_transcoder;
> + int port = intel_ddi_get_encoder_port(encoder);
>   u32 temp, flags = 0;
>
>   temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct
intel_encoder *encoder,
>   flags |= DRM_MODE_FLAG_NVSYNC;
>
>   pipe_config->adjusted_mode.flags |= flags;
> +
> + if (port == PORT_A) {
> + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) ==
DP_PLL_FREQ_160MHZ)
> + pipe_config->port_clock = 162000;
> + else
> + pipe_config->port_clock = 27;
> + }

I don't think this works correctly since for DP we have new clocks on
haswell, see intel_ddi_pll_mode_set. Also I think it'd be good to
go right
ahead and implement clock readout support for all hsw clock
sources, not
just DP.
-Daniel

>  }
>
>  static void intel_ddi_destroy(struct drm_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
> index 3e66f05..681c99a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct
intel_crtc *crtc,
>   pipe_config->pixel_multiplier;
>  }
>
> +#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
> +
>  static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
>   struct intel_crtc_config
*pipe_config)
>  {
> @@ -7218,7 +7220,11 @@ static void
ironlake_crtc_clock_get(struct intel_crtc *crtc,
>   return;
>
>   clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
> - do_div(clock, link_n);
> + /* This is required because the value comes out to be in
fraction
> +(eg. 70699.54). Need to round it up since values are
compared in
> +drm_mode_equal
> + */
> + clock = div_ceil(clock, link_n);
>
>   pipe_config->adjusted_mode.clock = clock;
>  }
> @@ -9588,6 +9594,7 @@ static void intel_init_display(struct
drm_device *dev)
>
>   if (HAS_DDI(dev)) {
> dev_priv->display.get_pipe_config = haswell_get_pipe_config;
> + dev_priv->display.get_clock = ironlake_crtc_clock_get;
>   dev_priv->display.crtc_mode_set =
haswell_crtc_mode_set;
>   dev_priv->display.crtc_enable = haswell_crtc_enable;
>   dev_priv->display.crtc_disable = haswell_crtc_disable;
> --
> 1.8.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org

> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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




Intel Semiconductor AG
Registered No. 020.30.913.786-7
Registered Office: World Trade Center, Leutschenbachstrasse 95,

Re: i915 INFO: trying to register non-static key.

On Mon, Aug 05, 2013 at 03:27:29PM +0200, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 03:23:53PM +0200, Johannes Stezenbach wrote:
> > wrt to $Subject, I get this with 3.10.5:
> > 
> > [4.342638] i915 :00:02.0: setting latency timer to 64
> > [4.409045] INFO: trying to register non-static key.
> > [4.409164] the code is fine but needs lockdep annotation.
> > [4.409278] turning off the locking correctness validator.
> > [4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1
> > [4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 
> > 09/11/2012
> > [4.409690]  0001 8802121559e0 816b265c 
> > 880212155a50
> > [4.410050]  8109ba03 822cd1c0  
> > 00010006
> > [4.410408]     
> > 8802121587a8
> 
> Looks similar to what I'm seeing. Can you cherry-pick
> 
> commit e1b4d3036c07ff137955fb1c0197ab62534f46ec
> Author: Ben Widawsky 
> Date:   Tue Jul 30 16:27:57 2013 -0700
> 
> drm/i915: fix missed hunk after GT access breakage
> 
> ontop of 3.10-stable?

This is already in 3.10.5 as commit c9af307d38974264922d35c77bb71087d171f8f8.

Thanks,
Johannes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 INFO: trying to register non-static key.

Hi,

wrt to $Subject, I get this with 3.10.5:

[4.342638] i915 :00:02.0: setting latency timer to 64
[4.409045] INFO: trying to register non-static key.
[4.409164] the code is fine but needs lockdep annotation.
[4.409278] turning off the locking correctness validator.
[4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1
[4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 
09/11/2012
[4.409690]  0001 8802121559e0 816b265c 
880212155a50
[4.410050]  8109ba03 822cd1c0  
00010006
[4.410408]     
8802121587a8
[4.410764] Call Trace:
[4.410880]  [] dump_stack+0x19/0x1b
[4.411000]  [] __lock_acquire.isra.23+0x7f7/0xb9c
[4.411120]  [] lock_acquire+0xc0/0x142
[4.411240]  [] ? i915_write32+0x99/0x13a
[4.411360]  [] _raw_spin_lock_irqsave+0x57/0x8e
[4.411481]  [] ? i915_write32+0x99/0x13a
[4.411599]  [] i915_write32+0x99/0x13a
[4.411718]  [] intel_disable_gt_powersave+0x264/0x2e5
[4.411839]  [] intel_gt_sanitize+0x91/0x93
[4.411956]  [] i915_driver_load+0x6e7/0xca5
[4.412080]  [] ? drm_get_minor+0x1d4/0x22e
[4.412199]  [] drm_get_pci_dev+0x169/0x269
[4.412319]  [] ? _raw_spin_unlock_irqrestore+0x5b/0x79
[4.412440]  [] i915_pci_probe+0x66/0x6f
[4.412557]  [] pci_device_probe+0x6e/0xb2
[4.412679]  [] driver_probe_device+0x11a/0x2e2
[4.412799]  [] __driver_attach+0x61/0x83
[4.412918]  [] ? __device_attach+0x3d/0x3d
[4.413039]  [] bus_for_each_dev+0x7d/0x87
[4.413158]  [] driver_attach+0x1e/0x20
[4.413278]  [] bus_add_driver+0x128/0x233
[4.413397]  [] driver_register+0x8c/0xfd
[4.413515]  [] __pci_register_driver+0x5d/0x60
[4.413637]  [] ? 
ftrace_define_fields_drm_vblank_event_delivered+0x9a/0x9a
[4.413818]  [] drm_pci_init+0x86/0xea
[4.413936]  [] ? 
ftrace_define_fields_drm_vblank_event_delivered+0x9a/0x9a
[4.414117]  [] i915_init+0x66/0x68
[4.414235]  [] do_one_initcall+0xa0/0x13f
[4.414355]  [] kernel_init_freeable+0x115/0x196
[4.414475]  [] ? do_early_param+0x88/0x88
[4.414594]  [] ? rest_init+0xc2/0xc2
[4.414711]  [] kernel_init+0xe/0xd6
[4.414828]  [] ret_from_fork+0x7c/0xb0
[4.414946]  [] ? rest_init+0xc2/0xc2
[4.422529] i915 :00:02.0: irq 40 for MSI/MSI-X

If you have a fix for it please send it to stable.

Thanks,
Johannes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0

To address the case where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non physically
continous memory for fb if IOMMU is supported and if CONTIG memory allocation
fails.

Signed-off-by: Vikas Sajjan 
Signed-off-by: Arun Kumar 
---
changes since v1:
 - Modified to add the fallback patch if CONTIG alloc fails as suggested
 by Rob Clark robdcl...@gmail.com and Tomasz Figa 
.

 - changed the commit message.
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..9a4b886 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
@@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
 
size = mode_cmd.pitches[0] * mode_cmd.height;
 
-   /* 0 means to allocate physically continuous memory */
-   exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
if (IS_ERR(exynos_gem_obj)) {
-   ret = PTR_ERR(exynos_gem_obj);
-   goto err_release_framebuffer;
+   /*
+* If IOMMU is supported then try to get buffer from
+* non-continous memory area
+*/
+   if (is_drm_iommu_supported(dev))
+   exynos_gem_obj = exynos_drm_gem_create(dev,
+   EXYNOS_BO_NONCONTIG, size);
+   if (IS_ERR(exynos_gem_obj)) {
+   ret = PTR_ERR(exynos_gem_obj);
+   goto err_release_framebuffer;
+   }
+   dev_warn(&pdev->dev, "exynos_gem_obj for FB is allocated with\n"
+   "non physically continuous memory\n");
}
 
exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

Hi Sylwester,

On 2 August 2013 16:28, Sylwester Nawrocki  wrote:
> Hi Vikas,
>
> On 08/02/2013 12:10 PM, Vikas Sajjan wrote:
>> yeah, we could not allocate CMA region for FIMD, because the function
>> dma_declare_contiguous() needs "dev" as the first argument and we have
>> access to "dev" node only if it is NON-DT way of probing like the way
>> it is done in arch/arm/mach-davinci/devices-da8xx.c
>> But now, since the probing is through DT way, there is NO way ( Let me
>> know if something is newly added ) to call dma_declare_contiguous()
>> and reserve CMA region .
>
> See this patch series [1]. We have have been using this kind of bindings
> for assigning physically contiguous memory regions to the Exynos
> multimedia devices, instead of what's currently in mainline where same
> physical addresses are repeated in dts for various boards without much
> thought. And where custom device specific parsing code is required at
> arch side.
>
> $ git grep mfc\-[lr] arch/arm/boot/dts
>
> arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-l = <0x5100 
> 0x80>;
>
>
> [1] http://www.spinics.net/lists/arm-kernel/msg263130.html
>


Thanks, its good that now we have a new way to reserve CMA region.


> Regards,
> Sylwester



-- 
Thanks and Regards
 Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: add fast boot support for Haswell

2013-08-05 Thread Furquan Shaikh

We tested the submitted patch on several systems here and it seems to be
working fine. So, I'm not sure I understand your comment. Can you please
provide more details?

Thanks,
Furquan


On Mon, Aug 5, 2013 at 12:24 AM, Daniel Vetter  wrote:

> On Thu, Aug 01, 2013 at 02:12:22PM -0700, Furquan Shaikh wrote:
> > Enables getting correct mode clock when reading pipe config
> >
> > Signed-off-by: Furquan Shaikh 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 8 
> >  drivers/gpu/drm/i915/intel_display.c | 9 -
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> > index 931b4bb..fa0af9b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct
> intel_encoder *encoder,
> >   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> >   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> >   enum transcoder cpu_transcoder = intel_crtc->config.cpu_transcoder;
> > + int port = intel_ddi_get_encoder_port(encoder);
> >   u32 temp, flags = 0;
> >
> >   temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct
> intel_encoder *encoder,
> >   flags |= DRM_MODE_FLAG_NVSYNC;
> >
> >   pipe_config->adjusted_mode.flags |= flags;
> > +
> > + if (port == PORT_A) {
> > + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) ==
> DP_PLL_FREQ_160MHZ)
> > + pipe_config->port_clock = 162000;
> > + else
> > + pipe_config->port_clock = 27;
> > + }
>
> I don't think this works correctly since for DP we have new clocks on
> haswell, see intel_ddi_pll_mode_set. Also I think it'd be good to go right
> ahead and implement clock readout support for all hsw clock sources, not
> just DP.
> -Daniel
>
> >  }
> >
> >  static void intel_ddi_destroy(struct drm_encoder *encoder)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> > index 3e66f05..681c99a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct intel_crtc
> *crtc,
> >   pipe_config->pixel_multiplier;
> >  }
> >
> > +#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
> > +
> >  static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
> >   struct intel_crtc_config *pipe_config)
> >  {
> > @@ -7218,7 +7220,11 @@ static void ironlake_crtc_clock_get(struct
> intel_crtc *crtc,
> >   return;
> >
> >   clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
> > - do_div(clock, link_n);
> > + /* This is required because the value comes out to be in fraction
> > +(eg. 70699.54). Need to round it up since values are compared in
> > +drm_mode_equal
> > + */
> > + clock = div_ceil(clock, link_n);
> >
> >   pipe_config->adjusted_mode.clock = clock;
> >  }
> > @@ -9588,6 +9594,7 @@ static void intel_init_display(struct drm_device
> *dev)
> >
> >   if (HAS_DDI(dev)) {
> >   dev_priv->display.get_pipe_config =
> haswell_get_pipe_config;
> > + dev_priv->display.get_clock = ironlake_crtc_clock_get;
> >   dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> >   dev_priv->display.crtc_enable = haswell_crtc_enable;
> >   dev_priv->display.crtc_disable = haswell_crtc_disable;
> > --
> > 1.8.3
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)

https://bugs.freedesktop.org/show_bug.cgi?id=42162

Johan Brannlund  changed:

   What|Removed |Added

  Attachment #83689|0   |1
is obsolete||

--- Comment #22 from Johan Brannlund  ---
Created attachment 83693
  --> https://bugs.freedesktop.org/attachment.cgi?id=83693&action=edit
3.11-rc3 suspend/resume, both cards powered up before suspend

Including previously missing REDWOOD_smc.bin changes the log slightly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)

https://bugs.freedesktop.org/show_bug.cgi?id=42162

--- Comment #21 from Johan Brannlund  ---
Comment on attachment 83689
  --> https://bugs.freedesktop.org/attachment.cgi?id=83689
3.11-rc3 suspend/resume, both cards powered up before suspend

>Aug  6 00:14:53 mars kernel: [  143.123335] PM: Syncing filesystems ... done.
>Aug  6 00:15:18 mars kernel: [  143.265460] Freezing user space processes ... 
>(elapsed 0.001 seconds) done.
>Aug  6 00:15:18 mars kernel: [  143.267108] Freezing remaining freezable tasks 
>... (elapsed 0.001 seconds) done.
>Aug  6 00:15:18 mars kernel: [  143.268729] Suspending console(s) (use 
>no_console_suspend to debug)
>Aug  6 00:15:18 mars kernel: [  143.269239] brcmsmac bcma0:0: brcmsmac: 
>brcms_ops_bss_info_changed: disassociated
>Aug  6 00:15:18 mars kernel: [  143.269245] brcmsmac bcma0:0: 
>brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
>Aug  6 00:15:18 mars kernel: [  143.269247] brcmsmac bcma0:0: 
>brcms_ops_bss_info_changed: qos enabled: false (implement)
>Aug  6 00:15:18 mars kernel: [  143.297269] sd 0:0:0:0: [sda] Synchronizing 
>SCSI cache
>Aug  6 00:15:18 mars kernel: [  143.297339] cfg80211: Calling CRDA to update 
>world regulatory domain
>Aug  6 00:15:18 mars kernel: [  143.297341] sd 0:0:0:0: [sda] Stopping disk
>Aug  6 00:15:18 mars kernel: [  143.387143] i8042 aux 00:07: System wakeup 
>disabled by ACPI
>Aug  6 00:15:18 mars kernel: [  143.387217] i8042 kbd 00:06: System wakeup 
>enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.703766] PM: suspend of devices complete 
>after 1434.453 msecs
>Aug  6 00:15:18 mars kernel: [  144.704050] PM: late suspend of devices 
>complete after 0.279 msecs
>Aug  6 00:15:18 mars kernel: [  144.705302] pcieport :00:06.0: System 
>wakeup enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.735807] ehci-pci :00:16.2: System 
>wakeup enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.751774] ehci-pci :00:13.2: System 
>wakeup enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.767674] ohci-pci :00:13.0: System 
>wakeup enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.767707] ehci-pci :00:12.2: System 
>wakeup enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.783677] ohci-pci :00:12.0: System 
>wakeup enabled by ACPI
>Aug  6 00:15:18 mars kernel: [  144.783802] PM: noirq suspend of devices 
>complete after 79.730 msecs
>Aug  6 00:15:18 mars kernel: [  144.783866] ACPI: Preparing to enter system 
>sleep state S3
>Aug  6 00:15:18 mars kernel: [  144.793732] PM: Saving platform NVS memory
>Aug  6 00:15:18 mars kernel: [  144.798121] Disabling non-boot CPUs ...
>Aug  6 00:15:18 mars kernel: [  144.798530] Broke affinity for irq 19
>Aug  6 00:15:18 mars kernel: [  144.799604] smpboot: CPU 1 is now offline
>Aug  6 00:15:18 mars kernel: [  144.903635] smpboot: CPU 2 is now offline
>Aug  6 00:15:18 mars kernel: [  144.904260] Broke affinity for irq 17
>Aug  6 00:15:18 mars kernel: [  145.007704] smpboot: CPU 3 is now offline
>Aug  6 00:15:18 mars kernel: [  145.008505] ACPI: Low-level resume complete
>Aug  6 00:15:18 mars kernel: [  145.008555] PM: Restoring platform NVS memory
>Aug  6 00:15:18 mars kernel: [  145.010313] PCI-DMA: Resuming GART IOMMU
>Aug  6 00:15:18 mars kernel: [  145.010314] PCI-DMA: Restoring GART aperture 
>settings
>Aug  6 00:15:18 mars kernel: [  145.010614] Enabling non-boot CPUs ...
>Aug  6 00:15:18 mars kernel: [  145.010663] smpboot: Booting Node 0 Processor 
>1 APIC 0x1
>Aug  6 00:15:18 mars kernel: [  145.021636] [Firmware Bug]: cpu 1, try to use 
>APIC500 (LVT offset 0) for vector 0x400, but the register is already in use 
>for vector 0xf9 on another cpu
>Aug  6 00:15:18 mars kernel: [  145.021638] perf: IBS APIC setup failed on cpu 
>#1
>Aug  6 00:15:18 mars kernel: [  145.023788] process: Switch to broadcast mode 
>on CPU1
>Aug  6 00:15:18 mars kernel: [  145.024075] CPU1 is up
>Aug  6 00:15:18 mars kernel: [  145.024094] smpboot: Booting Node 0 Processor 
>2 APIC 0x2
>Aug  6 00:15:18 mars kernel: [  145.035062] [Firmware Bug]: cpu 2, try to use 
>APIC500 (LVT offset 0) for vector 0x400, but the register is already in use 
>for vector 0xf9 on another cpu
>Aug  6 00:15:18 mars kernel: [  145.035064] perf: IBS APIC setup failed on cpu 
>#2
>Aug  6 00:15:18 mars kernel: [  145.037208] process: Switch to broadcast mode 
>on CPU2
>Aug  6 00:15:18 mars kernel: [  145.037422] CPU2 is up
>Aug  6 00:15:18 mars kernel: [  145.037440] smpboot: Booting Node 0 Processor 
>3 APIC 0x3
>Aug  6 00:15:18 mars kernel: [  145.037956] [ cut here 
>]
>Aug  6 00:15:18 mars kernel: [  145.037967] WARNING: CPU: 2 PID: 0 at 
>/home/apw/COD/linux/kernel/time/tick-broadcast.c:667 
>tick_broadcast_oneshot_control+0x18c/0x1a0()
>Aug  6 00:15:18 mars kernel: [  145.038014] Modules linked in: arc4 brcmsmac 
>cordic brcmutil b43 mac80211 cfg80211 joydev ssb hp_wmi sparse_keymap 
>snd_hda_codec_hdmi snd_hda_codec_idt snd_seq_midi snd_hda_intel dm_multipath 
>sn

[PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 07:18:27PM +0100, Damien Lespiau wrote:
> On Mon, Aug 05, 2013 at 09:07:05PM +0300, Ville Syrj?l? wrote:
> > On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> > > >From CEA-861:
> > > 
> > >   Data Byte 1, bit A0 indicates whether Active Format Data is present in
> > >   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
> > >   any of the AFD bits are set.
> > > 
> > > ie. if we want to set active_aspect, we need to set the
> > > active_info_valid bit to 1 as well.
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Damien Lespiau 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 95d6f4b..8d1139f 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > > hdmi_avi_infoframe *frame,
> > >   return 0;
> > 
> > Nothing to do with this patch, but I just spotted this return here. So
> > we're not populating the aspect ratio stuff if VIC=0. Doesn't really
> > make sense to me. Who will tell me what this is trying to achieve?
> 
> I wondered about that to. The intent seems to not set those bits when
> we're not setting a CEA mode. I guess the author thought that only CEA
> modes can understand the infoframes described in CEA-861. I haven't
> found any evidence of that, but made some sense to me.

Perhaps. I'm leaning towards just killing that check though.

-- 
Ville Syrj?l?
Intel OTC

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)

https://bugs.freedesktop.org/show_bug.cgi?id=42162

--- Comment #20 from Johan Brannlund  ---
Created attachment 83689
  --> https://bugs.freedesktop.org/attachment.cgi?id=83689&action=edit
3.11-rc3 suspend/resume, both cards powered up before suspend

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)

https://bugs.freedesktop.org/show_bug.cgi?id=42162

--- Comment #19 from Johan Brannlund  ---
I just tried 3.11-rc3, with the important difference that I kept both cards
active when suspending.

When resuming, the backlight now came on for a second but the screen then
turned dark again. Looking at the logs, the failure now seems less catastrophic
than before. 

Could it be that if I disable one card before suspending (using vgaswitcheroo),
the resume code unsuccessfully tries to power up the previously disabled card?

Also, I don't seem to get any dpm options in /sys for the discrete card (the
5650), but that's a separate bug I guess.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> >From CEA-861:
> 
>   Data Byte 1, bit A0 indicates whether Active Format Data is present in
>   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
>   any of the AFD bits are set.
> 
> ie. if we want to set active_aspect, we need to set the
> active_info_valid bit to 1 as well.
> 
> Cc: Thierry Reding 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/drm_edid.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 95d6f4b..8d1139f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> hdmi_avi_infoframe *frame,
>   return 0;

Nothing to do with this patch, but I just spotted this return here. So
we're not populating the aspect ratio stuff if VIC=0. Doesn't really
make sense to me. Who will tell me what this is trying to achieve?

>  
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> + frame->active_info_valid = 1;
>   frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
>  
>   return 0;
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #8 from Gabor Hasenfrasz  ---
Created attachment 107105
  --> https://bugzilla.kernel.org/attachment.cgi?id=107105&action=edit
avivotool regs hdmi output on kernel 3.10

This is with radeon.audio=1 kernel parameter with kernel 3.10.3

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #7 from Gabor Hasenfrasz  ---
Created attachment 107104
  --> https://bugzilla.kernel.org/attachment.cgi?id=107104&action=edit
avivotool regs hdmi output on kernel 3.9

This is with radeon.audio=1 kernel parameter with kernel 3.9.9

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 67800] New: Computer freezes after idle for several hours with dpms off (trinity)

https://bugs.freedesktop.org/show_bug.cgi?id=67800

Priority: medium
Bug ID: 67800
Assignee: dri-devel at lists.freedesktop.org
Summary: Computer freezes after idle for several hours with
dpms off (trinity)
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: laszlo.kertesz at gmail.com
Hardware: x86-64 (AMD64)
Status: NEW
Version: DRI CVS
Component: DRM/Radeon
Product: DRI

I use Debian 64 bit and now i have the 3.11rc4 kernel installed, with mesa from
git, xf86-video-ati from git, libdrm from git, all firmwares put in
/lib/firmware.
The hardware is A8-5500 desktop APU with its built in 7560D card.
The system works very well, opengl, vdpau is functional.

I have xscreensaver set to turn off the monitor after 4 minutes, which it does.
I can wake up after a few minutes by moving the mouse or pressing a key.

All is going well until i leave the computer for a longer time (it varies,
usually a few hours) - the computer becomes totally unresponsive, doesnt react
to keyboard/mouse and network wise is totally dead. The fans are on normally,
no disk activity. I have to reset it from the reset button.
Nothing out of the ordinary in any logs, they just stop logging, presumably
when the computer freezes.

Now if i disable dpms and leave only blanking, this doesnt happen (This is why
i think it has to do with the kernel driver), but this mean the monitor is on
all the tme which isnt good since the computer runs 24/7.

PS. It didnt happen previously with the fglrx driver in any circumstances.

Any ideas why this might happen?

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/24a5d66a/attachment.html>

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #6 from Gabor Hasenfrasz  ---
(In reply to Rafa? Mi?ecki from comment #4)
> Do you have some second monitor or other machine to ssh the first one?
> 
> I'd like to see output of command
> avivotool regs hdmi
> when using 3.9 with audio=1 and then using 3.10/3.11 with audio=1.

Yes I do. I will run it now.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #5 from Gabor Hasenfrasz  ---
(In reply to Alex Deucher from comment #2)
> Can you bisect?

Bisect finished:

d3418eacad403033e95e49dc14afa37c2112c134 is the first bad commit
commit d3418eacad403033e95e49dc14afa37c2112c134
Author: Rafa? Mi?ecki 
Date:   Thu Apr 18 09:23:12 2013 -0400

drm/radeon/evergreen: setup HDMI before enabling it

Closed source driver fglrx seems to enable infoframes and audio packets
at the end, which makes sense, do the same.

Signed-off-by: Rafa? Mi?ecki 
Signed-off-by: Alex Deucher 

:04 04 67e10b90afeefe688d0c291e603c80dd7a9e810a
1105ef4336989eee87c971b035fedcc092c42417 Mdrivers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/4] drm/radeon: only save UVD bo when we have open handles

2013-08-05 Thread Alex Deucher

On Mon, Aug 5, 2013 at 8:10 AM, Christian K?nig  
wrote:
> From: Christian K?nig 
>
> Otherwise just reinitialize from scratch on resume,
> and so make it more likely to succeed.
>
> Signed-off-by: Christian K?nig 
> Cc: stable at vger.kernel.org

Pulled the series into my -fixes branch.

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c  |2 +-
>  drivers/gpu/drm/radeon/radeon.h   |2 +-
>  drivers/gpu/drm/radeon/radeon_fence.c |2 +-
>  drivers/gpu/drm/radeon/radeon_uvd.c   |   46 
> +++--
>  drivers/gpu/drm/radeon/rv770.c|2 +-
>  5 files changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 524db70..ecb883d 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -6979,7 +6979,7 @@ int cik_uvd_resume(struct radeon_device *rdev)
>
> /* programm the VCPU memory controller bits 0-27 */
> addr = rdev->uvd.gpu_addr >> 3;
> -   size = RADEON_GPU_PAGE_ALIGN(rdev->uvd.fw_size + 4) >> 3;
> +   size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 4) >> 3;
> WREG32(UVD_VCPU_CACHE_OFFSET0, addr);
> WREG32(UVD_VCPU_CACHE_SIZE0, size);
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 2f08219..76dbe8e 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1468,7 +1468,6 @@ struct radeon_uvd {
> void*cpu_addr;
> uint64_tgpu_addr;
> void*saved_bo;
> -   unsignedfw_size;
> atomic_thandles[RADEON_MAX_UVD_HANDLES];
> struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
> struct delayed_work idle_work;
> @@ -2066,6 +2065,7 @@ struct radeon_device {
> const struct firmware *mec_fw;  /* CIK MEC firmware */
> const struct firmware *sdma_fw; /* CIK SDMA firmware */
> const struct firmware *smc_fw;  /* SMC firmware */
> +   const struct firmware *uvd_fw;  /* UVD firmware */
> struct r600_blit r600_blit;
> struct r600_vram_scratch vram_scratch;
> int msi_enabled; /* msi enabled */
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 7ddb0ef..ddb8f8e 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -782,7 +782,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
> *rdev, int ring)
>
> } else {
> /* put fence directly behind firmware */
> -   index = ALIGN(rdev->uvd.fw_size, 8);
> +   index = ALIGN(rdev->uvd_fw->size, 8);
> rdev->fence_drv[ring].cpu_addr = rdev->uvd.cpu_addr + 
> index;
> rdev->fence_drv[ring].gpu_addr = rdev->uvd.gpu_addr + 
> index;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 414fd14..ca0d735 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -56,7 +56,6 @@ static void radeon_uvd_idle_work_handler(struct work_struct 
> *work);
>
>  int radeon_uvd_init(struct radeon_device *rdev)
>  {
> -   const struct firmware *fw;
> unsigned long bo_size;
> const char *fw_name;
> int i, r;
> @@ -105,14 +104,14 @@ int radeon_uvd_init(struct radeon_device *rdev)
> return -EINVAL;
> }
>
> -   r = request_firmware(&fw, fw_name, rdev->dev);
> +   r = request_firmware(&rdev->uvd_fw, fw_name, rdev->dev);
> if (r) {
> dev_err(rdev->dev, "radeon_uvd: Can't load firmware \"%s\"\n",
> fw_name);
> return r;
> }
>
> -   bo_size = RADEON_GPU_PAGE_ALIGN(fw->size + 8) +
> +   bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 8) +
>   RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE;
> r = radeon_bo_create(rdev, bo_size, PAGE_SIZE, true,
>  RADEON_GEM_DOMAIN_VRAM, NULL, 
> &rdev->uvd.vcpu_bo);
> @@ -145,12 +144,6 @@ int radeon_uvd_init(struct radeon_device *rdev)
>
> radeon_bo_unreserve(rdev->uvd.vcpu_bo);
>
> -   rdev->uvd.fw_size = fw->size;
> -   memset(rdev->uvd.cpu_addr, 0, bo_size);
> -   memcpy(rdev->uvd.cpu_addr, fw->data, fw->size);
> -
> -   release_firmware(fw);
> -
> for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
> atomic_set(&rdev->uvd.handles[i], 0);
> rdev->uvd.filp[i] = NULL;
> @@ -174,33 +167,60 @@ void radeon_uvd_fini(struct radeon_device *rdev)
> }
>
> radeon_bo_unref(&rdev->uvd.vcpu_bo);
> +
> +   release_firmware(rdev->uvd_fw);
>  }
>
>  int radeon_uvd_suspend(struct radeon_device *rdev)
>  {
> unsigned size;
> +   vo

[PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 09:07:05PM +0300, Ville Syrj?l? wrote:
> On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> > >From CEA-861:
> > 
> >   Data Byte 1, bit A0 indicates whether Active Format Data is present in
> >   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
> >   any of the AFD bits are set.
> > 
> > ie. if we want to set active_aspect, we need to set the
> > active_info_valid bit to 1 as well.
> > 
> > Cc: Thierry Reding 
> > Signed-off-by: Damien Lespiau 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 95d6f4b..8d1139f 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > hdmi_avi_infoframe *frame,
> > return 0;
> 
> Nothing to do with this patch, but I just spotted this return here. So
> we're not populating the aspect ratio stuff if VIC=0. Doesn't really
> make sense to me. Who will tell me what this is trying to achieve?

I wondered about that to. The intent seems to not set those bits when
we're not setting a CEA mode. I guess the author thought that only CEA
modes can understand the infoframes described in CEA-861. I haven't
found any evidence of that, but made some sense to me.

-- 
Damien

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-05 Thread Tom Cooksey

Hi Rob,

+linux-media, +linaro-mm-sig for discussion of video/camera
buffer constraints...

> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey 
> wrote:
> >> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >> >allocate buffers for the GPU. Still not sure how to resolve
> >> >this as we don't use DRM for our GPU driver.
> >>
> >> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
> >> once the dma-fence stuff is in place), we'd have gpu-specific drm
> >> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
> >> using prime/dmabuf to share between the two.
> >
> > The "extra" buffers we were allocating from armsoc DDX were really
> > being allocated through DRM/GEM so we could get an flink name
> > for them and pass a reference to them back to our GPU driver on
> > the client side. If it weren't for our need to access those
> > extra off-screen buffers with the GPU we wouldn't need to
> > allocate them with DRM at all. So, given they are really "GPU"
> > buffers, it does absolutely make sense to allocate them in a
> > different driver to the display driver.
> >
> > However, to avoid unnecessary memcpys & related cache
> > maintenance ops, we'd also like the GPU to render into buffers
> > which are scanned out by the display controller. So let's say
> > we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> > out buffers with the display's DRM driver but a custom ioctl
> > on the GPU's DRM driver to allocate non scanout, off-screen
> > buffers. Sounds great, but I don't think that really works
> > with DRI2. If we used two drivers to allocate buffers, which
> > of those drivers do we return in DRI2ConnectReply? Even if we
> > solve that somehow, GEM flink names are name-spaced to a
> > single device node (AFAIK). So when we do a DRI2GetBuffers,
> > how does the EGL in the client know which DRM device owns GEM
> > flink name "1234"? We'd need some pretty dirty hacks.
> 
> You would return the name of the display driver allocating the
> buffers.  On the client side you can use generic ioctls to go from
> flink -> handle -> dmabuf.  So the client side would end up opening
> both the display drm device and the gpu, but without needing to know
> too much about the display.

I think the bit I was missing was that a GEM bo for a buffer imported
using dma_buf/PRIME can still be flink'd. So the display controller's
DRM driver allocates scan-out buffers via the DUMB buffer allocate
ioctl. Those scan-out buffers than then be exported from the
dispaly's DRM driver and imported into the GPU's DRM driver using
PRIME. Once imported into the GPU's driver, we can use flink to get a
name for that buffer within the GPU DRM driver's name-space to return
to the DRI2 client. That same namespace is also what DRI2 back-buffers
are allocated from, so I think that could work... Except...

> > Anyway, that latter case also gets quite difficult. The "GPU"
> > DRM driver would need to know the constraints of the display
> > controller when allocating buffers intended to be scanned out.
> > For example, pl111 typically isn't behind an IOMMU and so
> > requires physically contiguous memory. We'd have to teach the
> > GPU's DRM driver about the constraints of the display HW. Not
> > exactly a clean driver model. :-(
> >
> > I'm still a little stuck on how to proceed, so any ideas
> > would greatly appreciated! My current train of thought is
> > having a kind of SoC-specific DRM driver which allocates
> > buffers for both display and GPU within a single GEM
> > namespace. That SoC-specific DRM driver could then know the
> > constraints of both the GPU and the display HW. We could then
> > use PRIME to export buffers allocated with the SoC DRM driver
> > and import them into the GPU and/or display DRM driver.
> 
> Usually if the display drm driver is allocating the buffers that might
> be scanned out, it just needs to have minimal knowledge of the GPU
> (pitch alignment constraints).  I don't think we need a 3rd device
> just to allocate buffers.

While Mali can render to pretty much any buffer, there is a mild
performance improvement to be had if the buffer stride is aligned to
the AXI bus's max burst length when drawing to the buffer.

So in some respects, there is a constraint on how buffers which will
be drawn to using the GPU are allocated. I don't really like the idea
of teaching the display controller DRM driver about the GPU buffer
constraints, even if they are fairly trivial like this. If the same
display HW IP is being used on several SoCs, it seems wrong somehow
to enforce those GPU constraints if some of those SoCs don't have a
GPU.

We may also then have additional constraints when sharing buffers
between the display HW and video decode or even camera ISP HW.
Programmatically describing buffer allocation constraints is very
difficult and I'm not sure you can actually do it - there's some
pretty complex constraints out there! E.g. I believe there's a
platform

modetest patches pushed to libdrm master

2013-08-05 Thread Laurent Pinchart

Hello,

Just a quick mail to tell that I've pushed the following modetest patches to 
the libdrm master branch.

3c967e7 modetest: Allocate NV buffers large enough for the two planes
1ef179d modetest: Fix line stride in SMPTE YUV packet pattern generator
a4f2f1b modetest: Try all possible encoders for a connector
2c5ee84 modetest: Support pipes with multiple connectors
b1e0bde modetest: Rename struct connector_arg to struct pipe_arg
3813e0f modetest: Split mode setting and plane setup
eabf199 modetest: Give the CRTC ID to the -P option
5659268 modetest: Store the mode in the crtc structure
a6349d0 modetest: Store the crtc in the connector_arg structure
b373de3 modetest: Remove the struct connector_arg encoder field
605efd7 modetest: Compute CRTC pipe number as needed
549fe0b modetest: Create a device structure
dab3c80 modetest: Remove the -m argument
581c7cf modetest: Print the plane ID when setting up a plane
7badcca modetest: Allow specifying plane position
d725227 modetest: Add a command line parameter to set properties
6e0c74c modetest: Don't limit mode set and planes to two instances
02fa8f7 modetest: Retrieve all resources in one go
ab52756 modetest: Add a command line parameter to drop master after mode set
45901fd modetest: Add a command line parameter to select the driver
ef07acf modetest: Sort command line arguments
c93f4af modetest: Remove extern declarations of opt(arg|ind|err|opt)
ca9c8f0 modetest: Fix warnings

All patches have been previously reviewed on the list.

-- 
Regards,

Laurent Pinchart

[Bug 67713] Freezes on Trinity 7500G

https://bugs.freedesktop.org/show_bug.cgi?id=67713

--- Comment #7 from Mike Lothian  ---
Changing the bug name - perhaps the atombios issue was a red herring

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67713] Freezes on Trinity 7500G

https://bugs.freedesktop.org/show_bug.cgi?id=67713

Mike Lothian  changed:

   What|Removed |Added

Summary|Atombios stuck in a loop on |Freezes on Trinity 7500G
   |Trinity 7500G   |

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67713] Atombios stuck in a loop on Trinity 7500G

https://bugs.freedesktop.org/show_bug.cgi?id=67713

--- Comment #6 from Mike Lothian  ---
Created attachment 83685
  --> https://bugs.freedesktop.org/attachment.cgi?id=83685&action=edit
Dmesg showing issue

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67713] Atombios stuck in a loop on Trinity 7500G

https://bugs.freedesktop.org/show_bug.cgi?id=67713

--- Comment #5 from Mike Lothian  ---
OK I've gotten a dmesg for when it freezes up

I can't change VTs but I was able to SSH in

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/msm: add a3xx gpu support

> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> new file mode 100644
> index 000..a586fbd
> --- /dev/null
> +++ b/include/uapi/drm/msm_drm.h
> @@ -0,0 +1,198 @@
> +/*
> + * Copyright (C) 2013 Red Hat
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __MSM_DRM_H__
> +#define __MSM_DRM_H__
> +
> +#include 
> +#include 
> +
> +/* Please note that modifications to all structs defined here are
> + * subject to backwards-compatibility constraints:
> + *  1) Do not use pointers, use uint64_t instead for 32 bit / 64 bit
> + * user/kernel compatibility
> + *  2) Keep fields aligned to their size
> + *  3) Because of how drm_ioctl() works, we can add new fields at
> + * the end of an ioctl if some care is taken: drm_ioctl() will
> + * zero out the new fields at the tail of the ioctl, so a zero
> + * value should have a backwards compatible meaning.  And for
> + * output params, userspace won't see the newly added output
> + * fields.. so that has to be somehow ok.
> + */
> +
> +#define MSM_PIPE_NONE0x00
> +#define MSM_PIPE_2D0 0x01
> +#define MSM_PIPE_2D1 0x02
> +#define MSM_PIPE_3D0 0x10
> +
> +#define MSM_PARAM_GPU_ID 0x01
> +#define MSM_PARAM_GMEM_SIZE  0x02
> +
> +struct drm_msm_param {
> +   uint32_t pipe;   /* in, MSM_PIPE_x */
> +   uint32_t param;  /* in, MSM_PARAM_x */
> +   uint64_t value;  /* out (get_param) or in (set_param) */
> +};
> +
> +/*
> + * GEM buffers:
> + */
> +
> +// TODO: might eventually want some more usage hints (like RENDER_TARGET,
> +// etc) to give some hint about initial placement (DDR, SMI, etc..)
> +#define MSM_BO_SCANOUT   0x0001 /* scanout capable */
> +#define MSM_BO_GPU_READONLY  0x0002
> +#define MSM_BO_CACHE_MASK0x000f
> +/* cache modes */
> +#define MSM_BO_CACHED0x0001
> +#define MSM_BO_WC0x0002
> +#define MSM_BO_UNCACHED  0x0004
> +
> +struct drm_msm_gem_new {
> +   uint64_t size;   /* in */
> +   uint32_t flags;  /* in, mask of MSM_BO_x */
> +   uint32_t handle; /* out */
> +};
> +
> +struct drm_msm_gem_info {
> +   uint32_t handle; /* in */
> +   uint32_t pad;
> +   uint64_t offset; /* out, offset to pass to mmap() */
> +};
> +
> +#define MSM_PREP_READ0x01
> +#define MSM_PREP_WRITE   0x02
> +#define MSM_PREP_NOSYNC  0x04
> +
> +struct drm_msm_gem_cpu_prep {
> +   uint32_t handle; /* in */
> +   uint32_t op; /* in, mask of MSM_PREP_x */
> +   struct timespec timeout; /* in, timeout (clock_monotonic abs time) */

this scares me, don't do this from what I can see, and the fact I have
to check to confirm it this ends up using a long, which changes size
on 32/64 bit.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> >From CEA-861:
> 
>   Data Byte 1, bit A0 indicates whether Active Format Data is present in
>   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
>   any of the AFD bits are set.
> 
> ie. if we want to set active_aspect, we need to set the
> active_info_valid bit to 1 as well.
> 
> Cc: Thierry Reding 
> Signed-off-by: Damien Lespiau 

Reviewed-by: Ville Syrj?l? 

But why don't we just kill active_info_valid and instead just
check active_aspect in hdmi_avi_infoframe_pack()?

> ---
>  drivers/gpu/drm/drm_edid.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 95d6f4b..8d1139f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> hdmi_avi_infoframe *frame,
>   return 0;
>  
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> + frame->active_info_valid = 1;
>   frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
>  
>   return 0;
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

Re: [PATCH 1/4] drm/radeon: only save UVD bo when we have open handles

2013-08-05 Thread Alex Deucher

On Mon, Aug 5, 2013 at 8:10 AM, Christian König  wrote:
> From: Christian König 
>
> Otherwise just reinitialize from scratch on resume,
> and so make it more likely to succeed.
>
> Signed-off-by: Christian König 
> Cc: sta...@vger.kernel.org

Pulled the series into my -fixes branch.

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c  |2 +-
>  drivers/gpu/drm/radeon/radeon.h   |2 +-
>  drivers/gpu/drm/radeon/radeon_fence.c |2 +-
>  drivers/gpu/drm/radeon/radeon_uvd.c   |   46 
> +++--
>  drivers/gpu/drm/radeon/rv770.c|2 +-
>  5 files changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 524db70..ecb883d 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -6979,7 +6979,7 @@ int cik_uvd_resume(struct radeon_device *rdev)
>
> /* programm the VCPU memory controller bits 0-27 */
> addr = rdev->uvd.gpu_addr >> 3;
> -   size = RADEON_GPU_PAGE_ALIGN(rdev->uvd.fw_size + 4) >> 3;
> +   size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 4) >> 3;
> WREG32(UVD_VCPU_CACHE_OFFSET0, addr);
> WREG32(UVD_VCPU_CACHE_SIZE0, size);
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 2f08219..76dbe8e 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1468,7 +1468,6 @@ struct radeon_uvd {
> void*cpu_addr;
> uint64_tgpu_addr;
> void*saved_bo;
> -   unsignedfw_size;
> atomic_thandles[RADEON_MAX_UVD_HANDLES];
> struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
> struct delayed_work idle_work;
> @@ -2066,6 +2065,7 @@ struct radeon_device {
> const struct firmware *mec_fw;  /* CIK MEC firmware */
> const struct firmware *sdma_fw; /* CIK SDMA firmware */
> const struct firmware *smc_fw;  /* SMC firmware */
> +   const struct firmware *uvd_fw;  /* UVD firmware */
> struct r600_blit r600_blit;
> struct r600_vram_scratch vram_scratch;
> int msi_enabled; /* msi enabled */
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 7ddb0ef..ddb8f8e 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -782,7 +782,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
> *rdev, int ring)
>
> } else {
> /* put fence directly behind firmware */
> -   index = ALIGN(rdev->uvd.fw_size, 8);
> +   index = ALIGN(rdev->uvd_fw->size, 8);
> rdev->fence_drv[ring].cpu_addr = rdev->uvd.cpu_addr + 
> index;
> rdev->fence_drv[ring].gpu_addr = rdev->uvd.gpu_addr + 
> index;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 414fd14..ca0d735 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -56,7 +56,6 @@ static void radeon_uvd_idle_work_handler(struct work_struct 
> *work);
>
>  int radeon_uvd_init(struct radeon_device *rdev)
>  {
> -   const struct firmware *fw;
> unsigned long bo_size;
> const char *fw_name;
> int i, r;
> @@ -105,14 +104,14 @@ int radeon_uvd_init(struct radeon_device *rdev)
> return -EINVAL;
> }
>
> -   r = request_firmware(&fw, fw_name, rdev->dev);
> +   r = request_firmware(&rdev->uvd_fw, fw_name, rdev->dev);
> if (r) {
> dev_err(rdev->dev, "radeon_uvd: Can't load firmware \"%s\"\n",
> fw_name);
> return r;
> }
>
> -   bo_size = RADEON_GPU_PAGE_ALIGN(fw->size + 8) +
> +   bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 8) +
>   RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE;
> r = radeon_bo_create(rdev, bo_size, PAGE_SIZE, true,
>  RADEON_GEM_DOMAIN_VRAM, NULL, 
> &rdev->uvd.vcpu_bo);
> @@ -145,12 +144,6 @@ int radeon_uvd_init(struct radeon_device *rdev)
>
> radeon_bo_unreserve(rdev->uvd.vcpu_bo);
>
> -   rdev->uvd.fw_size = fw->size;
> -   memset(rdev->uvd.cpu_addr, 0, bo_size);
> -   memcpy(rdev->uvd.cpu_addr, fw->data, fw->size);
> -
> -   release_firmware(fw);
> -
> for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
> atomic_set(&rdev->uvd.handles[i], 0);
> rdev->uvd.filp[i] = NULL;
> @@ -174,33 +167,60 @@ void radeon_uvd_fini(struct radeon_device *rdev)
> }
>
> radeon_bo_unref(&rdev->uvd.vcpu_bo);
> +
> +   release_firmware(rdev->uvd_fw);
>  }
>
>  int radeon_uvd_suspend(struct radeon_device *rdev)
>  {
> unsigned size;
> +   void *

[PATCH] dma-buf: Expose buffer size to userspace

2013-08-05 Thread Christopher James Halse Rogers

Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.

Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.

Signed-off-by: Christopher James Halse Rogers 
---

I've run into a point in the radeon DRM userspace where I need the
size of a dma-buf. I could add a radeon-specific mechanism to get that,
but this seems like something that would be more generally useful.

I'm not entirely sure about supporting both SEEK_END and SEEK_CUR; this
is somewhat of an abuse of lseek, as seeking obviously doesn't make sense.
It's the obivous idiom for getting the size of what's on the other end of a
file descriptor, though.

I didn't notice anywhere to document this; Documentation/dma-buf-api didn't
seem like the right place. Is there somewhere I've overlooked?

 drivers/base/dma-buf.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 6687ba7..c33a857 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,9 +77,36 @@ static int dma_buf_mmap_internal(struct file *file, struct 
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
 }

+static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
+{
+   struct dma_buf *dmabuf;
+   loff_t base;
+
+   if (!is_dma_buf_file(file))
+   return -EBADF;
+
+   dmabuf = file->private_data;
+
+   /* only support discovering the end of the buffer,
+  but also allow SEEK_SET to maintain the idiomatic
+  SEEK_END(0), SEEK_CUR(0) pattern */
+   if (whence == SEEK_END)
+   base = dmabuf->size;
+   else if (whence == SEEK_SET)
+   base = 0;
+   else
+   return -EINVAL;
+
+   if (offset != 0)
+   return -EINVAL;
+
+   return base + offset;
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
+   .llseek = dma_buf_llseek,
 };

 /*
@@ -133,6 +160,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->exp_name = exp_name;

file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
+   file->f_mode |= FMODE_LSEEK;

dmabuf->file = file;

-- 
1.8.3.2

[PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb

2013-08-05 Thread Tomasz Figa

On Monday 05 of August 2013 15:14:42 Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> 
> To address the case where physically continous memory MAY NOT be a
> mandatory requirement for fb, the patch adds a feature to get non
> physically continous memory for fb if IOMMU is supported and if CONTIG
> memory allocation fails.
> 
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Arun Kumar 
> ---
> changes since v1:
>- Modified to add the fallback patch if CONTIG alloc fails as suggested
> by Rob Clark robdclark at gmail.com and Tomasz Figa
> .
> 
>- changed the commit message.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..9a4b886
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> @@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper,
> 
>   size = mode_cmd.pitches[0] * mode_cmd.height;
> 
> - /* 0 means to allocate physically continuous memory */
> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> + exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);

You can put the fallback here like this:
if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
/*
 * If IOMMU is supported then try to get buffer from
 * non-continous memory area
 */
dev_warn(&pdev->dev, "contiguous FB allocation failed, falling 
back to non-contiguous\n");
exynos_gem_obj = exynos_drm_gem_create(dev,

EXYNOS_BO_NONCONTIG, size);
}

>   if (IS_ERR(exynos_gem_obj)) {
> - ret = PTR_ERR(exynos_gem_obj);
> - goto err_release_framebuffer;

And then you can leave this original check untouched, reducing the
diffstat and unnecessary code indentation.

> + /*
> +  * If IOMMU is supported then try to get buffer from
> +  * non-continous memory area
> +  */
> + if (is_drm_iommu_supported(dev))
> + exynos_gem_obj = exynos_drm_gem_create(dev,
> + EXYNOS_BO_NONCONTIG, size);
> + if (IS_ERR(exynos_gem_obj)) {
> + ret = PTR_ERR(exynos_gem_obj);
> + goto err_release_framebuffer;
> + }
> + dev_warn(&pdev->dev, "exynos_gem_obj for FB is allocated with\n"
> + "non physically continuous memory\n");

Please don't split messages into multiple lines, because this makes
grepping for them harder (and checkpatch complains).

Best regards,
Tomasz

i915 INFO: trying to register non-static key.

On Mon, Aug 05, 2013 at 03:27:29PM +0200, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 03:23:53PM +0200, Johannes Stezenbach wrote:
> > wrt to $Subject, I get this with 3.10.5:
> > 
> > [4.342638] i915 :00:02.0: setting latency timer to 64
> > [4.409045] INFO: trying to register non-static key.
> > [4.409164] the code is fine but needs lockdep annotation.
> > [4.409278] turning off the locking correctness validator.
> > [4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1
> > [4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 
> > 09/11/2012
> > [4.409690]  0001 8802121559e0 816b265c 
> > 880212155a50
> > [4.410050]  8109ba03 822cd1c0  
> > 00010006
> > [4.410408]     
> > 8802121587a8
> 
> Looks similar to what I'm seeing. Can you cherry-pick
> 
> commit e1b4d3036c07ff137955fb1c0197ab62534f46ec
> Author: Ben Widawsky 
> Date:   Tue Jul 30 16:27:57 2013 -0700
> 
> drm/i915: fix missed hunk after GT access breakage
> 
> ontop of 3.10-stable?

This is already in 3.10.5 as commit c9af307d38974264922d35c77bb71087d171f8f8.

Thanks,
Johannes

Re: [PATCH] drm/i915: add fast boot support for Haswell

2013-08-05 Thread Jesse Barnes

On Thu,  1 Aug 2013 14:12:22 -0700
Furquan Shaikh  wrote:

> @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct intel_encoder 
> *encoder,
>   flags |= DRM_MODE_FLAG_NVSYNC;
>  
>   pipe_config->adjusted_mode.flags |= flags;
> +
> + if (port == PORT_A) {
> + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) == DP_PLL_FREQ_160MHZ)
> + pipe_config->port_clock = 162000;
> + else
> + pipe_config->port_clock = 27;
> + }

Sorry Furquan, I should have checked this earlier, I knew it was too
good to be true. :)

On HSW, DP_A is actually DDI_BUF_CTL, and it has a different layout
than the old DP_A reg.  Like Daniel said, doing it the old way is
invalid on HSW.  It might work in your configs, but I think that's just
coincidence, since bit 16 is the port reversal bit on HSW, not the
clock freq.

To get the clock freq, you need to look at 0x45020 to find the refclk,
then look at the WRPLL_CTL for the pipe to get the dividers.  That's
what Daniel meant when he asked for a full "clock_get" function.  It's
only a little more complicated, but you'll need docs for it.  Charlie
Huang ought to be able to get you the NDA docs that should have the
info you need.

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

[PATCH] drm/i915: add fast boot support for Haswell

2013-08-05 Thread Jesse Barnes

On Thu,  1 Aug 2013 14:12:22 -0700
Furquan Shaikh  wrote:

> @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct intel_encoder 
> *encoder,
>   flags |= DRM_MODE_FLAG_NVSYNC;
>  
>   pipe_config->adjusted_mode.flags |= flags;
> +
> + if (port == PORT_A) {
> + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) == DP_PLL_FREQ_160MHZ)
> + pipe_config->port_clock = 162000;
> + else
> + pipe_config->port_clock = 27;
> + }

Sorry Furquan, I should have checked this earlier, I knew it was too
good to be true. :)

On HSW, DP_A is actually DDI_BUF_CTL, and it has a different layout
than the old DP_A reg.  Like Daniel said, doing it the old way is
invalid on HSW.  It might work in your configs, but I think that's just
coincidence, since bit 16 is the port reversal bit on HSW, not the
clock freq.

To get the clock freq, you need to look at 0x45020 to find the refclk,
then look at the WRPLL_CTL for the pipe to get the dividers.  That's
what Daniel meant when he asked for a full "clock_get" function.  It's
only a little more complicated, but you'll need docs for it.  Charlie
Huang ought to be able to get you the NDA docs that should have the
info you need.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

i915 INFO: trying to register non-static key.

2013-08-05 Thread Borislav Petkov

On Mon, Aug 05, 2013 at 03:23:53PM +0200, Johannes Stezenbach wrote:
> wrt to $Subject, I get this with 3.10.5:
> 
> [4.342638] i915 :00:02.0: setting latency timer to 64
> [4.409045] INFO: trying to register non-static key.
> [4.409164] the code is fine but needs lockdep annotation.
> [4.409278] turning off the locking correctness validator.
> [4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1
> [4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 
> 09/11/2012
> [4.409690]  0001 8802121559e0 816b265c 
> 880212155a50
> [4.410050]  8109ba03 822cd1c0  
> 00010006
> [4.410408]     
> 8802121587a8

Looks similar to what I'm seeing. Can you cherry-pick

commit e1b4d3036c07ff137955fb1c0197ab62534f46ec
Author: Ben Widawsky 
Date:   Tue Jul 30 16:27:57 2013 -0700

drm/i915: fix missed hunk after GT access breakage

ontop of 3.10-stable?

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

i915 INFO: trying to register non-static key.

Hi,

wrt to $Subject, I get this with 3.10.5:

[4.342638] i915 :00:02.0: setting latency timer to 64
[4.409045] INFO: trying to register non-static key.
[4.409164] the code is fine but needs lockdep annotation.
[4.409278] turning off the locking correctness validator.
[4.409396] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.5 #1
[4.409514] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET82WW (2.02 ) 
09/11/2012
[4.409690]  0001 8802121559e0 816b265c 
880212155a50
[4.410050]  8109ba03 822cd1c0  
00010006
[4.410408]     
8802121587a8
[4.410764] Call Trace:
[4.410880]  [] dump_stack+0x19/0x1b
[4.411000]  [] __lock_acquire.isra.23+0x7f7/0xb9c
[4.411120]  [] lock_acquire+0xc0/0x142
[4.411240]  [] ? i915_write32+0x99/0x13a
[4.411360]  [] _raw_spin_lock_irqsave+0x57/0x8e
[4.411481]  [] ? i915_write32+0x99/0x13a
[4.411599]  [] i915_write32+0x99/0x13a
[4.411718]  [] intel_disable_gt_powersave+0x264/0x2e5
[4.411839]  [] intel_gt_sanitize+0x91/0x93
[4.411956]  [] i915_driver_load+0x6e7/0xca5
[4.412080]  [] ? drm_get_minor+0x1d4/0x22e
[4.412199]  [] drm_get_pci_dev+0x169/0x269
[4.412319]  [] ? _raw_spin_unlock_irqrestore+0x5b/0x79
[4.412440]  [] i915_pci_probe+0x66/0x6f
[4.412557]  [] pci_device_probe+0x6e/0xb2
[4.412679]  [] driver_probe_device+0x11a/0x2e2
[4.412799]  [] __driver_attach+0x61/0x83
[4.412918]  [] ? __device_attach+0x3d/0x3d
[4.413039]  [] bus_for_each_dev+0x7d/0x87
[4.413158]  [] driver_attach+0x1e/0x20
[4.413278]  [] bus_add_driver+0x128/0x233
[4.413397]  [] driver_register+0x8c/0xfd
[4.413515]  [] __pci_register_driver+0x5d/0x60
[4.413637]  [] ? 
ftrace_define_fields_drm_vblank_event_delivered+0x9a/0x9a
[4.413818]  [] drm_pci_init+0x86/0xea
[4.413936]  [] ? 
ftrace_define_fields_drm_vblank_event_delivered+0x9a/0x9a
[4.414117]  [] i915_init+0x66/0x68
[4.414235]  [] do_one_initcall+0xa0/0x13f
[4.414355]  [] kernel_init_freeable+0x115/0x196
[4.414475]  [] ? do_early_param+0x88/0x88
[4.414594]  [] ? rest_init+0xc2/0xc2
[4.414711]  [] kernel_init+0xe/0xd6
[4.414828]  [] ret_from_fork+0x7c/0xb0
[4.414946]  [] ? rest_init+0xc2/0xc2
[4.422529] i915 :00:02.0: irq 40 for MSI/MSI-X

If you have a fix for it please send it to stable.

Thanks,
Johannes

[PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb

While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0

To address the case where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non physically
continous memory for fb if IOMMU is supported and if CONTIG memory allocation
fails.

Signed-off-by: Vikas Sajjan 
Signed-off-by: Arun Kumar 
---
changes since v1:
 - Modified to add the fallback patch if CONTIG alloc fails as suggested
 by Rob Clark robdclark at gmail.com and Tomasz Figa .

 - changed the commit message.
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..9a4b886 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "exynos_drm_drv.h"
 #include "exynos_drm_fb.h"
@@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,

size = mode_cmd.pitches[0] * mode_cmd.height;

-   /* 0 means to allocate physically continuous memory */
-   exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
if (IS_ERR(exynos_gem_obj)) {
-   ret = PTR_ERR(exynos_gem_obj);
-   goto err_release_framebuffer;
+   /*
+* If IOMMU is supported then try to get buffer from
+* non-continous memory area
+*/
+   if (is_drm_iommu_supported(dev))
+   exynos_gem_obj = exynos_drm_gem_create(dev,
+   EXYNOS_BO_NONCONTIG, size);
+   if (IS_ERR(exynos_gem_obj)) {
+   ret = PTR_ERR(exynos_gem_obj);
+   goto err_release_framebuffer;
+   }
+   dev_warn(&pdev->dev, "exynos_gem_obj for FB is allocated with\n"
+   "non physically continuous memory\n");
}

exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
-- 
1.7.9.5

[PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 04:54:06PM +0300, Ville Syrj?l? wrote:
> On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> > >From CEA-861:
> > 
> >   Data Byte 1, bit A0 indicates whether Active Format Data is present in
> >   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
> >   any of the AFD bits are set.
> > 
> > ie. if we want to set active_aspect, we need to set the
> > active_info_valid bit to 1 as well.
> > 
> > Cc: Thierry Reding 
> > Signed-off-by: Damien Lespiau 
> 
> Reviewed-by: Ville Syrj?l? 
> 
> But why don't we just kill active_info_valid and instead just
> check active_aspect in hdmi_avi_infoframe_pack()?

Right, so I thought about that, I'd love to have an API that doesn't
allow its user to do something wrong. My reflections so far:

 1/ I did not want to depend on a fix that was outside of the drm/
 directory for people that pull that directory between different
 kernels, they will end up missing the patch in video/hdmi.c.

 On the other hand, we could just tell people to sync
 drivers/video/hdmi.c and include/linux/hdmi.h along with drm/.

 2/ I was thinking that killing the _valid bits in the
 hdmi_avi_infoframe struct would not allow an _unpack() function that
 can check if the infoframe was valid.

Probably thinking too much though...

-- 
Damien

[PATCH] drm: const'ify ioctls table (v2)

On Fri, Aug 02, 2013 at 01:27:49PM -0400, Rob Clark wrote:
> Because, there is no reason for it not to be const.
> 
> v1: original
> v2: fix compile break in vmwgfx, and couple related cleanups suggested
> by Ville Syrj?l?
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Ville Syrj?l? 

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

>From CEA-861:

  Data Byte 1, bit A0 indicates whether Active Format Data is present in
  Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
  any of the AFD bits are set.

ie. if we want to set active_aspect, we need to set the
active_info_valid bit to 1 as well.

Cc: Thierry Reding 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_edid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95d6f4b..8d1139f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
return 0;

frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   frame->active_info_valid = 1;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;

return 0;
-- 
1.8.3.1

[Bug 67283] VDPAU doesn't work on hybrid laptop through DRI_PRIME

https://bugs.freedesktop.org/show_bug.cgi?id=67283

--- Comment #13 from sfievet  ---
would these patches work for a "muxed" hybrid laptop as well ? 
Otherwise, what would be needed to have libvdpau automatically pick up the
right driver on muxed systems ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/d427224d/attachment.html>

[PATCH 4/4] drm/radeon: remove unnecessary unpin

From: Christian K?nig 

We don't pin the BO on allocation, so don't unpin it on free.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gart.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 6a51d94..b990b1a 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -207,7 +207,6 @@ void radeon_gart_table_vram_free(struct radeon_device *rdev)
if (rdev->gart.robj == NULL) {
return;
}
-   radeon_gart_table_vram_unpin(rdev);
radeon_bo_unref(&rdev->gart.robj);
 }

-- 
1.7.9.5

[PATCH 3/4] drm/radeon: add more UVD CS checking

From: Christian K?nig 

Improve error handling in case userspace sends us
an invalid command buffer.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_uvd.c |   43 ---
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 4fec195..f1c1575 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -357,8 +357,10 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, 
struct radeon_bo *bo,
}

r = radeon_bo_kmap(bo, &ptr);
-   if (r)
+   if (r) {
+   DRM_ERROR("Failed mapping the UVD message (%d)!\n", r);
return r;
+   }

msg = ptr + offset;

@@ -384,8 +386,14 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, 
struct radeon_bo *bo,
radeon_bo_kunmap(bo);
return 0;
} else {
-   /* it's a create msg, no special handling needed */
radeon_bo_kunmap(bo);
+
+   if (msg_type != 0) {
+   DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
+   return -EINVAL;
+   }
+
+   /* it's a create msg, no special handling needed */
}

/* create or decode, validate the handle */
@@ -408,7 +416,7 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, 
struct radeon_bo *bo,

 static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
   int data0, int data1,
-  unsigned buf_sizes[])
+  unsigned buf_sizes[], bool *has_msg_cmd)
 {
struct radeon_cs_chunk *relocs_chunk;
struct radeon_cs_reloc *reloc;
@@ -437,7 +445,7 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,

if (cmd < 0x4) {
if ((end - start) < buf_sizes[cmd]) {
-   DRM_ERROR("buffer to small (%d / %d)!\n",
+   DRM_ERROR("buffer (%d) to small (%d / %d)!\n", cmd,
  (unsigned)(end - start), buf_sizes[cmd]);
return -EINVAL;
}
@@ -462,9 +470,17 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
}

if (cmd == 0) {
+   if (*has_msg_cmd) {
+   DRM_ERROR("More than one message in a UVD-IB!\n");
+   return -EINVAL;
+   }
+   *has_msg_cmd = true;
r = radeon_uvd_cs_msg(p, reloc->robj, offset, buf_sizes);
if (r)
return r;
+   } else if (!*has_msg_cmd) {
+   DRM_ERROR("Message needed before other commands are send!\n");
+   return -EINVAL;
}

return 0;
@@ -473,7 +489,8 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
 static int radeon_uvd_cs_reg(struct radeon_cs_parser *p,
 struct radeon_cs_packet *pkt,
 int *data0, int *data1,
-unsigned buf_sizes[])
+unsigned buf_sizes[],
+bool *has_msg_cmd)
 {
int i, r;

@@ -487,7 +504,8 @@ static int radeon_uvd_cs_reg(struct radeon_cs_parser *p,
*data1 = p->idx;
break;
case UVD_GPCOM_VCPU_CMD:
-   r = radeon_uvd_cs_reloc(p, *data0, *data1, buf_sizes);
+   r = radeon_uvd_cs_reloc(p, *data0, *data1,
+   buf_sizes, has_msg_cmd);
if (r)
return r;
break;
@@ -508,6 +526,9 @@ int radeon_uvd_cs_parse(struct radeon_cs_parser *p)
struct radeon_cs_packet pkt;
int r, data0 = 0, data1 = 0;

+   /* does the IB has a msg command */
+   bool has_msg_cmd = false;
+
/* minimum buffer sizes */
unsigned buf_sizes[] = {
[0x]=   2048,
@@ -534,8 +555,8 @@ int radeon_uvd_cs_parse(struct radeon_cs_parser *p)
return r;
switch (pkt.type) {
case RADEON_PACKET_TYPE0:
-   r = radeon_uvd_cs_reg(p, &pkt, &data0,
- &data1, buf_sizes);
+   r = radeon_uvd_cs_reg(p, &pkt, &data0, &data1,
+ buf_sizes, &has_msg_cmd);
if (r)
return r;
break;
@@ -547,6 +568,12 @@ int radeon_uvd_cs_parse(struct radeon_cs_parser *p)
return -EINVAL;
}
} while (p->idx < p->chunks[p->chunk_ib_idx].length_dw);
+
+   if (!has_msg_cmd) {
+   DRM_ERROR("UVD-IBs need a msg command!\n")

[PATCH 2/4] drm/radeon: stop sending invalid UVD destroy msg

From: Christian K?nig 

We also need to check the handle.

Signed-off-by: Christian K?nig 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_uvd.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index ca0d735..4fec195 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -235,8 +235,8 @@ void radeon_uvd_free_handles(struct radeon_device *rdev, 
struct drm_file *filp)
 {
int i, r;
for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
-   if (rdev->uvd.filp[i] == filp) {
-   uint32_t handle = atomic_read(&rdev->uvd.handles[i]);
+   uint32_t handle = atomic_read(&rdev->uvd.handles[i]);
+   if (handle != 0 && rdev->uvd.filp[i] == filp) {
struct radeon_fence *fence;

r = radeon_uvd_get_destroy_msg(rdev,
-- 
1.7.9.5

[PATCH 1/4] drm/radeon: only save UVD bo when we have open handles

From: Christian K?nig 

Otherwise just reinitialize from scratch on resume,
and so make it more likely to succeed.

Signed-off-by: Christian K?nig 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h   |2 +-
 drivers/gpu/drm/radeon/radeon_fence.c |2 +-
 drivers/gpu/drm/radeon/radeon_uvd.c   |   46 +++--
 drivers/gpu/drm/radeon/rv770.c|2 +-
 5 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 524db70..ecb883d 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6979,7 +6979,7 @@ int cik_uvd_resume(struct radeon_device *rdev)

/* programm the VCPU memory controller bits 0-27 */
addr = rdev->uvd.gpu_addr >> 3;
-   size = RADEON_GPU_PAGE_ALIGN(rdev->uvd.fw_size + 4) >> 3;
+   size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 4) >> 3;
WREG32(UVD_VCPU_CACHE_OFFSET0, addr);
WREG32(UVD_VCPU_CACHE_SIZE0, size);

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 2f08219..76dbe8e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1468,7 +1468,6 @@ struct radeon_uvd {
void*cpu_addr;
uint64_tgpu_addr;
void*saved_bo;
-   unsignedfw_size;
atomic_thandles[RADEON_MAX_UVD_HANDLES];
struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
struct delayed_work idle_work;
@@ -2066,6 +2065,7 @@ struct radeon_device {
const struct firmware *mec_fw;  /* CIK MEC firmware */
const struct firmware *sdma_fw; /* CIK SDMA firmware */
const struct firmware *smc_fw;  /* SMC firmware */
+   const struct firmware *uvd_fw;  /* UVD firmware */
struct r600_blit r600_blit;
struct r600_vram_scratch vram_scratch;
int msi_enabled; /* msi enabled */
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7ddb0ef..ddb8f8e 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -782,7 +782,7 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)

} else {
/* put fence directly behind firmware */
-   index = ALIGN(rdev->uvd.fw_size, 8);
+   index = ALIGN(rdev->uvd_fw->size, 8);
rdev->fence_drv[ring].cpu_addr = rdev->uvd.cpu_addr + 
index;
rdev->fence_drv[ring].gpu_addr = rdev->uvd.gpu_addr + 
index;
}
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 414fd14..ca0d735 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -56,7 +56,6 @@ static void radeon_uvd_idle_work_handler(struct work_struct 
*work);

 int radeon_uvd_init(struct radeon_device *rdev)
 {
-   const struct firmware *fw;
unsigned long bo_size;
const char *fw_name;
int i, r;
@@ -105,14 +104,14 @@ int radeon_uvd_init(struct radeon_device *rdev)
return -EINVAL;
}

-   r = request_firmware(&fw, fw_name, rdev->dev);
+   r = request_firmware(&rdev->uvd_fw, fw_name, rdev->dev);
if (r) {
dev_err(rdev->dev, "radeon_uvd: Can't load firmware \"%s\"\n",
fw_name);
return r;
}

-   bo_size = RADEON_GPU_PAGE_ALIGN(fw->size + 8) +
+   bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 8) +
  RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE;
r = radeon_bo_create(rdev, bo_size, PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM, NULL, &rdev->uvd.vcpu_bo);
@@ -145,12 +144,6 @@ int radeon_uvd_init(struct radeon_device *rdev)

radeon_bo_unreserve(rdev->uvd.vcpu_bo);

-   rdev->uvd.fw_size = fw->size;
-   memset(rdev->uvd.cpu_addr, 0, bo_size);
-   memcpy(rdev->uvd.cpu_addr, fw->data, fw->size);
-
-   release_firmware(fw);
-
for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
atomic_set(&rdev->uvd.handles[i], 0);
rdev->uvd.filp[i] = NULL;
@@ -174,33 +167,60 @@ void radeon_uvd_fini(struct radeon_device *rdev)
}

radeon_bo_unref(&rdev->uvd.vcpu_bo);
+
+   release_firmware(rdev->uvd_fw);
 }

 int radeon_uvd_suspend(struct radeon_device *rdev)
 {
unsigned size;
+   void *ptr;
+   int i;

if (rdev->uvd.vcpu_bo == NULL)
return 0;

+   for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i)
+   if (atomic_read(&rdev->uvd.handles[i]))
+   break;
+
+   if (i == RADEON_MAX_UVD_HANDLES)
+   return 0;
+
size = radeon_bo_size(rdev->uvd

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey  wrote:
> Hi Rob,
>
> +linux-media, +linaro-mm-sig for discussion of video/camera
> buffer constraints...
>
>
>> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey 
>> wrote:
>> >> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >> >allocate buffers for the GPU. Still not sure how to resolve
>> >> >this as we don't use DRM for our GPU driver.
>> >>
>> >> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> >> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> >> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> >> using prime/dmabuf to share between the two.
>> >
>> > The "extra" buffers we were allocating from armsoc DDX were really
>> > being allocated through DRM/GEM so we could get an flink name
>> > for them and pass a reference to them back to our GPU driver on
>> > the client side. If it weren't for our need to access those
>> > extra off-screen buffers with the GPU we wouldn't need to
>> > allocate them with DRM at all. So, given they are really "GPU"
>> > buffers, it does absolutely make sense to allocate them in a
>> > different driver to the display driver.
>> >
>> > However, to avoid unnecessary memcpys & related cache
>> > maintenance ops, we'd also like the GPU to render into buffers
>> > which are scanned out by the display controller. So let's say
>> > we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
>> > out buffers with the display's DRM driver but a custom ioctl
>> > on the GPU's DRM driver to allocate non scanout, off-screen
>> > buffers. Sounds great, but I don't think that really works
>> > with DRI2. If we used two drivers to allocate buffers, which
>> > of those drivers do we return in DRI2ConnectReply? Even if we
>> > solve that somehow, GEM flink names are name-spaced to a
>> > single device node (AFAIK). So when we do a DRI2GetBuffers,
>> > how does the EGL in the client know which DRM device owns GEM
>> > flink name "1234"? We'd need some pretty dirty hacks.
>>
>> You would return the name of the display driver allocating the
>> buffers.  On the client side you can use generic ioctls to go from
>> flink -> handle -> dmabuf.  So the client side would end up opening
>> both the display drm device and the gpu, but without needing to know
>> too much about the display.
>
> I think the bit I was missing was that a GEM bo for a buffer imported
> using dma_buf/PRIME can still be flink'd. So the display controller's
> DRM driver allocates scan-out buffers via the DUMB buffer allocate
> ioctl. Those scan-out buffers than then be exported from the
> dispaly's DRM driver and imported into the GPU's DRM driver using
> PRIME. Once imported into the GPU's driver, we can use flink to get a
> name for that buffer within the GPU DRM driver's name-space to return
> to the DRI2 client. That same namespace is also what DRI2 back-buffers
> are allocated from, so I think that could work... Except...
>

(and.. the general direction is that things will move more to just use
dmabuf directly, ie. wayland or dri3)

>
>> > Anyway, that latter case also gets quite difficult. The "GPU"
>> > DRM driver would need to know the constraints of the display
>> > controller when allocating buffers intended to be scanned out.
>> > For example, pl111 typically isn't behind an IOMMU and so
>> > requires physically contiguous memory. We'd have to teach the
>> > GPU's DRM driver about the constraints of the display HW. Not
>> > exactly a clean driver model. :-(
>> >
>> > I'm still a little stuck on how to proceed, so any ideas
>> > would greatly appreciated! My current train of thought is
>> > having a kind of SoC-specific DRM driver which allocates
>> > buffers for both display and GPU within a single GEM
>> > namespace. That SoC-specific DRM driver could then know the
>> > constraints of both the GPU and the display HW. We could then
>> > use PRIME to export buffers allocated with the SoC DRM driver
>> > and import them into the GPU and/or display DRM driver.
>>
>> Usually if the display drm driver is allocating the buffers that might
>> be scanned out, it just needs to have minimal knowledge of the GPU
>> (pitch alignment constraints).  I don't think we need a 3rd device
>> just to allocate buffers.
>
> While Mali can render to pretty much any buffer, there is a mild
> performance improvement to be had if the buffer stride is aligned to
> the AXI bus's max burst length when drawing to the buffer.

I suspect the display controllers might frequently benefit if the
pitch is aligned to AXI burst length too..

> So in some respects, there is a constraint on how buffers which will
> be drawn to using the GPU are allocated. I don't really like the idea
> of teaching the display controller DRM driver about the GPU buffer
> constraints, even if they are fairly trivial like this. If the same
> display HW IP is being used on several SoCs, it seems wrong somehow
> to enforce those GPU constr

Re: [Intel-gfx] [PATCH] drm/i915: add fast boot support for Haswell

[Now without the confidential header which shouldn't have spilled to
public lists, please reply to this one here.]

On Mon, Aug 05, 2013 at 01:24:15PM -0700, Furquan Shaikh wrote:
> We tested the submitted patch on several systems here and it seems to be
> working fine. So, I'm not sure I understand your comment. Can you please
> provide more details?

You check for the bit DP_PLL_FREQ_160MHZ in the register DP_A when
calculating the reference frequence for port A eDP panels (i.e. the
assignement of pipe_config->port_clock). This bit is valid on port A
for ivb, snb & ilk, but not on hsw. Haswell has a complete new way for
assigning the pll to the port. For solid fastboot support I think we
need to support them all (i.e. also the hdmi wrpll clocks and while at
it we might as well write the fdi dotclock readout code, it should be
almost the same as the DP dotclock computation).
-Daniel

> 
> Thanks,
> Furquan
> 
> 
> On Mon, Aug 5, 2013 at 12:24 AM, Daniel Vetter  wrote:
> 
> > On Thu, Aug 01, 2013 at 02:12:22PM -0700, Furquan Shaikh wrote:
> > > Enables getting correct mode clock when reading pipe config
> > >
> > > Signed-off-by: Furquan Shaikh 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 8 
> > >  drivers/gpu/drm/i915/intel_display.c | 9 -
> > >  2 files changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 931b4bb..fa0af9b 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct
> > intel_encoder *encoder,
> > >   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > >   enum transcoder cpu_transcoder = intel_crtc->config.cpu_transcoder;
> > > + int port = intel_ddi_get_encoder_port(encoder);
> > >   u32 temp, flags = 0;
> > >
> > >   temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > > @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct
> > intel_encoder *encoder,
> > >   flags |= DRM_MODE_FLAG_NVSYNC;
> > >
> > >   pipe_config->adjusted_mode.flags |= flags;
> > > +
> > > + if (port == PORT_A) {
> > > + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) ==
> > DP_PLL_FREQ_160MHZ)
> > > + pipe_config->port_clock = 162000;
> > > + else
> > > + pipe_config->port_clock = 27;
> > > + }
> >
> > I don't think this works correctly since for DP we have new clocks on
> > haswell, see intel_ddi_pll_mode_set. Also I think it'd be good to go right
> > ahead and implement clock readout support for all hsw clock sources, not
> > just DP.
> > -Daniel
> >
> > >  }
> > >
> > >  static void intel_ddi_destroy(struct drm_encoder *encoder)
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > > index 3e66f05..681c99a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct intel_crtc
> > *crtc,
> > >   pipe_config->pixel_multiplier;
> > >  }
> > >
> > > +#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
> > > +
> > >  static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
> > >   struct intel_crtc_config *pipe_config)
> > >  {
> > > @@ -7218,7 +7220,11 @@ static void ironlake_crtc_clock_get(struct
> > intel_crtc *crtc,
> > >   return;
> > >
> > >   clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
> > > - do_div(clock, link_n);
> > > + /* This is required because the value comes out to be in fraction
> > > +(eg. 70699.54). Need to round it up since values are compared in
> > > +drm_mode_equal
> > > + */
> > > + clock = div_ceil(clock, link_n);
> > >
> > >   pipe_config->adjusted_mode.clock = clock;
> > >  }
> > > @@ -9588,6 +9594,7 @@ static void intel_init_display(struct drm_device
> > *dev)
> > >
> > >   if (HAS_DDI(dev)) {
> > >   dev_priv->display.get_pipe_config =
> > haswell_get_pipe_config;
> > > + dev_priv->display.get_clock = ironlake_crtc_clock_get;
> > >   dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> > >   dev_priv->display.crtc_enable = haswell_crtc_enable;
> > >   dev_priv->display.crtc_disable = haswell_crtc_disable;
> > > --
> > > 1.8.3
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >

> ___
> Intel-gfx mailing list
> intel-.

[PATCH] drm/i915: add fast boot support for Haswell

2013-08-05 Thread Furquan Shaikh

We tested the submitted patch on several systems here and it seems to be
working fine. So, I'm not sure I understand your comment. Can you please
provide more details?

Thanks,
Furquan


On Mon, Aug 5, 2013 at 12:24 AM, Daniel Vetter  wrote:

> On Thu, Aug 01, 2013 at 02:12:22PM -0700, Furquan Shaikh wrote:
> > Enables getting correct mode clock when reading pipe config
> >
> > Signed-off-by: Furquan Shaikh 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 8 
> >  drivers/gpu/drm/i915/intel_display.c | 9 -
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> > index 931b4bb..fa0af9b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct
> intel_encoder *encoder,
> >   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> >   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> >   enum transcoder cpu_transcoder = intel_crtc->config.cpu_transcoder;
> > + int port = intel_ddi_get_encoder_port(encoder);
> >   u32 temp, flags = 0;
> >
> >   temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > @@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct
> intel_encoder *encoder,
> >   flags |= DRM_MODE_FLAG_NVSYNC;
> >
> >   pipe_config->adjusted_mode.flags |= flags;
> > +
> > + if (port == PORT_A) {
> > + if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) ==
> DP_PLL_FREQ_160MHZ)
> > + pipe_config->port_clock = 162000;
> > + else
> > + pipe_config->port_clock = 27;
> > + }
>
> I don't think this works correctly since for DP we have new clocks on
> haswell, see intel_ddi_pll_mode_set. Also I think it'd be good to go right
> ahead and implement clock readout support for all hsw clock sources, not
> just DP.
> -Daniel
>
> >  }
> >
> >  static void intel_ddi_destroy(struct drm_encoder *encoder)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> > index 3e66f05..681c99a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct intel_crtc
> *crtc,
> >   pipe_config->pixel_multiplier;
> >  }
> >
> > +#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
> > +
> >  static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
> >   struct intel_crtc_config *pipe_config)
> >  {
> > @@ -7218,7 +7220,11 @@ static void ironlake_crtc_clock_get(struct
> intel_crtc *crtc,
> >   return;
> >
> >   clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
> > - do_div(clock, link_n);
> > + /* This is required because the value comes out to be in fraction
> > +(eg. 70699.54). Need to round it up since values are compared in
> > +drm_mode_equal
> > + */
> > + clock = div_ceil(clock, link_n);
> >
> >   pipe_config->adjusted_mode.clock = clock;
> >  }
> > @@ -9588,6 +9594,7 @@ static void intel_init_display(struct drm_device
> *dev)
> >
> >   if (HAS_DDI(dev)) {
> >   dev_priv->display.get_pipe_config =
> haswell_get_pipe_config;
> > + dev_priv->display.get_clock = ironlake_crtc_clock_get;
> >   dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> >   dev_priv->display.crtc_enable = haswell_crtc_enable;
> >   dev_priv->display.crtc_disable = haswell_crtc_disable;
> > --
> > 1.8.3
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/b58b/attachment-0001.html>

[Bug 67723] Resume from s2ram fails with [drm:r600_uvd_init] ERROR UVD not responding, trying to reset the VCPU!!!

https://bugs.freedesktop.org/show_bug.cgi?id=67723

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 67187 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/7c781b38/attachment.html>

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

https://bugs.freedesktop.org/show_bug.cgi?id=67187

Alex Deucher  changed:

   What|Removed |Added

 CC||bastian.triller at gmail.com

--- Comment #11 from Alex Deucher  ---
*** Bug 67723 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/87745c92/attachment.html>

[Bug 60691] [radeon HD5450 ] UVD don't work after resume from hibernate

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60691

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Looks like a duplicate of:
https://bugs.freedesktop.org/show_bug.cgi?id=67187

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 67790] New: error message on suspend: ERROR Could not force DPM to low

https://bugs.freedesktop.org/show_bug.cgi?id=67790

  Priority: medium
Bug ID: 67790
  Assignee: dri-devel at lists.freedesktop.org
   Summary: error message on suspend: *ERROR* Could not force DPM
to low
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: johannes.hirte at fem.tu-ilmenau.de
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

On suspend dmesg shows the following error message:

[  236.137036] PM: Syncing filesystems ... done.
[  236.673588] Freezing user space processes ... (elapsed 0.007 seconds) done.
[  236.680901] Freezing remaining freezable tasks ... (elapsed 0.000 seconds)
done.
[  236.681975] Suspending console(s) (use no_console_suspend to debug)
[  236.693223] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  236.695019] sd 0:0:0:0: [sda] Stopping disk
[  237.336598] [drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.
[  239.009616] radeon :01:00.0: power state changed by ACPI to D3cold
[  239.009696] PM: suspend of devices complete after 2315.934 msecs
[  239.009861] PM: late suspend of devices complete after 0.162 msecs

I've not seen any problems, suspend and resume worked correct so far.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/77e48f66/attachment.html>

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #8 from Gabor Hasenfrasz  ---
Created attachment 107105
  --> https://bugzilla.kernel.org/attachment.cgi?id=107105&action=edit
avivotool regs hdmi output on kernel 3.10

This is with radeon.audio=1 kernel parameter with kernel 3.10.3

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support (v3)

Add support for HDMI audio device on VGA cards that powerdown
to D3cold using non-standard ACPI/PCI infrastructure (optimus).

This does a couple of things to make it work:

a) add a set of power ops for the hdmi domain, and enables them
via vga_switcheroo when we are a switcheroo controlled card. This
just replaces the runtime resume operation so that when the card
is in D3cold the userspace pci config space access via sysfs,
the vga switcheroon runtime resume gets called first and it calls
the GPU resume callback before calling the sound card runtime
resume.

b) standard ACPI/PCI stacks won't put a device into D3cold without
an ACPI handle, but since the hdmi audio devices on gpus don't have
an ACPI handle, we need to manually force the device into D3cold
after suspend from the switcheroo path only.

c) don't try and do runtime s/r when the GPU is off.

d) call runtime suspend/resume during switcheroo suspend/resume
this is to make sure the runtime stack knows to try and resume
the hdmi audio device for pci config space access.

v2: fix incorrect runtime call suspend->resume.

v3: rework irq handler to avoid false irq when we are resuming
but haven't runtime resumed yet, don't bother trying D3cold,
it won't work, just set it manually ourselves, move runtime s/r
calls outside the main s/r hook. enable dnyamic pm properly by
dropping reference.

Signed-off-by: Dave Airlie 
---
 sound/pci/hda/hda_intel.c | 36 +---
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 8860dd5..4c4f546 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -555,6 +555,9 @@ struct azx {
 #ifdef CONFIG_SND_HDA_DSP_LOADER
struct azx_dev saved_azx_dev;
 #endif
+
+   /* secondary power domain for hdmi audio under vga device */
+   struct dev_pm_domain hdmi_pm_domain;
 };

 #define CREATE_TRACE_POINTS
@@ -1396,11 +1399,6 @@ static irqreturn_t azx_interrupt(int irq, void *dev_id)
u8 sd_status;
int i, ok;

-#ifdef CONFIG_PM_RUNTIME
-   if (chip->pci->dev.power.runtime_status != RPM_ACTIVE)
-   return IRQ_NONE;
-#endif
-
spin_lock(&chip->reg_lock);

if (chip->disabled) {
@@ -1409,7 +1407,7 @@ static irqreturn_t azx_interrupt(int irq, void *dev_id)
}

status = azx_readl(chip, INTSTS);
-   if (status == 0) {
+   if (status == 0 || status == 0x) {
spin_unlock(&chip->reg_lock);
return IRQ_NONE;
}
@@ -2971,6 +2969,12 @@ static int azx_runtime_suspend(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
+   if (!(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
+   return 0;
+
azx_stop_chip(chip);
azx_enter_link_reset(chip);
azx_clear_irq_pending(chip);
@@ -2984,6 +2988,12 @@ static int azx_runtime_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
+   if (!(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
+   return 0;
+
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
hda_display_power(true);
azx_init_pci(chip);
@@ -2996,6 +3006,9 @@ static int azx_runtime_idle(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip = card->private_data;

+   if (chip->disabled)
+   return 0;
+
if (!power_save_controller ||
!(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
return -EBUSY;
@@ -3078,13 +3091,19 @@ static void azx_vs_set_state(struct pci_dev *pci,
   "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
   disabled ? "Disabling" : "Enabling");
if (disabled) {
+   pm_runtime_put_sync_suspend(&pci->dev);
azx_suspend(&pci->dev);
+   /* when we get suspended by vga switcheroo we end up in 
D3cold,
+* however we have no ACPI handle, so pci/acpi can't 
put us there,
+* put ourselves there */
+   pci->current_state = PCI_D3cold;
chip->disabled = true;
if (snd_hda_lock_devices(chip->bus))
snd_printk(KERN_WARNING SFX "%s: Cannot lock 
devices!\n",
   pci_name(chip->pci));
} else {
snd_hda_unlock_devices(chip->bus);
+   pm_runtime_get_noresume(&pci->dev);
chip->disabled = false;
azx_resume(&pci->dev);
}
@@ -3139,6 +3158,9 @@ static int register_vga_swit

[PATCH 3/4] nouveau: add runtime PM support (v0.9)

From: Dave Airlie 

This hooks nouveau up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and optimus laptops.

a) rewrite suspend/resume printks to hide them during dynamic s/r
to avoid cluttering logs
b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
connector status,
c) handle hdmi audio dynamic power on/off using magic register.

v0.5:
make sure we hit D3 properly
fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
active crtcs/fbcon anyways.
add reference for active crtcs.
sprinkle mark last busy for autosuspend timeout

v0.6:
allow more flexible debugging - to avoid log spam
add option to enable/disable dynpm
got to D3Cold

v0.7:
add hdmi audio support.

v0.8:
call autosuspend from idle, so pci config space access doesn't go straight
back to sleep, this makes starting X faster.
only signal usage if we actually handle the irq, otherwise usb keeps us awake.
fix nv50 display active powerdown

v0.9:
use masking function to enable hdmi audio
set busy when we fail to suspend

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/core/core/printk.c |  19 ++
 drivers/gpu/drm/nouveau/core/include/core/printk.h |  13 ++
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c|   2 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c  |   6 +
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|  49 +++-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  42 +++-
 drivers/gpu/drm/nouveau/nouveau_connector.c|  27 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  12 +-
 drivers/gpu/drm/nouveau/nouveau_display.h  |   2 +
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 250 +++--
 drivers/gpu/drm/nouveau/nouveau_drm.h  |   9 +
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  14 +-
 drivers/gpu/drm/nouveau/nv50_display.c |   2 +-
 13 files changed, 404 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/printk.c 
b/drivers/gpu/drm/nouveau/core/core/printk.c
index 6161eaf..52fb2aa 100644
--- a/drivers/gpu/drm/nouveau/core/core/printk.c
+++ b/drivers/gpu/drm/nouveau/core/core/printk.c
@@ -27,6 +27,8 @@
 #include 
 #include 

+int nv_printk_suspend_level = NV_DBG_DEBUG;
+
 void
 nv_printk_(struct nouveau_object *object, const char *pfx, int level,
   const char *fmt, ...)
@@ -72,3 +74,20 @@ nv_printk_(struct nouveau_object *object, const char *pfx, 
int level,
vprintk(mfmt, args);
va_end(args);
 }
+
+#define CONV_LEVEL(x) case NV_DBG_##x: return NV_PRINTK_##x
+
+const char *nv_printk_level_to_pfx(int level)
+{
+   switch (level) {
+   CONV_LEVEL(FATAL);
+   CONV_LEVEL(ERROR);
+   CONV_LEVEL(WARN);
+   CONV_LEVEL(INFO);
+   CONV_LEVEL(DEBUG);
+   CONV_LEVEL(PARANOIA);
+   CONV_LEVEL(TRACE);
+   CONV_LEVEL(SPAM);
+   }
+   return NV_PRINTK_DEBUG;
+}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/printk.h 
b/drivers/gpu/drm/nouveau/core/include/core/printk.h
index febed2e..d87836e 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/printk.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/printk.h
@@ -15,6 +15,12 @@ struct nouveau_object;
 #define NV_PRINTK_TRACEKERN_DEBUG
 #define NV_PRINTK_SPAM KERN_DEBUG

+extern int nv_printk_suspend_level;
+
+#define NV_DBG_SUSPEND (nv_printk_suspend_level)
+#define NV_PRINTK_SUSPEND  (nv_printk_level_to_pfx(nv_printk_suspend_level))
+
+const char *nv_printk_level_to_pfx(int level);
 void __printf(4, 5)
 nv_printk_(struct nouveau_object *, const char *, int, const char *, ...);

@@ -31,6 +37,13 @@ nv_printk_(struct nouveau_object *, const char *, int, const 
char *, ...);
 #define nv_trace(o,f,a...) nv_printk((o), TRACE, f, ##a)
 #define nv_spam(o,f,a...) nv_printk((o), SPAM, f, ##a)

+#define nv_suspend(o,f,a...) nv_printk((o), SUSPEND, f, ##a)
+
+static inline void nv_suspend_set_printk_level(int level)
+{
+   nv_printk_suspend_level = level;
+}
+
 #define nv_assert(f,a...) do { 
\
if (NV_DBG_FATAL <= CONFIG_NOUVEAU_DEBUG)  \
nv_printk_(NULL, NV_PRINTK_FATAL, NV_DBG_FATAL, f "\n", ##a);  \
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
index 0687e64..2e11ea0 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c
@@ -2165,7 +2165,7 @@ nvbios_init(struct nouveau_subdev *subdev, bool execute)
u16 data;

if (execute)
-   nv_info(bios, "running init tables\n");
+   nv_suspend(bios, "running init tables\n");
while (!ret && (data = (init_script(bios, ++i {
struct nvbios_init init = {
.subdev = subdev,
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
b/drivers/gpu/drm/nouveau/

[PATCH 2/4] drm: allow open of dynamic off devices.

From: Dave Airlie 

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fops.c | 2 +-
 include/drm/drmP.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..d5429ee 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -257,7 +257,7 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
return -EBUSY;  /* No exclusive opens */
if (!drm_cpu_valid())
return -EINVAL;
-   if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
+   if (dev->switch_power_state != DRM_SWITCH_POWER_ON && 
dev->switch_power_state != DRM_SWITCH_POWER_DYNAMIC_OFF)
return -EINVAL;

DRM_DEBUG("pid = %d, minor = %d\n", task_pid_nr(current), minor_id);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 12083dc..7f8acaf 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1223,6 +1223,7 @@ struct drm_device {
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
+#define DRM_SWITCH_POWER_DYNAMIC_OFF 3

 static __inline__ int drm_core_check_feature(struct drm_device *dev,
 int feature)
-- 
1.8.2.1

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

From: Dave Airlie 

For optimus and powerxpress muxless we really want the GPU
driver deciding when to power up/down the GPU, not userspace.

This adds the ability for a driver to dynamically power up/down
the GPU and remove the switcheroo from controlling it, the
switcheroo reports the dynamic state to userspace also.

It also adds 2 power domains, one for machine where the power
switch is controlled outside the GPU D3 state, so the powerdown
ordering is done correctly, and the second for the hdmi audio
device to make sure it can resume for PCI config space accesses.

v1.1: fix build with switcheroo off

v2: add power domain support for radeon and v1 nvidia dsms
v2.1: fix typo in off case

v3: add audio power domain for hdmi audio + misc audio fixes

v4: use PCI_SLOT macro, drop power reference on hdmi audio resume
failure also.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_dma.c|   2 +-
 drivers/gpu/drm/nouveau/nouveau_vga.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_device.c |   2 +-
 drivers/gpu/vga/vga_switcheroo.c   | 147 +++--
 include/linux/vga_switcheroo.h |  13 ++-
 5 files changed, 156 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b152068..5f930a1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1293,7 +1293,7 @@ static int i915_load_modeset_init(struct drm_device *dev)

intel_register_dsm_handler();

-   ret = vga_switcheroo_register_client(dev->pdev, &i915_switcheroo_ops);
+   ret = vga_switcheroo_register_client(dev->pdev, &i915_switcheroo_ops, 
false);
if (ret)
goto cleanup_vga_client;

diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 25d3495..40a09f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -79,7 +79,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
 {
struct drm_device *dev = drm->dev;
vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode);
-   vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops);
+   vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops, 
false);
 }

 void
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 82335e3..0610ca4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1269,7 +1269,7 @@ int radeon_device_init(struct radeon_device *rdev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
vga_client_register(rdev->pdev, rdev, NULL, radeon_vga_set_decode);
-   vga_switcheroo_register_client(rdev->pdev, &radeon_switcheroo_ops);
+   vga_switcheroo_register_client(rdev->pdev, &radeon_switcheroo_ops, 
false);

r = radeon_init(rdev);
if (r)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index cf787e1..ec0ae2d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 

@@ -37,6 +38,7 @@ struct vga_switcheroo_client {
const struct vga_switcheroo_client_ops *ops;
int id;
bool active;
+   bool driver_power_control;
struct list_head list;
 };

@@ -132,7 +134,7 @@ EXPORT_SYMBOL(vga_switcheroo_unregister_handler);

 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  int id, bool active)
+  int id, bool active, bool driver_power_control)
 {
struct vga_switcheroo_client *client;

@@ -145,6 +147,7 @@ static int register_client(struct pci_dev *pdev,
client->ops = ops;
client->id = id;
client->active = active;
+   client->driver_power_control = driver_power_control;

mutex_lock(&vgasr_mutex);
list_add_tail(&client->list, &vgasr_priv.clients);
@@ -160,10 +163,11 @@ static int register_client(struct pci_dev *pdev,
 }

 int vga_switcheroo_register_client(struct pci_dev *pdev,
-  const struct vga_switcheroo_client_ops *ops)
+  const struct vga_switcheroo_client_ops *ops,
+  bool driver_power_control)
 {
return register_client(pdev, ops, -1,
-  pdev == vga_default_device());
+  pdev == vga_default_device(), 
driver_power_control);
 }
 EXPORT_SYMBOL(vga_switcheroo_register_client);

@@ -171,7 +175,7 @@ int vga_switcheroo_register_audio_client(struct pci_dev 
*pdev,
 const struct vga_switcheroo_client_ops 
*ops,
 int id, bool active)
 {
-   return register_client(pdev, ops, id | I

optimus dynamic power patches

This is a repost of the series with some bugs fixed, I've really only
tested this on my one optimus laptop so far. I've also ported radeon
to this patch series, but it doesn't work on my only radeon test box
since we always end up with a crtc configured, but I may just push
the patches as they might help others with muxless hw.

Dave.

[RFC] drm: add flip-work helper

On Mon, Aug 5, 2013 at 4:00 AM, Daniel Vetter  wrote:
> On Sun, Aug 04, 2013 at 10:20:54PM -0400, Rob Clark wrote:
>> On Sun, Aug 4, 2013 at 1:34 PM, Daniel Vetter  wrote:
>> > On Thu, Aug 1, 2013 at 1:23 AM, Rob Clark  wrote:
>> >> A small helper to queue up work to do, from workqueue context, after a
>> >> flip.  Typically useful to defer unreffing buffers that may be read by
>> >> the display controller until vblank.
>> >>
>> >> Signed-off-by: Rob Clark 
>> >> ---
>> >> I've re-inventing the same wheel three times in as many drivers (omapdrm,
>> >> tilcdc, and in upcoming msm driver I need two of 'em).  I guess it is
>> >> time to helper-up.
>> >>
>> >> I'll update omapdrm and tilcdc to use this as well, but I figured I'd
>> >> send an RFC first in case anyone wants to get their bikeshed on.  If
>> >> there are other drivers that could use this, and are straightforward
>> >> to convert over, let me know and I can update them as well.
>> >
>> >
>> > One thing drm/i915 needs is to be able to flush the workqueue (to make
>> > sure we don't pile up giant amounts of buffers waiting to be unpinned
>> > and so temporarily leak a bit of memory). So some way to synchronously
>> > flush out flip functions would be required (and make sure all that
>> > have been queued up to that point are really completed). But at that
>> > point a separate workqueue sounds simpler, so I wonder a bit what this
>> > gains us? At roughly 50Hz flip work functions aren't really that
>> > performance critical imo ...
>>
>> you could of course do separate or same workqueue from your main
>> render-complete workqueue, or flush the workqueue at whatever point
>> you want..  I suppose if you are queuing from a context that is safe
>> to sleep you could have a blocking-queue function.  I haven't really
>> needed anything like that so far, but feel free to extend the
>> flip-work helper however you need to be useful for i915.  (Or point me
>> at the bits in i915 that do something similar and I'll have a think
>> about how to convert that)
>
> queue_work in do_intel_finish_page_flip and flush_work in
> intel_crtc_page_flip is the relevant code. The former is called from irq
> context.

ok, it looks like intel_crtc_page_flip() would call
drm_flip_work_queue() and then something like:

  if (kfifo_len(&flipwork->fifo) >= 2)
flush_workqueue(wq)

maybe a static inline fxn to wrap the kfifo_len().. but that is the
basic idea.  Although seems like you have a few other things wrapped
up in intel_unpin_work.  I guess you could move the pending event to
the crtc because you can only have one pending flip at a time (and
maybe enable_stall_check  I didn't really look at the stall-check
stuff..)

BR,
-R




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

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #7 from Gabor Hasenfrasz  ---
Created attachment 107104
  --> https://bugzilla.kernel.org/attachment.cgi?id=107104&action=edit
avivotool regs hdmi output on kernel 3.9

This is with radeon.audio=1 kernel parameter with kernel 3.9.9

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67800] New: Computer freezes after idle for several hours with dpms off (trinity)

https://bugs.freedesktop.org/show_bug.cgi?id=67800

  Priority: medium
Bug ID: 67800
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Computer freezes after idle for several hours with
dpms off (trinity)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: laszlo.kert...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

I use Debian 64 bit and now i have the 3.11rc4 kernel installed, with mesa from
git, xf86-video-ati from git, libdrm from git, all firmwares put in
/lib/firmware.
The hardware is A8-5500 desktop APU with its built in 7560D card.
The system works very well, opengl, vdpau is functional.

I have xscreensaver set to turn off the monitor after 4 minutes, which it does.
I can wake up after a few minutes by moving the mouse or pressing a key.

All is going well until i leave the computer for a longer time (it varies,
usually a few hours) - the computer becomes totally unresponsive, doesnt react
to keyboard/mouse and network wise is totally dead. The fans are on normally,
no disk activity. I have to reset it from the reset button.
Nothing out of the ordinary in any logs, they just stop logging, presumably
when the computer freezes.

Now if i disable dpms and leave only blanking, this doesnt happen (This is why
i think it has to do with the kernel driver), but this mean the monitor is on
all the tme which isnt good since the computer runs 24/7.

PS. It didnt happen previously with the fglrx driver in any circumstances.

Any ideas why this might happen?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #6 from Gabor Hasenfrasz  ---
(In reply to Rafał Miłecki from comment #4)
> Do you have some second monitor or other machine to ssh the first one?
> 
> I'd like to see output of command
> avivotool regs hdmi
> when using 3.9 with audio=1 and then using 3.10/3.11 with audio=1.

Yes I do. I will run it now.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760

https://bugzilla.kernel.org/show_bug.cgi?id=60687

--- Comment #5 from Gabor Hasenfrasz  ---
(In reply to Alex Deucher from comment #2)
> Can you bisect?

Bisect finished:

d3418eacad403033e95e49dc14afa37c2112c134 is the first bad commit
commit d3418eacad403033e95e49dc14afa37c2112c134
Author: Rafał Miłecki 
Date:   Thu Apr 18 09:23:12 2013 -0400

drm/radeon/evergreen: setup HDMI before enabling it

Closed source driver fglrx seems to enable infoframes and audio packets
at the end, which makes sense, do the same.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Alex Deucher 

:04 04 67e10b90afeefe688d0c291e603c80dd7a9e810a
1105ef4336989eee87c971b035fedcc092c42417 Mdrivers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

Hi Sylwester,

On 2 August 2013 16:28, Sylwester Nawrocki  wrote:
> Hi Vikas,
>
> On 08/02/2013 12:10 PM, Vikas Sajjan wrote:
>> yeah, we could not allocate CMA region for FIMD, because the function
>> dma_declare_contiguous() needs "dev" as the first argument and we have
>> access to "dev" node only if it is NON-DT way of probing like the way
>> it is done in arch/arm/mach-davinci/devices-da8xx.c
>> But now, since the probing is through DT way, there is NO way ( Let me
>> know if something is newly added ) to call dma_declare_contiguous()
>> and reserve CMA region .
>
> See this patch series [1]. We have have been using this kind of bindings
> for assigning physically contiguous memory regions to the Exynos
> multimedia devices, instead of what's currently in mainline where same
> physical addresses are repeated in dts for various boards without much
> thought. And where custom device specific parsing code is required at
> arch side.
>
> $ git grep mfc\-[lr] arch/arm/boot/dts
>
> arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-l = <0x5100 
> 0x80>;
> arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-r = <0x4300 
> 0x80>;
> arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-l = <0x5100 
> 0x80>;
>
>
> [1] http://www.spinics.net/lists/arm-kernel/msg263130.html
>


Thanks, its good that now we have a new way to reserve CMA region.


> Regards,
> Sylwester



-- 
Thanks and Regards
 Vikas Sajjan

[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60606

--- Comment #2 from Sebastien Fievet  ---
After a *lot* of googling effort, I managed to narrow down and find a
workaround to this bug.
- First, my mistake was to have an xorg.conf.d directory defining the video
drivers. 
  Letting X auto detect the driver was the necessary first step.

- Second I applied the "drm/i915: do not disable backlight on vgaswitcheroo
switch off" patch referenced in
https://bugs.freedesktop.org/show_bug.cgi?id=59785
  It made switching from IGD to discrete functional, but switching away from
IGD with discrete OFF was still screwing up the display.

- Finally, I found
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1077675, which was
reporting the exact same bug as I was experiencing.
  Same hardware, same issue. Same workaround : echoing MIGD to
/sys/kernel/debug/vgaswitcheroo/switch restores display when discrete is
  switched back ON

- I am now on 3.11.0-rc4 + drm/i915 patch and everything works fine (with the
workaround)

Conclusion :
  1. DPM is not involved at all.
  2. Switcheroo doesn't fully support Acer 3820TG hybrid (muxed) laptop out of
the box, but workaround exists.

If anyone wants to investigate further, I'll be glad to provide any relevant
information.
Thanks,
Seb.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 07:18:27PM +0100, Damien Lespiau wrote:
> On Mon, Aug 05, 2013 at 09:07:05PM +0300, Ville Syrjälä wrote:
> > On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> > > >From CEA-861:
> > > 
> > >   Data Byte 1, bit A0 indicates whether Active Format Data is present in
> > >   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
> > >   any of the AFD bits are set.
> > > 
> > > ie. if we want to set active_aspect, we need to set the
> > > active_info_valid bit to 1 as well.
> > > 
> > > Cc: Thierry Reding 
> > > Signed-off-by: Damien Lespiau 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 95d6f4b..8d1139f 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > > hdmi_avi_infoframe *frame,
> > >   return 0;
> > 
> > Nothing to do with this patch, but I just spotted this return here. So
> > we're not populating the aspect ratio stuff if VIC=0. Doesn't really
> > make sense to me. Who will tell me what this is trying to achieve?
> 
> I wondered about that to. The intent seems to not set those bits when
> we're not setting a CEA mode. I guess the author thought that only CEA
> modes can understand the infoframes described in CEA-861. I haven't
> found any evidence of that, but made some sense to me.

Perhaps. I'm leaning towards just killing that check though.

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

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #10 from Christian K?nig  ---
I'm constantly improving the UVD support for 3.11 (and back porting the fixes
to 3.10).

So please retest with each new release candidate as long a those symptoms
remain.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/df865fca/attachment.html>

i915 INFO: trying to register non-static key.

2013-08-05 Thread Borislav Petkov

On Mon, Aug 05, 2013 at 01:06:35AM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 6:22 PM, Borislav Petkov  wrote:
> > Dudes,
> >
> > has anyone already reported this (happens on Linus of today +
> > tip/master):
> 
> I think this should be fixed with
> 
> commit e1b4d3036c07ff137955fb1c0197ab62534f46ec
> Author: Ben Widawsky 
> Date:   Tue Jul 30 16:27:57 2013 -0700
> 
> drm/i915: fix missed hunk after GT access breakage
> 
> which is now in upstream git and -rc4.

Yes it is.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 09:07:05PM +0300, Ville Syrjälä wrote:
> On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> > >From CEA-861:
> > 
> >   Data Byte 1, bit A0 indicates whether Active Format Data is present in
> >   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
> >   any of the AFD bits are set.
> > 
> > ie. if we want to set active_aspect, we need to set the
> > active_info_valid bit to 1 as well.
> > 
> > Cc: Thierry Reding 
> > Signed-off-by: Damien Lespiau 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 95d6f4b..8d1139f 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > hdmi_avi_infoframe *frame,
> > return 0;
> 
> Nothing to do with this patch, but I just spotted this return here. So
> we're not populating the aspect ratio stuff if VIC=0. Doesn't really
> make sense to me. Who will tell me what this is trying to achieve?

I wondered about that to. The intent seems to not set those bits when
we're not setting a CEA mode. I guess the author thought that only CEA
modes can understand the infoframes described in CEA-861. I haven't
found any evidence of that, but made some sense to me.

-- 
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey  wrote:
> Hi Rob,
>
> +linux-media, +linaro-mm-sig for discussion of video/camera
> buffer constraints...
>
>
>> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey 
>> wrote:
>> >> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>> >> >allocate buffers for the GPU. Still not sure how to resolve
>> >> >this as we don't use DRM for our GPU driver.
>> >>
>> >> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
>> >> once the dma-fence stuff is in place), we'd have gpu-specific drm
>> >> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
>> >> using prime/dmabuf to share between the two.
>> >
>> > The "extra" buffers we were allocating from armsoc DDX were really
>> > being allocated through DRM/GEM so we could get an flink name
>> > for them and pass a reference to them back to our GPU driver on
>> > the client side. If it weren't for our need to access those
>> > extra off-screen buffers with the GPU we wouldn't need to
>> > allocate them with DRM at all. So, given they are really "GPU"
>> > buffers, it does absolutely make sense to allocate them in a
>> > different driver to the display driver.
>> >
>> > However, to avoid unnecessary memcpys & related cache
>> > maintenance ops, we'd also like the GPU to render into buffers
>> > which are scanned out by the display controller. So let's say
>> > we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
>> > out buffers with the display's DRM driver but a custom ioctl
>> > on the GPU's DRM driver to allocate non scanout, off-screen
>> > buffers. Sounds great, but I don't think that really works
>> > with DRI2. If we used two drivers to allocate buffers, which
>> > of those drivers do we return in DRI2ConnectReply? Even if we
>> > solve that somehow, GEM flink names are name-spaced to a
>> > single device node (AFAIK). So when we do a DRI2GetBuffers,
>> > how does the EGL in the client know which DRM device owns GEM
>> > flink name "1234"? We'd need some pretty dirty hacks.
>>
>> You would return the name of the display driver allocating the
>> buffers.  On the client side you can use generic ioctls to go from
>> flink -> handle -> dmabuf.  So the client side would end up opening
>> both the display drm device and the gpu, but without needing to know
>> too much about the display.
>
> I think the bit I was missing was that a GEM bo for a buffer imported
> using dma_buf/PRIME can still be flink'd. So the display controller's
> DRM driver allocates scan-out buffers via the DUMB buffer allocate
> ioctl. Those scan-out buffers than then be exported from the
> dispaly's DRM driver and imported into the GPU's DRM driver using
> PRIME. Once imported into the GPU's driver, we can use flink to get a
> name for that buffer within the GPU DRM driver's name-space to return
> to the DRI2 client. That same namespace is also what DRI2 back-buffers
> are allocated from, so I think that could work... Except...
>

(and.. the general direction is that things will move more to just use
dmabuf directly, ie. wayland or dri3)

>
>> > Anyway, that latter case also gets quite difficult. The "GPU"
>> > DRM driver would need to know the constraints of the display
>> > controller when allocating buffers intended to be scanned out.
>> > For example, pl111 typically isn't behind an IOMMU and so
>> > requires physically contiguous memory. We'd have to teach the
>> > GPU's DRM driver about the constraints of the display HW. Not
>> > exactly a clean driver model. :-(
>> >
>> > I'm still a little stuck on how to proceed, so any ideas
>> > would greatly appreciated! My current train of thought is
>> > having a kind of SoC-specific DRM driver which allocates
>> > buffers for both display and GPU within a single GEM
>> > namespace. That SoC-specific DRM driver could then know the
>> > constraints of both the GPU and the display HW. We could then
>> > use PRIME to export buffers allocated with the SoC DRM driver
>> > and import them into the GPU and/or display DRM driver.
>>
>> Usually if the display drm driver is allocating the buffers that might
>> be scanned out, it just needs to have minimal knowledge of the GPU
>> (pitch alignment constraints).  I don't think we need a 3rd device
>> just to allocate buffers.
>
> While Mali can render to pretty much any buffer, there is a mild
> performance improvement to be had if the buffer stride is aligned to
> the AXI bus's max burst length when drawing to the buffer.

I suspect the display controllers might frequently benefit if the
pitch is aligned to AXI burst length too..

> So in some respects, there is a constraint on how buffers which will
> be drawn to using the GPU are allocated. I don't really like the idea
> of teaching the display controller DRM driver about the GPU buffer
> constraints, even if they are fairly trivial like this. If the same
> display HW IP is being used on several SoCs, it seems wrong somehow
> to enforce those GPU constr

Re: [PATCH] drm: Don't generate invalid AVI infoframes for CEA modes

On Mon, Aug 05, 2013 at 02:36:47PM +0100, Damien Lespiau wrote:
> >From CEA-861:
> 
>   Data Byte 1, bit A0 indicates whether Active Format Data is present in
>   Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
>   any of the AFD bits are set.
> 
> ie. if we want to set active_aspect, we need to set the
> active_info_valid bit to 1 as well.
> 
> Cc: Thierry Reding 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/drm_edid.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 95d6f4b..8d1139f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3107,6 +3107,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> hdmi_avi_infoframe *frame,
>   return 0;

Nothing to do with this patch, but I just spotted this return here. So
we're not populating the aspect ratio stuff if VIC=0. Doesn't really
make sense to me. Who will tell me what this is trying to achieve?

>  
>   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> + frame->active_info_valid = 1;
>   frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
>  
>   return 0;
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 00/20] prime/flink fixes and related stuff

2013-08-05 Thread Inki Dae



> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> Sent: Monday, August 05, 2013 2:42 AM
> To: Inki Dae
> Cc: DRI Development
> Subject: Re: [PATCH 00/20] prime/flink fixes and related stuff
> 
> On Sat, Jul 27, 2013 at 11:22 AM, Inki Dae  wrote:
> >
> > 2013/7/16 Daniel Vetter 
> >>
> >> Hi all,
> >>
> >> This patch series is my 2nd real stab at fixing up the locking issues
> >> around our
> >> two buffer sharing mechanisms in gem: flink and prime.
> >>
> >> I think the approach taken here is much better than my first stab, and
> it
> >> also
> >> seems to no longer leak buffers ;-) There some assorted cleanup and
> prep
> >> work
> >> (and one i915 fix) thrown into the mix, it's all stuff I've stumbled
> over
> >> while
> >> digging through the code.
> >>
> >> Open issues left in prime-land after these patches:
> >> - exynos probably wants a similar patch to "drm/i915: explicit store
> base
> >> gem
> >>   object in dma_buf->priv". The current code should be correct, but
> it's a
> >> bit
> >
> >
> > How about using stuffs of drm_prime instead of specific ones? Seem like
> that
> > we could replace specific dmabuf stuffs with common ones of drm_prime,
> at
> > least in case of Exynos: i.e. each driver can export a gem to a dmabuf
> > through drm_gem_prime_export function of drm_prime instead of specific
> one.
> > By doing so, I think we could remove duplicated codes of drivers,
> specific
> > dmabuf stuffs. I'm not sure but it seems like that there is any reason
> you
> > try to use existing stuffs with a little change: maybe the stuffs of
> > drm_prime couldn't be used for all drm drivers commonly.
> 
> I have to admit that I didn't really understand your email, mostly
> since you talk about "stuff" and "stuffs" and I didn't really grok
> which piece of code you actually mean. Can you pls elaborate, maybe
> taking the functions for exynos as an example?

You have posted one patch that makes i915/exynos drivers use
drm_gem_dmabuf_release function commonly. But my opinion is that we could
use not only drm_gem_dmabuf_release function but also other functions of
drm_prime commonly. I think that could be done simply like below,

In drivers/gpu/drm/i915/i915_dev.c,
Static struct drm_driver driver = {
...
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
...

We are using driver specific dma_buf_ops, i915_dmabuf_ops for i915 and
exynos_dmabuf_ops for exynos. So my opinion is to use
drm_gem_prime_dmabuf_ops of drm_prime instead. However, for this, we have to
change specific export and import functions to exported drm_prim's ones,
drm_gem_prime_export and drm_gem_prime_import. And I thought maybe you
caught that but you used only drm_gem_dmabuf_release function among them of
drm_prime if there is no my missing point. So I guess maybe there is any
reason in doing so.

Thanks,
Inki Dae

drm: use common drm_gem_dmabuf_release in i915/exynos drivers


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

[PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb

On Mon, Aug 5, 2013 at 5:44 AM, Vikas Sajjan  wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> To address the case where physically continous memory MAY NOT be a
> mandatory requirement for fb, the patch adds a feature to get non physically
> continous memory for fb if IOMMU is supported and if CONTIG memory allocation
> fails.


Reviewed-by: Rob Clark 

>
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Arun Kumar 
> ---
> changes since v1:
>  - Modified to add the fallback patch if CONTIG alloc fails as 
> suggested
>  by Rob Clark robdclark at gmail.com and Tomasz Figa  gmail.com>.
>
>  - changed the commit message.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 8e60bd6..9a4b886 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> @@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
> *helper,
>
> size = mode_cmd.pitches[0] * mode_cmd.height;
>
> -   /* 0 means to allocate physically continuous memory */
> -   exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> +   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
> if (IS_ERR(exynos_gem_obj)) {
> -   ret = PTR_ERR(exynos_gem_obj);
> -   goto err_release_framebuffer;
> +   /*
> +* If IOMMU is supported then try to get buffer from
> +* non-continous memory area
> +*/
> +   if (is_drm_iommu_supported(dev))
> +   exynos_gem_obj = exynos_drm_gem_create(dev,
> +   EXYNOS_BO_NONCONTIG, size);
> +   if (IS_ERR(exynos_gem_obj)) {
> +   ret = PTR_ERR(exynos_gem_obj);
> +   goto err_release_framebuffer;
> +   }
> +   dev_warn(&pdev->dev, "exynos_gem_obj for FB is allocated 
> with\n"
> +   "non physically continuous memory\n");
> }
>
> exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
> --
> 1.7.9.5
>

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-05 Thread Tom Cooksey

Hi Rob,

+linux-media, +linaro-mm-sig for discussion of video/camera
buffer constraints...

> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey 
> wrote:
> >> >  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
> >> >allocate buffers for the GPU. Still not sure how to resolve
> >> >this as we don't use DRM for our GPU driver.
> >>
> >> any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
> >> once the dma-fence stuff is in place), we'd have gpu-specific drm
> >> (gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
> >> using prime/dmabuf to share between the two.
> >
> > The "extra" buffers we were allocating from armsoc DDX were really
> > being allocated through DRM/GEM so we could get an flink name
> > for them and pass a reference to them back to our GPU driver on
> > the client side. If it weren't for our need to access those
> > extra off-screen buffers with the GPU we wouldn't need to
> > allocate them with DRM at all. So, given they are really "GPU"
> > buffers, it does absolutely make sense to allocate them in a
> > different driver to the display driver.
> >
> > However, to avoid unnecessary memcpys & related cache
> > maintenance ops, we'd also like the GPU to render into buffers
> > which are scanned out by the display controller. So let's say
> > we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan
> > out buffers with the display's DRM driver but a custom ioctl
> > on the GPU's DRM driver to allocate non scanout, off-screen
> > buffers. Sounds great, but I don't think that really works
> > with DRI2. If we used two drivers to allocate buffers, which
> > of those drivers do we return in DRI2ConnectReply? Even if we
> > solve that somehow, GEM flink names are name-spaced to a
> > single device node (AFAIK). So when we do a DRI2GetBuffers,
> > how does the EGL in the client know which DRM device owns GEM
> > flink name "1234"? We'd need some pretty dirty hacks.
> 
> You would return the name of the display driver allocating the
> buffers.  On the client side you can use generic ioctls to go from
> flink -> handle -> dmabuf.  So the client side would end up opening
> both the display drm device and the gpu, but without needing to know
> too much about the display.

I think the bit I was missing was that a GEM bo for a buffer imported
using dma_buf/PRIME can still be flink'd. So the display controller's
DRM driver allocates scan-out buffers via the DUMB buffer allocate
ioctl. Those scan-out buffers than then be exported from the
dispaly's DRM driver and imported into the GPU's DRM driver using
PRIME. Once imported into the GPU's driver, we can use flink to get a
name for that buffer within the GPU DRM driver's name-space to return
to the DRI2 client. That same namespace is also what DRI2 back-buffers
are allocated from, so I think that could work... Except...

> > Anyway, that latter case also gets quite difficult. The "GPU"
> > DRM driver would need to know the constraints of the display
> > controller when allocating buffers intended to be scanned out.
> > For example, pl111 typically isn't behind an IOMMU and so
> > requires physically contiguous memory. We'd have to teach the
> > GPU's DRM driver about the constraints of the display HW. Not
> > exactly a clean driver model. :-(
> >
> > I'm still a little stuck on how to proceed, so any ideas
> > would greatly appreciated! My current train of thought is
> > having a kind of SoC-specific DRM driver which allocates
> > buffers for both display and GPU within a single GEM
> > namespace. That SoC-specific DRM driver could then know the
> > constraints of both the GPU and the display HW. We could then
> > use PRIME to export buffers allocated with the SoC DRM driver
> > and import them into the GPU and/or display DRM driver.
> 
> Usually if the display drm driver is allocating the buffers that might
> be scanned out, it just needs to have minimal knowledge of the GPU
> (pitch alignment constraints).  I don't think we need a 3rd device
> just to allocate buffers.

While Mali can render to pretty much any buffer, there is a mild
performance improvement to be had if the buffer stride is aligned to
the AXI bus's max burst length when drawing to the buffer.

So in some respects, there is a constraint on how buffers which will
be drawn to using the GPU are allocated. I don't really like the idea
of teaching the display controller DRM driver about the GPU buffer
constraints, even if they are fairly trivial like this. If the same
display HW IP is being used on several SoCs, it seems wrong somehow
to enforce those GPU constraints if some of those SoCs don't have a
GPU.

We may also then have additional constraints when sharing buffers
between the display HW and video decode or even camera ISP HW.
Programmatically describing buffer allocation constraints is very
difficult and I'm not sure you can actually do it - there's some
pretty complex constraints out there! E.g. I believe there's a
platform

[robclark:drm-next 14/15] WARNING: debugfs_remove(NULL) is safe this check is probably not required

2013-08-05 Thread Fengguang Wu


Hi Rob,

FYI, there are new warnings show up in

tree:   git://people.freedesktop.org/~robclark/linux drm-next
head:   865ff8a71f4227222fec89ebb1743b4ca9f24ab1
commit: b91c7b5f2efe902c846e315ea7d219f37ba17ef5 [14/15] WIP: drm/msm: add rd 
logging debugfs

scripts/checkpatch.pl 0001-WIP-drm-msm-add-rd-logging-debugfs.patch

WARNING: min() should probably be min_t(int, sz, circ_count_to_end(&rd->fifo))
#270: drivers/gpu/drm/msm/msm_rd.c:142:
+   n = min((int)sz, circ_count_to_end(&rd->fifo));

ERROR: do not use C99 // comments
#299: drivers/gpu/drm/msm/msm_rd.c:171:
+priv->rd = rd; // XXX this isn't really good..

ERROR: do not use C99 // comments
#352: drivers/gpu/drm/msm/msm_rd.c:224:
+// priv->rd = rd;

WARNING: debugfs_remove(NULL) is safe this check is probably not required
#389: drivers/gpu/drm/msm/msm_rd.c:261:
+   if (rd->ent)
+   debugfs_remove(rd->ent);

ERROR: do not use C99 // comments
#412: drivers/gpu/drm/msm/msm_rd.c:284:
+if (!rd) return; // XXX

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

>From b91c7b5f2efe902c846e315ea7d219f37ba17ef5 Mon Sep 17 00:00:00 2001
From: Rob Clark 
Date: Thu, 25 Jul 2013 12:07:04 -0400
Subject: [PATCH] WIP: drm/msm: add rd logging debugfs

To ease debugging, add debugfs file which can be cat/tail'd to log
submits, along with fence #.  If GPU hangs, you can look at 'gpu'
debugfs file to find last completed fence and current register state,
and compare with logged rd file to narrow down the DRAW_INDX which
triggered the GPU hang.
---
 drivers/gpu/drm/msm/Makefile |1 +
 drivers/gpu/drm/msm/msm_drv.c|3 +-
 drivers/gpu/drm/msm/msm_drv.h|9 +
 drivers/gpu/drm/msm/msm_gem.h|1 +
 drivers/gpu/drm/msm/msm_gem_submit.c |1 +
 drivers/gpu/drm/msm/msm_gpu.c|2 +
 drivers/gpu/drm/msm/msm_rd.c |  334 ++
 7 files changed, 350 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/msm/msm_rd.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index c3a5134..f945179 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -23,6 +23,7 @@ msm-y := \
msm_gem.o \
msm_gem_submit.o \
msm_gpu.o \
+   msm_rd.o \
msm_ringbuffer.o

 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 355157d..adcc68b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -459,11 +459,12 @@ static int msm_debugfs_init(struct drm_minor *minor)
return ret;
}

-   return ret;
+   return msm_rd_debugfs_init(minor);
 }

 static void msm_debugfs_cleanup(struct drm_minor *minor)
 {
+   msm_rd_debugfs_cleanup(minor);
drm_debugfs_remove_files(msm_debugfs_list,
ARRAY_SIZE(msm_debugfs_list), minor);
 }
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index a7426f1..ea6f1c7 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -44,6 +44,8 @@

 struct msm_kms;
 struct msm_gpu;
+struct msm_rd_state;
+struct msm_gem_submit;

 #define NUM_DOMAINS 2/* one for KMS, then one per gpu core (?) */

@@ -68,6 +70,8 @@ struct msm_drm_private {
uint32_t next_fence, completed_fence;
wait_queue_head_t fence_event;

+   struct msm_rd_state *rd;
+
/* list of GEM objects: */
struct list_head inactive_list;

@@ -179,6 +183,11 @@ void __exit hdmi_unregister(void);
 void msm_gem_describe(struct drm_gem_object *obj, struct seq_file *m);
 void msm_gem_describe_objects(struct list_head *list, struct seq_file *m);
 void msm_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m);
+int msm_rd_debugfs_init(struct drm_minor *minor);
+void msm_rd_debugfs_cleanup(struct drm_minor *minor);
+void msm_rd_dump_submit(struct msm_gem_submit *submit);
+#else
+static inline void msm_rd_dump_submit(struct msm_gem_submit *submit) {}
 #endif

 void __iomem *msm_ioremap(struct device *dev, resource_size_t offset,
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index d746f13..a5dbc5c 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -88,6 +88,7 @@ struct msm_gem_submit {
uint32_t type;
uint32_t size;  /* in dwords */
uint32_t iova;
+   uint32_t idx;   /* cmdstream buffer idx in bos[] */
} cmd[MAX_CMDS];
struct {
uint32_t flags;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index f62904f..d18e677 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -389,6 +389,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,

[robclark:drm-next 15/15] WARNING: debugfs_remove(NULL) is safe this check is probably not required

2013-08-05 Thread Fengguang Wu


Hi Rob,

FYI, there are new warnings show up in

tree:   git://people.freedesktop.org/~robclark/linux drm-next
head:   72b17e21c5965bd0da5e56d96a4776e508cbd79e
commit: 72b17e21c5965bd0da5e56d96a4776e508cbd79e [15/15] WIP: drm/msm: add perf 
logging debugfs

scripts/checkpatch.pl 0001-WIP-drm-msm-add-perf-logging-debugfs.patch

ERROR: do not use C99 // comments
#565: drivers/gpu/drm/msm/msm_perf.c:170:
+priv->perf = perf; // XXX this isn't really good..

ERROR: do not use C99 // comments
#616: drivers/gpu/drm/msm/msm_perf.c:221:
+// priv->perf = perf;

WARNING: debugfs_remove(NULL) is safe this check is probably not required
#651: drivers/gpu/drm/msm/msm_perf.c:256:
+   if (perf->ent)
+   debugfs_remove(perf->ent);

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

>From 72b17e21c5965bd0da5e56d96a4776e508cbd79e Mon Sep 17 00:00:00 2001
From: Rob Clark 
Date: Sat, 3 Aug 2013 12:43:25 -0400
Subject: [PATCH] WIP: drm/msm: add perf logging debugfs

---
 drivers/gpu/drm/msm/Makefile|1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |   20 ++-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |4 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |2 -
 drivers/gpu/drm/msm/msm_drv.c   |   15 +-
 drivers/gpu/drm/msm/msm_drv.h   |4 +
 drivers/gpu/drm/msm/msm_gpu.c   |  110 +
 drivers/gpu/drm/msm/msm_gpu.h   |   33 
 drivers/gpu/drm/msm/msm_perf.c  |  270 +++
 9 files changed, 448 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/msm_perf.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index f945179..a19c731 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -23,6 +23,7 @@ msm-y := \
msm_gem.o \
msm_gem_submit.o \
msm_gpu.o \
+   msm_perf.o \
msm_rd.o \
msm_ringbuffer.o

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 13d61bb..2e2950f 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -174,11 +174,11 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
/* Turn on performance counters: */
gpu_write(gpu, REG_A3XX_RBBM_PERFCTR_CTL, 0x01);

-   /* Set SP perfcounter 7 to count SP_FS_FULL_ALU_INSTRUCTIONS
-* we will use this to augment our hang detection:
-*/
-   gpu_write(gpu, REG_A3XX_SP_PERFCOUNTER7_SELECT,
-   SP_FS_FULL_ALU_INSTRUCTIONS);
+   /* Enable the perfcntrs that we use.. */
+   for (i = 0; i < gpu->num_perfcntrs; i++) {
+   const struct msm_gpu_perfcntr *perfcntr = &gpu->perfcntrs[i];
+   gpu_write(gpu, perfcntr->select_reg, perfcntr->select_val);
+   }

gpu_write(gpu, REG_A3XX_RBBM_INT_0_MASK, A3XX_INT0_MASK);

@@ -383,6 +383,13 @@ static const struct adreno_gpu_funcs funcs = {
},
 };

+static const struct msm_gpu_perfcntr perfcntrs[] = {
+   { REG_A3XX_SP_PERFCOUNTER6_SELECT, REG_A3XX_RBBM_PERFCTR_SP_6_LO,
+   SP_ALU_ACTIVE_CYCLES, "ALUACTIVE" },
+   { REG_A3XX_SP_PERFCOUNTER7_SELECT, REG_A3XX_RBBM_PERFCTR_SP_7_LO,
+   SP_FS_FULL_ALU_INSTRUCTIONS, "ALUFULL" },
+};
+
 struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
 {
struct a3xx_gpu *a3xx_gpu = NULL;
@@ -417,6 +424,9 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
DBG("fast_rate=%u, slow_rate=%u, bus_freq=%u",
gpu->fast_rate, gpu->slow_rate, gpu->bus_freq);

+   gpu->perfcntrs = perfcntrs;
+   gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
+
ret = adreno_gpu_init(dev, pdev, &a3xx_gpu->base,
&funcs, config->rev);
if (ret)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 282163e..39a65af 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -119,8 +119,6 @@ int adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
struct msm_ringbuffer *ring = gpu->rb;
unsigned i, ibs = 0;

-   adreno_gpu->last_fence = submit->fence;
-
for (i = 0; i < submit->nr_cmds; i++) {
switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
@@ -225,7 +223,7 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
adreno_gpu->rev.patchid);

seq_printf(m, "fence:%d/%d\n", adreno_gpu->memptrs->fence,
-   adreno_gpu->last_fence);
+   gpu->submitted_fence);
seq_printf(m, "rptr: %d\n", adreno_gpu->memptrs->rptr);
seq_printf(m, "wptr: %d\n", adreno_gpu->memptrs->wptr);
seq_printf(m, "rb wptr:  %d\n", get_wptr(gpu->rb));

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #9 from Harald Judt  ---
Ok, it happened a second time with a similar message; this seems to occur
randomly and unpredictibly as always.

It is definitely a UVD-only issue. I've applied the radeon.no_uvd patch some
guy wrote from here: http://pastebin.com/0mRGb224. Now with uvd turned off, 32
out of 32 attempts have been successful. No more hibernate problems, but UVD
doesn't work of course.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/8487684f/attachment.html>

[RFC] drm: add flip-work helper

On Sun, Aug 04, 2013 at 10:20:54PM -0400, Rob Clark wrote:
> On Sun, Aug 4, 2013 at 1:34 PM, Daniel Vetter  wrote:
> > On Thu, Aug 1, 2013 at 1:23 AM, Rob Clark  wrote:
> >> A small helper to queue up work to do, from workqueue context, after a
> >> flip.  Typically useful to defer unreffing buffers that may be read by
> >> the display controller until vblank.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >> I've re-inventing the same wheel three times in as many drivers (omapdrm,
> >> tilcdc, and in upcoming msm driver I need two of 'em).  I guess it is
> >> time to helper-up.
> >>
> >> I'll update omapdrm and tilcdc to use this as well, but I figured I'd
> >> send an RFC first in case anyone wants to get their bikeshed on.  If
> >> there are other drivers that could use this, and are straightforward
> >> to convert over, let me know and I can update them as well.
> >
> >
> > One thing drm/i915 needs is to be able to flush the workqueue (to make
> > sure we don't pile up giant amounts of buffers waiting to be unpinned
> > and so temporarily leak a bit of memory). So some way to synchronously
> > flush out flip functions would be required (and make sure all that
> > have been queued up to that point are really completed). But at that
> > point a separate workqueue sounds simpler, so I wonder a bit what this
> > gains us? At roughly 50Hz flip work functions aren't really that
> > performance critical imo ...
> 
> you could of course do separate or same workqueue from your main
> render-complete workqueue, or flush the workqueue at whatever point
> you want..  I suppose if you are queuing from a context that is safe
> to sleep you could have a blocking-queue function.  I haven't really
> needed anything like that so far, but feel free to extend the
> flip-work helper however you need to be useful for i915.  (Or point me
> at the bits in i915 that do something similar and I'll have a think
> about how to convert that)

queue_work in do_intel_finish_page_flip and flush_work in
intel_crtc_page_flip is the relevant code. The former is called from irq
context.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] mutex: fix deadlock injection

On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
> to return -EDEADLK did.
> 
> Cc: Alex Deucher 
> Signed-off-by: Maarten Lankhorst 

Oops, thanks for catching this.

Reviewed-by: Daniel Vetter 

> ---
> diff --git a/kernel/mutex.c b/kernel/mutex.c
> index ff05f4b..a52ee7bb 100644
> --- a/kernel/mutex.c
> +++ b/kernel/mutex.c
> @@ -686,7 +686,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct 
> ww_acquire_ctx *ctx)
>   might_sleep();
>   ret =  __mutex_lock_common(&lock->base, TASK_UNINTERRUPTIBLE,
>  0, &ctx->dep_map, _RET_IP_, ctx);
> - if (!ret && ctx->acquired > 0)
> + if (!ret && ctx->acquired > 1)
>   return ww_mutex_deadlock_injection(lock, ctx);
>  
>   return ret;
> @@ -702,7 +702,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, 
> struct ww_acquire_ctx *ctx)
>   ret = __mutex_lock_common(&lock->base, TASK_INTERRUPTIBLE,
> 0, &ctx->dep_map, _RET_IP_, ctx);
>  
> - if (!ret && ctx->acquired > 0)
> + if (!ret && ctx->acquired > 1)
>   return ww_mutex_deadlock_injection(lock, ctx);
>  
>   return ret;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [RFC] drm: add flip-work helper

On Mon, Aug 5, 2013 at 4:00 AM, Daniel Vetter  wrote:
> On Sun, Aug 04, 2013 at 10:20:54PM -0400, Rob Clark wrote:
>> On Sun, Aug 4, 2013 at 1:34 PM, Daniel Vetter  wrote:
>> > On Thu, Aug 1, 2013 at 1:23 AM, Rob Clark  wrote:
>> >> A small helper to queue up work to do, from workqueue context, after a
>> >> flip.  Typically useful to defer unreffing buffers that may be read by
>> >> the display controller until vblank.
>> >>
>> >> Signed-off-by: Rob Clark 
>> >> ---
>> >> I've re-inventing the same wheel three times in as many drivers (omapdrm,
>> >> tilcdc, and in upcoming msm driver I need two of 'em).  I guess it is
>> >> time to helper-up.
>> >>
>> >> I'll update omapdrm and tilcdc to use this as well, but I figured I'd
>> >> send an RFC first in case anyone wants to get their bikeshed on.  If
>> >> there are other drivers that could use this, and are straightforward
>> >> to convert over, let me know and I can update them as well.
>> >
>> >
>> > One thing drm/i915 needs is to be able to flush the workqueue (to make
>> > sure we don't pile up giant amounts of buffers waiting to be unpinned
>> > and so temporarily leak a bit of memory). So some way to synchronously
>> > flush out flip functions would be required (and make sure all that
>> > have been queued up to that point are really completed). But at that
>> > point a separate workqueue sounds simpler, so I wonder a bit what this
>> > gains us? At roughly 50Hz flip work functions aren't really that
>> > performance critical imo ...
>>
>> you could of course do separate or same workqueue from your main
>> render-complete workqueue, or flush the workqueue at whatever point
>> you want..  I suppose if you are queuing from a context that is safe
>> to sleep you could have a blocking-queue function.  I haven't really
>> needed anything like that so far, but feel free to extend the
>> flip-work helper however you need to be useful for i915.  (Or point me
>> at the bits in i915 that do something similar and I'll have a think
>> about how to convert that)
>
> queue_work in do_intel_finish_page_flip and flush_work in
> intel_crtc_page_flip is the relevant code. The former is called from irq
> context.

ok, it looks like intel_crtc_page_flip() would call
drm_flip_work_queue() and then something like:

  if (kfifo_len(&flipwork->fifo) >= 2)
flush_workqueue(wq)

maybe a static inline fxn to wrap the kfifo_len().. but that is the
basic idea.  Although seems like you have a few other things wrapped
up in intel_unpin_work.  I guess you could move the pending event to
the crtc because you can only have one pending flip at a time (and
maybe enable_stall_check  I didn't really look at the stall-check
stuff..)

BR,
-R




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

[Bug 60694] New: nvc3 suspend hangs

2013-08-05 Thread bugzilla-dae...@bugzilla.kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=60694

Bug ID: 60694
   Summary: nvc3 suspend hangs
   Product: Drivers
   Version: 2.5
Kernel Version: 3.5-3.11
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: cedric at brandenbourger.lu
Regression: No

Hi,

Until mainline kernel 3.4, nvc3 used to suspend and resume normally with
nouveau
After kernel 3.5, nvc3 cards are able to suspend but cannot resume with
nouveau.
The bug exists also in mainline kernel 3.11

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 3/4] drm/i915: pre-alloc instead of drm_mm search/get_block

On Sat, Jul 27, 2013 at 04:21:27PM +0200, David Herrmann wrote:
> i915 is the last user of the weird search+get_block drm_mm API. Convert it
> to an explicit kmalloc()+insert_node(). This drops the last user of the
> node-cache in drm_mm. We can remove it now in a follow-up patch.
> 
> v2:
>  - simplify error path in i915_setup_compression()
> v3:
>  - simplify error path even more
> 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Signed-off-by: David Herrmann 

I think this won't conflict badly with the ongoing VMA rework in drm/i915,
so

Acked-by: Daniel Vetter 

for merging through drm-next directly.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 78 
> --
>  1 file changed, 47 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index e355170..a3d1a12 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -112,34 +112,36 @@ static int i915_setup_compression(struct drm_device 
> *dev, int size)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_mm_node *compressed_fb, *uninitialized_var(compressed_llb);
> + int ret;
>  
> - /* Try to over-allocate to reduce reallocations and fragmentation */
> - compressed_fb = drm_mm_search_free(&dev_priv->mm.stolen,
> -size <<= 1, 4096,
> -DRM_MM_SEARCH_DEFAULT);
> - if (!compressed_fb)
> - compressed_fb = drm_mm_search_free(&dev_priv->mm.stolen,
> -size >>= 1, 4096,
> -DRM_MM_SEARCH_DEFAULT);
> - if (compressed_fb)
> - compressed_fb = drm_mm_get_block(compressed_fb, size, 4096);
> + compressed_fb = kzalloc(sizeof(*compressed_fb), GFP_KERNEL);
>   if (!compressed_fb)
> - goto err;
> + goto err_llb;
> +
> + /* Try to over-allocate to reduce reallocations and fragmentation */
> + ret = drm_mm_insert_node(&dev_priv->mm.stolen, compressed_fb,
> +  size <<= 1, 4096, DRM_MM_SEARCH_DEFAULT);
> + if (ret)
> + ret = drm_mm_insert_node(&dev_priv->mm.stolen, compressed_fb,
> +  size >>= 1, 4096,
> +  DRM_MM_SEARCH_DEFAULT);
> + if (ret)
> + goto err_llb;
>  
>   if (HAS_PCH_SPLIT(dev))
>   I915_WRITE(ILK_DPFC_CB_BASE, compressed_fb->start);
>   else if (IS_GM45(dev)) {
>   I915_WRITE(DPFC_CB_BASE, compressed_fb->start);
>   } else {
> - compressed_llb = drm_mm_search_free(&dev_priv->mm.stolen,
> - 4096, 4096,
> - DRM_MM_SEARCH_DEFAULT);
> - if (compressed_llb)
> - compressed_llb = drm_mm_get_block(compressed_llb,
> -   4096, 4096);
> + compressed_llb = kzalloc(sizeof(*compressed_llb), GFP_KERNEL);
>   if (!compressed_llb)
>   goto err_fb;
>  
> + ret = drm_mm_insert_node(&dev_priv->mm.stolen, compressed_llb,
> +  4096, 4096, DRM_MM_SEARCH_DEFAULT);
> + if (ret)
> + goto err_fb;
> +
>   dev_priv->fbc.compressed_llb = compressed_llb;
>  
>   I915_WRITE(FBC_CFB_BASE,
> @@ -157,8 +159,10 @@ static int i915_setup_compression(struct drm_device 
> *dev, int size)
>   return 0;
>  
>  err_fb:
> - drm_mm_put_block(compressed_fb);
> -err:
> + kfree(compressed_llb);
> + drm_mm_remove_node(compressed_fb);
> +err_llb:
> + kfree(compressed_fb);
>   pr_info_once("drm: not enough stolen space for compressed buffer (need 
> %d more bytes), disabling. Hint: you may be able to increase stolen memory 
> size in the BIOS to avoid this.\n", size);
>   return -ENOSPC;
>  }
> @@ -186,11 +190,15 @@ void i915_gem_stolen_cleanup_compression(struct 
> drm_device *dev)
>   if (dev_priv->fbc.size == 0)
>   return;
>  
> - if (dev_priv->fbc.compressed_fb)
> - drm_mm_put_block(dev_priv->fbc.compressed_fb);
> + if (dev_priv->fbc.compressed_fb) {
> + drm_mm_remove_node(dev_priv->fbc.compressed_fb);
> + kfree(dev_priv->fbc.compressed_fb);
> + }
>  
> - if (dev_priv->fbc.compressed_llb)
> - drm_mm_put_block(dev_priv->fbc.compressed_llb);
> + if (dev_priv->fbc.compressed_llb) {
> + drm_mm_remove_node(dev_priv->fbc.compressed_llb);
> + kfree(dev_priv->fbc.compressed_llb);
> + }
>  
>   dev_priv->fbc.size = 0;
>  }
> @@ -323,6 +331,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 
> size)
>   struct drm

[PATCH 1/4] drm/mm: add "best_match" flag to drm_mm_insert_node()

On Sat, Jul 27, 2013 at 01:36:27PM +0200, David Herrmann wrote:
> Add a "best_match" flag similar to the drm_mm_search_*() helpers so we
> can convert TTM to use them in follow up patches. We can also inline the
> non-generic helpers and move them into the header to allow compile-time
> optimizations.
> 
> To make calls to drm_mm_{search,insert}_node() more readable, this
> converts the boolean argument to a flagset. There are pending patches that
> add additional flags for top-down allocators and more.
> 
> v2:
>  - use flag parameter instead of boolean "best_match"
>  - convert *_search_free() helpers to also use flags argument
> 
> Signed-off-by: David Herrmann 

I'm not sure whether the use of an enum here is proper C style (usually
bitflag arguments tend to be unsigned ints), but that's a bikeshed. So

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_mm.c   | 37 ---
>  drivers/gpu/drm/drm_vma_manager.c  |  4 +--
>  drivers/gpu/drm/i915/i915_gem.c|  3 +-
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 12 +---
>  drivers/gpu/drm/sis/sis_mm.c   |  6 ++--
>  drivers/gpu/drm/ttm/ttm_bo_manager.c   |  3 +-
>  drivers/gpu/drm/via/via_mm.c   |  4 +--
>  include/drm/drm_mm.h   | 54 
> ++
>  8 files changed, 68 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index fe304f9..9a38327 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -212,12 +212,13 @@ EXPORT_SYMBOL(drm_mm_get_block_generic);
>   */
>  int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
>  unsigned long size, unsigned alignment,
> -unsigned long color)
> +unsigned long color,
> +enum drm_mm_search_flags flags)
>  {
>   struct drm_mm_node *hole_node;
>  
>   hole_node = drm_mm_search_free_generic(mm, size, alignment,
> -color, 0);
> +color, flags);
>   if (!hole_node)
>   return -ENOSPC;
>  
> @@ -226,13 +227,6 @@ int drm_mm_insert_node_generic(struct drm_mm *mm, struct 
> drm_mm_node *node,
>  }
>  EXPORT_SYMBOL(drm_mm_insert_node_generic);
>  
> -int drm_mm_insert_node(struct drm_mm *mm, struct drm_mm_node *node,
> -unsigned long size, unsigned alignment)
> -{
> - return drm_mm_insert_node_generic(mm, node, size, alignment, 0);
> -}
> -EXPORT_SYMBOL(drm_mm_insert_node);
> -
>  static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node,
>  struct drm_mm_node *node,
>  unsigned long size, unsigned alignment,
> @@ -313,13 +307,14 @@ EXPORT_SYMBOL(drm_mm_get_block_range_generic);
>   */
>  int drm_mm_insert_node_in_range_generic(struct drm_mm *mm, struct 
> drm_mm_node *node,
>   unsigned long size, unsigned alignment, 
> unsigned long color,
> - unsigned long start, unsigned long end)
> + unsigned long start, unsigned long end,
> + enum drm_mm_search_flags flags)
>  {
>   struct drm_mm_node *hole_node;
>  
>   hole_node = drm_mm_search_free_in_range_generic(mm,
>   size, alignment, color,
> - start, end, 0);
> + start, end, flags);
>   if (!hole_node)
>   return -ENOSPC;
>  
> @@ -330,14 +325,6 @@ int drm_mm_insert_node_in_range_generic(struct drm_mm 
> *mm, struct drm_mm_node *n
>  }
>  EXPORT_SYMBOL(drm_mm_insert_node_in_range_generic);
>  
> -int drm_mm_insert_node_in_range(struct drm_mm *mm, struct drm_mm_node *node,
> - unsigned long size, unsigned alignment,
> - unsigned long start, unsigned long end)
> -{
> - return drm_mm_insert_node_in_range_generic(mm, node, size, alignment, 
> 0, start, end);
> -}
> -EXPORT_SYMBOL(drm_mm_insert_node_in_range);
> -
>  /**
>   * Remove a memory node from the allocator.
>   */
> @@ -413,7 +400,7 @@ struct drm_mm_node *drm_mm_search_free_generic(const 
> struct drm_mm *mm,
>  unsigned long size,
>  unsigned alignment,
>  unsigned long color,
> -bool best_match)
> +enum drm_mm_search_flags flags)
>  {
>   struct drm_mm_node *entry;
>   struct drm_mm_node *best;
> @@ -436,7 +423,7 @@ struct drm_mm_node *drm_mm_search_free_generic(const 
> struct drm_mm *mm,
>

[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)

https://bugs.freedesktop.org/show_bug.cgi?id=66940

--- Comment #8 from Marco Trevisan (Trevi?o)  ---
(In reply to comment #7)
> Can you try with my drm-fixes-3.11 branch:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11

Cool, that seems to work... I can't test this with HDMI screen plugged now,
though (I don't remember if that was relevant). However I've noticed that the
VT switch on resume seems slower than it used to be.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130805/502f05a7/attachment.html>

[PATCH 00/20] prime/flink fixes and related stuff

On Mon, Aug 05, 2013 at 11:02:48AM +0900, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> > Sent: Monday, August 05, 2013 2:42 AM
> > To: Inki Dae
> > Cc: DRI Development
> > Subject: Re: [PATCH 00/20] prime/flink fixes and related stuff
> > 
> > On Sat, Jul 27, 2013 at 11:22 AM, Inki Dae  wrote:
> > >
> > > 2013/7/16 Daniel Vetter 
> > >>
> > >> Hi all,
> > >>
> > >> This patch series is my 2nd real stab at fixing up the locking issues
> > >> around our
> > >> two buffer sharing mechanisms in gem: flink and prime.
> > >>
> > >> I think the approach taken here is much better than my first stab, and
> > it
> > >> also
> > >> seems to no longer leak buffers ;-) There some assorted cleanup and
> > prep
> > >> work
> > >> (and one i915 fix) thrown into the mix, it's all stuff I've stumbled
> > over
> > >> while
> > >> digging through the code.
> > >>
> > >> Open issues left in prime-land after these patches:
> > >> - exynos probably wants a similar patch to "drm/i915: explicit store
> > base
> > >> gem
> > >>   object in dma_buf->priv". The current code should be correct, but
> > it's a
> > >> bit
> > >
> > >
> > > How about using stuffs of drm_prime instead of specific ones? Seem like
> > that
> > > we could replace specific dmabuf stuffs with common ones of drm_prime,
> > at
> > > least in case of Exynos: i.e. each driver can export a gem to a dmabuf
> > > through drm_gem_prime_export function of drm_prime instead of specific
> > one.
> > > By doing so, I think we could remove duplicated codes of drivers,
> > specific
> > > dmabuf stuffs. I'm not sure but it seems like that there is any reason
> > you
> > > try to use existing stuffs with a little change: maybe the stuffs of
> > > drm_prime couldn't be used for all drm drivers commonly.
> > 
> > I have to admit that I didn't really understand your email, mostly
> > since you talk about "stuff" and "stuffs" and I didn't really grok
> > which piece of code you actually mean. Can you pls elaborate, maybe
> > taking the functions for exynos as an example?
> 
> You have posted one patch that makes i915/exynos drivers use
> drm_gem_dmabuf_release function commonly. But my opinion is that we could
> use not only drm_gem_dmabuf_release function but also other functions of
> drm_prime commonly. I think that could be done simply like below,
> 
> In drivers/gpu/drm/i915/i915_dev.c,
>   Static struct drm_driver driver = {
>   ...
>   .gem_prime_export = drm_gem_prime_export,
>   .gem_prime_import = drm_gem_prime_import,
>   ...
> 
> We are using driver specific dma_buf_ops, i915_dmabuf_ops for i915 and
> exynos_dmabuf_ops for exynos. So my opinion is to use
> drm_gem_prime_dmabuf_ops of drm_prime instead. However, for this, we have to
> change specific export and import functions to exported drm_prim's ones,
> drm_gem_prime_export and drm_gem_prime_import. And I thought maybe you
> caught that but you used only drm_gem_dmabuf_release function among them of
> drm_prime if there is no my missing point. So I guess maybe there is any
> reason in doing so.

Ah, now I understand.

Yeah, there's probably some room to share more code, otoh prime is still
rather new so I prefer to keep code separate if it's not obviously the
same code. That makes experimentation a bit easier.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[3.10rc6] /proc/dri/0/vma broken on nouveau.