Re: [RFCv1 12/12] ARM: add get_user() support for 8 byte types

2013-10-07 Thread Russell King - ARM Linux 
On Sat, Oct 05, 2013 at 08:45:50PM -0400, Rob Clark wrote:
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
> 
> v1: original
> v2: pass correct size to check_uaccess, and better handling of narrowing
> double word read with __get_user_xb() (Russell King's suggestion)

I thought we had decided not to support this for 32-bit because x86_32
had problems here as well:

#ifdef CONFIG_X86_32
#define __get_user_asm_u64(x, ptr, retval, errret)  (x) = __get_user_bad()
#define __get_user_asm_ex_u64(x, ptr)   (x) = __get_user_bad()
#else
#define __get_user_asm_u64(x, ptr, retval, errret) \
 __get_user_asm(x, ptr, retval, "q", "", "=r", errret)
#define __get_user_asm_ex_u64(x, ptr) \
 __get_user_asm_ex(x, ptr, "q", "", "=r")
#endif

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

Re: [RFCv1 12/12] ARM: add get_user() support for 8 byte types

2013-10-07 Thread Russell King - ARM Linux 
On Sun, Oct 06, 2013 at 10:09:34AM -0400, Rob Clark wrote:
> On Sun, Oct 6, 2013 at 4:53 AM, Russell King - ARM Linux
>  wrote:
> > On Sat, Oct 05, 2013 at 08:45:50PM -0400, Rob Clark wrote:
> >> A new atomic modeset/pageflip ioctl being developed in DRM requires
> >> get_user() to work for 64bit types (in addition to just put_user()).
> >>
> >> v1: original
> >> v2: pass correct size to check_uaccess, and better handling of narrowing
> >> double word read with __get_user_xb() (Russell King's suggestion)
> >
> > I thought we had decided not to support this for 32-bit because x86_32
> > had problems here as well:
> 
> I don't remember.. actually I didn't even realize it wasn't merged
> until I tried to build with the atomic modeset ioctl.
> 
> Ville did have a patch to add it for x86_32, and that patch appears to
> be merged (96477b4c), so I just assume it wasn't removed since then.

Okay, the code I quoted is for __get_user() not get_user().

This is roughly what we (hpa/myself) came up with for ARM which did get
things working, but itw as x86 which made us decide not to persue this.
I've added the __get_user_8 implementation to this.  The __inttype()
thing was hpa's idea.

 arch/arm/include/asm/uaccess.h |   17 +
 arch/arm/lib/getuser.S |   33 -
 2 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 72abdc5..747f2cb 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -93,6 +93,9 @@ static inline void set_fs(mm_segment_t fs)
: "cc"); \
flag; })
 
+#define __inttype(x) \
+   __typeof__(__builtin_choose_expr(sizeof(x) > sizeof(0UL), 0ULL, 0UL))
+
 /*
  * Single-value transfer routines.  They automatically use the right
  * size if we just have the right pointer type.  Note that the functions
@@ -107,14 +110,16 @@ static inline void set_fs(mm_segment_t fs)
 extern int __get_user_1(void *);
 extern int __get_user_2(void *);
 extern int __get_user_4(void *);
+extern int __get_user_8(void *);
 
-#define __GUP_CLOBBER_1"lr", "cc"
+#define __GUP_CLOBBER_1 "lr", "cc"
 #ifdef CONFIG_CPU_USE_DOMAINS
-#define __GUP_CLOBBER_2"ip", "lr", "cc"
+#define __GUP_CLOBBER_2 "ip", "lr", "cc"
 #else
 #define __GUP_CLOBBER_2 "lr", "cc"
 #endif
-#define __GUP_CLOBBER_4"lr", "cc"
+#define __GUP_CLOBBER_4 "lr", "cc"
+#define __GUP_CLOBBER_8 "lr", "cc"
 
 #define __get_user_x(__r2,__p,__e,__l,__s) \
   __asm__ __volatile__ (   \
@@ -129,7 +134,7 @@ extern int __get_user_4(void *);
({  \
unsigned long __limit = current_thread_info()->addr_limit - 1; \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
-   register unsigned long __r2 asm("r2");  \
+   register __inttype(*p) __r2 asm("r2");  \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \
switch (sizeof(*(__p))) {   \
@@ -142,6 +147,9 @@ extern int __get_user_4(void *);
case 4: \
__get_user_x(__r2, __p, __e, __l, 4);   \
break;  \
+   case 8: \
+   __get_user_x(__r2, __p, __e, __l, 8);   \
+   break;  \
default: __e = __get_user_bad(); break; \
}   \
x = (typeof(*(p))) __r2;\
@@ -150,6 +158,7 @@ extern int __get_user_4(void *);
 
 #define get_user(x,p)  \
({  \
+   __chk_user_ptr(ptr);\
might_fault();  \
__get_user_check(x,p);  \
 })
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..3583c83 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
  * Inputs: r0 contains the address
  * r1 contains the address limit, which must be preserved
  * Outputs:r0 is the error code
- * r2 contains the zero-extended value
+ * r2/r3 contains the zero-extended value
  * lr corrupted
  *
  * No other registers must be altered.  (see 
@@ -32,6 +32,14 @@
 #include 
 #include 
 
+#ifdef

[PATCH 0/5] Armada DRM stuff

2013-10-07 Thread Russell King - ARM Linux 
The Armada DRM drivers again, along with the TDA998x HDMI output support,
and an illustration to show how to add Armada 610 support (and others.)

Rob has looked at this a couple of times since its last posting, and
has provided additional useful feedback which has been incorporated.
I believe all the major issues have been addressed now.

 drivers/gpu/drm/Kconfig |2 +
 drivers/gpu/drm/Makefile|1 +
 drivers/gpu/drm/armada/Kconfig  |   24 +
 drivers/gpu/drm/armada/Makefile |8 +
 drivers/gpu/drm/armada/armada_510.c |   87 +++
 drivers/gpu/drm/armada/armada_610.c |   49 ++
 drivers/gpu/drm/armada/armada_crtc.c| 1099 +++
 drivers/gpu/drm/armada/armada_crtc.h|   83 +++
 drivers/gpu/drm/armada/armada_debugfs.c |  183 +
 drivers/gpu/drm/armada/armada_drm.h |  114 
 drivers/gpu/drm/armada/armada_drv.c |  428 
 drivers/gpu/drm/armada/armada_fb.c  |  170 +
 drivers/gpu/drm/armada/armada_fb.h  |   24 +
 drivers/gpu/drm/armada/armada_fbdev.c   |  202 ++
 drivers/gpu/drm/armada/armada_gem.c |  616 +
 drivers/gpu/drm/armada/armada_gem.h |   52 ++
 drivers/gpu/drm/armada/armada_hw.h  |  326 +
 drivers/gpu/drm/armada/armada_ioctlP.h  |   18 +
 drivers/gpu/drm/armada/armada_output.c  |  158 +
 drivers/gpu/drm/armada/armada_output.h  |   39 ++
 drivers/gpu/drm/armada/armada_overlay.c |  477 ++
 drivers/gpu/drm/armada/armada_slave.c   |  139 
 drivers/gpu/drm/armada/armada_slave.h   |   26 +
 drivers/gpu/drm/i2c/tda998x_drv.c   |2 +
 include/drm/drm_crtc.h  |   17 +
 include/uapi/drm/armada_drm.h   |   45 ++
 26 files changed, 4389 insertions(+), 0 deletions(-)

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

[PATCH 1/5] drm/i2c: tda998x: set VIF for full range, underscanned display

2013-10-07 Thread Russell King 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 60e8404..704040b5 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -549,6 +549,8 @@ tda998x_write_avi(struct drm_encoder *encoder, struct 
drm_display_mode *mode)
buf[HB(0)] = 0x82;
buf[HB(1)] = 0x02;
buf[HB(2)] = 13;
+   buf[PB(1)] = 2; /* underscanned display */
+   buf[PB(3)] = 2 << 2; /* full range */
buf[PB(4)] = drm_match_cea_mode(mode);
 
