date:20120316

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

Fabio Pedretti  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #3 from Fabio Pedretti  2012-03-16 15:00:23 
PDT ---
No longer reproducible with 0 A.D. alpha 9. Dunno what fixed/workarounded the
problem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm/ttm: Use pr_fmt and pr_

2012-03-16 Thread Joe Perches

Use the more current logging style.

Add pr_fmt and remove the TTM_PFX uses.
Coalesce formats and align arguments.

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/ttm/ttm_agp_backend.c|4 +-
 drivers/gpu/drm/ttm/ttm_bo.c |   72 +-
 drivers/gpu/drm/ttm/ttm_bo_vm.c  |5 +-
 drivers/gpu/drm/ttm/ttm_memory.c |   12 +++---
 drivers/gpu/drm/ttm/ttm_object.c |5 +-
 drivers/gpu/drm/ttm/ttm_page_alloc.c |   55 ---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |   60 +++--
 drivers/gpu/drm/ttm/ttm_tt.c |8 ++-
 8 files changed, 96 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c 
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 747c141..4a87282 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -29,6 +29,8 @@
  *  Keith Packard.
  */

+#define pr_fmt(fmt) "[TTM] " fmt
+
 #include "ttm/ttm_module.h"
 #include "ttm/ttm_bo_driver.h"
 #include "ttm/ttm_page_alloc.h"
@@ -74,7 +76,7 @@ static int ttm_agp_bind(struct ttm_tt *ttm, struct 
ttm_mem_reg *bo_mem)

ret = agp_bind_memory(mem, node->start);
if (ret)
-   printk(KERN_ERR TTM_PFX "AGP Bind memory failed.\n");
+   pr_err("AGP Bind memory failed\n");

return ret;
 }
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c3a57d..1f5c67c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -28,6 +28,8 @@
  * Authors: Thomas Hellstrom 
  */

+#define pr_fmt(fmt) "[TTM] " fmt
+
 #include "ttm/ttm_module.h"
 #include "ttm/ttm_bo_driver.h"
 #include "ttm/ttm_placement.h"
@@ -68,15 +70,13 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
int mem_type)
 {
struct ttm_mem_type_manager *man = >man[mem_type];

-   printk(KERN_ERR TTM_PFX "has_type: %d\n", man->has_type);
-   printk(KERN_ERR TTM_PFX "use_type: %d\n", man->use_type);
-   printk(KERN_ERR TTM_PFX "flags: 0x%08X\n", man->flags);
-   printk(KERN_ERR TTM_PFX "gpu_offset: 0x%08lX\n", man->gpu_offset);
-   printk(KERN_ERR TTM_PFX "size: %llu\n", man->size);
-   printk(KERN_ERR TTM_PFX "available_caching: 0x%08X\n",
-   man->available_caching);
-   printk(KERN_ERR TTM_PFX "default_caching: 0x%08X\n",
-   man->default_caching);
+   pr_err("has_type: %d\n", man->has_type);
+   pr_err("use_type: %d\n", man->use_type);
+   pr_err("flags: 0x%08X\n", man->flags);
+   pr_err("gpu_offset: 0x%08lX\n", man->gpu_offset);
+   pr_err("size: %llu\n", man->size);
+   pr_err("available_caching: 0x%08X\n", man->available_caching);
+   pr_err("default_caching: 0x%08X\n", man->default_caching);
if (mem_type != TTM_PL_SYSTEM)
(*man->func->debug)(man, TTM_PFX);
 }
@@ -86,16 +86,16 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object 
*bo,
 {
int i, ret, mem_type;

-   printk(KERN_ERR TTM_PFX "No space for %p (%lu pages, %luK, %luM)\n",
-   bo, bo->mem.num_pages, bo->mem.size >> 10,
-   bo->mem.size >> 20);
+   pr_err("No space for %p (%lu pages, %luK, %luM)\n",
+  bo, bo->mem.num_pages, bo->mem.size >> 10,
+  bo->mem.size >> 20);
for (i = 0; i < placement->num_placement; i++) {
ret = ttm_mem_type_from_flags(placement->placement[i],
_type);
if (ret)
return;
-   printk(KERN_ERR TTM_PFX "  placement[%d]=0x%08X (%d)\n",
-   i, placement->placement[i], mem_type);
+   pr_err("  placement[%d]=0x%08X (%d)\n",
+  i, placement->placement[i], mem_type);
ttm_mem_type_debug(bo->bdev, mem_type);
}
 }
@@ -344,7 +344,7 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
ret = -ENOMEM;
break;
default:
-   printk(KERN_ERR TTM_PFX "Illegal buffer object type\n");
+   pr_err("Illegal buffer object type\n");
ret = -EINVAL;
break;
}
@@ -432,7 +432,7 @@ moved:
if (bo->evicted) {
ret = bdev->driver->invalidate_caches(bdev, bo->mem.placement);
if (ret)
-   printk(KERN_ERR TTM_PFX "Can not flush read caches\n");
+   pr_err("Can not flush read caches\n");
bo->evicted = false;
}

@@ -734,9 +734,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,

if (unlikely(ret != 0)) {
if (ret != -ERESTARTSYS) {
-   printk(KERN_ERR TTM_PFX
-  "Failed to expire sync object before "
-

[PATCH 1/2] i915: Add and use pr_fmt and pr_

2012-03-16 Thread Joe Perches

Use a more current logging style.  Ensure that appropriate
logging messages are prefixed with "i915: ".

Convert printks to pr_.  Align arguments.

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/i915/i915_dma.c   |6 ++-
 drivers/gpu/drm/i915/i915_irq.c   |   70 +
 drivers/gpu/drm/i915/intel_opregion.c |4 +-
 drivers/gpu/drm/i915/intel_panel.c|4 +-
 4 files changed, 37 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9341eb8..7e83818 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -26,6 +26,8 @@
  *
  */

+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc_helper.h"
@@ -1158,14 +1160,14 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
struct drm_device *dev = pci_get_drvdata(pdev);
pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
if (state == VGA_SWITCHEROO_ON) {
-   printk(KERN_INFO "i915: switched on\n");
+   pr_info("switched on\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
/* i915 resume handler doesn't set to D0 */
pci_set_power_state(dev->pdev, PCI_D0);
i915_resume(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
-   printk(KERN_ERR "i915: switched off\n");
+   pr_err("switched off\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
i915_suspend(dev, pmm);
dev->switch_power_state = DRM_SWITCH_POWER_OFF;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index afd4e03..4c89149 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -26,6 +26,8 @@
  *
  */

+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include "drmP.h"
@@ -1103,33 +1105,26 @@ static void i915_report_and_clear_eir(struct drm_device 
*dev)
if (!eir)
return;

-   printk(KERN_ERR "render error detected, EIR: 0x%08x\n",
-  eir);
+   pr_err("render error detected, EIR: 0x%08x\n", eir);

if (IS_G4X(dev)) {
if (eir & (GM45_ERROR_MEM_PRIV | GM45_ERROR_CP_PRIV)) {
u32 ipeir = I915_READ(IPEIR_I965);

-   printk(KERN_ERR "  IPEIR: 0x%08x\n",
-  I915_READ(IPEIR_I965));
-   printk(KERN_ERR "  IPEHR: 0x%08x\n",
-  I915_READ(IPEHR_I965));
-   printk(KERN_ERR "  INSTDONE: 0x%08x\n",
+   pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
+   pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
+   pr_err("  INSTDONE: 0x%08x\n",
   I915_READ(INSTDONE_I965));
-   printk(KERN_ERR "  INSTPS: 0x%08x\n",
-  I915_READ(INSTPS));
-   printk(KERN_ERR "  INSTDONE1: 0x%08x\n",
-  I915_READ(INSTDONE1));
-   printk(KERN_ERR "  ACTHD: 0x%08x\n",
-  I915_READ(ACTHD_I965));
+   pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
+   pr_err("  INSTDONE1: 0x%08x\n", I915_READ(INSTDONE1));
+   pr_err("  ACTHD: 0x%08x\n", I915_READ(ACTHD_I965));
I915_WRITE(IPEIR_I965, ipeir);
POSTING_READ(IPEIR_I965);
}
if (eir & GM45_ERROR_PAGE_TABLE) {
u32 pgtbl_err = I915_READ(PGTBL_ER);
-   printk(KERN_ERR "page table error\n");
-   printk(KERN_ERR "  PGTBL_ER: 0x%08x\n",
-  pgtbl_err);
+   pr_err("page table error\n");
+   pr_err("  PGTBL_ER: 0x%08x\n", pgtbl_err);
I915_WRITE(PGTBL_ER, pgtbl_err);
POSTING_READ(PGTBL_ER);
}
@@ -1138,53 +1133,42 @@ static void i915_report_and_clear_eir(struct drm_device 
*dev)
if (!IS_GEN2(dev)) {
if (eir & I915_ERROR_PAGE_TABLE) {
u32 pgtbl_err = I915_READ(PGTBL_ER);
-   printk(KERN_ERR "page table error\n");
-   printk(KERN_ERR "  PGTBL_ER: 0x%08x\n",
-  pgtbl_err);
+   pr_err("page table error\n");
+   pr_err("  PGTBL_ER: 0x%08x\n", pgtbl_err);
I915_WRITE(PGTBL_ER, pgtbl_err);
POSTING_READ(PGTBL_ER);
}
}

if (eir & I915_ERROR_MEMORY_REFRESH) {
-   printk(KERN_ERR "memory refresh

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

2012-03-16 Thread Keith Packard

<#part sign=pgpmime>
On Fri, 16 Mar 2012 16:24:35 -0700, Linus Torvalds  wrote:

> Well, even without hibernation, one theory was about the VC switching
> - apparently that was one thing that at least one reporter does end up
> doing - switching from X into the virtual terminals and back.

Thanks for the extra info; it doesn't bring anything to mind as we just
don't do that much when VT-switching anymore. But, yet another code path
to explore.

> That may have similar issues, and may be the deeper problem (do people
> still do the VC switching *for* hibernation?)

I haven't a clue -- I haven't tried hibernating a machine in years...

-- 
keith.packard at intel.com

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

2012-03-16 Thread bugzilla-dae...@bugzilla.kernel.org

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


Jonathan Nieder  changed:

   What|Removed |Added

 CC||jrnieder at gmail.com




--- Comment #3 from Jonathan Nieder   2012-03-16 
19:05:06 ---
(In reply to comment #2)

> I did bisect to identify the first bad commit as
> 17d857be649a21ca90008c6dc425d849fa83db5c , which is merely tagging 2.6.32-rc1.
> I suspect some user space component is only enabling KMS if the kernel version
> equals or exceeds this tag and that's why it is only triggered from that
> commit.

Thanks.  Odd.  The test the radeon driver uses is

if (info->dri->pKernelDRMVersion->version_minor >= 5)
  ginfo.request = RADEON_INFO_ACCEL_WORKING2;
else
  ginfo.request = RADEON_INFO_ACCEL_WORKING;

which wouldn't be affected by utsversion.  So, questions:

1) Is that bisection result reproducible?  I.e., if you do:

 cd linux
 git checkout v2.6.32-rc1
 cp /boot/config-$(uname -r) .config; # current configuration
 make localmodconfig; # optional: minimize configuration
 make deb-pkg; # optionally with -j for parallel build
 dpkg -i ../; # as root
 reboot
 ... test test test ...

 cd linux
 git checkout HEAD^
 make deb-pkg; # maybe with -j4
 dpkg -i ../
 reboot
 ... test some more ...

does the first package produced reproduce the misbehavior and
the second one not?

2) Can you reproduce this without X?  What happens if you boot
in recovery mode, run "modprobe radeon" to make sure the driver
is loaded, and suspend?

3) An attachment with "dmesg" output (and /var/log/Xorg.0.log if
X seems to be involved) from a non-working kernel would also be
interesting.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH v2 14/14] drm/exynos: enable hdmi audio feature

From: Seung-Woo Kim 

This patch adds hdmi audio feature for exynos drm.
With this patch, i2s channel feeds audio data in hdmi when hdmi is connected.

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |  167 +++
 drivers/gpu/drm/exynos/regs-hdmi.h   |  182 ++
 2 files changed, 349 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3583a7b..575a8cb 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1319,6 +1319,169 @@ static struct exynos_hdmi_display_ops display_ops = {
.power_on   = hdmi_display_power_on,
 };

+static void hdmi_set_acr(u32 freq, u8 *acr)
+{
+   u32 n, cts;
+
+   switch (freq) {
+   case 32000:
+   n = 4096;
+   cts = 27000;
+   break;
+   case 44100:
+   n = 6272;
+   cts = 3;
+   break;
+   case 88200:
+   n = 12544;
+   cts = 3;
+   break;
+   case 176400:
+   n = 25088;
+   cts = 3;
+   break;
+   case 48000:
+   n = 6144;
+   cts = 27000;
+   break;
+   case 96000:
+   n = 12288;
+   cts = 27000;
+   break;
+   case 192000:
+   n = 24576;
+   cts = 27000;
+   break;
+   default:
+   n = 0;
+   cts = 0;
+   break;
+   }
+
+   acr[1] = cts >> 16;
+   acr[2] = cts >> 8 & 0xff;
+   acr[3] = cts & 0xff;
+
+   acr[4] = n >> 16;
+   acr[5] = n >> 8 & 0xff;
+   acr[6] = n & 0xff;
+}
+
+static void hdmi_reg_acr(struct hdmi_context *hdata, u8 *acr)
+{
+   hdmi_reg_writeb(hdata, HDMI_ACR_N0, acr[6]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_N1, acr[5]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_N2, acr[4]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_MCTS0, acr[3]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_MCTS1, acr[2]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_MCTS2, acr[1]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_CTS0, acr[3]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_CTS1, acr[2]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_CTS2, acr[1]);
+
+   if (hdata->is_v13)
+   hdmi_reg_writeb(hdata, HDMI_V13_ACR_CON, 4);
+   else
+   hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
+}
+
+static void hdmi_audio_init(struct hdmi_context *hdata)
+{
+   u32 sample_rate, bits_per_sample, frame_size_code;
+   u32 data_num, bit_ch, sample_frq;
+   u32 val;
+   u8 acr[7];
+
+   sample_rate = 44100;
+   bits_per_sample = 16;
+   frame_size_code = 0;
+
+   switch (bits_per_sample) {
+   case 20:
+   data_num = 2;
+   bit_ch  = 1;
+   break;
+   case 24:
+   data_num = 3;
+   bit_ch  = 1;
+   break;
+   default:
+   data_num = 1;
+   bit_ch  = 0;
+   break;
+   }
+
+   hdmi_set_acr(sample_rate, acr);
+   hdmi_reg_acr(hdata, acr);
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CON, HDMI_I2S_IN_DISABLE
+   | HDMI_I2S_AUD_I2S | HDMI_I2S_CUV_I2S_ENABLE
+   | HDMI_I2S_MUX_ENABLE);
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CH, HDMI_I2S_CH0_EN
+   | HDMI_I2S_CH1_EN | HDMI_I2S_CH2_EN);
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CUV, HDMI_I2S_CUV_RL_EN);
+
+   sample_frq = (sample_rate == 44100) ? 0 :
+   (sample_rate == 48000) ? 2 :
+   (sample_rate == 32000) ? 3 :
+   (sample_rate == 96000) ? 0xa : 0x0;
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_CLK_CON, HDMI_I2S_CLK_DIS);
+   hdmi_reg_writeb(hdata, HDMI_I2S_CLK_CON, HDMI_I2S_CLK_EN);
+
+   val = hdmi_reg_read(hdata, HDMI_I2S_DSD_CON) | 0x01;
+   hdmi_reg_writeb(hdata, HDMI_I2S_DSD_CON, val);
+
+   /* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
+   | HDMI_I2S_SEL_LRCK(6));
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
+   | HDMI_I2S_SEL_SDATA2(4));
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_2, HDMI_I2S_SEL_SDATA3(1)
+   | HDMI_I2S_SEL_SDATA2(2));
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_3, HDMI_I2S_SEL_DSD(0));
+
+   /* I2S_CON_1 & 2 */
+   hdmi_reg_writeb(hdata, HDMI_I2S_CON_1, HDMI_I2S_SCLK_FALLING_EDGE
+   | HDMI_I2S_L_CH_LOW_POL);
+   hdmi_reg_writeb(hdata, HDMI_I2S_CON_2, HDMI_I2S_MSB_FIRST_MODE
+   |

[PATCH v2 13/14] drm/exynos: add default pixel format for plane

From: Eunchul Kim 

DRM checks whether the plane supports a pixel format of fb when plane is
updated. This adds a default pixel format supporting format exynos drm
plane.

Signed-off-by: Eunchul Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index bdcf770..c277a3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -22,6 +22,10 @@ struct exynos_plane {
boolenabled;
 };

+static const uint32_t formats[] = {
+   DRM_FORMAT_XRGB,
+};
+
 static int
 exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
 struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -115,9 +119,9 @@ int exynos_plane_init(struct drm_device *dev, unsigned int 
nr)

exynos_plane->overlay.zpos = DEFAULT_ZPOS;

-   /* TODO: format */
return drm_plane_init(dev, _plane->base, possible_crtcs,
- _plane_funcs, NULL, 0, false);
+ _plane_funcs, formats, ARRAY_SIZE(formats),
+ false);
 }

 int exynos_plane_set_zpos_ioctl(struct drm_device *dev, void *data,
-- 
1.7.4.1

[PATCH v2 12/14] drm/exynos: cleanup exynos_hdmi.h

From: Joonyoung Shim 

The some contents of the exynos_hdmi.h are used only in exynos_hdmi.c,
so move them to exynos_hdmi.c.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   36 
 drivers/gpu/drm/exynos/exynos_hdmi.h  |   42 -
 drivers/gpu/drm/exynos/exynos_mixer.c |1 -
 3 files changed, 36 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3fe5b2e..3583a7b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -45,6 +45,42 @@
 #define MAX_HEIGHT 1080
 #define get_hdmi_context(dev)  platform_get_drvdata(to_platform_device(dev))

+struct hdmi_resources {
+   struct clk  *hdmi;
+   struct clk  *sclk_hdmi;
+   struct clk  *sclk_pixel;
+   struct clk  *sclk_hdmiphy;
+   struct clk  *hdmiphy;
+   struct regulator_bulk_data  *regul_bulk;
+   int regul_count;
+};
+
+struct hdmi_context {
+   struct device   *dev;
+   struct drm_device   *drm_dev;
+   struct fb_videomode *default_timing;
+   unsigned intis_v13:1;
+   unsigned intdefault_win;
+   unsigned intdefault_bpp;
+   boolhpd_handle;
+   boolenabled;
+
+   struct resource *regs_res;
+   void __iomem*regs;
+   unsigned intirq;
+   struct workqueue_struct *wq;
+   struct work_struct  hotplug_work;
+
+   struct i2c_client   *ddc_port;
+   struct i2c_client   *hdmiphy_port;
+
+   /* current hdmiphy conf index */
+   int cur_conf;
+
+   struct hdmi_resources   res;
+   void*parent_ctx;
+};
+
 /* HDMI Version 1.3 */
 static const u8 hdmiphy_v13_conf27[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_hdmi.h
index 040ecad..1c3b6d8 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.h
@@ -28,48 +28,6 @@
 #ifndef _EXYNOS_HDMI_H_
 #define _EXYNOS_HDMI_H_

-struct hdmi_resources {
-   struct clk *hdmi;
-   struct clk *sclk_hdmi;
-   struct clk *sclk_pixel;
-   struct clk *sclk_hdmiphy;
-   struct clk *hdmiphy;
-   struct regulator_bulk_data *regul_bulk;
-   int regul_count;
-};
-
-struct hdmi_context {
-   struct device   *dev;
-   struct drm_device   *drm_dev;
-   struct fb_videomode *default_timing;
-   unsigned intis_v13:1;
-   unsigned intdefault_win;
-   unsigned intdefault_bpp;
-   boolhpd_handle;
-   boolenabled;
-
-   struct resource *regs_res;
-   /** base address of HDMI registers */
-   void __iomem *regs;
-   /** HDMI hotplug interrupt */
-   unsigned int irq;
-   /** workqueue for delayed work */
-   struct workqueue_struct *wq;
-   /** hotplug handling work */
-   struct work_struct hotplug_work;
-
-   struct i2c_client *ddc_port;
-   struct i2c_client *hdmiphy_port;
-
-   /** current hdmiphy conf index */
-   int cur_conf;
-   /** other resources */
-   struct hdmi_resources res;
-
-   void *parent_ctx;
-};
-
-
 void hdmi_attach_ddc_client(struct i2c_client *ddc);
 void hdmi_attach_hdmiphy_client(struct i2c_client *hdmiphy);

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index f42c437..4d5f41e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -36,7 +36,6 @@

 #include "exynos_drm_drv.h"
 #include "exynos_drm_hdmi.h"
-#include "exynos_hdmi.h"

 #define HDMI_OVERLAY_NUMBER3

-- 
1.7.4.1

[PATCH v2 11/14] drm/exynos: remove exynos_mixer.h

From: Joonyoung Shim 

The contents of exynos_mixer.h are used only in exynos_mixer.c, so
separated header is unnecessary.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   49 +-
 drivers/gpu/drm/exynos/exynos_mixer.h |   92 -
 2 files changed, 48 insertions(+), 93 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 242cbcd..f42c437 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -37,10 +37,57 @@
 #include "exynos_drm_drv.h"
 #include "exynos_drm_hdmi.h"
 #include "exynos_hdmi.h"
-#include "exynos_mixer.h"
+
+#define HDMI_OVERLAY_NUMBER3

 #define get_mixer_context(dev) platform_get_drvdata(to_platform_device(dev))

+struct hdmi_win_data {
+   dma_addr_t  dma_addr;
+   void __iomem*vaddr;
+   dma_addr_t  chroma_dma_addr;
+   void __iomem*chroma_vaddr;
+   uint32_tpixel_format;
+   unsigned intbpp;
+   unsigned intcrtc_x;
+   unsigned intcrtc_y;
+   unsigned intcrtc_width;
+   unsigned intcrtc_height;
+   unsigned intfb_x;
+   unsigned intfb_y;
+   unsigned intfb_width;
+   unsigned intfb_height;
+   unsigned intmode_width;
+   unsigned intmode_height;
+   unsigned intscan_flags;
+};
+
+struct mixer_resources {
+   struct device   *dev;
+   int irq;
+   void __iomem*mixer_regs;
+   void __iomem*vp_regs;
+   spinlock_t  reg_slock;
+   struct clk  *mixer;
+   struct clk  *vp;
+   struct clk  *sclk_mixer;
+   struct clk  *sclk_hdmi;
+   struct clk  *sclk_dac;
+};
+
+struct mixer_context {
+   struct fb_videomode *default_timing;
+   unsigned intdefault_win;
+   unsigned intdefault_bpp;
+   unsigned intirq;
+   int pipe;
+   boolinterlace;
+   boolvp_enabled;
+
+   struct mixer_resources  mixer_res;
+   struct hdmi_win_datawin_data[HDMI_OVERLAY_NUMBER];
+};
+
 static const u8 filter_y_horiz_tap8[] = {
0,  -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, 0,  0,  0,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.h 
b/drivers/gpu/drm/exynos/exynos_mixer.h
deleted file mode 100644
index cebacfe..000
--- a/drivers/gpu/drm/exynos/exynos_mixer.h
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * Authors:
- * Seung-Woo Kim 
- * Inki Dae 
- *
- * 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, sublicense,
- * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
- * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS 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.
- */
-
-#ifndef _EXYNOS_MIXER_H_
-#define _EXYNOS_MIXER_H_
-
-#define HDMI_OVERLAY_NUMBER3
-
-struct hdmi_win_data {
-   dma_addr_t  dma_addr;
-   void __iomem*vaddr;
-   dma_addr_t  chroma_dma_addr;
-   void __iomem*chroma_vaddr;
-   uint32_tpixel_format;
-   unsigned intbpp;
-   unsigned intcrtc_x;
-   unsigned intcrtc_y;
-   unsigned intcrtc_width;
-   unsigned intcrtc_height;
-   unsigned intfb_x;
-   unsigned intfb_y;
-   unsigned intfb_width;
-   unsigned intfb_height;
-   unsigned intmode_width;
-

[PATCH v2 10/14] drm/exynos: added virtual display driver.

this driver would be used for wireless display. virtual display
driver has independent crtc, encoder and connector and to use
this driver, user application should send edid data to this driver
from wireless display.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig|6 +
 drivers/gpu/drm/exynos/Makefile   |1 +
 drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   18 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |7 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  676 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  |   36 ++
 include/drm/exynos_drm.h  |   18 +
 9 files changed, 765 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 8493fe9..7b980cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -27,3 +27,9 @@ config DRM_EXYNOS_G2D
depends on DRM_EXYNOS
help
  Choose this option if you want to use Exynos G2D for DRM.
+
+config DRM_EXYNOS_VIDI
+   bool "Exynos DRM Virtual Display"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos VIDI for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index d6c1a3c..a67ea9a 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -13,5 +13,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index a5d6591..ee4ff74 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -315,6 +315,10 @@ struct drm_connector *exynos_drm_connector_create(struct 
drm_device *dev,
connector->interlace_allowed = true;
connector->polled = DRM_CONNECTOR_POLL_HPD;
break;
+   case EXYNOS_DISPLAY_TYPE_VIDI:
+   type = DRM_MODE_CONNECTOR_VIRTUAL;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   break;
default:
type = DRM_MODE_CONNECTOR_Unknown;
break;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 64ef4ce..9af9dec2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -39,6 +39,7 @@
 #include "exynos_drm_gem.h"
 #include "exynos_drm_g2d.h"
 #include "exynos_drm_plane.h"
+#include "exynos_drm_vidi.h"

 #define DRIVER_NAME"exynos"
 #define DRIVER_DESC"Samsung SoC DRM"
@@ -217,6 +218,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
+   vidi_connection_ioctl, DRM_UNLOCKED | DRM_AUTH),

DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
@@ -314,6 +317,12 @@ static int __init exynos_drm_init(void)
goto out_common_hdmi;
 #endif

+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   ret = platform_driver_register(_driver);
+   if (ret < 0)
+   goto out_vidi;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(_driver);
if (ret < 0)
@@ -332,6 +341,11 @@ out:
 out_g2d:
 #endif

+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   platform_driver_unregister(_driver);
+out_vidi:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
 out_common_hdmi:
@@ -358,6 +372,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(_driver);
 #endif

+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   platform_driver_unregister(_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(_drm_common_hdmi_driver);
platform_driver_unregister(_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 750daa9..168d296 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -32,9 +32,9 @@
 #include 
 #include "drm.h"

-#define MAX_CRTC

[PATCH v2 09/14] drm/exynos: add G2D driver

From: Joonyoung Shim 

The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X12 because supporting DMA.

The G2D is performed by two tasks simply.
1. Configures the rendering parameters, such as foreground color and
   coordinates data by setting the drawing context registers.
2. Start the rendering process by setting thre relevant command
   registers accordingly.

The G2D version 4.1 supports DMA mode as host interface. User can make
command list to reduce HOST(ARM) loads. The contents of The command list
is setted to relevant registers of G2D by DMA.

The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)

By Tail field, the G2D can process many command lists without halt at
one go.

The G2D has following the rendering pipeline.
--> Primitive Drawing --> Rotation --> Clipping --> Bilinear Sampling
--> Color Key --> ROP --> Mask Operation --> Alpha Blending -->
Dithering --> FrameBuffer

And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- window clipping
- rotation
- flip
- 4 operand raster operation(ROP4)
- masking operation
- alpha blending
- color key
- dithering
- etc

User should make the command list to data and registers needed by
operation to use. The Exynos G2D driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then G2D driver
converts it to memory base address.

We adds three ioctls and one event for Exynos G2D.

- ioctls
DRM_EXYNOS_G2D_GET_VER: get the G2D hardware version
DRM_EXYNOS_G2D_SET_CMDLIST: set the command list from user to driver
DRM_EXYNOS_G2D_EXEC: execute the command lists setted to driver

- event
DRM_EXYNOS_G2D_EVENT: event to give notification completion of the
  command list to user

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   31 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   13 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  885 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h |   36 ++
 include/drm/exynos_drm.h|   57 ++
 7 files changed, 1029 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9a9850a..8493fe9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -21,3 +21,9 @@ config DRM_EXYNOS_HDMI
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
+
+config DRM_EXYNOS_G2D
+   bool "Exynos DRM G2D"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 5331fa3..d6c1a3c 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -12,5 +12,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 1d78e03..64ef4ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,6 +37,7 @@
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_g2d.h"
 #include "exynos_drm_plane.h"

 #define DRIVER_NAME"exynos"
@@ -146,8 +147,16 @@ static int exynos_drm_unload(struct drm_device *dev)

 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
+   struct drm_exynos_file_private *file_priv;
+
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
+   if (!file_priv)
+   return -ENOMEM;
+
+   file->driver_priv = file_priv;
+
return exynos_drm_subdrv_open(dev, file);
 }

@@ -208,6 +217,13 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED

[PATCH v2 08/14] drm/exynos: add is_local member in exynos_drm_subdrv struct

From: Joonyoung Shim 

The is_local member indicates unused subdrv such connector and encoder
so doesn't make resources for them.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |3 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 ++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4e29c71..411832e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -59,6 +59,9 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
return ret;
}

+   if (subdrv->is_local)
+   return 0;
+
/* create and initialize a encoder for this sub driver. */
encoder = exynos_drm_encoder_create(dev, >manager,
(1 << MAX_CRTC) - 1);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a412454..b26c2f4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -225,6 +225,7 @@ struct exynos_drm_private {
  * @list: sub driver has its own list object to register to exynos drm driver.
  * @drm_dev: pointer to drm_device and this pointer would be set
  * when sub driver calls exynos_drm_subdrv_register().
+ * @is_local: appear encoder and connector disrelated device.
  * @probe: this callback would be called by exynos drm driver after
  * subdrv is registered to it.
  * @remove: this callback is used to release resources created
@@ -239,6 +240,7 @@ struct exynos_drm_private {
 struct exynos_drm_subdrv {
struct list_head list;
struct drm_device *drm_dev;
+   bool is_local;

int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
-- 
1.7.4.1

[PATCH v2 07/14] drm/exynos: add subdrv open/close functions

From: Joonyoung Shim 

Some subdrv need open and close functions call when open and close drm.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |   35 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   10 
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 +++
 3 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 937b059..4e29c71 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -175,3 +175,38 @@ int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv 
*subdrv)
return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);
+
+int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct exynos_drm_subdrv *subdrv;
+   int ret;
+
+   list_for_each_entry(subdrv, _drm_subdrv_list, list) {
+   if (subdrv->open) {
+   ret = subdrv->open(dev, subdrv->manager.dev, file);
+   if (ret)
+   goto err;
+   }
+   }
+
+   return 0;
+
+err:
+   list_for_each_entry_reverse(subdrv, >list, list) {
+   if (subdrv->close)
+   subdrv->close(dev, subdrv->manager.dev, file);
+   }
+   return ret;
+}
+EXPORT_SYMBOL_GPL(exynos_drm_subdrv_open);
+
+void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file)
+{
+   struct exynos_drm_subdrv *subdrv;
+
+   list_for_each_entry(subdrv, _drm_subdrv_list, list) {
+   if (subdrv->close)
+   subdrv->close(dev, subdrv->manager.dev, file);
+   }
+}
+EXPORT_SYMBOL_GPL(exynos_drm_subdrv_close);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 903fcf0..1d78e03 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -144,6 +144,13 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
 }

+static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
+{
+   DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+   return exynos_drm_subdrv_open(dev, file);
+}
+
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
@@ -163,6 +170,8 @@ static void exynos_drm_preclose(struct drm_device *dev,
}
}
spin_unlock_irqrestore(>event_lock, flags);
+
+   exynos_drm_subdrv_close(dev, file);
 }

 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
@@ -216,6 +225,7 @@ static struct drm_driver exynos_drm_driver = {
  DRIVER_MODESET | DRIVER_GEM,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
+   .open   = exynos_drm_open,
.preclose   = exynos_drm_preclose,
.lastclose  = exynos_drm_lastclose,
.postclose  = exynos_drm_postclose,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f8bac0e..a412454 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -229,6 +229,8 @@ struct exynos_drm_private {
  * subdrv is registered to it.
  * @remove: this callback is used to release resources created
  * by probe callback.
+ * @open: this would be called with drm device file open.
+ * @close: this would be called with drm device file close.
  * @manager: subdrv has its own manager to control a hardware appropriately
  * and we can access a hardware drawing on this manager.
  * @encoder: encoder object owned by this sub driver.
@@ -240,6 +242,10 @@ struct exynos_drm_subdrv {

int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
+   int (*open)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);
+   void (*close)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);

struct exynos_drm_manager manager;
struct drm_encoder *encoder;
@@ -269,6 +275,9 @@ int exynos_drm_subdrv_register(struct exynos_drm_subdrv 
*drm_subdrv);
 /* this function removes subdrv list from exynos drm driver */
 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *drm_subdrv);

+int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file);
+void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file);
+
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct platform_driver mixer_driver;
-- 
1.7.4.1

[PATCH v2 06/14] drm/exynos: remove module of exynos drm subdrv

From: Joonyoung Shim 

The exynos drm driver has several subdrv. They each can be module but it
causes unfixed probe order of exynodr drm driver and each subdrv. It
also needs some weird codes such as exynos_drm_fbdev_reinit and
exynos_drm_mode_group_reinit. This patch can remove weird codes and
clear codes through we doesn't modularity each subdrv.

Also this removes unnecessary codes related module.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig|8 +--
 drivers/gpu/drm/exynos/Makefile   |   10 ++-
 drivers/gpu/drm/exynos/exynos_ddc.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_connector.c |6 --
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  112 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |6 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   52 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   12 ++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |6 --
 drivers/gpu/drm/exynos/exynos_drm_fb.c|6 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   86 ---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |4 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   87 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |9 --
 drivers/gpu/drm/exynos/exynos_mixer.c |7 --
 16 files changed, 77 insertions(+), 355 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index b9e5266..9a9850a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,7 +1,6 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
depends on DRM && PLAT_SAMSUNG
-   default n
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -12,16 +11,13 @@ config DRM_EXYNOS
  If M is selected the module will be called exynosdrm.

 config DRM_EXYNOS_FIMD
-   tristate "Exynos DRM FIMD"
+   bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
-   default n
help
  Choose this option if you want to use Exynos FIMD for DRM.
- If M is selected, the module will be called exynos_drm_fimd

 config DRM_EXYNOS_HDMI
-   tristate "Exynos DRM HDMI"
+   bool "Exynos DRM HDMI"
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
- If M is selected, the module will be called exynos_drm_hdmi
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 395e69c..5331fa3 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,7 +8,9 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o 
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o

-obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
-obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
-obj-$(CONFIG_DRM_EXYNOS_HDMI) += exynos_hdmi.o exynos_mixer.o exynos_ddc.o \
-exynos_hdmiphy.o exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
+  exynos_ddc.o exynos_hdmiphy.o \
+  exynos_drm_hdmi.o
+
+obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 84b614f..7e1051d 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -55,4 +55,3 @@ struct i2c_driver ddc_driver = {
.remove = __devexit_p(s5p_ddc_remove),
.command= NULL,
 };
-EXPORT_SYMBOL(ddc_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ebdd71d..a5d6591 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -348,9 +348,3 @@ err_connector:
kfree(exynos_connector);
return NULL;
 }
-
-MODULE_AUTHOR("Inki Dae ");
-MODULE_AUTHOR("Joonyoung Shim ");
-MODULE_AUTHOR("Seung-Woo Kim ");
-MODULE_DESCRIPTION("Samsung SoC DRM Connector Driver");
-MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index d08a558..937b059 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -32,7 +32,6 @@
 #include "exynos_drm_connector.h"
 #include "exynos_drm_fbdev.h"

-static DEFINE_MUTEX(exynos_drm_mutex);
 static LIST_HEAD(exynos_drm_subdrv_list);
 static struct drm_device *drm_dev;

@@ -116,13 +115,10 @@ int

[PATCH v2 05/14] drm/exynos: release pending pageflip events when closed

From: Joonyoung Shim 

We should release pending pageflip events when closed. If not, they will
be dangling events.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 58820eb..d359cb4b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -147,8 +147,22 @@ static int exynos_drm_unload(struct drm_device *dev)
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
+   struct exynos_drm_private *private = dev->dev_private;
+   struct drm_pending_vblank_event *e, *t;
+   unsigned long flags;
+
DRM_DEBUG_DRIVER("%s\n", __FILE__);

+   /* release events of current file */
+   spin_lock_irqsave(>event_lock, flags);
+   list_for_each_entry_safe(e, t, >pageflip_event_list,
+   base.link) {
+   if (e->base.file_priv == file) {
+   list_del(>base.link);
+   e->base.destroy(>base);
+   }
+   }
+   spin_unlock_irqrestore(>event_lock, flags);
 }

 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