tda998x_write_if(encoder, DIP_IF_FLAGS_IF2, REG_IF2_HB0, buf,
-- 
1.7.4.4

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

[PATCH 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

2013-10-07 Thread Russell King 
This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
64x32 resolutions.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_510.c  |1 +
 drivers/gpu/drm/armada/armada_crtc.c |  245 +-
 drivers/gpu/drm/armada/armada_crtc.h |9 ++
 drivers/gpu/drm/armada/armada_drm.h  |1 +
 drivers/gpu/drm/armada/armada_hw.h   |6 +-
 5 files changed, 256 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_510.c 
b/drivers/gpu/drm/armada/armada_510.c
index a016888..59948ef 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -80,6 +80,7 @@ static int armada510_crtc_compute_clock(struct armada_crtc 
*dcrtc,
 
 const struct armada_variant armada510_ops = {
.has_spu_adv_reg = true,
+   .spu_adv_reg = ADV_HWC32ENABLE | ADV_HWC32ARGB | ADV_HWC32BLEND,
.init = armada510_init,
.crtc_init = armada510_crtc_init,
.crtc_compute_clock = armada510_crtc_compute_clock,
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 7b379fd..e8605bf 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -381,8 +381,21 @@ void armada_drm_crtc_irq(struct armada_crtc *dcrtc, u32 
stat)
val = readl_relaxed(base + LCD_SPU_ADV_REG);
val &= ~(ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF | ADV_VSYNCOFFEN);
val |= dcrtc->v[i].spu_adv_reg;
-   writel_relaxed(val, dcrtc->base + LCD_SPU_ADV_REG);
+   writel_relaxed(val, base + LCD_SPU_ADV_REG);
}
+
+   if (stat & DUMB_FRAMEDONE && dcrtc->cursor_update) {
+   writel_relaxed(dcrtc->cursor_hw_pos,
+  base + LCD_SPU_HWC_OVSA_HPXL_VLN);
+   writel_relaxed(dcrtc->cursor_hw_sz,
+  base + LCD_SPU_HWC_HPXL_VLN);
+   armada_updatel(CFG_HWC_ENA,
+  CFG_HWC_ENA | CFG_HWC_1BITMOD | CFG_HWC_1BITENA,
+  base + LCD_SPU_DMA_CTRL0);
+   dcrtc->cursor_update = false;
+   armada_drm_crtc_disable_irq(dcrtc, DUMB_FRAMEDONE_ENA);
+   }
+
spin_unlock(&dcrtc->irq_lock);
 
if (stat & GRA_FRAME_IRQ) {
@@ -522,7 +535,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
adj->crtc_htotal;
dcrtc->v[1].spu_v_porch = tm << 16 | bm;
val = adj->crtc_hsync_start;
-   dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+   dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+   priv->variant->spu_adv_reg;
 
if (interlaced) {
/* Odd interlaced frame */
@@ -530,7 +544,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
(1 << 16);
dcrtc->v[0].spu_v_porch = dcrtc->v[1].spu_v_porch + 1;
val = adj->crtc_hsync_start - adj->crtc_htotal / 2;
-   dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+   dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+   priv->variant->spu_adv_reg;
} else {
dcrtc->v[0] = dcrtc->v[1];
}
@@ -545,10 +560,11 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_h_total,
   LCD_SPUT_V_H_TOTAL);
 
-   if (priv->variant->has_spu_adv_reg)
+   if (priv->variant->has_spu_adv_reg) {
armada_reg_queue_mod(regs, i, dcrtc->v[0].spu_adv_reg,
 ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF |
 ADV_VSYNCOFFEN, LCD_SPU_ADV_REG);
+   }
 
val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.fb)->fmt);
@@ -640,11 +656,230 @@ static const struct drm_crtc_helper_funcs 
armada_crtc_helper_funcs = {
.disable= armada_drm_crtc_disable,
 };
 
+static void armada_load_cursor_argb(void __iomem *base, uint32_t *pix,
+   unsigned stride, unsigned width, unsigned height)
+{
+   uint32_t addr;
+   unsigned y;
+
+   addr = SRAM_HWC32_RAM1;
+   for (y = 0; y < height; y++) {
+   uint32_t *p = &pix[y * stride];
+   unsigned x;
+
+   for (x = 0; x < width; x++, p++) {
+   uint32_t val = *p;
+
+   val = (val & 0xff00ff00) |
+ (val & 0x00ff) << 16 |
+ (val & 0x00ff) >> 16;
+
+   writel_relaxed(val,
+  base + LCD_SPU_SRAM_WRDAT);
+   writel_relaxed(addr | SRAM_WRITE,
+  base +

[PATCH 4/5] DRM: Armada: start of MMP2/MMP3 support

2013-10-07 Thread Russell King 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/Makefile  |1 +
 drivers/gpu/drm/armada/armada_610.c  |   49 ++
 drivers/gpu/drm/armada/armada_crtc.c |1 +
 drivers/gpu/drm/armada/armada_drm.h  |1 +
 drivers/gpu/drm/armada/armada_drv.c  |6 
 drivers/gpu/drm/armada/armada_hw.h   |8 +
 6 files changed, 66 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/armada/armada_610.c

diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile
index d6f43e0..088db4a 100644
--- a/drivers/gpu/drm/armada/Makefile
+++ b/drivers/gpu/drm/armada/Makefile
@@ -2,6 +2,7 @@ armada-y:= armada_crtc.o armada_drv.o armada_fb.o 
armada_fbdev.o \
   armada_gem.o armada_output.o armada_overlay.o \
   armada_slave.o
 armada-y   += armada_510.o
+armada-y   += armada_610.o
 armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
 
 obj-$(CONFIG_DRM_ARMADA) := armada.o
diff --git a/drivers/gpu/drm/armada/armada_610.c 
b/drivers/gpu/drm/armada/armada_610.c
new file mode 100644
index 000..36a10e3
--- /dev/null
+++ b/drivers/gpu/drm/armada/armada_610.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (C) 2012 Russell King
+ *
+ * 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.
+ *
+ * Armada 610/MMP2/MMP3 variant support
+ */
+#include 
+#include 
+#include 
+#include 
+#include "armada_crtc.h"
+#include "armada_drm.h"
+#include "armada_hw.h"
+
+static int mmp23_init(struct armada_private *priv, struct device *dev)
+{
+   priv->extclk[0] = devm_clk_get(dev, NULL);
+
+   if (IS_ERR(priv->extclk[0]) && PTR_ERR(priv->extclk[0]) == -ENOENT)
+   priv->extclk[0] = ERR_PTR(-EPROBE_DEFER);
+
+   return PTR_RET(priv->extclk[0]);
+}
+
+/*
+ * This gets called with sclk = NULL to test whether the mode is
+ * supportable, and again with sclk != NULL to set the clocks up for
+ * that.  The former can return an error, but the latter is expected
+ * not to.
+ */
+static int mmp23_crtc_compute_clock(struct armada_crtc *dcrtc,
+   const struct drm_display_mode *mode, uint32_t *sclk)
+{
+   /*
+* on MMP3 bits 31:29 select the clock, OLPC wants 0x1 here, LCD clock 1
+* on MMP2 bits 31:30 select the clock, OLPC wants 0x1 here, LCD clock 1
+*/
+   *sclk = 0x20001100; // FIXME hardcoded mmp3 value
+
+   return 0;
+}
+
+const struct armada_variant mmp23_ops = {
+   .init = mmp23_init,
+   .crtc_compute_clock = mmp23_crtc_compute_clock,
+};
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index e8605bf..b5877ee 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1054,6 +1054,7 @@ int armada_drm_crtc_create(struct drm_device *dev, 
unsigned num,
dcrtc->clk = ERR_PTR(-EINVAL);
dcrtc->csc_yuv_mode = CSC_AUTO;
dcrtc->csc_rgb_mode = CSC_AUTO;
+   /* FIXME: MMP2/MMP3: OLPC panel is RGB666 */
dcrtc->cfg_dumb_ctrl = DUMB24_RGB888_0;
dcrtc->spu_iopad_ctrl = CFG_VSCALE_LN_EN | CFG_IOPAD_DUMB24;
spin_lock_init(&dcrtc->irq_lock);
diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index eef09ec..f52fccb 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -70,6 +70,7 @@ struct armada_variant {
 
 /* Variant ops */
 extern const struct armada_variant armada510_ops;
+extern const struct armada_variant mmp23_ops;
 
 struct armada_private {
const struct armada_variant *variant;
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 7bfab9a..db62f1b 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -344,6 +344,12 @@ static const struct platform_device_id 
armada_drm_platform_ids[] = {
.name   = "armada-drm",
.driver_data= (unsigned long)&armada510_ops,
}, {
+   .name   = "armada-610-drm", /* aka MMP2 */
+   .driver_data= (unsigned long)&mmp23_ops,
+   }, {
+   .name   = "mmp3-drm",
+   .driver_data= (unsigned long)&mmp23_ops,
+   }, {
.name   = "armada-510-drm",
.driver_data= (unsigned long)&armada510_ops,
},
diff --git a/drivers/gpu/drm/armada/armada_hw.h 
b/drivers/gpu/drm/armada/armada_hw.h
index 27319a8..1688716 100644
--- a/drivers/gpu/drm/armada/armada_hw.h
+++ b/drivers/gpu/drm/armada/armada_hw.h
@@ -74,6 +74,7 @@ enum {
LCD_SPU_IOPAD_CONTROL   = 0x01bc,
LCD_SPU_IRQ_ENA = 0x01c0,
LCD_SPU_IRQ_ISR = 0x01c4,
+   LCD_MISC_CNTL   = 0x01c8,   /* Armada 168 */
 };
 
 /* For LCD_

[PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Russell King 
Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/Kconfig  |9 +++
 drivers/gpu/drm/armada/armada_drv.c |   42 +++
 2 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index c7a0a94..87e62dd 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -13,3 +13,12 @@ config DRM_ARMADA
  This driver provides no built-in acceleration; acceleration is
  performed by other IP found on the SoC.  This driver provides
  kernel mode setting and buffer management to userspace.
+
+config DRM_ARMADA_TDA1998X
+   bool "Support TDA1998X HDMI output"
+   depends on DRM_ARMADA != n
+   depends on I2C && DRM_I2C_NXP_TDA998X = y
+   default y
+   help
+ Support the TDA1998x HDMI output device found on the Solid-Run
+ CuBox.
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index db62f1b..69517cf 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -16,6 +16,42 @@
 #include 
 #include "armada_ioctlP.h"
 
+#ifdef CONFIG_DRM_ARMADA_TDA1998X
+#include 
+#include "armada_slave.h"
+
+static struct tda998x_encoder_params params = {
+   /* With 0x24, there is no translation between vp_out and int_vp
+   FB  LCD out PinsVIP Int Vp
+   R:23:16 R:7:0   VPC7:0  7:0 7:0[R]
+   G:15:8  G:15:8  VPB7:0  23:16   23:16[G]
+   B:7:0   B:23:16 VPA7:0  15:815:8[B]
+   */
+   .swap_a = 2,
+   .swap_b = 3,
+   .swap_c = 4,
+   .swap_d = 5,
+   .swap_e = 0,
+   .swap_f = 1,
+   .audio_cfg = BIT(2),
+   .audio_frame[1] = 1,
+   .audio_format = AFMT_SPDIF,
+   .audio_sample_rate = 44100,
+};
+
+static const struct armada_drm_slave_config tda19988_config = {
+   .i2c_adapter_id = 0,
+   .crtcs = 1 << 0, /* Only LCD0 at the moment */
+   .polled = DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT,
+   .interlace_allowed = true,
+   .info = {
+   .type = "tda998x",
+   .addr = 0x70,
+   .platform_data = ¶ms,
+   },
+};
+#endif
+
 static void armada_drm_unref_work(struct work_struct *work)
 {
struct armada_private *priv =
@@ -134,6 +170,12 @@ static int armada_drm_load(struct drm_device *dev, 
unsigned long flags)
goto err_kms;
}
 
+#ifdef CONFIG_DRM_ARMADA_TDA1998X
+   ret = armada_drm_connector_slave_create(dev, &tda19988_config);
+   if (ret)
+   goto err_kms;
+#endif
+
ret = drm_vblank_init(dev, n);
if (ret)
goto err_kms;
-- 
1.7.4.4

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

Re: [PATCH] drm/dp: Clarify automated test constant and add constant for FAUX test pattern

2013-10-07 Thread Jani Nikula 
On Fri, 04 Oct 2013, Todd Previte  wrote:
>   - DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN 
> to clarify
>   - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX
>
> Signed-off-by: Todd Previte 

Reviewed-by: Jani Nikula 


> ---
>  include/drm/drm_dp_helper.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ae8dbfb..34c8202 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -266,9 +266,10 @@
>  
>  #define DP_TEST_REQUEST  0x218
>  # define DP_TEST_LINK_TRAINING   (1 << 0)
> -# define DP_TEST_LINK_PATTERN(1 << 1)
> +# define DP_TEST_LINK_VIDEO_PATTERN  (1 << 1)
>  # define DP_TEST_LINK_EDID_READ  (1 << 2)
>  # define DP_TEST_LINK_PHY_TEST_PATTERN   (1 << 3) /* DPCD >= 1.1 */
> +# define DP_TEST_LINK_FAUX_PATTERN   (1 << 4) /* DPCD >= 1.2 */
>  
>  #define DP_TEST_LINK_RATE0x219
>  # define DP_LINK_RATE_162(0x6)
> -- 
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

2013-10-07 Thread Rafał Miłecki 
For the last few days it was I was testing fglrx on various cards to
trace HDMI setup. One thing that was killing me was no HDMI audio when
using some generic/cheap DVI to HDMI adapter with my HD 4850.

I started digging and it has appeared to be common problem when using
Catalyst / fglrx. Windows users were also experiencing this problem,
without any known workaround.

I've found one explanation by droidhacker:
http://phoronix.com/forums/showthread.php?23451-HDMI-Audio-with-fglrx&p=124891#post124891
> If that is the case, you need to be aware that AMD sells a couple of 
> PROPRIETARY adapter plugs, which fglrx can DETECT in order to decide whether 
> or not to enable HDMI audio.

That sounded weird, I didn't believe that. There wasn't any
explanation how it's handled, I couldn't imagine how fglrx can "talk"
to the simple adapter. Overall it should just map the PINs, not
include any logic!

But today I've found another discussion:
http://www.avsforum.com/t/1080627/atis-magic-dvi-to-hdmi-dongle

That finally explains what is happening. So it appears that ATI's
proprietary adapter include some tiny I2C protocol that allows
identifying them! It seems that Catalyst / fglrx uses some simple I2C
talk to check if the adapter is made by ATI and allows or refuses to
use HDMI mode.
That also explains why radeon driver never had any problems with audio
over DVI, no matter what adapter was used.

Another ATI/fgllx mystery explained ;)

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

[Bug 70035] GPU Lockup on AMD RS880 HD4200

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70035

--- Comment #10 from Tasev  ---
(In reply to comment #9)
> Tasev,
> 
> If your issue is related to mine then the corresponding debs from the
> 9.3~git1309201759 Sept 20th release should work :-
> 
> https://launchpad.net/~oibaf/+archive/graphics-drivers/+build/5036069 [amd64]
> https://launchpad.net/~oibaf/+archive/graphics-drivers/+build/5036070 [i386]
> 
> 
> ...and the debs from Sept 23rd 9.3~git1309231016 should fail :-
> 
> https://launchpad.net/~oibaf/+archive/graphics-drivers/+build/5042397 [amd64]
> https://launchpad.net/~oibaf/+archive/graphics-drivers/+build/5042398 [i386]
> 
> 
> To find out which mesa packages you have installed (hopefully nothing else
> has a matching version string) :-
> 
> dpkg -l | grep ".*9.3~git[0-9]*.[0-9a-z]*~gd~.*"
> 
> 
> To install the debs download the appropriate packages to
> /path/to/some/directory and then :-
> 
> cd /path/to/some/directory
> 
> sudo dpkg -i *.deb
> 
> 
> You can usually find the debs from an older mesa version by looking in apt's
> archives :-
> 
> ls -lrt /var/cache/apt/archives/*_9.3~git[0-9]*.[0-9a-z]*~gd~*
> 
> And copy them somewhere for easy installation :-
> 
> cp /var/cache/apt/archives/*_9.3~git1309040912.644fbb~gd~*
> /path/to/some/directory
> 
> 
> Hopefully you can find out which version breaks your install or at least get
> things working again.

Thank you Blake,

I reverted the mesa deb's to 9.3~git1309201759 Sept 20th version and my system
is working again.

Then i update my system with the debs from Sept 23rd 9.3~git1309231016 but my
system is still ok.

Only updating to the deb's from Sept 30th 9.3~git1309300954.868791 break my
system so it's probably a different issue from your.

Thank you again for your help, i have a working system again now.

-- 
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 v2 00/27] drm/tegra: Repatriation and DSI support

2013-10-07 Thread Thierry Reding 
This series of patches moves the Tegra DRM driver back to drivers/gpu/drm
where it belongs. While this is not entirely trivial, decoupling it from the
host1x driver will make things easier in the long run.

Patches 1 to 14 are mostly cleanup and decoupling from host1x. After those
patches, the DRM specific parts are back in drivers/gpu/drm/tegra in which
they originated and all host1x support code that they use is exported by the
host1x driver and exposed in the include/linux/host1x.h header file.

The larger part of patches 15 to 20 have been contributed by Mikko Perttunen
and add support for HDMI on Tegra114.

Patches 21 to 23 are the panel support patches, addressing comments that I
received on an earlier version.

Patch 24 fixes an issue with the DPMS mode tracking. Connectors default to
off on Tegra, so the initial DPMS mode needs to reflect that.

Patches 25 and 27 add support for DSI and gr2d on Tegra114.

Thierry

Mikko Perttunen (4):
  drm/tegra: Add Tegra114 display controller support
  drm/tegra: Add Tegra114 HDMI support
  drm/tegra: hdmi: Detect DVI-only displays
  host1x: hdmi: Enable VDD earlier for hotplug/DDC

Thierry Reding (23):
  drm/tegra: Remove unused fields
  drm/tegra: Cleanup tegra_dc structure
  drm/tegra: Rename host1x_drm structure to tegra_drm
  drm/tegra: Rename host1x_drm_file to tegra_drm_file
  drm/tegra: Rename host1x_drm_context to tegra_drm_context
  gpu: host1x: Cleanup includes
  gpu: host1x: Do not discard .remove()
  drm/tegra: gr2d: Miscellaneous cleanups
  drm/tegra: gem: Miscellaneous cleanups
  gpu: host1x: Make host1x header file public
  drm/tegra: Introduce tegra_drm_client structure
  gpu: host1x: Expose syncpt and channel functionality
  drm/tegra: Move subdevice infrastructure to host1x
  drm/tegra: Move driver to DRM tree
  gpu: host1x: Add support for Tegra114
  drm/tegra: hdmi: Rename tegra{2,3} to tegra{20,30}
  drm: Add panel support
  drm/panel: Add simple panel support
  drm/tegra: Implement panel support
  drm/tegra: Start connectors with correct DPMS mode
  gpu: host1x: Add MIPI pad calibration support
  drm/tegra: Add DSI support
  drm/tegra: Add Tegra114 gr2d support

 .../devicetree/bindings/panel/auo,b101aw03.txt |7 +
 .../bindings/panel/chunghwa,claa101wb03.txt|7 +
 .../bindings/panel/panasonic,vvx10f004b00.txt  |7 +
 .../devicetree/bindings/panel/simple-panel.txt |   21 +
 MAINTAINERS|2 +
 drivers/gpu/drm/Kconfig|4 +
 drivers/gpu/drm/Makefile   |3 +
 drivers/gpu/drm/drm_panel.c|   96 ++
 drivers/gpu/drm/panel/Kconfig  |   17 +
 drivers/gpu/drm/panel/Makefile |1 +
 drivers/gpu/drm/panel/panel-simple.c   |  339 +++
 drivers/gpu/{host1x/drm => drm/tegra}/Kconfig  |   11 +-
 drivers/gpu/drm/tegra/Makefile |   16 +
 drivers/gpu/drm/tegra/bus.c|  123 +++
 drivers/gpu/{host1x/drm => drm/tegra}/dc.c |   34 +-
 drivers/gpu/{host1x/drm => drm/tegra}/dc.h |1 +
 drivers/gpu/{host1x/drm => drm/tegra}/drm.c|  441 -
 drivers/gpu/{host1x/drm => drm/tegra}/drm.h|   92 +-
 drivers/gpu/drm/tegra/dsi.c| 1026 
 drivers/gpu/{host1x/drm => drm/tegra}/fb.c |   16 +-
 drivers/gpu/{host1x/drm => drm/tegra}/gem.c|   30 +-
 drivers/gpu/{host1x/drm => drm/tegra}/gem.h|4 +-
 drivers/gpu/{host1x/drm => drm/tegra}/gr2d.c   |  176 ++--
 drivers/gpu/{host1x/drm => drm/tegra}/hdmi.c   |  177 +++-
 drivers/gpu/{host1x/drm => drm/tegra}/hdmi.h   |  152 +++
 drivers/gpu/{host1x/drm => drm/tegra}/output.c |   40 +-
 drivers/gpu/{host1x/drm => drm/tegra}/rgb.c|3 -
 drivers/gpu/host1x/Kconfig |2 -
 drivers/gpu/host1x/Makefile|   14 +-
 drivers/gpu/host1x/bus.c   |  309 ++
 drivers/gpu/host1x/{host1x_client.h => bus.h}  |   24 +-
 drivers/gpu/host1x/cdma.c  |2 +-
 drivers/gpu/host1x/channel.h   |6 -
 drivers/gpu/host1x/dev.c   |   73 +-
 drivers/gpu/host1x/dev.h   |9 +-
 drivers/gpu/host1x/host1x.h|   30 -
 drivers/gpu/host1x/host1x_bo.h |   87 --
 drivers/gpu/host1x/hw/channel_hw.c |4 +-
 drivers/gpu/host1x/hw/debug_hw.c   |8 -
 drivers/gpu/host1x/hw/host1x02.c   |   42 +
 drivers/gpu/host1x/hw/host1x02.h   |   26 +
 drivers/gpu/host1x/hw/hw_host1x02_channel.h|  121 +++
 drivers/gpu/host1x/hw/hw_host1x02_sync.h   |  243 +
 drivers/gpu/host1x/hw/hw_host1x02_uclass.h |  175 
 drivers/gpu/host1x/job.c   |2 +-
 drivers/gpu/h

[PATCH v2 01/27] drm/tegra: Remove unused fields

2013-10-07 Thread Thierry Reding 
Some of the fields in struct host1x_drm haven't been used for a while,
so remove them.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/drm.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 02ce020..f7cd946 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -33,10 +33,6 @@ struct tegra_fbdev {
 struct host1x_drm {
struct drm_device *drm;
struct device *dev;
-   void __iomem *regs;
-   struct clk *clk;
-   int syncpt;
-   int irq;
 
struct mutex drm_clients_lock;
struct list_head drm_clients;
-- 
1.8.4

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

[PATCH v2 02/27] drm/tegra: Cleanup tegra_dc structure

2013-10-07 Thread Thierry Reding 
Remove the unused host1x field from the structure and group the fields
more logically.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/drm.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index f7cd946..b8d9f43 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -94,16 +94,13 @@ struct tegra_output;
 
 struct tegra_dc {
struct host1x_client client;
-   spinlock_t lock;
-
-   struct host1x_drm *host1x;
struct device *dev;
+   spinlock_t lock;
 
struct drm_crtc base;
int pipe;
 
struct clk *clk;
-
void __iomem *regs;
int irq;
 
-- 
1.8.4

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

[PATCH v2 03/27] drm/tegra: Rename host1x_drm structure to tegra_drm

2013-10-07 Thread Thierry Reding 
The host1x and Tegra DRM drivers are currently tightly coupled. Renaming
the structure marks the boundary more clearly.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/dev.c   |   2 +-
 drivers/gpu/host1x/drm/dc.c|   8 +-
 drivers/gpu/host1x/drm/drm.c   | 169 ++---
 drivers/gpu/host1x/drm/drm.h   |  18 ++--
 drivers/gpu/host1x/drm/fb.c|  14 +--
 drivers/gpu/host1x/drm/gr2d.c  |   8 +-
 drivers/gpu/host1x/drm/hdmi.c  |   8 +-
 drivers/gpu/host1x/host1x_client.h |   4 +-
 8 files changed, 115 insertions(+), 116 deletions(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 4716302..0f7b44c 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -163,7 +163,7 @@ static int host1x_probe(struct platform_device *pdev)
 
host1x_debug_init(host);
 
-   host1x_drm_alloc(pdev);
+   tegra_drm_alloc(pdev);
 
return 0;
 
diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index b1a05ad..c4765b3 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -1109,7 +1109,7 @@ static const struct host1x_client_ops dc_client_ops = {
 
 static int tegra_dc_probe(struct platform_device *pdev)
 {
-   struct host1x_drm *host1x = host1x_get_drm_data(pdev->dev.parent);
+   struct tegra_drm *tegra = host1x_get_drm_data(pdev->dev.parent);
struct resource *regs;
struct tegra_dc *dc;
int err;
@@ -1153,7 +1153,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
return err;
}
 
-   err = host1x_register_client(host1x, &dc->client);
+   err = host1x_register_client(tegra, &dc->client);
if (err < 0) {
dev_err(&pdev->dev, "failed to register host1x client: %d\n",
err);
@@ -1167,11 +1167,11 @@ static int tegra_dc_probe(struct platform_device *pdev)
 
 static int tegra_dc_remove(struct platform_device *pdev)
 {
-   struct host1x_drm *host1x = host1x_get_drm_data(pdev->dev.parent);
+   struct tegra_drm *tegra = host1x_get_drm_data(pdev->dev.parent);
struct tegra_dc *dc = platform_get_drvdata(pdev);
int err;
 
-   err = host1x_unregister_client(host1x, &dc->client);
+   err = host1x_unregister_client(tegra, &dc->client);
if (err < 0) {
dev_err(&pdev->dev, "failed to unregister host1x client: %d\n",
err);
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 8c61cee..7230b40 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -30,56 +30,55 @@
 #define DRIVER_MINOR 0
 #define DRIVER_PATCHLEVEL 0
 
-struct host1x_drm_client {
+struct host1x_subdev {
struct host1x_client *client;
struct device_node *np;
struct list_head list;
 };
 
-static int host1x_add_drm_client(struct host1x_drm *host1x,
-struct device_node *np)
+static int host1x_subdev_add(struct tegra_drm *tegra, struct device_node *np)
 {
-   struct host1x_drm_client *client;
+   struct host1x_subdev *subdev;
 
-   client = kzalloc(sizeof(*client), GFP_KERNEL);
-   if (!client)
+   subdev = kzalloc(sizeof(*subdev), GFP_KERNEL);
+   if (!subdev)
return -ENOMEM;
 
-   INIT_LIST_HEAD(&client->list);
-   client->np = of_node_get(np);
+   INIT_LIST_HEAD(&subdev->list);
+   subdev->np = of_node_get(np);
 
-   list_add_tail(&client->list, &host1x->drm_clients);
+   list_add_tail(&subdev->list, &tegra->subdevs);
 
return 0;
 }
 
-static int host1x_activate_drm_client(struct host1x_drm *host1x,
- struct host1x_drm_client *drm,
- struct host1x_client *client)
+static int host1x_subdev_register(struct tegra_drm *tegra,
+ struct host1x_subdev *subdev,
+ struct host1x_client *client)
 {
-   mutex_lock(&host1x->drm_clients_lock);
-   list_del_init(&drm->list);
-   list_add_tail(&drm->list, &host1x->drm_active);
-   drm->client = client;
-   mutex_unlock(&host1x->drm_clients_lock);
+   mutex_lock(&tegra->subdevs_lock);
+   list_del_init(&subdev->list);
+   list_add_tail(&subdev->list, &tegra->active);
+   subdev->client = client;
+   mutex_unlock(&tegra->subdevs_lock);
 
return 0;
 }
 
-static int host1x_remove_drm_client(struct host1x_drm *host1x,
-   struct host1x_drm_client *client)
+static int host1x_subdev_unregister(struct tegra_drm *tegra,
+   struct host1x_subdev *subdev)
 {
-   mutex_lock(&host1x->drm_clients_lock);
-   list_del_init(&client->list);
-   mutex_unlock(&host1x->drm_clients_lock);
+   mutex_lock(&tegra->subdevs_lock);
+   list_del_init(&subdev->list);
+   mutex_unlo

[PATCH v2 04/27] drm/tegra: Rename host1x_drm_file to tegra_drm_file

2013-10-07 Thread Thierry Reding 
This structure extends drm_file with Tegra DRM specific fields and has
nothing to do with host1x. Rename the structure to more clearly mark the
boundaries between host1x and Tegra DRM.

While at it, move the structure definition out of the header. It's never
used outside of the drm.c source file, so it can be defined within that.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/drm.c | 26 +++---
 drivers/gpu/host1x/drm/drm.h |  4 
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 7230b40..67fd856 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -30,6 +30,10 @@
 #define DRIVER_MINOR 0
 #define DRIVER_PATCHLEVEL 0
 
+struct tegra_drm_file {
+   struct list_head contexts;
+};
+
 struct host1x_subdev {
struct host1x_client *client;
struct device_node *np;
@@ -290,7 +294,7 @@ static int tegra_drm_unload(struct drm_device *drm)
 
 static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
 {
-   struct host1x_drm_file *fpriv;
+   struct tegra_drm_file *fpriv;
 
fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
if (!fpriv)
@@ -316,8 +320,8 @@ static void tegra_drm_lastclose(struct drm_device *drm)
 }
 
 #ifdef CONFIG_DRM_TEGRA_STAGING
-static bool host1x_drm_file_owns_context(struct host1x_drm_file *file,
-struct host1x_drm_context *context)
+static bool tegra_drm_file_owns_context(struct tegra_drm_file *file,
+   struct host1x_drm_context *context)
 {
struct host1x_drm_context *ctx;
 
@@ -406,7 +410,7 @@ static int tegra_syncpt_wait(struct drm_device *drm, void 
*data,
 static int tegra_open_channel(struct drm_device *drm, void *data,
  struct drm_file *file)
 {
-   struct host1x_drm_file *fpriv = file->driver_priv;
+   struct tegra_drm_file *fpriv = file->driver_priv;
struct tegra_drm *tegra = drm->dev_private;
struct drm_tegra_open_channel *args = data;
struct host1x_drm_context *context;
@@ -437,11 +441,11 @@ static int tegra_close_channel(struct drm_device *drm, 
void *data,
   struct drm_file *file)
 {
struct drm_tegra_close_channel *args = data;
-   struct host1x_drm_file *fpriv = file->driver_priv;
+   struct tegra_drm_file *fpriv = file->driver_priv;
struct host1x_drm_context *context =
(struct host1x_drm_context *)(uintptr_t)args->context;
 
-   if (!host1x_drm_file_owns_context(fpriv, context))
+   if (!tegra_drm_file_owns_context(fpriv, context))
return -EINVAL;
 
list_del(&context->list);
@@ -453,13 +457,13 @@ static int tegra_close_channel(struct drm_device *drm, 
void *data,
 static int tegra_get_syncpt(struct drm_device *drm, void *data,
struct drm_file *file)
 {
+   struct tegra_drm_file *fpriv = file->driver_priv;
struct drm_tegra_get_syncpt *args = data;
-   struct host1x_drm_file *fpriv = file->driver_priv;
struct host1x_drm_context *context =
(struct host1x_drm_context *)(uintptr_t)args->context;
struct host1x_syncpt *syncpt;
 
-   if (!host1x_drm_file_owns_context(fpriv, context))
+   if (!tegra_drm_file_owns_context(fpriv, context))
return -ENODEV;
 
if (args->index >= context->client->num_syncpts)
@@ -474,12 +478,12 @@ static int tegra_get_syncpt(struct drm_device *drm, void 
*data,
 static int tegra_submit(struct drm_device *drm, void *data,
struct drm_file *file)
 {
+   struct tegra_drm_file *fpriv = file->driver_priv;
struct drm_tegra_submit *args = data;
-   struct host1x_drm_file *fpriv = file->driver_priv;
struct host1x_drm_context *context =
(struct host1x_drm_context *)(uintptr_t)args->context;
 
-   if (!host1x_drm_file_owns_context(fpriv, context))
+   if (!tegra_drm_file_owns_context(fpriv, context))
return -ENODEV;
 
return context->client->ops->submit(context, args, drm, file);
@@ -558,7 +562,7 @@ static void tegra_drm_disable_vblank(struct drm_device 
*drm, int pipe)
 
 static void tegra_drm_preclose(struct drm_device *drm, struct drm_file *file)
 {
-   struct host1x_drm_file *fpriv = file->driver_priv;
+   struct tegra_drm_file *fpriv = file->driver_priv;
struct host1x_drm_context *context, *tmp;
struct drm_crtc *crtc;
 
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 858bfc0..74869d3 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -63,10 +63,6 @@ struct host1x_client_ops {
  struct drm_file *file);
 };
 
-struct host1x_drm_file {
-   struct list_head contexts;
-};
-
 struct host1x_client {
struct tegra_drm *tegra;

[PATCH v2 05/27] drm/tegra: Rename host1x_drm_context to tegra_drm_context

2013-10-07 Thread Thierry Reding 
The structure represents a context associated with a particular process
that has opened the Tegra DRM device and requested a channel. This is a
very DRM-specific notion and has nothing to do with host1x. Rename the
structure to more clearly mark the boundaries between the two.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/drm.c  | 34 +-
 drivers/gpu/host1x/drm/drm.h  |  8 
 drivers/gpu/host1x/drm/gr2d.c |  6 +++---
 3 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 67fd856..7f8f419 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -306,7 +306,7 @@ static int tegra_drm_open(struct drm_device *drm, struct 
drm_file *filp)
return 0;
 }
 
-static void host1x_drm_context_free(struct host1x_drm_context *context)
+static void tegra_drm_context_free(struct tegra_drm_context *context)
 {
context->client->ops->close_channel(context);
kfree(context);
@@ -320,10 +320,15 @@ static void tegra_drm_lastclose(struct drm_device *drm)
 }
 
 #ifdef CONFIG_DRM_TEGRA_STAGING
+static struct tegra_drm_context *tegra_drm_get_context(__u64 context)
+{
+   return (struct tegra_drm_context *)(uintptr_t)context;
+}
+
 static bool tegra_drm_file_owns_context(struct tegra_drm_file *file,
-   struct host1x_drm_context *context)
+   struct tegra_drm_context *context)
 {
-   struct host1x_drm_context *ctx;
+   struct tegra_drm_context *ctx;
 
list_for_each_entry(ctx, &file->contexts, list)
if (ctx == context)
@@ -413,7 +418,7 @@ static int tegra_open_channel(struct drm_device *drm, void 
*data,
struct tegra_drm_file *fpriv = file->driver_priv;
struct tegra_drm *tegra = drm->dev_private;
struct drm_tegra_open_channel *args = data;
-   struct host1x_drm_context *context;
+   struct tegra_drm_context *context;
struct host1x_client *client;
int err = -ENODEV;
 
@@ -442,14 +447,15 @@ static int tegra_close_channel(struct drm_device *drm, 
void *data,
 {
struct drm_tegra_close_channel *args = data;
struct tegra_drm_file *fpriv = file->driver_priv;
-   struct host1x_drm_context *context =
-   (struct host1x_drm_context *)(uintptr_t)args->context;
+   struct tegra_drm_context *context;
+
+   context = tegra_drm_get_context(args->context);
 
if (!tegra_drm_file_owns_context(fpriv, context))
return -EINVAL;
 
list_del(&context->list);
-   host1x_drm_context_free(context);
+   tegra_drm_context_free(context);
 
return 0;
 }
@@ -459,10 +465,11 @@ static int tegra_get_syncpt(struct drm_device *drm, void 
*data,
 {
struct tegra_drm_file *fpriv = file->driver_priv;
struct drm_tegra_get_syncpt *args = data;
-   struct host1x_drm_context *context =
-   (struct host1x_drm_context *)(uintptr_t)args->context;
+   struct tegra_drm_context *context;
struct host1x_syncpt *syncpt;
 
+   context = tegra_drm_get_context(args->context);
+
if (!tegra_drm_file_owns_context(fpriv, context))
return -ENODEV;
 
@@ -480,8 +487,9 @@ static int tegra_submit(struct drm_device *drm, void *data,
 {
struct tegra_drm_file *fpriv = file->driver_priv;
struct drm_tegra_submit *args = data;
-   struct host1x_drm_context *context =
-   (struct host1x_drm_context *)(uintptr_t)args->context;
+   struct tegra_drm_context *context;
+
+   context = tegra_drm_get_context(args->context);
 
if (!tegra_drm_file_owns_context(fpriv, context))
return -ENODEV;
@@ -563,14 +571,14 @@ static void tegra_drm_disable_vblank(struct drm_device 
*drm, int pipe)
 static void tegra_drm_preclose(struct drm_device *drm, struct drm_file *file)
 {
struct tegra_drm_file *fpriv = file->driver_priv;
-   struct host1x_drm_context *context, *tmp;
+   struct tegra_drm_context *context, *tmp;
struct drm_crtc *crtc;
 
list_for_each_entry(crtc, &drm->mode_config.crtc_list, head)
tegra_dc_cancel_page_flip(crtc, file);
 
list_for_each_entry_safe(context, tmp, &fpriv->contexts, list)
-   host1x_drm_context_free(context);
+   tegra_drm_context_free(context);
 
kfree(fpriv);
 }
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index 74869d3..dd6b98b 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -46,7 +46,7 @@ struct tegra_drm {
 
 struct host1x_client;
 
-struct host1x_drm_context {
+struct tegra_drm_context {
struct host1x_client *client;
struct host1x_channel *channel;
struct list_head list;
@@ -56,9 +56,9 @@ struct host1x_client_ops {
int (*drm_init)(struct host1x_client *client, struct drm_

[PATCH v2 06/27] gpu: host1x: Cleanup includes

2013-10-07 Thread Thierry Reding 
Most of the included files are either not required or already included
by some other header file.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/dc.c  |  5 +
 drivers/gpu/host1x/drm/drm.c | 10 --
 drivers/gpu/host1x/drm/fb.c  |  2 --
 drivers/gpu/host1x/drm/gem.c |  9 -
 drivers/gpu/host1x/drm/gr2d.c|  7 ---
 drivers/gpu/host1x/drm/hdmi.c|  8 +---
 drivers/gpu/host1x/drm/output.c  |  2 --
 drivers/gpu/host1x/drm/rgb.c |  3 ---
 drivers/gpu/host1x/hw/debug_hw.c |  7 ---
 9 files changed, 2 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index c4765b3..e11aec7 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -8,11 +8,8 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
+#include 
 
 #include "host1x_client.h"
 #include "dc.h"
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 7f8f419..90a1f3d 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -7,16 +7,6 @@
  * published by the Free Software Foundation.
  */
 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-#include 
-
 #include "host1x_client.h"
 #include "dev.h"
 #include "drm.h"
diff --git a/drivers/gpu/host1x/drm/fb.c b/drivers/gpu/host1x/drm/fb.c
index 7dcd796..1fd4e19 100644
--- a/drivers/gpu/host1x/drm/fb.c
+++ b/drivers/gpu/host1x/drm/fb.c
@@ -10,8 +10,6 @@
  * published by the Free Software Foundation.
  */
 
-#include 
-
 #include "drm.h"
 #include "gem.h"
 
diff --git a/drivers/gpu/host1x/drm/gem.c b/drivers/gpu/host1x/drm/gem.c
index 59623de..4a21378 100644
--- a/drivers/gpu/host1x/drm/gem.c
+++ b/drivers/gpu/host1x/drm/gem.c
@@ -18,15 +18,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
 #include "gem.h"
 
 static inline struct tegra_bo *host1x_to_drm_bo(struct host1x_bo *bo)
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 06507c8..8d9a10f 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -1,8 +1,4 @@
 /*
- * drivers/video/tegra/host/gr2d/gr2d.c
- *
- * Tegra Graphics 2D
- *
  * Copyright (c) 2012-2013, NVIDIA Corporation.
  *
  * This program is free software; you can redistribute it and/or modify it
@@ -18,9 +14,6 @@
  * along with this program.  If not, see .
  */
 
-#include 
-#include 
-#include 
 #include 
 
 #include "channel.h"
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index e7fb9d9..5d8c41c 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -8,16 +8,10 @@
  */
 
 #include 
+#include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
-
-#include 
 
 #include "hdmi.h"
 #include "drm.h"
diff --git a/drivers/gpu/host1x/drm/output.c b/drivers/gpu/host1x/drm/output.c
index 137ae81..8f40fa6 100644
--- a/drivers/gpu/host1x/drm/output.c
+++ b/drivers/gpu/host1x/drm/output.c
@@ -7,9 +7,7 @@
  * published by the Free Software Foundation.
  */
 
-#include 
 #include 
-#include 
 
 #include "drm.h"
 
diff --git a/drivers/gpu/host1x/drm/rgb.c b/drivers/gpu/host1x/drm/rgb.c
index 5aa66ef..e4d2841 100644
--- a/drivers/gpu/host1x/drm/rgb.c
+++ b/drivers/gpu/host1x/drm/rgb.c
@@ -8,9 +8,6 @@
  */
 
 #include 
-#include 
-#include 
-#include 
 
 #include "drm.h"
 #include "dc.h"
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 334c038..dfad663 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -15,13 +15,6 @@
  *
  */
 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
 #include "dev.h"
 #include "debug.h"
 #include "cdma.h"
-- 
1.8.4

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

[PATCH v2 07/27] gpu: host1x: Do not discard .remove()

2013-10-07 Thread Thierry Reding 
The device can be unbound from the driver via sysfs, so regardless of
whether the driver is builtin or a module, its .remove() function needs
to stick around.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/dev.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 0f7b44c..105aa4e 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -172,7 +172,7 @@ fail_deinit_syncpt:
return err;
 }
 
-static int __exit host1x_remove(struct platform_device *pdev)
+static int host1x_remove(struct platform_device *pdev)
 {
struct host1x *host = platform_get_drvdata(pdev);
 
@@ -184,13 +184,12 @@ static int __exit host1x_remove(struct platform_device 
*pdev)
 }
 
 static struct platform_driver tegra_host1x_driver = {
-   .probe = host1x_probe,
-   .remove = __exit_p(host1x_remove),
.driver = {
-   .owner = THIS_MODULE,
.name = "tegra-host1x",
.of_match_table = host1x_of_match,
},
+   .probe = host1x_probe,
+   .remove = host1x_remove,
 };
 
 static int __init tegra_host1x_init(void)
-- 
1.8.4

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

[PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Thierry Reding 
Rework the address table code for the host1x firewall. The previous
implementation allocated a bitfield but didn't check for a valid pointer
so it could potentially crash. Furthermore setting up a bitfield makes
the code more complex than it needs to be.

Don't annotate the driver's .remove() function __exit. Even if built in
the driver can be unloaded via sysfs, so .remove() needs to stick around
after initialization. Also remove the explicit initialization of the
driver's .owner field to THIS_MODULE because that's now handled by the
driver core.

Furthermore make an error message more consistent with other subdrivers,
index the syncpts array for better readability, remove a gratuituous
newline and reorder some variable declarations to make the code easier
to read.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/gr2d.c | 95 +++
 1 file changed, 41 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 8d9a10f..07f0425 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -27,9 +27,8 @@
 
 struct gr2d {
struct host1x_client client;
-   struct clk *clk;
struct host1x_channel *channel;
-   unsigned long *addr_regs;
+   struct clk *clk;
 };
 
 static inline struct gr2d *to_gr2d(struct host1x_client *client)
@@ -37,8 +36,6 @@ static inline struct gr2d *to_gr2d(struct host1x_client 
*client)
return container_of(client, struct gr2d, client);
 }
 
-static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 reg);
-
 static int gr2d_client_init(struct host1x_client *client,
struct drm_device *drm)
 {
@@ -56,7 +53,6 @@ static int gr2d_open_channel(struct host1x_client *client,
struct gr2d *gr2d = to_gr2d(client);
 
context->channel = host1x_channel_get(gr2d->channel);
-
if (!context->channel)
return -ENOMEM;
 
@@ -87,11 +83,38 @@ static struct host1x_bo *host1x_bo_lookup(struct drm_device 
*drm,
return &bo->base;
 }
 
+static const u32 gr2d_addr_regs[] = {
+   0x1a, 0x1b, 0x26, 0x2b, 0x2c, 0x2d, 0x31, 0x32,
+   0x48, 0x49, 0x4a, 0x4b, 0x4c
+};
+
+static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 offset)
+{
+   unsigned int i;
+
+   switch (class) {
+   case HOST1X_CLASS_HOST1X:
+   if (offset == 0x2b)
+   return 1;
+
+   break;
+
+   case HOST1X_CLASS_GR2D:
+   case HOST1X_CLASS_GR2D_SB:
+   for (i = 0; i < ARRAY_SIZE(gr2d_addr_regs); i++)
+   if (offset == gr2d_addr_regs[i])
+   return 1;
+
+   break;
+   }
+
+   return 0;
+}
+
 static int gr2d_submit(struct tegra_drm_context *context,
   struct drm_tegra_submit *args, struct drm_device *drm,
   struct drm_file *file)
 {
-   struct host1x_job *job;
unsigned int num_cmdbufs = args->num_cmdbufs;
unsigned int num_relocs = args->num_relocs;
unsigned int num_waitchks = args->num_waitchks;
@@ -102,6 +125,7 @@ static int gr2d_submit(struct tegra_drm_context *context,
struct drm_tegra_waitchk __user *waitchks =
(void * __user)(uintptr_t)args->waitchks;
struct drm_tegra_syncpt syncpt;
+   struct host1x_job *job;
int err;
 
/* We don't yet support other than one syncpt_incr struct per submit */
@@ -205,41 +229,6 @@ static struct host1x_client_ops gr2d_client_ops = {
.submit = gr2d_submit,
 };
 
-static void gr2d_init_addr_reg_map(struct device *dev, struct gr2d *gr2d)
-{
-   const u32 gr2d_addr_regs[] = {0x1a, 0x1b, 0x26, 0x2b, 0x2c, 0x2d, 0x31,
- 0x32, 0x48, 0x49, 0x4a, 0x4b, 0x4c};
-   unsigned long *bitmap;
-   int i;
-
-   bitmap = devm_kzalloc(dev, DIV_ROUND_UP(256, BITS_PER_BYTE),
- GFP_KERNEL);
-
-   for (i = 0; i < ARRAY_SIZE(gr2d_addr_regs); ++i) {
-   u32 reg = gr2d_addr_regs[i];
-   bitmap[BIT_WORD(reg)] |= BIT_MASK(reg);
-   }
-
-   gr2d->addr_regs = bitmap;
-}
-
-static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 reg)
-{
-   struct gr2d *gr2d = dev_get_drvdata(dev);
-
-   switch (class) {
-   case HOST1X_CLASS_HOST1X:
-   return reg == 0x2b;
-   case HOST1X_CLASS_GR2D:
-   case HOST1X_CLASS_GR2D_SB:
-   reg &= 0xff;
-   if (gr2d->addr_regs[BIT_WORD(reg)] & BIT_MASK(reg))
-   return 1;
-   default:
-   return 0;
-   }
-}
-
 static const struct of_device_id gr2d_match[] = {
{ .compatible = "nvidia,tegra30-gr2d" },
{ .compatible = "nvidia,tegra20-gr2d" },
@@ -248,11 +237,11 @@ static const struct of_device_id gr2d_match[] = {
 
 static int gr2d_probe(struct platform_device *pdev)
 {
+   st

[PATCH v2 09/27] drm/tegra: gem: Miscellaneous cleanups

2013-10-07 Thread Thierry Reding 
Rename the host1x_to_drm_bo() macro to host1x_to_tegra_bo() for
consistency and fixup various stylistic issues.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/gem.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/host1x/drm/gem.c b/drivers/gpu/host1x/drm/gem.c
index 4a21378..267c0c2 100644
--- a/drivers/gpu/host1x/drm/gem.c
+++ b/drivers/gpu/host1x/drm/gem.c
@@ -20,14 +20,14 @@
 
 #include "gem.h"
 
-static inline struct tegra_bo *host1x_to_drm_bo(struct host1x_bo *bo)
+static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo)
 {
return container_of(bo, struct tegra_bo, base);
 }
 
 static void tegra_bo_put(struct host1x_bo *bo)
 {
-   struct tegra_bo *obj = host1x_to_drm_bo(bo);
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
struct drm_device *drm = obj->gem.dev;
 
mutex_lock(&drm->struct_mutex);
@@ -37,7 +37,7 @@ static void tegra_bo_put(struct host1x_bo *bo)
 
 static dma_addr_t tegra_bo_pin(struct host1x_bo *bo, struct sg_table **sgt)
 {
-   struct tegra_bo *obj = host1x_to_drm_bo(bo);
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
 
return obj->paddr;
 }
@@ -48,7 +48,7 @@ static void tegra_bo_unpin(struct host1x_bo *bo, struct 
sg_table *sgt)
 
 static void *tegra_bo_mmap(struct host1x_bo *bo)
 {
-   struct tegra_bo *obj = host1x_to_drm_bo(bo);
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
 
return obj->vaddr;
 }
@@ -59,7 +59,7 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void *addr)
 
 static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
 {
-   struct tegra_bo *obj = host1x_to_drm_bo(bo);
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
 
return obj->vaddr + page * PAGE_SIZE;
 }
@@ -71,7 +71,7 @@ static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned 
int page,
 
 static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
 {
-   struct tegra_bo *obj = host1x_to_drm_bo(bo);
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
struct drm_device *drm = obj->gem.dev;
 
mutex_lock(&drm->struct_mutex);
@@ -140,9 +140,9 @@ err_dma:
 }
 
 struct tegra_bo *tegra_bo_create_with_handle(struct drm_file *file,
-   struct drm_device *drm,
-   unsigned int size,
-   unsigned int *handle)
+struct drm_device *drm,
+unsigned int size,
+unsigned int *handle)
 {
struct tegra_bo *bo;
int ret;
@@ -169,7 +169,6 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
struct tegra_bo *bo = to_tegra_bo(gem);
 
drm_gem_free_mmap_offset(gem);
-
drm_gem_object_release(gem);
tegra_bo_destroy(gem->dev, bo);
 
@@ -189,7 +188,7 @@ int tegra_bo_dumb_create(struct drm_file *file, struct 
drm_device *drm,
args->size = args->pitch * args->height;
 
bo = tegra_bo_create_with_handle(file, drm, args->size,
-   &args->handle);
+&args->handle);
if (IS_ERR(bo))
return PTR_ERR(bo);
 
-- 
1.8.4

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

[PATCH v2 10/27] gpu: host1x: Make host1x header file public

2013-10-07 Thread Thierry Reding 
In preparation to support host1x clients other than DRM, move this
header into a public location.

Signed-off-by: Thierry Reding 
---
 MAINTAINERS| 1 +
 drivers/gpu/host1x/drm/drm.h   | 6 +++---
 drivers/gpu/host1x/drm/gr2d.c  | 1 -
 drivers/gpu/host1x/hw/channel_hw.c | 3 ++-
 {drivers/gpu/host1x => include/linux}/host1x.h | 8 +++-
 5 files changed, 9 insertions(+), 10 deletions(-)
 rename {drivers/gpu/host1x => include/linux}/host1x.h (88%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0df0af2..a1a4c7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2812,6 +2812,7 @@ L:linux-te...@vger.kernel.org
 T: git git://anongit.freedesktop.org/tegra/linux.git
 S: Supported
 F: drivers/gpu/host1x/
+F: include/linux/host1x.h
 F: include/uapi/drm/tegra_drm.h
 F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
 
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index dd6b98b..78754f6 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -10,14 +10,14 @@
 #ifndef HOST1X_DRM_H
 #define HOST1X_DRM_H 1
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-
-#include "host1x.h"
 
 struct tegra_fb {
struct drm_framebuffer base;
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 07f0425..fc4476d 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -20,7 +20,6 @@
 #include "drm.h"
 #include "gem.h"
 #include "job.h"
-#include "host1x.h"
 #include "host1x_bo.h"
 #include "host1x_client.h"
 #include "syncpt.h"
diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
b/drivers/gpu/host1x/hw/channel_hw.c
index ee19962..c950bc6 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -16,10 +16,11 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
+
 #include 
 
-#include "host1x.h"
 #include "host1x_bo.h"
 #include "channel.h"
 #include "dev.h"
diff --git a/drivers/gpu/host1x/host1x.h b/include/linux/host1x.h
similarity index 88%
rename from drivers/gpu/host1x/host1x.h
rename to include/linux/host1x.h
index a2bc1e6..fe09939 100644
--- a/drivers/gpu/host1x/host1x.h
+++ b/include/linux/host1x.h
@@ -1,6 +1,4 @@
 /*
- * Tegra host1x driver
- *
  * Copyright (c) 2009-2013, NVIDIA Corporation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
@@ -22,9 +20,9 @@
 #define __LINUX_HOST1X_H
 
 enum host1x_class {
-   HOST1X_CLASS_HOST1X = 0x1,
-   HOST1X_CLASS_GR2D   = 0x51,
-   HOST1X_CLASS_GR2D_SB= 0x52
+   HOST1X_CLASS_HOST1X = 0x1,
+   HOST1X_CLASS_GR2D = 0x51,
+   HOST1X_CLASS_GR2D_SB = 0x52,
 };
 
 #endif
-- 
1.8.4

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

[PATCH v2 11/27] drm/tegra: Introduce tegra_drm_client structure

2013-10-07 Thread Thierry Reding 
This structure derives from host1x_client. DRM-specific fields are moved
from host1x_client to this structure, so that host1x_client can remain
agnostic of DRM.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/drm/dc.c   | 35 ++-
 drivers/gpu/host1x/drm/drm.c  | 30 +++---
 drivers/gpu/host1x/drm/drm.h  | 37 +
 drivers/gpu/host1x/drm/gr2d.c | 42 +++---
 drivers/gpu/host1x/drm/hdmi.c | 33 +
 include/linux/host1x.h| 20 
 6 files changed, 114 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index e11aec7..5106df0 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -1038,30 +1038,30 @@ static int tegra_dc_debugfs_exit(struct tegra_dc *dc)
return 0;
 }
 
-static int tegra_dc_drm_init(struct host1x_client *client,
-struct drm_device *drm)
+static int tegra_dc_init(struct host1x_client *client)
 {
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_drm_client *drm = to_tegra_drm_client(client);
+   struct tegra_dc *dc = tegra_drm_client_to_dc(drm);
int err;
 
-   dc->pipe = drm->mode_config.num_crtc;
+   dc->pipe = drm->drm->mode_config.num_crtc;
 
-   drm_crtc_init(drm, &dc->base, &tegra_crtc_funcs);
+   drm_crtc_init(drm->drm, &dc->base, &tegra_crtc_funcs);
drm_mode_crtc_set_gamma_size(&dc->base, 256);
drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
 
-   err = tegra_dc_rgb_init(drm, dc);
+   err = tegra_dc_rgb_init(drm->drm, dc);
if (err < 0 && err != -ENODEV) {
dev_err(dc->dev, "failed to initialize RGB output: %d\n", err);
return err;
}
 
-   err = tegra_dc_add_planes(drm, dc);
+   err = tegra_dc_add_planes(drm->drm, dc);
if (err < 0)
return err;
 
if (IS_ENABLED(CONFIG_DEBUG_FS)) {
-   err = tegra_dc_debugfs_init(dc, drm->primary);
+   err = tegra_dc_debugfs_init(dc, drm->drm->primary);
if (err < 0)
dev_err(dc->dev, "debugfs setup failed: %d\n", err);
}
@@ -1077,9 +1077,10 @@ static int tegra_dc_drm_init(struct host1x_client 
*client,
return 0;
 }
 
-static int tegra_dc_drm_exit(struct host1x_client *client)
+static int tegra_dc_exit(struct host1x_client *client)
 {
-   struct tegra_dc *dc = host1x_client_to_dc(client);
+   struct tegra_drm_client *drm = to_tegra_drm_client(client);
+   struct tegra_dc *dc = tegra_drm_client_to_dc(drm);
int err;
 
devm_free_irq(dc->dev, dc->irq, dc);
@@ -1100,8 +1101,8 @@ static int tegra_dc_drm_exit(struct host1x_client *client)
 }
 
 static const struct host1x_client_ops dc_client_ops = {
-   .drm_init = tegra_dc_drm_init,
-   .drm_exit = tegra_dc_drm_exit,
+   .init = tegra_dc_init,
+   .exit = tegra_dc_exit,
 };
 
 static int tegra_dc_probe(struct platform_device *pdev)
@@ -1140,9 +1141,9 @@ static int tegra_dc_probe(struct platform_device *pdev)
return -ENXIO;
}
 
-   INIT_LIST_HEAD(&dc->client.list);
-   dc->client.ops = &dc_client_ops;
-   dc->client.dev = &pdev->dev;
+   INIT_LIST_HEAD(&dc->client.base.list);
+   dc->client.base.ops = &dc_client_ops;
+   dc->client.base.dev = &pdev->dev;
 
err = tegra_dc_rgb_probe(dc);
if (err < 0 && err != -ENODEV) {
@@ -1150,7 +1151,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
return err;
}
 
-   err = host1x_register_client(tegra, &dc->client);
+   err = host1x_register_client(tegra, &dc->client.base);
if (err < 0) {
dev_err(&pdev->dev, "failed to register host1x client: %d\n",
err);
@@ -1168,7 +1169,7 @@ static int tegra_dc_remove(struct platform_device *pdev)
struct tegra_dc *dc = platform_get_drvdata(pdev);
int err;
 
-   err = host1x_unregister_client(tegra, &dc->client);
+   err = host1x_unregister_client(tegra, &dc->client.base);
if (err < 0) {
dev_err(&pdev->dev, "failed to unregister host1x client: %d\n",
err);
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 90a1f3d..cb6a4e8 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -131,12 +131,18 @@ int tegra_drm_alloc(struct platform_device *pdev)
 int tegra_drm_init(struct tegra_drm *tegra, struct drm_device *drm)
 {
struct host1x_client *client;
+   int err;
 
mutex_lock(&tegra->clients_lock);
 
list_for_each_entry(client, &tegra->clients, list) {
-   if (client->ops && client->ops->drm_init) {
-   int err = client->ops->drm_init

[PATCH v2 12/27] gpu: host1x: Expose syncpt and channel functionality

2013-10-07 Thread Thierry Reding 
Expose the buffer objects, syncpoint and channel functionality in the
public public header so that drivers can use them.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/Makefile|   2 -
 drivers/gpu/host1x/cdma.c  |   2 +-
 drivers/gpu/host1x/channel.h   |   6 --
 drivers/gpu/host1x/drm/drm.c   |   2 -
 drivers/gpu/host1x/drm/gem.h   |   4 +-
 drivers/gpu/host1x/drm/gr2d.c  |   6 +-
 drivers/gpu/host1x/drm/hdmi.c  |   2 +-
 drivers/gpu/host1x/host1x_bo.h |  87 -
 drivers/gpu/host1x/hw/channel_hw.c |   1 -
 drivers/gpu/host1x/hw/debug_hw.c   |   1 -
 drivers/gpu/host1x/job.c   |   2 +-
 drivers/gpu/host1x/job.h   | 108 --
 drivers/gpu/host1x/syncpt.c|  19 
 drivers/gpu/host1x/syncpt.h|  40 +---
 include/linux/host1x.h | 185 +
 15 files changed, 211 insertions(+), 256 deletions(-)
 delete mode 100644 drivers/gpu/host1x/host1x_bo.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 3b037b6..64628ba 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -1,5 +1,3 @@
-ccflags-y = -Idrivers/gpu/host1x
-
 host1x-y = \
syncpt.o \
dev.o \
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index de72172..3995255 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +31,6 @@
 #include "channel.h"
 #include "dev.h"
 #include "debug.h"
-#include "host1x_bo.h"
 #include "job.h"
 
 /*
diff --git a/drivers/gpu/host1x/channel.h b/drivers/gpu/host1x/channel.h
index 48723b8..df767cf 100644
--- a/drivers/gpu/host1x/channel.h
+++ b/drivers/gpu/host1x/channel.h
@@ -40,12 +40,6 @@ struct host1x_channel {
 /* channel list operations */
 int host1x_channel_list_init(struct host1x *host);
 
-struct host1x_channel *host1x_channel_request(struct device *dev);
-void host1x_channel_free(struct host1x_channel *channel);
-struct host1x_channel *host1x_channel_get(struct host1x_channel *channel);
-void host1x_channel_put(struct host1x_channel *channel);
-int host1x_job_submit(struct host1x_job *job);
-
 #define host1x_for_each_channel(host, channel) \
list_for_each_entry(channel, &host->chlist.list, list)
 
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index cb6a4e8..e93caea 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -8,10 +8,8 @@
  */
 
 #include "host1x_client.h"
-#include "dev.h"
 #include "drm.h"
 #include "gem.h"
-#include "syncpt.h"
 
 #define DRIVER_NAME "tegra"
 #define DRIVER_DESC "NVIDIA Tegra graphics"
diff --git a/drivers/gpu/host1x/drm/gem.h b/drivers/gpu/host1x/drm/gem.h
index 492533a..2b54f14 100644
--- a/drivers/gpu/host1x/drm/gem.h
+++ b/drivers/gpu/host1x/drm/gem.h
@@ -19,11 +19,11 @@
 #ifndef __HOST1X_GEM_H
 #define __HOST1X_GEM_H
 
+#include 
+
 #include 
 #include 
 
-#include "host1x_bo.h"
-
 struct tegra_bo {
struct drm_gem_object gem;
struct host1x_bo base;
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index e814918..a16aaa8 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -16,13 +16,9 @@
 
 #include 
 
-#include "channel.h"
+#include "host1x_client.h"
 #include "drm.h"
 #include "gem.h"
-#include "job.h"
-#include "host1x_bo.h"
-#include "host1x_client.h"
-#include "syncpt.h"
 
 struct gr2d {
struct tegra_drm_client client;
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 30ac9e8..a237004 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -13,10 +13,10 @@
 #include 
 #include 
 
+#include "host1x_client.h"
 #include "hdmi.h"
 #include "drm.h"
 #include "dc.h"
-#include "host1x_client.h"
 
 struct tegra_hdmi {
struct tegra_drm_client client;
diff --git a/drivers/gpu/host1x/host1x_bo.h b/drivers/gpu/host1x/host1x_bo.h
deleted file mode 100644
index 4c1f10bd..000
--- a/drivers/gpu/host1x/host1x_bo.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/*
- * Tegra host1x Memory Management Abstraction header
- *
- * Copyright (c) 2012-2013, NVIDIA Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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 _HOST1X_BO_H
-#define _HOST1X_BO_H
-
-struct hos

[PATCH v2 13/27] drm/tegra: Move subdevice infrastructure to host1x

2013-10-07 Thread Thierry Reding 
The Tegra DRM driver currently uses some infrastructure to defer the DRM
core initialization until all required devices have registered. The same
infrastructure can potentially be used by any other driver that requires
more than a single sub-device of the host1x module.

Make the infrastructure more generic and keep only the DRM specific code
in the DRM part of the driver. Eventually this will make it easy to move
the DRM driver part back to the DRM subsystem.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/Makefile   |   2 +
 drivers/gpu/host1x/bus.c  | 309 +++
 drivers/gpu/host1x/{host1x_client.h => bus.h} |  24 +-
 drivers/gpu/host1x/dev.c  |  60 ++---
 drivers/gpu/host1x/dev.h  |   9 +-
 drivers/gpu/host1x/drm/bus.c  | 123 +
 drivers/gpu/host1x/drm/dc.c   |  35 +--
 drivers/gpu/host1x/drm/drm.c  | 347 +-
 drivers/gpu/host1x/drm/drm.h  |  31 +--
 drivers/gpu/host1x/drm/gr2d.c |  32 ++-
 drivers/gpu/host1x/drm/hdmi.c |  33 +--
 include/drm/drmP.h|   1 +
 include/linux/host1x.h|  45 +++-
 13 files changed, 700 insertions(+), 351 deletions(-)
 create mode 100644 drivers/gpu/host1x/bus.c
 rename drivers/gpu/host1x/{host1x_client.h => bus.h} (60%)
 create mode 100644 drivers/gpu/host1x/drm/bus.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 64628ba..616fe82 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -1,4 +1,5 @@
 host1x-y = \
+   bus.o \
syncpt.o \
dev.o \
intr.o \
@@ -15,4 +16,5 @@ host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gem.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gr2d.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/bus.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
new file mode 100644
index 000..8e96d23
--- /dev/null
+++ b/drivers/gpu/host1x/bus.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (C) 2012 Avionic Design GmbH
+ * Copyright (C) 2012-2013, NVIDIA Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+#include 
+#include 
+#include 
+
+#include "dev.h"
+
+struct host1x_subdev {
+   struct host1x_client *client;
+   struct device_node *np;
+   struct list_head list;
+};
+
+static int host1x_subdev_add(struct host1x_device *device,
+struct device_node *np)
+{
+   struct host1x_subdev *subdev;
+
+   subdev = kzalloc(sizeof(*subdev), GFP_KERNEL);
+   if (!subdev)
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(&subdev->list);
+   subdev->np = of_node_get(np);
+
+   list_add_tail(&subdev->list, &device->subdevs);
+
+   return 0;
+}
+
+static int host1x_device_parse_dt(struct host1x_device *device)
+{
+   struct device_node *np;
+   int err;
+
+   for_each_child_of_node(device->dev.parent->of_node, np) {
+   if (of_match_node(device->driver->subdevs, np) &&
+   of_device_is_available(np)) {
+   err = host1x_subdev_add(device, np);
+   if (err < 0)
+   return err;
+   }
+   }
+
+   return 0;
+}
+
+static void host1x_subdev_register(struct host1x_device *device,
+  struct host1x_subdev *subdev,
+  struct host1x_client *client)
+{
+   int err;
+
+   mutex_lock(&device->subdevs_lock);
+   mutex_lock(&device->clients_lock);
+   list_del_init(&subdev->list);
+   list_add_tail(&client->list, &device->clients);
+   client->parent = &device->dev;
+   subdev->client = client;
+   mutex_unlock(&device->clients_lock);
+   mutex_unlock(&device->subdevs_lock);
+
+   if (list_empty(&device->subdevs)) {
+   err = device->driver->probe(device);
+   if (err < 0)
+   dev_err(&device->dev, "probe failed: %d\n", err);
+   }
+}
+
+static void host1x_subdev_unregister(struct host1x_device *device,
+struct host1x_subdev *subdev)
+{
+   mutex_lock(&devi

[PATCH v2 14/27] drm/tegra: Move driver to DRM tree

2013-10-07 Thread Thierry Reding 
In order to subsystem-wide changes easier, move the Tegra DRM driver
back into the DRM tree.

Signed-off-by: Thierry Reding 
---
 MAINTAINERS|  1 +
 drivers/gpu/drm/Kconfig|  2 ++
 drivers/gpu/drm/Makefile   |  1 +
 drivers/gpu/{host1x/drm => drm/tegra}/Kconfig  | 10 +-
 drivers/gpu/drm/tegra/Makefile | 15 +++
 drivers/gpu/{host1x/drm => drm/tegra}/bus.c|  0
 drivers/gpu/{host1x/drm => drm/tegra}/dc.c |  0
 drivers/gpu/{host1x/drm => drm/tegra}/dc.h |  0
 drivers/gpu/{host1x/drm => drm/tegra}/drm.c|  0
 drivers/gpu/{host1x/drm => drm/tegra}/drm.h|  0
 drivers/gpu/{host1x/drm => drm/tegra}/fb.c |  0
 drivers/gpu/{host1x/drm => drm/tegra}/gem.c|  0
 drivers/gpu/{host1x/drm => drm/tegra}/gem.h|  0
 drivers/gpu/{host1x/drm => drm/tegra}/gr2d.c   |  0
 drivers/gpu/{host1x/drm => drm/tegra}/hdmi.c   |  0
 drivers/gpu/{host1x/drm => drm/tegra}/hdmi.h   |  0
 drivers/gpu/{host1x/drm => drm/tegra}/output.c |  0
 drivers/gpu/{host1x/drm => drm/tegra}/rgb.c|  0
 drivers/gpu/host1x/Kconfig |  2 --
 drivers/gpu/host1x/Makefile|  8 
 drivers/video/Kconfig  |  4 ++--
 21 files changed, 26 insertions(+), 17 deletions(-)
 rename drivers/gpu/{host1x/drm => drm/tegra}/Kconfig (100%)
 create mode 100644 drivers/gpu/drm/tegra/Makefile
 rename drivers/gpu/{host1x/drm => drm/tegra}/bus.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/dc.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/dc.h (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/drm.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/drm.h (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/fb.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/gem.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/gem.h (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/gr2d.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/hdmi.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/hdmi.h (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/output.c (100%)
 rename drivers/gpu/{host1x/drm => drm/tegra}/rgb.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index a1a4c7c..26ff91a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2811,6 +2811,7 @@ L:dri-devel@lists.freedesktop.org
 L: linux-te...@vger.kernel.org
 T: git git://anongit.freedesktop.org/tegra/linux.git
 S: Supported
+F: drivers/gpu/drm/tegra/
 F: drivers/gpu/host1x/
 F: include/linux/host1x.h
 F: include/uapi/drm/tegra_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..290e2ac 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source "drivers/gpu/drm/tilcdc/Kconfig"
 source "drivers/gpu/drm/qxl/Kconfig"
 
 source "drivers/gpu/drm/msm/Kconfig"
+
+source "drivers/gpu/drm/tegra/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..e39cd03 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -55,4 +55,5 @@ obj-$(CONFIG_DRM_OMAP)+= omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_MSM) += msm/
+obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-y  += i2c/
diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/drm/tegra/Kconfig
similarity index 100%
rename from drivers/gpu/host1x/drm/Kconfig
rename to drivers/gpu/drm/tegra/Kconfig
index 69853a4..7759eea 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -13,6 +13,11 @@ config DRM_TEGRA
 
 if DRM_TEGRA
 
+config DRM_TEGRA_DEBUG
+   bool "NVIDIA Tegra DRM debug support"
+   help
+ Say yes here to enable debugging support.
+
 config DRM_TEGRA_STAGING
bool "Enable HOST1X interface"
depends on STAGING
@@ -21,9 +26,4 @@ config DRM_TEGRA_STAGING
 
  If unsure, choose N.
 
-config DRM_TEGRA_DEBUG
-   bool "NVIDIA Tegra DRM debug support"
-   help
- Say yes here to enable debugging support.
-
 endif
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
new file mode 100644
index 000..abb267c
--- /dev/null
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -0,0 +1,15 @@
+ccflags-y += -Iinclude/drm
+ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
+
+tegra-drm-y := \
+   bus.o \
+   drm.o \
+   gem.o \
+   fb.o \
+   dc.o \
+   output.o \
+   rgb.o \
+   hdmi.o \
+   gr2d.o
+
+obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/host1x/drm/bus.c b/drivers/gpu/drm/tegra/bus.c
similarity index 100%
rename from drivers/gpu/host1x/drm/bus.c
rename to drivers/gpu/drm/tegra/bus.c
diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/drm/tegra/dc.c
similarity index 100%
rename from drivers/gpu/host1x/drm/dc.c
rename to drivers/gpu/drm/tegra/dc.c
diff --git a/drivers/gpu/host1x/drm/dc.

[PATCH v2 15/27] gpu: host1x: Add support for Tegra114

2013-10-07 Thread Thierry Reding 
Tegra114 uses a slightly updated version of host1x with an additional
syncpoint.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- fix register fields changed from host1x01

 drivers/gpu/host1x/Makefile |   3 +-
 drivers/gpu/host1x/dev.c|  11 ++
 drivers/gpu/host1x/hw/host1x02.c|  42 +
 drivers/gpu/host1x/hw/host1x02.h|  26 +++
 drivers/gpu/host1x/hw/hw_host1x02_channel.h | 121 ++
 drivers/gpu/host1x/hw/hw_host1x02_sync.h| 243 
 drivers/gpu/host1x/hw/hw_host1x02_uclass.h  | 175 
 7 files changed, 620 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/host1x/hw/host1x02.c
 create mode 100644 drivers/gpu/host1x/hw/host1x02.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x02_channel.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x02_sync.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x02_uclass.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 889217c..afa1e9e 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -7,6 +7,7 @@ host1x-y = \
channel.o \
job.o \
debug.o \
-   hw/host1x01.o
+   hw/host1x01.o \
+   hw/host1x02.o
 
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index de0fd55..ab402a5 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -33,6 +33,7 @@
 #include "channel.h"
 #include "debug.h"
 #include "hw/host1x01.h"
+#include "hw/host1x02.h"
 
 void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
 {
@@ -67,7 +68,17 @@ static const struct host1x_info host1x01_info = {
.sync_offset= 0x3000,
 };
 
+static const struct host1x_info host1x02_info = {
+   .nb_channels = 9,
+   .nb_pts = 32,
+   .nb_mlocks = 16,
+   .nb_bases = 12,
+   .init = host1x02_init,
+   .sync_offset = 0x3000,
+};
+
 static struct of_device_id host1x_of_match[] = {
+   { .compatible = "nvidia,tegra114-host1x", .data = &host1x02_info, },
{ .compatible = "nvidia,tegra30-host1x", .data = &host1x01_info, },
{ .compatible = "nvidia,tegra20-host1x", .data = &host1x01_info, },
{ },
diff --git a/drivers/gpu/host1x/hw/host1x02.c b/drivers/gpu/host1x/hw/host1x02.c
new file mode 100644
index 000..52c0467
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x02.c
@@ -0,0 +1,42 @@
+/*
+ * Host1x init for Tegra114 SoCs
+ *
+ * Copyright (c) 2013 NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+/* include hw specification */
+#include "hw/host1x01.h"
+#include "hw/host1x01_hardware.h"
+
+/* include code */
+#include "hw/cdma_hw.c"
+#include "hw/channel_hw.c"
+#include "hw/debug_hw.c"
+#include "hw/intr_hw.c"
+#include "hw/syncpt_hw.c"
+
+#include "dev.h"
+
+int host1x02_init(struct host1x *host)
+{
+   host->channel_op = &host1x_channel_ops;
+   host->cdma_op = &host1x_cdma_ops;
+   host->cdma_pb_op = &host1x_pushbuffer_ops;
+   host->syncpt_op = &host1x_syncpt_ops;
+   host->intr_op = &host1x_intr_ops;
+   host->debug_op = &host1x_debug_ops;
+
+   return 0;
+}
diff --git a/drivers/gpu/host1x/hw/host1x02.h b/drivers/gpu/host1x/hw/host1x02.h
new file mode 100644
index 000..f748660
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x02.h
@@ -0,0 +1,26 @@
+/*
+ * Host1x init for Tegra114 SoCs
+ *
+ * Copyright (c) 2013 NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 HOST1X_HOST1X02_H
+#define HOST1X_HOST1X02_H
+
+struct host1x;
+
+int host1x02_init(struct host1x *host);
+
+#endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x02_channel.h 
b/drivers/gpu/host1x/hw/hw_host1x02_channel.h
new file mode 100644
index 000..e490bcd
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x02

[PATCH v2 16/27] drm/tegra: Add Tegra114 display controller support

2013-10-07 Thread Thierry Reding 
From: Mikko Perttunen 

The Tegra114 display controller is backwards-compatible with previous
generations of the Tegra SoC. No code changes are required.

Signed-off-by: Mikko Perttunen 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/dc.c  | 1 +
 drivers/gpu/drm/tegra/drm.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 71cbda6..e8a0f5f 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1183,6 +1183,7 @@ static int tegra_dc_remove(struct platform_device *pdev)
 }
 
 static struct of_device_id tegra_dc_of_match[] = {
+   { .compatible = "nvidia,tegra114-dc", },
{ .compatible = "nvidia,tegra30-dc", },
{ .compatible = "nvidia,tegra20-dc", },
{ },
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index f9def3c..e958960 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -489,6 +489,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra30-dc", },
{ .compatible = "nvidia,tegra30-hdmi", },
{ .compatible = "nvidia,tegra30-gr2d", },
+   { .compatible = "nvidia,tegra114-dc", },
{ /* sentinel */ }
 };
 
-- 
1.8.4

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

[PATCH v2 17/27] drm/tegra: Add Tegra114 HDMI support

2013-10-07 Thread Thierry Reding 
From: Mikko Perttunen 

Tegra114 TMDS configuration requires a new peak_current field and the
driver current override bit has changed position.

Signed-off-by: Mikko Perttunen 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c  |   1 +
 drivers/gpu/drm/tegra/hdmi.c | 103 -
 drivers/gpu/drm/tegra/hdmi.h | 152 +++
 3 files changed, 253 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e958960..4afc9e1 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -490,6 +490,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra30-hdmi", },
{ .compatible = "nvidia,tegra30-gr2d", },
{ .compatible = "nvidia,tegra114-dc", },
+   { .compatible = "nvidia,tegra114-hdmi", },
{ /* sentinel */ }
 };
 
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 4489d56..130cb6d 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -142,6 +142,7 @@ struct tmds_config {
u32 pll1;
u32 pe_current;
u32 drive_current;
+   u32 peak_current;
 };
 
 static const struct tmds_config tegra2_tmds_config[] = {
@@ -223,6 +224,85 @@ static const struct tmds_config tegra3_tmds_config[] = {
},
 };
 
+const struct tmds_config tegra114_tmds_config[] = {
+   { /* 480p/576p / 25.2MHz/27MHz modes */
+   .pclk = 2700,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(0) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_LOADADJ(3) | SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_0_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_0_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_10_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 720p / 74.25MHz modes */
+   .pclk = 7425,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(1) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_PE_EN | SOR_PLL_LOADADJ(3) |
+   SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_15_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_15_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_10_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_10_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CURRENT_0_000_mA),
+   }, { /* 1080p / 148.5MHz modes */
+   .pclk = 14850,
+   .pll0 = SOR_PLL_ICHPMP(1) | SOR_PLL_BG_V17_S(3) |
+   SOR_PLL_VCOCAP(3) | SOR_PLL_RESISTORSEL,
+   .pll1 = SOR_PLL_PE_EN | SOR_PLL_LOADADJ(3) |
+   SOR_PLL_TMDS_TERMADJ(0),
+   .pe_current = PE_CURRENT0(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT1(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT2(PE_CURRENT_10_mA_T114) |
+   PE_CURRENT3(PE_CURRENT_10_mA_T114),
+   .drive_current =
+   DRIVE_CURRENT_LANE0_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   DRIVE_CURRENT_LANE1_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   DRIVE_CURRENT_LANE2_T114(DRIVE_CURRENT_12_400_mA_T114) |
+   DRIVE_CURRENT_LANE3_T114(DRIVE_CURRENT_12_400_mA_T114),
+   .peak_current = PEAK_CURRENT_LANE0(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE1(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE2(PEAK_CURRENT_0_000_mA) |
+   PEAK_CURRENT_LANE3(PEAK_CUR

[PATCH v2 18/27] drm/tegra: hdmi: Detect DVI-only displays

2013-10-07 Thread Thierry Reding 
From: Mikko Perttunen 

Use EDID data to determine whether the display supports HDMI or DVI
only. The HDMI output used to assume to be connected to HDMI displays,
but that broke support for DVI displays that don't understand the
interspersed audio/other data.

To be on the safe side, default to DVI if no EDID data is available.

Signed-off-by: Mikko Perttunen 
[tred...@nvidia.com: move detection to separate function]
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/hdmi.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 130cb6d..3808226 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -666,6 +666,18 @@ static void tegra_hdmi_setup_tmds(struct tegra_hdmi *hdmi,
}
 }
 
+static bool tegra_output_is_hdmi(struct tegra_output *output)
+{
+   struct edid *edid;
+
+   if (!output->connector.edid_blob_ptr)
+   return false;
+
+   edid = (struct edid *)output->connector.edid_blob_ptr->data;
+
+   return drm_detect_hdmi_monitor(edid);
+}
+
 static int tegra_output_hdmi_enable(struct tegra_output *output)
 {
unsigned int h_sync_width, h_front_porch, h_back_porch, i, rekey;
@@ -680,6 +692,8 @@ static int tegra_output_hdmi_enable(struct tegra_output 
*output)
int retries = 1000;
int err;
 
+   hdmi->dvi = !tegra_output_is_hdmi(output);
+
pclk = mode->clock * 1000;
h_sync_width = mode->hsync_end - mode->hsync_start;
h_back_porch = mode->htotal - mode->hsync_end;
-- 
1.8.4

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

[PATCH v2 19/27] host1x: hdmi: Enable VDD earlier for hotplug/DDC

2013-10-07 Thread Thierry Reding 
From: Mikko Perttunen 

The VDD regulator used to be enabled only at tegra_output_hdmi_enable,
which is called after a sink is detected. However, the HDMI hotplug pin
works by returning the voltage supplied by the VDD pin, so this meant
that the hotplug pin was never asserted and the sink was not detected
unless the VDD regulator was set to be always on.

This patch moves the enable to the tegra_hdmi_init() function to make
sure the regulator will get enabled and therefore ensure proper hotplug
detection.

Signed-off-by: Mikko Perttunen 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/hdmi.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 3808226..9bd912c 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -699,12 +699,6 @@ static int tegra_output_hdmi_enable(struct tegra_output 
*output)
h_back_porch = mode->htotal - mode->hsync_end;
h_front_porch = mode->hsync_start - mode->hdisplay;
 
-   err = regulator_enable(hdmi->vdd);
-   if (err < 0) {
-   dev_err(hdmi->dev, "failed to enable VDD regulator: %d\n", err);
-   return err;
-   }
-
err = regulator_enable(hdmi->pll);
if (err < 0) {
dev_err(hdmi->dev, "failed to enable PLL regulator: %d\n", err);
@@ -926,7 +920,6 @@ static int tegra_output_hdmi_disable(struct tegra_output 
*output)
tegra_periph_reset_assert(hdmi->clk);
clk_disable(hdmi->clk);
regulator_disable(hdmi->pll);
-   regulator_disable(hdmi->vdd);
 
return 0;
 }
@@ -1231,6 +1224,13 @@ static int tegra_hdmi_init(struct host1x_client *client)
struct tegra_hdmi *hdmi = host1x_client_to_hdmi(client);
int err;
 
+   err = regulator_enable(hdmi->vdd);
+   if (err < 0) {
+   dev_err(client->dev, "failed to enable VDD regulator: %d\n",
+   err);
+   return err;
+   }
+
hdmi->output.type = TEGRA_OUTPUT_HDMI;
hdmi->output.dev = client->dev;
hdmi->output.ops = &hdmi_ops;
@@ -1274,6 +1274,8 @@ static int tegra_hdmi_exit(struct host1x_client *client)
return err;
}
 
+   regulator_disable(hdmi->vdd);
+
return 0;
 }
 
-- 
1.8.4

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

[PATCH v2 20/27] drm/tegra: hdmi: Rename tegra{2,3} to tegra{20,30}

2013-10-07 Thread Thierry Reding 
Everything related to Tegra uses Tegra20 and Tegra30 instead of Tegra2
and Tegra3, respectively. Rename the TMDS arrays in the HDMI driver for
consistency.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/hdmi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 9bd912c..68ab00d 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -145,7 +145,7 @@ struct tmds_config {
u32 peak_current;
 };
 
-static const struct tmds_config tegra2_tmds_config[] = {
+static const struct tmds_config tegra20_tmds_config[] = {
{ /* slow pixel clock modes */
.pclk = 2700,
.pll0 = SOR_PLL_BG_V17_S(3) | SOR_PLL_ICHPMP(1) |
@@ -178,7 +178,7 @@ static const struct tmds_config tegra2_tmds_config[] = {
},
 };
 
-static const struct tmds_config tegra3_tmds_config[] = {
+static const struct tmds_config tegra30_tmds_config[] = {
{ /* 480p modes */
.pclk = 2700,
.pll0 = SOR_PLL_BG_V17_S(3) | SOR_PLL_ICHPMP(1) |
@@ -807,11 +807,11 @@ static int tegra_output_hdmi_enable(struct tegra_output 
*output)
num_tmds = ARRAY_SIZE(tegra114_tmds_config);
tmds = tegra114_tmds_config;
} else if (of_device_is_compatible(node, "nvidia,tegra30-hdmi")) {
-   num_tmds = ARRAY_SIZE(tegra3_tmds_config);
-   tmds = tegra3_tmds_config;
+   num_tmds = ARRAY_SIZE(tegra30_tmds_config);
+   tmds = tegra30_tmds_config;
} else {
-   num_tmds = ARRAY_SIZE(tegra2_tmds_config);
-   tmds = tegra2_tmds_config;
+   num_tmds = ARRAY_SIZE(tegra20_tmds_config);
+   tmds = tegra20_tmds_config;
}
 
for (i = 0; i < num_tmds; i++) {
-- 
1.8.4

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

[PATCH v2 21/27] drm: Add panel support

2013-10-07 Thread Thierry Reding 
Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.

The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.

Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- split .dpms() into separate .disable() and .enable()

 drivers/gpu/drm/Kconfig   |  2 +
 drivers/gpu/drm/Makefile  |  1 +
 drivers/gpu/drm/drm_panel.c   | 96 +++
 drivers/gpu/drm/panel/Kconfig |  4 ++
 include/drm/drm_panel.h   | 78 +++
 5 files changed, 181 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_panel.c
 create mode 100644 drivers/gpu/drm/panel/Kconfig
 create mode 100644 include/drm/drm_panel.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 290e2ac..a1d4f8e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -238,3 +238,5 @@ source "drivers/gpu/drm/qxl/Kconfig"
 source "drivers/gpu/drm/msm/Kconfig"
 
 source "drivers/gpu/drm/tegra/Kconfig"
+
+source "drivers/gpu/drm/panel/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e39cd03..81363a9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 
 drm-usb-y   := drm_usb.o
 
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
new file mode 100644
index 000..ff6e459
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+
+static DEFINE_MUTEX(panel_lock);
+static LIST_HEAD(panel_list);
+
+void drm_panel_init(struct drm_panel *panel)
+{
+   INIT_LIST_HEAD(&panel->list);
+}
+EXPORT_SYMBOL(drm_panel_init);
+
+int drm_panel_add(struct drm_panel *panel)
+{
+   mutex_lock(&panel_lock);
+   list_add_tail(&panel->list, &panel_list);
+   mutex_unlock(&panel_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_add);
+
+void drm_panel_remove(struct drm_panel *panel)
+{
+   mutex_lock(&panel_lock);
+   list_del_init(&panel->list);
+   mutex_unlock(&panel_lock);
+}
+EXPORT_SYMBOL(drm_panel_remove);
+
+int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
+{
+   if (panel->connector)
+   return -EBUSY;
+
+   panel->connector = connector;
+   panel->drm = connector->dev;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_attach);
+
+int drm_panel_detach(struct drm_panel *panel)
+{
+   panel->connector = NULL;
+   panel->drm = NULL;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_panel_detach);
+
+#ifdef CONFIG_OF
+struct drm_panel *of_drm_find_panel(struct device_node *np)
+{
+   struct drm_panel *panel;
+
+   mutex_lock(&panel_lock);
+
+   list_for_each_entry(panel, &panel_list, list) {
+   if (panel->dev->of_node == np) {
+   mutex_unl

[PATCH v2 22/27] drm/panel: Add simple panel support

2013-10-07 Thread Thierry Reding 
Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.

Support is added for three panels: An AU Optronics 10.1" WSVGA, a
Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD
panel.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- update vendor prefixes (cptt -> chunghwa, pc -> panasonic)
- split up panel binding documents per-panel
- make regulator mandatory
- add flag to keep track of enabled status

 .../devicetree/bindings/panel/auo,b101aw03.txt |   7 +
 .../bindings/panel/chunghwa,claa101wb03.txt|   7 +
 .../bindings/panel/panasonic,vvx10f004b00.txt  |   7 +
 .../devicetree/bindings/panel/simple-panel.txt |  21 ++
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/panel/Kconfig  |  13 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-simple.c   | 339 +
 8 files changed, 396 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt
 create mode 100644 
Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
 create mode 100644 
Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
 create mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt
 create mode 100644 drivers/gpu/drm/panel/Makefile
 create mode 100644 drivers/gpu/drm/panel/panel-simple.c

diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt 
b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
new file mode 100644
index 000..72e088a
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,b101aw03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt 
b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
new file mode 100644
index 000..0ab2c05
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa101wb03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt 
b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
new file mode 100644
index 000..d328b03
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
@@ -0,0 +1,7 @@
+Panasonic Corporation 10.1" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "panasonic,vvx10f004b00"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/panel/simple-panel.txt
new file mode 100644
index 000..1341bbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
@@ -0,0 +1,21 @@
+Simple display panel
+
+Required properties:
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   panel: panel {
+   compatible = "cptt,claa101wb01";
+   ddc-i2c-bus = <&panelddc>;
+
+   power-supply = <&vdd_pnl_reg>;
+   enable-gpios = <&gpio 90 0>;
+
+   backlight = <&backlight>;
+   };
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 81363a9..a9859e0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-y  += i2c/
+obj-y  += panel/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 2ddd5bd..843087b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -2,3 +2,16 @@ menuconfig DRM_PANEL
bool "DRM panel support"
help
  Panel registration and lookup framework.
+
+if DRM_PANEL
+
+config DRM_PANEL_SIMPLE
+   bool "support for simple panels"
+   depends on OF
+   help
+ DRM panel driver for dumb panels that need at most a regulator and
+ a GPIO to be powered up. Optionally a backlight can be attached so

[PATCH v2 23/27] drm/tegra: Implement panel support

2013-10-07 Thread Thierry Reding 
Use the DRM panel framework to attach a panel to an output.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/Kconfig  |  1 +
 drivers/gpu/drm/tegra/drm.h|  1 +
 drivers/gpu/drm/tegra/output.c | 32 ++--
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 7759eea..d1dde2b 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -2,6 +2,7 @@ config DRM_TEGRA
bool "NVIDIA Tegra DRM"
depends on DRM
select DRM_KMS_HELPER
+   select DRM_PANEL
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 25522e2..a8ba13c 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -176,6 +176,7 @@ struct tegra_output {
const struct tegra_output_ops *ops;
enum tegra_output_type type;
 
+   struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
unsigned int hpd_irq;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 8f40fa6..be6ef34 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -9,6 +9,7 @@
 
 #include 
 
+#include 
 #include "drm.h"
 
 static int tegra_connector_get_modes(struct drm_connector *connector)
@@ -17,6 +18,9 @@ static int tegra_connector_get_modes(struct drm_connector 
*connector)
struct edid *edid = NULL;
int err = 0;
 
+   if (output->panel)
+   return output->panel->funcs->get_modes(output->panel);
+
if (output->edid)
edid = kmemdup(output->edid, sizeof(*edid), GFP_KERNEL);
else if (output->ddc)
@@ -72,6 +76,9 @@ tegra_connector_detect(struct drm_connector *connector, bool 
force)
else
status = connector_status_connected;
} else {
+   if (output->panel)
+   status = connector_status_connected;
+
if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS)
status = connector_status_connected;
}
@@ -103,6 +110,15 @@ static const struct drm_encoder_funcs encoder_funcs = {
 
 static void tegra_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
+   struct tegra_output *output = encoder_to_output(encoder);
+   struct drm_panel *panel = output->panel;
+
+   if (panel && panel->funcs) {
+   if (mode != DRM_MODE_DPMS_ON)
+   drm_panel_disable(panel);
+   else
+   drm_panel_enable(panel);
+   }
 }
 
 static bool tegra_encoder_mode_fixup(struct drm_encoder *encoder,
@@ -151,14 +167,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
 
 int tegra_output_parse_dt(struct tegra_output *output)
 {
+   struct device_node *ddc, *panel;
enum of_gpio_flags flags;
-   struct device_node *ddc;
size_t size;
int err;
 
if (!output->of_node)
output->of_node = output->dev->of_node;
 
+   panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
+   if (panel) {
+   output->panel = of_drm_find_panel(panel);
+   if (!output->panel)
+   return -EPROBE_DEFER;
+
+   of_node_put(panel);
+   }
+
output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
 
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
@@ -173,7 +198,7 @@ int tegra_output_parse_dt(struct tegra_output *output)
of_node_put(ddc);
}
 
-   if (!output->edid && !output->ddc)
+   if (!output->panel && !output->edid && !output->ddc)
return -ENODEV;
 
output->hpd_gpio = of_get_named_gpio_flags(output->of_node,
@@ -240,6 +265,9 @@ int tegra_output_init(struct drm_device *drm, struct 
tegra_output *output)
   connector);
drm_connector_helper_add(&output->connector, &connector_helper_funcs);
 
+   if (output->panel)
+   drm_panel_attach(output->panel, &output->connector);
+
drm_encoder_init(drm, &output->encoder, &encoder_funcs, encoder);
drm_encoder_helper_add(&output->encoder, &encoder_helper_funcs);
 
-- 
1.8.4

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

[PATCH v2 24/27] drm/tegra: Start connectors with correct DPMS mode

2013-10-07 Thread Thierry Reding 
A connector's DPMS mode isn't initialized by default, therefore using a
default of 0 (DRM_MODE_DPMS_ON). This can cause problems in that the DRM
core won't explicitly turn on a connector because it thinks that it is
already on.

Signed-off-by: Thierry Reding 
---
Note that it would probably make sense to do this in the core, but after
some discussion on IRC it became clear that other drivers (specifically
i915) use similar workarounds and moving this to the core may cause them
to regress.

 drivers/gpu/drm/tegra/output.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index be6ef34..d911fe8 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -264,6 +264,7 @@ int tegra_output_init(struct drm_device *drm, struct 
tegra_output *output)
drm_connector_init(drm, &output->connector, &connector_funcs,
   connector);
drm_connector_helper_add(&output->connector, &connector_helper_funcs);
+   output->connector.dpms = DRM_MODE_DPMS_OFF;
 
if (output->panel)
drm_panel_attach(output->panel, &output->connector);
-- 
1.8.4

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

[PATCH v2 25/27] gpu: host1x: Add MIPI pad calibration support

2013-10-07 Thread Thierry Reding 
This driver adds support to perform calibration of the MIPI pads for CSI
and DSI.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- rename fields to mirror the names in the TRM
- remove unused fields

 drivers/gpu/host1x/Makefile |   1 +
 drivers/gpu/host1x/dev.c|  17 +++-
 drivers/gpu/host1x/dev.h|   2 +
 drivers/gpu/host1x/mipi.c   | 230 
 include/linux/host1x.h  |   2 +
 5 files changed, 248 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/host1x/mipi.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index afa1e9e..de305c2 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -7,6 +7,7 @@ host1x-y = \
channel.o \
job.o \
debug.o \
+   mipi.o \
hw/host1x01.o \
hw/host1x02.o
 
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index ab402a5..12d6333 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -208,17 +208,26 @@ static int __init tegra_host1x_init(void)
return err;
 
err = platform_driver_register(&tegra_host1x_driver);
-   if (err < 0) {
-   host1x_bus_exit();
-   return err;
-   }
+   if (err < 0)
+   goto unregister_bus;
+
+   err = platform_driver_register(&tegra_mipi_driver);
+   if (err < 0)
+   goto unregister_host1x;
 
return 0;
+
+unregister_host1x:
+   platform_driver_unregister(&tegra_host1x_driver);
+unregister_bus:
+   host1x_bus_exit();
+   return err;
 }
 module_init(tegra_host1x_init);
 
 static void __exit tegra_host1x_exit(void)
 {
+   platform_driver_unregister(&tegra_mipi_driver);
platform_driver_unregister(&tegra_host1x_driver);
host1x_bus_exit();
 }
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 6cf689b..65c80dc 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -304,4 +304,6 @@ static inline void host1x_hw_show_mlocks(struct host1x 
*host, struct output *o)
host->debug_op->show_mlocks(host, o);
 }
 
+extern struct platform_driver tegra_mipi_driver;
+
 #endif
diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
new file mode 100644
index 000..8a54613
--- /dev/null
+++ b/drivers/gpu/host1x/mipi.c
@@ -0,0 +1,230 @@
+/*
+ * Copyright (C) 2013 NVIDIA Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MIPI_CAL_CTRL  0x00
+#define MIPI_CAL_CTRL_START(1 << 0)
+
+#define MIPI_CAL_AUTOCAL_CTRL  0x01
+
+#define MIPI_CAL_STATUS0x02
+#define MIPI_CAL_STATUS_DONE   (1 << 16)
+#define MIPI_CAL_STATUS_ACTIVE (1 <<  0)
+
+#define MIPI_CAL_CONFIG_CSIA   0x05
+#define MIPI_CAL_CONFIG_CSIB   0x06
+#define MIPI_CAL_CONFIG_CSIC   0x07
+#define MIPI_CAL_CONFIG_CSID   0x08
+#define MIPI_CAL_CONFIG_CSIE   0x09
+#define MIPI_CAL_CONFIG_DSIA   0x0e
+#define MIPI_CAL_CONFIG_DSIB   0x0f
+#define MIPI_CAL_CONFIG_DSIC   0x10
+#define MIPI_CAL_CONFIG_DSID   0x11
+
+#define MIPI_CAL_CONFIG_SELECT (1 << 21)
+#define MIPI_CAL_CONFIG_HSPDOS(x)  (((x) & 0x1f) << 16)
+#define MIPI_CAL_CONFIG_HSPUOS(x)  (((x) & 0x1f) <<  8)
+#define MIPI_CAL_CONFIG_TERMOS(x)  (((x) & 0x1f) <<  0)
+
+#define MIPI_CAL_BIAS_PAD_CFG0 0x16
+#define MIPI_CAL_BIAS_PAD_PDVCLAMP (1 << 1)
+#define MIPI_CAL_BIAS_PAD_E_VCLAMP_REF (1 << 0)
+
+#define MIPI_CAL_BIAS_PAD_CFG1 0x17
+
+#define MIPI_CAL_BIAS_PAD_CFG2 0x18
+#define MIPI_CAL_BIAS_PAD_PDVREG   (1 << 1)
+
+static const struct module {
+   unsigned long reg;
+} modules[] = {
+   { .reg = MIPI_CAL_CONFIG

[PATCH v2 26/27] drm/tegra: Add DSI support

2013-10-07 Thread Thierry Reding 
This commit adds support for both DSI outputs found on Tegra. Only very
minimal functionality is implemented, so advanced features like ganged
mode won't work.

Due to the lack of other test hardware, some sections of the driver are
hardcoded to work with Dalmore.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/Makefile |1 +
 drivers/gpu/drm/tegra/dc.h |1 +
 drivers/gpu/drm/tegra/drm.c|   10 +-
 drivers/gpu/drm/tegra/drm.h|2 +
 drivers/gpu/drm/tegra/dsi.c| 1026 
 drivers/gpu/drm/tegra/output.c |5 +
 6 files changed, 1044 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/tegra/dsi.c

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index abb267c..6d16d43 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -10,6 +10,7 @@ tegra-drm-y := \
output.o \
rgb.o \
hdmi.o \
+   dsi.o \
gr2d.o
 
 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 79eaec9..5e2006c 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -116,6 +116,7 @@
 
 #define DC_DISP_DISP_WIN_OPTIONS   0x402
 #define HDMI_ENABLE (1 << 30)
+#define DSI_ENABLE  (1 << 29)
 
 #define DC_DISP_DISP_MEM_HIGH_PRIORITY 0x403
 #define CURSOR_THRESHOLD(x)   (((x) & 0x03) << 24)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 4afc9e1..d95be81 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -490,6 +490,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra30-hdmi", },
{ .compatible = "nvidia,tegra30-gr2d", },
{ .compatible = "nvidia,tegra114-dc", },
+   { .compatible = "nvidia,tegra114-dsi", },
{ .compatible = "nvidia,tegra114-hdmi", },
{ /* sentinel */ }
 };
@@ -513,10 +514,14 @@ static int __init host1x_drm_init(void)
if (err < 0)
goto unregister_host1x;
 
-   err = platform_driver_register(&tegra_hdmi_driver);
+   err = platform_driver_register(&tegra_dsi_driver);
if (err < 0)
goto unregister_dc;
 
+   err = platform_driver_register(&tegra_hdmi_driver);
+   if (err < 0)
+   goto unregister_dsi;
+
err = platform_driver_register(&tegra_gr2d_driver);
if (err < 0)
goto unregister_hdmi;
@@ -525,6 +530,8 @@ static int __init host1x_drm_init(void)
 
 unregister_hdmi:
platform_driver_unregister(&tegra_hdmi_driver);
+unregister_dsi:
+   platform_driver_unregister(&tegra_dsi_driver);
 unregister_dc:
platform_driver_unregister(&tegra_dc_driver);
 unregister_host1x:
@@ -537,6 +544,7 @@ static void __exit host1x_drm_exit(void)
 {
platform_driver_unregister(&tegra_gr2d_driver);
platform_driver_unregister(&tegra_hdmi_driver);
+   platform_driver_unregister(&tegra_dsi_driver);
platform_driver_unregister(&tegra_dc_driver);
host1x_driver_unregister(&host1x_drm_driver);
 }
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index a8ba13c..3dd43c7 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -167,6 +167,7 @@ struct tegra_output_ops {
 enum tegra_output_type {
TEGRA_OUTPUT_RGB,
TEGRA_OUTPUT_HDMI,
+   TEGRA_OUTPUT_DSI,
 };
 
 struct tegra_output {
@@ -253,6 +254,7 @@ extern void tegra_drm_fb_exit(struct drm_device *drm);
 extern void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
 
 extern struct platform_driver tegra_dc_driver;
+extern struct platform_driver tegra_dsi_driver;
 extern struct platform_driver tegra_hdmi_driver;
 extern struct platform_driver tegra_gr2d_driver;
 
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
new file mode 100644
index 000..0059f56
--- /dev/null
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -0,0 +1,1026 @@
+/*
+ * Copyright (C) 2013 NVIDIA Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMA

[PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support

2013-10-07 Thread Thierry Reding 
The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
Tegra30. No functionaly changes are required.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c  | 1 +
 drivers/gpu/drm/tegra/gr2d.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d95be81..b9e0977 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -492,6 +492,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra114-dc", },
{ .compatible = "nvidia,tegra114-dsi", },
{ .compatible = "nvidia,tegra114-hdmi", },
+   { .compatible = "nvidia,tegra114-gr2d", },
{ /* sentinel */ }
 };
 
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 9588072..f4e478b 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -232,6 +232,7 @@ static const struct tegra_drm_client_ops gr2d_ops = {
 };
 
 static const struct of_device_id gr2d_match[] = {
+   { .compatible = "nvidia,tegra114-gr2d" },
{ .compatible = "nvidia,tegra30-gr2d" },
{ .compatible = "nvidia,tegra20-gr2d" },
{ },
-- 
1.8.4

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

[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

--- Comment #30 from Paul Bodenbenner  ---
Created attachment 87222
  --> https://bugs.freedesktop.org/attachment.cgi?id=87222&action=edit
3.11.4

-- 
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 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

--- Comment #31 from Paul Bodenbenner  ---
Created attachment 87223
  --> https://bugs.freedesktop.org/attachment.cgi?id=87223&action=edit
3.12rc4

-- 
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 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

--- Comment #32 from Paul Bodenbenner  ---
Yes, I am using 3.11.4 from Arch testing repository and also enabled HDMI in
kernel boot line.
Just a side note: Upgraded to 3.12rc4 already...

-- 
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: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

2013-10-07 Thread Christian König 

Am 07.10.2013 10:06, schrieb Rafał Miłecki:

For the last few days it was I was testing fglrx on various cards to
trace HDMI setup. One thing that was killing me was no HDMI audio when
using some generic/cheap DVI to HDMI adapter with my HD 4850.

I started digging and it has appeared to be common problem when using
Catalyst / fglrx. Windows users were also experiencing this problem,
without any known workaround.

I've found one explanation by droidhacker:
http://phoronix.com/forums/showthread.php?23451-HDMI-Audio-with-fglrx&p=124891#post124891

If that is the case, you need to be aware that AMD sells a couple of 
PROPRIETARY adapter plugs, which fglrx can DETECT in order to decide whether or 
not to enable HDMI audio.

That sounded weird, I didn't believe that. There wasn't any
explanation how it's handled, I couldn't imagine how fglrx can "talk"
to the simple adapter. Overall it should just map the PINs, not
include any logic!

But today I've found another discussion:
http://www.avsforum.com/t/1080627/atis-magic-dvi-to-hdmi-dongle

That finally explains what is happening. So it appears that ATI's
proprietary adapter include some tiny I2C protocol that allows
identifying them! It seems that Catalyst / fglrx uses some simple I2C
talk to check if the adapter is made by ATI and allows or refuses to
use HDMI mode.
That also explains why radeon driver never had any problems with audio
over DVI, no matter what adapter was used.

Another ATI/fgllx mystery explained ;)


Why didn't you just asked me?

I've figured this out over five years ago by applying brute force to one 
of the "magic" DVI->HDMI adapters that came with my original RV635. And 
it indeed contains an extra EEPROM on the I2C bus ;)


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

Re: [PATCH 1/5] drm/i2c: tda998x: set VIF for full range, underscanned display

2013-10-07 Thread Jean-Francois Moine 
On Sun, 06 Oct 2013 23:07:55 +0100
Russell King  wrote:

> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 60e8404..704040b5 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -549,6 +549,8 @@ tda998x_write_avi(struct drm_encoder *encoder, struct 
> drm_display_mode *mode)
>   buf[HB(0)] = 0x82;
>   buf[HB(1)] = 0x02;
>   buf[HB(2)] = 13;
> + buf[PB(1)] = 2; /* underscanned display */
> + buf[PB(3)] = 2 << 2; /* full range */
>   buf[PB(4)] = drm_match_cea_mode(mode);
>  
>   tda998x_write_if(encoder, DIP_IF_FLAGS_IF2, REG_IF2_HB0, buf,

You should use the 'hdmi.h' constants which are meaningful enough:

buf[PB(1)] = HDMI_SCAN_MODE_UNDERSCAN;
buf[PB(3)] = HDMI_QUANTIZATION_RANGE_FULL << 2;

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

2013-10-07 Thread Rafał Miłecki 
2013/10/7 Christian König :
> Why didn't you just asked me?

I was told on #radeon you're on holidays ;) I was trying to catch you.

> I've figured this out over five years ago by applying brute force to one of
> the "magic" DVI->HDMI adapters that came with my original RV635. And it
> indeed contains an extra EEPROM on the I2C bus ;)

Did you find any way to workaround this? So I can use my generic
adapter with fglrx for audio?

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

Re: [PATCH 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

2013-10-07 Thread Jean-Francois Moine 
On Sun, 06 Oct 2013 23:09:56 +0100
Russell King  wrote:

> This patch adds ARGB hardware cursor support to the DRM driver for the
> Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
> 64x32 resolutions.
[snip]

I don't see the interest of such cursors. Actually, most often, the
cursors are 64x64 and 'A' is either 0 or 0xff. As the Armada 510
supports 64x64 cursors with transparency, it would be more useful to
implement these ones...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

--- Comment #33 from Paul Bodenbenner  ---
For sure 3.11.4 is already in the stable repository.

-- 
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 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Jean-Francois Moine 
On Sun, 06 Oct 2013 23:11:56 +0100
Russell King  wrote:

> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/armada/Kconfig  |9 +++
>  drivers/gpu/drm/armada/armada_drv.c |   42 
> +++
>  2 files changed, 51 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
> index c7a0a94..87e62dd 100644
> --- a/drivers/gpu/drm/armada/Kconfig
> +++ b/drivers/gpu/drm/armada/Kconfig
> @@ -13,3 +13,12 @@ config DRM_ARMADA
> This driver provides no built-in acceleration; acceleration is
> performed by other IP found on the SoC.  This driver provides
> kernel mode setting and buffer management to userspace.
> +
> +config DRM_ARMADA_TDA1998X
> + bool "Support TDA1998X HDMI output"
> + depends on DRM_ARMADA != n
> + depends on I2C && DRM_I2C_NXP_TDA998X = y
> + default y
> + help
> +   Support the TDA1998x HDMI output device found on the Solid-Run
> +   CuBox.

It seems we are going backwards: as the Armada based boards will soon
move to full DT (mvebu), you are making an exception for the Cubox, so
that there should be Cubox specific kernels. I don't like that...

> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index db62f1b..69517cf 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -16,6 +16,42 @@
>  #include 
>  #include "armada_ioctlP.h"
>  
> +#ifdef CONFIG_DRM_ARMADA_TDA1998X
> +#include 
> +#include "armada_slave.h"
> +
> +static struct tda998x_encoder_params params = {
> + /* With 0x24, there is no translation between vp_out and int_vp
> + FB  LCD out PinsVIP Int Vp
> + R:23:16 R:7:0   VPC7:0  7:0 7:0[R]
> + G:15:8  G:15:8  VPB7:0  23:16   23:16[G]
> + B:7:0   B:23:16 VPA7:0  15:815:8[B]
> + */
> + .swap_a = 2,
> + .swap_b = 3,
> + .swap_c = 4,
> + .swap_d = 5,
> + .swap_e = 0,
> + .swap_f = 1,

I still don't agree. You don't need to invert R <-> B for the Cubox at
the tda998x level: this may be done setting as it should be the
CFG_GRA_SWAPRB flag of the lcd register LCD_SPU_DMA_CTRL0.

> + .audio_cfg = BIT(2),
> + .audio_frame[1] = 1,
> + .audio_format = AFMT_SPDIF,
> + .audio_sample_rate = 44100,

These values are rather mysterious!

Looking at the tda998x driver, I found that:
- audio_cfg can be 0x03 for i2s input and 0x04 for spdif input
- audio_frame[1] is the (channel count - 1)
- audio_format and audio_sample_rate are hardcoding the audio input to
  spdif and the sample rate to 44.1kHz

I don't think that these parameters are needed:

- the tda998x must be prepared to get either i2s or spdif as the audio
  input at any time. The choice of this input results from the audio
  subsystem constraints (codec) found at audio streaming start time.

- the channel count is always 2 for spdif. Do we need to accept four
  channels for i2s?

- audio on hdmi works fine for me at any input rate setting the tda998x
  sample rate to 96 kHz. Anyway, in the actual tda998x driver, this
  audio_sample_rate value is just used to set an approximate value of
  ACR. But this value is not used because an optimal value is computed
  by the hardware thanks to the flag AIP_CNTRL_0_ACR_MAN!

[snip]

The remaining patch is Cubox specific.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70219] New: [radeon] Cannot restore video mode after vt switch or GPU lockup

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70219

  Priority: medium
Bug ID: 70219
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [radeon] Cannot restore video mode after vt switch or
GPU lockup
  Severity: minor
Classification: Unclassified
OS: Linux (All)
  Reporter: pupyki...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Steps to reproduce:
- boot using "radeon.modeset=1 video=DIN-1:1024x768-24@60e"
- switch off S-Video: "xrandr --output DIN --off"
- Ctrl+Alt+F1 - vt1 console appears
- Ctrl+Alt+F7 - monitor shows no video input

Workaround:
- Ctrl+Alt+F1 again
- login and export proper DISPLAY
- xrandr --output DIN --auto
- Ctrl+Alt+F7 - Xorg works

Booting with forced S-Video and switching it off from Xorg makes problem. Also
video mode cannot be restored in this case after GPU lockup. Restarting Xorg
from vt1 helps too.

Environment:
Arch Linux x86_64
linux 3.11.3-1
xorg-server 1.14.3-1
libdrm 2.4.46-2
xf86-video-ati 1:7.2.0-1

-- 
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: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)

2013-10-07 Thread Christian König 

Am 07.10.2013 10:58, schrieb Rafał Miłecki:

2013/10/7 Christian König :

Why didn't you just asked me?

I was told on #radeon you're on holidays ;) I was trying to catch you.


I'm on vacation right now, but got back yesterday and now greping though 
my accumulated mails ;)





I've figured this out over five years ago by applying brute force to one of
the "magic" DVI->HDMI adapters that came with my original RV635. And it
indeed contains an extra EEPROM on the I2C bus ;)

Did you find any way to workaround this? So I can use my generic
adapter with fglrx for audio?


Not that I know of any, well those adapters where only used on the early 
RV6xx HDMI days. IIRC my later RV7xx worked well with the 10meters 
DVI->HDMI cable fglrx on RV6xx failed.


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

[PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues

2013-10-07 Thread Archit Taneja 
With the new omapdss device model. The user(omapdrm/omapfb) of a omap_dss_device
has to call connect() to use the device. A connect() call can request to defer
probe if the device(or the previous entities in the chain) have missing
resources like a regulator or an I2C bus.

We make omapdrm defer probe by trying to first connect all panels, and request
for deferral if any panel requests for a defer. This makes sure that all the
panels are set up correctly when we finally proceed with omapdrm initialization.

In order for omapdrm module to be removed successfully, we need to disconnect
the panels which omapdrm connected. Another thing noticed was that omapdrm
insertion followed by some usage results in panels getting enabled.

Trying to remove omapdrm with a panel enabled results in failure while
disconnecting. This leaves omapdss panels in a bad state. I have added an
explicit panel disable in the omap_encoder_destroy() op, I needed some
suggestions on whether there is a better way to do this.

changes in v2:
- Add special case when no panels are available to connect.
- Make sure panels are diabled (and then disconnected) when omapdrm is removed

Archit Taneja (2):
  drm: omap: fix: Defer probe if an omapdss device requests for it at
connect
  drm: omap: disconnect devices when omapdrm module is removed

 drivers/gpu/drm/omapdrm/omap_crtc.c|  5 +++
 drivers/gpu/drm/omapdrm/omap_drv.c | 77 --
 drivers/gpu/drm/omapdrm/omap_drv.h |  1 +
 drivers/gpu/drm/omapdrm/omap_encoder.c |  3 ++
 4 files changed, 64 insertions(+), 22 deletions(-)

-- 
1.8.1.2

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

[PATCH v2 1/2] drm: omap: fix: Defer probe if an omapdss device requests for it at connect

2013-10-07 Thread Archit Taneja 
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.

omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe deferral
if a panel's connect op returns -EPROBE_DEFER.

A special case has to be considered when no panels are available to connect when
omapdrm probes. In this case too, we defer probe and expect that a panel will be
available to connect the next time.

The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.

Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.

This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c |  5 +++
 drivers/gpu/drm/omapdrm/omap_drv.c  | 70 +
 drivers/gpu/drm/omapdrm/omap_drv.h  |  1 +
 3 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(&mgr_ops);
 }
 
+void omap_crtc_pre_uninit(void)
+{
+   dss_uninstall_mgr_ops();
+}
+
 /* initialize crtc */
 struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..be3bfe1 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,43 @@ static bool channel_used(struct drm_device *dev, enum 
omap_channel channel)
return false;
 }
 
+static int omap_connect_dssdevs(void)
+{
+   int r;
+   struct omap_dss_device *dssdev = NULL;
+   bool no_displays = true;
+
+   for_each_dss_dev(dssdev) {
+   r = dssdev->driver->connect(dssdev);
+   if (r == -EPROBE_DEFER) {
+   omap_dss_put_device(dssdev);
+   goto cleanup;
+   } else if (r) {
+   dev_warn(dssdev->dev, "could not connect display: %s\n",
+   dssdev->name);
+   } else {
+   no_displays = false;
+   }
+   }
+
+   if (no_displays)
+   return -EPROBE_DEFER;
+
+   return 0;
+
+cleanup:
+   /*
+* if we are deferring probe, we disconnect the devices we previously
+* connected
+*/
+   dssdev = NULL;
+
+   for_each_dss_dev(dssdev)
+   dssdev->driver->disconnect(dssdev);
+
+   return r;
+}
+
 static int omap_modeset_init(struct drm_device *dev)
 {
struct omap_drm_private *priv = dev->dev_private;
@@ -95,9 +132,6 @@ static int omap_modeset_init(struct drm_device *dev)
int num_mgrs = dss_feat_get_num_mgrs();
int num_crtcs;
int i, id = 0;
-   int r;
-
-   omap_crtc_pre_init();
 
drm_mode_config_init(dev);
 
@@ -119,26 +153,8 @@ static int omap_modeset_init(struct drm_device *dev)
enum omap_channel channel;
struct omap_overlay_manager *mgr;
 
-   if (!dssdev->driver) {
-   dev_warn(dev->dev, "%s has no driver.. skipping it\n",
-   dssdev->name);
-   continue;
-   }
-
-   if (!(dssdev->driver->get_timings ||
-   dssdev->driver->read_edid)) {
-   dev_warn(dev->dev, "%s driver does not support "
-   "get_timings or read_edid.. skipping it!\n",
-   dssdev->name);
-   continue;
-   }
-
-   r = dssdev->driver->connect(dssdev);
-   if (r) {
-   dev_err(dev->dev, "could not connect display: %s\n",
-   dssdev->name);
+   if (!omapdss_device_is_connected(dssdev))
continue;
-   }
 
encoder = omap_encoder_init(dev, dssd

[PATCH v2 2/2] drm: omap: disconnect devices when omapdrm module is removed

2013-10-07 Thread Archit Taneja 
omapdrm establishes connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it also causes
issues when we try to remove or re-insert omapdrm module.

Before omapdrm module is removed, we need to make sure that all the connectors
are disabled. Without this, the omap_dss_devices won't disconnect, and cause
issues when we try to re-insert omapdrm.

For now, disable encoders in omap_encoder_destroy. We are not clear if this is
the best place to disable an encoder. This makes successive module insertions
and removal work unlike before. But it leads to warning backtraces when the
module is removed. The func omap_crtc_destroy() gves a warning because
omap_crtc->apply_irq.registered is still set when we try to disable the crtc. I
haven't figured out a way to prevent this, would appreciate some help here.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 15 +++
 drivers/gpu/drm/omapdrm/omap_encoder.c |  3 +++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index be3bfe1..45f7ec6 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum 
omap_channel channel)
 
return false;
 }
+static void omap_disconnect_dssdevs(void)
+{
+   struct omap_dss_device *dssdev = NULL;
+
+   for_each_dss_dev(dssdev)
+   dssdev->driver->disconnect(dssdev);
+}
 
 static int omap_connect_dssdevs(void)
 {
@@ -116,10 +123,7 @@ cleanup:
 * if we are deferring probe, we disconnect the devices we previously
 * connected
 */
-   dssdev = NULL;
-
-   for_each_dss_dev(dssdev)
-   dssdev->driver->disconnect(dssdev);
+   omap_disconnect_dssdevs();
 
return r;
 }
@@ -694,6 +698,9 @@ static int pdev_remove(struct platform_device *device)
DBG("");
drm_platform_exit(&omap_drm_driver, device);
 
+   omap_disconnect_dssdevs();
+   omap_crtc_pre_uninit();
+
platform_driver_unregister(&omap_dmm_driver);
return 0;
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 6a12e89..5290a88 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -51,6 +51,9 @@ struct omap_dss_device *omap_encoder_get_dssdev(struct 
drm_encoder *encoder)
 static void omap_encoder_destroy(struct drm_encoder *encoder)
 {
struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
+
+   omap_encoder_set_enabled(encoder, false);
+
drm_encoder_cleanup(encoder);
kfree(omap_encoder);
 }
-- 
1.8.1.2

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

[Bug 69729] HDMI audio stopped working on HD 3470 (RV620/M82)

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=69729

--- Comment #34 from Rafał Miłecki  ---
Paul: OK, you're right. It was a mistake in backporting the fix.

Reported: http://permalink.gmane.org/gmane.linux.kernel.stable/66333

-- 
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 62601] 3.11 radeon hdmi audio does not work

2013-10-07 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=62601

Rafał Miłecki  changed:

   What|Removed |Added

 CC||zaj...@gmail.com

--- Comment #1 from Rafał Miłecki  ---
RS880 is a DCE 3.0, you may want the following fix:
drm/radeon: fix hdmi audio on DCE3.0/3.1 asics

Please try 3.11.4 which includes it and report back.

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

Re: [PATCH 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

2013-10-07 Thread Jean-Francois Moine 
On Mon, 7 Oct 2013 10:40:08 +0100
Russell King - ARM Linux  wrote:

> > > This patch adds ARGB hardware cursor support to the DRM driver for the
> > > Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
> > > 64x32 resolutions.  
> > [snip]
> > 
> > I don't see the interest of such cursors. Actually, most often, the
> > cursors are 64x64 and 'A' is either 0 or 0xff. As the Armada 510
> > supports 64x64 cursors with transparency, it would be more useful to
> > implement these ones...  
> 
> Sorry, you're completely wrong there.  Xorg uses an alphablended cursor.
> This patch is a result of trialling each of the Armada's cursor options
> and this is the only one which results in a reasonable looking cursor.

Strange. I am using the 64x64 cursor with transparency of the 510 for
many months and I never saw any problem.

If you absolutely want to have all transparency shades, you should
accept 64x64 cursors and test if they may be rendered as 64x32 or 32x64,
i.e. test that there is only pure transparency in the non-rendered
rectangles...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Jean-Francois Moine 
On Mon, 7 Oct 2013 10:44:04 +0100
Russell King - ARM Linux  wrote:

> On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
[snip]
> > It seems we are going backwards: as the Armada based boards will soon
> > move to full DT (mvebu), you are making an exception for the Cubox, so
> > that there should be Cubox specific kernels. I don't like that...
> 
> *Ignored*.  You know why.

Sorry. I don't see why. May you explain again?

> > > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> > > b/drivers/gpu/drm/armada/armada_drv.c
[snip]
> > > +static struct tda998x_encoder_params params = {
> > > + /* With 0x24, there is no translation between vp_out and int_vp
> > > + FB  LCD out PinsVIP Int Vp
> > > + R:23:16 R:7:0   VPC7:0  7:0 7:0[R]
> > > + G:15:8  G:15:8  VPB7:0  23:16   23:16[G]
> > > + B:7:0   B:23:16 VPA7:0  15:815:8[B]
> > > + */
> > > + .swap_a = 2,
> > > + .swap_b = 3,
> > > + .swap_c = 4,
> > > + .swap_d = 5,
> > > + .swap_e = 0,
> > > + .swap_f = 1,
> > 
> > I still don't agree. You don't need to invert R <-> B for the Cubox at
> > the tda998x level: this may be done setting as it should be the
> > CFG_GRA_SWAPRB flag of the lcd register LCD_SPU_DMA_CTRL0.
> 
> You are totally and utterly wrong there.  We need R and B presented on
> their correct lanes to the TDA998x so that the Armadas YUV->RGB
> conversion works.  Setting CFG_GRA_SWAPRB does not swap the YUV output
> to match, neither does setting any of the other bits.
> 
> CFG_GRA_SWAPRB is all about the _graphics_ _framebuffer_ format, it's got
> nothing to do at all with how the output is wired.

Then, may you explain why you must swap R/B on simple RGB output?

From your [PATCH 2/5] DRM: Armada: Add Armada DRM driver:

+   FMT(RGB888, 888PACK,CFG_SWAPRB);
+   FMT(BGR888, 888PACK,0);

+   FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);

> > > + .audio_cfg = BIT(2),
> > > + .audio_frame[1] = 1,
> > > + .audio_format = AFMT_SPDIF,
> > > + .audio_sample_rate = 44100,
> > 
> > These values are rather mysterious!
> 
> Also I'm going to ignore this comment, because quite honestly, I think
> this is worthless.  You haven't investigated how the TDA998x actually
> gets setup by Rabeeh.

Rabeeh did the most he could to have a working Cubox. He used bad
written drivers and he had not the time to think about how the drivers
could be enhanced.

Here is a small story about i2s/spdif: once, I set the tda998x to use
the spdif input, and at this time, I was using the dummy codec.
This codec accepts the format 32_LE, as does the audio device, but the
output cannot go to spdif. Result: no hdmi sound.

Should we restrict the hdmi transmitter to spdif (thus 'no 32 bits
stream') or to i2s (thus 'no compressed stream') only, or accept both
i2s and spdif and allow a full range of supported audio streams?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
+
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC PATCH 1/4] mipi-dsi-bus: add MIPI DSI bus support

2013-10-07 Thread Bert Kenward 
On Tuesday September 24 2013 at 15:23, Andrzej Hajda wrote:
> MIPI DSI is a high-speed serial interface to transmit
> data from/to host to display module.
> 
> Signed-off-by: Andrzej Hajda 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/video/display/Kconfig|   4 +
>  drivers/video/display/Makefile   |   1 +
>  drivers/video/display/mipi-dsi-bus.c | 332
> +++
>  include/video/display.h  |   3 +
>  include/video/mipi-dsi-bus.h | 144 +++
>  5 files changed, 484 insertions(+)

 diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h
> new file mode 100644
> index 000..a78792d
> --- /dev/null
> +++ b/include/video/mipi-dsi-bus.h
> @@ -0,0 +1,144 @@
> +/*
> + * MIPI DSI Bus
> + *
> + * Copyright (C) 2013, Samsung Electronics, Co., Ltd.
> + * Andrzej Hajda 
> + *
> + * 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.
> + */
> +
> +#ifndef __MIPI_DSI_BUS_H__
> +#define __MIPI_DSI_BUS_H__
> +
> +#include 
> +#include 
> +
> +struct mipi_dsi_bus;
> +struct mipi_dsi_device;
> +
> +struct mipi_dsi_bus_ops {
> + int (*set_power)(struct mipi_dsi_bus *bus, struct mipi_dsi_device
> *dev,
> +  bool on);
> + int (*set_stream)(struct mipi_dsi_bus *bus, struct mipi_dsi_device
> *dev,
> +   bool on);
> + int (*transfer)(struct mipi_dsi_bus *bus, struct mipi_dsi_device
> *dev,
> + u8 type, const u8 *tx_buf, size_t tx_len, u8 *rx_buf,
> + size_t rx_len);
> +};
> +
> +#define DSI_MODE_VIDEO   (1 << 0)
> +#define DSI_MODE_VIDEO_BURST (1 << 1)
> +#define DSI_MODE_VIDEO_SYNC_PULSE(1 << 2)
> +#define DSI_MODE_VIDEO_AUTO_VERT (1 << 3)
> +#define DSI_MODE_VIDEO_HSE   (1 << 4)
> +#define DSI_MODE_VIDEO_HFP   (1 << 5)
> +#define DSI_MODE_VIDEO_HBP   (1 << 6)
> +#define DSI_MODE_VIDEO_HSA   (1 << 7)
> +#define DSI_MODE_VSYNC_FLUSH (1 << 8)
> +#define DSI_MODE_EOT_PACKET  (1 << 9)
> +
> +enum mipi_dsi_pixel_format {
> + DSI_FMT_RGB888,
> + DSI_FMT_RGB666,
> + DSI_FMT_RGB666_PACKED,
> + DSI_FMT_RGB565,
> +};
> +
> +struct mipi_dsi_interface_params {
> + enum mipi_dsi_pixel_format format;
> + unsigned long mode;
> + unsigned long hs_clk_freq;
> + unsigned long esc_clk_freq;
> + unsigned char data_lanes;
> + unsigned char cmd_allow;
> +};
> +
> +struct mipi_dsi_bus {
> + struct device *dev;
> + const struct mipi_dsi_bus_ops *ops;
> +};
> +
> +#define MIPI_DSI_MODULE_PREFIX   "mipi-dsi:"
> +#define MIPI_DSI_NAME_SIZE   32
> +
> +struct mipi_dsi_device_id {
> + char name[MIPI_DSI_NAME_SIZE];
> + __kernel_ulong_t driver_data/* Data private to the driver */
> + __aligned(sizeof(__kernel_ulong_t));
> +};
> +
> +struct mipi_dsi_device {
> + char name[MIPI_DSI_NAME_SIZE];
> + int id;
> + struct device dev;
> +
> + const struct mipi_dsi_device_id *id_entry;
> + struct mipi_dsi_bus *bus;
> + struct videomode vm;
> + struct mipi_dsi_interface_params params;
> +};
> +
> +#define to_mipi_dsi_device(d)container_of(d, struct
> mipi_dsi_device, dev)
> +
> +int mipi_dsi_device_register(struct mipi_dsi_device *dev,
> +  struct mipi_dsi_bus *bus);
> +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev);
> +
> +struct mipi_dsi_driver {
> + int(*probe)(struct mipi_dsi_device *);
> + int(*remove)(struct mipi_dsi_device *);
> + struct device_driver driver;
> + const struct mipi_dsi_device_id *id_table;
> +};
> +
> +#define to_mipi_dsi_driver(d)container_of(d, struct
> mipi_dsi_driver, driver)
> +
> +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv);
> +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv);
> +
> +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device
> *dev)
> +{
> + return dev_get_drvdata(&dev->dev);
> +}
> +
> +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev,
> + void *data)
> +{
> + dev_set_drvdata(&dev->dev, data);
> +}
> +
> +int of_mipi_dsi_register_devices(struct mipi_dsi_bus *bus);
> +void mipi_dsi_unregister_devices(struct mipi_dsi_bus *bus);
> +
> +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do
> + * anything special in module init/exit.  This eliminates a lot of
> + * boilerplate.  Each module may only use this macro once, and
> + * calling it replaces module_init() and module_exit()
> + */
> +#define module_mipi_dsi_driver(__mipi_dsi_driver) \
> + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \
> + mipi_dsi_driver_unregister)
> +
> +int mipi_dsi_set_power(struct mipi_dsi_device *dev, bool

Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT

2013-10-07 Thread Christian König 

First of all, I can't complain about the reliability of the hardware
GPU reset. It's mostly the kernel driver that happens to run into a
deadlock at the same time.


Alex and I spend quite some time on making this reliable again after 
activating more rings and adding VM support. The main problem is that I 
couldn't figure out where the CPU deadlock comes from, cause I couldn't 
reliable reproduce the issue.


What is the content of /proc//task/*/stack and 
sys/kernel/debug/dri/0/radeon_fence_info when the X server is stuck in 
the deadlock situation?


I'm pretty sure that we nearly always have a problem when two threads 
are waiting for fences on one of them detects that we have a lockup 
while the other one keeps holding the exclusive lock. Signaling all 
fences might work around that problem, but it probably would be better 
to fix the underlying issue.


Going to take a deeper look into it.

Christian.

Am 03.10.2013 02:45, schrieb Marek Olšák:

First of all, I can't complain about the reliability of the hardware
GPU reset. It's mostly the kernel driver that happens to run into a
deadlock at the same time.

Regarding the issue with fences, the problem is that the GPU reset
completes successfully according to dmesg, but X doesn't respond. I
can move the cursor on the screen, but I can't do anything else and
the UI is frozen. gdb says that X is stuck in GEM_WAIT_IDLE. I can
easily reproduce this, because it's the most common reason why a GPU
lockup leads to frozen X. The GPU actually recovers, but X is hung. I
can't tell whether the fences are just not signalled or whether there
is actually a real CPU deadlock I can't see.

This patch makes the problem go away and GPU resets are successful
(except for extreme cases, see below). With a small enough lockup
timeout, the lockups are just a minor annoyance and I thought I could
get through a piglit run just with a few tens or hundreds of GPU
resets...

A different type of deadlock showed up, though it needs a lot of
concurrently-running apps like piglit. What happened is that the
kernel driver was stuck/deadlocked in radeon_cs_ioctl presumably due
to a GPU hang while holding onto the exclusive lock, and another
thread wanting to do the GPU reset was unable to acquire the lock.

That said, I will use the patch locally, because it helps a lot. I got
a few lockups while writing this email and I'm glad I didn't have to
reboot.

Marek

On Wed, Oct 2, 2013 at 4:50 PM, Christian König  wrote:

Possible, but I would rather guess that this doesn't work because the IB test 
runs into a deadlock situation and so the GPU reset never fully completes.

Can you reproduce the problem?

If you want to make GPU resets more reliable I would rather suggest to remove 
the ring lock dependency.
Then we should try to give all the fence wait functions a (reliable) timeout 
and move reset handling a layer up into the ioctl functions. But for this you 
need to rip out the old PM code first.

Christian.

Marek Olšák  schrieb:


I'm afraid signalling the fences with an IB test is not reliable.

Marek

On Wed, Oct 2, 2013 at 3:52 PM, Christian König  wrote:

NAK, after recovering from a lockup the first thing we do is signalling all 
remaining fences with an IB test.

If we don't recover we indeed signal all fences manually.

Signalling all fences regardless of the outcome of the reset creates problems 
with both types of partial resets.

Christian.

Marek Olšák  schrieb:


From: Marek Olšák 

After a lockup, fences are not signalled sometimes, causing
the GEM_WAIT_IDLE ioctl to never return, which sometimes results
in an X server freeze.

This fixes only one of many deadlocks which can occur during a lockup.

Signed-off-by: Marek Olšák 
---
drivers/gpu/drm/radeon/radeon_device.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 841d0e0..7b97baa 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1552,6 +1552,11 @@ int radeon_gpu_reset(struct radeon_device *rdev)
   radeon_save_bios_scratch_regs(rdev);
   /* block TTM */
   resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
+
+  mutex_lock(&rdev->ring_lock);
+  radeon_fence_driver_force_completion(rdev);
+  mutex_unlock(&rdev->ring_lock);
+
   radeon_pm_suspend(rdev);
   radeon_suspend(rdev);

--
1.8.1.2

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


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

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Erik Faye-Lund 
On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
 wrote:
> Rework the address table code for the host1x firewall. The previous
> implementation allocated a bitfield but didn't check for a valid pointer
> so it could potentially crash.

I don't think it could crash. The bitmaps was allocated as a 256-bit
field, and the register offset gets AND'ed with 0xFF before being
looked up. What am I missing?

> Furthermore setting up a bitfield makes
> the code more complex than it needs to be.

Doesn't this perform worse than the current implementation? Going from
1 to 13 checks per write sounds less than ideal to me...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70207] rs690: kernel can't bring lvds in dpms on mode

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70207

--- Comment #1 from David "okias" Heidelberger  ---
In cases STR (using hibernate-ram) within console it work well too.

-- 
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 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Jean-Francois Moine 
On Mon, 7 Oct 2013 12:09:02 +0100
Russell King - ARM Linux  wrote:

> > Here is a small story about i2s/spdif: once, I set the tda998x to use
> > the spdif input, and at this time, I was using the dummy codec.
> > This codec accepts the format 32_LE, as does the audio device, but the
> > output cannot go to spdif. Result: no hdmi sound.  
> 
> How ASoC works in this regard is that the capabilities are the _union_ of
> the codec and the cpu DAIs.
> 
> The SPDIF transmitter codec supports 16, 20 and 24 bits per sample but not
> 32.  Quite simply, that's because the SPDIF format does not allow 32-bits
> per sample.  Therefore, 32_LE is not available for use with audio output,
> and userspace must convert down to something which the hardware does
> support.
> 
> "Because I2S can support 32-bit audio" is a poor reason, because you can't
> pass 32-bit audio via HDMI due to a subframe being limited to 28 bits - up
> to 24 bits for the sample and 4 bits of control/status information.

OK. So, to resume, if both i2s and spdif are furnished by the audio
subsystem, the tda998x must use spdif only (with the spdif codec).

Then, the declaration of the tda998x in the DT will include an
optional audio property, say 'audio-input' with the values "i2s" or
"spdif" which corresponds to your parameter 'audio_format'.

Also, from your video swap explanation, the DT will contain some video
property(ies) TBD.

The remaining question is: do we need more audio parameters?

- the audio_cfg value is defined by i2s/spdif (3 or 4)
- the audio_frame[1] value is always 1 (2 channels)
- audio_sample_rate is useless

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Thierry Reding 
On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
>  wrote:
> > Rework the address table code for the host1x firewall. The previous
> > implementation allocated a bitfield but didn't check for a valid pointer
> > so it could potentially crash.
> 
> I don't think it could crash. The bitmaps was allocated as a 256-bit
> field, and the register offset gets AND'ed with 0xFF before being
> looked up. What am I missing?

The pointer returned from the allocation is never checked, so it could
theoretically be NULL and be used regardless.

Also I'm not sure that AND'ing with 0xff is the right thing to do here.

> > Furthermore setting up a bitfield makes
> > the code more complex than it needs to be.
> 
> Doesn't this perform worse than the current implementation? Going from
> 1 to 13 checks per write sounds less than ideal to me...

I'm not so sure. Caching should alleviate the issue with the increased
amount of data. Then there's the fact that previously we needed to
divide and compute the remainder of the division for the BIT_MASK and
BIT_WORD operations.

One other added benefit of this approach is that the address registers
are stored in a const array and therefore could reside in a read-only
memory region. With the previous approach, once somebody had access to
the bitmap, it could easily be overwritten with zeros and effectively
make the firewall useless. I'm not sure how likely that would be, but it
could be done.

I guess one could actually go and run a benchmark against both versions
and balance the performance impact against the possible security
implications. But given that we don't really have any benchmarks that's
pretty hard to do.

Thierry


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

Re: [PATCH 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

2013-10-07 Thread Siarhei Siamashka 
On Mon, 7 Oct 2013 11:32:50 +0100
Russell King - ARM Linux  wrote:

> On Mon, Oct 07, 2013 at 12:09:22PM +0200, Jean-Francois Moine wrote:
> > On Mon, 7 Oct 2013 10:40:08 +0100
> > Russell King - ARM Linux  wrote:
> > 
> > > > > This patch adds ARGB hardware cursor support to the DRM driver for the
> > > > > Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
> > > > > 64x32 resolutions.  
> > > > [snip]
> > > > 
> > > > I don't see the interest of such cursors. Actually, most often, the
> > > > cursors are 64x64 and 'A' is either 0 or 0xff. As the Armada 510
> > > > supports 64x64 cursors with transparency, it would be more useful to
> > > > implement these ones...  
> > > 
> > > Sorry, you're completely wrong there.  Xorg uses an alphablended cursor.
> > > This patch is a result of trialling each of the Armada's cursor options
> > > and this is the only one which results in a reasonable looking cursor.
> > 
> > Strange. I am using the 64x64 cursor with transparency of the 510 for
> > many months and I never saw any problem.
> 
> When I tried it, all cursors had variable alpha, and converting the
> alpha to a single transparency bit made the cursor look rubbish against
> certain backgrounds.
> 
> > If you absolutely want to have all transparency shades, you should
> > accept 64x64 cursors and test if they may be rendered as 64x32 or
> > 32x64, i.e. test that there is only pure transparency in the non-
> > rendered rectangles...
> 
> That is policy, and that is something which can be done by the X server
> rather than the kernel.  The kernel exposes the hardware capabilities,
> which are to allow a 64x32 or a 32x64 cursor.  Userspace can make the
> decision dynamically which it wishes to use.
> 
> However, what you're suggesting is dangerous.  What do you do when you're
> presented with a cursor which is 64x64 ?  Do you:
> 
> (a) not display it
> (b) crash the X server
> 
> There isn't a fallback to using software cursors available in the X server
> because there's no error reporting for a failed hardware cursor update.

Hmm, maybe I'm missing something, but doesn't returning FALSE from
UseHWCursorARGB just make the X server fallback to using a software
cursor?

https://github.com/ssvb/xf86-video-fbturbo/blob/689c08256555/src/sunxi_disp_hwcursor.c#L72

I'm just doing this. And also have hooks to notify the DRI2 code about
the status of the cursor. In the case if the hardware cursor is not
enabled, hardware overlays can't be safely used with the software
cursor and we need to fallback to CPU/GPU copy instead of zero-copy
buffers swapping.

And I fully agree that it is the responsibility of the kernel to expose
as much of the hardware capabilities as possible (without compromising
reliability and/or security).

-- 
Best regards,
Siarhei Siamashka
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Erik Faye-Lund 
On Mon, Oct 7, 2013 at 2:14 PM, Thierry Reding  wrote:
> On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
>> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
>>  wrote:
>> > Rework the address table code for the host1x firewall. The previous
>> > implementation allocated a bitfield but didn't check for a valid pointer
>> > so it could potentially crash.
>>
>> I don't think it could crash. The bitmaps was allocated as a 256-bit
>> field, and the register offset gets AND'ed with 0xFF before being
>> looked up. What am I missing?
>
> The pointer returned from the allocation is never checked, so it could
> theoretically be NULL and be used regardless.
>

Right. Thanks for clarifying.

> Also I'm not sure that AND'ing with 0xff is the right thing to do here.

Well, maybe not. I'm not entirely convinced it's *not*, though.

>> > Furthermore setting up a bitfield makes
>> > the code more complex than it needs to be.
>>
>> Doesn't this perform worse than the current implementation? Going from
>> 1 to 13 checks per write sounds less than ideal to me...
>
> I'm not so sure. Caching should alleviate the issue with the increased
> amount of data. Then there's the fact that previously we needed to
> divide and compute the remainder of the division for the BIT_MASK and
> BIT_WORD operations.

That's an AND and a shift, not division and modulo, both single-cycle
instructions on ARM. I'm pretty sure that'd be a win.

> One other added benefit of this approach is that the address registers
> are stored in a const array and therefore could reside in a read-only
> memory region. With the previous approach, once somebody had access to
> the bitmap, it could easily be overwritten with zeros and effectively
> make the firewall useless. I'm not sure how likely that would be, but it
> could be done.

Perhaps the bitmap could be generated compile-time and stuck in
read-only memory?

> I guess one could actually go and run a benchmark against both versions
> and balance the performance impact against the possible security
> implications. But given that we don't really have any benchmarks that's
> pretty hard to do.

Well, perhaps we could have both? :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Terje Bergström 
On 07.10.2013 15:14, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
>> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
>>  wrote:
>>> Rework the address table code for the host1x firewall. The previous
>>> implementation allocated a bitfield but didn't check for a valid pointer
>>> so it could potentially crash.
>>
>> I don't think it could crash. The bitmaps was allocated as a 256-bit
>> field, and the register offset gets AND'ed with 0xFF before being
>> looked up. What am I missing?
> 
> The pointer returned from the allocation is never checked, so it could
> theoretically be NULL and be used regardless.
> 
> Also I'm not sure that AND'ing with 0xff is the right thing to do here.

Oops, there's a check for NULL missing. If that allocation fails, probe
should fail, so we just need to propagate the error condition. Otherwise
we might just leave the firewall off, and let everything go in unchecked.

AND 0xff is necessary, because the same registers are mirrored in
multiple contexts. AND removes the offset coming from context, and
leaves just the plain register offset.

> I'm not so sure. Caching should alleviate the issue with the increased
> amount of data. Then there's the fact that previously we needed to
> divide and compute the remainder of the division for the BIT_MASK and
> BIT_WORD operations.

Don't these get compiled into shifts and bitwise ands?

> One other added benefit of this approach is that the address registers
> are stored in a const array and therefore could reside in a read-only
> memory region. With the previous approach, once somebody had access to
> the bitmap, it could easily be overwritten with zeros and effectively
> make the firewall useless. I'm not sure how likely that would be, but it
> could be done.

If somebody gets access to the bitmap, he has access to kernel data
structures. GR2D firewall is the least of our worries in this case.

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

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Erik Faye-Lund 
On Mon, Oct 7, 2013 at 2:53 PM, Erik Faye-Lund  wrote:
> On Mon, Oct 7, 2013 at 2:14 PM, Thierry Reding  
> wrote:
>> On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
>>> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
>>>  wrote:
>>> > Rework the address table code for the host1x firewall. The previous
>>> > implementation allocated a bitfield but didn't check for a valid pointer
>>> > so it could potentially crash.
>>>
>>> I don't think it could crash. The bitmaps was allocated as a 256-bit
>>> field, and the register offset gets AND'ed with 0xFF before being
>>> looked up. What am I missing?
>>
>> The pointer returned from the allocation is never checked, so it could
>> theoretically be NULL and be used regardless.
>>
>> Also I'm not sure that AND'ing with 0xff is the right thing to do here.
>
> Well, maybe not. I'm not entirely convinced it's *not*, though.
>

I'm sorry, I intended to fill out a bit more here before I hit send,
and totally forgot.

Point is, it seems only 0x00..0x4c is used (and then repeated at
multiples of 0x4000 for each context, but the offsets don't have
enough bits to reach that far), from looking at the TRM.

So the question is really how the hardware treats writes to
non-existent registers. My guess would be that they are simply not
recorded, and if that's the case it doesn't matter what we do. And
doing an unconditional AND is faster than doing a bit-test followed by
a conditional branch.

Of course, if the hardware does *not* ignore writes to non-existent
register, then we might be in trouble. But for that, we'd probably
want a full map of valid registers, not just saying that they aren't
pointers, no?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Erik Faye-Lund 
On Mon, Oct 7, 2013 at 2:52 PM, Terje Bergström  wrote:
> On 07.10.2013 15:14, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
>>> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
>>>  wrote:
 Rework the address table code for the host1x firewall. The previous
 implementation allocated a bitfield but didn't check for a valid pointer
 so it could potentially crash.
>>>
>>> I don't think it could crash. The bitmaps was allocated as a 256-bit
>>> field, and the register offset gets AND'ed with 0xFF before being
>>> looked up. What am I missing?
>>
>> The pointer returned from the allocation is never checked, so it could
>> theoretically be NULL and be used regardless.
>>
>> Also I'm not sure that AND'ing with 0xff is the right thing to do here.
>
> Oops, there's a check for NULL missing. If that allocation fails, probe
> should fail, so we just need to propagate the error condition. Otherwise
> we might just leave the firewall off, and let everything go in unchecked.
>
> AND 0xff is necessary, because the same registers are mirrored in
> multiple contexts. AND removes the offset coming from context, and
> leaves just the plain register offset.
>

The offsets in the commands don't have enough bits to reach over to
the next context. The contexts are repeated at multiples of 0x4000,
and 0xFFF is the largest encodable offset. So I don't really thing the
AND is needed for *that* purpose.

> If somebody gets access to the bitmap, he has access to kernel data
> structures. GR2D firewall is the least of our worries in this case.

Indeed, that's only a problem if someone is already on the other side
of the air-tight hatch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/27] drm/tegra: gr2d: Miscellaneous cleanups

2013-10-07 Thread Thierry Reding 
On Mon, Oct 07, 2013 at 03:52:28PM +0300, Terje Bergström wrote:
> On 07.10.2013 15:14, Thierry Reding wrote:
> > * PGP Signed by an unknown key
> > 
> > On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
> >> On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
> >>  wrote:
> >>> Rework the address table code for the host1x firewall. The previous
> >>> implementation allocated a bitfield but didn't check for a valid pointer
> >>> so it could potentially crash.
> >>
> >> I don't think it could crash. The bitmaps was allocated as a 256-bit
> >> field, and the register offset gets AND'ed with 0xFF before being
> >> looked up. What am I missing?
> > 
> > The pointer returned from the allocation is never checked, so it could
> > theoretically be NULL and be used regardless.
> > 
> > Also I'm not sure that AND'ing with 0xff is the right thing to do here.
> 
> Oops, there's a check for NULL missing. If that allocation fails, probe
> should fail, so we just need to propagate the error condition. Otherwise
> we might just leave the firewall off, and let everything go in unchecked.

Yes, definitely.

> AND 0xff is necessary, because the same registers are mirrored in
> multiple contexts. AND removes the offset coming from context, and
> leaves just the plain register offset.

That looks like something which should go into a comment.

> > I'm not so sure. Caching should alleviate the issue with the increased
> > amount of data. Then there's the fact that previously we needed to
> > divide and compute the remainder of the division for the BIT_MASK and
> > BIT_WORD operations.
> 
> Don't these get compiled into shifts and bitwise ands?

Yes, they are.

> > One other added benefit of this approach is that the address registers
> > are stored in a const array and therefore could reside in a read-only
> > memory region. With the previous approach, once somebody had access to
> > the bitmap, it could easily be overwritten with zeros and effectively
> > make the firewall useless. I'm not sure how likely that would be, but it
> > could be done.
> 
> If somebody gets access to the bitmap, he has access to kernel data
> structures. GR2D firewall is the least of our worries in this case.

I see the point. Oh well, all my arguments are torn down. I'll drop this
patch. Or at least the part that rewrites the gr2d_is_addr() and make it
check for failed allocations properly.

For what it's worth, I still think the plain table lookup is much easier
to understand.

Thierry


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

Re: [RFCv1 11/12] drm: Atomic modeset ioctl

2013-10-07 Thread Ville Syrjälä 
On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
> From: Ville Syrjälä 
> 
> The atomic modeset ioctl cna be used to push any number of new values
> for object properties. The driver can then check the full device
> configuration as single unit, and try to apply the changes atomically.
> 
> The ioctl simply takes a list of object IDs and property IDs and their
> values. For setting values to blob properties, the property value
> indicates the length of the data, and the actual data is passed via
> another blob pointer.
> 
> The caller can demand non-blocking operation from the ioctl, and if the
> driver can't satisfy that requirement an error will be returned.
> 
> The caller can also request to receive asynchronous completion events
> after the operation has reached the hardware. An event is sent for each
> object specified by the caller, whether or not the actual state of
> that object changed. Each event also carries a framebuffer ID, which
> indicates to user space that the specified object is no longer
> accessing that framebuffer.
> 
> TODO: detailed error reporting?
> 
> v1: original
> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_crtc.c  | 159 
> 
>  drivers/gpu/drm/drm_drv.c   |   1 +
>  include/drm/drmP.h  |   6 ++
>  include/drm/drm_crtc.h  |   2 +
>  include/uapi/drm/drm.h  |  12 
>  include/uapi/drm/drm_mode.h |  16 +
>  6 files changed, 196 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 09396a9..910e5c6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4338,3 +4338,162 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   idr_destroy(&dev->mode_config.crtc_idr);
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
> +
> +int drm_mode_atomic_ioctl(struct drm_device *dev,
> +   void *data, struct drm_file *file_priv)
> +{
> + struct drm_mode_atomic *arg = data;
> + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
> long)(arg->objs_ptr);
> + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
> long)(arg->count_props_ptr);
> + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
> long)(arg->props_ptr);
> + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
> long)(arg->prop_values_ptr);
> + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
> long)(arg->blob_values_ptr);
> + unsigned int copied_objs = 0;
> + unsigned int copied_props = 0;
> + unsigned int copied_blobs = 0;
> + void *state;
> + int ret = 0;
> + unsigned int i, j;
> +
> + if (arg->flags & ~(DRM_MODE_ATOMIC_TEST_ONLY |
> + DRM_MODE_ATOMIC_EVENT | DRM_MODE_ATOMIC_NONBLOCK))
> + return -EINVAL;
> +
> + /* can't test and expect an event at the same time. */
> + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
> + (arg->flags & DRM_MODE_ATOMIC_EVENT))
> + return -EINVAL;
> +
> + mutex_lock(&dev->mode_config.mutex);

I'm pretty sure I had a version w/ fixed locking...

git://gitorious.org/vsyrjala/linux.git rebased_drm_atomic_24

> +
> + state = dev->driver->atomic_begin(dev, arg->flags);
> + if (IS_ERR(state)) {
> + ret = PTR_ERR(state);
> + goto unlock;
> + }
> +
> + for (i = 0; i < arg->count_objs; i++) {
> + uint32_t obj_id, count_props;
> + struct drm_mode_object *obj;
> +
> + if (get_user(obj_id, objs_ptr + copied_objs)) {
> + ret = -EFAULT;
> + goto out;
> + }
> +
> + obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
> + if (!obj || !obj->properties) {
> + ret = -ENOENT;
> + goto out;
> + }
> +
> + if (arg->flags & DRM_MODE_ATOMIC_EVENT) {
> + // XXX create atomic event instead..

Some people are apparently more comfortable with a per-crtc event
rather than the per-obj events I added. So I think we might want
both in the end.

> + struct drm_pending_vblank_event *e =
> + create_vblank_event(dev, file_priv, 
> arg->user_data);
> + if (!e) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + ret = dev->driver->atomic_set_event(dev, state, obj, e);
> + if (ret) {
> + destroy_vblank_event(dev, file_priv, e);
> + goto out;
> + }
> + }
> +
> + if (get_user(count_props, count_props_ptr + copied_objs)) {
> +

Re: [RFCv1 10/12] drm: convert crtc to properties/state

2013-10-07 Thread Ville Syrjälä 
On Sat, Oct 05, 2013 at 08:45:48PM -0400, Rob Clark wrote:
> Break the mutable state of a crtc out into a separate structure
> and use atomic properties mechanism to set crtc attributes.  This
> makes it easier to have some helpers for crtc->set_property()
> and for checking for invalid params.  The idea is that individual
> drivers can wrap the state struct in their own struct which adds
> driver specific parameters, for easy build-up of state across
> multiple set_property() calls and for easy atomic commit or roll-
> back.

I'm not sure how we're going to handle the mismatch in the behaviour of
the atomic modeset vs. the current setcrtc.

The problem is that setcrtc ignore all kinds of conflicting
crtc->connector assignments, and just overwrites whatever was there
with the latest configuration. For the atomic case we want to return an
error if there's a conflict. And another thing is the DPMS handling. The
current API forces DPMS on when you do a modeset, but for the atomic
case I want to keep things nice and clean and avoid doing such silly
things.

So I don't think we can simply convert the current modeset codepaths to
call into the atomic code. We basically need another version of the
check function, or another step that happens before .check only in the
setcrtc case which eliminates the conflicts in a way that matches the
current setcrtc behaviour.

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

[Bug 54867] bug in r300 compiler

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=54867

--- Comment #4 from Tom Stellard  ---
(In reply to comment #3)
> So, still not pushed in today git, can someone push this small fix?

I can push it if you provide an updated patch with a proper commit message.

-- 
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: [RFCv1 02/12] drm: add object property type

2013-10-07 Thread Ville Syrjälä 
On Sat, Oct 05, 2013 at 08:45:40PM -0400, Rob Clark wrote:
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5508117..35921ba 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -231,6 +231,7 @@ struct drm_mode_get_connector {
>  #define DRM_MODE_PROP_ENUM   (1<<3) /* enumerated type with text strings */
>  #define DRM_MODE_PROP_BLOB   (1<<4)
>  #define DRM_MODE_PROP_BITMASK(1<<5) /* bitmask of enumerated types */
> +#define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */

This way to using up one bit for each type sucks big time. IIRC we
discussed this at Fosdem and one idea was to leave the current bits as
sort of base types, and reserve a bunch of the other bits to indicate a
sub-type. For instance the new signed range and object ID prop types
could be sub-types of the current range type.

Maybe we should reserve a few more bits for new base types in case we
need them in the future, or just add sometime king DRM_MODE_PROP_MISC,
which is where we'd stick every sub-type that doesn't fit the current
base types.

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

Re: [RFCv1 03/12] drm: add DRM_MODE_PROP_DYNAMIC property flag

2013-10-07 Thread Ville Syrjälä 
On Sat, Oct 05, 2013 at 08:45:41PM -0400, Rob Clark wrote:
> This indicates to userspace that the property is something that can
> be set dynamically without requiring a "test" step to check if the
> hw is capable.  This allows a userspace compositor, such as weston,
> to avoid an extra ioctl to check whether it needs to fall-back to
> GPU to composite some surface prior to submission of GPU render
> commands.
> ---
>  include/uapi/drm/drm_mode.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 35921ba..15db837 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -232,6 +232,15 @@ struct drm_mode_get_connector {
>  #define DRM_MODE_PROP_BLOB   (1<<4)
>  #define DRM_MODE_PROP_BITMASK(1<<5) /* bitmask of enumerated types */
>  #define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */
> +/* Properties that are not dynamic cannot safely be changed without a
> + * atomic-modeset / atomic-pageflip test step.  But if userspace is
> + * only changing dynamic properties, it is guaranteed that the change
> + * will not exceed hw limits, so no test step is required.
> + *
> + * Note that fb_id properties are a bit ambiguous.. they of course can
> + * be changed dynamically, assuming the pixel format does not change.
> + */
> +#define DRM_MODE_PROP_DYNAMIC(1<<24)

I'm still not convinced that this is useful. We can't even flag the FB
ID with this flag since the FB encompasses stride/bpp/etc. parameters
that for sure can't just be changed w/o first checking the new
configuration.

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

Re: [RFCv1 08/12] drm: Refactor object property check code

2013-10-07 Thread Ville Syrjälä 
On Sat, Oct 05, 2013 at 08:45:46PM -0400, Rob Clark wrote:
> From: Ville Syrjälä 
> 
> Refactor the code to check whether an object has a specific property
> to a new function.
> 
> v1: original
> v2: rebase on atomic -- Rob Clark
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_crtc.c | 25 ++---
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index c0546e8..776edf3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3374,6 +3374,19 @@ static int drm_mode_set_obj_prop(struct 
> drm_mode_object *obj,
>   return -EINVAL;
>  }
>  
> +static bool object_has_prop(const struct drm_mode_object *obj, u32 prop_id)
> +{
> + int i;
> +
> + if (!obj->properties)
> + return false;
> +
> + for (i = 0; i < obj->properties->count; i++)
> + if (obj->properties->ids[i] == prop_id)
> + return true;
> + return false;
> +}
> +
>  /* call with mode_config mutex held */
>  static int drm_mode_set_obj_prop_id(struct drm_device *dev, void *state,
>   uint32_t obj_id, uint32_t obj_type,
> @@ -3382,19 +3395,9 @@ static int drm_mode_set_obj_prop_id(struct drm_device 
> *dev, void *state,
>   struct drm_mode_object *arg_obj;
>   struct drm_mode_object *prop_obj;
>   struct drm_property *property;
> - int i;
>  
>   arg_obj = drm_mode_object_find(dev, obj_id, obj_type);
> - if (!arg_obj)
> - return -EINVAL;
> - if (!arg_obj->properties)
> - return -EINVAL;
> -
> - for (i = 0; i < arg_obj->properties->count; i++)
> - if (arg_obj->properties->ids[i] == prop_id)
> - break;
> -
> - if (i == arg_obj->properties->count)
> + if (!(arg_obj && object_has_prop(arg_obj, prop_id)))
>   return -EINVAL;

-ENOENT would actually seem more appropriate here.

>  
>   prop_obj = drm_mode_object_find(dev, prop_id,
> -- 
> 1.8.3.1

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

Re: [RFCv1 11/12] drm: Atomic modeset ioctl

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
 wrote:
> On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
>> From: Ville Syrjälä 
>>
>> The atomic modeset ioctl cna be used to push any number of new values
>> for object properties. The driver can then check the full device
>> configuration as single unit, and try to apply the changes atomically.
>>
>> The ioctl simply takes a list of object IDs and property IDs and their
>> values. For setting values to blob properties, the property value
>> indicates the length of the data, and the actual data is passed via
>> another blob pointer.
>>
>> The caller can demand non-blocking operation from the ioctl, and if the
>> driver can't satisfy that requirement an error will be returned.
>>
>> The caller can also request to receive asynchronous completion events
>> after the operation has reached the hardware. An event is sent for each
>> object specified by the caller, whether or not the actual state of
>> that object changed. Each event also carries a framebuffer ID, which
>> indicates to user space that the specified object is no longer
>> accessing that framebuffer.
>>
>> TODO: detailed error reporting?
>>
>> v1: original
>> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
>> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
>>
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/drm_crtc.c  | 159 
>> 
>>  drivers/gpu/drm/drm_drv.c   |   1 +
>>  include/drm/drmP.h  |   6 ++
>>  include/drm/drm_crtc.h  |   2 +
>>  include/uapi/drm/drm.h  |  12 
>>  include/uapi/drm/drm_mode.h |  16 +
>>  6 files changed, 196 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 09396a9..910e5c6 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -4338,3 +4338,162 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>>   idr_destroy(&dev->mode_config.crtc_idr);
>>  }
>>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>> +
>> +int drm_mode_atomic_ioctl(struct drm_device *dev,
>> +   void *data, struct drm_file *file_priv)
>> +{
>> + struct drm_mode_atomic *arg = data;
>> + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
>> long)(arg->objs_ptr);
>> + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
>> long)(arg->count_props_ptr);
>> + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
>> long)(arg->props_ptr);
>> + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
>> long)(arg->prop_values_ptr);
>> + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
>> long)(arg->blob_values_ptr);
>> + unsigned int copied_objs = 0;
>> + unsigned int copied_props = 0;
>> + unsigned int copied_blobs = 0;
>> + void *state;
>> + int ret = 0;
>> + unsigned int i, j;
>> +
>> + if (arg->flags & ~(DRM_MODE_ATOMIC_TEST_ONLY |
>> + DRM_MODE_ATOMIC_EVENT | DRM_MODE_ATOMIC_NONBLOCK))
>> + return -EINVAL;
>> +
>> + /* can't test and expect an event at the same time. */
>> + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
>> + (arg->flags & DRM_MODE_ATOMIC_EVENT))
>> + return -EINVAL;
>> +
>> + mutex_lock(&dev->mode_config.mutex);
>
> I'm pretty sure I had a version w/ fixed locking...
>
> git://gitorious.org/vsyrjala/linux.git rebased_drm_atomic_24

oh, hmm.. actually the locking should no longer be in the ioctl fxn,
but should be pushed down to the commit.  looks like I missed this.  I
need to dig up some actual test code for atomic ioctl ;-)

>> +
>> + state = dev->driver->atomic_begin(dev, arg->flags);
>> + if (IS_ERR(state)) {
>> + ret = PTR_ERR(state);
>> + goto unlock;
>> + }
>> +
>> + for (i = 0; i < arg->count_objs; i++) {
>> + uint32_t obj_id, count_props;
>> + struct drm_mode_object *obj;
>> +
>> + if (get_user(obj_id, objs_ptr + copied_objs)) {
>> + ret = -EFAULT;
>> + goto out;
>> + }
>> +
>> + obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
>> + if (!obj || !obj->properties) {
>> + ret = -ENOENT;
>> + goto out;
>> + }
>> +
>> + if (arg->flags & DRM_MODE_ATOMIC_EVENT) {
>> + // XXX create atomic event instead..
>
> Some people are apparently more comfortable with a per-crtc event
> rather than the per-obj events I added. So I think we might want
> both in the end.

yeah, sorting out events is a bit 'TODO' at the moment.  I do kind of
like per-crtc event.. it seems easier to implement and I'm not really
sure what finer event granularity buys us.

BR,
-R

>> + struct drm_pending_vblank_event *e =
>> + create_vblank_ev

Re: [RFCv1 10/12] drm: convert crtc to properties/state

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 9:39 AM, Ville Syrjälä
 wrote:
> On Sat, Oct 05, 2013 at 08:45:48PM -0400, Rob Clark wrote:
>> Break the mutable state of a crtc out into a separate structure
>> and use atomic properties mechanism to set crtc attributes.  This
>> makes it easier to have some helpers for crtc->set_property()
>> and for checking for invalid params.  The idea is that individual
>> drivers can wrap the state struct in their own struct which adds
>> driver specific parameters, for easy build-up of state across
>> multiple set_property() calls and for easy atomic commit or roll-
>> back.
>
> I'm not sure how we're going to handle the mismatch in the behaviour of
> the atomic modeset vs. the current setcrtc.
>
> The problem is that setcrtc ignore all kinds of conflicting
> crtc->connector assignments, and just overwrites whatever was there
> with the latest configuration. For the atomic case we want to return an
> error if there's a conflict.

Hmm, well currently we preserve the setcrtc behavior because it ends
up going through crtc helpers (or whatever the driver uses).  So
should be fine for setcrtc, but probably not what we want for atomic
ioctl.

I suppose we could solve some of this via internal flags, ie
.atomic_begin(dev, LEGACY_SETCRTC_CHECK_MODE)

it is a bit ugly, but it keeps the ugly in core and drivers don't have
to care as much about it (which is my main concern)

> And another thing is the DPMS handling. The
> current API forces DPMS on when you do a modeset, but for the atomic
> case I want to keep things nice and clean and avoid doing such silly
> things.

I guess the easy thing is to set DPMS property in setcrtc too ;-)

BR,
-R

> So I don't think we can simply convert the current modeset codepaths to
> call into the atomic code. We basically need another version of the
> check function, or another step that happens before .check only in the
> setcrtc case which eliminates the conflicts in a way that matches the
> current setcrtc behaviour.
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv1 11/12] drm: Atomic modeset ioctl

2013-10-07 Thread Ville Syrjälä 
On Mon, Oct 07, 2013 at 09:55:47AM -0400, Rob Clark wrote:
> On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
>  wrote:
> > On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
> >> From: Ville Syrjälä 
> >>
> >> The atomic modeset ioctl cna be used to push any number of new values
> >> for object properties. The driver can then check the full device
> >> configuration as single unit, and try to apply the changes atomically.
> >>
> >> The ioctl simply takes a list of object IDs and property IDs and their
> >> values. For setting values to blob properties, the property value
> >> indicates the length of the data, and the actual data is passed via
> >> another blob pointer.
> >>
> >> The caller can demand non-blocking operation from the ioctl, and if the
> >> driver can't satisfy that requirement an error will be returned.
> >>
> >> The caller can also request to receive asynchronous completion events
> >> after the operation has reached the hardware. An event is sent for each
> >> object specified by the caller, whether or not the actual state of
> >> that object changed. Each event also carries a framebuffer ID, which
> >> indicates to user space that the specified object is no longer
> >> accessing that framebuffer.
> >>
> >> TODO: detailed error reporting?
> >>
> >> v1: original
> >> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
> >> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
> >>
> >> Signed-off-by: Ville Syrjälä 
> >> ---
> >>  drivers/gpu/drm/drm_crtc.c  | 159 
> >> 
> >>  drivers/gpu/drm/drm_drv.c   |   1 +
> >>  include/drm/drmP.h  |   6 ++
> >>  include/drm/drm_crtc.h  |   2 +
> >>  include/uapi/drm/drm.h  |  12 
> >>  include/uapi/drm/drm_mode.h |  16 +
> >>  6 files changed, 196 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index 09396a9..910e5c6 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -4338,3 +4338,162 @@ void drm_mode_config_cleanup(struct drm_device 
> >> *dev)
> >>   idr_destroy(&dev->mode_config.crtc_idr);
> >>  }
> >>  EXPORT_SYMBOL(drm_mode_config_cleanup);
> >> +
> >> +int drm_mode_atomic_ioctl(struct drm_device *dev,
> >> +   void *data, struct drm_file *file_priv)
> >> +{
> >> + struct drm_mode_atomic *arg = data;
> >> + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
> >> long)(arg->objs_ptr);
> >> + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
> >> long)(arg->count_props_ptr);
> >> + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
> >> long)(arg->props_ptr);
> >> + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
> >> long)(arg->prop_values_ptr);
> >> + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
> >> long)(arg->blob_values_ptr);
> >> + unsigned int copied_objs = 0;
> >> + unsigned int copied_props = 0;
> >> + unsigned int copied_blobs = 0;
> >> + void *state;
> >> + int ret = 0;
> >> + unsigned int i, j;
> >> +
> >> + if (arg->flags & ~(DRM_MODE_ATOMIC_TEST_ONLY |
> >> + DRM_MODE_ATOMIC_EVENT | DRM_MODE_ATOMIC_NONBLOCK))
> >> + return -EINVAL;
> >> +
> >> + /* can't test and expect an event at the same time. */
> >> + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
> >> + (arg->flags & DRM_MODE_ATOMIC_EVENT))
> >> + return -EINVAL;
> >> +
> >> + mutex_lock(&dev->mode_config.mutex);
> >
> > I'm pretty sure I had a version w/ fixed locking...
> >
> > git://gitorious.org/vsyrjala/linux.git rebased_drm_atomic_24
> 
> oh, hmm.. actually the locking should no longer be in the ioctl fxn,
> but should be pushed down to the commit.  looks like I missed this.  I
> need to dig up some actual test code for atomic ioctl ;-)

It can't be in commit. At the very least it has to be around
check+commit, and also you need to hold some locks when you're copying
the current config over to your temp storage. That's assuming you store
_everything_ in the temp storage and so it doesn't matter if the current
state can change between the copy and check+commit.

> 
> >> +
> >> + state = dev->driver->atomic_begin(dev, arg->flags);
> >> + if (IS_ERR(state)) {
> >> + ret = PTR_ERR(state);
> >> + goto unlock;
> >> + }
> >> +
> >> + for (i = 0; i < arg->count_objs; i++) {
> >> + uint32_t obj_id, count_props;
> >> + struct drm_mode_object *obj;
> >> +
> >> + if (get_user(obj_id, objs_ptr + copied_objs)) {
> >> + ret = -EFAULT;
> >> + goto out;
> >> + }
> >> +
> >> + obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
> >> + if (!obj || !obj->properties) {
> >> + ret = -ENOENT;
> >> +

[Bug 70227] New: OpenCL reaper-prime app crashes due to atomic_or unimplemented

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70227

  Priority: medium
Bug ID: 70227
  Assignee: dri-devel@lists.freedesktop.org
   Summary: OpenCL reaper-prime app crashes due to atomic_or
unimplemented
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: ale...@gentoo.org
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Miner app https://github.com/arnuschky/primecoin-reaper.git crashes with 

./reaper 
\|/
-  Reaper v13 64-bit  -
-PRIME BETA 2 -
-   coded by mtrlt-
/|\


Warning: unknown property "use_gpu" in configuration file.
I'm now mining primecoin!
Share thread started
GeneratePrimeTable() : setting nSievePercentage = 1, nSieveSize = 10
GeneratePrimeTable() : prime table [1, 10] generated with 9592 primes
Available CPU mining algorithms: hp7
Using default: hp7
Creating 1 CPU thread.
1...Warning: can't set thread priority
done
List of platforms:
0   Default
Using platform number 0

Using device 0
OpenCL device 0
Compiling kernel... this could take up to 2 minutes.
2 warnings generated.
Building kernel CalculateMultipliers
Building kernel Sieve
Building kernel Combine
Building kernel Fermat
done
Compiling kernel... this could take up to 2 minutes.
2 warnings generated.
Building kernel CalculateMultipliers
Building kernel Sieve
Building kernel Combine
Building kernel Fermat
0x7f735cdadd00: i32 = GlobalAddress 0 [ORD=104]
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'radeon'.
1.  Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on
function '@Sieve'
Segmentation fault

-- 
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: [RFCv1 10/12] drm: convert crtc to properties/state

2013-10-07 Thread Ville Syrjälä 
On Mon, Oct 07, 2013 at 10:03:01AM -0400, Rob Clark wrote:
> On Mon, Oct 7, 2013 at 9:39 AM, Ville Syrjälä
>  wrote:
> > On Sat, Oct 05, 2013 at 08:45:48PM -0400, Rob Clark wrote:
> >> Break the mutable state of a crtc out into a separate structure
> >> and use atomic properties mechanism to set crtc attributes.  This
> >> makes it easier to have some helpers for crtc->set_property()
> >> and for checking for invalid params.  The idea is that individual
> >> drivers can wrap the state struct in their own struct which adds
> >> driver specific parameters, for easy build-up of state across
> >> multiple set_property() calls and for easy atomic commit or roll-
> >> back.
> >
> > I'm not sure how we're going to handle the mismatch in the behaviour of
> > the atomic modeset vs. the current setcrtc.
> >
> > The problem is that setcrtc ignore all kinds of conflicting
> > crtc->connector assignments, and just overwrites whatever was there
> > with the latest configuration. For the atomic case we want to return an
> > error if there's a conflict.
> 
> Hmm, well currently we preserve the setcrtc behavior because it ends
> up going through crtc helpers (or whatever the driver uses).  So
> should be fine for setcrtc, but probably not what we want for atomic
> ioctl.
> 
> I suppose we could solve some of this via internal flags, ie
> .atomic_begin(dev, LEGACY_SETCRTC_CHECK_MODE)
> 
> it is a bit ugly, but it keeps the ugly in core and drivers don't have
> to care as much about it (which is my main concern)

Well, it could be an entirely separate .legacy_crap() hook or something
that happens just before .check().

> 
> > And another thing is the DPMS handling. The
> > current API forces DPMS on when you do a modeset, but for the atomic
> > case I want to keep things nice and clean and avoid doing such silly
> > things.
> 
> I guess the easy thing is to set DPMS property in setcrtc too ;-)

That's what we do, but I don't want it for atomic.

> 
> BR,
> -R
> 
> > So I don't think we can simply convert the current modeset codepaths to
> > call into the atomic code. We basically need another version of the
> > check function, or another step that happens before .check only in the
> > setcrtc case which eliminates the conflicts in a way that matches the
> > current setcrtc behaviour.
> >
> > --
> > Ville Syrjälä
> > Intel OTC

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

Re: [RFCv1 10/12] drm: convert crtc to properties/state

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 10:19 AM, Ville Syrjälä
 wrote:
> On Mon, Oct 07, 2013 at 10:03:01AM -0400, Rob Clark wrote:
>> On Mon, Oct 7, 2013 at 9:39 AM, Ville Syrjälä
>>  wrote:
>> > On Sat, Oct 05, 2013 at 08:45:48PM -0400, Rob Clark wrote:
>> >> Break the mutable state of a crtc out into a separate structure
>> >> and use atomic properties mechanism to set crtc attributes.  This
>> >> makes it easier to have some helpers for crtc->set_property()
>> >> and for checking for invalid params.  The idea is that individual
>> >> drivers can wrap the state struct in their own struct which adds
>> >> driver specific parameters, for easy build-up of state across
>> >> multiple set_property() calls and for easy atomic commit or roll-
>> >> back.
>> >
>> > I'm not sure how we're going to handle the mismatch in the behaviour of
>> > the atomic modeset vs. the current setcrtc.
>> >
>> > The problem is that setcrtc ignore all kinds of conflicting
>> > crtc->connector assignments, and just overwrites whatever was there
>> > with the latest configuration. For the atomic case we want to return an
>> > error if there's a conflict.
>>
>> Hmm, well currently we preserve the setcrtc behavior because it ends
>> up going through crtc helpers (or whatever the driver uses).  So
>> should be fine for setcrtc, but probably not what we want for atomic
>> ioctl.
>>
>> I suppose we could solve some of this via internal flags, ie
>> .atomic_begin(dev, LEGACY_SETCRTC_CHECK_MODE)
>>
>> it is a bit ugly, but it keeps the ugly in core and drivers don't have
>> to care as much about it (which is my main concern)
>
> Well, it could be an entirely separate .legacy_crap() hook or something
> that happens just before .check().

yeah, that could work too.. I'll think about it a bit and see what I
can come up with

>>
>> > And another thing is the DPMS handling. The
>> > current API forces DPMS on when you do a modeset, but for the atomic
>> > case I want to keep things nice and clean and avoid doing such silly
>> > things.
>>
>> I guess the easy thing is to set DPMS property in setcrtc too ;-)
>
> That's what we do, but I don't want it for atomic.