-- 
1.7.4.1

[PATCH v2 04/14] drm/exynos: added new funtion to get/put dma address.

this function would be used for drm based 2d acceleration driver
to get/put dma address through gem handle.
when exynos_drm_get_dma_address is called reference count of
gem object would be increased not to be released by gem close and
when exynos_drm_put_dma_address is called the reference count of
this gem object would be decreased to be released.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   58 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   18 +
 2 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 730093f..b5c6f3c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -386,6 +386,64 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
void *data,
return 0;
 }

+void *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(dev, file_priv, gem_handle);
+   if (!obj) {
+   DRM_ERROR("failed to lookup gem object.\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   exynos_gem_obj = to_exynos_gem_obj(obj);
+
+   if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS("not support NONCONTIG type.\n");
+   drm_gem_object_unreference_unlocked(obj);
+
+   /* TODO */
+   return ERR_PTR(-EINVAL);
+   }
+
+   return _gem_obj->buffer->dma_addr;
+}
+
+void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(dev, file_priv, gem_handle);
+   if (!obj) {
+   DRM_ERROR("failed to lookup gem object.\n");
+   return;
+   }
+
+   exynos_gem_obj = to_exynos_gem_obj(obj);
+
+   if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS("not support NONCONTIG type.\n");
+   drm_gem_object_unreference_unlocked(obj);
+
+   /* TODO */
+   return;
+   }
+
+   drm_gem_object_unreference_unlocked(obj);
+
+   /*
+* decrease obj->refcount one more time because we has already
+* increased it at exynos_drm_gem_get_dma_addr().
+*/
+   drm_gem_object_unreference_unlocked(obj);
+}
+
 int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 096267d..e40fbad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -88,6 +88,24 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
 int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);

+/*
+ * get dma address from gem handle and this function could be used for
+ * other drivers such as 2d/3d acceleration drivers.
+ * with this function call, gem object reference count would be increased.
+ */
+void *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv);
+
+/*
+ * put dma address from gem handle and this function could be used for
+ * other drivers such as 2d/3d acceleration drivers.
+ * with this function call, gem object reference count would be decreased.
+ */
+void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv);
+
 /* get buffer offset to map to user space. */
 int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-- 
1.7.4.1

[PATCH v2 03/14] drm/exynos: update gem and buffer framework.

with this patch, we can allocate physically continuous or non-continuous
memory and also it creates scatterlist for iommu support so allocated
memory region can be mapped to iommu page table using scatterlist.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  191 +++
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |   22 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  301 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   11 +-
 include/drm/exynos_drm.h  |6 +
 6 files changed, 463 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 3cf785c..4a3a5f7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -25,45 +25,161 @@

 #include "drmP.h"
 #include "drm.h"
+#include "exynos_drm.h"

 #include "exynos_drm_drv.h"
 #include "exynos_drm_gem.h"
 #include "exynos_drm_buf.h"

 static int lowlevel_buffer_allocate(struct drm_device *dev,
-   struct exynos_drm_gem_buf *buffer)
+   unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
+   dma_addr_t start_addr, end_addr;
+   unsigned int npages, page_size, i = 0;
+   struct scatterlist *sgl;
+   int ret = 0;
+
DRM_DEBUG_KMS("%s\n", __FILE__);

-   buffer->kvaddr = dma_alloc_writecombine(dev->dev, buffer->size,
-   >dma_addr, GFP_KERNEL);
-   if (!buffer->kvaddr) {
-   DRM_ERROR("failed to allocate buffer.\n");
+   if (flags & EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS("not support allocation type.\n");
+   return -EINVAL;
+   }
+
+   if (buf->dma_addr) {
+   DRM_DEBUG_KMS("already allocated.\n");
+   return 0;
+   }
+
+   if (buf->size >= SZ_1M) {
+   npages = (buf->size >> SECTION_SHIFT) + 1;
+   page_size = SECTION_SIZE;
+   } else if (buf->size >= SZ_64K) {
+   npages = (buf->size >> 16) + 1;
+   page_size = SZ_64K;
+   } else {
+   npages = (buf->size >> PAGE_SHIFT) + 1;
+   page_size = PAGE_SIZE;
+   }
+
+   buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   if (!buf->sgt) {
+   DRM_ERROR("failed to allocate sg table.\n");
return -ENOMEM;
}

-   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
-   (unsigned long)buffer->kvaddr,
-   (unsigned long)buffer->dma_addr,
-   buffer->size);
+   ret = sg_alloc_table(buf->sgt, npages, GFP_KERNEL);
+   if (ret < 0) {
+   DRM_ERROR("failed to initialize sg table.\n");
+   kfree(buf->sgt);
+   buf->sgt = NULL;
+   return -ENOMEM;
+   }

-   return 0;
+   buf->kvaddr = dma_alloc_writecombine(dev->dev, buf->size,
+   >dma_addr, GFP_KERNEL);
+   if (!buf->kvaddr) {
+   DRM_ERROR("failed to allocate buffer.\n");
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   start_addr = buf->dma_addr;
+   end_addr = buf->dma_addr + buf->size;
+
+   buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
+   if (!buf->pages) {
+   DRM_ERROR("failed to allocate pages.\n");
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   start_addr = buf->dma_addr;
+   end_addr = buf->dma_addr + buf->size;
+
+   buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
+   if (!buf->pages) {
+   DRM_ERROR("failed to allocate pages.\n");
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   sgl = buf->sgt->sgl;
+
+   while (i < npages) {
+   buf->pages[i] = phys_to_page(start_addr);
+   sg_set_page(sgl, buf->pages[i], page_size, 0);
+   sg_dma_address(sgl) = start_addr;
+   start_addr += page_size;
+   if (end_addr - start_addr < page_size)
+   break;
+   sgl = sg_next(sgl);
+   i++;
+   }
+
+   buf->pages[i] = phys_to_page(start_addr);
+
+   sgl = sg_next(sgl);
+   sg_set_page(sgl, buf->pages[i+1], end_addr - start_addr, 0);
+
+   DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
+   (unsigned long)buf->kvaddr,
+   (unsigned long)buf->dma_addr,
+   buf->size);
+
+   return ret;
+err2:
+   dma_free_writecombine(dev->dev, buf->size, buf->kvaddr,
+   (dma_addr_t)buf->dma_addr);
+   buf->dma_addr = (dma_addr_t)NULL;

[PATCH v2 02/14] drm/exynos: added mode_fixup feature and code clean.

this patch adds mode_fixup feature for hdmi module that
specific driver changes current mode to driver desired mode
properly.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   25 +++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |6 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |8 +++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   17 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   28 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   81 ++--
 7 files changed, 157 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 618bd4d..ebdd71d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -225,6 +225,29 @@ static struct drm_connector_helper_funcs 
exynos_connector_helper_funcs = {
.best_encoder   = exynos_drm_best_encoder,
 };

+static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
+   unsigned int max_width, unsigned int max_height)
+{
+   struct exynos_drm_connector *exynos_connector =
+   to_exynos_connector(connector);
+   struct exynos_drm_manager *manager = exynos_connector->manager;
+   struct exynos_drm_manager_ops *ops = manager->ops;
+   unsigned int width, height;
+
+   width = max_width;
+   height = max_height;
+
+   /*
+* if specific driver want to find desired_mode using maxmum
+* resolution then get max width and height from that driver.
+*/
+   if (ops && ops->get_max_resol)
+   ops->get_max_resol(manager->dev, , );
+
+   return drm_helper_probe_single_connector_modes(connector, width,
+   height);
+}
+
 /* get detection status of display device. */
 static enum drm_connector_status
 exynos_drm_connector_detect(struct drm_connector *connector, bool force)
@@ -262,7 +285,7 @@ static void exynos_drm_connector_destroy(struct 
drm_connector *connector)

 static struct drm_connector_funcs exynos_connector_funcs = {
.dpms   = drm_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
 };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index de81883..2d9a0e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -249,7 +249,11 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 {
DRM_DEBUG_KMS("%s\n", __FILE__);

-   mode = adjusted_mode;
+   /*
+* copy the mode data adjusted by mode_fixup() into crtc->mode
+* so that hardware can be seet to proper mode.
+*/
+   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));