yeah, I need think about how that could work if we are still using
.set_config() from the commit, but I guess I should be able to sort
out something..

BR,
-R

>>
>> BR,
>> -R
>>
>> > So I don't think we can simply convert the current modeset codepaths to
>> > call into the atomic code. We basically need another version of the
>> > check function, or another step that happens before .check only in the
>> > setcrtc case which eliminates the conflicts in a way that matches the
>> > current setcrtc behaviour.
>> >
>> > --
>> > Ville Syrjälä
>> > Intel OTC
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv1 11/12] drm: Atomic modeset ioctl

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 10:18 AM, Ville Syrjälä
 wrote:
> On Mon, Oct 07, 2013 at 09:55:47AM -0400, Rob Clark wrote:
>> On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
>>  wrote:
>> > On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
>> >> From: Ville Syrjälä 
>> >>
>> >> The atomic modeset ioctl cna be used to push any number of new values
>> >> for object properties. The driver can then check the full device
>> >> configuration as single unit, and try to apply the changes atomically.
>> >>
>> >> The ioctl simply takes a list of object IDs and property IDs and their
>> >> values. For setting values to blob properties, the property value
>> >> indicates the length of the data, and the actual data is passed via
>> >> another blob pointer.
>> >>
>> >> The caller can demand non-blocking operation from the ioctl, and if the
>> >> driver can't satisfy that requirement an error will be returned.
>> >>
>> >> The caller can also request to receive asynchronous completion events
>> >> after the operation has reached the hardware. An event is sent for each
>> >> object specified by the caller, whether or not the actual state of
>> >> that object changed. Each event also carries a framebuffer ID, which
>> >> indicates to user space that the specified object is no longer
>> >> accessing that framebuffer.
>> >>
>> >> TODO: detailed error reporting?
>> >>
>> >> v1: original
>> >> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
>> >> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
>> >>
>> >> Signed-off-by: Ville Syrjälä 
>> >> ---
>> >>  drivers/gpu/drm/drm_crtc.c  | 159 
>> >> 
>> >>  drivers/gpu/drm/drm_drv.c   |   1 +
>> >>  include/drm/drmP.h  |   6 ++
>> >>  include/drm/drm_crtc.h  |   2 +
>> >>  include/uapi/drm/drm.h  |  12 
>> >>  include/uapi/drm/drm_mode.h |  16 +
>> >>  6 files changed, 196 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> index 09396a9..910e5c6 100644
>> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> @@ -4338,3 +4338,162 @@ void drm_mode_config_cleanup(struct drm_device 
>> >> *dev)
>> >>   idr_destroy(&dev->mode_config.crtc_idr);
>> >>  }
>> >>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>> >> +
>> >> +int drm_mode_atomic_ioctl(struct drm_device *dev,
>> >> +   void *data, struct drm_file *file_priv)
>> >> +{
>> >> + struct drm_mode_atomic *arg = data;
>> >> + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
>> >> long)(arg->objs_ptr);
>> >> + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
>> >> long)(arg->count_props_ptr);
>> >> + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
>> >> long)(arg->props_ptr);
>> >> + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
>> >> long)(arg->prop_values_ptr);
>> >> + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
>> >> long)(arg->blob_values_ptr);
>> >> + unsigned int copied_objs = 0;
>> >> + unsigned int copied_props = 0;
>> >> + unsigned int copied_blobs = 0;
>> >> + void *state;
>> >> + int ret = 0;
>> >> + unsigned int i, j;
>> >> +
>> >> + if (arg->flags & ~(DRM_MODE_ATOMIC_TEST_ONLY |
>> >> + DRM_MODE_ATOMIC_EVENT | DRM_MODE_ATOMIC_NONBLOCK))
>> >> + return -EINVAL;
>> >> +
>> >> + /* can't test and expect an event at the same time. */
>> >> + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
>> >> + (arg->flags & DRM_MODE_ATOMIC_EVENT))
>> >> + return -EINVAL;
>> >> +
>> >> + mutex_lock(&dev->mode_config.mutex);
>> >
>> > I'm pretty sure I had a version w/ fixed locking...
>> >
>> > git://gitorious.org/vsyrjala/linux.git rebased_drm_atomic_24
>>
>> oh, hmm.. actually the locking should no longer be in the ioctl fxn,
>> but should be pushed down to the commit.  looks like I missed this.  I
>> need to dig up some actual test code for atomic ioctl ;-)
>
> It can't be in commit. At the very least it has to be around
> check+commit, and also you need to hold some locks when you're copying
> the current config over to your temp storage. That's assuming you store
> _everything_ in the temp storage and so it doesn't matter if the current
> state can change between the copy and check+commit.
>

hmm.. I start to wish we did atomic first, before the fine grained
locking re-work ;-)

>>
>> >> +
>> >> + state = dev->driver->atomic_begin(dev, arg->flags);
>> >> + if (IS_ERR(state)) {
>> >> + ret = PTR_ERR(state);
>> >> + goto unlock;
>> >> + }
>> >> +
>> >> + for (i = 0; i < arg->count_objs; i++) {
>> >> + uint32_t obj_id, count_props;
>> >> + struct drm_mode_object *obj;
>> >> +
>> >> + if (get_user(obj_id, objs_ptr + copied_objs)) {
>> >> + ret = -EFAULT;
>> >>

Re: [RFCv1 02/12] drm: add object property type

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 9:43 AM, Ville Syrjälä
 wrote:
> On Sat, Oct 05, 2013 at 08:45:40PM -0400, Rob Clark wrote:
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 5508117..35921ba 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -231,6 +231,7 @@ struct drm_mode_get_connector {
>>  #define DRM_MODE_PROP_ENUM   (1<<3) /* enumerated type with text strings */
>>  #define DRM_MODE_PROP_BLOB   (1<<4)
>>  #define DRM_MODE_PROP_BITMASK(1<<5) /* bitmask of enumerated types 
>> */
>> +#define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */
>
> This way to using up one bit for each type sucks big time. IIRC we
> discussed this at Fosdem and one idea was to leave the current bits as
> sort of base types, and reserve a bunch of the other bits to indicate a
> sub-type. For instance the new signed range and object ID prop types
> could be sub-types of the current range type.

oh, right..  current object-prop is just a straight rebase of the
original patch, so I didn't change this yet.

We probably don't want to use sub-type in cases where old userspace
could misinterpret things, so not sure about signed-range to be a
sub-type of range (if that is what you meant)... but maybe a good idea
for PROP_MISC + PROP_SUBTYPE_OBJECT.  Otoh, at the moment, the only
other prop type I have in mind is ARRAY (although not sure if we can
do single PROP_ARRAY or if we end up needing PROP_ARRAY_foo, for
everything we might want an array of..)

BR,
-R

> Maybe we should reserve a few more bits for new base types in case we
> need them in the future, or just add sometime king DRM_MODE_PROP_MISC,
> which is where we'd stick every sub-type that doesn't fit the current
> base types.
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFCv1 03/12] drm: add DRM_MODE_PROP_DYNAMIC property flag

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 9:46 AM, Ville Syrjälä
 wrote:
> On Sat, Oct 05, 2013 at 08:45:41PM -0400, Rob Clark wrote:
>> This indicates to userspace that the property is something that can
>> be set dynamically without requiring a "test" step to check if the
>> hw is capable.  This allows a userspace compositor, such as weston,
>> to avoid an extra ioctl to check whether it needs to fall-back to
>> GPU to composite some surface prior to submission of GPU render
>> commands.
>> ---
>>  include/uapi/drm/drm_mode.h | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 35921ba..15db837 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -232,6 +232,15 @@ struct drm_mode_get_connector {
>>  #define DRM_MODE_PROP_BLOB   (1<<4)
>>  #define DRM_MODE_PROP_BITMASK(1<<5) /* bitmask of enumerated types 
>> */
>>  #define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */
>> +/* Properties that are not dynamic cannot safely be changed without a
>> + * atomic-modeset / atomic-pageflip test step.  But if userspace is
>> + * only changing dynamic properties, it is guaranteed that the change
>> + * will not exceed hw limits, so no test step is required.
>> + *
>> + * Note that fb_id properties are a bit ambiguous.. they of course can
>> + * be changed dynamically, assuming the pixel format does not change.
>> + */
>> +#define DRM_MODE_PROP_DYNAMIC(1<<24)
>
> I'm still not convinced that this is useful. We can't even flag the FB
> ID with this flag since the FB encompasses stride/bpp/etc. parameters
> that for sure can't just be changed w/o first checking the new
> configuration.

well, I know of at least some hw that can change plane src/crtc coords
without requiring a check step.  So I think it is useful as an
optimization.  But it is also something that could be easily/safely
added later so maybe I should drop it from the initial atomic
patchset.

BR,
-R

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

RE: [RFCv1 04/12] drm: add DRM_MODE_PROP_SIGNED property flag

2013-10-07 Thread Matt Plumtree 
> static bool drm_property_change_is_valid(struct drm_property *property,
>uint64_t value)
>  {
> - if (property->flags & DRM_MODE_PROP_IMMUTABLE)
> + if (property->flags & DRM_MODE_PROP_IMMUTABLE) {
>   return false;
> - if (property->flags & DRM_MODE_PROP_RANGE) {
> + } else if (property->flags & 
> (DRM_MODE_PROP_RANGE|DRM_MODE_PROP_SIGNED)) {
> + int64_t svalue = U642I64(value);
> + if (svalue < U642I64(property->values[0]) ||
> + svalue > U642I64(property->values[1]))
> + return false;
> + return true;
> + } else if (property->flags & DRM_MODE_PROP_RANGE) {
>   if (value < property->values[0] || value > property->values[1])
>   return false;
>   return true;

I don't think this is doing what you think it should. If the flags include
DRM_MODE_PROP_RANGE, the first "else if" will be executed regardless of
whether DRM_MODE_PROP_SIGNED is set or not. This means that the second
"else if" will never be executed.

You'd need to add "== (DRM_MODE_PROP_RANGE|DRM_MODE_PROP_SIGNED)" or
similar.

Matt

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

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 7:09 AM, Russell King - ARM Linux
 wrote:
> On Mon, Oct 07, 2013 at 12:48:20PM +0200, Jean-Francois Moine wrote:
>> On Mon, 7 Oct 2013 10:44:04 +0100
>> Russell King - ARM Linux  wrote:
>>
>> > On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
>>   [snip]
>> > > It seems we are going backwards: as the Armada based boards will soon
>> > > move to full DT (mvebu), you are making an exception for the Cubox, so
>> > > that there should be Cubox specific kernels. I don't like that...
>> >
>> > *Ignored*.  You know why.
>>
>> Sorry. I don't see why. May you explain again?
>
> I don't run DT because DT lacks most of the features I require on the
> cubox.  Therefore I can't develop for DT.  Simple.

Jean-François, just as an aside, I really don't think code that can be
shared, like tda998x, should encode a DT requirement.. there are
plenty of platforms that don't use DT (arm isn't everything, and last
I heard aarch64 was going to be ACPI).

Beyond that, it is a driver decision whether or not to support only-DT
or DT + other.. and as long as there is a common board which can use
the driver but which is not DT, there is probably a compelling reason
to still support the non-DT case.

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

Re: [RFCv1 11/12] drm: Atomic modeset ioctl

2013-10-07 Thread Ville Syrjälä 
On Mon, Oct 07, 2013 at 10:39:01AM -0400, Rob Clark wrote:
> On Mon, Oct 7, 2013 at 10:18 AM, Ville Syrjälä
>  wrote:
> > On Mon, Oct 07, 2013 at 09:55:47AM -0400, Rob Clark wrote:
> >> On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
> >>  wrote:
> >> > On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
> >> >> From: Ville Syrjälä 
> >> >>
> >> >> The atomic modeset ioctl cna be used to push any number of new values
> >> >> for object properties. The driver can then check the full device
> >> >> configuration as single unit, and try to apply the changes atomically.
> >> >>
> >> >> The ioctl simply takes a list of object IDs and property IDs and their
> >> >> values. For setting values to blob properties, the property value
> >> >> indicates the length of the data, and the actual data is passed via
> >> >> another blob pointer.
> >> >>
> >> >> The caller can demand non-blocking operation from the ioctl, and if the
> >> >> driver can't satisfy that requirement an error will be returned.
> >> >>
> >> >> The caller can also request to receive asynchronous completion events
> >> >> after the operation has reached the hardware. An event is sent for each
> >> >> object specified by the caller, whether or not the actual state of
> >> >> that object changed. Each event also carries a framebuffer ID, which
> >> >> indicates to user space that the specified object is no longer
> >> >> accessing that framebuffer.
> >> >>
> >> >> TODO: detailed error reporting?
> >> >>
> >> >> v1: original
> >> >> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
> >> >> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
> >> >>
> >> >> Signed-off-by: Ville Syrjälä 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_crtc.c  | 159 
> >> >> 
> >> >>  drivers/gpu/drm/drm_drv.c   |   1 +
> >> >>  include/drm/drmP.h  |   6 ++
> >> >>  include/drm/drm_crtc.h  |   2 +
> >> >>  include/uapi/drm/drm.h  |  12 
> >> >>  include/uapi/drm/drm_mode.h |  16 +
> >> >>  6 files changed, 196 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> >> index 09396a9..910e5c6 100644
> >> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> >> @@ -4338,3 +4338,162 @@ void drm_mode_config_cleanup(struct drm_device 
> >> >> *dev)
> >> >>   idr_destroy(&dev->mode_config.crtc_idr);
> >> >>  }
> >> >>  EXPORT_SYMBOL(drm_mode_config_cleanup);
> >> >> +
> >> >> +int drm_mode_atomic_ioctl(struct drm_device *dev,
> >> >> +   void *data, struct drm_file *file_priv)
> >> >> +{
> >> >> + struct drm_mode_atomic *arg = data;
> >> >> + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
> >> >> long)(arg->objs_ptr);
> >> >> + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
> >> >> long)(arg->count_props_ptr);
> >> >> + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
> >> >> long)(arg->props_ptr);
> >> >> + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
> >> >> long)(arg->prop_values_ptr);
> >> >> + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
> >> >> long)(arg->blob_values_ptr);
> >> >> + unsigned int copied_objs = 0;
> >> >> + unsigned int copied_props = 0;
> >> >> + unsigned int copied_blobs = 0;
> >> >> + void *state;
> >> >> + int ret = 0;
> >> >> + unsigned int i, j;
> >> >> +
> >> >> + if (arg->flags & ~(DRM_MODE_ATOMIC_TEST_ONLY |
> >> >> + DRM_MODE_ATOMIC_EVENT | DRM_MODE_ATOMIC_NONBLOCK))
> >> >> + return -EINVAL;
> >> >> +
> >> >> + /* can't test and expect an event at the same time. */
> >> >> + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
> >> >> + (arg->flags & DRM_MODE_ATOMIC_EVENT))
> >> >> + return -EINVAL;
> >> >> +
> >> >> + mutex_lock(&dev->mode_config.mutex);
> >> >
> >> > I'm pretty sure I had a version w/ fixed locking...
> >> >
> >> > git://gitorious.org/vsyrjala/linux.git rebased_drm_atomic_24
> >>
> >> oh, hmm.. actually the locking should no longer be in the ioctl fxn,
> >> but should be pushed down to the commit.  looks like I missed this.  I
> >> need to dig up some actual test code for atomic ioctl ;-)
> >
> > It can't be in commit. At the very least it has to be around
> > check+commit, and also you need to hold some locks when you're copying
> > the current config over to your temp storage. That's assuming you store
> > _everything_ in the temp storage and so it doesn't matter if the current
> > state can change between the copy and check+commit.
> >
> 
> hmm.. I start to wish we did atomic first, before the fine grained
> locking re-work ;-)