return exynos_drm_crtc_update(crtc);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 13540de..4115a9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -155,8 +155,10 @@ struct exynos_drm_display_ops {
  *
  * @dpms: control device power.
  * @apply: set timing, vblank and overlay data to registers.
+ * @mode_fixup: fix mode data comparing to hw specific display mode.
  * @mode_set: convert drm_display_mode to hw specific display mode and
  *   would be called by encoder->mode_set().
+ * @get_max_resol: get maximum resolution to specific hardware.
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
@@ -164,7 +166,13 @@ struct exynos_drm_display_ops {
 struct exynos_drm_manager_ops {
void (*dpms)(struct device *subdrv_dev, int mode);
void (*apply)(struct device *subdrv_dev);
+   void (*mode_fixup)(struct device *subdrv_dev,
+   struct drm_connector *connector,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode);
void (*mode_set)(struct device *subdrv_dev, void *mode);
+   void (*get_max_resol)(struct device *subdrv_dev, unsigned int *width,
+   unsigned int *height);
void (*commit)(struct device *subdrv_dev);
int (*enable_vblank)(struct device *subdrv_dev);
void (*disable_vblank)(struct device *subdrv_dev);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c

[PATCH v2 01/14] drm/exynos: add HDMI version 1.4 support

From: Joonyoung Shim 

Later Exynos series from Exynos4X12 support HDMI version 1.4. We will
distinguish to use which version via platform data. This patch supports
only default features of HDMI version 1.4(The 3D, sound and etc don't
support yet)

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1152 +++---
 drivers/gpu/drm/exynos/exynos_hdmi.h |   10 +-
 drivers/gpu/drm/exynos/regs-hdmi.h   |  306 --
 include/drm/exynos_drm.h |2 +
 4 files changed, 1325 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3429d3f..1cfe86e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -43,42 +43,43 @@
 #define HDMI_OVERLAY_NUMBER3
 #define get_hdmi_context(dev)  platform_get_drvdata(to_platform_device(dev))

-static const u8 hdmiphy_conf27[32] = {
+/* HDMI Version 1.3 */
+static const u8 hdmiphy_v13_conf27[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf27_027[32] = {
+static const u8 hdmiphy_v13_conf27_027[32] = {
0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf74_175[32] = {
+static const u8 hdmiphy_v13_conf74_175[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54, 0xb9,
0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf74_25[32] = {
+static const u8 hdmiphy_v13_conf74_25[32] = {
0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8, 0x40,
0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xe0,
0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00, 0x00,
 };

-static const u8 hdmiphy_conf148_5[32] = {
+static const u8 hdmiphy_v13_conf148_5[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8, 0x40,
0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54, 0xba,
0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10, 0xE0,
0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00, 0x00,
 };

-struct hdmi_tg_regs {
+struct hdmi_v13_tg_regs {
u8 cmd;
u8 h_fsz_l;
u8 h_fsz_h;
@@ -110,7 +111,7 @@ struct hdmi_tg_regs {
u8 field_bot_hdmi_h;
 };

-struct hdmi_core_regs {
+struct hdmi_v13_core_regs {
u8 h_blank[2];
u8 v_blank[3];
u8 h_v_line[3];
@@ -123,12 +124,21 @@ struct hdmi_core_regs {
u8 v_sync_gen3[3];
 };

-struct hdmi_preset_conf {
-   struct hdmi_core_regs core;
-   struct hdmi_tg_regs tg;
+struct hdmi_v13_preset_conf {
+   struct hdmi_v13_core_regs core;
+   struct hdmi_v13_tg_regs tg;
+};
+
+struct hdmi_v13_conf {
+   int width;
+   int height;
+   int vrefresh;
+   bool interlace;
+   const u8 *hdmiphy_data;
+   const struct hdmi_v13_preset_conf *conf;
 };

-static const struct hdmi_preset_conf hdmi_conf_480p = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_480p = {
.core = {
.h_blank = {0x8a, 0x00},
.v_blank = {0x0d, 0x6a, 0x01},
@@ -154,7 +164,7 @@ static const struct hdmi_preset_conf hdmi_conf_480p = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_720p60 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_720p60 = {
.core = {
.h_blank = {0x72, 0x01},
.v_blank = {0xee, 0xf2, 0x00},
@@ -182,7 +192,7 @@ static const struct hdmi_preset_conf hdmi_conf_720p60 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080i50 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080i50 = {
.core = {
.h_blank = {0xd0, 0x02},
.v_blank = {0x32, 0xB2, 0x00},
@@ -210,7 +220,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080i50 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080p50 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080p50 = {
.core = {
.h_blank = {0xd0, 0x02},
.v_blank = {0x65, 0x6c, 0x01},
@@ -238,7 +248,7 @@ static const struct hdmi_preset_conf hdmi_conf_1080p50 = {
},
 };

-static const struct hdmi_preset_conf hdmi_conf_1080i60 = {
+static const struct hdmi_v13_preset_conf hdmi_v13_conf_1080i60 = {
.core = {
.h_blank = {0x18, 0x01},
.v_blank = {0x32, 0xB2, 0x00},
@@ -266,7 +276,7 @@ static const struct hdmi_preset_conf

[PATCH v2 00/14] updated exynos-drm-next.

Hi, Dave and all.

this update adds new features below:
- add HDMI version 1.4 and Audio support.
- add mode_fixup feature.
  . hdmi module would change current mode to driver desired mode properly.
- updated gem and buffer framework.
  . we can allocate physically continuous or non-continuous
memory and also it creates scatterlist for iommu support so allocated
memory region can be mapped to iommu page table using scatterlist.
- add dma address get/put interface.
  . this function would be used for drm based 2d acceleration driver
to get/put dma address through gem handle.
when exynos_drm_get_dma_address is called reference count of
gem object would be increased not to be released by gem close and
when exynos_drm_put_dma_address is called the reference count of
this gem object would be decreased to be released.
- add virtual display driver.
  . this driver would be used for wireless display.
- add direct rendering based 2d graphics acceleration module.
  . exynos SoC chip has fimg2d named 2d graphics accelerator and this driver
supports only exynos4x12 series.

Links to previous versions of the patchset:
v1: < http://permalink.gmane.org/gmane.comp.video.dri.devel/66247 >

Changelog v2:
- add HDMI Audio support.
- add descriptions for direct rendering based g2d driver and
  user application for it.
  . for user application, you can refer to this link below:
http://www.spinics.net/lists/dri-devel/msg20014.html
- fix variable type Dave pointed out.
  . use __u64 __user * instead of void *
- code clean to exynos gem and buffer framework.
- add default pixel format for plane.

this patch set is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-core-next
commit-id: 8229c885fe361e521ac64de36b16011e54a30de0

and you can refer to our working git repository below:
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

Thanks.

Eunchul Kim (1):
  drm/exynos: add default pixel format for plane

Inki Dae (4):
  drm/exynos: added mode_fixup feature and code clean.
  drm/exynos: update gem and buffer framework.
  drm/exynos: added new funtion to get/put dma address.
  drm/exynos: added virtual display driver.

Joonyoung Shim (8):
  drm/exynos: add HDMI version 1.4 support
  drm/exynos: release pending pageflip events when closed
  drm/exynos: remove module of exynos drm subdrv
  drm/exynos: add subdrv open/close functions
  drm/exynos: add is_local member in exynos_drm_subdrv struct
  drm/exynos: add G2D driver
  drm/exynos: remove exynos_mixer.h
  drm/exynos: cleanup exynos_hdmi.h

Seung-Woo Kim (1):
  drm/exynos: enable hdmi audio feature

 drivers/gpu/drm/exynos/Kconfig|   20 +-
 drivers/gpu/drm/exynos/Makefile   |   12 +-
 drivers/gpu/drm/exynos/exynos_ddc.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  191 +++-
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |   22 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   35 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  140 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  125 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   51 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   24 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|6 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   90 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  885 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h   |   36 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  363 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   29 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  115 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |8 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  676 
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  |   36 +
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 1437 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.h  |   50 -
 drivers/gpu/drm/exynos/exynos_mixer.c |   57 +-
 drivers/gpu/drm/exynos/exynos_mixer.h |   92 --
 drivers/gpu/drm/exynos/regs-hdmi.h|  488 -
 include/drm/exynos_drm.h  |   83 ++
 29 files changed, 4394 insertions(+), 715 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h

-- 
1.7.4.1

[Bug 42941] Resume from suspend to memory leaves display blank on Lenovo Ideapad U455

2012-03-16 Thread bugzilla-dae...@bugzilla.kernel.org

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





--- Comment #1 from Igor Murzov   2012-03-16 18:43:00 ---
Created an attachment (id=72611)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72611)
output of lspci -vvv

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching someone on the CC list of the bug.

[Bug 42941] New: Resume from suspend to memory leaves display blank on Lenovo Ideapad U455

2012-03-16 Thread bugzilla-dae...@bugzilla.kernel.org

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

   Summary: Resume from suspend to memory leaves display blank on
Lenovo Ideapad U455
   Product: Power Management
   Version: 2.5
Kernel Version: 3.3.0-rc7+
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Hibernation/Suspend
AssignedTo: power-management_other at kernel-bugs.osdl.org
ReportedBy: e-mail at date.by
CC: drivers_video-dri at kernel-bugs.osdl.org
Regression: No


Created an attachment (id=72610)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72610)
dmesg output

Hardware: Lenovo Ideapad U455 laptop with AMD Athlon Neo processor and two
video cards: Radeon HD 3200 and Radeon HD 4500.

Description: when system resumes from suspend to memory (`echo mem >
/sys/power/state`) system resumes fine as i can log into it via ssh and display
turns on, but the display stays black showing nothing. However it's possible to
make display show a picture by switching video cards with vga_switcheroo.

Steps to reproduce attached dmesg log (see my comments below):
[1]# mount -t debugfs none /sys/kernel/debug
[2]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::01:05.0
1:DIS: :Pwr::02:00.0
[3]# echo mem > /sys/power/state
[4]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::01:05.0
1:DIS: :Pwr::02:00.0
[5]# echo DIS > /sys/kernel/debug/vgaswitcheroo/switch
[6]# echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
[7]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::01:05.0
1:DIS: :Off::02:00.0
[8]# echo mem > /sys/power/state
[9]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr::01:05.0
1:DIS: :Off::02:00.0
[10]# echo DIS > /sys/kernel/debug/vgaswitcheroo/switch
[11]# echo IGD > /sys/kernel/debug/vgaswitcheroo/switch

Comments:
[2] This shows the state of the video cards before suspend.
[3] Suspend worked fine, but display was blank after resume.
[4] This shows the state of the video cards after resume.
[5] That command made display to show the picture.
[7] This shows the state of the video cards before second suspend, when only
IGD card was active.
[8] Suspend worked fine, but resume took a lot of time:
 PM: resume devices took 82.256 seconds
 [ cut here ]
 WARNING: at kernel/power/suspend_test.c:53 suspend_test_finish+0x86/0x90()
 Hardware name: 20046   
 Component: resume devices, time: 82256
 Modules linked in: btusb bluetooth snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 ext2
mbcache cpufreq_ondemand powernow_k8 freq_table mperf lp parport_pc parport
fuse radeon brcmsmac ttm mac80211 drm_kms_helper joydev snd_hda_codec_hdmi
ohci_hcd snd_hda_codec_conexant brcmutil ssb snd_hda_intel drm mmc_core
snd_hda_codec sp5100_tco cfg80211 sg ideapad_laptop agpgart psmouse atl1c
thermal snd_hwdep processor video crc8 thermal_sys pcmcia snd_pcm snd_timer
cordic rtc_cmos pcmcia_core shpchp sparse_keymap evdev ehci_hcd i2c_piix4 snd
k8temp i2c_algo_bit bcma rfkill i2c_core serio_raw soundcore snd_page_alloc
battery ac hwmon button loop btrfs [last unloaded: pcmcia_rsrc]
 Pid: 1834, comm: bash Not tainted 3.3.0-rc7+ #36
 Call Trace:
  [] warn_slowpath_common+0x7f/0xc0
  [] warn_slowpath_fmt+0x46/0x50
  [] suspend_test_finish+0x86/0x90
  [] suspend_devices_and_enter+0x101/0x1e0
  [] enter_state+0xd1/0x110
  [] state_store+0xb7/0x130
  [] kobj_attr_store+0xf/0x30
  [] sysfs_write_file+0xf2/0x180
  [] vfs_write+0xb3/0x180
  [] sys_write+0x4a/0x90
  [] system_call_fastpath+0x16/0x1b
 ---[ end trace 6802c35567ce73fa ]---
 PM: Finishing wakeup.

[9] This shows the state of the video cards after second resume.
[10] That command turned display off and that's what appeared in dmesg output:
 radeon: switched on
 radeon :02:00.0: enabling device ( -> 0003)
 radeon :02:00.0: Wait for MC idle timedout !
 radeon :02:00.0: Wait for MC idle timedout !
 [drm] PCIE GART of 512M enabled (table at 0x0004).
 radeon :02:00.0: WB enabled
 [drm] fence driver on ring 0 use gpu addr 0x2c00 and cpu addr
0x8800a4523c00
 [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8500)=0x)
 [drm:rv770_resume] *ERROR* r600 startup failed on resume
 fbcon: Remapping primary device, fb1, to tty 1-63
 radeon: switched off
[11] That command made display to show the picture.

Notes:
* I have read Documentation/power/basic-pm-debugging.txt and made all described
tests and all of them were successful.
* I have tried different quirks with `pm-suspend --quirk-*`, but none of them
helped.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching someone on the CC list of the bug.

[Linaro-mm-sig] [PATCH] dma-buf: add get_dma_buf()

On Fri, Mar 16, 2012 at 4:04 PM, Rob Clark  wrote:
> From: Rob Clark 
>
> Works in a similar way to get_file(), and is needed in cases such as
> when the exporter needs to also keep a reference to the dmabuf (that
> is later released with a dma_buf_put()), and possibly other similar
> cases.
>
> Signed-off-by: Rob Clark 

Reviewed-by: Dave Airlie

[PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Tom Cooksey


> From: Rob Clark 
> 
> Enable optional userspace access to dma-buf buffers via mmap() on the
> dma-buf file descriptor.  Userspace access to the buffer should be
> bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
> give the exporting driver a chance to deal with cache synchronization
> and such for cached userspace mappings without resorting to page
> faulting tricks.  The reasoning behind this is that, while drm
> drivers tend to have all the mechanisms in place for dealing with
> page faulting tricks, other driver subsystems may not.  And in
> addition, while page faulting tricks make userspace simpler, there
> are some associated overheads.

Speaking for the ARM Mali T6xx driver point of view, this API looks
good for us. Our use-case for mmap is glReadPixels and
glTex[Sub]Image2D on buffers the driver has imported via dma_buf. In
the case of glReadPixels, the finish ioctl isn't strictly necessary
as the CPU won't have written to the buffer and so doesn't need
flushing. As such, we'd get an additional cache flush which isn't
really necessary. But hey, it's glReadPixels - it's supposed to be
slow. :-)

I think requiring the finish ioctl in the API contract is a good
idea, even if the CPU has only done a ro access as it allows future
enhancements*. To "fix" the unnecessary flush in glReadPixels, I
think we'd like to keep the finish but see an "access type"
parameter added to prepare ioctl indicating if the access is ro or
rw to allow the cache flush in finish to be skipped if the access
was ro. As Rebecca says, a debug feature could even be added to
re-map the pages as ro in prepare(ro) to catch naughty accesses. I'd
also go as far as to say the debug feature should completely unmap
the pages after finish too. Though for us, both the access-type
parameter and debug features are "nice to haves" - we can make
progress with the code as it currently stands (assuming exporters
start using the API that is).

Something which also came up when discussing internally is the topic
of mmap APIs of the importing device driver. For example, I believe
DRM has an mmap API on GEM buffer objects. If a new dma_buf import
ioctl was added to GEM (maybe the PRIME patches already add this),
how would GEM's bo mmap API work?


* Future enhancements: The prepare/finish bracketing could be used
as part of a wider synchronization scheme with other devices.
E.g. If another device was writing to the buffer, the prepare ioctl
could block until that device had finished accessing that buffer.
In the same way, another device could be blocked from accessing that
buffer until the client process called finish. We have already
started playing with such a scheme in the T6xx driver stack we're
terming "kernel dependency system". In this scheme each buffer has a
FIFO of "buffer consumers" waiting to access a buffer. The idea
being that a "buffer consumer" is fairly abstract and could be any
device or userspace process participating in the synchronization
scheme. Examples would be GPU jobs, display controller "scan-out"
jobs, etc.

So for example, a userspace application could dispatch a GPU
fragment shading job into the GPU's kernel driver which will write
to a KMS scanout buffer. The application then immediately issues a
drm_mode_crtc_page_flip ioctl on the display controller's DRM driver
to display the soon-to-be-rendered buffer. Inside the kernel, the
GPU driver adds the fragment job to the dma_buf's FIFO. As the FIFO
was empty, dma_buf calls into the GPU kernel driver to tell it it
"owns" access to the buffer and the GPU driver schedules the job to
run on the GPU. Upon receiving the drm_mode_crtc_page_flip ioctl,
the DRM/KMS driver adds a scan-out job to the buffer's FIFO.
However, the FIFO already has the GPU's fragment shading job in it
so nothing happens until the GPU job completes. When the GPU job
completes, the GPU driver calls into dma_buf to mark its job
complete. dma_buf then takes the next job in its FIFO which the KMS
driver's scanout job, calls into the KMS driver to schedule the
pageflip. The result? A buffer gets scanned out as soon as it has
finished being rendered without needing a round-trip to userspace.
Sure, there are easier ways to achieve that goal, but the idea is
that the mechanism can be used to synchronize access across multiple
devices, which makes it useful for lots of other use-cases too.


As I say, we have already implemented something which works as I
describe but where the buffers are abstract resources not linked to
dma_buf. I'd like to discuss the finer points of the mechanisms
further, but if it's looking like there's interest in this approach
we'll start re-writing the code we have to sit on-top of dma_buf
and posting it as RFCs to the various lists. The intention is to get
this to mainline, if mainline wants it. :-)

Personally, what I particularly like about this approach to
synchronization is that it doesn't require any interfaces to be
modified. I think/hope that makes it easier

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

> Guys,
> ?I don't know if these kinds of things have been forwarded to you, but
> there's apparently been several things like this going on - with the
> finger pointing to the i915 driver apparently clearing random memory.
> Often the end result seems to be list corruption or a NULL pointer
> dereference in the filesystem layer.
>

I think the hibernate problem isn't this problem.

The hibernate issue is known and I've been hoping someone from Intel
would run with debugging it, they have a big enough team that I don't
feel I can expend the personal time to look into it.

Maybe Keith can push someone or maybe I just refuse pull requests
until one with a fix appears.

The latest thinking on the hibernate issues is kernel one sets up an
fbcon, hibernate restores the old memory and the GTT still points at
the pages,
then something writes to the console and overwrites real memory., just
a working theory, nobody has proven it yet.

Dave.

[Bug 37171] half-life 2 with -dxlevel 90 crashes system

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

--- Comment #20 from Stefan D?singer  2012-03-16 
09:41:21 PDT ---
Note that Shader Model 2 in d3d kinda supports loops and conditions on hardware
that shouldn't be able to handle them. The caveat of this support is that they
do not support dynamic branching. The loop counter is a uniform and cannot be
changed at shader runtime, and there are no break statements or other ways to
abort the loop before the iteration counter is reached. If statements only
support uniforms as conditions as well.

Wine translates those constructs into GLSL for loops and if statements that
only read uniforms, the compiler should be able to unroll them. With ARB
shaders we unroll them ourselves and generate one GL shader for each control
uniform combination that is used by the application.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

2012-03-16 Thread Linus Torvalds

On Fri, Mar 16, 2012 at 3:52 PM, Keith Packard  wrote:
>
> We had a theory about hibernation -- unflushed FB writes that go astray
> when the pages underneath the GTT get reassigned when switching from the
> boot kernel to the resumed kernel.

Well, even without hibernation, one theory was about the VC switching
- apparently that was one thing that at least one reporter does end up
doing - switching from X into the virtual terminals and back.

That may have similar issues, and may be the deeper problem (do people
still do the VC switching *for* hibernation?)

Maybe.

Linus

[ANNOUNCE] libdrm 2.4.32

2012-03-16 Thread Eric Anholt

I pushed this version out to make two new intel interfaces available
to Mesa: unsynchronized maps, and AUB dumping.

It also contains valgrind support, so you no longer get complaints in GL
applications about invalid reads/writes when the driver talks to the
GPU. Thanks, Chris!

Alan Coopersmith (1):
Make drm/drm_fourcc.h portable to non-linux platforms

Chris Wilson (3):
intel: Mark up with valgrind intrinsics to reduce false positives
configure: Fix pkg-config test in absence of valgrind
intel: Detect cache domain inconsistency with valgrind

David Herrman (1):
xf86drmMode.h: Add header protection

Eric Anholt (12):
intel: Fix a typo in decode error message.
intel: Add decode for gen7 3DSTATE_WM.
intel: Add decode for gen7 HIER_DEPTH_BUFFER.
intel: Import a new batchbuffer for the gen7 test.
intel: Add .aub file output support.
intel: Bump the copyright dates on the bufmgr files.
intel: Fix error check for I915_PARAM_HAS_LLC.
intel: Add support for (possibly) unsynchronized maps.
intel: Move the gen4-6 3DPRIMITIVE handling out of the switch statement.
intel: Add per-dword decode of gen7 3DPRIMITIVE.
intel: Quiet two more valgrind complaints with recent changes.
configure: Bump version for 2.4.32.

Jerome Glisse (1):
radeon: fix pitch alignment for scanout buffer

Kenneth Graunke (1):
intel: Add support for overriding the PCI ID via an environment variable

Matt Turner (1):
Don't require pciaccess if Intel is disabled

Michel D?nzer (1):
radeon_cs_setup_bo: Fix accounting if caller specified write and read
domains.

git tag: 2.4.32

http://dri.freedesktop.org/libdrm/libdrm-2.4.32.tar.bz2
MD5: b731faf4a49f89c318d84378cb563cf8 libdrm-2.4.32.tar.bz2
SHA1: 4aab6cc1c0d2a4822ffd83bd3da0e7a5479bf842 libdrm-2.4.32.tar.bz2
SHA256: 9ba8a1613de57af8f501a162747ed69aff30d63fc1316602770974bdd9ee984e
libdrm-2.4.32.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.32.tar.gz
MD5: 531a9c01d52808020abfe0db5f3a90e7 libdrm-2.4.32.tar.gz
SHA1: 992629afd3fca71fea351b0b0403c6682faea575 libdrm-2.4.32.tar.gz
SHA256: 79ad7c60cfb17381f0fba5f0ddb7e899d85215a894dac79be18da324f78e223e
libdrm-2.4.32.tar.gz
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120316/3221c8d9/attachment.pgp>

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #45 from Tvrtko Ursulin  2012-03-16 
09:09:56 PDT ---
(In reply to comment #44)
> Created attachment 58568 [details] [review]
> fix dvi-i load detection
> 
> It's being called on the wrong encoder.  This should fix the load detection
> issue.

Works perfectly now, thank you!

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

2012-03-16 Thread Keith Packard

<#part sign=pgpmime>
On Fri, 16 Mar 2012 16:47:46 +, Dave Airlie  wrote:

> The hibernate issue is known and I've been hoping someone from Intel
> would run with debugging it, they have a big enough team that I don't
> feel I can expend the personal time to look into it.

Yeah, I've been chatting with a couple of intel folks; we should have a
test patch ready shortly, but we haven't been able to reproduce anything
like this...

> Maybe Keith can push someone or maybe I just refuse pull requests
> until one with a fix appears.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #44 from Alex Deucher  2012-03-16 08:59:36 PDT 
---
Created attachment 58568
  --> https://bugs.freedesktop.org/attachment.cgi?id=58568
fix dvi-i load detection

It's being called on the wrong encoder.  This should fix the load detection
issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

2012-03-16 Thread Keith Packard

<#part sign=pgpmime>
On Fri, 16 Mar 2012 09:11:54 -0700, Linus Torvalds  wrote:

>  I don't know if these kinds of things have been forwarded to you, but
> there's apparently been several things like this going on - with the
> finger pointing to the i915 driver apparently clearing random memory.
> Often the end result seems to be list corruption or a NULL pointer
> dereference in the filesystem layer.

Yikes! I've been participating in the hibernation thread, but
I hadn't heard about this other random memory corruption.

We had a theory about hibernation -- unflushed FB writes that go astray
when the pages underneath the GTT get reassigned when switching from the
boot kernel to the resumed kernel.

Something similar could be happening at other times though? A graphics
page is freed with writes outstanding, the GTT entry is cleared and the
page allocated to something in the filesystem, but before the GTT entry
update is recognized by the GPU, and before pending writes are flushed,
the data gets written through the GTT to the middle of the file system
structure. That stretches the bounds of credibility though; you'd have
to have unflushed data *and* an unflushed GTT write, neither of which is
supposed to happen.

> So it might be the culprit. As the reason of the corruption is not yet
> understood, it might be that suspend/resume cycle is not necessary
> pre-requisite for this to trigger, it might just make it more likely.

That opens up a much broader scope of code that might contain problems...

-- 
keith.packard at intel.com

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #43 from Tvrtko Ursulin  2012-03-16 
08:35:35 PDT ---
(In reply to comment #42)
> (In reply to comment #41)
> > Btw is it correct that it is not possible to load detect with this hardware 
> > on
> > DVI-I when nothing is connected? (Comes up as connector status unknown).
> 
> It should work.  Sounds like you were testing without the proper quirk patch 
> in
> place or it was being called on the wrong encoder.  See
> atombios_dac_load_detect() and radeon_atom_dac_detect() in 
> atombios_encoders.c.

Hmmm.. radeon_atom_dig_detect is actually called (hpd unplug, ddc probe fails)
where the ext_encoder test fails setting it into unknown state. I definitely
have your version of the quirk.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #42 from Alex Deucher  2012-03-16 08:30:04 PDT 
---
(In reply to comment #41)
> Btw is it correct that it is not possible to load detect with this hardware on
> DVI-I when nothing is connected? (Comes up as connector status unknown).

It should work.  Sounds like you were testing without the proper quirk patch in
place or it was being called on the wrong encoder.  See
atombios_dac_load_detect() and radeon_atom_dac_detect() in atombios_encoders.c.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 09/10] drm/exynos: add G2D driver

2012-03-16 Thread Joonyoung Shim

On 03/15/2012 07:50 PM, Dave Airlie wrote:
>> G2D is a 2D graphic accelerator that supports Bit Block Transfer. This
>> G2D driver is exynos drm specific and supports only exynos4x12 series.
>> user application fills command set in cmdlist and once dma start request
>> these cmdlists are parsed and performed by dma.
> Where is this block documented or a pointer to the corresponding open
> userspace user code?

I attach simple g2dtest program patch. The base of this patch is master
branch of lastest libdrm git.

This user progrem can test just solid color fill example.
I will cleanup and update it for more operations later.

Thanks.

> Again the ioctls look like they need to be depointered and use __u64.
>
> It would be nice if you could document how the command stream and engine work.
>
> How does userspace pass addresses to it? straight or via gem objects?
> how does it
> stop userspace blt to places it shouldn't etc.
>
> I'm getting the feeling this accel enabled driver needs a lot more of
> a commit message
> and lot more documentation on what it can be used for.
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #41 from Tvrtko Ursulin  2012-03-16 
08:16:13 PDT ---
Btw is it correct that it is not possible to load detect with this hardware on
DVI-I when nothing is connected? (Comes up as connector status unknown).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] Add simple g2dtest

2012-03-16 Thread Joonyoung Shim

This can test only solid color fill.

Signed-off-by: Joonyoung Shim 
---
 configure.ac  |1 +
 include/drm/exynos_drm.h  |  185 ++
 tests/Makefile.am |2 +-
 tests/g2dtest/Makefile.am |   16 ++
 tests/g2dtest/g2d.h   |   64 +
 tests/g2dtest/g2d_reg.h   |  108 
 tests/g2dtest/g2dtest.c   |  612 +
 7 files changed, 987 insertions(+), 1 deletions(-)
 create mode 100644 include/drm/exynos_drm.h
 create mode 100644 tests/g2dtest/Makefile.am
 create mode 100644 tests/g2dtest/g2d.h
 create mode 100644 tests/g2dtest/g2d_reg.h
 create mode 100644 tests/g2dtest/g2dtest.c

diff --git a/configure.ac b/configure.ac
index 71a596c..1b51b65 100644
--- a/configure.ac
+++ b/configure.ac
@@ -297,6 +297,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
+   tests/g2dtest/Makefile
include/Makefile
include/drm/Makefile
libdrm.pc])
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
new file mode 100644
index 000..701dbd9
--- /dev/null
+++ b/include/drm/exynos_drm.h
@@ -0,0 +1,185 @@
+/* exynos_drm.h
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * Authors:
+ * Inki Dae 
+ * Joonyoung Shim 
+ * Seung-Woo Kim 
+ *
+ * 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, sublicense,
+ * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS 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.
+ */
+
+#ifndef _EXYNOS_DRM_H_
+#define _EXYNOS_DRM_H_
+
+#include "drm.h"
+
+/**
+ * User-desired buffer creation information structure.
+ *
+ * @size: user-desired memory allocation size.
+ * - this size value would be page-aligned internally.
+ * @flags: user request for setting memory type or cache attributes.
+ * @handle: returned a handle to created gem object.
+ * - this handle will be set by gem module of kernel side.
+ */
+struct drm_exynos_gem_create {
+   uint64_t size;
+   unsigned int flags;
+   unsigned int handle;
+};
+
+/**
+ * A structure for getting buffer offset.
+ *
+ * @handle: a pointer to gem object created.
+ * @pad: just padding to be 64-bit aligned.
+ * @offset: relatived offset value of the memory region allocated.
+ * - this value should be set by user.
+ */
+struct drm_exynos_gem_map_off {
+   unsigned int handle;
+   unsigned int pad;
+   uint64_t offset;
+};
+
+/**
+ * A structure for mapping buffer.
+ *
+ * @handle: a handle to gem object created.
+ * @size: memory size to be mapped.
+ * @mapped: having user virtual address mmaped.
+ * - this variable would be filled by exynos gem module
+ * of kernel side with user virtual address which is allocated
+ * by do_mmap().
+ */
+struct drm_exynos_gem_mmap {
+   unsigned int handle;
+   unsigned int size;
+   uint64_t mapped;
+};
+
+/**
+ * A structure for user connection request of virtual display.
+ *
+ * @connection: indicate whether doing connetion or not by user.
+ * @extensions: if this value is 1 then the vidi driver would need additional
+ * 128bytes edid data.
+ * @pad: just padding to be 64-bit aligned.
+ * @edid: the edid data pointer from user side.
+ */
+struct drm_exynos_vidi_connection {
+   unsigned int connection;
+   unsigned int extensions;
+   unsigned int pad;
+   void *edid;
+};
+
+struct drm_exynos_plane_set_zpos {
+   __u32 crtc_id;
+   __u32 plane_id;
+   __s32 zpos;
+   __u32 pad;
+};
+
+/* memory type definitions. */
+enum e_drm_exynos_gem_mem_type {
+   /* Physically Non-Continuous memory. */
+   EXYNOS_BO_NONCONTIG = 1 << 0
+};
+
+struct drm_exynos_g2d_get_ver {
+   __u32   major;
+   __u32   minor;
+};
+
+struct drm_exynos_g2d_cmd {
+   __u32   offset;
+   __u32   data;
+};
+
+enum drm_exynos_g2d_event_type {
+   G2D_EVENT_NOT,
+   G2D_EVENT_NONSTOP,
+   G2D_EVENT_STOP, /* not yet */
+};
+
+struct drm_exynos_g2d_set_cmdlist {
+

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

Tvrtko Ursulin  changed:

   What|Removed |Added

  Attachment #58555|0   |1
is obsolete||

--- Comment #40 from Tvrtko Ursulin  2012-03-16 
08:09:09 PDT ---
Created attachment 58566
  --> https://bugs.freedesktop.org/attachment.cgi?id=58566
Do not probe extensively if HPD hasn't changed on R600+ ASICs

Made by git format-patch and signed off.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] dma-buf: add get_dma_buf()

From: Rob Clark 

Works in a similar way to get_file(), and is needed in cases such as
when the exporter needs to also keep a reference to the dmabuf (that
is later released with a dma_buf_put()), and possibly other similar
cases.

Signed-off-by: Rob Clark 
---
Minor update on original to add a missing #include

 include/linux/dma-buf.h |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 891457a..bc4203dc 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 

 struct dma_buf;
 struct dma_buf_attachment;
@@ -110,6 +111,20 @@ struct dma_buf_attachment {
void *priv;
 };

+/**
+ * get_dma_buf - convenience wrapper for get_file.
+ * @dmabuf:[in]pointer to dma_buf
+ *
+ * Increments the reference count on the dma-buf, needed in case of drivers
+ * that either need to create additional references to the dmabuf on the
+ * kernel side.  For example, an exporter that needs to keep a dmabuf ptr
+ * so that subsequent exports don't create a new dmabuf.
+ */
+static inline void get_dma_buf(struct dma_buf *dmabuf)
+{
+   get_file(dmabuf->file);
+}
+
 #ifdef CONFIG_DMA_SHARED_BUFFER
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
-- 
1.7.5.4

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #39 from Alex Deucher  2012-03-16 07:46:10 PDT 
---
(In reply to comment #38)
> 
> Magic. :) Thanks, seems to work now.
> 
> What are the chances of upstreaming the two?

Please provide a git patch for your hpd unchanged patch with your
signed-off-by, and I'll send that and the quirk patch upstream.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #38 from Tvrtko Ursulin  2012-03-16 
07:16:44 PDT ---
(In reply to comment #37)
> Created attachment 58556 [details] [review]
> add quirk for fujitsu board
> 
> (In reply to comment #35)
> > Created attachment 58554 [details] [review] [review]
> > Correctly identify connector on Fujitsu D3003-S2 board
> 
> The patch is not quite correct.  You dropped the VGA connect, but did not
> associate the dac with the new DVI-I connector.  I think this patch should fix
> that.  This may be the cause of the problems you were seeing.

Magic. :) Thanks, seems to work now.

What are the chances of upstreaming the two?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47407] System unable to recover from suspend to disk

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

Alex Deucher  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/Gallium/r600|DRM/Radeon

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

Tvrtko Ursulin  changed:

   What|Removed |Added

  Attachment #58481|0   |1
is obsolete||

--- Comment #36 from Tvrtko Ursulin  2012-03-16 
06:57:03 PDT ---
Created attachment 58555
  --> https://bugs.freedesktop.org/attachment.cgi?id=58555
Donot probe extensively if HPD hasn't changed on R600+ ASICs

Now, with these last two patches things should look better for us you think? 

Problem I have now is that with VGA connected to this DVI-I as soon as KMS
kicks in (radeon.ko loads) monitor goes to power save. Even after X is running
and xrandr shows that a mode is active, monitor is still off. This is caused
purely by the Fujitsu quirk patch.

Same symptoms if I boot on DVI and then plug VGA later. Although in this case
it may be a different cause. When I unplug the DVI connector goes into the
"unknown" state. This is because ext_encoder test radeon_atom_dig_detect fails.
And Xorg sees that as "unknown" status but show an active mode while monitor is
firmly in power save.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] RFC: dma-buf: userspace mmap support

On Fri, Mar 16, 2012 at 12:24 PM, Tom Cooksey  wrote:
>
>> From: Rob Clark 
>>
>> Enable optional userspace access to dma-buf buffers via mmap() on the
>> dma-buf file descriptor. ?Userspace access to the buffer should be
>> bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
>> give the exporting driver a chance to deal with cache synchronization
>> and such for cached userspace mappings without resorting to page
>> faulting tricks. ?The reasoning behind this is that, while drm
>> drivers tend to have all the mechanisms in place for dealing with
>> page faulting tricks, other driver subsystems may not. ?And in
>> addition, while page faulting tricks make userspace simpler, there
>> are some associated overheads.
>
> Speaking for the ARM Mali T6xx driver point of view, this API looks
> good for us. Our use-case for mmap is glReadPixels and
> glTex[Sub]Image2D on buffers the driver has imported via dma_buf. In
> the case of glReadPixels, the finish ioctl isn't strictly necessary
> as the CPU won't have written to the buffer and so doesn't need
> flushing. As such, we'd get an additional cache flush which isn't
> really necessary. But hey, it's glReadPixels - it's supposed to be
> slow. :-)
>
> I think requiring the finish ioctl in the API contract is a good
> idea, even if the CPU has only done a ro access as it allows future
> enhancements*. To "fix" the unnecessary flush in glReadPixels, I
> think we'd like to keep the finish but see an "access type"
> parameter added to prepare ioctl indicating if the access is ro or
> rw to allow the cache flush in finish to be skipped if the access
> was ro. As Rebecca says, a debug feature could even be added to
> re-map the pages as ro in prepare(ro) to catch naughty accesses. I'd
> also go as far as to say the debug feature should completely unmap
> the pages after finish too. Though for us, both the access-type
> parameter and debug features are "nice to haves" - we can make
> progress with the code as it currently stands (assuming exporters
> start using the API that is).

Perhaps it isn't a bad idea to include access-type bitmask in the
first version.  It would help optimize a bit the cache operations.

> Something which also came up when discussing internally is the topic
> of mmap APIs of the importing device driver. For example, I believe
> DRM has an mmap API on GEM buffer objects. If a new dma_buf import
> ioctl was added to GEM (maybe the PRIME patches already add this),
> how would GEM's bo mmap API work?

My first thought is maybe we should just dis-allow this for now until
we have a chance to see if there are any possible issues with an
importer mmap'ing the buffer to userspace.  We could possible have a
helper dma_buf_mmap() fxn which in turn calls dmabuf ops->mmap() so
the mmap'ing is actually performed by the exporter on behalf of the
importer.

>
> * Future enhancements: The prepare/finish bracketing could be used
> as part of a wider synchronization scheme with other devices.
> E.g. If another device was writing to the buffer, the prepare ioctl
> could block until that device had finished accessing that buffer.
> In the same way, another device could be blocked from accessing that
> buffer until the client process called finish. We have already
> started playing with such a scheme in the T6xx driver stack we're
> terming "kernel dependency system". In this scheme each buffer has a
> FIFO of "buffer consumers" waiting to access a buffer. The idea
> being that a "buffer consumer" is fairly abstract and could be any
> device or userspace process participating in the synchronization
> scheme. Examples would be GPU jobs, display controller "scan-out"
> jobs, etc.
>
> So for example, a userspace application could dispatch a GPU
> fragment shading job into the GPU's kernel driver which will write
> to a KMS scanout buffer. The application then immediately issues a
> drm_mode_crtc_page_flip ioctl on the display controller's DRM driver
> to display the soon-to-be-rendered buffer. Inside the kernel, the
> GPU driver adds the fragment job to the dma_buf's FIFO. As the FIFO
> was empty, dma_buf calls into the GPU kernel driver to tell it it
> "owns" access to the buffer and the GPU driver schedules the job to
> run on the GPU. Upon receiving the drm_mode_crtc_page_flip ioctl,
> the DRM/KMS driver adds a scan-out job to the buffer's FIFO.
> However, the FIFO already has the GPU's fragment shading job in it
> so nothing happens until the GPU job completes. When the GPU job
> completes, the GPU driver calls into dma_buf to mark its job
> complete. dma_buf then takes the next job in its FIFO which the KMS
> driver's scanout job, calls into the KMS driver to schedule the
> pageflip. The result? A buffer gets scanned out as soon as it has
> finished being rendered without needing a round-trip to userspace.
> Sure, there are easier ways to achieve that goal, but the idea is
> that the mechanism can be used to synchronize access across multiple
>

[PATCH 02/10] drm/exynos: added mode_fixup feature and code clean.

2012-03-16 Thread InKi Dae

Hi Dave.

2012? 3? 15? ?? 8:21, Inki Dae ?? ?:
>> -Original Message-
>> From: Dave Airlie [mailto:airlied at gmail.com]
>> Sent: Thursday, March 15, 2012 7:40 PM
>> To: Inki Dae
>> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>> kyungmin.park at samsung.com; sw0312.kim at samsung.com
>> Subject: Re: [PATCH 02/10] drm/exynos: added mode_fixup feature and code
>> clean.
>>
>> >  };
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> > index de81883..2d9a0e6 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> > @@ -249,7 +249,11 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc,
>> struct drm_display_mode *mode,
>> >  {
>> >DRM_DEBUG_KMS("%s\n", __FILE__);
>> >
>> > -   mode = adjusted_mode;
>> > +   /*
>> > +* copy the mode data adjusted by mode_fixup() into crtc->mode
>> > +* so that hardware can be seet to proper mode.
>> > +*/
>> > +   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>>
>> This just seems wrong on lots of levels, if you get an error how are
>> you going to fallback?
>>
>> You should be passing the modes into the crtc_update function and
>> doing things like other drivers here.
>>
>> Dave.
>

I have looked into the part you pointed out but I think it's ok.
exynos_drm_crtc_update just sets mode values to overlay structure and
overlay structure is common data structure that all hardware can use
and exynos crtc has no hardware defendency so we could use it commoly
for all hardware such as FIMD, HDMI and Virtual Display. so with
exynos_drm_crtc_update call, any hardward isn't updated. if
exynos_drm_crtc_update is fail then adjusted_mode would be released
and back to saved_mode. only if crtc_func->mode_set is true then
hardware would be updated. please let me know if there is my missing
point.

Thanks,
Inki Dae



> Got it. I will check return value from crtc_update and if it gets an error
> then I will handle it properly.
>
> Thanks,
> Inki Dae
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] omap2+: add drm device

2012-03-16 Thread Tomi Valkeinen

On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote:
> On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen  
> wrote:
> > On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
> >
> >> > Well, as I said, it's not an issue for me and from my side it can be
> >> > improved later.
> >>
> >> yeah, when CMA is actually merged, there are a few other things I'd
> >> like to do to, incl converting omapfb over to use CMA and remove
> >> omap_vram.. but I guess those will be other patches.
> >
> > Right, I just realized CMA is not in the kernel, nor does it seem to be
> > in the linux-next. Is there a reason why you want it already merged?
> > Wouldn't it be easier to get it in only when it can actually be used.
> > Especially if there's room for improvement.
> 
> Some folks are already pulling CMA into product kernels for various
> reasons.. keeping this w/ #ifdef CONFIG_CMA guards seemed like it
> would make their life a bit easier.
> 
> But if people feel strongly about it, I can strip that out.

Well, I wouldn't say "feel strongly", but... I think the mainline kernel
should have code only for the mainline kernel, not for some custom
kernels. And the code is not testable in any way, not even compilable. I
think all code going in should be tested and compiled. Also, if the CMA
code is not in, who says it won't change. Perhaps the CMA function won't
even exist in the version going into mainline.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120316/c1ef8aff/attachment.pgp>

[PATCH 3/3] drm/radeon/kms: reduce probe latency on digital connectors

2012-03-16 Thread alexdeuc...@gmail.com

From: Tvrtko Ursulin 

On a system with one HDMI and one VGA connector the latter
causes output polling to run every ten seconds. This causes
full EDID re-fetch on every poll and approx. 100ms rendering
stalls are experienced by full screen page-flipping applications.
Optimisation is to trust HPD sense on R600+ ASICs and to skip
doing these expensive probes unless HPD sense has changed.

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

agd5f: fix patch and message formatting.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_connectors.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index f7d39ac..dfbd391 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -827,6 +827,27 @@ static int radeon_dvi_get_modes(struct drm_connector 
*connector)
return ret;
 }

+static bool radeon_check_hpd_status_unchanged(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct radeon_device *rdev = dev->dev_private;
+   struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
+   enum drm_connector_status status;
+
+   /* We only trust HPD on R600 and newer ASICS. */
+   if (rdev->family >= CHIP_R600
+ && radeon_connector->hpd.hpd != RADEON_HPD_NONE) {
+   if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
+   status = connector_status_connected;
+   else
+   status = connector_status_disconnected;
+   if (connector->status == status)
+   return true;
+   }
+
+   return false;
+}
+
 /*
  * DVI is complicated
  * Do a DDC probe, if DDC probe passes, get the full EDID so
@@ -851,6 +872,9 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false;

+   if (!force && radeon_check_hpd_status_unchanged(connector))
+   return connector->status;
+
if (radeon_connector->ddc_bus)
dret = radeon_ddc_probe(radeon_connector);
if (dret) {
@@ -1245,6 +1269,9 @@ radeon_dp_detect(struct drm_connector *connector, bool 
force)
struct radeon_connector_atom_dig *radeon_dig_connector = 
radeon_connector->con_priv;
struct drm_encoder *encoder = radeon_best_single_encoder(connector);

+   if (!force && radeon_check_hpd_status_unchanged(connector))
+   return connector->status;
+
if (radeon_connector->edid) {
kfree(radeon_connector->edid);
radeon_connector->edid = NULL;
-- 
1.7.7.5

[PATCH 2/3] drm/radeon/kms: add connector quirk for Fujitsu D3003-S2 board

2012-03-16 Thread alexdeuc...@gmail.com

From: Alex Deucher 

vbios lists DVI-I port as VGA and DVI-D.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_atombios.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 85f0b91..239b5c8 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -442,6 +442,20 @@ static bool radeon_atom_apply_quirks(struct drm_device 
*dev,
struct radeon_device *rdev = dev->dev_private;
*i2c_bus = radeon_lookup_i2c_gpio(rdev, 0x93);
}
+
+   /* Fujitsu D3003-S2 board lists DVI-I as DVI-D and VGA */
+   if ((dev->pdev->device == 0x9802) &&
+   (dev->pdev->subsystem_vendor == 0x1734) &&
+   (dev->pdev->subsystem_device == 0x11bd)) {
+   if (*connector_type == DRM_MODE_CONNECTOR_VGA) {
+   *connector_type = DRM_MODE_CONNECTOR_DVII;
+   *line_mux = 0x3103;
+   } else if (*connector_type == DRM_MODE_CONNECTOR_DVID) {
+   *connector_type = DRM_MODE_CONNECTOR_DVII;
+   }
+   }
+
+
return true;
 }

-- 
1.7.7.5

[PATCH 1/3] drm/radeon/kms: fix analog load detection on DVI-I connectors

2012-03-16 Thread alexdeuc...@gmail.com

From: Alex Deucher 

We digital encoders have a detect function as well (for
DP to VGA bridges), so we make sure we choose the analog
one here.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_connectors.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index e7cb3ab..f7d39ac 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -946,6 +946,10 @@ radeon_dvi_detect(struct drm_connector *connector, bool 
force)

encoder = obj_to_encoder(obj);

+   if (encoder->encoder_type != DRM_MODE_ENCODER_DAC ||
+   encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
+   continue;
+
encoder_funcs = encoder->helper_private;
if (encoder_funcs->detect) {
if (ret != connector_status_connected) {
-- 
1.7.7.5

[Bug 47407] System unable to recover from suspend to disk

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

samit vats  changed:

   What|Removed |Added

   Priority|medium  |high

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 25672] System unable to recover from suspend to disk

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

--- Comment #4 from samit vats  2012-03-16 05:13:22 PDT 
---
(In reply to comment #3)
> Created attachment 32118 [details]
> lspci


Re-opening for GalliumR600

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47407] System unable to recover from suspend to disk

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

--- Comment #1 from samit vats  2012-03-16 05:09:38 PDT 
---
Created attachment 58552
  --> https://bugs.freedesktop.org/attachment.cgi?id=58552
Xorg.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47407] New: System unable to recover from suspend to disk

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

 Bug #: 47407
   Summary: System unable to recover from suspend to disk
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: hysvats at gmail.com


Created attachment 58551
  --> https://bugs.freedesktop.org/attachment.cgi?id=58551
dmesg

Driver Stack Details:
=

1)Kernel-3.0.0-12-generice-pae 
2)drm-2.4.31
3)Mesa-8.1-devel (git-5beba3d) 
4)Xorg-server-1.11.4
5)xf86-video-ati- master



System Environment:
===

Asic : M97
O.S. : Ubuntu-11.10 (32 bit)
Processor: AMD Athlon(tm) 64 X2 @ 1 GHz
Memory   : 2 GB  

Steps to Reproduce:
===


1) echo disk > /sys/power/state 
   System suspends to disk and screen goes to blank.

2) Use the wakeup device to wakeup the system


Observation : System unable to recover from suspend to disk using the wake up
===   device

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Marcus Lorentzon

On 03/15/2012 02:32 AM, Rob Clark wrote:
> From: Rob Clark
> [snip]
> In all cases, the mmap() call is allowed to fail, and the associated
> dma_buf_ops are optional (mmap() will fail if at least the mmap()
> op is not implemented by the exporter, but in either case the
> {prepare,finish}_access() ops are optional).
I sort of understand this approach. It allowes some implementations 
(ARM/Android) to move forward. But how would an application act if mmap 
fails? What is the option? How can the application detect if mmap is 
possible or not? Or is this mmap only supposed to be used from device 
specific libs like libdrm-xx/libv4l2-xx/libgralloc?

Can mmap fail for one buffer, but not another? Can it fail for a buffer 
that have successfully been mmapped once before (except for the usual 
ENOMEM/EAGAIN etc)?
> For now the prepare/finish access ioctls are kept simple with no
> argument, although there is possibility to add additional ioctls
> (or simply change the existing ioctls from _IO() to _IOW()) later
> to provide optimization to allow userspace to specify a region of
> interest.
I like the idea of simple, assume the worst, no args, versions of 
begin/end access. But once we move forward, I don't just like the 
region, but also access type (R/W). R/W info allows the driver to make 
cache management optimizations otherwise impossible. Like if CPU with no 
alloc-on-write just write, a write buffer flush is enough to switch to a 
HW read. And (at least on ARM) cache clean can be done for all cache for 
large areas, but invalidate has to be done line by line. Eliminating the 
need to do invalidate, especially if region is small, compared to 
invalidate entire buffer line by line can make a huge difference.
But I would like these in a separate ioctl to keep the normal case 
simple. Maybe as a separate patch even.
>
> For a final patch, dma-buf.h would need to be split into what is
> exported to userspace, and what is kernel private, but I wanted to
> get feedback on the idea of requiring userspace to bracket access
> first (vs. limiting this to coherent mappings or exporters who play
> page faltings plus PTE shoot-down games) before I split the header
> which would cause conflicts with other pending dma-buf patches.  So
> flame-on!
Why not just guard the kernel parts with __KERNEL__ or something? Or 
there are guidelines preventing this?

> [snip]
>
> +
> +static long dma_buf_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct dma_buf *dmabuf;
> +
> + if (!is_dma_buf_file(file))
> + return -EINVAL;
> +
> + dmabuf = file->private_data;
> +
> + switch (_IOC_NR(cmd)) {
> + case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
> + if (dmabuf->ops->prepare_access)
> + return dmabuf->ops->prepare_access(dmabuf);
> + return 0;
> + case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
> + if (dmabuf->ops->finish_access)
> + return dmabuf->ops->finish_access(dmabuf);
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +
Multiple empty lines
>   static int dma_buf_release(struct inode *inode, struct file *file)
>   {
>   struct dma_buf *dmabuf;
> @@ -45,6 +85,8 @@ static int dma_buf_release(struct inode *inode, struct file 
> *file)
>   }
>
>   static const struct file_operations dma_buf_fops = {
> + .mmap   = dma_buf_mmap,
> + .unlocked_ioctl = dma_buf_ioctl,
>   .release= dma_buf_release,
>   };
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index a885b26..cbdff81 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -34,6 +34,17 @@
>   struct dma_buf;
>   struct dma_buf_attachment;
>
> +/* TODO: dma-buf.h should be the userspace visible header, and 
> dma-buf-priv.h (?)
> + * the kernel internal header.. for now just stuff these here to avoid 
> conflicting
> + * with other patches..
> + *
> + * For now, no arg to keep things simple, but we could consider adding an
> + * optional region of interest later.
> + */
> +#define DMA_BUF_IOCTL_PREPARE_ACCESS   _IO('Z', 0)
> +#define DMA_BUF_IOCTL_FINISH_ACCESS_IO('Z', 1)
> +
> +
Multiple empty lines
>   /**
>* struct dma_buf_ops - operations possible on struct dma_buf
>* @attach: [optional] allows different devices to 'attach' themselves to 
> the
> @@ -49,6 +60,13 @@ struct dma_buf_attachment;
>* @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter
>* pages.
>* @release: release this buffer; to be called after the last dma_buf_put.
> + * @mmap: [optional, allowed to fail] operation called if userspace calls
> + *mmap() on the dmabuf fd.  Note that userspace should use the
> + *DMA_BUF_PREPARE_ACCESS / DMA_BUF_FINISH_ACCESS ioctls 
> before/after
> + *sw access to the buffer, to give the exporter an opportunity to
> + *

[PATCH] dma-buf: add get_dma_buf()

From: Rob Clark 

Works in a similar way to get_file(), and is needed in cases such as
when the exporter needs to also keep a reference to the dmabuf (that
is later released with a dma_buf_put()), and possibly other similar
cases.

Signed-off-by: Rob Clark 
---
 include/linux/dma-buf.h |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cbdff81..25eb287 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -132,6 +132,20 @@ struct dma_buf_attachment {
void *priv;
 };

+/**
+ * get_dma_buf - convenience wrapper for get_file.
+ * @dmabuf:[in]pointer to dma_buf
+ *
+ * Increments the reference count on the dma-buf, needed in case of drivers
+ * that either need to create additional references to the dmabuf on the
+ * kernel side.  For example, an exporter that needs to keep a dmabuf ptr
+ * so that subsequent exports don't create a new dmabuf.
+ */
+static inline void get_dma_buf(struct dma_buf *dmabuf)
+{
+   get_file(dmabuf->file);
+}
+
 #ifdef CONFIG_DMA_SHARED_BUFFER
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
-- 
1.7.5.4

expected userspace prime/dma-buf usage

Just wondering how we expect userspace to use dma-buf/prime interfaces.

Currently I see one driver in sharing the buffer with handle->fd, then
passing the fd to the other driver and it using fd->handle, do we then
expect the importing driver to close the fd?

Dave.

[PATCH] dma-buf: pass flags into dma_buf_fd.

From: Dave Airlie 

We need to pass the flags into dma_buf_fd at this point,
so the flags end up doing the right thing for O_CLOEXEC.

Signed-off-by: Dave Airlie 
---
 drivers/base/dma-buf.c  |5 +++--
 include/linux/dma-buf.h |2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c9a945f..3c8c023 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -107,17 +107,18 @@ EXPORT_SYMBOL_GPL(dma_buf_export);
 /**
  * dma_buf_fd - returns a file descriptor for the given dma_buf
  * @dmabuf:[in]pointer to dma_buf for which fd is required.
+ * @flags:  [in]flags to give to fd
  *
  * On success, returns an associated 'fd'. Else, returns error.
  */
-int dma_buf_fd(struct dma_buf *dmabuf)
+int dma_buf_fd(struct dma_buf *dmabuf, int flags)
 {
int error, fd;

if (!dmabuf || !dmabuf->file)
return -EINVAL;

-   error = get_unused_fd();
+   error = get_unused_fd_flags(flags);
if (error < 0)
return error;
fd = error;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a885b26..891457a 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -117,7 +117,7 @@ void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);
 struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
   size_t size, int flags);
-int dma_buf_fd(struct dma_buf *dmabuf);
+int dma_buf_fd(struct dma_buf *dmabuf, int flags);
 struct dma_buf *dma_buf_get(int fd);
 void dma_buf_put(struct dma_buf *dmabuf);

-- 
1.7.6

[PATCH] dma-buf: pass flags into dma_buf_fd.

On Fri, Mar 16, 2012 at 5:34 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> We need to pass the flags into dma_buf_fd at this point,
> so the flags end up doing the right thing for O_CLOEXEC.
>
> Signed-off-by: Dave Airlie 

Signed-off-by: Rob Clark 

> ---
> ?drivers/base/dma-buf.c ?| ? ?5 +++--
> ?include/linux/dma-buf.h | ? ?2 +-
> ?2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index c9a945f..3c8c023 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -107,17 +107,18 @@ EXPORT_SYMBOL_GPL(dma_buf_export);
> ?/**
> ?* dma_buf_fd - returns a file descriptor for the given dma_buf
> ?* @dmabuf: ? ?[in] ? ?pointer to dma_buf for which fd is required.
> + * @flags: ? ? ?[in] ? ?flags to give to fd
> ?*
> ?* On success, returns an associated 'fd'. Else, returns error.
> ?*/
> -int dma_buf_fd(struct dma_buf *dmabuf)
> +int dma_buf_fd(struct dma_buf *dmabuf, int flags)
> ?{
> ? ? ? ?int error, fd;
>
> ? ? ? ?if (!dmabuf || !dmabuf->file)
> ? ? ? ? ? ? ? ?return -EINVAL;
>
> - ? ? ? error = get_unused_fd();
> + ? ? ? error = get_unused_fd_flags(flags);
> ? ? ? ?if (error < 0)
> ? ? ? ? ? ? ? ?return error;
> ? ? ? ?fd = error;
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index a885b26..891457a 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -117,7 +117,7 @@ void dma_buf_detach(struct dma_buf *dmabuf,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct dma_buf_attachment *dmabuf_attach);
> ?struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? size_t size, int flags);
> -int dma_buf_fd(struct dma_buf *dmabuf);
> +int dma_buf_fd(struct dma_buf *dmabuf, int flags);
> ?struct dma_buf *dma_buf_get(int fd);
> ?void dma_buf_put(struct dma_buf *dmabuf);
>
> --
> 1.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: enable hdmi audio feature

2012-03-16 Thread Seung-Woo Kim

This patch adds hdmi audio feature for exynos drm.
With this patch, i2s channel feeds audio data in hdmi when hdmi is connected.

This patch is for drm-next branch and the base of this patch is patch set from
Joonyoung Shim, "[PATCH 2/2] drm/exynos: cleanup exynos_hdmi.h".
link:
http://www.spinics.net/lists/dri-devel/msg19939.html

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |  167 +++
 drivers/gpu/drm/exynos/regs-hdmi.h   |  182 ++
 2 files changed, 349 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3583a7b..575a8cb 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1319,6 +1319,169 @@ static struct exynos_hdmi_display_ops display_ops = {
.power_on   = hdmi_display_power_on,
 };

+static void hdmi_set_acr(u32 freq, u8 *acr)
+{
+   u32 n, cts;
+
+   switch (freq) {
+   case 32000:
+   n = 4096;
+   cts = 27000;
+   break;
+   case 44100:
+   n = 6272;
+   cts = 3;
+   break;
+   case 88200:
+   n = 12544;
+   cts = 3;
+   break;
+   case 176400:
+   n = 25088;
+   cts = 3;
+   break;
+   case 48000:
+   n = 6144;
+   cts = 27000;
+   break;
+   case 96000:
+   n = 12288;
+   cts = 27000;
+   break;
+   case 192000:
+   n = 24576;
+   cts = 27000;
+   break;
+   default:
+   n = 0;
+   cts = 0;
+   break;
+   }
+
+   acr[1] = cts >> 16;
+   acr[2] = cts >> 8 & 0xff;
+   acr[3] = cts & 0xff;
+
+   acr[4] = n >> 16;
+   acr[5] = n >> 8 & 0xff;
+   acr[6] = n & 0xff;
+}
+
+static void hdmi_reg_acr(struct hdmi_context *hdata, u8 *acr)
+{
+   hdmi_reg_writeb(hdata, HDMI_ACR_N0, acr[6]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_N1, acr[5]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_N2, acr[4]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_MCTS0, acr[3]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_MCTS1, acr[2]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_MCTS2, acr[1]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_CTS0, acr[3]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_CTS1, acr[2]);
+   hdmi_reg_writeb(hdata, HDMI_ACR_CTS2, acr[1]);
+
+   if (hdata->is_v13)
+   hdmi_reg_writeb(hdata, HDMI_V13_ACR_CON, 4);
+   else
+   hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
+}
+
+static void hdmi_audio_init(struct hdmi_context *hdata)
+{
+   u32 sample_rate, bits_per_sample, frame_size_code;
+   u32 data_num, bit_ch, sample_frq;
+   u32 val;
+   u8 acr[7];
+
+   sample_rate = 44100;
+   bits_per_sample = 16;
+   frame_size_code = 0;
+
+   switch (bits_per_sample) {
+   case 20:
+   data_num = 2;
+   bit_ch  = 1;
+   break;
+   case 24:
+   data_num = 3;
+   bit_ch  = 1;
+   break;
+   default:
+   data_num = 1;
+   bit_ch  = 0;
+   break;
+   }
+
+   hdmi_set_acr(sample_rate, acr);
+   hdmi_reg_acr(hdata, acr);
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CON, HDMI_I2S_IN_DISABLE
+   | HDMI_I2S_AUD_I2S | HDMI_I2S_CUV_I2S_ENABLE
+   | HDMI_I2S_MUX_ENABLE);
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CH, HDMI_I2S_CH0_EN
+   | HDMI_I2S_CH1_EN | HDMI_I2S_CH2_EN);
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_MUX_CUV, HDMI_I2S_CUV_RL_EN);
+
+   sample_frq = (sample_rate == 44100) ? 0 :
+   (sample_rate == 48000) ? 2 :
+   (sample_rate == 32000) ? 3 :
+   (sample_rate == 96000) ? 0xa : 0x0;
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_CLK_CON, HDMI_I2S_CLK_DIS);
+   hdmi_reg_writeb(hdata, HDMI_I2S_CLK_CON, HDMI_I2S_CLK_EN);
+
+   val = hdmi_reg_read(hdata, HDMI_I2S_DSD_CON) | 0x01;
+   hdmi_reg_writeb(hdata, HDMI_I2S_DSD_CON, val);
+
+   /* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
+   | HDMI_I2S_SEL_LRCK(6));
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
+   | HDMI_I2S_SEL_SDATA2(4));
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_2, HDMI_I2S_SEL_SDATA3(1)
+   | HDMI_I2S_SEL_SDATA2(2));
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_3, HDMI_I2S_SEL_DSD(0));
+
+   /* I2S_CON_1 & 2 */
+   hdmi_reg_writeb(hdata, HDMI_I2S_CON_1, HDMI_I2S_SCLK_FALLING_EDGE
+

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

On Fri, Mar 16, 2012 at 5:50 AM, Marcus Lorentzon
 wrote:
> On 03/15/2012 02:32 AM, Rob Clark wrote:
>>
>> From: Rob Clark
>> [snip]
>>
>> In all cases, the mmap() call is allowed to fail, and the associated
>> dma_buf_ops are optional (mmap() will fail if at least the mmap()
>> op is not implemented by the exporter, but in either case the
>> {prepare,finish}_access() ops are optional).
>
> I sort of understand this approach. It allowes some implementations
> (ARM/Android) to move forward. But how would an application act if mmap
> fails? What is the option? How can the application detect if mmap is
> possible or not? Or is this mmap only supposed to be used from device
> specific libs like libdrm-xx/libv4l2-xx/libgralloc?

The most sane fail path probably depends on the use case.  For
example, if you have some code that is writing subtitle overlay into
frames of video, then the fallback that makes sense is probably just
to skip the buffer.  In other cases, showing error message and exiting
gracefully might be what makes sense.

I expect it is most likely that a particular exporting device will
either support mmap or not.  But I expect there would at least some
special cases, for example in product kernels with secure/protected
content.

> Can mmap fail for one buffer, but not another? Can it fail for a buffer that
> have successfully been mmapped once before (except for the usual
> ENOMEM/EAGAIN etc)?

well, this is always possible regardless, for example if client
process virtual address space is exhausted.

>> For now the prepare/finish access ioctls are kept simple with no
>> argument, although there is possibility to add additional ioctls
>> (or simply change the existing ioctls from _IO() to _IOW()) later
>> to provide optimization to allow userspace to specify a region of
>> interest.
>
> I like the idea of simple, assume the worst, no args, versions of begin/end
> access. But once we move forward, I don't just like the region, but also
> access type (R/W). R/W info allows the driver to make cache management
> optimizations otherwise impossible. Like if CPU with no alloc-on-write just
> write, a write buffer flush is enough to switch to a HW read. And (at least
> on ARM) cache clean can be done for all cache for large areas, but
> invalidate has to be done line by line. Eliminating the need to do
> invalidate, especially if region is small, compared to invalidate entire
> buffer line by line can make a huge difference.
> But I would like these in a separate ioctl to keep the normal case simple.
> Maybe as a separate patch even.

yeah, I expect that there will be some proposals and discussions about
that, so I wanted to get basic support in first :-)

>>
>> For a final patch, dma-buf.h would need to be split into what is
>> exported to userspace, and what is kernel private, but I wanted to
>> get feedback on the idea of requiring userspace to bracket access
>> first (vs. limiting this to coherent mappings or exporters who play
>> page faltings plus PTE shoot-down games) before I split the header
>> which would cause conflicts with other pending dma-buf patches. ?So
>> flame-on!
>
> Why not just guard the kernel parts with __KERNEL__ or something? Or there
> are guidelines preventing this?

I think that is at least not how things are normally done, and seems a bit ugly

BR,
-R

>> [snip]
>>
>>
>> +
>> +static long dma_buf_ioctl(struct file *file, unsigned int cmd,
>> + ? ? ? ? ? ? ? unsigned long arg)
>> +{
>> + ? ? ? struct dma_buf *dmabuf;
>> +
>> + ? ? ? if (!is_dma_buf_file(file))
>> + ? ? ? ? ? ? ? return -EINVAL;
>> +
>> + ? ? ? dmabuf = file->private_data;
>> +
>> + ? ? ? switch (_IOC_NR(cmd)) {
>> + ? ? ? case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
>> + ? ? ? ? ? ? ? if (dmabuf->ops->prepare_access)
>> + ? ? ? ? ? ? ? ? ? ? ? return dmabuf->ops->prepare_access(dmabuf);
>> + ? ? ? ? ? ? ? return 0;
>> + ? ? ? case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
>> + ? ? ? ? ? ? ? if (dmabuf->ops->finish_access)
>> + ? ? ? ? ? ? ? ? ? ? ? return dmabuf->ops->finish_access(dmabuf);
>> + ? ? ? ? ? ? ? return 0;
>> + ? ? ? default:
>> + ? ? ? ? ? ? ? return -EINVAL;
>> + ? ? ? }
>> +}
>> +
>> +
>
> Multiple empty lines
>
>> ?static int dma_buf_release(struct inode *inode, struct file *file)
>> ?{
>> ? ? ? ?struct dma_buf *dmabuf;
>> @@ -45,6 +85,8 @@ static int dma_buf_release(struct inode *inode, struct
>> file *file)
>> ?}
>>
>> ?static const struct file_operations dma_buf_fops = {
>> + ? ? ? .mmap ? ? ? ? ? = dma_buf_mmap,
>> + ? ? ? .unlocked_ioctl = dma_buf_ioctl,
>> ? ? ? ?.release ? ? ? ?= dma_buf_release,
>> ?};
>>
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index a885b26..cbdff81 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -34,6 +34,17 @@
>> ?struct dma_buf;
>> ?struct dma_buf_attachment;
>>
>> +/* TODO: dma-buf.h should be the userspace visible header, and
>> dma-buf-priv.h (?)
>> + * the kernel internal header.. for now just stuff these

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

2012-03-16 Thread Linus Torvalds

Guys,
 I don't know if these kinds of things have been forwarded to you, but
there's apparently been several things like this going on - with the
finger pointing to the i915 driver apparently clearing random memory.
Often the end result seems to be list corruption or a NULL pointer
dereference in the filesystem layer.

 Linus

-- Forwarded message --
From: Jiri Kosina 
Date: Fri, Mar 16, 2012 at 8:25 AM
Subject: Re: Oops in ext3_block_to_path.isra.40+0x26/0x11b
To: George Spelvin 
Cc: jack at suse.cz, linux-ext4 at vger.kernel.org,
linux-kernel at vger.kernel.org, torvalds at linux-foundation.org

On Fri, 16 Mar 2012, George Spelvin wrote:

> > I am not aware of anything, but I have a question -- George, did the
> > machine get suspended/resumed before this happened?
>
> I'm pretty sure it didn't. ?It's a desktop machine, and I don't ever
> suspend it. ?It had been up for a while, and /sys/power/state exists, and
> *maybe* I played with it sometime since boot, but the backup runs nightly
> and I *definitely* did not suspend it the day (or even several days)
> before the oops.
>
> (I tried to preserve the machine state, but processes started getting
> stuck in the kernel a few hours after the report, so I had to reboot it.)
>
> Jan Kara asked:
> > ? And by any chance, do you use i915 driver? Because that one seems to
> > cause corruption - see: https://lkml.org/lkml/2012/3/9/217. I believe
> > Jiri's corruption is likely caused by that...
>
> Yes! ?lspci -nn and abbreviated .config attached. ?But, as mentioned, the 
> machine
> hasn't been suspended...

So it might be the culprit. As the reason of the corruption is not yet
understood, it might be that suspend/resume cycle is not necessary
pre-requisite for this to trigger, it might just make it more likely.

And the corruption is observed to be indeed several writes of 0x,
so it could easily lead to null pointer dereferences all over the place.

Are you able to reproduce the problem if you turn kernel modesetting off?

--
Jiri Kosina
SUSE Labs

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #33 from Tvrtko Ursulin  2012-03-16 
01:47:31 PDT ---
(In reply to comment #32)
> (In reply to comment #31)
> > It is a single DVI-I physically.
> > 
> > But even identifying it would not change anything with regards to polling
> > induced rendering stalls, right? 
> > 
> 
> Well, shared_ddc wouldn't apply in that case since there is only one 
> connector,
> and for better or worse we wouldn't be polling since the connector does have 
> an
> HPD pin (even if it doesn't necessarily work reliably with the analog part of 
> a
> DVI-I connector).  So fixing that would avoid the polling stalls on your
> particular board.

Ok, I misunderstood would would happen after applying this quirk. I though we
would still have three connectors, just that DVI-D would become DVI-I. In fact
what should happen is that DVI-D becomes DVI-I and VGA vbios entry is ignored
for this board?

Is this something which can be done in radeon_atom_apply_quirks? I'll give it a
go.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

expected userspace prime/dma-buf usage

On Fri, Mar 16, 2012 at 8:22 AM, Rob Clark  wrote:
> On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie  wrote:
>> Just wondering how we expect userspace to use dma-buf/prime interfaces.
>>
>> Currently I see one driver in sharing the buffer with handle->fd, then
>> passing the fd to the other driver and it using fd->handle, do we then
>> expect the importing driver to close the fd?
>
> Importing driver should:
>
> ?dbuf = dma_buf_get(fd);
> ?... store the 'struct dma_buf *' for however long is needed.. this holds
> ? ? ?a ref to the 'struct file' that backs the dma-buf.. and then when no
> ? ? ?longer needed:
> ?dma_buf_put(dbuf);
>
> think of dma_buf_get()/dma_buf_put() as basically similar to
> fget()/fput().. the fget() would either atomically succeed (if the
> file descriptor was still valid) and increment the ref count, or fail.
> ?The fput() would decrement the refcnt. ?The last fput() triggers
> ->release() (which then in turn decrements the ref count of the
> original gem buffer object, etc).

oh, and userspace would close the fd when it no longer needs it..  in
case of prime, once you've done fd->handle, how the handle holds a ref
to the imported buffer so you can close the fd.

Other subsystems, it may be different.. if you're repeatedly passing
the fd into the driver each time you use the buffer (ie. no gem handle
or similar) then userspace would need to keep the fd open so they have
it to pass back in to the driver the each time.. v4l2 is working this
way

BR,
-R

expected userspace prime/dma-buf usage

On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie  wrote:
> Just wondering how we expect userspace to use dma-buf/prime interfaces.
>
> Currently I see one driver in sharing the buffer with handle->fd, then
> passing the fd to the other driver and it using fd->handle, do we then
> expect the importing driver to close the fd?

Importing driver should:

  dbuf = dma_buf_get(fd);
  ... store the 'struct dma_buf *' for however long is needed.. this holds
  a ref to the 'struct file' that backs the dma-buf.. and then when no
  longer needed:
  dma_buf_put(dbuf);

think of dma_buf_get()/dma_buf_put() as basically similar to
fget()/fput().. the fget() would either atomically succeed (if the
file descriptor was still valid) and increment the ref count, or fail.
 The fput() would decrement the refcnt.  The last fput() triggers
->release() (which then in turn decrements the ref count of the
original gem buffer object, etc).

BR,
-R

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

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #34 from Tvrtko Ursulin  2012-03-16 
03:54:47 UTC ---
(In reply to comment #32)
> (In reply to comment #31)
> > It is a single DVI-I physically.
> > 
> > But even identifying it would not change anything with regards to polling
> > induced rendering stalls, right? 
> > 
> 
> Well, shared_ddc wouldn't apply in that case since there is only one 
> connector,
> and for better or worse we wouldn't be polling since the connector does have 
> an
> HPD pin (even if it doesn't necessarily work reliably with the analog part of 
> a
> DVI-I connector).  So fixing that would avoid the polling stalls on your
> particular board.

Now I know how to do the quirk to make only DVI-I appear instead of DVI-D and
VGA, however obvious limitation here is that:
 a) use cases from #18 are broken
 b) code seems to be buggy in bringing up even HPD enabled connectors anyway

Consider this for the latter:

* DVI monitor connected to DVI-I
* Unplug the cable
* HPD interrupt happens
* radeon_dvi_detect called
* DDC probe fails
* connector marked as disconnected
* output_poll_changed called,
* drm_helper_probe_single_connector_modes
* radeon_dvi_detect called again with force=true
* DAC load detect puts the connector in unknown status
* poll scheduled for ten seconds later
* ten seconds later radeon_dvi_detect called
* ddc probe fails
* connector still in unknown state
* Now plug the cable back in
* HPD irq fires
* radeon_dvi_detect called
* DDC is not ready yet for some reason and probe fails (I get this a lot)
* monitor still in unknown status
* end of story, no display

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42611] [865g] webgl enabled pages crash Firefox and mesa

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

--- Comment #8 from Cesare Leonardi  2012-03-15 17:40:15 
PDT ---
With the latest Firefox from Debian (Iceweasel 10.0.3esr-1), the problem looks
resolved: no more crashes for me. The fix is documented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=696636
https://bugzilla.mozilla.org/show_bug.cgi?id=728656

And for the record, no problems with Mesa 8.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [PATCH 09/10] drm/exynos: add G2D driver

2012-03-16 Thread Joonyoung Shim


On 03/15/2012 07:50 PM, Dave Airlie wrote:

G2D is a 2D graphic accelerator that supports Bit Block Transfer. This
G2D driver is exynos drm specific and supports only exynos4x12 series.
user application fills command set in cmdlist and once dma start request
these cmdlists are parsed and performed by dma.

Where is this block documented or a pointer to the corresponding open
userspace user code?


I attach simple g2dtest program patch. The base of this patch is master
branch of lastest libdrm git.

This user progrem can test just solid color fill example.
I will cleanup and update it for more operations later.

Thanks.


Again the ioctls look like they need to be depointered and use __u64.

It would be nice if you could document how the command stream and engine work.

How does userspace pass addresses to it? straight or via gem objects?
how does it
stop userspace blt to places it shouldn't etc.

I'm getting the feeling this accel enabled driver needs a lot more of
a commit message
and lot more documentation on what it can be used for.

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



From 845c0a1bbf67b342099c5eae6f573063af8fc023 Mon Sep 17 00:00:00 2001
From: Joonyoung Shim jy0922.s...@samsung.com
Date: Fri, 16 Mar 2012 15:13:45 +0900
Subject: [PATCH] Add simple g2dtest

This can test only solid color fill.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 configure.ac  |1 +
 include/drm/exynos_drm.h  |  185 ++
 tests/Makefile.am |2 +-
 tests/g2dtest/Makefile.am |   16 ++
 tests/g2dtest/g2d.h   |   64 +
 tests/g2dtest/g2d_reg.h   |  108 
 tests/g2dtest/g2dtest.c   |  612 +
 7 files changed, 987 insertions(+), 1 deletions(-)
 create mode 100644 include/drm/exynos_drm.h
 create mode 100644 tests/g2dtest/Makefile.am
 create mode 100644 tests/g2dtest/g2d.h
 create mode 100644 tests/g2dtest/g2d_reg.h
 create mode 100644 tests/g2dtest/g2dtest.c

diff --git a/configure.ac b/configure.ac
index 71a596c..1b51b65 100644
--- a/configure.ac
+++ b/configure.ac
@@ -297,6 +297,7 @@ AC_CONFIG_FILES([
 	tests/kmstest/Makefile
 	tests/radeon/Makefile
 	tests/vbltest/Makefile
+	tests/g2dtest/Makefile
 	include/Makefile
 	include/drm/Makefile
 	libdrm.pc])
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
new file mode 100644
index 000..701dbd9
--- /dev/null
+++ b/include/drm/exynos_drm.h
@@ -0,0 +1,185 @@
+/* exynos_drm.h
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * Authors:
+ *	Inki Dae inki@samsung.com
+ *	Joonyoung Shim jy0922.s...@samsung.com
+ *	Seung-Woo Kim sw0312@samsung.com
+ *
+ * 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, sublicense,
+ * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS 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.
+ */
+
+#ifndef _EXYNOS_DRM_H_
+#define _EXYNOS_DRM_H_
+
+#include drm.h
+
+/**
+ * User-desired buffer creation information structure.
+ *
+ * @size: user-desired memory allocation size.
+ *	- this size value would be page-aligned internally.
+ * @flags: user request for setting memory type or cache attributes.
+ * @handle: returned a handle to created gem object.
+ *	- this handle will be set by gem module of kernel side.
+ */
+struct drm_exynos_gem_create {
+	uint64_t size;
+	unsigned int flags;
+	unsigned int handle;
+};
+
+/**
+ * A structure for getting buffer offset.
+ *
+ * @handle: a pointer to gem object created.
+ * @pad: just padding to be 64-bit aligned.
+ * @offset: relatived offset value of the memory region allocated.
+ *	- this value should be set by user.
+ */
+struct drm_exynos_gem_map_off {
+	unsigned int handle;
+	unsigned int pad;
+	uint64_t offset;
+};
+
+/**
+ * A structure for mapping buffer.
+ *
+ * @handle: a handle to gem object created.
+ * @size: memory size to be mapped.
+ * @mapped: having user virtual address mmaped.
+ *	- this variable

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Rebecca Schultz Zavin

This looks perfect to me and will close really the last remaining blocking
issue for converting ion to be a dma-buf exporter.  Assuming there are no
major objections to this I'll post some patches to the list next week that
make that change to ion.  Looking forward to meeting in the middle on this!
 Thanks Rob!

I'm happy with the bracketing calls as well.  We've been discussing a
similar api to ion to manage the caches.  It'll allow us to enable debug
features like remapping the buffers read only when a process says it's
finished with them to catch cache offenders.

Rebecca

On Thu, Mar 15, 2012 at 5:27 AM, Rob Clark rob.cl...@linaro.org wrote:

 On Thu, Mar 15, 2012 at 2:16 AM, Abhinav Kochhar
 kochhar.abhi...@gmail.com wrote:
  do we need to pass the dmabuf object to dmabuf-ops-mmap(dmabuf, file,
  vma)?
 
  as file-private_data can retrieve the dmabuf object.
 
  dmabuf = file-private_data
 
  removing dmabuf from the function arguments will keep it consistent with
  basic mmap definitions:
 
  static int _mmap(struct file *file, struct vm_area_struct *vma)
 

 This was intentional to deviate from standard mmap fxn signature..  it
 was to avoid encouraging incorrect use.

 What I mean is, most subsystems interested in participating in dmabuf
 support mmap'ing multiple buffers on a single chrdev, with some
 offset-object mapping mechanism.  But in the case of a dmabuf fd, the
 buffer userspace would mmap would be at offset=0.  So you wouldn't get
 the expected results if you just directly plugged v4l2_mmap or
 drm_gem_mmap, etc, into your dmabuf-ops.  Not to mention the
 file-file_private wouldn't be what you expected.  So basically I was
 just trying to follow principle-of-least-surprise ;-)

 BR,
 -R

  On Thu, Mar 15, 2012 at 10:32 AM, Rob Clark rob.cl...@linaro.org
 wrote:
 
  From: Rob Clark r...@ti.com
 
  Enable optional userspace access to dma-buf buffers via mmap() on the
  dma-buf file descriptor.  Userspace access to the buffer should be
  bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
  give the exporting driver a chance to deal with cache synchronization
  and such for cached userspace mappings without resorting to page
  faulting tricks.  The reasoning behind this is that, while drm
  drivers tend to have all the mechanisms in place for dealing with
  page faulting tricks, other driver subsystems may not.  And in
  addition, while page faulting tricks make userspace simpler, there
  are some associated overheads.
 
  In all cases, the mmap() call is allowed to fail, and the associated
  dma_buf_ops are optional (mmap() will fail if at least the mmap()
  op is not implemented by the exporter, but in either case the
  {prepare,finish}_access() ops are optional).
 
  For now the prepare/finish access ioctls are kept simple with no
  argument, although there is possibility to add additional ioctls
  (or simply change the existing ioctls from _IO() to _IOW()) later
  to provide optimization to allow userspace to specify a region of
  interest.
 
  For a final patch, dma-buf.h would need to be split into what is
  exported to userspace, and what is kernel private, but I wanted to
  get feedback on the idea of requiring userspace to bracket access
  first (vs. limiting this to coherent mappings or exporters who play
  page faltings plus PTE shoot-down games) before I split the header
  which would cause conflicts with other pending dma-buf patches.  So
  flame-on!
  ---
   drivers/base/dma-buf.c  |   42
 ++
   include/linux/dma-buf.h |   22 ++
   2 files changed, 64 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
  index c9a945f..382b78a 100644
  --- a/drivers/base/dma-buf.c
  +++ b/drivers/base/dma-buf.c
  @@ -30,6 +30,46 @@
 
   static inline int is_dma_buf_file(struct file *);
 
  +static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
  +{
  +   struct dma_buf *dmabuf;
  +
  +   if (!is_dma_buf_file(file))
  +   return -EINVAL;
  +
  +   dmabuf = file-private_data;
  +
  +   if (dmabuf-ops-mmap)
  +   return dmabuf-ops-mmap(dmabuf, file, vma);
  +
  +   return -ENODEV;
  +}
  +
  +static long dma_buf_ioctl(struct file *file, unsigned int cmd,
  +   unsigned long arg)
  +{
  +   struct dma_buf *dmabuf;
  +
  +   if (!is_dma_buf_file(file))
  +   return -EINVAL;
  +
  +   dmabuf = file-private_data;
  +
  +   switch (_IOC_NR(cmd)) {
  +   case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
  +   if (dmabuf-ops-prepare_access)
  +   return dmabuf-ops-prepare_access(dmabuf);
  +   return 0;
  +   case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
  +   if (dmabuf-ops-finish_access)
  +   return dmabuf-ops-finish_access(dmabuf);
  +   return 0;
  +   default:
  +   return

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Rebecca Schultz Zavin

This looks perfect to me and will close really the last remaining blocking
issue for converting ion to be a dma-buf exporter.  Assuming there are no
major objections to this I'll post some patches to the list next week that
make that change to ion.  Looking forward to meeting in the middle on this!
 Thanks Rob!

I'm happy with the bracketing calls as well.  We've been discussing a
similar api to ion to manage the caches.  It'll allow us to enable debug
features like remapping the buffers read only when a process says it's
finished with them to catch cache offenders.

Rebecca

On Thu, Mar 15, 2012 at 5:27 AM, Rob Clark rob.cl...@linaro.org wrote:

 On Thu, Mar 15, 2012 at 2:16 AM, Abhinav Kochhar
 kochhar.abhi...@gmail.com wrote:
  do we need to pass the dmabuf object to dmabuf-ops-mmap(dmabuf, file,
  vma)?
 
  as file-private_data can retrieve the dmabuf object.
 
  dmabuf = file-private_data
 
  removing dmabuf from the function arguments will keep it consistent with
  basic mmap definitions:
 
  static int _mmap(struct file *file, struct vm_area_struct *vma)
 

 This was intentional to deviate from standard mmap fxn signature..  it
 was to avoid encouraging incorrect use.

 What I mean is, most subsystems interested in participating in dmabuf
 support mmap'ing multiple buffers on a single chrdev, with some
 offset-object mapping mechanism.  But in the case of a dmabuf fd, the
 buffer userspace would mmap would be at offset=0.  So you wouldn't get
 the expected results if you just directly plugged v4l2_mmap or
 drm_gem_mmap, etc, into your dmabuf-ops.  Not to mention the
 file-file_private wouldn't be what you expected.  So basically I was
 just trying to follow principle-of-least-surprise ;-)

 BR,
 -R

  On Thu, Mar 15, 2012 at 10:32 AM, Rob Clark rob.cl...@linaro.org
 wrote:
 
  From: Rob Clark r...@ti.com
 
  Enable optional userspace access to dma-buf buffers via mmap() on the
  dma-buf file descriptor.  Userspace access to the buffer should be
  bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to
  give the exporting driver a chance to deal with cache synchronization
  and such for cached userspace mappings without resorting to page
  faulting tricks.  The reasoning behind this is that, while drm
  drivers tend to have all the mechanisms in place for dealing with
  page faulting tricks, other driver subsystems may not.  And in
  addition, while page faulting tricks make userspace simpler, there
  are some associated overheads.
 
  In all cases, the mmap() call is allowed to fail, and the associated
  dma_buf_ops are optional (mmap() will fail if at least the mmap()
  op is not implemented by the exporter, but in either case the
  {prepare,finish}_access() ops are optional).
 
  For now the prepare/finish access ioctls are kept simple with no
  argument, although there is possibility to add additional ioctls
  (or simply change the existing ioctls from _IO() to _IOW()) later
  to provide optimization to allow userspace to specify a region of
  interest.
 
  For a final patch, dma-buf.h would need to be split into what is
  exported to userspace, and what is kernel private, but I wanted to
  get feedback on the idea of requiring userspace to bracket access
  first (vs. limiting this to coherent mappings or exporters who play
  page faltings plus PTE shoot-down games) before I split the header
  which would cause conflicts with other pending dma-buf patches.  So
  flame-on!
  ---
   drivers/base/dma-buf.c  |   42
 ++
   include/linux/dma-buf.h |   22 ++
   2 files changed, 64 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
  index c9a945f..382b78a 100644
  --- a/drivers/base/dma-buf.c
  +++ b/drivers/base/dma-buf.c
  @@ -30,6 +30,46 @@
 
   static inline int is_dma_buf_file(struct file *);
 
  +static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
  +{
  +   struct dma_buf *dmabuf;
  +
  +   if (!is_dma_buf_file(file))
  +   return -EINVAL;
  +
  +   dmabuf = file-private_data;
  +
  +   if (dmabuf-ops-mmap)
  +   return dmabuf-ops-mmap(dmabuf, file, vma);
  +
  +   return -ENODEV;
  +}
  +
  +static long dma_buf_ioctl(struct file *file, unsigned int cmd,
  +   unsigned long arg)
  +{
  +   struct dma_buf *dmabuf;
  +
  +   if (!is_dma_buf_file(file))
  +   return -EINVAL;
  +
  +   dmabuf = file-private_data;
  +
  +   switch (_IOC_NR(cmd)) {
  +   case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
  +   if (dmabuf-ops-prepare_access)
  +   return dmabuf-ops-prepare_access(dmabuf);
  +   return 0;
  +   case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
  +   if (dmabuf-ops-finish_access)
  +   return dmabuf-ops-finish_access(dmabuf);
  +   return 0;
  +   default:
  +   return

Re: i2c handling in nouveau driver

2012-03-16 Thread Jean Delvare

Hi Ben,

I'm sorry for the very very late reply. Please do not jump to the 
conclusion that I do not care - I do! Just I am very busy, just as you.

On Wednesday 11 January 2012 01:40:58 pm Ben Skeggs wrote:
 On Wed, 2012-01-11 at 11:17 +0100, Jean Delvare wrote:
  In the commit message, you complain about the use of cond_resched()
  in i2c-algo-bit. You might as well be right, maybe it should be
  removed. It's been there pretty much forever (February 2002 at
  least) and while I can understand why it was put there, I would
  agree it isn't necessarily a good idea. Did you try removing it to
  see if it solved your problem?
 
 I don't disagree, and I held off a long time before finally
  committing it to the nouveau repository due to not liking the
  duplication.  My final decision to do it was admittedly due to
  having very very limited time and a *lot* of other things to work
  on.  And this solution worked now.
 
 The fact i2c-algo-bit can't be used from an atomic context was
  probably a convenient excuse I guess, but I did also figure there
  were good reasons for it and there'd likely be push-back at
  attempting to change that.  Again, due to having loads of other
  things to do, I took the quick approach.

I don't think there actually is any good reason, and not only I wouldn't 
push back if someone wants to get rid of the call to cond_resched(), but 
I would even push for it to happen ;)

Now the question is, what do we replace it with? Nothing? cpu_relax()? 
yield()? udelay(small value)?

I guess yield() would have the same property of making the code not 
callable from atomic context. Not having anything might be harsh from a 
CPU and I/O load perspective, as it would be a tight loop lasting for 
several milliseconds. So this leaves us with cpu_relax() and udelay(). 
Any preference?

 (...)
 I'd be more than happy to have these issues (nvs300 and running from
  an atomic context) solved in i2c-algo-bit, and will gladly revert
  the nouveau changes once it is.  Let me know how I can help you with
  that.

Incidentally I just sent a fix upstream for a bug reported by Ville 
Syrjälä in i2c-algo-bit, that would cause spurious timeouts on heavy CPU 
load. I am curious if it would have helped in your case. Please take a 
look:

http://marc.info/?l=linux-kernelm=133182203301053w=2

And if you think it could help, I would appreciate if you could give it 
a try with the nouveau driver and see if it actually does.

Thanks,
-- 
Jean Delvare
Suse L3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #33 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-16 
01:47:31 PDT ---
(In reply to comment #32)
 (In reply to comment #31)
  It is a single DVI-I physically.
  
  But even identifying it would not change anything with regards to polling
  induced rendering stalls, right? 
  
 
 Well, shared_ddc wouldn't apply in that case since there is only one 
 connector,
 and for better or worse we wouldn't be polling since the connector does have 
 an
 HPD pin (even if it doesn't necessarily work reliably with the analog part of 
 a
 DVI-I connector).  So fixing that would avoid the polling stalls on your
 particular board.

Ok, I misunderstood would would happen after applying this quirk. I though we
would still have three connectors, just that DVI-D would become DVI-I. In fact
what should happen is that DVI-D becomes DVI-I and VGA vbios entry is ignored
for this board?

Is this something which can be done in radeon_atom_apply_quirks? I'll give it a
go.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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/14] updated exynos-drm-next.

Hi, Dave and all.

this update adds new features below:
- add HDMI version 1.4 and Audio support.
- add mode_fixup feature.
  . hdmi module would change current mode to driver desired mode properly.
- updated gem and buffer framework.
  . we can allocate physically continuous or non-continuous
memory and also it creates scatterlist for iommu support so allocated
memory region can be mapped to iommu page table using scatterlist.
- add dma address get/put interface.
  . this function would be used for drm based 2d acceleration driver
to get/put dma address through gem handle.
when exynos_drm_get_dma_address is called reference count of
gem object would be increased not to be released by gem close and
when exynos_drm_put_dma_address is called the reference count of
this gem object would be decreased to be released.
- add virtual display driver.
  . this driver would be used for wireless display.
- add direct rendering based 2d graphics acceleration module.
  . exynos SoC chip has fimg2d named 2d graphics accelerator and this driver
supports only exynos4x12 series.

Links to previous versions of the patchset:
v1:  http://permalink.gmane.org/gmane.comp.video.dri.devel/66247 

Changelog v2:
- add HDMI Audio support.
- add descriptions for direct rendering based g2d driver and
  user application for it.
  . for user application, you can refer to this link below:
http://www.spinics.net/lists/dri-devel/msg20014.html
- fix variable type Dave pointed out.
  . use __u64 __user * instead of void *
- code clean to exynos gem and buffer framework.
- add default pixel format for plane.

this patch set is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-core-next
commit-id: 8229c885fe361e521ac64de36b16011e54a30de0

and you can refer to our working git repository below:
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

Thanks.

Eunchul Kim (1):
  drm/exynos: add default pixel format for plane

Inki Dae (4):
  drm/exynos: added mode_fixup feature and code clean.
  drm/exynos: update gem and buffer framework.
  drm/exynos: added new funtion to get/put dma address.
  drm/exynos: added virtual display driver.

Joonyoung Shim (8):
  drm/exynos: add HDMI version 1.4 support
  drm/exynos: release pending pageflip events when closed
  drm/exynos: remove module of exynos drm subdrv
  drm/exynos: add subdrv open/close functions
  drm/exynos: add is_local member in exynos_drm_subdrv struct
  drm/exynos: add G2D driver
  drm/exynos: remove exynos_mixer.h
  drm/exynos: cleanup exynos_hdmi.h

Seung-Woo Kim (1):
  drm/exynos: enable hdmi audio feature

 drivers/gpu/drm/exynos/Kconfig|   20 +-
 drivers/gpu/drm/exynos/Makefile   |   12 +-
 drivers/gpu/drm/exynos/exynos_ddc.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  191 +++-
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |   22 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   35 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  140 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  125 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   51 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   24 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|6 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   90 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  885 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h   |   36 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  363 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   29 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  115 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |8 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  676 
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  |   36 +
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 1437 +++--
 drivers/gpu/drm/exynos/exynos_hdmi.h  |   50 -
 drivers/gpu/drm/exynos/exynos_mixer.c |   57 +-
 drivers/gpu/drm/exynos/exynos_mixer.h |   92 --
 drivers/gpu/drm/exynos/regs-hdmi.h|  488 -
 include/drm/exynos_drm.h  |   83 ++
 29 files changed, 4394 insertions(+), 715 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h

-- 
1.7.4.1

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

[PATCH v2 02/14] drm/exynos: added mode_fixup feature and code clean.

this patch adds mode_fixup feature for hdmi module that
specific driver changes current mode to driver desired mode
properly.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   25 +++-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |6 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |8 +++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   17 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   28 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |5 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   81 ++--
 7 files changed, 157 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 618bd4d..ebdd71d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -225,6 +225,29 @@ static struct drm_connector_helper_funcs 
exynos_connector_helper_funcs = {
.best_encoder   = exynos_drm_best_encoder,
 };
 
+static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
+   unsigned int max_width, unsigned int max_height)
+{
+   struct exynos_drm_connector *exynos_connector =
+   to_exynos_connector(connector);
+   struct exynos_drm_manager *manager = exynos_connector-manager;
+   struct exynos_drm_manager_ops *ops = manager-ops;
+   unsigned int width, height;
+
+   width = max_width;
+   height = max_height;
+
+   /*
+* if specific driver want to find desired_mode using maxmum
+* resolution then get max width and height from that driver.
+*/
+   if (ops  ops-get_max_resol)
+   ops-get_max_resol(manager-dev, width, height);
+
+   return drm_helper_probe_single_connector_modes(connector, width,
+   height);
+}
+
 /* get detection status of display device. */
 static enum drm_connector_status
 exynos_drm_connector_detect(struct drm_connector *connector, bool force)
@@ -262,7 +285,7 @@ static void exynos_drm_connector_destroy(struct 
drm_connector *connector)
 
 static struct drm_connector_funcs exynos_connector_funcs = {
.dpms   = drm_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   .fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
 };
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index de81883..2d9a0e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -249,7 +249,11 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 {
DRM_DEBUG_KMS(%s\n, __FILE__);
 
-   mode = adjusted_mode;
+   /*
+* copy the mode data adjusted by mode_fixup() into crtc-mode
+* so that hardware can be seet to proper mode.
+*/
+   memcpy(crtc-mode, adjusted_mode, sizeof(*adjusted_mode));
 
return exynos_drm_crtc_update(crtc);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 13540de..4115a9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -155,8 +155,10 @@ struct exynos_drm_display_ops {
  *
  * @dpms: control device power.
  * @apply: set timing, vblank and overlay data to registers.
+ * @mode_fixup: fix mode data comparing to hw specific display mode.
  * @mode_set: convert drm_display_mode to hw specific display mode and
  *   would be called by encoder-mode_set().
+ * @get_max_resol: get maximum resolution to specific hardware.
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
@@ -164,7 +166,13 @@ struct exynos_drm_display_ops {
 struct exynos_drm_manager_ops {
void (*dpms)(struct device *subdrv_dev, int mode);
void (*apply)(struct device *subdrv_dev);
+   void (*mode_fixup)(struct device *subdrv_dev,
+   struct drm_connector *connector,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode);
void (*mode_set)(struct device *subdrv_dev, void *mode);
+   void (*get_max_resol)(struct device *subdrv_dev, unsigned int *width,
+   unsigned int *height);
void (*commit)(struct device *subdrv_dev);
int (*enable_vblank)(struct device *subdrv_dev);
void (*disable_vblank)(struct device *subdrv_dev);
diff --git

[PATCH v2 03/14] drm/exynos: update gem and buffer framework.

with this patch, we can allocate physically continuous or non-continuous
memory and also it creates scatterlist for iommu support so allocated
memory region can be mapped to iommu page table using scatterlist.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  191 +++
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |   22 ++-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  301 ++---
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   11 +-
 include/drm/exynos_drm.h  |6 +
 6 files changed, 463 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 3cf785c..4a3a5f7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -25,45 +25,161 @@
 
 #include drmP.h
 #include drm.h
+#include exynos_drm.h
 
 #include exynos_drm_drv.h
 #include exynos_drm_gem.h
 #include exynos_drm_buf.h
 
 static int lowlevel_buffer_allocate(struct drm_device *dev,
-   struct exynos_drm_gem_buf *buffer)
+   unsigned int flags, struct exynos_drm_gem_buf *buf)
 {
+   dma_addr_t start_addr, end_addr;
+   unsigned int npages, page_size, i = 0;
+   struct scatterlist *sgl;
+   int ret = 0;
+
DRM_DEBUG_KMS(%s\n, __FILE__);
 
-   buffer-kvaddr = dma_alloc_writecombine(dev-dev, buffer-size,
-   buffer-dma_addr, GFP_KERNEL);
-   if (!buffer-kvaddr) {
-   DRM_ERROR(failed to allocate buffer.\n);
+   if (flags  EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS(not support allocation type.\n);
+   return -EINVAL;
+   }
+
+   if (buf-dma_addr) {
+   DRM_DEBUG_KMS(already allocated.\n);
+   return 0;
+   }
+
+   if (buf-size = SZ_1M) {
+   npages = (buf-size  SECTION_SHIFT) + 1;
+   page_size = SECTION_SIZE;
+   } else if (buf-size = SZ_64K) {
+   npages = (buf-size  16) + 1;
+   page_size = SZ_64K;
+   } else {
+   npages = (buf-size  PAGE_SHIFT) + 1;
+   page_size = PAGE_SIZE;
+   }
+
+   buf-sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
+   if (!buf-sgt) {
+   DRM_ERROR(failed to allocate sg table.\n);
return -ENOMEM;
}
 
-   DRM_DEBUG_KMS(vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n,
-   (unsigned long)buffer-kvaddr,
-   (unsigned long)buffer-dma_addr,
-   buffer-size);
+   ret = sg_alloc_table(buf-sgt, npages, GFP_KERNEL);
+   if (ret  0) {
+   DRM_ERROR(failed to initialize sg table.\n);
+   kfree(buf-sgt);
+   buf-sgt = NULL;
+   return -ENOMEM;
+   }
 
-   return 0;
+   buf-kvaddr = dma_alloc_writecombine(dev-dev, buf-size,
+   buf-dma_addr, GFP_KERNEL);
+   if (!buf-kvaddr) {
+   DRM_ERROR(failed to allocate buffer.\n);
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   start_addr = buf-dma_addr;
+   end_addr = buf-dma_addr + buf-size;
+
+   buf-pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
+   if (!buf-pages) {
+   DRM_ERROR(failed to allocate pages.\n);
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   start_addr = buf-dma_addr;
+   end_addr = buf-dma_addr + buf-size;
+
+   buf-pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
+   if (!buf-pages) {
+   DRM_ERROR(failed to allocate pages.\n);
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   sgl = buf-sgt-sgl;
+
+   while (i  npages) {
+   buf-pages[i] = phys_to_page(start_addr);
+   sg_set_page(sgl, buf-pages[i], page_size, 0);
+   sg_dma_address(sgl) = start_addr;
+   start_addr += page_size;
+   if (end_addr - start_addr  page_size)
+   break;
+   sgl = sg_next(sgl);
+   i++;
+   }
+
+   buf-pages[i] = phys_to_page(start_addr);
+
+   sgl = sg_next(sgl);
+   sg_set_page(sgl, buf-pages[i+1], end_addr - start_addr, 0);
+
+   DRM_DEBUG_KMS(vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n,
+   (unsigned long)buf-kvaddr,
+   (unsigned long)buf-dma_addr,
+   buf-size);
+
+   return ret;
+err2:
+   dma_free_writecombine(dev-dev, buf-size, buf-kvaddr,
+   (dma_addr_t)buf-dma_addr);
+   buf-dma_addr = (dma_addr_t)NULL;
+err1:
+

[PATCH v2 04/14] drm/exynos: added new funtion to get/put dma address.

this function would be used for drm based 2d acceleration driver
to get/put dma address through gem handle.
when exynos_drm_get_dma_address is called reference count of
gem object would be increased not to be released by gem close and
when exynos_drm_put_dma_address is called the reference count of
this gem object would be decreased to be released.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   58 +++
 drivers/gpu/drm/exynos/exynos_drm_gem.h |   18 +
 2 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 730093f..b5c6f3c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -386,6 +386,64 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
void *data,
return 0;
 }
 
+void *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(dev, file_priv, gem_handle);
+   if (!obj) {
+   DRM_ERROR(failed to lookup gem object.\n);
+   return ERR_PTR(-EINVAL);
+   }
+
+   exynos_gem_obj = to_exynos_gem_obj(obj);
+
+   if (exynos_gem_obj-flags  EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS(not support NONCONTIG type.\n);
+   drm_gem_object_unreference_unlocked(obj);
+
+   /* TODO */
+   return ERR_PTR(-EINVAL);
+   }
+
+   return exynos_gem_obj-buffer-dma_addr;
+}
+
+void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv)
+{
+   struct exynos_drm_gem_obj *exynos_gem_obj;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(dev, file_priv, gem_handle);
+   if (!obj) {
+   DRM_ERROR(failed to lookup gem object.\n);
+   return;
+   }
+
+   exynos_gem_obj = to_exynos_gem_obj(obj);
+
+   if (exynos_gem_obj-flags  EXYNOS_BO_NONCONTIG) {
+   DRM_DEBUG_KMS(not support NONCONTIG type.\n);
+   drm_gem_object_unreference_unlocked(obj);
+
+   /* TODO */
+   return;
+   }
+
+   drm_gem_object_unreference_unlocked(obj);
+
+   /*
+* decrease obj-refcount one more time because we has already
+* increased it at exynos_drm_gem_get_dma_addr().
+*/
+   drm_gem_object_unreference_unlocked(obj);
+}
+
 int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 096267d..e40fbad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -88,6 +88,24 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
 int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
 
+/*
+ * get dma address from gem handle and this function could be used for
+ * other drivers such as 2d/3d acceleration drivers.
+ * with this function call, gem object reference count would be increased.
+ */
+void *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv);
+
+/*
+ * put dma address from gem handle and this function could be used for
+ * other drivers such as 2d/3d acceleration drivers.
+ * with this function call, gem object reference count would be decreased.
+ */
+void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
+   unsigned int gem_handle,
+   struct drm_file *file_priv);
+
 /* get buffer offset to map to user space. */
 int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-- 
1.7.4.1

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

[PATCH v2 05/14] drm/exynos: release pending pageflip events when closed

From: Joonyoung Shim jy0922.s...@samsung.com

We should release pending pageflip events when closed. If not, they will
be dangling events.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 58820eb..d359cb4b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -147,8 +147,22 @@ static int exynos_drm_unload(struct drm_device *dev)
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
+   struct exynos_drm_private *private = dev-dev_private;
+   struct drm_pending_vblank_event *e, *t;
+   unsigned long flags;
+
DRM_DEBUG_DRIVER(%s\n, __FILE__);
 
+   /* release events of current file */
+   spin_lock_irqsave(dev-event_lock, flags);
+   list_for_each_entry_safe(e, t, private-pageflip_event_list,
+   base.link) {
+   if (e-base.file_priv == file) {
+   list_del(e-base.link);
+   e-base.destroy(e-base);
+   }
+   }
+   spin_unlock_irqrestore(dev-event_lock, flags);
 }
 
 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
-- 
1.7.4.1

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

[PATCH v2 06/14] drm/exynos: remove module of exynos drm subdrv

From: Joonyoung Shim jy0922.s...@samsung.com

The exynos drm driver has several subdrv. They each can be module but it
causes unfixed probe order of exynodr drm driver and each subdrv. It
also needs some weird codes such as exynos_drm_fbdev_reinit and
exynos_drm_mode_group_reinit. This patch can remove weird codes and
clear codes through we doesn't modularity each subdrv.

Also this removes unnecessary codes related module.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig|8 +--
 drivers/gpu/drm/exynos/Makefile   |   10 ++-
 drivers/gpu/drm/exynos/exynos_ddc.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_connector.c |6 --
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  112 ++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |6 --
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   52 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   12 ++--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |6 --
 drivers/gpu/drm/exynos/exynos_drm_fb.c|6 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   86 ---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   20 +
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |4 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   87 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |9 --
 drivers/gpu/drm/exynos/exynos_mixer.c |7 --
 16 files changed, 77 insertions(+), 355 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index b9e5266..9a9850a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,7 +1,6 @@
 config DRM_EXYNOS
tristate DRM Support for Samsung SoC EXYNOS Series
depends on DRM  PLAT_SAMSUNG
-   default n
select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -12,16 +11,13 @@ config DRM_EXYNOS
  If M is selected the module will be called exynosdrm.
 
 config DRM_EXYNOS_FIMD
-   tristate Exynos DRM FIMD
+   bool Exynos DRM FIMD
depends on DRM_EXYNOS  !FB_S3C
-   default n
help
  Choose this option if you want to use Exynos FIMD for DRM.
- If M is selected, the module will be called exynos_drm_fimd
 
 config DRM_EXYNOS_HDMI
-   tristate Exynos DRM HDMI
+   bool Exynos DRM HDMI
depends on DRM_EXYNOS  !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
- If M is selected, the module will be called exynos_drm_hdmi
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 395e69c..5331fa3 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,7 +8,9 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o 
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o
 
-obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
-obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
-obj-$(CONFIG_DRM_EXYNOS_HDMI) += exynos_hdmi.o exynos_mixer.o exynos_ddc.o \
-exynos_hdmiphy.o exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
+  exynos_ddc.o exynos_hdmiphy.o \
+  exynos_drm_hdmi.o
+
+obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 84b614f..7e1051d 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -55,4 +55,3 @@ struct i2c_driver ddc_driver = {
.remove = __devexit_p(s5p_ddc_remove),
.command= NULL,
 };
-EXPORT_SYMBOL(ddc_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ebdd71d..a5d6591 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -348,9 +348,3 @@ err_connector:
kfree(exynos_connector);
return NULL;
 }
-
-MODULE_AUTHOR(Inki Dae inki@samsung.com);
-MODULE_AUTHOR(Joonyoung Shim jy0922.s...@samsung.com);
-MODULE_AUTHOR(Seung-Woo Kim sw0312@samsung.com);
-MODULE_DESCRIPTION(Samsung SoC DRM Connector Driver);
-MODULE_LICENSE(GPL);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index d08a558..937b059 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -32,7 +32,6 @@
 #include exynos_drm_connector.h
 #include exynos_drm_fbdev.h
 
-static DEFINE_MUTEX(exynos_drm_mutex);
 static

[PATCH v2 08/14] drm/exynos: add is_local member in exynos_drm_subdrv struct

From: Joonyoung Shim jy0922.s...@samsung.com

The is_local member indicates unused subdrv such connector and encoder
so doesn't make resources for them.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |3 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 ++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4e29c71..411832e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -59,6 +59,9 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
return ret;
}
 
+   if (subdrv-is_local)
+   return 0;
+
/* create and initialize a encoder for this sub driver. */
encoder = exynos_drm_encoder_create(dev, subdrv-manager,
(1  MAX_CRTC) - 1);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a412454..b26c2f4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -225,6 +225,7 @@ struct exynos_drm_private {
  * @list: sub driver has its own list object to register to exynos drm driver.
  * @drm_dev: pointer to drm_device and this pointer would be set
  * when sub driver calls exynos_drm_subdrv_register().
+ * @is_local: appear encoder and connector disrelated device.
  * @probe: this callback would be called by exynos drm driver after
  * subdrv is registered to it.
  * @remove: this callback is used to release resources created
@@ -239,6 +240,7 @@ struct exynos_drm_private {
 struct exynos_drm_subdrv {
struct list_head list;
struct drm_device *drm_dev;
+   bool is_local;
 
int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
-- 
1.7.4.1

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

[PATCH v2 07/14] drm/exynos: add subdrv open/close functions

From: Joonyoung Shim jy0922.s...@samsung.com

Some subdrv need open and close functions call when open and close drm.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_core.c |   35 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   10 
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 +++
 3 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 937b059..4e29c71 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -175,3 +175,38 @@ int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv 
*subdrv)
return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);
+
+int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct exynos_drm_subdrv *subdrv;
+   int ret;
+
+   list_for_each_entry(subdrv, exynos_drm_subdrv_list, list) {
+   if (subdrv-open) {
+   ret = subdrv-open(dev, subdrv-manager.dev, file);
+   if (ret)
+   goto err;
+   }
+   }
+
+   return 0;
+
+err:
+   list_for_each_entry_reverse(subdrv, subdrv-list, list) {
+   if (subdrv-close)
+   subdrv-close(dev, subdrv-manager.dev, file);
+   }
+   return ret;
+}
+EXPORT_SYMBOL_GPL(exynos_drm_subdrv_open);
+
+void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file)
+{
+   struct exynos_drm_subdrv *subdrv;
+
+   list_for_each_entry(subdrv, exynos_drm_subdrv_list, list) {
+   if (subdrv-close)
+   subdrv-close(dev, subdrv-manager.dev, file);
+   }
+}
+EXPORT_SYMBOL_GPL(exynos_drm_subdrv_close);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 903fcf0..1d78e03 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -144,6 +144,13 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
 }
 
+static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
+{
+   DRM_DEBUG_DRIVER(%s\n, __FILE__);
+
+   return exynos_drm_subdrv_open(dev, file);
+}
+
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
@@ -163,6 +170,8 @@ static void exynos_drm_preclose(struct drm_device *dev,
}
}
spin_unlock_irqrestore(dev-event_lock, flags);
+
+   exynos_drm_subdrv_close(dev, file);
 }
 
 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
@@ -216,6 +225,7 @@ static struct drm_driver exynos_drm_driver = {
  DRIVER_MODESET | DRIVER_GEM,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
+   .open   = exynos_drm_open,
.preclose   = exynos_drm_preclose,
.lastclose  = exynos_drm_lastclose,
.postclose  = exynos_drm_postclose,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f8bac0e..a412454 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -229,6 +229,8 @@ struct exynos_drm_private {
  * subdrv is registered to it.
  * @remove: this callback is used to release resources created
  * by probe callback.
+ * @open: this would be called with drm device file open.
+ * @close: this would be called with drm device file close.
  * @manager: subdrv has its own manager to control a hardware appropriately
  * and we can access a hardware drawing on this manager.
  * @encoder: encoder object owned by this sub driver.
@@ -240,6 +242,10 @@ struct exynos_drm_subdrv {
 
int (*probe)(struct drm_device *drm_dev, struct device *dev);
void (*remove)(struct drm_device *dev);
+   int (*open)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);
+   void (*close)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);
 
struct exynos_drm_manager manager;
struct drm_encoder *encoder;
@@ -269,6 +275,9 @@ int exynos_drm_subdrv_register(struct exynos_drm_subdrv 
*drm_subdrv);
 /* this function removes subdrv list from exynos drm driver */
 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *drm_subdrv);
 
+int exynos_drm_subdrv_open(struct drm_device *dev, struct drm_file *file);
+void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file *file);
+
 extern struct platform_driver fimd_driver;
 extern struct platform_driver hdmi_driver;
 extern struct

[PATCH v2 12/14] drm/exynos: cleanup exynos_hdmi.h

From: Joonyoung Shim jy0922.s...@samsung.com

The some contents of the exynos_hdmi.h are used only in exynos_hdmi.c,
so move them to exynos_hdmi.c.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   36 
 drivers/gpu/drm/exynos/exynos_hdmi.h  |   42 -
 drivers/gpu/drm/exynos/exynos_mixer.c |1 -
 3 files changed, 36 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3fe5b2e..3583a7b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -45,6 +45,42 @@
 #define MAX_HEIGHT 1080
 #define get_hdmi_context(dev)  platform_get_drvdata(to_platform_device(dev))
 
+struct hdmi_resources {
+   struct clk  *hdmi;
+   struct clk  *sclk_hdmi;
+   struct clk  *sclk_pixel;
+   struct clk  *sclk_hdmiphy;
+   struct clk  *hdmiphy;
+   struct regulator_bulk_data  *regul_bulk;
+   int regul_count;
+};
+
+struct hdmi_context {
+   struct device   *dev;
+   struct drm_device   *drm_dev;
+   struct fb_videomode *default_timing;
+   unsigned intis_v13:1;
+   unsigned intdefault_win;
+   unsigned intdefault_bpp;
+   boolhpd_handle;
+   boolenabled;
+
+   struct resource *regs_res;
+   void __iomem*regs;
+   unsigned intirq;
+   struct workqueue_struct *wq;
+   struct work_struct  hotplug_work;
+
+   struct i2c_client   *ddc_port;
+   struct i2c_client   *hdmiphy_port;
+
+   /* current hdmiphy conf index */
+   int cur_conf;
+
+   struct hdmi_resources   res;
+   void*parent_ctx;
+};
+
 /* HDMI Version 1.3 */
 static const u8 hdmiphy_v13_conf27[32] = {
0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_hdmi.h
index 040ecad..1c3b6d8 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.h
@@ -28,48 +28,6 @@
 #ifndef _EXYNOS_HDMI_H_
 #define _EXYNOS_HDMI_H_
 
-struct hdmi_resources {
-   struct clk *hdmi;
-   struct clk *sclk_hdmi;
-   struct clk *sclk_pixel;
-   struct clk *sclk_hdmiphy;
-   struct clk *hdmiphy;
-   struct regulator_bulk_data *regul_bulk;
-   int regul_count;
-};
-
-struct hdmi_context {
-   struct device   *dev;
-   struct drm_device   *drm_dev;
-   struct fb_videomode *default_timing;
-   unsigned intis_v13:1;
-   unsigned intdefault_win;
-   unsigned intdefault_bpp;
-   boolhpd_handle;
-   boolenabled;
-
-   struct resource *regs_res;
-   /** base address of HDMI registers */
-   void __iomem *regs;
-   /** HDMI hotplug interrupt */
-   unsigned int irq;
-   /** workqueue for delayed work */
-   struct workqueue_struct *wq;
-   /** hotplug handling work */
-   struct work_struct hotplug_work;
-
-   struct i2c_client *ddc_port;
-   struct i2c_client *hdmiphy_port;
-
-   /** current hdmiphy conf index */
-   int cur_conf;
-   /** other resources */
-   struct hdmi_resources res;
-
-   void *parent_ctx;
-};
-
-
 void hdmi_attach_ddc_client(struct i2c_client *ddc);
 void hdmi_attach_hdmiphy_client(struct i2c_client *hdmiphy);
 
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index f42c437..4d5f41e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -36,7 +36,6 @@
 
 #include exynos_drm_drv.h
 #include exynos_drm_hdmi.h
-#include exynos_hdmi.h
 
 #define HDMI_OVERLAY_NUMBER3
 
-- 
1.7.4.1

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

[PATCH v2 09/14] drm/exynos: add G2D driver

From: Joonyoung Shim jy0922.s...@samsung.com

The G2D is a 2D graphic accelerator that supports Bit Block Transfer.
This G2D driver is exynos drm specific and supports only G2D(version
4.1) of later Exynos series from Exynos4X12 because supporting DMA.

The G2D is performed by two tasks simply.
1. Configures the rendering parameters, such as foreground color and
   coordinates data by setting the drawing context registers.
2. Start the rendering process by setting thre relevant command
   registers accordingly.

The G2D version 4.1 supports DMA mode as host interface. User can make
command list to reduce HOST(ARM) loads. The contents of The command list
is setted to relevant registers of G2D by DMA.

The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)

By Tail field, the G2D can process many command lists without halt at
one go.

The G2D has following the rendering pipeline.
-- Primitive Drawing -- Rotation -- Clipping -- Bilinear Sampling
-- Color Key -- ROP -- Mask Operation -- Alpha Blending --
Dithering -- FrameBuffer

And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- window clipping
- rotation
- flip
- 4 operand raster operation(ROP4)
- masking operation
- alpha blending
- color key
- dithering
- etc

User should make the command list to data and registers needed by
operation to use. The Exynos G2D driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then G2D driver
converts it to memory base address.

We adds three ioctls and one event for Exynos G2D.

- ioctls
DRM_EXYNOS_G2D_GET_VER: get the G2D hardware version
DRM_EXYNOS_G2D_SET_CMDLIST: set the command list from user to driver
DRM_EXYNOS_G2D_EXEC: execute the command lists setted to driver

- event
DRM_EXYNOS_G2D_EVENT: event to give notification completion of the
  command list to user

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig  |6 +
 drivers/gpu/drm/exynos/Makefile |1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   31 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   13 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  885 +++
 drivers/gpu/drm/exynos/exynos_drm_g2d.h |   36 ++
 include/drm/exynos_drm.h|   57 ++
 7 files changed, 1029 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_g2d.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9a9850a..8493fe9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -21,3 +21,9 @@ config DRM_EXYNOS_HDMI
depends on DRM_EXYNOS  !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
+
+config DRM_EXYNOS_G2D
+   bool Exynos DRM G2D
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 5331fa3..d6c1a3c 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -12,5 +12,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
 
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 1d78e03..64ef4ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,6 +37,7 @@
 #include exynos_drm_fbdev.h
 #include exynos_drm_fb.h
 #include exynos_drm_gem.h
+#include exynos_drm_g2d.h
 #include exynos_drm_plane.h
 
 #define DRIVER_NAMEexynos
@@ -146,8 +147,16 @@ static int exynos_drm_unload(struct drm_device *dev)
 
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
+   struct drm_exynos_file_private *file_priv;
+
DRM_DEBUG_DRIVER(%s\n, __FILE__);
 
+   file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
+   if (!file_priv)
+   return -ENOMEM;
+
+   file-driver_priv = file_priv;
+
return exynos_drm_subdrv_open(dev, file);
 }
 
@@ -208,6 +217,13 @@ static struct drm_ioctl_desc exynos_ioctls[] = {

[PATCH v2 10/14] drm/exynos: added virtual display driver.

this driver would be used for wireless display. virtual display
driver has independent crtc, encoder and connector and to use
this driver, user application should send edid data to this driver
from wireless display.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig|6 +
 drivers/gpu/drm/exynos/Makefile   |1 +
 drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   18 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |7 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  676 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.h  |   36 ++
 include/drm/exynos_drm.h  |   18 +
 9 files changed, 765 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_vidi.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 8493fe9..7b980cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -27,3 +27,9 @@ config DRM_EXYNOS_G2D
depends on DRM_EXYNOS
help
  Choose this option if you want to use Exynos G2D for DRM.
+
+config DRM_EXYNOS_VIDI
+   bool Exynos DRM Virtual Display
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos VIDI for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index d6c1a3c..a67ea9a 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -13,5 +13,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o 
exynos_mixer.o \
   exynos_ddc.o exynos_hdmiphy.o \
   exynos_drm_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
 
 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index a5d6591..ee4ff74 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -315,6 +315,10 @@ struct drm_connector *exynos_drm_connector_create(struct 
drm_device *dev,
connector-interlace_allowed = true;
connector-polled = DRM_CONNECTOR_POLL_HPD;
break;
+   case EXYNOS_DISPLAY_TYPE_VIDI:
+   type = DRM_MODE_CONNECTOR_VIRTUAL;
+   connector-polled = DRM_CONNECTOR_POLL_HPD;
+   break;
default:
type = DRM_MODE_CONNECTOR_Unknown;
break;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 64ef4ce..9af9dec2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -39,6 +39,7 @@
 #include exynos_drm_gem.h
 #include exynos_drm_g2d.h
 #include exynos_drm_plane.h
+#include exynos_drm_vidi.h
 
 #define DRIVER_NAMEexynos
 #define DRIVER_DESCSamsung SoC DRM
@@ -217,6 +218,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
+   vidi_connection_ioctl, DRM_UNLOCKED | DRM_AUTH),
 
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
exynos_g2d_get_ver_ioctl, DRM_UNLOCKED | DRM_AUTH),
@@ -314,6 +317,12 @@ static int __init exynos_drm_init(void)
goto out_common_hdmi;
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   ret = platform_driver_register(vidi_driver);
+   if (ret  0)
+   goto out_vidi;
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(g2d_driver);
if (ret  0)
@@ -332,6 +341,11 @@ out:
 out_g2d:
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   platform_driver_unregister(vidi_driver);
+out_vidi:
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(exynos_drm_common_hdmi_driver);
 out_common_hdmi:
@@ -358,6 +372,10 @@ static void __exit exynos_drm_exit(void)
platform_driver_unregister(g2d_driver);
 #endif
 
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+   platform_driver_unregister(vidi_driver);
+#endif
+
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(exynos_drm_common_hdmi_driver);
platform_driver_unregister(mixer_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 750daa9..168d296 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h

[PATCH v2 13/14] drm/exynos: add default pixel format for plane

From: Eunchul Kim chulspro@samsung.com

DRM checks whether the plane supports a pixel format of fb when plane is
updated. This adds a default pixel format supporting format exynos drm
plane.

Signed-off-by: Eunchul Kim chulspro@samsung.com
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index bdcf770..c277a3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -22,6 +22,10 @@ struct exynos_plane {
boolenabled;
 };
 
+static const uint32_t formats[] = {
+   DRM_FORMAT_XRGB,
+};
+
 static int
 exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
 struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -115,9 +119,9 @@ int exynos_plane_init(struct drm_device *dev, unsigned int 
nr)
 
exynos_plane-overlay.zpos = DEFAULT_ZPOS;
 
-   /* TODO: format */
return drm_plane_init(dev, exynos_plane-base, possible_crtcs,
- exynos_plane_funcs, NULL, 0, false);
+ exynos_plane_funcs, formats, ARRAY_SIZE(formats),
+ false);
 }
 
 int exynos_plane_set_zpos_ioctl(struct drm_device *dev, void *data,
-- 
1.7.4.1

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

[PATCH v2 11/14] drm/exynos: remove exynos_mixer.h

From: Joonyoung Shim jy0922.s...@samsung.com

The contents of exynos_mixer.h are used only in exynos_mixer.c, so
separated header is unnecessary.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   49 +-
 drivers/gpu/drm/exynos/exynos_mixer.h |   92 -
 2 files changed, 48 insertions(+), 93 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_mixer.h

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 242cbcd..f42c437 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -37,10 +37,57 @@
 #include exynos_drm_drv.h
 #include exynos_drm_hdmi.h
 #include exynos_hdmi.h
-#include exynos_mixer.h
+
+#define HDMI_OVERLAY_NUMBER3
 
 #define get_mixer_context(dev) platform_get_drvdata(to_platform_device(dev))
 
+struct hdmi_win_data {
+   dma_addr_t  dma_addr;
+   void __iomem*vaddr;
+   dma_addr_t  chroma_dma_addr;
+   void __iomem*chroma_vaddr;
+   uint32_tpixel_format;
+   unsigned intbpp;
+   unsigned intcrtc_x;
+   unsigned intcrtc_y;
+   unsigned intcrtc_width;
+   unsigned intcrtc_height;
+   unsigned intfb_x;
+   unsigned intfb_y;
+   unsigned intfb_width;
+   unsigned intfb_height;
+   unsigned intmode_width;
+   unsigned intmode_height;
+   unsigned intscan_flags;
+};
+
+struct mixer_resources {
+   struct device   *dev;
+   int irq;
+   void __iomem*mixer_regs;
+   void __iomem*vp_regs;
+   spinlock_t  reg_slock;
+   struct clk  *mixer;
+   struct clk  *vp;
+   struct clk  *sclk_mixer;
+   struct clk  *sclk_hdmi;
+   struct clk  *sclk_dac;
+};
+
+struct mixer_context {
+   struct fb_videomode *default_timing;
+   unsigned intdefault_win;
+   unsigned intdefault_bpp;
+   unsigned intirq;
+   int pipe;
+   boolinterlace;
+   boolvp_enabled;
+
+   struct mixer_resources  mixer_res;
+   struct hdmi_win_datawin_data[HDMI_OVERLAY_NUMBER];
+};
+
 static const u8 filter_y_horiz_tap8[] = {
0,  -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, 0,  0,  0,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.h 
b/drivers/gpu/drm/exynos/exynos_mixer.h
deleted file mode 100644
index cebacfe..000
--- a/drivers/gpu/drm/exynos/exynos_mixer.h
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * Authors:
- * Seung-Woo Kim sw0312@samsung.com
- * Inki Dae inki@samsung.com
- *
- * 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, sublicense,
- * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
- * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS 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.
- */
-
-#ifndef _EXYNOS_MIXER_H_
-#define _EXYNOS_MIXER_H_
-
-#define HDMI_OVERLAY_NUMBER3
-
-struct hdmi_win_data {
-   dma_addr_t  dma_addr;
-   void __iomem*vaddr;
-   dma_addr_t  chroma_dma_addr;
-   void __iomem*chroma_vaddr;
-   uint32_tpixel_format;
-   unsigned intbpp;
-   unsigned intcrtc_x;
-   unsigned intcrtc_y;
-   unsigned intcrtc_width;
-   unsigned intcrtc_height;
-   unsigned intfb_x;
-   unsigned intfb_y;
-   unsigned int

[PATCH] dma-buf: pass flags into dma_buf_fd.

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

We need to pass the flags into dma_buf_fd at this point,
so the flags end up doing the right thing for O_CLOEXEC.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/base/dma-buf.c  |5 +++--
 include/linux/dma-buf.h |2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c9a945f..3c8c023 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -107,17 +107,18 @@ EXPORT_SYMBOL_GPL(dma_buf_export);
 /**
  * dma_buf_fd - returns a file descriptor for the given dma_buf
  * @dmabuf:[in]pointer to dma_buf for which fd is required.
+ * @flags:  [in]flags to give to fd
  *
  * On success, returns an associated 'fd'. Else, returns error.
  */
-int dma_buf_fd(struct dma_buf *dmabuf)
+int dma_buf_fd(struct dma_buf *dmabuf, int flags)
 {
int error, fd;
 
if (!dmabuf || !dmabuf-file)
return -EINVAL;
 
-   error = get_unused_fd();
+   error = get_unused_fd_flags(flags);
if (error  0)
return error;
fd = error;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a885b26..891457a 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -117,7 +117,7 @@ void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);
 struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
   size_t size, int flags);
-int dma_buf_fd(struct dma_buf *dmabuf);
+int dma_buf_fd(struct dma_buf *dmabuf, int flags);
 struct dma_buf *dma_buf_get(int fd);
 void dma_buf_put(struct dma_buf *dmabuf);
 
-- 
1.7.6

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

expected userspace prime/dma-buf usage

Just wondering how we expect userspace to use dma-buf/prime interfaces.

Currently I see one driver in sharing the buffer with handle-fd, then
passing the fd to the other driver and it using fd-handle, do we then
expect the importing driver to close the fd?

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

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #34 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-16 
03:54:47 UTC ---
(In reply to comment #32)
 (In reply to comment #31)
  It is a single DVI-I physically.
  
  But even identifying it would not change anything with regards to polling
  induced rendering stalls, right? 
  
 
 Well, shared_ddc wouldn't apply in that case since there is only one 
 connector,
 and for better or worse we wouldn't be polling since the connector does have 
 an
 HPD pin (even if it doesn't necessarily work reliably with the analog part of 
 a
 DVI-I connector).  So fixing that would avoid the polling stalls on your
 particular board.

Now I know how to do the quirk to make only DVI-I appear instead of DVI-D and
VGA, however obvious limitation here is that:
 a) use cases from #18 are broken
 b) code seems to be buggy in bringing up even HPD enabled connectors anyway

Consider this for the latter:

* DVI monitor connected to DVI-I
* Unplug the cable
* HPD interrupt happens
* radeon_dvi_detect called
* DDC probe fails
* connector marked as disconnected
* output_poll_changed called,
* drm_helper_probe_single_connector_modes
* radeon_dvi_detect called again with force=true
* DAC load detect puts the connector in unknown status
* poll scheduled for ten seconds later
* ten seconds later radeon_dvi_detect called
* ddc probe fails
* connector still in unknown state
* Now plug the cable back in
* HPD irq fires
* radeon_dvi_detect called
* DDC is not ready yet for some reason and probe fails (I get this a lot)
* monitor still in unknown status
* end of story, no display

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] omap2+: add drm device

2012-03-16 Thread Tomi Valkeinen

On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote:
 On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
  On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
 
   Well, as I said, it's not an issue for me and from my side it can be
   improved later.
 
  yeah, when CMA is actually merged, there are a few other things I'd
  like to do to, incl converting omapfb over to use CMA and remove
  omap_vram.. but I guess those will be other patches.
 
  Right, I just realized CMA is not in the kernel, nor does it seem to be
  in the linux-next. Is there a reason why you want it already merged?
  Wouldn't it be easier to get it in only when it can actually be used.
  Especially if there's room for improvement.
 
 Some folks are already pulling CMA into product kernels for various
 reasons.. keeping this w/ #ifdef CONFIG_CMA guards seemed like it
 would make their life a bit easier.
 
 But if people feel strongly about it, I can strip that out.

Well, I wouldn't say feel strongly, but... I think the mainline kernel
should have code only for the mainline kernel, not for some custom
kernels. And the code is not testable in any way, not even compilable. I
think all code going in should be tested and compiled. Also, if the CMA
code is not in, who says it won't change. Perhaps the CMA function won't
even exist in the version going into mainline.

 Tomi



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

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

2012-03-16 Thread Marcus Lorentzon


On 03/15/2012 02:32 AM, Rob Clark wrote:

From: Rob Clarkr...@ti.com
[snip]
In all cases, the mmap() call is allowed to fail, and the associated
dma_buf_ops are optional (mmap() will fail if at least the mmap()
op is not implemented by the exporter, but in either case the
{prepare,finish}_access() ops are optional).
I sort of understand this approach. It allowes some implementations 
(ARM/Android) to move forward. But how would an application act if mmap 
fails? What is the option? How can the application detect if mmap is 
possible or not? Or is this mmap only supposed to be used from device 
specific libs like libdrm-xx/libv4l2-xx/libgralloc?


Can mmap fail for one buffer, but not another? Can it fail for a buffer 
that have successfully been mmapped once before (except for the usual 
ENOMEM/EAGAIN etc)?

For now the prepare/finish access ioctls are kept simple with no
argument, although there is possibility to add additional ioctls
(or simply change the existing ioctls from _IO() to _IOW()) later
to provide optimization to allow userspace to specify a region of
interest.
I like the idea of simple, assume the worst, no args, versions of 
begin/end access. But once we move forward, I don't just like the 
region, but also access type (R/W). R/W info allows the driver to make 
cache management optimizations otherwise impossible. Like if CPU with no 
alloc-on-write just write, a write buffer flush is enough to switch to a 
HW read. And (at least on ARM) cache clean can be done for all cache for 
large areas, but invalidate has to be done line by line. Eliminating the 
need to do invalidate, especially if region is small, compared to 
invalidate entire buffer line by line can make a huge difference.
But I would like these in a separate ioctl to keep the normal case 
simple. Maybe as a separate patch even.


For a final patch, dma-buf.h would need to be split into what is
exported to userspace, and what is kernel private, but I wanted to
get feedback on the idea of requiring userspace to bracket access
first (vs. limiting this to coherent mappings or exporters who play
page faltings plus PTE shoot-down games) before I split the header
which would cause conflicts with other pending dma-buf patches.  So
flame-on!
Why not just guard the kernel parts with __KERNEL__ or something? Or 
there are guidelines preventing this?



[snip]

+
+static long dma_buf_ioctl(struct file *file, unsigned int cmd,
+   unsigned long arg)
+{
+   struct dma_buf *dmabuf;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   dmabuf = file-private_data;
+
+   switch (_IOC_NR(cmd)) {
+   case _IOC_NR(DMA_BUF_IOCTL_PREPARE_ACCESS):
+   if (dmabuf-ops-prepare_access)
+   return dmabuf-ops-prepare_access(dmabuf);
+   return 0;
+   case _IOC_NR(DMA_BUF_IOCTL_FINISH_ACCESS):
+   if (dmabuf-ops-finish_access)
+   return dmabuf-ops-finish_access(dmabuf);
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+

Multiple empty lines

  static int dma_buf_release(struct inode *inode, struct file *file)
  {
struct dma_buf *dmabuf;
@@ -45,6 +85,8 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
  }

  static const struct file_operations dma_buf_fops = {
+   .mmap   = dma_buf_mmap,
+   .unlocked_ioctl = dma_buf_ioctl,
.release= dma_buf_release,
  };

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a885b26..cbdff81 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -34,6 +34,17 @@
  struct dma_buf;
  struct dma_buf_attachment;

+/* TODO: dma-buf.h should be the userspace visible header, and dma-buf-priv.h 
(?)
+ * the kernel internal header.. for now just stuff these here to avoid 
conflicting
+ * with other patches..
+ *
+ * For now, no arg to keep things simple, but we could consider adding an
+ * optional region of interest later.
+ */
+#define DMA_BUF_IOCTL_PREPARE_ACCESS   _IO('Z', 0)
+#define DMA_BUF_IOCTL_FINISH_ACCESS_IO('Z', 1)
+
+

Multiple empty lines

  /**
   * struct dma_buf_ops - operations possible on struct dma_buf
   * @attach: [optional] allows different devices to 'attach' themselves to the
@@ -49,6 +60,13 @@ struct dma_buf_attachment;
   * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter
   *   pages.
   * @release: release this buffer; to be called after the last dma_buf_put.
+ * @mmap: [optional, allowed to fail] operation called if userspace calls
+ *  mmap() on the dmabuf fd.  Note that userspace should use the
+ *  DMA_BUF_PREPARE_ACCESS / DMA_BUF_FINISH_ACCESS ioctls 
before/after
+ *  sw access to the buffer, to give the exporter an opportunity to
+ *  deal with cache maintenance.
+ * @prepare_access: [optional] handler for PREPARE_ACCESS ioctl.
+ * @finish_access:

[Bug 47407] New: System unable to recover from suspend to disk

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

 Bug #: 47407
   Summary: System unable to recover from suspend to disk
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: hysv...@gmail.com


Created attachment 58551
  -- https://bugs.freedesktop.org/attachment.cgi?id=58551
dmesg

Driver Stack Details:
=

1)Kernel-3.0.0-12-generice-pae 
2)drm-2.4.31
3)Mesa-8.1-devel (git-5beba3d) 
4)Xorg-server-1.11.4
5)xf86-video-ati- master



System Environment:
===

Asic : M97
O.S. : Ubuntu-11.10 (32 bit)
Processor: AMD Athlon(tm) 64 X2 @ 1 GHz
Memory   : 2 GB  

Steps to Reproduce:
===


1) echo disk  /sys/power/state 
   System suspends to disk and screen goes to blank.

2) Use the wakeup device to wakeup the system


Observation : System unable to recover from suspend to disk using the wake up
===   device

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 47407] System unable to recover from suspend to disk

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

--- Comment #1 from samit vats hysv...@gmail.com 2012-03-16 05:09:38 PDT ---
Created attachment 58552
  -- https://bugs.freedesktop.org/attachment.cgi?id=58552
Xorg.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 47407] System unable to recover from suspend to disk

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

samit vats hysv...@gmail.com changed:

   What|Removed |Added

   Priority|medium  |high

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 47007] HDMI monitor polling causing 100ms rendering stalls

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

--- Comment #35 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-16 
06:18:42 PDT ---
Created attachment 58554
  -- https://bugs.freedesktop.org/attachment.cgi?id=58554
Correctly identify connector on Fujitsu D3003-S2 board

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: expected userspace prime/dma-buf usage

On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie airl...@gmail.com wrote:
 Just wondering how we expect userspace to use dma-buf/prime interfaces.

 Currently I see one driver in sharing the buffer with handle-fd, then
 passing the fd to the other driver and it using fd-handle, do we then
 expect the importing driver to close the fd?

Importing driver should:

  dbuf = dma_buf_get(fd);
  ... store the 'struct dma_buf *' for however long is needed.. this holds
  a ref to the 'struct file' that backs the dma-buf.. and then when no
  longer needed:
  dma_buf_put(dbuf);

think of dma_buf_get()/dma_buf_put() as basically similar to
fget()/fput().. the fget() would either atomically succeed (if the
file descriptor was still valid) and increment the ref count, or fail.
 The fput() would decrement the refcnt.  The last fput() triggers
-release() (which then in turn decrements the ref count of the
original gem buffer object, etc).

BR,
-R

 Dave.
 ___
 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: expected userspace prime/dma-buf usage

On Fri, Mar 16, 2012 at 8:22 AM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie airl...@gmail.com wrote:
 Just wondering how we expect userspace to use dma-buf/prime interfaces.

 Currently I see one driver in sharing the buffer with handle-fd, then
 passing the fd to the other driver and it using fd-handle, do we then
 expect the importing driver to close the fd?

 Importing driver should:

  dbuf = dma_buf_get(fd);
  ... store the 'struct dma_buf *' for however long is needed.. this holds
      a ref to the 'struct file' that backs the dma-buf.. and then when no
      longer needed:
  dma_buf_put(dbuf);

 think of dma_buf_get()/dma_buf_put() as basically similar to
 fget()/fput().. the fget() would either atomically succeed (if the
 file descriptor was still valid) and increment the ref count, or fail.
  The fput() would decrement the refcnt.  The last fput() triggers
 -release() (which then in turn decrements the ref count of the
 original gem buffer object, etc).

oh, and userspace would close the fd when it no longer needs it..  in
case of prime, once you've done fd-handle, how the handle holds a ref
to the imported buffer so you can close the fd.

Other subsystems, it may be different.. if you're repeatedly passing
the fd into the driver each time you use the buffer (ie. no gem handle
or similar) then userspace would need to keep the fd open so they have
it to pass back in to the driver the each time.. v4l2 is working this
way

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

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk changed:

   What|Removed |Added

  Attachment #58481|0   |1
is obsolete||

--- Comment #36 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-16 
06:57:03 PDT ---
Created attachment 58555
  -- https://bugs.freedesktop.org/attachment.cgi?id=58555
Donot probe extensively if HPD hasn't changed on R600+ ASICs

Now, with these last two patches things should look better for us you think? 

Problem I have now is that with VGA connected to this DVI-I as soon as KMS
kicks in (radeon.ko loads) monitor goes to power save. Even after X is running
and xrandr shows that a mode is active, monitor is still off. This is caused
purely by the Fujitsu quirk patch.

Same symptoms if I boot on DVI and then plug VGA later. Although in this case
it may be a different cause. When I unplug the DVI connector goes into the
unknown state. This is because ext_encoder test radeon_atom_dig_detect fails.
And Xorg sees that as unknown status but show an active mode while monitor is
firmly in power save.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 47007] HDMI monitor polling causing 100ms rendering stalls

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #58554|0   |1
is obsolete||

--- Comment #37 from Alex Deucher ag...@yahoo.com 2012-03-16 07:04:36 PDT ---
Created attachment 58556
  -- https://bugs.freedesktop.org/attachment.cgi?id=58556
add quirk for fujitsu board

(In reply to comment #35)
 Created attachment 58554 [details] [review]
 Correctly identify connector on Fujitsu D3003-S2 board

The patch is not quite correct.  You dropped the VGA connect, but did not
associate the dac with the new DVI-I connector.  I think this patch should fix
that.  This may be the cause of the problems you were seeing.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 47407] System unable to recover from suspend to disk

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/Gallium/r600|DRM/Radeon

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 47007] HDMI monitor polling causing 100ms rendering stalls