I don't see it mattering for this particular problem if we just grab
the big lock anyway.

But as I already stated, I would prefer to solve the plane locking 
before doing atomic. Whether we have per-plane locks or

Re: [RFCv1 11/12] drm: Atomic modeset ioctl

2013-10-07 Thread Rob Clark 
On Mon, Oct 7, 2013 at 11:05 AM, Ville Syrjälä
 wrote:
> On Mon, Oct 07, 2013 at 10:39:01AM -0400, Rob Clark wrote:
>> On Mon, Oct 7, 2013 at 10:18 AM, Ville Syrjälä
>>  wrote:
>> > On Mon, Oct 07, 2013 at 09:55:47AM -0400, Rob Clark wrote:
>> >> On Mon, Oct 7, 2013 at 9:28 AM, Ville Syrjälä
>> >>  wrote:
>> >> > On Sat, Oct 05, 2013 at 08:45:49PM -0400, Rob Clark wrote:
>> >> >> From: Ville Syrjälä 
>> >> >>
>> >> >> The atomic modeset ioctl cna be used to push any number of new values
>> >> >> for object properties. The driver can then check the full device
>> >> >> configuration as single unit, and try to apply the changes atomically.
>> >> >>
>> >> >> The ioctl simply takes a list of object IDs and property IDs and their
>> >> >> values. For setting values to blob properties, the property value
>> >> >> indicates the length of the data, and the actual data is passed via
>> >> >> another blob pointer.
>> >> >>
>> >> >> The caller can demand non-blocking operation from the ioctl, and if the
>> >> >> driver can't satisfy that requirement an error will be returned.
>> >> >>
>> >> >> The caller can also request to receive asynchronous completion events
>> >> >> after the operation has reached the hardware. An event is sent for each
>> >> >> object specified by the caller, whether or not the actual state of
>> >> >> that object changed. Each event also carries a framebuffer ID, which
>> >> >> indicates to user space that the specified object is no longer
>> >> >> accessing that framebuffer.
>> >> >>
>> >> >> TODO: detailed error reporting?
>> >> >>
>> >> >> v1: original
>> >> >> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
>> >> >> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
>> >> >>
>> >> >> Signed-off-by: Ville Syrjälä 
>> >> >> ---
>> >> >>  drivers/gpu/drm/drm_crtc.c  | 159 
>> >> >> 
>> >> >>  drivers/gpu/drm/drm_drv.c   |   1 +
>> >> >>  include/drm/drmP.h  |   6 ++
>> >> >>  include/drm/drm_crtc.h  |   2 +
>> >> >>  include/uapi/drm/drm.h  |  12 
>> >> >>  include/uapi/drm/drm_mode.h |  16 +
>> >> >>  6 files changed, 196 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> >> index 09396a9..910e5c6 100644
>> >> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> >> @@ -4338,3 +4338,162 @@ void drm_mode_config_cleanup(struct drm_device 
>> >> >> *dev)
>> >> >>   idr_destroy(&dev->mode_config.crtc_idr);
>> >> >>  }
>> >> >>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>> >> >> +
>> >> >> +int drm_mode_atomic_ioctl(struct drm_device *dev,
>> >> >> +   void *data, struct drm_file *file_priv)
>> >> >> +{
>> >> >> + struct drm_mode_atomic *arg = data;
>> >> >> + uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned 
>> >> >> long)(arg->objs_ptr);
>> >> >> + uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned 
>> >> >> long)(arg->count_props_ptr);
>> >> >> + uint32_t __user *props_ptr = (uint32_t __user *)(unsigned 
>> >> >> long)(arg->props_ptr);
>> >> >> + uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned 
>> >> >> long)(arg->prop_values_ptr);
>> >> >> + uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned 
>> >> >> long)(arg->blob_values_ptr);
>> >> >> + unsigned int copied_objs = 0;
>> >> >> + unsigned int copied_props = 0;
>> >> >> + unsigned int copied_blobs = 0;
>> >> >> + void *state;
>> >> >> + int ret = 0;
>> >> >> + unsigned int i, j;
>> >> >> +
>> >> >> + if (arg->flags & ~(DRM_MODE_ATOMIC_TEST_ONLY |
>> >> >> + DRM_MODE_ATOMIC_EVENT | 
>> >> >> DRM_MODE_ATOMIC_NONBLOCK))
>> >> >> + return -EINVAL;
>> >> >> +
>> >> >> + /* can't test and expect an event at the same time. */
>> >> >> + if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
>> >> >> + (arg->flags & DRM_MODE_ATOMIC_EVENT))
>> >> >> + return -EINVAL;
>> >> >> +
>> >> >> + mutex_lock(&dev->mode_config.mutex);
>> >> >
>> >> > I'm pretty sure I had a version w/ fixed locking...
>> >> >
>> >> > git://gitorious.org/vsyrjala/linux.git rebased_drm_atomic_24
>> >>
>> >> oh, hmm.. actually the locking should no longer be in the ioctl fxn,
>> >> but should be pushed down to the commit.  looks like I missed this.  I
>> >> need to dig up some actual test code for atomic ioctl ;-)
>> >
>> > It can't be in commit. At the very least it has to be around
>> > check+commit, and also you need to hold some locks when you're copying
>> > the current config over to your temp storage. That's assuming you store
>> > _everything_ in the temp storage and so it doesn't matter if the current
>> > state can change between the copy and check+commit.
>> >
>>
>> hmm.. I start to wish we did atomic first, before the fine grained
>> locking re-work ;-)
>
> I don't see it mattering for this particula

[Bug 65254] opengl flicker in xbmc / glxgears

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=65254

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #23 from Alex Deucher  ---


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

-- 
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 63997] Artifacts using a HD7480D on a A4-5300 APU

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=63997

Alex Deucher  changed:

   What|Removed |Added

 CC||vl...@aresgate.net

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

-- 
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 1/3] drm/dp: add helper for checking DP_ENHANCED_FRAME_CAP in DPCD

2013-10-07 Thread Alex Deucher 
On Fri, Oct 4, 2013 at 8:08 AM, Jani Nikula  wrote:
> Signed-off-by: Jani Nikula 

Patches 1 and 2 are:

Reviewed-by: Alex Deucher 


> ---
>  include/drm/drm_dp_helper.h |7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ae8dbfb..fdf58fa 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -390,4 +390,11 @@ drm_dp_max_lane_count(u8 dpcd[DP_RECEIVER_CAP_SIZE])
> return dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
>  }
>
> +static inline bool
> +drm_dp_enhanced_frame_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> +   return dpcd[DP_DPCD_REV] >= 0x11 &&
> +   (dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP);
> +}
> +
>  #endif /* _DRM_DP_HELPER_H_ */
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] Rv6xx dpm problems

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

Alex Deucher  changed:

   What|Removed |Added

Summary|r600: linux v3.11.0-RC  |Rv6xx dpm problems
   |isn't booting with  |
   |radeon.dpm=1 option in grub |

-- 
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 70189] [rv620] Thinkpad T400 fails to boot most times with radeon.dpm=1

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=70189

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Deucher  ---


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

-- 
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 66963] Rv6xx dpm problems

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

Alex Deucher  changed:

   What|Removed |Added

 CC||h.j...@gmx.at

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

-- 
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 54867] bug in r300 compiler

2013-10-07 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=54867

David "okias" Heidelberger  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|dri-devel@lists.freedesktop |david.heidelber...@ixit.cz
   |.org|
  Attachment #80074|0   |1
is obsolete||

--- Comment #5 from David "okias" Heidelberger  ---
Created attachment 87247
  --> https://bugs.freedesktop.org/attachment.cgi?id=87247&action=edit
0001-r300g-compiler-Fix-unsigned-comparison-with-less-tha.patch

Hi Tom,

sending correctly formated commit message.

David

-- 
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 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

2013-10-07 Thread Russell King - ARM Linux 
On Mon, Oct 07, 2013 at 11:01:41AM +0200, Jean-Francois Moine wrote:
> On Sun, 06 Oct 2013 23:09:56 +0100
> Russell King  wrote:
> 
> > This patch adds ARGB hardware cursor support to the DRM driver for the
> > Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
> > 64x32 resolutions.
>   [snip]
> 
> I don't see the interest of such cursors. Actually, most often, the
> cursors are 64x64 and 'A' is either 0 or 0xff. As the Armada 510
> supports 64x64 cursors with transparency, it would be more useful to
> implement these ones...

Sorry, you're completely wrong there.  Xorg uses an alphablended cursor.
This patch is a result of trialling each of the Armada's cursor options
and this is the only one which results in a reasonable looking cursor.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Russell King - ARM Linux 
On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
> On Sun, 06 Oct 2013 23:11:56 +0100
> Russell King  wrote:
> 
> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/drm/armada/Kconfig  |9 +++
> >  drivers/gpu/drm/armada/armada_drv.c |   42 
> > +++
> >  2 files changed, 51 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
> > index c7a0a94..87e62dd 100644
> > --- a/drivers/gpu/drm/armada/Kconfig
> > +++ b/drivers/gpu/drm/armada/Kconfig
> > @@ -13,3 +13,12 @@ config DRM_ARMADA
> >   This driver provides no built-in acceleration; acceleration is
> >   performed by other IP found on the SoC.  This driver provides
> >   kernel mode setting and buffer management to userspace.
> > +
> > +config DRM_ARMADA_TDA1998X
> > +   bool "Support TDA1998X HDMI output"
> > +   depends on DRM_ARMADA != n
> > +   depends on I2C && DRM_I2C_NXP_TDA998X = y
> > +   default y
> > +   help
> > + Support the TDA1998x HDMI output device found on the Solid-Run
> > + CuBox.
> 
> It seems we are going backwards: as the Armada based boards will soon
> move to full DT (mvebu), you are making an exception for the Cubox, so
> that there should be Cubox specific kernels. I don't like that...

*Ignored*.  You know why.

> > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> > b/drivers/gpu/drm/armada/armada_drv.c
> > index db62f1b..69517cf 100644
> > --- a/drivers/gpu/drm/armada/armada_drv.c
> > +++ b/drivers/gpu/drm/armada/armada_drv.c
> > @@ -16,6 +16,42 @@
> >  #include 
> >  #include "armada_ioctlP.h"
> >  
> > +#ifdef CONFIG_DRM_ARMADA_TDA1998X
> > +#include 
> > +#include "armada_slave.h"
> > +
> > +static struct tda998x_encoder_params params = {
> > +   /* With 0x24, there is no translation between vp_out and int_vp
> > +   FB  LCD out PinsVIP Int Vp
> > +   R:23:16 R:7:0   VPC7:0  7:0 7:0[R]
> > +   G:15:8  G:15:8  VPB7:0  23:16   23:16[G]
> > +   B:7:0   B:23:16 VPA7:0  15:815:8[B]
> > +   */
> > +   .swap_a = 2,
> > +   .swap_b = 3,
> > +   .swap_c = 4,
> > +   .swap_d = 5,
> > +   .swap_e = 0,
> > +   .swap_f = 1,
> 
> I still don't agree. You don't need to invert R <-> B for the Cubox at
> the tda998x level: this may be done setting as it should be the
> CFG_GRA_SWAPRB flag of the lcd register LCD_SPU_DMA_CTRL0.

You are totally and utterly wrong there.  We need R and B presented on
their correct lanes to the TDA998x so that the Armadas YUV->RGB
conversion works.  Setting CFG_GRA_SWAPRB does not swap the YUV output
to match, neither does setting any of the other bits.

CFG_GRA_SWAPRB is all about the _graphics_ _framebuffer_ format, it's got
nothing to do at all with how the output is wired.

> > +   .audio_cfg = BIT(2),
> > +   .audio_frame[1] = 1,
> > +   .audio_format = AFMT_SPDIF,
> > +   .audio_sample_rate = 44100,
> 
> These values are rather mysterious!

Also I'm going to ignore this comment, because quite honestly, I think
this is worthless.  You haven't investigated how the TDA998x actually
gets setup by Rabeeh.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

2013-10-07 Thread Russell King - ARM Linux 
On Mon, Oct 07, 2013 at 12:09:22PM +0200, Jean-Francois Moine wrote:
> On Mon, 7 Oct 2013 10:40:08 +0100
> Russell King - ARM Linux  wrote:
> 
> > > > This patch adds ARGB hardware cursor support to the DRM driver for the
> > > > Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
> > > > 64x32 resolutions.  
> > >   [snip]
> > > 
> > > I don't see the interest of such cursors. Actually, most often, the
> > > cursors are 64x64 and 'A' is either 0 or 0xff. As the Armada 510
> > > supports 64x64 cursors with transparency, it would be more useful to
> > > implement these ones...  
> > 
> > Sorry, you're completely wrong there.  Xorg uses an alphablended cursor.
> > This patch is a result of trialling each of the Armada's cursor options
> > and this is the only one which results in a reasonable looking cursor.
> 
> Strange. I am using the 64x64 cursor with transparency of the 510 for
> many months and I never saw any problem.

When I tried it, all cursors had variable alpha, and converting the
alpha to a single transparency bit made the cursor look rubbish against
certain backgrounds.

> If you absolutely want to have all transparency shades, you should
> accept 64x64 cursors and test if they may be rendered as 64x32 or
> 32x64, i.e. test that there is only pure transparency in the non-
> rendered rectangles...

That is policy, and that is something which can be done by the X server
rather than the kernel.  The kernel exposes the hardware capabilities,
which are to allow a 64x32 or a 32x64 cursor.  Userspace can make the
decision dynamically which it wishes to use.

However, what you're suggesting is dangerous.  What do you do when you're
presented with a cursor which is 64x64 ?  Do you:

(a) not display it
(b) crash the X server

There isn't a fallback to using software cursors available in the X server
because there's no error reporting for a failed hardware cursor update.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Russell King - ARM Linux 
On Mon, Oct 07, 2013 at 12:48:20PM +0200, Jean-Francois Moine wrote:
> On Mon, 7 Oct 2013 10:44:04 +0100
> Russell King - ARM Linux  wrote:
> 
> > On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
>   [snip]
> > > It seems we are going backwards: as the Armada based boards will soon
> > > move to full DT (mvebu), you are making an exception for the Cubox, so
> > > that there should be Cubox specific kernels. I don't like that...
> > 
> > *Ignored*.  You know why.
> 
> Sorry. I don't see why. May you explain again?

I don't run DT because DT lacks most of the features I require on the
cubox.  Therefore I can't develop for DT.  Simple.

> > > > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> > > > b/drivers/gpu/drm/armada/armada_drv.c
>   [snip]
> > > > +static struct tda998x_encoder_params params = {
> > > > +   /* With 0x24, there is no translation between vp_out and int_vp
> > > > +   FB  LCD out PinsVIP Int Vp
> > > > +   R:23:16 R:7:0   VPC7:0  7:0 7:0[R]
> > > > +   G:15:8  G:15:8  VPB7:0  23:16   23:16[G]
> > > > +   B:7:0   B:23:16 VPA7:0  15:815:8[B]
> > > > +   */
> > > > +   .swap_a = 2,
> > > > +   .swap_b = 3,
> > > > +   .swap_c = 4,
> > > > +   .swap_d = 5,
> > > > +   .swap_e = 0,
> > > > +   .swap_f = 1,
> > > 
> > > I still don't agree. You don't need to invert R <-> B for the Cubox at
> > > the tda998x level: this may be done setting as it should be the
> > > CFG_GRA_SWAPRB flag of the lcd register LCD_SPU_DMA_CTRL0.
> > 
> > You are totally and utterly wrong there.  We need R and B presented on
> > their correct lanes to the TDA998x so that the Armadas YUV->RGB
> > conversion works.  Setting CFG_GRA_SWAPRB does not swap the YUV output
> > to match, neither does setting any of the other bits.
> > 
> > CFG_GRA_SWAPRB is all about the _graphics_ _framebuffer_ format, it's got
> > nothing to do at all with how the output is wired.
> 
> Then, may you explain why you must swap R/B on simple RGB output?
> 
> From your [PATCH 2/5] DRM: Armada: Add Armada DRM driver:
> 
> + FMT(RGB888, 888PACK,CFG_SWAPRB);
> + FMT(BGR888, 888PACK,0);

I think I explained above.  This is to do with the *graphics* *framebuffer*
*format* in *memory*.  This has nothing to do with how the hardware is
wired up.

With no swapping, the 888 format is defined by the documentation to be:

[7:0] = red
[15:8] = green
[23:16] = blue

Now, if you look this up in the drm_fourcc.h header file, this corresponds
with this entry:

#define DRM_FORMAT_BGR888   fourcc_code('B', 'G', '2', '4') /* [23:0] B:G:R 
little endian */

Hence, this is the BGR888 format with no swapping.  Therefore, my second
line is correct.

With CFG_SWAPRB set, the format in hardware becomes:

[7:0] = blue
[15:8] = green
[23:16] = red

Again, if you look this up in the drm_fourcc.h header, you get:

#define DRM_FORMAT_RGB888   fourcc_code('R', 'G', '2', '4') /* [23:0] R:G:B 
little endian */

So, the two entries you quote above are 100% correct.

> + FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);

Where is the RGB swap there?  Again, this is to do with swapping the
format to match the hardware.  Please read the documentation on the
framebuffer formats.

The native 422PACK format is:
[7:0] = U
[15:8] = Y0
[23:16] = V
[31:24] = Y1

and we need to set both CFG_SWAPYU and CFG_SWAPUV to get this to be:
[7:0] = V
[15:8] = Y1
[23:16] = U
[31:24] = Y0

which is what the YUYV format wants.

> Rabeeh did the most he could to have a working Cubox. He used bad
> written drivers and he had not the time to think about how the drivers
> could be enhanced.

What does I2S give us in terms of "enhancement" which SPDIF does not,
remembering that audio is transmitted over HDMI in a format which closely
resembles SPDIF (but with a 28-bit subframe size.)

> Here is a small story about i2s/spdif: once, I set the tda998x to use
> the spdif input, and at this time, I was using the dummy codec.
> This codec accepts the format 32_LE, as does the audio device, but the
> output cannot go to spdif. Result: no hdmi sound.

How ASoC works in this regard is that the capabilities are the _union_ of
the codec and the cpu DAIs.

The SPDIF transmitter codec supports 16, 20 and 24 bits per sample but not
32.  Quite simply, that's because the SPDIF format does not allow 32-bits
per sample.  Therefore, 32_LE is not available for use with audio output,
and userspace must convert down to something which the hardware does
support.

"Because I2S can support 32-bit audio" is a poor reason, because you can't
pass 32-bit audio via HDMI due to a subframe being limited to 28 bits - up
to 24 bits for the sample and 4 bits of control/status information.
___
dri-devel mailing list
dri-devel@lis

Re: [PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

2013-10-07 Thread Sebastian Hesselbarth 

On 10/07/2013 01:09 PM, Russell King - ARM Linux wrote:

On Mon, Oct 07, 2013 at 12:48:20PM +0200, Jean-Francois Moine wrote:

On Mon, 7 Oct 2013 10:44:04 +0100
Rabeeh did the most he could to have a working Cubox. He used bad
written drivers and he had not the time to think about how the drivers
could be enhanced.


What does I2S give us in terms of "enhancement" which SPDIF does not,
remembering that audio is transmitted over HDMI in a format which closely
resembles SPDIF (but with a 28-bit subframe size.)


With respect to what _most_ users want, we should use SPDIF and ignore
I2S. Consumer audio fits well into SPDIF and we get pass-through, which
we loose on I2S.

I2S _can_ support more than two channels, but only if you wire up more
DATA lines. Those are not available on Dove, so its I2S is limited to
two channel audio.

The CuBox is simply not designed for HBR or multi-channel PCM, it is a
_consumer_ settop box replacement.

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

Re: [PATCH v3 2/4] ACPI / video: seperate backlight control and event interface

2013-10-07 Thread Rafael J. Wysocki 
On Tuesday, September 24, 2013 05:54:53 PM Aaron Lu wrote:
> On 09/24/2013 05:47 PM, Aaron Lu wrote:

[...]

> > diff --git a/include/acpi/video.h b/include/acpi/video.h
> > index 61109f2..0c665b5 100644
> > --- a/include/acpi/video.h
> > +++ b/include/acpi/video.h
> > @@ -19,11 +19,13 @@ struct acpi_device;
> >  #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
> >  extern int acpi_video_register(void);
> >  extern void acpi_video_unregister(void);
> > +extern int acpi_video_unregister_backlight(void);
> 
> Oops, forgot to remove the declration and the stub below. But it doesn't
> affect the test of the patches, so I'll leave it for a while till next
> revision.

Any chance to send the next revision?

Rafael

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

  1   2   >