Re: [inconsistent HARDIRQ usage] &dev->mode_config.idr_mutex at drm_mode_object_find()

[Maarten Lankhorst]

Op 10-06-13 03:55, Fengguang Wu schreef:
> Maarten,
>
> Sorry for the delay!
>
> On Sun, Jun 09, 2013 at 08:58:44AM +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 06-06-13 09:28, Fengguang Wu schreef:
>>> Hi Maarten,
>>>
>>> Thanks for the patch! I'll queue it for the tests.
>>>
>>> 
>> I haven't heard back from you yet, did it fix all lockdep issues you were 
>> having?
>> If so I'll get it queued.
> Booted 1000 kernels with the patch, I no longer see the
> mutex_trylock() warning. However there is one single occurrence of
> this warning. Not sure how relevant it is.
>
> [  347.858442] =
> [  347.858442] [ INFO: inconsistent lock state ]
> [  347.858442] 3.9.0-rc5-00675-ga35505b #60 Not tainted
> [  347.858442] -
> [  347.858442] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [  347.858442] umount/122 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [  347.858442]  (&dev->mode_config.idr_mutex){?.+.+.}, at: 
> [] drm_mode_object_find+0xf2/0x110
>
> Thanks,
> Fengguang
>
> PS. full dmesg.
> 
> [  309.914133] raid6test: complete (257 tests, 0 failures)
> [  310.338146]   Magic number: 1:250:706
> [  310.458434] tty ttySL122: hash matches
> [  310.589995] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
> [  310.709702] EDD information not available.
> [  310.906183] ALSA device list:
> [  311.026184]   #0: Dummy 1
> [  311.153927]   #1: Loopback 1
> [  311.277938]   #2: MTPAV on parallel port at 0x378
> [  312.230916] Freeing unused kernel memory: 1052k freed
> [  323.435915] hostname (110) used greatest stack depth: 5080 bytes left
> [  347.855138] BUG: soft lockup - CPU#0 stuck for 22s! [umount:122]
> [  347.858442] irq event stamp: 4246
> [  347.858442] hardirqs last  enabled at (4245): [] 
> mutex_lock_nested+0x380/0x3b0
> [  347.858442] hardirqs last disabled at (4246): [] 
> common_interrupt+0x6d/0x72
> [  347.858442] softirqs last  enabled at (4214): [] 
> __do_softirq+0x242/0x2c0
> [  347.858442] softirqs last disabled at (4175): [] 
> irq_exit+0x63/0xd0
> [  347.858442] CPU 0 
> [  347.858442] Pid: 122, comm: umount Not tainted 3.9.0-rc5-00675-ga35505b 
> #60 Bochs Bochs
> [  347.858442] RIP: 0010:[]  [] 
> mutex_lock_nested+0x386/0x3b0
> [  347.858442] RSP: 0018:8800055ebb48  EFLAGS: 0246
> [  347.858442] RAX: 8800055c6840 RBX: 81130fdb RCX: 
> 0006
> [  347.858442] RDX: 0006 RSI: 8800055c6f20 RDI: 
> 0246
> [  347.858442] RBP: 8800055ebbd8 R08:  R09: 
> 0002
> [  347.858442] R10:  R11:  R12: 
> 8800055c6840
> [  347.858442] R13: 0006 R14: 0007 R15: 
> 8800055c6f20
> [  347.858442] FS:  () GS:88000de0() 
> knlGS:
> [  347.858442] CS:  0010 DS:  ES:  CR0: 8005003b
> [  347.858442] CR2: 7ffc9b7ce09c CR3: 055a2000 CR4: 
> 06f0
> [  347.858442] DR0:  DR1:  DR2: 
> 
> [  347.858442] DR3:  DR6:  DR7: 
> 
> [  347.858442] Process umount (pid: 122, threadinfo 8800055ea000, task 
> 8800055c6840)
> [  347.858442] Stack:
> [  347.858442]  811d3991 7ffc9b7b7fff 7ffc9b7b7fff 
> 7ffc9b7b8000
> [  347.858442]  8800055a2800 7ffc9b7b7fff 88000b975a98 
> 0246
> [  347.858442]  8800055ebb88 8800055ebb88  
> 8800055ebb88
> [  347.858442] Call Trace:
> [  347.858442]  [] ? unlink_file_vma+0x41/0x70
> [  347.858442]  [] unlink_file_vma+0x41/0x70
> [  347.858442]  [] free_pgtables+0x47/0xe0
> [  347.858442]  [] unmap_region+0xdf/0x110
> [  347.858442]  [] ? vma_rb_erase+0x1c9/0x210
> [  347.858442]  [] do_munmap+0x2c2/0x3d0
> [  347.858442]  [] mmap_region+0x596/0x660
> [  347.858442]  [] ? vma_adjust+0x6a7/0x730
> [  347.858442]  [] ? cap_mmap_addr+0x5/0x50
> [  347.858442]  [] do_mmap_pgoff+0x2e2/0x3b0
> [  347.858442]  [] vm_mmap_pgoff+0x75/0xb0
> [  347.858442]  [] ? fget+0x5/0x120
> [  347.858442]  [] sys_mmap_pgoff+0x13b/0x180
> [  347.858442]  [] sys_mmap+0x22/0x30
> [  347.858442]  [] system_call_fastpath+0x16/0x1b
> [  347.858442] Code: 80 47 08 01 48 f7 45 a8 00 02 00 00 75 12 48 8b 7d a8 57 
> 9d 66 66 90 66 90 e8 97 4e 1d ff eb 10 e8 b0 4d 1d ff 48 8b 7d a8 57 9d <66> 
> 66 90 66 90 48 89 df e8 0d 21 1d ff 41 83 6d 1c 01 48 83 c4 
> [  347.858442] Kernel panic - not syncing: softlockup: hung tasks
> [  347.858442] Pid: 122, comm: umount Not tainted 3.9.0-rc5-00675-ga35505b #60
> [  347.858442] Call Trace:
> [  347.858442][] panic+0xc6/0x1d3
> [  347.858442]  [] watchdog_timer_fn+0x172/0x1c0
> [  347.858442]  [] __run_hrtimer+0x131/0x320
> [  347.858442]  [] ? watchdog+0x30/0x30
> [  347.858442]  [] hrtimer_interrupt+0x129/0x230
> [  347.858442]  [] ? put_cred_rcu+0x74/0x80
> [  347.858442]  [] ? rcu_process_callbacks+0x5a9/0x8c0
> 

[PATCH] drm/cirrus: do not attempt to acquire a reservation while in an interrupt handler

[Maarten Lankhorst]

Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:

[   13.044313] [ cut here ]
[   13.044367] WARNING: at /c/kernel-tests/src/tip/kernel/mutex.c:858 
mutex_trylock+0x87/0x220()
[   13.044378] DEBUG_LOCKS_WARN_ON(in_interrupt())
[   13.044378] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
3.10.0-rc4-00296-ga2963dd #20
[   13.044379] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   13.044390]  0009 88000de039f8 81fc86d5 
88000de03a38
[   13.044395]  810d511b 8818 88000f33c690 
0001
[   13.044398]  03f0 88000f4677c8  
88000de03a98
[   13.044400] Call Trace:
[   13.044412][] dump_stack+0x19/0x1b
[   13.01]  [] warn_slowpath_common+0x6b/0x90
[   13.05]  [] warn_slowpath_fmt+0x46/0x50
[   13.08]  [] mutex_trylock+0x87/0x220
[   13.044482]  [] cirrus_dirty_update+0x1cd/0x330
[   13.044486]  [] cirrus_imageblit+0x38/0x50
[   13.044506]  [] soft_cursor+0x22e/0x240
[   13.044510]  [] bit_cursor+0x581/0x5b0
[   13.044525]  [] ? vsnprintf+0x124/0x670
[   13.044529]  [] ? get_color.isra.16+0x43/0x130
[   13.044532]  [] fbcon_cursor+0x18a/0x1d0
[   13.044535]  [] ? update_attr.isra.2+0xa0/0xa0
[   13.044556]  [] hide_cursor+0x32/0xa0
[   13.044565]  [] vt_console_print+0x103/0x3b0
[   13.044569]  [] ? print_time+0x9c/0xb0
[   13.044576]  [] ? print_prefix+0xa0/0xc0
[   13.044580]  [] 
call_console_drivers.constprop.6+0x146/0x1f0
[   13.044593]  [] ? do_raw_spin_unlock+0xc8/0x100
[   13.044597]  [] console_unlock+0x2f7/0x460
[   13.044600]  [] vprintk_emit+0x59a/0x5e0
[   13.044615]  [] printk+0x4d/0x4f
[   13.044650]  [] print_local_APIC+0x28/0x41c
[   13.044672]  [] 
generic_smp_call_function_single_interrupt+0x145/0x2b0
[   13.044688]  [] 
smp_call_function_single_interrupt+0x27/0x40
[   13.044697]  [] call_function_single_interrupt+0x72/0x80
[   13.044707][] ? native_safe_halt+0x6/0x10
[   13.044717]  [] ? trace_hardirqs_on+0xd/0x10
[   13.044738]  [] default_idle+0x59/0x120
[   13.044742]  [] arch_cpu_idle+0x18/0x40
[   13.044754]  [] cpu_startup_entry+0x235/0x410
[   13.044763]  [] rest_init+0xd1/0xe0
[   13.044766]  [] ? rest_init+0x5/0xe0
[   13.044778]  [] start_kernel+0x425/0x493
[   13.044781]  [] ? repair_env_string+0x5e/0x5e
[   13.044786]  [] x86_64_start_reservations+0x2a/0x2c
[   13.044789]  [] x86_64_start_kernel+0xf1/0x100
[   13.044799] ---[ end trace 113ad28772af4058 ]---

Reported-by: Fengguang Wu 
Signed-off-by: Maarten Lankhorst 

---
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 3541b56..b27e956 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -25,7 +25,7 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
struct cirrus_bo *bo;
int src_offset, dst_offset;
int bpp = (afbdev->gfb.base.bits_per_pixel + 7)/8;
-   int ret;
+   int ret = -EBUSY;
bool unmap = false;
bool store_for_later = false;
int x2, y2;
@@ -39,7 +39,8 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
 * then the BO is being moved and we should
 * store up the damage until later.
 */
-   ret = cirrus_bo_reserve(bo, true);
+   if (!in_interrupt())
+   ret = cirrus_bo_reserve(bo, true);
if (ret) {
if (ret != -EBUSY)
return;

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

Re: [inconsistent HARDIRQ usage] &dev->mode_config.idr_mutex at drm_mode_object_find()

[Daniel Vetter]

On Mon, Jun 10, 2013 at 9:04 AM, Maarten Lankhorst
 wrote:
> ^ Stacktrace points at the warning being called from panic. At that point I 
> no longer trust anything to be sane.
> I don't know much about the panic handling in drm, but it's definitely not 
> related to your original issue.

The locking in the current drm panic handler is pretty much terminally
broken. At best we're trying not too flood dmesg too badly when it
happens.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

[Daniel Vetter]

On Sun, Jun 09, 2013 at 07:01:39PM -0400, Matthew Garrett wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the ACPI
> backlight interface on these systems.
> 
> Signed-off-by: Matthew Garrett 

Make sense and I guess it's easier to merge this all through the acpi
tree. So

Acked-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   /* Must be done after probing outputs */
>   intel_opregion_init(dev);
>   acpi_video_register();
> + /* Don't use ACPI backlight functions on Windows 8 platforms */
> + if (acpi_osi_version() >= ACPI_OSI_WIN_8)
> + acpi_video_backlight_unregister();
>   }
>  
>   if (IS_GEN5(dev))
> -- 
> 1.8.2.1
> 

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

[PATCH v2] drm: Print pretty names for pixel formats

[ville . syrjala]

From: Ville Syrjälä 

Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.

Keep printing the raw hex number too in case it contains non-printable
characters.

Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"

v2: Fix patch author

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_crtc.c | 29 +++--
 include/drm/drm_crtc.h |  1 +
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..079996a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -29,6 +29,7 @@
  *  Dave Airlie 
  *  Jesse Barnes 
  */
+#include 
 #include 
 #include 
 #include 
@@ -252,6 +253,28 @@ char *drm_get_connector_status_name(enum 
drm_connector_status status)
 }
 EXPORT_SYMBOL(drm_get_connector_status_name);
 
+static char printable_char(int c)
+{
+   return isascii(c) && isprint(c) ? c : '?';
+}
+
+char *drm_get_format_name(uint32_t format)
+{
+   static char buf[32];
+
+   snprintf(buf, sizeof(buf),
+"%c%c%c%c %s-endian (0x%08x)",
+printable_char(format & 0xff),
+printable_char((format >> 8) & 0xff),
+printable_char((format >> 16) & 0xff),
+printable_char((format >> 24) & 0x7f),
+format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
+format);
+
+   return buf;
+}
+EXPORT_SYMBOL(drm_get_format_name);
+
 /**
  * drm_mode_object_get - allocate a new modeset identifier
  * @dev: DRM device
@@ -1834,7 +1857,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
if (fb->pixel_format == plane->format_types[i])
break;
if (i == plane->format_count) {
-   DRM_DEBUG_KMS("Invalid pixel format 0x%08x\n", 
fb->pixel_format);
+   DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(fb->pixel_format));
ret = -EINVAL;
goto out;
}
@@ -2312,7 +2336,8 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)
 
ret = format_check(r);
if (ret) {
-   DRM_DEBUG_KMS("bad framebuffer format 0x%08x\n", 
r->pixel_format);
+   DRM_DEBUG_KMS("bad framebuffer format %s\n",
+ drm_get_format_name(r->pixel_format));
return ret;
}
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..2cbbfd4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1094,5 +1094,6 @@ extern int drm_format_num_planes(uint32_t format);
 extern int drm_format_plane_cpp(uint32_t format, int plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
+extern char *drm_get_format_name(uint32_t format);
 
 #endif /* __DRM_CRTC_H__ */
-- 
1.8.1.5

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

Re: [PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation

[Rahul Sharma]

This patch is already posted at
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg18331.html
and

Reviewed-by: Doug Anderson 

On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma  wrote:
> From: Arun Kumar K 
>
> This patch corrects the HDMI clock number given wrongly
> in the documentation.
>
> Signed-off-by: Arun Kumar K 
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 781a627..1a05761 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -154,7 +154,7 @@ clock which they consume.
>dsim0341
>dp   342
>mixer343
> -  hdmi 345
> +  hdmi 344
>
>  Example 1: An example of a clock controller node is listed below.
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/exynos: hdmi: use drm_display_mode to check the supported modes

[Rahul Sharma]

This patch renames check_timing to check_mode and removes the
unnecessary conversion of drm_display_mode to/from fb_videomode in
the hdmi driver.

v4:
1) Changed the commit message to add information related to renaming
the callbacks to check_mode.
2) Changed debug message to print 1/0 for interlace mode.

v3:
1) Replaced check_timing callbacks with check_mode.
2) Change the type of second parameter of check_mode callback from void
pointer paramenter to struct drm_display_mode pointer.

v2:
1) Removed convert_to_video_timing().
2) Corrected DRM_DEBUG_KMS to print the resolution properly.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   38 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |4 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |4 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   17 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |6 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |4 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   29 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |   15 +-
 8 files changed, 41 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ab3c6d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -58,37 +58,6 @@ convert_to_display_mode(struct drm_display_mode *mode,
mode->flags |= DRM_MODE_FLAG_DBLSCAN;
 }
 
-/* convert drm_display_mode to exynos_video_timings */
-static inline void
-convert_to_video_timing(struct fb_videomode *timing,
-   struct drm_display_mode *mode)
-{
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
-   memset(timing, 0, sizeof(*timing));
-
-   timing->pixclock = mode->clock * 1000;
-   timing->refresh = drm_mode_vrefresh(mode);
-
-   timing->xres = mode->hdisplay;
-   timing->right_margin = mode->hsync_start - mode->hdisplay;
-   timing->hsync_len = mode->hsync_end - mode->hsync_start;
-   timing->left_margin = mode->htotal - mode->hsync_end;
-
-   timing->yres = mode->vdisplay;
-   timing->lower_margin = mode->vsync_start - mode->vdisplay;
-   timing->vsync_len = mode->vsync_end - mode->vsync_start;
-   timing->upper_margin = mode->vtotal - mode->vsync_end;
-
-   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   timing->vmode = FB_VMODE_INTERLACED;
-   else
-   timing->vmode = FB_VMODE_NONINTERLACED;
-
-   if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
-   timing->vmode |= FB_VMODE_DOUBLE;
-}
-
 static int exynos_drm_connector_get_modes(struct drm_connector *connector)
 {
struct exynos_drm_connector *exynos_connector =
@@ -168,15 +137,12 @@ static int exynos_drm_connector_mode_valid(struct 
drm_connector *connector,
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
-   struct fb_videomode timing;
int ret = MODE_BAD;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
-   convert_to_video_timing(&timing, mode);
-
-   if (display_ops && display_ops->check_timing)
-   if (!display_ops->check_timing(manager->dev, (void *)&timing))
+   if (display_ops && display_ops->check_mode)
+   if (!display_ops->check_mode(manager->dev, mode))
ret = MODE_OK;
 
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 680a7c1..eaa1966 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -142,7 +142,7 @@ struct exynos_drm_overlay {
  * @is_connected: check for that display is connected or not.
  * @get_edid: get edid modes from display driver.
  * @get_panel: get panel object from display driver.
- * @check_timing: check if timing is valid or not.
+ * @check_mode: check if mode is valid or not.
  * @power_on: display device on or off.
  */
 struct exynos_drm_display_ops {
@@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
struct edid *(*get_edid)(struct device *dev,
struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
-   int (*check_timing)(struct device *dev, void *timing);
+   int (*check_mode)(struct device *dev, struct drm_display_mode *mode);
int (*power_on)(struct device *dev, int mode);
 };
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 279c3f8..d33e17d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -153,7 +153,7 @@ static void *fimd_get_panel(struct device *dev)
return ctx->panel;
 }
 
-static int fimd_check_ti

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

[joeyli]

於 日，2013-06-09 於 19:01 -0400，Matthew Garrett 提到：
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the ACPI
> backlight interface on these systems.
> 
> Signed-off-by: Matthew Garrett 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   /* Must be done after probing outputs */
>   intel_opregion_init(dev);
>   acpi_video_register();
> + /* Don't use ACPI backlight functions on Windows 8 platforms */
> + if (acpi_osi_version() >= ACPI_OSI_WIN_8)
> + acpi_video_backlight_unregister();
>   }
>  
>   if (IS_GEN5(dev))

This patch set works to me on Acer Aspire V3 notebook for unregister the
backlight interface of acpi video driver when i915 loaded. Acer Aspire
V3 has the Windows8 support in DSDT.

Tested-by: Lee, Chun-Yi 


Thanks a lot!
Joey Lee

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

[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem

[Rahul Sharma]

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

Arun Kumar K (1):
  clk/exynos5250: Fix HDMI clock number in documentation

Rahul Sharma (4):
  clk/exynos5250: add mout_hdmi mux clock for hdmi
  clk/exynos5250: add sclk_hdmiphy in the list of special clocks
  clk/exynos5250: add clock for tv sysmmu
  clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

 .../devicetree/bindings/clock/exynos5250-clock.txt   |   12 +++-
 drivers/clk/samsung/clk-exynos5250.c |   18 +-
 2 files changed, 24 insertions(+), 6 deletions(-)

-- 
1.7.10.4

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

[PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation

[Rahul Sharma]

From: Arun Kumar K 

This patch corrects the HDMI clock number given wrongly
in the documentation.

Signed-off-by: Arun Kumar K 
Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..1a05761 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,7 @@ clock which they consume.
   dsim0341
   dp   342
   mixer343
-  hdmi 345
+  hdmi 344
 
 Example 1: An example of a clock controller node is listed below.
 
-- 
1.7.10.4

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

[PATCH 2/5] clk/exynos5250: add mout_hdmi mux clock for hdmi

[Rahul Sharma]

hdmi driver needs to change the parent of hdmi clock
frequently between pixel clock and hdmiphy clock. hdmiphy is
not stable after power on and for a short interval while changing
the phy configuration. For this duration pixel clock is used to
clock hdmi.

This patch is exposing the mux for changing parent.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |8 
 drivers/clk/samsung/clk-exynos5250.c |5 -
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 1a05761..b337147 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -156,6 +156,14 @@ clock which they consume.
   mixer343
   hdmi 344
 
+
+   [Clock Muxes]
+
+  ClockID
+  
+  mout_hdmi1024
+
+
 Example 1: An example of a clock controller node is listed below.
 
clock: clock-controller@0x1001 {
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 5c97e75..587d913 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -100,6 +100,9 @@ enum exynos5250_clks {
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
 
+   /* mux clocks */
+   mout_hdmi = 1024,
+
nr_clks,
 };
 
@@ -231,7 +234,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = 
{
MUX(none, "mout_fimd1", mout_group1_p, SRC_DISP1_0, 0, 4),
MUX(none, "mout_mipi1", mout_group1_p, SRC_DISP1_0, 12, 4),
MUX(none, "mout_dp", mout_group1_p, SRC_DISP1_0, 16, 4),
-   MUX(none, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
+   MUX(mout_hdmi, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
MUX(none, "mout_audio0", mout_audio0_p, SRC_MAU, 0, 4),
MUX(none, "mout_mmc0", mout_group1_p, SRC_FSYS, 0, 4),
MUX(none, "mout_mmc1", mout_group1_p, SRC_FSYS, 4, 4),
-- 
1.7.10.4

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

[PATCH 3/5] clk/exynos5250: add sclk_hdmiphy in the list of special clocks

[Rahul Sharma]

hdmi driver needs hdmiphy clock which is one of the parent
for hdmi mux clock. This is required while changing the parent
of mux clock.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
 drivers/clk/samsung/clk-exynos5250.c |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index b337147..f333d61 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -59,6 +59,7 @@ clock which they consume.
   sclk_spi0154
   sclk_spi1155
   sclk_spi2156
+  sclk_hdmiphy 157
 
 
[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 587d913..88cdb13 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -87,6 +87,7 @@ enum exynos5250_clks {
sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
+   sclk_hdmiphy,
 
/* gate clocks */
gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
@@ -199,7 +200,7 @@ struct samsung_fixed_rate_clock 
exynos5250_fixed_rate_ext_clks[] __initdata = {
 
 /* fixed rate clocks generated inside the soc */
 struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
-   FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
+   FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 2700),
FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 4800),
-- 
1.7.10.4

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

[PATCH 4/5] clk/exynos5250: add clock for tv sysmmu

[Rahul Sharma]

Adding sysmmu clock for tv for exynos5250 SoC. It also
adds aclk200_disp1 mux which is the actual parent of the
disp1 block (contains hdmi, mixer, sysmmu_tv).

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
 drivers/clk/samsung/clk-exynos5250.c |6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index f333d61..f1c7e7f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -156,6 +156,7 @@ clock which they consume.
   dp   342
   mixer343
   hdmi 344
+  smmu_tv  345
 
 
[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 88cdb13..bb93d61 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -24,6 +24,7 @@
 #define SRC_CORE1  0x4204
 #define SRC_TOP0   0x10210
 #define SRC_TOP2   0x10218
+#define SRC_TOP3   0x1021C
 #define SRC_GSCL   0x10220
 #define SRC_DISP1_00x1022c
 #define SRC_MAU0x10240
@@ -99,7 +100,7 @@ enum exynos5250_clks {
spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
-   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, smmu_tv,
 
/* mux clocks */
mout_hdmi = 1024,
@@ -172,6 +173,7 @@ PNAME(mout_mpll_user_p) = { "fin_pll", "sclk_mpll" };
 PNAME(mout_bpll_user_p)= { "fin_pll", "sclk_bpll" };
 PNAME(mout_aclk166_p)  = { "sclk_cpll", "sclk_mpll_user" };
 PNAME(mout_aclk200_p)  = { "sclk_mpll_user", "sclk_bpll_user" };
+PNAME(mout_aclk200_disp1_sub_p) = { "fin_pll", "aclk200" };
 PNAME(mout_hdmi_p) = { "div_hdmi_pixel", "sclk_hdmiphy" };
 PNAME(mout_usb3_p) = { "sclk_mpll_user", "sclk_cpll" };
 PNAME(mout_group1_p)   = { "fin_pll", "fin_pll", "sclk_hdmi27m",
@@ -227,6 +229,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = 
{
MUX(none, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(none, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(none, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+   MUX(none, "aclk200_disp1", mout_aclk200_disp1_sub_p, SRC_TOP3, 4, 1),
MUX(none, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
MUX(none, "mout_cam0", mout_group1_p, SRC_GSCL, 16, 4),
MUX(none, "mout_cam1", mout_group1_p, SRC_GSCL, 20, 4),
@@ -328,6 +331,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata 
= {
GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
+   GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
-- 
1.7.10.4

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

[PATCH 5/5] clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

[Rahul Sharma]

parent of hdmi and mixer block is mentioned as aclk200 which is
not correct. It is clocked by the ouput of aclk200_disp1. Hence
parent for mixer and hdmi clocks is changed to aclk200_disp1.

Signed-off-by: Rahul Sharma 
---
 drivers/clk/samsung/clk-exynos5250.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index bb93d61..2075f5f 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -468,8 +468,8 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata 
= {
GATE(mie1, "mie1", "aclk200", GATE_IP_DISP1, 1, 0, 0),
GATE(dsim0, "dsim0", "aclk200", GATE_IP_DISP1, 3, 0, 0),
GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
-   GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
-   GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+   GATE(mixer, "mixer", "aclk200_disp1", GATE_IP_DISP1, 5, 0, 0),
+   GATE(hdmi, "hdmi", "aclk200_disp1", GATE_IP_DISP1, 6, 0, 0),
 };
 
 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.10.4

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

Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems

[Rafael J. Wysocki]

Hi Matthew,

On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest
> thing to do would be to just disable ACPI backlight control entirely if the
> firmware indicates Windows 8 support, but it's entirely possible that
> individual graphics drivers might still make use of the ACPI functionality in
> preference to native control.
> 
> The first two patches in this series are picked from other patchesets aimed at
> solving similar problems. The last simply unregisters ACPI backlight control
> on Windows 8 systems when using an Intel GPU. Similar code could be added to
> other drivers, but I'm reluctant to do so without further investigation as
> to the behaviour of the vendor drivers under Windows.

I happen to know that alternative solution to this problem is being worked on,
so I'm going to wait until it is submitted and then we'll decide what to merge.

I'm slightly concerned about unregistering ACPI backlight control for all
systems declaring win8 support, even though it may actually work for them.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/6/6 Joonyoung Shim 

> On 06/06/2013 03:14 AM, Tomasz Figa wrote:
>
>> On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
>>
>>> Hi,
>>>
>>> On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
>>>
 Much of the code in Exynos DRM subsystem is generic enough to use
 it for older (non-Exynos) Samsung SoCs as well, after minor
 modifications.

 This series starts adding support for previous SoCs to Exynos DRM by
 introducing S3C64xx support to exynos_drm_fimd driver.

 Adding support for remaining SoCs between S3C64xx and Exynos4
 (S5PC100,
 S5P64x0 and S5PV210) should be rather straightforward, but at the
 moment I can test only on S3C6410, so I limited my changes only to
 this SoC.

 On Tiny6410 (Mini6410-compatible) board based on Samsung S3C6410 SoC,
 using my to-be-resubmitted patches for Device Tree support:

 Tested-by: Tomasz Figa 

 Tomasz Figa (4):
drm/exynos: fimd: Hold pointer to driver data in context struct
drm/exynos: fimd: Add support for FIMD versions without SHADOWCON
 register
   drm/exynos: fimd: Add support for FIMD variants with clock
 selection
drm/exynos: fimd: Add support for S3C64xx SoCs
 drivers/gpu/drm/exynos/exynos_**drm_fimd.c | 90

 --**-- 1 file changed, 68 insertions(+), 22
 deletions(-)

>>> Any comments for this series?
>>>
>>> Best regards,
>>> Tomasz
>>>
>> Ping.
>>
>> Best regards,
>> Tomasz
>>
>>
>>
> This series looks good to me.
>
> Acked-by: Joonyoung Shim 
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  
> http://vger.kernel.org/**majordomo-info.html
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Sebastian Hesselbarth]

On 06/09/13 21:29, Russell King wrote:

This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs.  This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
   acceleration
- dual lcd0 and lcd1 crt operation
- video overlay on each LCD crt
- page flipping of the main scanout buffers

Included in this commit is the core driver with no output support; output
support is platform and encoder driver dependent.

Signed-off-by: Russell King 
---

[...]

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
new file mode 100644
index 000..e5ab4cb
--- /dev/null
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -0,0 +1,766 @@
+/*
+ * Copyright (C) 2012 Russell King
+ *  Rewritten from the dovefb driver, and Armada510 manuals.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */

[...]

+static void armada_drm_crtc_update(struct armada_crtc *dcrtc)
+{
+   uint32_t dumb_ctrl;
+
+   dumb_ctrl = dcrtc->cfg_dumb_ctrl;
+
+   if (!dpms_blanked(dcrtc->dpms))
+   dumb_ctrl |= CFG_DUMB_ENA;
+
+   /*
+* When a dumb interface isn't under 24bit, it might be
+* under SPI or GPIO.  If set to 7, this will force
+* LCD_D[23:0] to output blank color and damage GPIO
+* and SPI behaviour.  So leave it as-is unless in
+* DUMB24_RGB888_0 mode.
+*/
+   if (dpms_blanked(dcrtc->dpms) &&
+   (dumb_ctrl & DUMB_MASK) == DUMB24_RGB888_0) {
+   dumb_ctrl &= ~DUMB_MASK;
+   dumb_ctrl |= DUMB_BLANK;
+   }
+
+   /*
+* The spec is unclear about the polarities of the syncs.
+* We assume their non-inverted state is active high.
+*/


nit: "We confirmed their non-inverted state is active high."


+   if (dcrtc->crtc.mode.flags & DRM_MODE_FLAG_NCSYNC)
+   dumb_ctrl |= CFG_INV_CSYNC;
+   if (dcrtc->crtc.mode.flags & DRM_MODE_FLAG_NHSYNC)
+   dumb_ctrl |= CFG_INV_HSYNC;
+   if (dcrtc->crtc.mode.flags & DRM_MODE_FLAG_NVSYNC)
+   dumb_ctrl |= CFG_INV_VSYNC;
+
+   if (dcrtc->dumb_ctrl != dumb_ctrl) {
+   dcrtc->dumb_ctrl = dumb_ctrl;
+   writel_relaxed(dumb_ctrl, dcrtc->base + LCD_SPU_DUMB_CTRL);
+   }
+}

[...]

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
new file mode 100644
index 000..bb70cf5
--- /dev/null
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -0,0 +1,326 @@
+/*
+ * Copyright (C) 2012 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "armada_crtc.h"
+#include "armada_drm.h"
+#include "armada_gem.h"
+#include "armada_hw.h"
+#include "armada_ioctl.h"
+#include "armada_ioctlP.h"
+
+static int armada_drm_load(struct drm_device *dev, unsigned long flags)
+{
+   struct armada_private *priv;
+   struct resource *res[ARRAY_SIZE(priv->dcrtc)];
+   struct resource *mem = NULL;
+   int ret, n, i;
+
+   memset(res, 0, sizeof(res));
+
+   for (n = i = 0; ; n++) {
+   struct resource *r = platform_get_resource(dev->platformdev,
+  IORESOURCE_MEM, n);
+   if (!r)
+   break;
+
+   if (resource_size(r) > SZ_4K)
+   mem = r;


nit again: The register address window of Dove LCD is 64k although you 
are right an no more than 512B are used. Also a comment would be nice,

that everything above 4k (64k) is interpreted as gfx mem.


+   else if (i < ARRAY_SIZE(priv->dcrtc))
+   res[i++] = r;
+   else
+   return -EINVAL;
+   }
+
+   if (!res[0] || !mem)
+   return -ENXIO;
+
+   if (!devm_request_mem_region(dev->dev, mem->start,
+   resource_size(mem), "armada-drm"))
+   return -EBUSY;
+
+   priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv) {
+   DRM_ERROR("failed to allocate private\n");
+   ret = -ENOMEM;
+   goto err_buf;
+   }
+
+   dev->dev_private = priv;
+
+   /* Mode setting support */
+   drm_mode_config_init(dev);
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+   dev->mode_config.max_width = 2048;
+   dev->mode_config.max_height = 2048;
+   dev->mode_config.preferred_depth = 24;
+   dev->mode_config.funcs = &armada_drm_mode_config_funcs;
+   drm_mm_init(&priv->linear, mem->start,

Re: [PATCH 0/2] drm/exynos: clean up logs for next tree

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/6/5 Seung-Woo Kim 

> This patch set removes tracking logs and function name duplications.
> This is for the next tree and based on exynos-drm-next branch.
>
> YoungJun Cho (2):
>   drm/exynos: Remove tracking log functions
>   drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS
>
>  drivers/gpu/drm/exynos/exynos_drm_buf.c   |7 -
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |   17 --
>  drivers/gpu/drm/exynos/exynos_drm_core.c  |   12 --
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   29 
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|6 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |   20 ---
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   28 +
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|   10 --
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |8 -
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  129 +++--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   46 +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |   23 ---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  102 +
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   42 -
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  201
> 
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |   16 --
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   53 +++-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   40 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |   42 +-
>  drivers/gpu/drm/exynos/exynos_mixer.c |   32 +
>  20 files changed, 193 insertions(+), 670 deletions(-)
>
> --
> 1.7.4.1
>
> ___
> 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: [RPC 0/21] DRM: Add VIA DRM driver

[Konrad Rzeszutek Wilk]

On Sat, Jun 08, 2013 at 05:42:20PM +0100, James Simmons wrote:
> 
> Hello
> 
>   Here is the first run at inspection of the VIA openchrome dri 
> driver. Now that the Xorg driver has been out over a year with KMS support
> most people should be able to use this feature. The driver is totaly 
> complete but we wanted to merge it so people with newer hardware that has 
> HDMI/DVI-D support can be able to run X windows. Your xorg driver does not 
> implement HDMI/DVI in UMS mode and we don't have the resources to do this 
> work. Basic TTM/GEM is supported but currently you can't run any 
> acceleration with the command queue. Over the next 6 months this should be 
> implemented. Thank you.

Hey James,

I am not entirely sure what happend but it looks like you are using
Alpine mailer to send out the patches. The sad end result is that
all of the patches have the "DRM: Add VIA DRM driver" title instead
of the more appropiate title within the email.

Could you repost them with 'git send-email' please?

This link http://kernelnewbies.org/OPWfirstpatch
at the "Submit a patch" section has an excellent tutorial on how
to use different mailers. The "Setup your tools" has a nice
tutorial on .gitconfig setup. If you would like to use
me as test subject and send emails to me before the mailing list
please do.

I usually have this in my .gitconfig file:

[konrad@build-external ~]$ more .gitconfig
[user]
name = Konrad Rzeszutek Wilk
email = konrad.w...@oracle.com
signingkey = F1DB09BF
[color]
branch = true
diff = true
[sendemail]
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpencryption = tls
smtpuser = ketuzs...@gmail.com

and for sending emails to myself I do:

konrad@phenom:~/linux$ git format-patch --subject-prefix="v4" HEAD^^..
0001-xen-ring-Add-a-new-macro-to-detect-whether-there-is-.patch
0002-xen-blkback-Check-for-insane-amounts-of-request-on-t.patch

then:
konrad@phenom:~/linux: git send-email --suppress-cc=all --to kon...@kernel.org 
--compose --annotate --subject "[PATCH v4] Safety harness for the block 
driver." *.patch

edit in vim the changes, look over all of the patches, and then send.

Lastly, is there a git tree with these patches so that one may
just in one swoop test them out?

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

[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  ---
Created attachment 80624
  --> https://bugs.freedesktop.org/attachment.cgi?id=80624&action=edit
don't register a radeon backlight

This patch should skip adding a radeon backlight interface on your mac.

-- 
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 65611] New: UVD accelerated decoding causes hangs (ARUBA - HD 7540D)

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 65611
  Assignee: dri-devel@lists.freedesktop.org
   Summary: UVD accelerated decoding causes hangs (ARUBA - HD
7540D)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: otaz...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 80626
  --> https://bugs.freedesktop.org/attachment.cgi?id=80626&action=edit
relevant dmesg output

New UVD VDPAU decoding of VC-1 and MPEG-2 causes some kind of corruption and
ultimately hang of driver and whole system on the next try (cursor can be
moving for some time, even SysRq can work a few seconds after X totally hangs
but then only power off works).

Few notes (using mplayer):
ffmpeg12vdpau:
MPEG1 causes no harm, only decoding is really bad (software decoding works)
MPEG2 seems to cause really bad corruption

ffvc1vdpau:
VC-1 seems to cause problems (like attached dmesg) but not hangs.  There have
been decoding artifacts too, but it is not the rule.

divx and h264 seems to work flawless, unless previous corruption happened.

Hardware is ARUBA - A6-5400K Black Edition APU (Radeon HD 7540D).  Since this
particular hardware seems to be problematic (#65254 #60389) it might be unique
to this APU.

Test files:
VC1 http://samples.mplayerhq.hu/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv
MPEG2 http://samples.mplayerhq.hu/MPEG2/vid_0x80.ts
MPEG1 http://samples.mplayerhq.hu/MPEG1/

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

Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

[Alex Deucher]

Radeon probably needs something similar.  See attached untested patch.

Alex

On Sun, Jun 9, 2013 at 7:01 PM, Matthew Garrett
 wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the ACPI
> backlight interface on these systems.
>
> Signed-off-by: Matthew Garrett 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
> /* Must be done after probing outputs */
> intel_opregion_init(dev);
> acpi_video_register();
> +   /* Don't use ACPI backlight functions on Windows 8 platforms 
> */
> +   if (acpi_osi_version() >= ACPI_OSI_WIN_8)
> +   acpi_video_backlight_unregister();
> }
>
> if (IS_GEN5(dev))
> --
> 1.8.2.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
From c6ead3429fd3977b4b2ee5748d83c72272592b29 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Mon, 10 Jun 2013 10:05:43 -0400
Subject: [PATCH] drm/radeon: don't provide ACPI backlight if firmware expects
 Windows 8

Windows 8 leaves backlight control up to individual graphics drivers rather
than making ACPI calls itself.

Untested.

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

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index 4120d35..bc9e007 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -233,6 +233,10 @@ void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
 
 	DRM_INFO("radeon atom DIG backlight initialized\n");
 
+	/* Don't use ACPI backlight functions on Windows 8 platforms */
+	if (acpi_osi_version() >= ACPI_OSI_WIN_8)
+		acpi_video_backlight_unregister();
+
 	return;
 
 error:
-- 
1.7.7.5

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

Re: [RPC 0/21] DRM: Add VIA DRM driver

[Daniel Vetter]

On Mon, Jun 10, 2013 at 09:31:38AM -0400, Konrad Rzeszutek Wilk wrote:
> On Sat, Jun 08, 2013 at 05:42:20PM +0100, James Simmons wrote:
> > 
> > Hello
> > 
> > Here is the first run at inspection of the VIA openchrome dri 
> > driver. Now that the Xorg driver has been out over a year with KMS support
> > most people should be able to use this feature. The driver is totaly 
> > complete but we wanted to merge it so people with newer hardware that has 
> > HDMI/DVI-D support can be able to run X windows. Your xorg driver does not 
> > implement HDMI/DVI in UMS mode and we don't have the resources to do this 
> > work. Basic TTM/GEM is supported but currently you can't run any 
> > acceleration with the command queue. Over the next 6 months this should be 
> > implemented. Thank you.
> 
> Hey James,
> 
> I am not entirely sure what happend but it looks like you are using
> Alpine mailer to send out the patches. The sad end result is that
> all of the patches have the "DRM: Add VIA DRM driver" title instead
> of the more appropiate title within the email.

At least in my mutt here the threading also seems to be broken ...
-Daniel

> 
> Could you repost them with 'git send-email' please?
> 
> This link http://kernelnewbies.org/OPWfirstpatch
> at the "Submit a patch" section has an excellent tutorial on how
> to use different mailers. The "Setup your tools" has a nice
> tutorial on .gitconfig setup. If you would like to use
> me as test subject and send emails to me before the mailing list
> please do.
> 
> I usually have this in my .gitconfig file:
> 
> [konrad@build-external ~]$ more .gitconfig
> [user]
> name = Konrad Rzeszutek Wilk
> email = konrad.w...@oracle.com
> signingkey = F1DB09BF
> [color]
> branch = true
> diff = true
> [sendemail]
> smtpserver = smtp.gmail.com
> smtpserverport = 587
> smtpencryption = tls
> smtpuser = ketuzs...@gmail.com
> 
> and for sending emails to myself I do:
> 
> konrad@phenom:~/linux$ git format-patch --subject-prefix="v4" HEAD^^..
> 0001-xen-ring-Add-a-new-macro-to-detect-whether-there-is-.patch
> 0002-xen-blkback-Check-for-insane-amounts-of-request-on-t.patch
> 
> then:
> konrad@phenom:~/linux: git send-email --suppress-cc=all --to 
> kon...@kernel.org --compose --annotate --subject "[PATCH v4] Safety harness 
> for the block driver." *.patch
> 
> edit in vim the changes, look over all of the patches, and then send.
> 
> Lastly, is there a git tree with these patches so that one may
> just in one swoop test them out?
> 
> Thanks!
> >  
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm/radeon: fix AVI infoframe generation

[Alex Deucher]

On Sat, Jun 8, 2013 at 7:46 AM, Rafał Miłecki  wrote:
> 2013/6/7  :
>> From: Alex Deucher 
>>
>> - remove adding 2 to checksum, this breaks certain monitors
>> - properly emit the AVI infoframe version, not emitting
>> the version breaks some monitors.
>>
>> This should fix blank screen when HDMI audio is enabled on
>> certain monitors.
>
> Err, nack. I believe this it actually going to *break* some monitors
> compatibility.
>
> For some unknown reason AMD hardware uses 0x81 and 0x01 for type and
> version of infoframe. See this comment (written/published by you):
> /* The following packets and infoframes are required for HDMI:
>  * Packets:
>  * 0x00 - Null packet
>  * 0x01 - Audio clock regen
>  * 0x02 - Audio sample
>  * 0x03 - General Control
>  * Infoframes:
>  * 0x81 0x01 - AVI
>  * 0x83 0x03 - audio
>  */
>
> As you can see, AMD hardware uses 0x81 and 0x01. I've no idea why,
> according to the HDMI standard it should be 0x82 and 0x02. All other
> vendors seems to also use 0x82 and 0x02. In function
> hdmi_avi_infoframe_init type it set to 0x82 and 0x02.
>
> This type and version it's written anywhere, but they are used to
> calculate checksum. Checksum it what we store is frame[0x0]. We
> calculate checksum as 0x100 - sum (see hdmi_infoframe_checksum).
>
> Now... with common drm code we use 0x82 and 0x02 instead of 0x81 and
> 0x01. It means our "sum" is too big by 0x02. It means we have to use
> 0x100 - sum + 0x02 as checksum for AMD hardware.
>
> This whole hack was introduced in 92db7f6c860b8190571a9dc1fcbc16d003422fe8:
> drm/radeon/kms: workaround invalid AVI infoframe checksum issue
> and I'm pretty sure it was verified to fix somebody's HDMI mode. It
> also seems to be compatible with AMD specs (at least the part of it we
> can see in the quoted comment).
>
> For proof of fglrx doing the same, please see my e-mail where I
> provided dumps from registers when using fglrx:
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html
> (it was tested on 5 different cards!).

Actually, I think the patch is correct.  I think you were adding the
version twice:  From your examples:
[Rafał Miłecki][RV620] fglrx:
0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0
0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2
0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x1F8 = 0x289
-0x289 = 0x77

The payload sum is not 0x1f8, it's 0x1f6.
00 + A8 + 5E + 00 +
00 + 28 + 00 + 10 +
00 + 48 + 00 + 28 +
00 + 48 =
0x1f6

Bits 25:24 of HDMI_VIDEOINFOFRAME_3 are the packet version, not part
of the payload.  So the total would be:
(0x82 + 0x2 + 0xD) + 0x1f6 = 0x287
-0x287 = 0x79

I think the issue is that we are not setting the version in bits 25:24
of HDMI_VIDEOINFOFRAME_3 so we were sending a version 0 AVI packet.

Alex

>
> When working on that patch I was talking & debugging with few people
> on IRC. That mean I don't have logs anymore, but I'm sure I was
> testing exactly that single value and it was immediately fixing
> selected displays. I mean testing by writing something like:
>
> avivotool regset 0x10884 0x00a85e4f
> vs.
> avivotool regset 0x10884 0x00a85e4d
>
> --
> Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Sun, Jun 9, 2013 at 3:29 PM, Russell King
 wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs.  This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>   acceleration
> - dual lcd0 and lcd1 crt operation
> - video overlay on each LCD crt

Any particular reason for not exposing the overlays as drm_plane's?
That is probably something that should change before merging the
driver.

Other than that, it looks reasonably good, with just a few (mostly
minor) comments below.

> - page flipping of the main scanout buffers
>
> Included in this commit is the core driver with no output support; output
> support is platform and encoder driver dependent.
>
> Signed-off-by: Russell King 
> ---

[snip]

> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> new file mode 100644
> index 000..e5ab4cb
> --- /dev/null
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -0,0 +1,766 @@
> +/*
> + * Copyright (C) 2012 Russell King
> + *  Rewritten from the dovefb driver, and Armada510 manuals.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include "armada_crtc.h"
> +#include "armada_drm.h"
> +#include "armada_fb.h"
> +#include "armada_gem.h"
> +#include "armada_hw.h"
> +
> +struct armada_frame_work {
> +   struct drm_pending_vblank_event *event;
> +   struct armada_regs regs[4];
> +   struct drm_gem_object *old_fb_obj;
> +   struct work_struct work;
> +};
> +
> +/*
> + * A note about interlacing.  Let's consider HDMI 1920x1080i.
> + * The timing parameters we have from X are:
> + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
> + *  1920 2448 2492 2640  1080 1084 1094 1125
> + * Which get translated to:
> + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
> + *  1920 2448 2492 2640   540  542  547  562
> + *
> + * This is how it is defined by CEA-861-D - line and pixel numbers are
> + * referenced to the rising edge of VSYNC and HSYNC.  Total clocks per
> + * line: 2640.  The odd frame, the first active line is at line 21, and
> + * the even frame, the first active line is 584.
> + *
> + * LN:560 561 562 563 567 568569
> + * DE:~~~|//__
> + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
> + * VSYNC: _|~~//~~~|__
> + *  22 blanking lines.  VSYNC at 1320 (referenced to the HSYNC rising edge).
> + *
> + * LN:1123   11241125  1   5   6  7
> + * DE:~~~|//__
> + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
> + * VSYNC: |~~~//~~|___
> + *  23 blanking lines
> + *
> + * The Armada LCD Controller line and pixel numbers are, like X timings,
> + * referenced to the top left of the active frame.
> + *
> + * So, translating these to our LCD controller:
> + *  Odd frame, 563 total lines, VSYNC at line 543-548, pixel 1128.
> + *  Even frame, 562 total lines, VSYNC at line 542-547, pixel 2448.
> + * Note: Vsync front porch remains constant!
> + *
> + * if (odd_frame) {
> + *   vtotal = mode->crtc_vtotal + 1;
> + *   vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay + 1;
> + *   vhorizpos = mode->crtc_hsync_start - mode->crtc_htotal / 2
> + * } else {
> + *   vtotal = mode->crtc_vtotal;
> + *   vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay;
> + *   vhorizpos = mode->crtc_hsync_start;
> + * }
> + * vfrontporch = mode->crtc_vtotal - mode->crtc_vsync_end;
> + *
> + * So, we need to reprogram these registers on each vsync event:
> + *  LCD_SPU_V_PORCH, LCD_SPU_ADV_REG, LCD_SPUT_V_H_TOTAL

ouch, proof that some hw designers must really hate driver writers ;-)

[snip]

> +/* The mode_config.mutex will be held for this call */
> +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> +   struct drm_framebuffer *old_fb)
> +{
> +   struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
> +   struct armada_regs regs[4];
> +   unsigned i;
> +
> +   i = armada_drm_crtc_calc_fb(crtc->fb, crtc->x, crtc->y, regs, 
> dcrtc->interlaced);
> +   armada_reg_queue_end(regs, i);
> +
> +   /* Wait for pending flips to complete */
> +   wait_event(dcrtc->frame_wait, !dcrtc->frame_work);
> +
> +   /* Take a reference to the new fb as we're using it */
> +   drm_gem_object_reference(&drm_fb_obj(crtc->fb)->obj);

note that you probably want to ref/unref the fb (and let the fb hold a
ref to the gem bo).. that will make life easier for planar formats too
(as the fb should hold

[Bug 65438] GTK apps crash X11 since last update of LLVMM

[bugzilla-daemon]

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

--- Comment #9 from Tom Stellard  ---
Created attachment 80630
  --> https://bugs.freedesktop.org/attachment.cgi?id=80630&action=edit
Possible Fix / Work Around

Can you try this patch?  It should fix the segfault, but it looks to me like
the real bug might be in the CFG Structurizer.  There are a number of PHI nodes
that take undef as an argument, and I'm not sure if that is correct.

-- 
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 65254] opengl flicker in xbmc / glxgears

[bugzilla-daemon]

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

--- Comment #12 from Vladi  ---
should I rma my cpu then?

-- 
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 65254] opengl flicker in xbmc / glxgears

[bugzilla-daemon]

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

--- Comment #13 from adam  ---
I think the CPU/GPU si working as intended but it is not supported well by
anything but closed drivers or Windows.  I hope this will be resolved soon.

-- 
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 RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>>  wrote:
>> > This patch adds support for the pair of LCD controllers on the Marvell
>> > Armada 510 SoCs.  This driver supports:
>> > - multiple contiguous scanout buffers for video and graphics
>> > - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>> >   acceleration
>> > - dual lcd0 and lcd1 crt operation
>> > - video overlay on each LCD crt
>>
>> Any particular reason for not exposing the overlays as drm_plane's?
>> That is probably something that should change before merging the
>> driver.
>
> Only through not understanding much of DRM when I started this.
> Provided DRM planes can do everything that I'm already doing with
> the overlay support, then yes.  Otherwise, I want to stick with this
> which is modelled after the i915 overlay interface.
>
> The big question that this brings up is that the plane stuff looks
> a lot more heavyweight in terms of the computation done.  I'm already
> concerned that I'm doing too much with the overlay code - it occasionally
> misses getting the next frame of video ready before the VBLANK event
> in certain circumstances which I haven't been able to quantify.  I'd
> rather avoid adding too much additional work here, which would then
> make overlay pretty useless for what it's meant for - video playback.
>
> ... and it looks to me like it can't - because I sometimes get blocks
> of physical memory with the YUV data already in appropriately formatted
> for scanout that I really would like to avoid having to expensively
> copy.

I guess I'm not entirely sure that I understand your concern here..
all that planes require is a drm fb to scan out.  The GEM bo(s) that
make up the backing store for that fb can be anything (phys contig if
you need, etc).  You could keep your putimage ioctl to dma into an fb.
 Or if the decoder can decode directly into something that could be
scanned out, you can do that too.

I don't think anything about drm plane is computationally expensive.
It should be about on par w/ pageflip ioctl (ie. handful of error
checks, and then call into the driver).

>> > - page flipping of the main scanout buffers
>> >
>> > Included in this commit is the core driver with no output support; output
>> > support is platform and encoder driver dependent.
>> >
>> > Signed-off-by: Russell King 
>> > ---
>>
>> [snip]
>>
>> > diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
>> > b/drivers/gpu/drm/armada/armada_crtc.c
>> > new file mode 100644
>> > index 000..e5ab4cb
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/armada/armada_crtc.c
>> > @@ -0,0 +1,766 @@
>> > +/*
>> > + * Copyright (C) 2012 Russell King
>> > + *  Rewritten from the dovefb driver, and Armada510 manuals.
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License version 2 as
>> > + * published by the Free Software Foundation.
>> > + */
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "armada_crtc.h"
>> > +#include "armada_drm.h"
>> > +#include "armada_fb.h"
>> > +#include "armada_gem.h"
>> > +#include "armada_hw.h"
>> > +
>> > +struct armada_frame_work {
>> > +   struct drm_pending_vblank_event *event;
>> > +   struct armada_regs regs[4];
>> > +   struct drm_gem_object *old_fb_obj;
>> > +   struct work_struct work;
>> > +};
>> > +
>> > +/*
>> > + * A note about interlacing.  Let's consider HDMI 1920x1080i.
>> > + * The timing parameters we have from X are:
>> > + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
>> > + *  1920 2448 2492 2640  1080 1084 1094 1125
>> > + * Which get translated to:
>> > + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
>> > + *  1920 2448 2492 2640   540  542  547  562
>> > + *
>> > + * This is how it is defined by CEA-861-D - line and pixel numbers are
>> > + * referenced to the rising edge of VSYNC and HSYNC.  Total clocks per
>> > + * line: 2640.  The odd frame, the first active line is at line 21, and
>> > + * the even frame, the first active line is 584.
>> > + *
>> > + * LN:560 561 562 563 567 568569
>> > + * DE:~~~|//__
>> > + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
>> > + * VSYNC: _|~~//~~~|__
>> > + *  22 blanking lines.  VSYNC at 1320 (referenced to the HSYNC rising 
>> > edge).
>> > + *
>> > + * LN:1123   11241125  1   5   6  7
>> > + * DE:~~~|//__
>> > + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
>> > + * VSYNC: |~~~//~~|___
>> > + *  23 blanking lines
>> > + *
>> > + * The Armada LCD Controller line and pixel numbers are, like 

[Bug 65438] GTK apps crash X11 since last update of LLVMM

[bugzilla-daemon]

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

--- Comment #10 from had...@gmx.de ---
Yes, with your patch xfce starts fine.
Do you need more info to find the real issue?

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

Re: [PATCH] drm/tegra: add support for runtime pm

[Thierry Reding]

On Tue, Jun 04, 2013 at 02:11:27PM +0530, Mayuresh Kulkarni wrote:
> On Tuesday 28 May 2013 02:40 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Tue, May 28, 2013 at 08:45:03AM +0300, Terje Bergström wrote:
> >>On 27.05.2013 18:45, Thierry Reding wrote:
> >>>On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
> +#ifdef CONFIG_PM_RUNTIME
> +static int host1x_runtime_suspend(struct device *dev)
> +{
> + struct host1x *host;
> +
> + host = dev_get_drvdata(dev);
> + if (IS_ERR_OR_NULL(host))
> >>>
> >>>I think a simple
> >>>
> >>>   if (!host)
> >>>   return -EINVAL;
> >>>
> >>>would be enough here. The driver-data of the device should never be an
> >>>ERR_PTR()-encoded value, but either a valid pointer to a host1x object
> >>>or NULL.
> >>
> >>True, we should avoid IS_ERR_OR_NULL() like plague. We always know if
> >>the called API returns a NULL on error or an error code. In case of
> >>error code we should just propagate that.
> >
> >Yes, that's the case in general. In this specific case the value
> >obtained by dev_get_drvdata() should either be a valid pointer or NULL,
> >never an error code. We can easily make sure by only setting the data
> >(using platform_set_drvdata()) when the pointer is valid.
> >
> >Thinking about it some more, I don't think we can ever get NULL here. A
> >device's .runtime_suspend() cannot be called when the device has been
> >removed, right? That's the only case where the value returned might be
> >NULL. It would be NULL too if host1x wasn't initialized yet, but that's
> >already dealt with by the proper ordering in .probe().
> >
> >>>Same comments apply here. Also I think it might be a good idea to split
> >>>the host1x and gr2d changes into separate patches.
> >>
> >>That's a bit tricky, but doable. We just need to enable it for 2D first,
> >>and then host1x to keep bisectability.
> >
> >Right, there's a dependency. But I'd still prefer to have them separate.
> >Unless it gets really messy.
> >
>   static void action_submit_complete(struct host1x_waitlist *waiter)
>   {
> + int completed = waiter->count;
>   struct host1x_channel *channel = waiter->data;
> 
> + /* disable clocks for all the submits that got completed in this lot */
> + while (completed--)
> + pm_runtime_put(channel->dev);
> +
>   host1x_cdma_update(&channel->cdma);
> 
> - /*  Add nr_completed to trace */
> + /* Add nr_completed to trace */
>   trace_host1x_channel_submit_complete(dev_name(channel->dev),
>    waiter->count, 
>  waiter->thresh);
> -
>   }
> >>>
> >>>This feels hackish. But I can't see any better place to do this. Terje,
> >>>Arto: any ideas how we can do this in a cleaner way? If there's nothing
> >>>better then maybe moving the code into a separate function, say
> >>>host1x_waitlist_complete(), might make this less awkward?
> >>
> >>Yeah, it's a bit awkward. action_submit_complete() actually does handle
> >>completion of multiple jobs, and we do one pm_runtime_get() per job.
> >>
> >>We could do pm_runtime_put() in host1x_cdma_update(). It anyway goes
> >>through each job that is completed, so while freeing the job it could as
> >>well call runtime PM. That way we could even remove the waiter->count
> >>variable altogether as it's not needed anymore.
> >
> >That sounds a lot better. We could add a helper (host1x_job_finish()
> >perhaps) with the following from update_cdma_locked():
> >
> > /* Unpin the memory */
> > host1x_job_unpin(job);
> >
> > /* Pop push buffer slots */
> > if (job->num_slots) {
> > struct push_buffer *pb = &cdma->push_buffer;
> > host1x_pushbuffer_pop(pb, job->num_slots);
> > if (cdma->event == CDMA_EVENT_PUSH_BUFFER_SPACE)
> > signal = true;
> > }
> >
> > list_del(&job->list);
> >
> >And add pm_runtime_put() (as well as potentially other stuff) in there.
> >That'll prevent update_cdma_unlocked() from growing too much. It isn't
> >too bad right now, so maybe a helper isn't warranted yet, but I don't
> >think it'll hurt.
> >
> >>The not-so-beautiful aspect is that we do pm_runtime_get() in
> >>host1x_channel.c and pm_runtime_put() in host1x_cdma.c. For code
> >>readability it's be great to have them in the same file. I actually get
> >>questions every now and then because in downstream because of doing
> >>these operations in different files.
> >
> >With the above helper in place, we could move host1x_job_submit() to
> >job.c instead and have all the code in one file.
> >
> >Thierry
> >
> >* Unknown Key
> >* 0x7F3EB3A1
> >
> 
> In downstream, we have 2 APIs which are wrapper over runtime PM
> calls. We call those from _submit and job complete.
> 
> I wonder if we should follow the same here?

Can you post the corresponding wrappers to make it easier to discuss
them? If they just

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 4:08 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>>  wrote:
>> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
>> > a chunk of physical memory allocated by other means (eg, the Vmeta stuff.)
>> > This allows my X server to remain compatible with the XF86 Dove driver,
>> > which permits the passing of the physical address of the video frame to
>> > the X server (otherwise we're into rewriting a whole load more code than
>> > is really desirable - and I really don't have time to rewrite bits of
>> > gstreamer and other stuff.)
>>
>> ahh, gotcha.. and, ugg, that is even worse..
>>
>> I'm not hugely a fan of giving userspace a way to dma into arbitrary
>> phys addresses (ie. create_phys + put_image).  But I don't need to
>> explain what you already know ;-)
>>
>> Is there a pre-defined carveout pool that you can at least bounds
>> check against?  Otherwise put this ioctl inside a #if
>> CONFIG_CRAZY_SOC_VENDOR_HOLE_TO_DRIVE_A_TRUCK_THROUGH / #endif..
>
> This driver is _not_ about supporting the GPU natively as part of the DRM,
> but providing the foundations for:
>
> (a) a properly functional interface to HDMI TVs (fbdev doesn't hack that)
> with hotplug
> (b) providing sufficient infrastructure to allow video playback to work.

sure, but even omitting the phys ioctls gives you (a), which seems
like it is useful on it's own.  And would, I expect, be pretty useful
for the etnaviv folks working on r/e the gpu.

> What this is not about is fixing the crappy userspace GPU libraries and
> video decoding so that it's "secure" - not only is that way beyond my
> abilities, it would also be a violation of the closed source license to
> reverse engineer them so that were possible.

yeah, once you add the vendor gpu/etc drivers, if they are also giving
you a way to pass a phys addr, then plugging the holes in the drm/kms
driver won't do any good.  But in a way that is some other
non-upstream driver's problem.

> It is something that continues to be a problem and I'm making no claims
> that I'm fixing that.  So no, I will not put such a config option around
> it for the simple reason that by doing so, turning such an option off
> renders userspace utterly useless and the driver might as well not exist.
>
> If that means you want to NACK the patch, then fine; I'll just maintain
> it out of tree.  I did the driver mostly for my own personal benefit to
> get the Cubox to the point where I can boot it with or without the TV
> connected and have it work.  But it would be a shame if that meant
> that others could not benefit from about 8 solid months of my work on
> this and have to put up with crappy a fbdev driver.

I would like to get at least some of the driver upstream.  I'd hate
for it to have to live completely out of tree.  I can think of a
couple possibilities.

1) the best would be, if there was some way for the drm driver to know
the upper/lower bounds of the carveout, then it could bounds-check
against this.  And then in worst case, userspace can just screw up
other "graphics" buffers

2) if #1 weren't possible, then maybe just keep the phys ioctls as a
small patch on top of upstream.  The at least out of the box you get
modesetting.  I had to do something like this w/ omapdrm for gluing it
together w/ sgx/pvr stuff.  I re-arranged the code a bit to group all
the non-upstream bits together to avoid merge/rebase conflicts.

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark  wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>  wrote:
>> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>>>  wrote:
>>> > This patch adds support for the pair of LCD controllers on the Marvell
>>> > Armada 510 SoCs.  This driver supports:
>>> > - multiple contiguous scanout buffers for video and graphics
>>> > - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>>> >   acceleration
>>> > - dual lcd0 and lcd1 crt operation
>>> > - video overlay on each LCD crt
>>>
>>> Any particular reason for not exposing the overlays as drm_plane's?
>>> That is probably something that should change before merging the
>>> driver.
>>
>> Only through not understanding much of DRM when I started this.
>> Provided DRM planes can do everything that I'm already doing with
>> the overlay support, then yes.  Otherwise, I want to stick with this
>> which is modelled after the i915 overlay interface.

Oh i915 overlays aren't a good reason ;-) I've done those way back
when drm didn't have any plane infrastructure and pretty much as my
very contribution. So totally lacked any clue.

If I can scrap together a bit of time I want to port the legacy
overlay code over to drm planes (and remap the current ioctl interface
to the drm plane interface for backwards compat). But atm that's
crushed under a giant pile of other todo items.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65438] GTK apps crash X11 since last update of LLVMM

[bugzilla-daemon]

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

--- Comment #11 from Tom Stellard  ---
(In reply to comment #10)
> Yes, with your patch xfce starts fine.
> Do you need more info to find the real issue?

No, I think we have enough.

-- 
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: [PULL] GEM CMA DMA-BUF

[Dave Airlie]

>
> Here's a small pull request for v3.11 that contains the GEM CMA DMA-BUF
> support patches. The content is identical to "[PATCH v3 0/5] GEM CMA DMA-BUF
> support" with acks picked up from the list.

Pulled, thanks,

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

[Bug 64471] Radeon HD6570 lockup in Brütal Legend with HyperZ

[bugzilla-daemon]

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

Nicholas Miell  changed:

   What|Removed |Added

 CC||nmi...@gmail.com

--- Comment #7 from Nicholas Miell  ---
Also affects Double Fine's The Cave

-- 
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 RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 5:15 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
>> I would like to get at least some of the driver upstream.  I'd hate
>> for it to have to live completely out of tree.  I can think of a
>> couple possibilities.
>>
>> 1) the best would be, if there was some way for the drm driver to know
>> the upper/lower bounds of the carveout, then it could bounds-check
>> against this.  And then in worst case, userspace can just screw up
>> other "graphics" buffers
>
> The bounds check does what?  Check that the buffer object's physical
> address is within another driver's range?  Fine, but all that it's
> doing is preventing it being associated with a buffer object which can
> _only_ be used for _read_ access by the LCD controller.  There is no
> write access to the GEM objects by anything that this DRM driver talks
> to.

I was assuming there was a global carveout pool, so it would be just
one upper/lower check.  But from what you said and looking at the
allocation code in your driver, I guess this is not actually the case.

> So all it'll do is prevent you passing rogue addresses to the LCD
> controller for scanout.
>
> And how do we get that information into the driver from other random
> drivers?  Hack in random inter-driver specific APIs to do it?  Come
> up with yet another different way to try and identify whether a
> particular resource is a block of reserved memory for this driver's
> usage as a linear region or one of the others?  How.  Really, please
> think about the problem.
>
> The benefit vs the complexity involved really isn't worth it.

yeah, that suggestion was based on a wrong assumption about how the
phys contig buffers are allocated and passed.  So disregard it.

I guess in the short term, the best I can think is keep those phys
ioctls as a small patch on top of the upstream driver.  It is ok to
leave place-holder ioctl #'s in the upstream driver so that the ioctl
#'s don't shift when you rebase.  And then try to get the vendor to
add support for dmabuf so that the patch on top of upstream can
eventually be dropped.  Maybe someone else has a better suggestion,
but I don't think we can merge those phys ioctls upstream, and I'd
really hate to 'throw the baby out with the bathwater' in this case
and not at least get the modesetting part of the driver merged.

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

build warning on 32-bit

[Dave Airlie]

  CC [M]  drivers/gpu/drm/i915/i915_gem.o
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
‘i915_gem_object_bind_to_gtt’:
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c:3000:3: warning:
format ‘%ld’ expects argument of type ‘long int’, but argument 5 has
type ‘size_t’ [-Wformat]
  CC [M]  drivers/gpu/drm/i915/i915_gem_context.o

commit a36689cb771f06819c3fa8139c3d3716dfdf6d53
Author: Chris Wilson 
Date:   Tue May 21 16:58:49 2013 +0100

drm/i915: Be more informative when reporting "too large for aperture" error

This should help debugging the truly unexpected cases where it occurs -
in particular to see which value is garbage.

References: https://bugzilla.kernel.org/show_bug.cgi?id=58511
Signed-off-by: Chris Wilson 
[danvet: s/%ld/%zd/ as spotted by Wu Fengguang's autobuilder.]
Signed-off-by: Daniel Vetter 

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

Re: [RPC 0/21] DRM: Add VIA DRM driver

[Dave Airlie]

>
> Here is the first run at inspection of the VIA openchrome dri
> driver. Now that the Xorg driver has been out over a year with KMS support
> most people should be able to use this feature. The driver is totaly

Just FYI this is a really bad idea, don't go releasing userspace code that uses
interfaces for kernel code that hasn't been merged.

I'm not going to accept already existing userspace code as a reason to not fix
bugs in the interface. Now I'll go find those bugs.

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 6:32 PM, Russell King - ARM Linux
 wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
>> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark  wrote:
>> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>> >  wrote:
>> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>> >>>  wrote:
>> >>> > This patch adds support for the pair of LCD controllers on the Marvell
>> >>> > Armada 510 SoCs.  This driver supports:
>> >>> > - multiple contiguous scanout buffers for video and graphics
>> >>> > - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>> >>> >   acceleration
>> >>> > - dual lcd0 and lcd1 crt operation
>> >>> > - video overlay on each LCD crt
>> >>>
>> >>> Any particular reason for not exposing the overlays as drm_plane's?
>> >>> That is probably something that should change before merging the
>> >>> driver.
>> >>
>> >> Only through not understanding much of DRM when I started this.
>> >> Provided DRM planes can do everything that I'm already doing with
>> >> the overlay support, then yes.  Otherwise, I want to stick with this
>> >> which is modelled after the i915 overlay interface.
>>
>> Oh i915 overlays aren't a good reason ;-) I've done those way back
>> when drm didn't have any plane infrastructure and pretty much as my
>> very contribution. So totally lacked any clue.
>>
>> If I can scrap together a bit of time I want to port the legacy
>> overlay code over to drm planes (and remap the current ioctl interface
>> to the drm plane interface for backwards compat). But atm that's
>> crushed under a giant pile of other todo items.
>
> Aren't we all :(  The amount of time I have to touch this has reduced
> substantially over the last couple of months, which is why there's been
> a few weeks between the RFC's for this.
>
> The issue here is that with the overlay interface, all I have to do
> with one of these pass-by-phys-address things which the X server gets
> is to:
>
> 1. associate the phys address with a gem object
> 2. pass it in via the overlay interface
>
> With the DRM plane stuff, this gets more complicated:
>
> 1. associate the phys address with a gem object
> 2. call another driver private ioctl to bind the gem object to a framebuffer
>(there is no support for this in the generic ioctl API afaics) which
>has to allocate and setup a framebuffer
> 3. use setplane to update the plane
>
> That all increases the expense of overlay, and adds further memory
> allocations to the path (and frees when the previous framebuffer is
> discarded.)
>
> That all makes for higher load due to more CPU expense.

Nothing prevents you from having a driver private ioctl on top of drm
plane to combine this all into one ioctl in addition to supporting the
standard plane interface

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> I guess in the short term, the best I can think is keep those phys
>> ioctls as a small patch on top of the upstream driver.  It is ok to
>> leave place-holder ioctl #'s in the upstream driver so that the ioctl
>> #'s don't shift when you rebase.  And then try to get the vendor to
>> add support for dmabuf so that the patch on top of upstream can
>> eventually be dropped.  Maybe someone else has a better suggestion,
>> but I don't think we can merge those phys ioctls upstream, and I'd
>> really hate to 'throw the baby out with the bathwater' in this case
>> and not at least get the modesetting part of the driver merged.
>
> What you're saying is basically:
>
> 1. Throw out DRM_ARMADA_GEM_CREATE_PHYS, which cripples video playback
>on existing gstreamer, xbmc and other implementations without someone
>rewriting all that code.
>
> 2. Throw out DRM_ARMADA_GEM_PROP, which prevents any form of passing
>the GEM objects to the GPU libraries in userspace, thereby preventing
>any kind of GPU based acceleration.
>
> That makes the driver just be a dumb scanout only driver.  Sorry,
> that *really* does not interest me one bit, because the CPU doing
> framebuffer accesses is pig slow.

Well, yes that is basically what I am saying, unless we can find a
different way (dmabuf? if there is some way to pass it through the
blob bits you don't have src code for?)

The problem is that we really can't merge something upstream that lets
you dma to arbitrary physical address.  Maybe in staging, perhaps?  Or
otherwise if there is no other way, I hope someone will at least pick
up the modesetting parts of it and get that merged upstream.  The rest
of the driver is looking pretty good, and I think it would be useful
to have upstream.

BR,
-R

> There's really no point in such a driver; people might as well just
> use the standard fbdev driver instead.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Dave Airlie]

>>
>> That makes the driver just be a dumb scanout only driver.  Sorry,
>> that *really* does not interest me one bit, because the CPU doing
>> framebuffer accesses is pig slow.
>
> Well, yes that is basically what I am saying, unless we can find a
> different way (dmabuf? if there is some way to pass it through the
> blob bits you don't have src code for?)
>
> The problem is that we really can't merge something upstream that lets
> you dma to arbitrary physical address.  Maybe in staging, perhaps?  Or
> otherwise if there is no other way, I hope someone will at least pick
> up the modesetting parts of it and get that merged upstream.  The rest
> of the driver is looking pretty good, and I think it would be useful
> to have upstream.

Totally what he said.

upstream shouldn't be restricted by the bad decisions of others, and
adding security bypasses is one of them.

I'd like to see all the ARM based drivers based on CMA if it can meet
their requirements
and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
come an unmaintainable
nightmare for everyone, but mostly for me.

Merging the base dumb KMS driver, then working out acceptable ways to
provide the extra
features is definitely the nicest way to do things.

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

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #31 from Erdem U. Altınyurt  ---
I rebuilt libclc from your repo now.
Also update;rebuild;install the llvm,gallium,bfgminer.

Same error still exists.
Regards
Erdem

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #32 from Tom Stellard  ---
(In reply to comment #31)
> I rebuilt libclc from your repo now.
> Also update;rebuild;install the llvm,gallium,bfgminer.
> 
> Same error still exists.
> Regards
> Erdem


Did you build it with the same version of clang that you are using with Mesa?

-- 
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 RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie  wrote:
>>>
>>> That makes the driver just be a dumb scanout only driver.  Sorry,
>>> that *really* does not interest me one bit, because the CPU doing
>>> framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we can find a
>> different way (dmabuf? if there is some way to pass it through the
>> blob bits you don't have src code for?)
>>
>> The problem is that we really can't merge something upstream that lets
>> you dma to arbitrary physical address.  Maybe in staging, perhaps?  Or
>> otherwise if there is no other way, I hope someone will at least pick
>> up the modesetting parts of it and get that merged upstream.  The rest
>> of the driver is looking pretty good, and I think it would be useful
>> to have upstream.
>
> Totally what he said.
>
> upstream shouldn't be restricted by the bad decisions of others, and
> adding security bypasses is one of them.
>
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements

afaiu CMA has issues w/ changing cache attributes of pages on older
architectures like Russell is using.  Although perhaps on older arm
CMA should just be a straight carveout pool and not try to recycle the
unused pages.  At least then it would be the same API for the drivers.

BR,
-R

> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
>
> Merging the base dumb KMS driver, then working out acceptable ways to
> provide the extra
> features is definitely the nicest way to do things.
>
> Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Dave Airlie]

On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
 wrote:
> On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> I'd like to see all the ARM based drivers based on CMA if it can meet
>> their requirements
>> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
>> come an unmaintainable
>> nightmare for everyone, but mostly for me.
>
> I am *not* using the CMA layer - that layer is just plain broken in
> DRM.  It forces every single gem object to be a CMA allocated object,
> which means I can't have cacheable pixmaps in X.  And that makes X
> suck.
>
> Okay, I'm pulling this and I'm going to keep it in my private cubox
> tree; I'm not persuing pushing this driver or any other Armada 510
> driver into mainline anymore.  It's just too much fscking hastle
> dealing with people who don't like various stuff.
>
> I've done my best to clean a lot of the crap up, and the problem is
> that no matter how much I clean up, it remains unacceptable.  Only
> the 100% perfect solution seems to be acceptable.  That is
> unacceptable given that this stuff has already consumed something
> like 8 months solid of my time.

Russell, aren't you a kernel maintainer, because for fuck sake get real.

I'm not merging bullshit into my tree that has a completely broken API that
has to be maintained for ever. You of all people should understand we
don't break Linux
userspace APIs, and adding a phys addr one is wrong, wrong, wrong, its not
cleanups, its just broken, and I'll never merge it.

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Mon, Jun 10, 2013 at 7:38 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
>> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
>>  wrote:
>> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
>> >> I guess in the short term, the best I can think is keep those phys
>> >> ioctls as a small patch on top of the upstream driver.  It is ok to
>> >> leave place-holder ioctl #'s in the upstream driver so that the ioctl
>> >> #'s don't shift when you rebase.  And then try to get the vendor to
>> >> add support for dmabuf so that the patch on top of upstream can
>> >> eventually be dropped.  Maybe someone else has a better suggestion,
>> >> but I don't think we can merge those phys ioctls upstream, and I'd
>> >> really hate to 'throw the baby out with the bathwater' in this case
>> >> and not at least get the modesetting part of the driver merged.
>> >
>> > What you're saying is basically:
>> >
>> > 1. Throw out DRM_ARMADA_GEM_CREATE_PHYS, which cripples video playback
>> >on existing gstreamer, xbmc and other implementations without someone
>> >rewriting all that code.
>> >
>> > 2. Throw out DRM_ARMADA_GEM_PROP, which prevents any form of passing
>> >the GEM objects to the GPU libraries in userspace, thereby preventing
>> >any kind of GPU based acceleration.
>> >
>> > That makes the driver just be a dumb scanout only driver.  Sorry,
>> > that *really* does not interest me one bit, because the CPU doing
>> > framebuffer accesses is pig slow.
>>
>> Well, yes that is basically what I am saying, unless we can find a
>> different way (dmabuf? if there is some way to pass it through the
>> blob bits you don't have src code for?)
>>
>> The problem is that we really can't merge something upstream that lets
>> you dma to arbitrary physical address.  Maybe in staging, perhaps?  Or
>
> Which bit of "THIS DRIVER DOESN'T DMA _TO_ ANY ADDRESS" did you not yet?

ok, I see the 'put_image' ioctl is a non-destructive overlay (ie. not
a blit to memory).  In which case it is limited to letting you just
scan out arbitrary memory.  Which is still not awesome, but not nearly
as bad.

And fwiw, CMA is not a blocker point for me.  Although it seems like a
good idea into trying to talk someone into making CMA do something
sane on older arm's so that at some point armada driver can use it.

You probably can't use the drm cma helpers (since that wouldn't let
you do cached buffers), so the change to use dma_alloc_* from your
driver at a later date would be pretty small.  Fwiw, omapdrm and I
think also exynos both use CMA for some buffers (for example, omap3 or
anything without dmm/tiler would use cma for scanout buffers).

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

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

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

--- Comment #35 from Tom Stellard  ---
All of the proposed fixes have been merged to the LLVM tree, so what would be
helpful now is if people could post the output of R600_DEBUG=vs,fs,ps,sbdisasm
from the applications that don't work.  It would also be helpful if you could
post the same shader dumps from an older version of Mesa/LLVM when the
application was working.

-- 
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 0/3] Fix backlight issues on some Windows 8 systems

[Matthew Garrett]

On Mon, 2013-06-10 at 13:59 +0200, Rafael J. Wysocki wrote:

> I happen to know that alternative solution to this problem is being worked on,
> so I'm going to wait until it is submitted and then we'll decide what to 
> merge.

Sure.

> I'm slightly concerned about unregistering ACPI backlight control for all
> systems declaring win8 support, even though it may actually work for them.

Right, that's why I think it's correct to leave it up to the graphics
drivers. It seems like they're the ones that make the policy
determination under Windows now. The policy as implemented here may not
be correct, but doing better would probably involve Intel letting us
know how their Windows driver behaves.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>  wrote:
> > This patch adds support for the pair of LCD controllers on the Marvell
> > Armada 510 SoCs.  This driver supports:
> > - multiple contiguous scanout buffers for video and graphics
> > - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
> >   acceleration
> > - dual lcd0 and lcd1 crt operation
> > - video overlay on each LCD crt
> 
> Any particular reason for not exposing the overlays as drm_plane's?
> That is probably something that should change before merging the
> driver.

Only through not understanding much of DRM when I started this.
Provided DRM planes can do everything that I'm already doing with
the overlay support, then yes.  Otherwise, I want to stick with this
which is modelled after the i915 overlay interface.

The big question that this brings up is that the plane stuff looks
a lot more heavyweight in terms of the computation done.  I'm already
concerned that I'm doing too much with the overlay code - it occasionally
misses getting the next frame of video ready before the VBLANK event
in certain circumstances which I haven't been able to quantify.  I'd
rather avoid adding too much additional work here, which would then
make overlay pretty useless for what it's meant for - video playback.

... and it looks to me like it can't - because I sometimes get blocks
of physical memory with the YUV data already in appropriately formatted
for scanout that I really would like to avoid having to expensively
copy.

> > - page flipping of the main scanout buffers
> >
> > Included in this commit is the core driver with no output support; output
> > support is platform and encoder driver dependent.
> >
> > Signed-off-by: Russell King 
> > ---
> 
> [snip]
> 
> > diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> > b/drivers/gpu/drm/armada/armada_crtc.c
> > new file mode 100644
> > index 000..e5ab4cb
> > --- /dev/null
> > +++ b/drivers/gpu/drm/armada/armada_crtc.c
> > @@ -0,0 +1,766 @@
> > +/*
> > + * Copyright (C) 2012 Russell King
> > + *  Rewritten from the dovefb driver, and Armada510 manuals.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include "armada_crtc.h"
> > +#include "armada_drm.h"
> > +#include "armada_fb.h"
> > +#include "armada_gem.h"
> > +#include "armada_hw.h"
> > +
> > +struct armada_frame_work {
> > +   struct drm_pending_vblank_event *event;
> > +   struct armada_regs regs[4];
> > +   struct drm_gem_object *old_fb_obj;
> > +   struct work_struct work;
> > +};
> > +
> > +/*
> > + * A note about interlacing.  Let's consider HDMI 1920x1080i.
> > + * The timing parameters we have from X are:
> > + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
> > + *  1920 2448 2492 2640  1080 1084 1094 1125
> > + * Which get translated to:
> > + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
> > + *  1920 2448 2492 2640   540  542  547  562
> > + *
> > + * This is how it is defined by CEA-861-D - line and pixel numbers are
> > + * referenced to the rising edge of VSYNC and HSYNC.  Total clocks per
> > + * line: 2640.  The odd frame, the first active line is at line 21, and
> > + * the even frame, the first active line is 584.
> > + *
> > + * LN:560 561 562 563 567 568569
> > + * DE:~~~|//__
> > + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
> > + * VSYNC: _|~~//~~~|__
> > + *  22 blanking lines.  VSYNC at 1320 (referenced to the HSYNC rising 
> > edge).
> > + *
> > + * LN:1123   11241125  1   5   6  7
> > + * DE:~~~|//__
> > + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
> > + * VSYNC: |~~~//~~|___
> > + *  23 blanking lines
> > + *
> > + * The Armada LCD Controller line and pixel numbers are, like X timings,
> > + * referenced to the top left of the active frame.
> > + *
> > + * So, translating these to our LCD controller:
> > + *  Odd frame, 563 total lines, VSYNC at line 543-548, pixel 1128.
> > + *  Even frame, 562 total lines, VSYNC at line 542-547, pixel 2448.
> > + * Note: Vsync front porch remains constant!
> > + *
> > + * if (odd_frame) {
> > + *   vtotal = mode->crtc_vtotal + 1;
> > + *   vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay + 1;
> > + *   vhorizpos = mode->crtc_hsync_start - mode->crtc_htotal / 2
> > + * } else {
> > + *   vtotal = mode->crtc_vtotal;
> > + *   vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay;
> > + *   vhorizpos = mode->crtc_hsync_start;
> > + * }
> > + * vfrontpor

Re: [PATCH 3/4] fb: Make fb_get_options() 'name' parameter const

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:43 Fri 07 Jun , ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The string isn't modified so make it const.
> 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 

Applied

Best Regards,
J.
> ---
>  drivers/video/fbmem.c | 2 +-
>  include/linux/fb.h| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 098bfc6..d8d5779 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1881,7 +1881,7 @@ static int ofonly __read_mostly;
>   *
>   * NOTE: Needed to maintain backwards compatibility
>   */
> -int fb_get_options(char *name, char **option)
> +int fb_get_options(const char *name, char **option)
>  {
>   char *opt, *options = NULL;
>   int retval = 0;
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index d49c60f..ffac70a 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -624,7 +624,7 @@ extern void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, 
> u8 *src, u32 s_pitch, u3
>  extern void fb_set_suspend(struct fb_info *info, int state);
>  extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> struct fb_fix_screeninfo *fix);
> -extern int fb_get_options(char *name, char **option);
> +extern int fb_get_options(const char *name, char **option);
>  extern int fb_new_modelist(struct fb_info *info);
>  
>  extern struct fb_info *registered_fb[FB_MAX];
> -- 
> 1.8.1.5
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
>  wrote:
> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
> > a chunk of physical memory allocated by other means (eg, the Vmeta stuff.)
> > This allows my X server to remain compatible with the XF86 Dove driver,
> > which permits the passing of the physical address of the video frame to
> > the X server (otherwise we're into rewriting a whole load more code than
> > is really desirable - and I really don't have time to rewrite bits of
> > gstreamer and other stuff.)
> 
> ahh, gotcha.. and, ugg, that is even worse..
> 
> I'm not hugely a fan of giving userspace a way to dma into arbitrary
> phys addresses (ie. create_phys + put_image).  But I don't need to
> explain what you already know ;-)
> 
> Is there a pre-defined carveout pool that you can at least bounds
> check against?  Otherwise put this ioctl inside a #if
> CONFIG_CRAZY_SOC_VENDOR_HOLE_TO_DRIVE_A_TRUCK_THROUGH / #endif..

This driver is _not_ about supporting the GPU natively as part of the DRM,
but providing the foundations for:

(a) a properly functional interface to HDMI TVs (fbdev doesn't hack that)
with hotplug
(b) providing sufficient infrastructure to allow video playback to work.

What this is not about is fixing the crappy userspace GPU libraries and
video decoding so that it's "secure" - not only is that way beyond my
abilities, it would also be a violation of the closed source license to
reverse engineer them so that were possible.

It is something that continues to be a problem and I'm making no claims
that I'm fixing that.  So no, I will not put such a config option around
it for the simple reason that by doing so, turning such an option off
renders userspace utterly useless and the driver might as well not exist.

If that means you want to NACK the patch, then fine; I'll just maintain
it out of tree.  I did the driver mostly for my own personal benefit to
get the Cubox to the point where I can boot it with or without the TV
connected and have it work.  But it would be a shame if that meant
that others could not benefit from about 8 solid months of my work on
this and have to put up with crappy a fbdev driver.

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream.  I'd hate
> for it to have to live completely out of tree.  I can think of a
> couple possibilities.
> 
> 1) the best would be, if there was some way for the drm driver to know
> the upper/lower bounds of the carveout, then it could bounds-check
> against this.  And then in worst case, userspace can just screw up
> other "graphics" buffers

The bounds check does what?  Check that the buffer object's physical
address is within another driver's range?  Fine, but all that it's
doing is preventing it being associated with a buffer object which can
_only_ be used for _read_ access by the LCD controller.  There is no
write access to the GEM objects by anything that this DRM driver talks
to.

So all it'll do is prevent you passing rogue addresses to the LCD
controller for scanout.

And how do we get that information into the driver from other random
drivers?  Hack in random inter-driver specific APIs to do it?  Come
up with yet another different way to try and identify whether a
particular resource is a block of reserved memory for this driver's
usage as a linear region or one of the others?  How.  Really, please
think about the problem.

The benefit vs the complexity involved really isn't worth it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: encoder_slave: respect of_node on i2c encoder init

[Sebastian Hesselbarth]

Current DRM slave encoder API conflicts with auto-registration of i2c client
when using DT probed clients. To allow DRM slave encoders passed by DT, this
patch adds a check to drm_i2c_encoder_init for a non-NULL .of_node on
i2c_board_info and calls an of_i2c helper to get the i2c client device
instead of registering a new device.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: David Airlie 
Cc: Russell King - ARM Linux 
Cc: Darren Etheridge 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/drm_encoder_slave.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_encoder_slave.c 
b/drivers/gpu/drm/drm_encoder_slave.c
index 0cfb60f..36c0aa7 100644
--- a/drivers/gpu/drm/drm_encoder_slave.c
+++ b/drivers/gpu/drm/drm_encoder_slave.c
@@ -25,6 +25,7 @@
  */
 
 #include 
+#include 
 
 #include 
 
@@ -61,7 +62,10 @@ int drm_i2c_encoder_init(struct drm_device *dev,
 
request_module("%s%s", I2C_MODULE_PREFIX, info->type);
 
-   client = i2c_new_device(adap, info);
+   if (info->of_node)
+   client = of_find_i2c_device_by_node(info->of_node);
+   else
+   client = i2c_new_device(adap, info);
if (!client) {
err = -ENOMEM;
goto fail;
-- 
1.7.2.5

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

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

[Sebastian Hesselbarth]

This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive modes. Sync timings for a bunch of modes
have also been verified with an oscilloscope near-end (TDA998x input)
and far-end (DVI receiver output).

Signed-off-by: Sebastian Hesselbarth 
---
Note: This patch is based on rmk's Armada DRM driver plus some DT support
fixes, so offsets may vary on your side. Anyway, please 3-way apply and
test wherever possible.

Cc: David Airlie 
Cc: Russell King - ARM Linux 
Cc: Darren Etheridge 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |  168 ++---
 1 files changed, 102 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 819dcba..1564830 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -141,8 +141,12 @@ struct tda998x_priv {
 #define REG_VS_LINE_END_1_LSB REG(0x00, 0xae) /* write */
 #define REG_VS_PIX_END_1_MSB  REG(0x00, 0xaf) /* write */
 #define REG_VS_PIX_END_1_LSB  REG(0x00, 0xb0) /* write */
+#define REG_VS_LINE_STRT_2_MSBREG(0x00, 0xb1) /* write */
+#define REG_VS_LINE_STRT_2_LSBREG(0x00, 0xb2) /* write */
 #define REG_VS_PIX_STRT_2_MSB REG(0x00, 0xb3) /* write */
 #define REG_VS_PIX_STRT_2_LSB REG(0x00, 0xb4) /* write */
+#define REG_VS_LINE_END_2_MSB REG(0x00, 0xb5) /* write */
+#define REG_VS_LINE_END_2_LSB REG(0x00, 0xb6) /* write */
 #define REG_VS_PIX_END_2_MSB  REG(0x00, 0xb7) /* write */
 #define REG_VS_PIX_END_2_LSB  REG(0x00, 0xb8) /* write */
 #define REG_HS_PIX_START_MSB  REG(0x00, 0xb9) /* write */
@@ -153,21 +157,29 @@ struct tda998x_priv {
 #define REG_VWIN_START_1_LSB  REG(0x00, 0xbe) /* write */
 #define REG_VWIN_END_1_MSBREG(0x00, 0xbf) /* write */
 #define REG_VWIN_END_1_LSBREG(0x00, 0xc0) /* write */
+#define REG_VWIN_START_2_MSB  REG(0x00, 0xc1) /* write */
+#define REG_VWIN_START_2_LSB  REG(0x00, 0xc2) /* write */
+#define REG_VWIN_END_2_MSBREG(0x00, 0xc3) /* write */
+#define REG_VWIN_END_2_LSBREG(0x00, 0xc4) /* write */
 #define REG_DE_START_MSB  REG(0x00, 0xc5) /* write */
 #define REG_DE_START_LSB  REG(0x00, 0xc6) /* write */
 #define REG_DE_STOP_MSB   REG(0x00, 0xc7) /* write */
 #define REG_DE_STOP_LSB   REG(0x00, 0xc8) /* write */
 #define REG_TBG_CNTRL_0   REG(0x00, 0xca) /* write */
+# define TBG_CNTRL_0_TOP_TGL  (1 << 0)
+# define TBG_CNTRL_0_TOP_SEL  (1 << 1)
+# define TBG_CNTRL_0_DE_EXT   (1 << 2)
+# define TBG_CNTRL_0_TOP_EXT  (1 << 3)
 # define TBG_CNTRL_0_FRAME_DIS(1 << 5)
 # define TBG_CNTRL_0_SYNC_MTHD(1 << 6)
 # define TBG_CNTRL_0_SYNC_ONCE(1 << 7)
 #define REG_TBG_CNTRL_1   REG(0x00, 0xcb) /* write */
-# define TBG_CNTRL_1_VH_TGL_0 (1 << 0)
-# define TBG_CNTRL_1_VH_TGL_1 (1 << 1)
-# define TBG_CNTRL_1_VH_TGL_2 (1 << 2)
-# define TBG_CNTRL_1_VHX_EXT_DE   (1 << 3)
-# define TBG_CNTRL_1_VHX_EXT_HS   (1 << 4)
-# define TBG_CNTRL_1_VHX_EXT_VS   (1 << 5)
+# define TBG_CNTRL_1_H_TGL(1 << 0)
+# define TBG_CNTRL_1_V_TGL(1 << 1)
+# define TBG_CNTRL_1_TGL_EN   (1 << 2)
+# define TBG_CNTRL_1_X_EXT(1 << 3)
+# define TBG_CNTRL_1_H_EXT(1 << 4)
+# define TBG_CNTRL_1_V_EXT(1 << 5)
 # define TBG_CNTRL_1_DWIN_DIS (1 << 6)
 #define REG_ENABLE_SPACE  REG(0x00, 0xd6) /* write */
 #define REG_HVF_CNTRL_0   REG(0x00, 0xe4) /* write */
@@ -740,43 +752,57 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   uint16_t hs_start, hs_end, line_start, line_end;
-   uint16_t vwin_start, vwin_end, de_start, de_end;
-   uint16_t ref_pix, ref_line, pix_start2;
+   uint16_t ref_pix, ref_line, n_pix, n_line;
+   uint16_t hs_pix_s, hs_pix_e;
+   uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
+   uint16_t vs2_pix_s, vs2_pix_e, vs2_line_s, vs2_line_e;
+   uint16_t vwin1_line_s, vwin1_line_e;
+   uint16_t vwin2_line_s, vwin2_line_e;
+   uint16_t de_pix_s, de_pix_e;
uint8_t reg, div, rep;
 
-   hs_start   = mode->hsync_start - mode->hdisplay;
-   hs_end = mode->hsync_end - mode->hdisplay;
-   line_start = 1;
-   line_end   = 1 + mode->vsync_end - mode->vsync_start;
-   vwin_start = mode->vtotal - mode->vsync_start;
-   vwin_end   = vwin_start + mode->vdisplay;
-   de_start   = mode->htotal - mode->hdisplay;
-   de_end = mode->htotal;
-
-   pix_start2 = 0;
-   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   pix_start2 = (mode->htotal /

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>  wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int 
> > y,
> > +   struct drm_framebuffer *old_fb)
> > +{
> > +   struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
> > +   struct armada_regs regs[4];
> > +   unsigned i;
> > +
> > +   i = armada_drm_crtc_calc_fb(crtc->fb, crtc->x, crtc->y, regs, 
> > dcrtc->interlaced);
> > +   armada_reg_queue_end(regs, i);
> > +
> > +   /* Wait for pending flips to complete */
> > +   wait_event(dcrtc->frame_wait, !dcrtc->frame_work);
> > +
> > +   /* Take a reference to the new fb as we're using it */
> > +   drm_gem_object_reference(&drm_fb_obj(crtc->fb)->obj);
> 
> note that you probably want to ref/unref the fb (and let the fb hold a
> ref to the gem bo).. that will make life easier for planar formats too
> (as the fb should hold ref's to the bo for each plane)

Now changed - and it looks from my debug of gem_linear that it's working
correctly (iow, not leaking).

> > +struct drm_armada_gem_create {
> > +   uint32_t height;
> > +   uint32_t width;
> > +   uint32_t bpp;
> 
> just fwiw, typically height/width/bpp are properties of the fb but not
> the bo.. (except in some cases where kernel needs to know this to
> setup GTT correctly for tiled buffers)

Also fixed.

> > +struct drm_armada_gem_pwrite {
> > +   uint32_t handle;
> > +   uint32_t offset;
> > +   uint32_t size;
> 
> probably want a uint32_t padding here, or move the uint64_t up in the
> struct to avoid 32 vs 64b alignment differences.

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
> On 06/09/13 21:29, Russell King wrote:
>> +/*
>> + * The spec is unclear about the polarities of the syncs.
>> + * We assume their non-inverted state is active high.
>> + */
>
> nit: "We confirmed their non-inverted state is active high."

Thanks, it's been a while since I looked at this so I had forgotten
to update the comment.  Now done.

>> +if (resource_size(r) > SZ_4K)
>> +mem = r;
>
> nit again: The register address window of Dove LCD is 64k although you  
> are right an no more than 512B are used. Also a comment would be nice,
> that everything above 4k (64k) is interpreted as gfx mem.

Fixed and comment added.

>> +/* Create all LCD controllers */
>> +for (n = 0; n < ARRAY_SIZE(priv->dcrtc); n++) {
>> +struct clk *clk;
>> +
>> +if (!res[n])
>> +break;
>> +
>> +clk = clk_get_sys("dovefb.0", "extclk");
>
> To be precise: the above should have the index at extclk as there
> is two extclk inputs that can be used for both lcdcs. So currently,
> as armada_crtc is hard-coding extclk0 input it should be
> "armadafb.%d", "extclk0".
>
> But I know, clocking in general will work-out with parent select for
> clk-mux and DT support.

I've sorted that out, but I'd forgotten there were three additional
patches on top of what I've posted sorting that stuff out - the
second one in particular:

4a5e9b7 DRM: armada: store kernel address for gem objects
f760c94 DRM: Dove: alternative variant based clocking
2e051fd DRM: Armada: convert hardware cursor support to 64x32 or 32x64 ARGB

Because they're scattered in other branches (the h/w cursor stuff
is separate) it's not trivial to generate a single series from git
for these.

>> +static const struct armada_output_type armada_drm_conn_slave = {
>> +.connector_type = DRM_MODE_CONNECTOR_HDMIA,
>
> For a rework of DRM slave encoder API, there should also be some way to
> get .connector_type and .encoder_type above from that slave encoder.
> IMHO it should be up to the slave encoder to determine connector and
> encoder type.

Encoder type - yes, but connector type doesn't seem sensible.  It's
possible for the TDA998x to be connected to a DVI connector - how
would the slave encoder know that?

>> diff --git a/drivers/gpu/drm/armada/armada_slave.h 
>> b/drivers/gpu/drm/armada/armada_slave.h
>> new file mode 100644
>> index 000..1b86696
>> --- /dev/null
>> +++ b/drivers/gpu/drm/armada/armada_slave.h
>> @@ -0,0 +1,26 @@
>> +/*
>> + * Copyright (C) 2012 Russell King
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef ARMADA_TDA19988_H
>> +#define ARMADA_TDA19988_H
>
> nit: ARMADA_SLAVE_H

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

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Sebastian Hesselbarth]

On 06/10/2013 11:48 PM, Russell King - ARM Linux wrote:

On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:

On 06/09/13 21:29, Russell King wrote:

+static const struct armada_output_type armada_drm_conn_slave = {
+   .connector_type = DRM_MODE_CONNECTOR_HDMIA,


For a rework of DRM slave encoder API, there should also be some way to
get .connector_type and .encoder_type above from that slave encoder.
IMHO it should be up to the slave encoder to determine connector and
encoder type.


Encoder type - yes, but connector type doesn't seem sensible.  It's
possible for the TDA998x to be connected to a DVI connector - how
would the slave encoder know that?


True. But how should Armada DRM driver know? Actually, it is not
important where we put that information. IMHO it is more likely
to be known by TDA998x as by the corresponding master encoder.
With DT I'd suggest to have a property for TDA998x that sets either
HDMI A/B/C or DVI.

Not related to CuBox setup, but with DisplayPort it can even get worse,
e.g. consider a dumb LCDC connected to some DP++ (HDMI protocol over DP
electrical) encoder connected to a TMDS level shifter. Where do you put
the (final) connector type if not in the last encoder connected to that
chain?

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

[PATCH RFC v2] drm/i2c: tda998x: fix sync generation and calculation

[Sebastian Hesselbarth]

This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).

Signed-off-by: Sebastian Hesselbarth 
---
Note: This patch is based on rmk's Armada DRM driver plus some DT support
fixes, so offsets may vary on your side. Anyway, please 3-way apply and
test wherever possible.

Changelog:
v1->v2:
- also fix interlaced sync generation (tested with 1080i50)

Cc: David Airlie 
Cc: Russell King - ARM Linux 
Cc: Darren Etheridge 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |  173 +++--
 1 files changed, 107 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 819dcba..103a023 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -141,8 +141,12 @@ struct tda998x_priv {
 #define REG_VS_LINE_END_1_LSB REG(0x00, 0xae) /* write */
 #define REG_VS_PIX_END_1_MSB  REG(0x00, 0xaf) /* write */
 #define REG_VS_PIX_END_1_LSB  REG(0x00, 0xb0) /* write */
+#define REG_VS_LINE_STRT_2_MSBREG(0x00, 0xb1) /* write */
+#define REG_VS_LINE_STRT_2_LSBREG(0x00, 0xb2) /* write */
 #define REG_VS_PIX_STRT_2_MSB REG(0x00, 0xb3) /* write */
 #define REG_VS_PIX_STRT_2_LSB REG(0x00, 0xb4) /* write */
+#define REG_VS_LINE_END_2_MSB REG(0x00, 0xb5) /* write */
+#define REG_VS_LINE_END_2_LSB REG(0x00, 0xb6) /* write */
 #define REG_VS_PIX_END_2_MSB  REG(0x00, 0xb7) /* write */
 #define REG_VS_PIX_END_2_LSB  REG(0x00, 0xb8) /* write */
 #define REG_HS_PIX_START_MSB  REG(0x00, 0xb9) /* write */
@@ -153,21 +157,29 @@ struct tda998x_priv {
 #define REG_VWIN_START_1_LSB  REG(0x00, 0xbe) /* write */
 #define REG_VWIN_END_1_MSBREG(0x00, 0xbf) /* write */
 #define REG_VWIN_END_1_LSBREG(0x00, 0xc0) /* write */
+#define REG_VWIN_START_2_MSB  REG(0x00, 0xc1) /* write */
+#define REG_VWIN_START_2_LSB  REG(0x00, 0xc2) /* write */
+#define REG_VWIN_END_2_MSBREG(0x00, 0xc3) /* write */
+#define REG_VWIN_END_2_LSBREG(0x00, 0xc4) /* write */
 #define REG_DE_START_MSB  REG(0x00, 0xc5) /* write */
 #define REG_DE_START_LSB  REG(0x00, 0xc6) /* write */
 #define REG_DE_STOP_MSB   REG(0x00, 0xc7) /* write */
 #define REG_DE_STOP_LSB   REG(0x00, 0xc8) /* write */
 #define REG_TBG_CNTRL_0   REG(0x00, 0xca) /* write */
+# define TBG_CNTRL_0_TOP_TGL  (1 << 0)
+# define TBG_CNTRL_0_TOP_SEL  (1 << 1)
+# define TBG_CNTRL_0_DE_EXT   (1 << 2)
+# define TBG_CNTRL_0_TOP_EXT  (1 << 3)
 # define TBG_CNTRL_0_FRAME_DIS(1 << 5)
 # define TBG_CNTRL_0_SYNC_MTHD(1 << 6)
 # define TBG_CNTRL_0_SYNC_ONCE(1 << 7)
 #define REG_TBG_CNTRL_1   REG(0x00, 0xcb) /* write */
-# define TBG_CNTRL_1_VH_TGL_0 (1 << 0)
-# define TBG_CNTRL_1_VH_TGL_1 (1 << 1)
-# define TBG_CNTRL_1_VH_TGL_2 (1 << 2)
-# define TBG_CNTRL_1_VHX_EXT_DE   (1 << 3)
-# define TBG_CNTRL_1_VHX_EXT_HS   (1 << 4)
-# define TBG_CNTRL_1_VHX_EXT_VS   (1 << 5)
+# define TBG_CNTRL_1_H_TGL(1 << 0)
+# define TBG_CNTRL_1_V_TGL(1 << 1)
+# define TBG_CNTRL_1_TGL_EN   (1 << 2)
+# define TBG_CNTRL_1_X_EXT(1 << 3)
+# define TBG_CNTRL_1_H_EXT(1 << 4)
+# define TBG_CNTRL_1_V_EXT(1 << 5)
 # define TBG_CNTRL_1_DWIN_DIS (1 << 6)
 #define REG_ENABLE_SPACE  REG(0x00, 0xd6) /* write */
 #define REG_HVF_CNTRL_0   REG(0x00, 0xe4) /* write */
@@ -740,43 +752,62 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   uint16_t hs_start, hs_end, line_start, line_end;
-   uint16_t vwin_start, vwin_end, de_start, de_end;
-   uint16_t ref_pix, ref_line, pix_start2;
+   uint16_t ref_pix, ref_line, n_pix, n_line;
+   uint16_t hs_pix_s, hs_pix_e;
+   uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
+   uint16_t vs2_pix_s, vs2_pix_e, vs2_line_s, vs2_line_e;
+   uint16_t vwin1_line_s, vwin1_line_e;
+   uint16_t vwin2_line_s, vwin2_line_e;
+   uint16_t de_pix_s, de_pix_e;
uint8_t reg, div, rep;
 
-   hs_start   = mode->hsync_start - mode->hdisplay;
-   hs_end = mode->hsync_end - mode->hdisplay;
-   line_start = 1;
-   line_end   = 1 + mode->vsync_end - mode->vsync_start;
-   vwin_start = mode->vtotal - mode->vsync_start;
-   vwin_end   = vwin_start + mode->vdisplay;
-   de_start   = mode->htotal - mode->hdisplay;
-   de_end = mode->htotal;
-
-   pix_start2 = 0;
-   if (mode->flags &

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark  wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> >  wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> >>>  wrote:
> >>> > This patch adds support for the pair of LCD controllers on the Marvell
> >>> > Armada 510 SoCs.  This driver supports:
> >>> > - multiple contiguous scanout buffers for video and graphics
> >>> > - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
> >>> >   acceleration
> >>> > - dual lcd0 and lcd1 crt operation
> >>> > - video overlay on each LCD crt
> >>>
> >>> Any particular reason for not exposing the overlays as drm_plane's?
> >>> That is probably something that should change before merging the
> >>> driver.
> >>
> >> Only through not understanding much of DRM when I started this.
> >> Provided DRM planes can do everything that I'm already doing with
> >> the overlay support, then yes.  Otherwise, I want to stick with this
> >> which is modelled after the i915 overlay interface.
> 
> Oh i915 overlays aren't a good reason ;-) I've done those way back
> when drm didn't have any plane infrastructure and pretty much as my
> very contribution. So totally lacked any clue.
> 
> If I can scrap together a bit of time I want to port the legacy
> overlay code over to drm planes (and remap the current ioctl interface
> to the drm plane interface for backwards compat). But atm that's
> crushed under a giant pile of other todo items.

Aren't we all :(  The amount of time I have to touch this has reduced
substantially over the last couple of months, which is why there's been
a few weeks between the RFC's for this.

The issue here is that with the overlay interface, all I have to do
with one of these pass-by-phys-address things which the X server gets
is to:

1. associate the phys address with a gem object
2. pass it in via the overlay interface

With the DRM plane stuff, this gets more complicated:

1. associate the phys address with a gem object
2. call another driver private ioctl to bind the gem object to a framebuffer
   (there is no support for this in the generic ioctl API afaics) which
   has to allocate and setup a framebuffer
3. use setplane to update the plane

That all increases the expense of overlay, and adds further memory
allocations to the path (and frees when the previous framebuffer is
discarded.)

That all makes for higher load due to more CPU expense.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC v3] drm/i2c: tda998x: fix sync generation and calculation

[Sebastian Hesselbarth]

This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).

Signed-off-by: Sebastian Hesselbarth 
---
Note: This patch is based on rmk's Armada DRM driver plus some DT support
fixes, so offsets may vary on your side. Anyway, please 3-way apply and
test wherever possible.

Changelog:
v2->v3:
- fixed compiler warnings (it is getting late)

v1->v2:
- also fix interlaced sync generation (tested with 1080i50)

Cc: David Airlie 
Cc: Russell King - ARM Linux 
Cc: Darren Etheridge 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |  174 +++--
 1 files changed, 108 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 819dcba..2c29160 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -141,8 +141,12 @@ struct tda998x_priv {
 #define REG_VS_LINE_END_1_LSB REG(0x00, 0xae) /* write */
 #define REG_VS_PIX_END_1_MSB  REG(0x00, 0xaf) /* write */
 #define REG_VS_PIX_END_1_LSB  REG(0x00, 0xb0) /* write */
+#define REG_VS_LINE_STRT_2_MSBREG(0x00, 0xb1) /* write */
+#define REG_VS_LINE_STRT_2_LSBREG(0x00, 0xb2) /* write */
 #define REG_VS_PIX_STRT_2_MSB REG(0x00, 0xb3) /* write */
 #define REG_VS_PIX_STRT_2_LSB REG(0x00, 0xb4) /* write */
+#define REG_VS_LINE_END_2_MSB REG(0x00, 0xb5) /* write */
+#define REG_VS_LINE_END_2_LSB REG(0x00, 0xb6) /* write */
 #define REG_VS_PIX_END_2_MSB  REG(0x00, 0xb7) /* write */
 #define REG_VS_PIX_END_2_LSB  REG(0x00, 0xb8) /* write */
 #define REG_HS_PIX_START_MSB  REG(0x00, 0xb9) /* write */
@@ -153,21 +157,29 @@ struct tda998x_priv {
 #define REG_VWIN_START_1_LSB  REG(0x00, 0xbe) /* write */
 #define REG_VWIN_END_1_MSBREG(0x00, 0xbf) /* write */
 #define REG_VWIN_END_1_LSBREG(0x00, 0xc0) /* write */
+#define REG_VWIN_START_2_MSB  REG(0x00, 0xc1) /* write */
+#define REG_VWIN_START_2_LSB  REG(0x00, 0xc2) /* write */
+#define REG_VWIN_END_2_MSBREG(0x00, 0xc3) /* write */
+#define REG_VWIN_END_2_LSBREG(0x00, 0xc4) /* write */
 #define REG_DE_START_MSB  REG(0x00, 0xc5) /* write */
 #define REG_DE_START_LSB  REG(0x00, 0xc6) /* write */
 #define REG_DE_STOP_MSB   REG(0x00, 0xc7) /* write */
 #define REG_DE_STOP_LSB   REG(0x00, 0xc8) /* write */
 #define REG_TBG_CNTRL_0   REG(0x00, 0xca) /* write */
+# define TBG_CNTRL_0_TOP_TGL  (1 << 0)
+# define TBG_CNTRL_0_TOP_SEL  (1 << 1)
+# define TBG_CNTRL_0_DE_EXT   (1 << 2)
+# define TBG_CNTRL_0_TOP_EXT  (1 << 3)
 # define TBG_CNTRL_0_FRAME_DIS(1 << 5)
 # define TBG_CNTRL_0_SYNC_MTHD(1 << 6)
 # define TBG_CNTRL_0_SYNC_ONCE(1 << 7)
 #define REG_TBG_CNTRL_1   REG(0x00, 0xcb) /* write */
-# define TBG_CNTRL_1_VH_TGL_0 (1 << 0)
-# define TBG_CNTRL_1_VH_TGL_1 (1 << 1)
-# define TBG_CNTRL_1_VH_TGL_2 (1 << 2)
-# define TBG_CNTRL_1_VHX_EXT_DE   (1 << 3)
-# define TBG_CNTRL_1_VHX_EXT_HS   (1 << 4)
-# define TBG_CNTRL_1_VHX_EXT_VS   (1 << 5)
+# define TBG_CNTRL_1_H_TGL(1 << 0)
+# define TBG_CNTRL_1_V_TGL(1 << 1)
+# define TBG_CNTRL_1_TGL_EN   (1 << 2)
+# define TBG_CNTRL_1_X_EXT(1 << 3)
+# define TBG_CNTRL_1_H_EXT(1 << 4)
+# define TBG_CNTRL_1_V_EXT(1 << 5)
 # define TBG_CNTRL_1_DWIN_DIS (1 << 6)
 #define REG_ENABLE_SPACE  REG(0x00, 0xd6) /* write */
 #define REG_HVF_CNTRL_0   REG(0x00, 0xe4) /* write */
@@ -740,43 +752,63 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   uint16_t hs_start, hs_end, line_start, line_end;
-   uint16_t vwin_start, vwin_end, de_start, de_end;
-   uint16_t ref_pix, ref_line, pix_start2;
+   uint16_t ref_pix, ref_line, n_pix, n_line;
+   uint16_t hs_pix_s, hs_pix_e;
+   uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
+   uint16_t vs2_pix_s, vs2_pix_e, vs2_line_s, vs2_line_e;
+   uint16_t vwin1_line_s, vwin1_line_e;
+   uint16_t vwin2_line_s, vwin2_line_e;
+   uint16_t de_pix_s, de_pix_e;
uint8_t reg, div, rep;
 
-   hs_start   = mode->hsync_start - mode->hdisplay;
-   hs_end = mode->hsync_end - mode->hdisplay;
-   line_start = 1;
-   line_end   = 1 + mode->vsync_end - mode->vsync_start;
-   vwin_start = mode->vtotal - mode->vsync_start;
-   vwin_end   = vwin_start + mode->vdisplay;
-   de_start   = mode->htotal - mode->hdisplay;
-   de_end = mode->hto

Re: [RFC v3 0/4] rmk's Dove DRM/TDA19988 Cubox driver

[Russell King - ARM Linux]

Okay, so the previous set didn't contain all the updates I wanted.
That's partly because of the timespan between making those changes
and re-posting the RFC.

This time, the "Add Armada DRM driver" commit contains all the
updates it should've had from last time!

However, I'm posting a slightly different branch - it's rooted at
the same "Add Armada DRM driver" commit so take patch 1 from this
as an update to patch 2 of the previous series.

This looks like:
+  DRM: Armada: Add Armada DRM driver
|\
+ | drm/i2c: nxp-tda998x patches
+ | DRM: Armada: add support for drm tda19988 driver
  + DRM: Armada: Add support for hardware cursors
  + DRM: Armada: convert Armada hardware cursor support to RGB+transparency
  + DRM: Armada: convert hardware cursor support to 64x32 or 32x64 ARGB

Now, the three additional patches where incrementally add hardware
cursor support; first my original version.  This didn't work very well.
Next is my try with the RGB+transparency suggested in the first RFC
round.  The cursor image looked silly against some windows because
you can't sanely translate an alpha channel to transparency.

The last version is what I'm using, and I _am_ using hardware cursors.
This seems to be the best solution if we're going to have hardware
cursors, even though it means that we don't support 64x64 cursors.

For the first patch (the main large patch) the changes are as per my
reply to the previous review comments confirming the updates, and
a couple of other changes which should've been in the previous RFC:

1. if we map a gem object in kernel space, store its kernel space
   address.  This avoids use of phys_to_virt() in the cursor code
   which really wasn't nice.
2. initial variant-based clocking support to support non-Dove
   implementations.

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

[PATCH RFC v3 4/4] DRM: Armada: convert hardware cursor support to 64x32 or 32x64 ARGB

[Russell King]

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c |  125 +++---
 drivers/gpu/drm/armada/armada_hw.h   |6 +-
 2 files changed, 43 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index b833014..3e2f9d3 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -493,7 +493,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
dcrtc->v[1].spu_adv_reg = val << 20 | val;
 
/* Always enable RGB hardware cursor mode */
-   dcrtc->v[1].spu_adv_reg |= ADV_HWC32ENABLE;
+   dcrtc->v[1].spu_adv_reg |= ADV_HWC32ENABLE |
+  ADV_HWC32ARGB | ADV_HWC32BLEND;
 
if (interlaced) {
/* Odd interlaced frame */
@@ -641,100 +642,46 @@ static const struct drm_crtc_helper_funcs 
armada_crtc_helper_funcs = {
 };
 
 #ifdef CONFIG_DRM_ARMADA_CURSOR
-static void armada_load_cursor_rgb(void __iomem *base, uint32_t *pix,
+static void armada_load_cursor_argb(void __iomem *base, uint32_t *pix,
unsigned stride, unsigned width, unsigned height)
 {
-   uint32_t r, g, b, addr;
-   unsigned y, n;
+   uint32_t addr;
+   unsigned y;
 
-   for (r = g = b = addr = n = y = 0; y < height; y++) {
+   addr = SRAM_HWC32_RAM1;
+   for (y = 0; y < height; y++) {
uint32_t *p = &pix[y * stride];
unsigned x;
 
for (x = 0; x < width; x++, p++) {
-   r >>= 8;
-   r |= 0xff00 & (*p << 8);
-   g >>= 8;
-   g |= 0xff00 & (*p << 16);
-   b >>= 8;
-   b |= 0xff00 & (*p << 24);
-   if (x == 0 || y == 0) {
-   b |= 0xff00;
-   g |= 0xff00;
-   r &= ~0xff00;
-   }
-   if (++n == 4) {
-   writel_relaxed(r,
-  base + LCD_SPU_SRAM_WRDAT);
-   writel_relaxed(addr |
-  SRAM_WRITE | SRAM_HWC32_RAMR,
-  base + LCD_SPU_SRAM_CTRL);
-   writel_relaxed(g,
-  base + LCD_SPU_SRAM_WRDAT);
-   writel_relaxed(addr |
-  SRAM_WRITE | SRAM_HWC32_RAMG,
-  base + LCD_SPU_SRAM_CTRL);
-   writel_relaxed(b,
-  base + LCD_SPU_SRAM_WRDAT);
-   writel_relaxed(addr |
-  SRAM_WRITE | SRAM_HWC32_RAMB,
-  base + LCD_SPU_SRAM_CTRL);
-   addr += 1;
-   if ((addr & 255) == 0)
-   addr += 0xf00;
-   n = 0;
-   }
+   uint32_t val = *p;
+
+   val = (val & 0xff00ff00) |
+ (val & 0x00ff) << 16 |
+ (val & 0x00ff) >> 16;
+
+   writel_relaxed(val,
+  base + LCD_SPU_SRAM_WRDAT);
+   writel_relaxed(addr | SRAM_WRITE,
+  base + LCD_SPU_SRAM_CTRL);
+   addr += 1;
+   if ((addr & 0x00ff) == 0)
+   addr += 0xf00;
+   if ((addr & 0x30ff) == 0)
+   addr = SRAM_HWC32_RAM2;
}
}
-   if (n) {
-   r >>= 8 * (4 - n);
-   g >>= 8 * (4 - n);
-   b >>= 8 * (4 - n);
-   writel_relaxed(r, base + LCD_SPU_SRAM_WRDAT);
-   writel_relaxed(addr | SRAM_WRITE | SRAM_HWC32_RAMR,
-  base + LCD_SPU_SRAM_CTRL);
-   writel_relaxed(g, base + LCD_SPU_SRAM_WRDAT);
-   writel_relaxed(addr | SRAM_WRITE | SRAM_HWC32_RAMG,
-  base + LCD_SPU_SRAM_CTRL);
-   writel_relaxed(b, base + LCD_SPU_SRAM_WRDAT);
-   writel_relaxed(addr | SRAM_WRITE | SRAM_HWC32_RAMB,
-  base + LCD_SPU_SRAM_CTRL);
-   }
 }
 
-static void armada_load_cursor_alpha(void __iomem *base, uint32_t *pix,
-   unsigned stride, unsigned width, unsigned height)
+static void armada_drm_crtc_cursor_tran(void __iomem *base)
 {
-   uint32_t data, addr, ram_cmd = SRAM_WRITE | SRAM_HWC32_TRAN;
-   unsigned y, n;
+   unsigned addr

[PATCH RFC v3 2/4] DRM: Armada: Add support for hardware cursors

[Russell King]

This patch adds hardware cursor support to the DRM driver for the
Marvell Armada SoCs.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/Kconfig   |7 +
 drivers/gpu/drm/armada/armada_crtc.c |  201 ++
 drivers/gpu/drm/armada/armada_crtc.h |8 ++
 3 files changed, 216 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index c7a0a94..6f64642 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -13,3 +13,10 @@ config DRM_ARMADA
  This driver provides no built-in acceleration; acceleration is
  performed by other IP found on the SoC.  This driver provides
  kernel mode setting and buffer management to userspace.
+
+config DRM_ARMADA_CURSOR
+   bool "Enable hardware cursor support for Marvell Armada DRM"
+   depends on DRM_ARMADA != n
+   help
+ Add support for hardware cursor support on the Marvell
+ Armada devices.
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index dadaf63..4a71ba0 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -626,11 +626,210 @@ static const struct drm_crtc_helper_funcs 
armada_crtc_helper_funcs = {
.disable= armada_drm_crtc_disable,
 };
 
+#ifdef CONFIG_DRM_ARMADA_CURSOR
+static int armada_drm_crtc_cursor_update(struct armada_crtc *dcrtc, bool 
reload)
+{
+   uint32_t xoff, xscr, w = dcrtc->cursor_w, s;
+   uint32_t yoff, yscr, h = dcrtc->cursor_h;
+
+   /*
+* Calculate the visible width and height of the cursor,
+* screen position, and the position in the cursor bitmap.
+*/
+   if (dcrtc->cursor_x < 0) {
+   xoff = -dcrtc->cursor_x;
+   xscr = 0;
+   w -= min(xoff, w);
+   } else if (dcrtc->cursor_x + w > dcrtc->crtc.mode.hdisplay) {
+   xoff = 0;
+   xscr = dcrtc->cursor_x;
+   w = max_t(int, dcrtc->crtc.mode.hdisplay - dcrtc->cursor_x, 0);
+   } else {
+   xoff = 0;
+   xscr = dcrtc->cursor_x;
+   }
+
+   if (dcrtc->cursor_y < 0) {
+   yoff = -dcrtc->cursor_y;
+   yscr = 0;
+   h -= min(yoff, h);
+   } else if (dcrtc->cursor_y + h > dcrtc->crtc.mode.vdisplay) {
+   yoff = 0;
+   yscr = dcrtc->cursor_y;
+   h = max_t(int, dcrtc->crtc.mode.vdisplay - dcrtc->cursor_y, 0);
+   } else {
+   yoff = 0;
+   yscr = dcrtc->cursor_y;
+   }
+
+   /* On interlaced modes, the vertical cursor size must be halved */
+   s = dcrtc->cursor_w;
+   if (dcrtc->interlaced) {
+   s *= 2;
+   yscr /= 2;
+   h /= 2;
+   }
+
+   if (!dcrtc->cursor_obj || !h || !w) {
+   spin_lock_irq(&dcrtc->irq_lock);
+   armada_updatel(0, CFG_HWC_ENA, dcrtc->base + LCD_SPU_DMA_CTRL0);
+   spin_unlock_irq(&dcrtc->irq_lock);
+   return 0;
+   }
+
+   armada_updatel(CFG_CSB_256x32, CFG_PDWN256x32,
+dcrtc->base + LCD_SPU_SRAM_PARA1);
+
+   if (dcrtc->cursor_lw != w || dcrtc->cursor_lh != h || reload) {
+   struct armada_gem_object *obj = dcrtc->cursor_obj;
+   uint32_t *pix, *p, col2 = 0, col3 = 0;
+   unsigned x, y, d, n, a;
+
+   dcrtc->cursor_lw = w;
+   dcrtc->cursor_lh = h;
+
+   pix = obj->addr;
+
+   /* Set the top-left corner of the cursor image */
+   pix += yoff * s + xoff;
+
+   a = 2 << 14 | 15 << 8;
+   for (d = n = y = 0; y < h; y++) {
+   for (x = 0, p = &pix[y * s]; x < w; x++, p++) {
+   uint32_t v = *p;
+   unsigned b;
+
+   if ((v & 0xff00) != 0xff00) {
+   b = 0;  /* transparent */
+   } else if (col2 == v) {
+   b = 2;  /* color 2 */
+   } else if (col3 == v) {
+   b = 3;  /* color 3 */
+   } else if (col2 == 0) {
+   col2 = v;
+   b = 2;  /* alloc color 2 */
+   } else if (col3 == 0) {
+   col3 = v;
+   b = 3;  /* alloc color 3 */
+   } else {
+   /* fail */
+   b = 1;  /* inverse (!) */
+   }
+
+   d |= b << n;
+   n += 2;
+
+   if (

[PATCH RFC v3 3/4] DRM: Armada: convert Armada hardware cursor support to RGB+transparency

[Russell King]

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/Kconfig   |6 +-
 drivers/gpu/drm/armada/armada_crtc.c |  186 +++--
 drivers/gpu/drm/armada/armada_crtc.h |5 +-
 3 files changed, 135 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index 6f64642..c401339 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -15,8 +15,8 @@ config DRM_ARMADA
  kernel mode setting and buffer management to userspace.
 
 config DRM_ARMADA_CURSOR
-   bool "Enable hardware cursor support for Marvell Armada DRM"
+   bool "Enable hardware RGB+T cursor support for Marvell Armada DRM"
depends on DRM_ARMADA != n
help
- Add support for hardware cursor support on the Marvell
- Armada devices.
+ Add support for RGB+transparency hardware cursor support on
+ the Marvell Armada devices.
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 4a71ba0..b833014 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -369,8 +369,19 @@ void armada_drm_crtc_irq(struct armada_crtc *dcrtc, u32 
stat)
val = readl_relaxed(base + LCD_SPU_ADV_REG);
val &= ~(0xfff << 20 | 0xfff);
val |= dcrtc->v[i].spu_adv_reg;
-   writel_relaxed(val, dcrtc->base + LCD_SPU_ADV_REG);
+   writel_relaxed(val, base + LCD_SPU_ADV_REG);
}
+
+   if (stat & DUMB_FRAMEDONE && dcrtc->cursor_update) {
+   writel_relaxed(dcrtc->cursor_hw_pos, base + 
LCD_SPU_HWC_OVSA_HPXL_VLN);
+   writel_relaxed(dcrtc->cursor_hw_sz, base + 
LCD_SPU_HWC_HPXL_VLN);
+   armada_updatel(CFG_HWC_ENA,
+CFG_HWC_ENA | CFG_HWC_1BITMOD | CFG_HWC_1BITENA,
+base + LCD_SPU_DMA_CTRL0);
+   dcrtc->cursor_update = false;
+   armada_drm_crtc_disable_irq(dcrtc, DUMB_FRAMEDONE_ENA);
+   }
+
spin_unlock(&dcrtc->irq_lock);
 
/* Only on frame 0 IRQs (start of progressive / odd frame) */
@@ -481,6 +492,9 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
val = adj->crtc_hsync_start;
dcrtc->v[1].spu_adv_reg = val << 20 | val;
 
+   /* Always enable RGB hardware cursor mode */
+   dcrtc->v[1].spu_adv_reg |= ADV_HWC32ENABLE;
+
if (interlaced) {
/* Odd interlaced frame */
dcrtc->v[0].spu_v_h_total = dcrtc->v[1].spu_v_h_total +
@@ -627,6 +641,103 @@ static const struct drm_crtc_helper_funcs 
armada_crtc_helper_funcs = {
 };
 
 #ifdef CONFIG_DRM_ARMADA_CURSOR
+static void armada_load_cursor_rgb(void __iomem *base, uint32_t *pix,
+   unsigned stride, unsigned width, unsigned height)
+{
+   uint32_t r, g, b, addr;
+   unsigned y, n;
+
+   for (r = g = b = addr = n = y = 0; y < height; y++) {
+   uint32_t *p = &pix[y * stride];
+   unsigned x;
+
+   for (x = 0; x < width; x++, p++) {
+   r >>= 8;
+   r |= 0xff00 & (*p << 8);
+   g >>= 8;
+   g |= 0xff00 & (*p << 16);
+   b >>= 8;
+   b |= 0xff00 & (*p << 24);
+   if (x == 0 || y == 0) {
+   b |= 0xff00;
+   g |= 0xff00;
+   r &= ~0xff00;
+   }
+   if (++n == 4) {
+   writel_relaxed(r,
+  base + LCD_SPU_SRAM_WRDAT);
+   writel_relaxed(addr |
+  SRAM_WRITE | SRAM_HWC32_RAMR,
+  base + LCD_SPU_SRAM_CTRL);
+   writel_relaxed(g,
+  base + LCD_SPU_SRAM_WRDAT);
+   writel_relaxed(addr |
+  SRAM_WRITE | SRAM_HWC32_RAMG,
+  base + LCD_SPU_SRAM_CTRL);
+   writel_relaxed(b,
+  base + LCD_SPU_SRAM_WRDAT);
+   writel_relaxed(addr |
+  SRAM_WRITE | SRAM_HWC32_RAMB,
+  base + LCD_SPU_SRAM_CTRL);
+   addr += 1;
+   if ((addr & 255) == 0)
+   addr += 0xf00;
+   n = 0;
+   }
+   }
+   }
+   if (n) {
+   r >>= 8 * (4 - n);
+   g >>= 8 * (4 - n);
+   b >>=

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver.  It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you rebase.  And then try to get the vendor to
> add support for dmabuf so that the patch on top of upstream can
> eventually be dropped.  Maybe someone else has a better suggestion,
> but I don't think we can merge those phys ioctls upstream, and I'd
> really hate to 'throw the baby out with the bathwater' in this case
> and not at least get the modesetting part of the driver merged.

What you're saying is basically:

1. Throw out DRM_ARMADA_GEM_CREATE_PHYS, which cripples video playback
   on existing gstreamer, xbmc and other implementations without someone
   rewriting all that code.

2. Throw out DRM_ARMADA_GEM_PROP, which prevents any form of passing
   the GEM objects to the GPU libraries in userspace, thereby preventing
   any kind of GPU based acceleration.

That makes the driver just be a dumb scanout only driver.  Sorry,
that *really* does not interest me one bit, because the CPU doing
framebuffer accesses is pig slow.

There's really no point in such a driver; people might as well just
use the standard fbdev driver instead.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements
> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.

I am *not* using the CMA layer - that layer is just plain broken in
DRM.  It forces every single gem object to be a CMA allocated object,
which means I can't have cacheable pixmaps in X.  And that makes X
suck.

Okay, I'm pulling this and I'm going to keep it in my private cubox
tree; I'm not persuing pushing this driver or any other Armada 510
driver into mainline anymore.  It's just too much fscking hastle
dealing with people who don't like various stuff.

I've done my best to clean a lot of the crap up, and the problem is
that no matter how much I clean up, it remains unacceptable.  Only
the 100% perfect solution seems to be acceptable.  That is
unacceptable given that this stuff has already consumed something
like 8 months solid of my time.

So no, I'm not wasting any further time on this crap.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
>  wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> >> ioctls as a small patch on top of the upstream driver.  It is ok to
> >> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> >> #'s don't shift when you rebase.  And then try to get the vendor to
> >> add support for dmabuf so that the patch on top of upstream can
> >> eventually be dropped.  Maybe someone else has a better suggestion,
> >> but I don't think we can merge those phys ioctls upstream, and I'd
> >> really hate to 'throw the baby out with the bathwater' in this case
> >> and not at least get the modesetting part of the driver merged.
> >
> > What you're saying is basically:
> >
> > 1. Throw out DRM_ARMADA_GEM_CREATE_PHYS, which cripples video playback
> >on existing gstreamer, xbmc and other implementations without someone
> >rewriting all that code.
> >
> > 2. Throw out DRM_ARMADA_GEM_PROP, which prevents any form of passing
> >the GEM objects to the GPU libraries in userspace, thereby preventing
> >any kind of GPU based acceleration.
> >
> > That makes the driver just be a dumb scanout only driver.  Sorry,
> > that *really* does not interest me one bit, because the CPU doing
> > framebuffer accesses is pig slow.
> 
> Well, yes that is basically what I am saying, unless we can find a
> different way (dmabuf? if there is some way to pass it through the
> blob bits you don't have src code for?)
> 
> The problem is that we really can't merge something upstream that lets
> you dma to arbitrary physical address.  Maybe in staging, perhaps?  Or

Which bit of "THIS DRIVER DOESN'T DMA _TO_ ANY ADDRESS" did you not yet?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
>  wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> >> come an unmaintainable
> >> nightmare for everyone, but mostly for me.
> >
> > I am *not* using the CMA layer - that layer is just plain broken in
> > DRM.  It forces every single gem object to be a CMA allocated object,
> > which means I can't have cacheable pixmaps in X.  And that makes X
> > suck.
> >
> > Okay, I'm pulling this and I'm going to keep it in my private cubox
> > tree; I'm not persuing pushing this driver or any other Armada 510
> > driver into mainline anymore.  It's just too much fscking hastle
> > dealing with people who don't like various stuff.
> >
> > I've done my best to clean a lot of the crap up, and the problem is
> > that no matter how much I clean up, it remains unacceptable.  Only
> > the 100% perfect solution seems to be acceptable.  That is
> > unacceptable given that this stuff has already consumed something
> > like 8 months solid of my time.
> 
> Russell, aren't you a kernel maintainer, because for fuck sake get real.
> 
> I'm not merging bullshit into my tree that has a completely broken API that
> has to be maintained for ever. You of all people should understand we
> don't break Linux
> userspace APIs, and adding a phys addr one is wrong, wrong, wrong, its not
> cleanups, its just broken, and I'll never merge it.

As I say, I'm no longer interested in pushing this into mainline.  I've
said my piece above, and I'm not changing that.  I'm not spending years
trying to sort this stuff out, by which time the platforms using it will
be long since obsolete.  The "8 months" is not an exaggeration.  That's
the time taken to sort out the kernel side, the libdrm stuff, the
X server driver, and get video decode working on these platforms with
vlc.

It works for me, and that's really at this point all I care about.

And yes, I'm a kernel maintainer.  A FUCKING busy one right now at that.
I haven't stopped working since 9am today yet, and it's now 1am.  Do the
maths.  I really wish I had some time to myself now to think about some
of these bigger issues which this has brought up, but I don't.

And no, I *never* said that adding a phys address was a cleanup.

Sheesh why don't you read my emails properly.  Another reason why I
won't be continuing this discussion much further.

I said that _this_ amount of effort is a result of doing *LOTS* of
cleanups.  A DRM driver for this hardware *didn't* exist until I wrote
it.  There was a fbdev driver before, which was passed phys addresses
there for the overlay, and passed phys addresses back out after the
overlay frame has been replaced.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau: Load firmware for BSP/VP engines on NV84-NV96, NVA0

[Ben Skeggs]

On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin  wrote:
> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
>  wrote:
>> Hey,
>>
>> Op 04-06-13 20:38, Ilia Mirkin schreef:
>>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin  wrote:
 These chipsets include the VP2 engine which is composed of a bitstream
 processor (BSP) that decodes H.264 and a video processor (VP) which can
 do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
 driven by separate xtensa chips embedded in the hardware. This patch
 provides the mechanism to load the kernel for the xtensa chips and
 provide the necessary interactions to do the rest of the work.

 Signed-off-by: Ilia Mirkin 
 ---

 This patch applies on top of nouveau/master (16a41bcc8).

 This seems to work for me. There was one boot where my userspace
 component didn't work right, but it could just as well be a bug
 there. Subsequent attempts seem to work fine. Note that I'm not
 particularly familiar with any of this stuff, so if something looks
 odd, I probably didn't know any better. I did try to faithfully
 reproduce whatever the blob did. A few questions/thoughts:

 1. There's a LOT of similarity between BSP and VP setup/etc. Is it
worth it to create a core/xtensa.c or some such, similar to
falcon.c? Since it's only in two places, not that much code, and
there _are_ differences, I decided to keep them separate.

 2. Firmware naming. Maarten suggested to use the falcon naming style,
which is nv$chipset_fuc$offset. However here, all the chips share
the same firmware. Also the offset would be 103 vs 00f, and is a
little arbitrary. (And fuc doesn't apply here... xt? xtensa?) I've
left it the way I had it: nv84_bsp and nv84_vp.

 3. Firmware load time. I chose to load the fw into memory in the ctor,
and then copy it in in init, due to some potentially bogus
suspend/resume concerns. Also e.g. mplayer likes to create/destroy
decoders at startup a few times. The downside is that ~200KB of
memory is gone. Let me know if I should change it to do the
request_firmware in init.

 There's obviously a userspace piece to this, which I'm still working
 on. But right now I have it working within certain parameters
 (e.g. 1280x544 videos), and I'm relatively confident it can be
 completed without further kernel-side changes.

 There's also a hypothetical concern of "what if we create an open
 firmware with a different user API". Ideally there'd be some way to
 expose what kind of firmware is loaded, but I think that can be left
 for "later".
>>>
>>> I also happened to notice that NV98, NVA1+ refer to these nv84 engines
>>> (in drivers/gpu/drm/nouveau/core/engine/device/nv50.c). I assume that
>>> means I should create a new nv98.c version of BSP/VP that resembles
>>> the old versions of nv84.c, and point device/nv50.c at those for nv98
>>> and nva1+?
>>>
>> nv98+ should really have an implementation more like nvc0, and the copy 
>> engine
>> is a good example on what conversion is needed to do it. :-)
>
> That should probably be a separate patch, no? Do you mean something
> more falcon-y? (It still needs firmware, right?) I think I should just
> avoid changing things on those cards in this patch... (Also the only
> NV card I have access to is my NV96, so I'll be more likely to keep
> playing with that :) )
>
Just a note that I haven't forgotten about this.  I'm just finish off
a few things, and I'll give my comments at the end of the week!

Maarten, if you're reading this, same goes for your nvd7 branch :)

Ben.

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

Re: [PATCH] drm/tegra: add support for runtime pm

[Terje Bergström]

On 10.06.2013 23:43, Thierry Reding wrote:
> Can you post the corresponding wrappers to make it easier to discuss
> them? If they just wrap runtime PM calls then they don't solve the
> locality problems that Terje brought up.

I don't think the wrappers are applicable here. They're there in
downstream to fix a problem with runtime PM core: some host1x clients
require host1x to be active when they're processing, and some (dc) need
it only when CPU is programming DC or when a signal towards host1x is
pending. Runtime PM wants to keep parent enabled when any of the clients
are enabled.

We solved this downstream by enabling ignore_children for host1x. As a
side effect, we need to explicitly enable host1x when we're enabling one
of its clients that need host1x, and that's what the wrapper does.

We can fix this particular problem by moving calls to runtime PM to job.c.

Mayuresh, once you've managed to test your patches, please send the v2.

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

[RFC][PATCH 1/2] dma-buf: add importer private data to attachment

[김승우]

On 2013? 06? 07? 20:24, Maarten Lankhorst wrote:
> Op 07-06-13 04:32, ??? schreef:
>> Hello Maarten,
>>
>> On 2013? 06? 05? 22:23, Maarten Lankhorst wrote:
>>> Op 31-05-13 10:54, Seung-Woo Kim schreef:
 dma-buf attachment has only exporter private data, but importer private 
 data
 can be useful for importer especially to re-import the same dma-buf.
 To use importer private data in attachment of the device, the function to
 search attachment in the attachment list of dma-buf is also added.

 Signed-off-by: Seung-Woo Kim 
 ---
  drivers/base/dma-buf.c  |   31 +++
  include/linux/dma-buf.h |4 
  2 files changed, 35 insertions(+), 0 deletions(-)

 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index 08fe897..a1eaaf2 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -259,6 +259,37 @@ err_attach:
  EXPORT_SYMBOL_GPL(dma_buf_attach);
  
  /**
 + * dma_buf_get_attachment - Get attachment with the device from dma_buf's
 + * attachments list
 + * @dmabuf:   [in]buffer to find device from.
 + * @dev:  [in]device to be found.
 + *
 + * Returns struct dma_buf_attachment * attaching the device; may return
 + * negative error codes.
 + *
 + */
 +struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
 +struct device *dev)
 +{
 +  struct dma_buf_attachment *attach;
 +
 +  if (WARN_ON(!dmabuf || !dev))
 +  return ERR_PTR(-EINVAL);
 +
 +  mutex_lock(&dmabuf->lock);
 +  list_for_each_entry(attach, &dmabuf->attachments, node) {
 +  if (attach->dev == dev) {
 +  mutex_unlock(&dmabuf->lock);
 +  return attach;
 +  }
 +  }
 +  mutex_unlock(&dmabuf->lock);
 +
 +  return ERR_PTR(-ENODEV);
 +}
 +EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
>>> NAK in any form..
>>>
>>> Spot the race condition between dma_buf_get_attachment and 
>>> dma_buf_attach
>> Both dma_buf_get_attachment and dma_buf_attach has mutet with
>> dmabuf->lock, and dma_buf_get_attachment is used for get attachment from
>> same device before calling dma_buf_attach.
> 
> hint: what happens if 2 threads do this:
> 
> if (IS_ERR(attach = dma_buf_get_attachment(buf, dev)))
> attach = dma_buf_attach(buf, dev);
> 
> There really is no correct usecase for this kind of thing, so please don't do 
> it.

Ok, dma_buf_get_attachment can not prevent attachments from one device.

Anyway, do you think that importer side private data, not to allow
re-import one dma-buf to a device, has some advantage?
If that, I'll add some check_and_attach function, otherwise, I'll find
other way.

Thanks and Regards,
- Seung-Woo Kim

> 
>> While, dma_buf_detach can removes attachment because it does not have
>> ref count. So importer should check ref count in its importer private
>> data before calling dma_buf_detach if the importer want to use
>> dma_buf_get_attachment.
>>
>> And dma_buf_get_attachment is for the importer, so exporter attach and
>> detach callback operation should not call it as like exporter detach
>> callback operation should not call dma_buf_attach if you mean this kind
>> of race.
>>
>> If you have other considerations here, please describe more specifically.
>>
>> Thanks and Best Regards,
>> - Seung-Woo Kim
>>
>>> ~Maarten
>>>
>>>
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

[inconsistent HARDIRQ usage] &dev->mode_config.idr_mutex at drm_mode_object_find()

[Fengguang Wu]

Maarten,

Sorry for the delay!

On Sun, Jun 09, 2013 at 08:58:44AM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 06-06-13 09:28, Fengguang Wu schreef:
> > Hi Maarten,
> >
> > Thanks for the patch! I'll queue it for the tests.
> >
> > 
> I haven't heard back from you yet, did it fix all lockdep issues you were 
> having?
> If so I'll get it queued.

Booted 1000 kernels with the patch, I no longer see the
mutex_trylock() warning. However there is one single occurrence of
this warning. Not sure how relevant it is.

[  347.858442] =
[  347.858442] [ INFO: inconsistent lock state ]
[  347.858442] 3.9.0-rc5-00675-ga35505b #60 Not tainted
[  347.858442] -
[  347.858442] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[  347.858442] umount/122 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  347.858442]  (&dev->mode_config.idr_mutex){?.+.+.}, at: [] 
drm_mode_object_find+0xf2/0x110

Thanks,
Fengguang

PS. full dmesg.

[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.9.0-rc5-00675-ga35505b (kbuild at cairo) (gcc 
version 4.7.2 (Debian 4.7.2-4) ) #60 SMP Mon Jun 10 03:33:41 CST 2013
[0.00] Command line: hung_task_panic=1 
rcutree.rcu_cpu_stall_timeout=100 log_buf_len=8M ignore_loglevel debug 
sched_debug apic=debug dynamic_printk sysrq_always_enabled panic=10  
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal  root=/dev/ram0 
rw 
link=/kernel-tests/run-queue/kvm/x86_64-randconfig-c00-0605/wfg:0day/.vmlinuz-a35505b46be17ab9c91d77bf0b47df477b7181e1-20130610063801-720-ant
 branch=wfg/0day noapic nolapic nohz=off 
BOOT_IMAGE=/kernel/x86_64-randconfig-c00-0605/a35505b46be17ab9c91d77bf0b47df477b7181e1/vmlinuz-3.9.0-rc5-00675-ga35505b
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00093bff] usable
[0.00] BIOS-e820: [mem 0x00093c00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable
[0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2007
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00E000 mask FFE000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] Scan for SMP in [mem 0x-0x03ff]
[0.00] Scan for SMP in [mem 0x0009fc00-0x0009]
[0.00] Scan for SMP in [mem 0x000f-0x000f]
[0.00] found SMP MP-table at [mem 0x000fdab0-0x000fdabf] mapped at 
[880fdab0]
[0.00]   mpc: fdac0-fdbe4
[0.00] Base memory trampoline at [8808d000] 8d000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x035f3000, 0x035f3fff] PGTABLE
[0.00] BRK [0x035f4000, 0x035f4fff] PGTABLE
[0.00] BRK [0x035f5000, 0x035f5fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0e60-0x0e7f]
[0.00]  [mem 0x0e60-0x0e7f] page 2M
[0.00] init_memory_mapping: [mem 0x0c00-0x0e5f]
[0.00]  [mem 0x0c00-0x0e5f] page 2M
[0.00] init_memory_mapping: [mem 0x0010-0x0bff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0x0bff] page 2M
[0.00] init_memory_mapping: [mem 0x0e80-0x0fffdfff]
[0.00]  [mem 0x0e80-0x0fdf] page 2M
[0.00]  [mem 0x0fe0-0x0fffdfff] page 4k
[0.00] BRK [0x035f6000, 0x035f6fff] PGTABLE
[0.00] log_buf_len: 8388608
[0.00] early log buf free: 127440(97%)
[0.00] RAMDISK: [mem 0x0e8d6000-0x0ffe]
[0.00] ACPI: RSDP 000fd920 00014 (v00 BOCHS )
[0.00] ACPI: RSDT 0fffe550 00038 (v01 BOCHS  BXPCRSDT 0001 
BXPC 0001)
[0.00] ACPI: FACP 0f80 00074 (v01 BOCHS  BXPCFACP 0001 
BXPC 0001)
[0.00] ACPI: DSDT 0ff

[Bug 65254] opengl flicker in xbmc / glxgears

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from adam  ---
This is probably same as bug #60389

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

[inconsistent HARDIRQ usage] &dev->mode_config.idr_mutex at drm_mode_object_find()

[Maarten Lankhorst]

Op 10-06-13 03:55, Fengguang Wu schreef:
> Maarten,
>
> Sorry for the delay!
>
> On Sun, Jun 09, 2013 at 08:58:44AM +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 06-06-13 09:28, Fengguang Wu schreef:
>>> Hi Maarten,
>>>
>>> Thanks for the patch! I'll queue it for the tests.
>>>
>>> 
>> I haven't heard back from you yet, did it fix all lockdep issues you were 
>> having?
>> If so I'll get it queued.
> Booted 1000 kernels with the patch, I no longer see the
> mutex_trylock() warning. However there is one single occurrence of
> this warning. Not sure how relevant it is.
>
> [  347.858442] =
> [  347.858442] [ INFO: inconsistent lock state ]
> [  347.858442] 3.9.0-rc5-00675-ga35505b #60 Not tainted
> [  347.858442] -
> [  347.858442] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [  347.858442] umount/122 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [  347.858442]  (&dev->mode_config.idr_mutex){?.+.+.}, at: 
> [] drm_mode_object_find+0xf2/0x110
>
> Thanks,
> Fengguang
>
> PS. full dmesg.
> 
> [  309.914133] raid6test: complete (257 tests, 0 failures)
> [  310.338146]   Magic number: 1:250:706
> [  310.458434] tty ttySL122: hash matches
> [  310.589995] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
> [  310.709702] EDD information not available.
> [  310.906183] ALSA device list:
> [  311.026184]   #0: Dummy 1
> [  311.153927]   #1: Loopback 1
> [  311.277938]   #2: MTPAV on parallel port at 0x378
> [  312.230916] Freeing unused kernel memory: 1052k freed
> [  323.435915] hostname (110) used greatest stack depth: 5080 bytes left
> [  347.855138] BUG: soft lockup - CPU#0 stuck for 22s! [umount:122]
> [  347.858442] irq event stamp: 4246
> [  347.858442] hardirqs last  enabled at (4245): [] 
> mutex_lock_nested+0x380/0x3b0
> [  347.858442] hardirqs last disabled at (4246): [] 
> common_interrupt+0x6d/0x72
> [  347.858442] softirqs last  enabled at (4214): [] 
> __do_softirq+0x242/0x2c0
> [  347.858442] softirqs last disabled at (4175): [] 
> irq_exit+0x63/0xd0
> [  347.858442] CPU 0 
> [  347.858442] Pid: 122, comm: umount Not tainted 3.9.0-rc5-00675-ga35505b 
> #60 Bochs Bochs
> [  347.858442] RIP: 0010:[]  [] 
> mutex_lock_nested+0x386/0x3b0
> [  347.858442] RSP: 0018:8800055ebb48  EFLAGS: 0246
> [  347.858442] RAX: 8800055c6840 RBX: 81130fdb RCX: 
> 0006
> [  347.858442] RDX: 0006 RSI: 8800055c6f20 RDI: 
> 0246
> [  347.858442] RBP: 8800055ebbd8 R08:  R09: 
> 0002
> [  347.858442] R10:  R11:  R12: 
> 8800055c6840
> [  347.858442] R13: 0006 R14: 0007 R15: 
> 8800055c6f20
> [  347.858442] FS:  () GS:88000de0() 
> knlGS:
> [  347.858442] CS:  0010 DS:  ES:  CR0: 8005003b
> [  347.858442] CR2: 7ffc9b7ce09c CR3: 055a2000 CR4: 
> 06f0
> [  347.858442] DR0:  DR1:  DR2: 
> 
> [  347.858442] DR3:  DR6:  DR7: 
> 
> [  347.858442] Process umount (pid: 122, threadinfo 8800055ea000, task 
> 8800055c6840)
> [  347.858442] Stack:
> [  347.858442]  811d3991 7ffc9b7b7fff 7ffc9b7b7fff 
> 7ffc9b7b8000
> [  347.858442]  8800055a2800 7ffc9b7b7fff 88000b975a98 
> 0246
> [  347.858442]  8800055ebb88 8800055ebb88  
> 8800055ebb88
> [  347.858442] Call Trace:
> [  347.858442]  [] ? unlink_file_vma+0x41/0x70
> [  347.858442]  [] unlink_file_vma+0x41/0x70
> [  347.858442]  [] free_pgtables+0x47/0xe0
> [  347.858442]  [] unmap_region+0xdf/0x110
> [  347.858442]  [] ? vma_rb_erase+0x1c9/0x210
> [  347.858442]  [] do_munmap+0x2c2/0x3d0
> [  347.858442]  [] mmap_region+0x596/0x660
> [  347.858442]  [] ? vma_adjust+0x6a7/0x730
> [  347.858442]  [] ? cap_mmap_addr+0x5/0x50
> [  347.858442]  [] do_mmap_pgoff+0x2e2/0x3b0
> [  347.858442]  [] vm_mmap_pgoff+0x75/0xb0
> [  347.858442]  [] ? fget+0x5/0x120
> [  347.858442]  [] sys_mmap_pgoff+0x13b/0x180
> [  347.858442]  [] sys_mmap+0x22/0x30
> [  347.858442]  [] system_call_fastpath+0x16/0x1b
> [  347.858442] Code: 80 47 08 01 48 f7 45 a8 00 02 00 00 75 12 48 8b 7d a8 57 
> 9d 66 66 90 66 90 e8 97 4e 1d ff eb 10 e8 b0 4d 1d ff 48 8b 7d a8 57 9d <66> 
> 66 90 66 90 48 89 df e8 0d 21 1d ff 41 83 6d 1c 01 48 83 c4 
> [  347.858442] Kernel panic - not syncing: softlockup: hung tasks
> [  347.858442] Pid: 122, comm: umount Not tainted 3.9.0-rc5-00675-ga35505b #60
> [  347.858442] Call Trace:
> [  347.858442][] panic+0xc6/0x1d3
> [  347.858442]  [] watchdog_timer_fn+0x172/0x1c0
> [  347.858442]  [] __run_hrtimer+0x131/0x320
> [  347.858442]  [] ? watchdog+0x30/0x30
> [  347.858442]  [] hrtimer_interrupt+0x129/0x230
> [  347.858442]  [] ? put_cred_rcu+0x74/0x80
> [  347.858442]  [] ? rcu_process_callbacks+0x5a9/0x8c0
> 

[PATCH] drm/cirrus: do not attempt to acquire a reservation while in an interrupt handler

[Maarten Lankhorst]

Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:

[   13.044313] [ cut here ]
[   13.044367] WARNING: at /c/kernel-tests/src/tip/kernel/mutex.c:858 
mutex_trylock+0x87/0x220()
[   13.044378] DEBUG_LOCKS_WARN_ON(in_interrupt())
[   13.044378] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
3.10.0-rc4-00296-ga2963dd #20
[   13.044379] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   13.044390]  0009 88000de039f8 81fc86d5 
88000de03a38
[   13.044395]  810d511b 8818 88000f33c690 
0001
[   13.044398]  03f0 88000f4677c8  
88000de03a98
[   13.044400] Call Trace:
[   13.044412][] dump_stack+0x19/0x1b
[   13.01]  [] warn_slowpath_common+0x6b/0x90
[   13.05]  [] warn_slowpath_fmt+0x46/0x50
[   13.08]  [] mutex_trylock+0x87/0x220
[   13.044482]  [] cirrus_dirty_update+0x1cd/0x330
[   13.044486]  [] cirrus_imageblit+0x38/0x50
[   13.044506]  [] soft_cursor+0x22e/0x240
[   13.044510]  [] bit_cursor+0x581/0x5b0
[   13.044525]  [] ? vsnprintf+0x124/0x670
[   13.044529]  [] ? get_color.isra.16+0x43/0x130
[   13.044532]  [] fbcon_cursor+0x18a/0x1d0
[   13.044535]  [] ? update_attr.isra.2+0xa0/0xa0
[   13.044556]  [] hide_cursor+0x32/0xa0
[   13.044565]  [] vt_console_print+0x103/0x3b0
[   13.044569]  [] ? print_time+0x9c/0xb0
[   13.044576]  [] ? print_prefix+0xa0/0xc0
[   13.044580]  [] 
call_console_drivers.constprop.6+0x146/0x1f0
[   13.044593]  [] ? do_raw_spin_unlock+0xc8/0x100
[   13.044597]  [] console_unlock+0x2f7/0x460
[   13.044600]  [] vprintk_emit+0x59a/0x5e0
[   13.044615]  [] printk+0x4d/0x4f
[   13.044650]  [] print_local_APIC+0x28/0x41c
[   13.044672]  [] 
generic_smp_call_function_single_interrupt+0x145/0x2b0
[   13.044688]  [] 
smp_call_function_single_interrupt+0x27/0x40
[   13.044697]  [] call_function_single_interrupt+0x72/0x80
[   13.044707][] ? native_safe_halt+0x6/0x10
[   13.044717]  [] ? trace_hardirqs_on+0xd/0x10
[   13.044738]  [] default_idle+0x59/0x120
[   13.044742]  [] arch_cpu_idle+0x18/0x40
[   13.044754]  [] cpu_startup_entry+0x235/0x410
[   13.044763]  [] rest_init+0xd1/0xe0
[   13.044766]  [] ? rest_init+0x5/0xe0
[   13.044778]  [] start_kernel+0x425/0x493
[   13.044781]  [] ? repair_env_string+0x5e/0x5e
[   13.044786]  [] x86_64_start_reservations+0x2a/0x2c
[   13.044789]  [] x86_64_start_kernel+0xf1/0x100
[   13.044799] ---[ end trace 113ad28772af4058 ]---

Reported-by: Fengguang Wu 
Signed-off-by: Maarten Lankhorst 

---
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 3541b56..b27e956 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -25,7 +25,7 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
struct cirrus_bo *bo;
int src_offset, dst_offset;
int bpp = (afbdev->gfb.base.bits_per_pixel + 7)/8;
-   int ret;
+   int ret = -EBUSY;
bool unmap = false;
bool store_for_later = false;
int x2, y2;
@@ -39,7 +39,8 @@ static void cirrus_dirty_update(struct cirrus_fbdev *afbdev,
 * then the BO is being moved and we should
 * store up the damage until later.
 */
-   ret = cirrus_bo_reserve(bo, true);
+   if (!in_interrupt())
+   ret = cirrus_bo_reserve(bo, true);
if (ret) {
if (ret != -EBUSY)
return;

[inconsistent HARDIRQ usage] &dev->mode_config.idr_mutex at drm_mode_object_find()

[Daniel Vetter]

On Mon, Jun 10, 2013 at 9:04 AM, Maarten Lankhorst
 wrote:
> ^ Stacktrace points at the warning being called from panic. At that point I 
> no longer trust anything to be sane.
> I don't know much about the panic handling in drm, but it's definitely not 
> related to your original issue.

The locking in the current drm panic handler is pretty much terminally
broken. At best we're trying not too flood dmesg too badly when it
happens.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

[Daniel Vetter]

On Sun, Jun 09, 2013 at 07:01:39PM -0400, Matthew Garrett wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the ACPI
> backlight interface on these systems.
> 
> Signed-off-by: Matthew Garrett 

Make sense and I guess it's easier to merge this all through the acpi
tree. So

Acked-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   /* Must be done after probing outputs */
>   intel_opregion_init(dev);
>   acpi_video_register();
> + /* Don't use ACPI backlight functions on Windows 8 platforms */
> + if (acpi_osi_version() >= ACPI_OSI_WIN_8)
> + acpi_video_backlight_unregister();
>   }
>  
>   if (IS_GEN5(dev))
> -- 
> 1.8.2.1
> 

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

[PATCH v2] drm: Print pretty names for pixel formats

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.

Keep printing the raw hex number too in case it contains non-printable
characters.

Some examples what the new drm_get_format_name() produces:
DRM_FORMAT_XRGB: "XR24 little-endian (0x34325258)"
DRM_FORMAT_YUYV: "YUYV little-endian (0x56595559)"
DRM_FORMAT_RGB565|DRM_FORMAT_BIG_ENDIAN: "RG16 big-endian (0xb6314752)"
Unprintable characters: "D??? big-endian (0xff7f0244)"

v2: Fix patch author

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 29 +++--
 include/drm/drm_crtc.h |  1 +
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..079996a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -29,6 +29,7 @@
  *  Dave Airlie 
  *  Jesse Barnes 
  */
+#include 
 #include 
 #include 
 #include 
@@ -252,6 +253,28 @@ char *drm_get_connector_status_name(enum 
drm_connector_status status)
 }
 EXPORT_SYMBOL(drm_get_connector_status_name);

+static char printable_char(int c)
+{
+   return isascii(c) && isprint(c) ? c : '?';
+}
+
+char *drm_get_format_name(uint32_t format)
+{
+   static char buf[32];
+
+   snprintf(buf, sizeof(buf),
+"%c%c%c%c %s-endian (0x%08x)",
+printable_char(format & 0xff),
+printable_char((format >> 8) & 0xff),
+printable_char((format >> 16) & 0xff),
+printable_char((format >> 24) & 0x7f),
+format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
+format);
+
+   return buf;
+}
+EXPORT_SYMBOL(drm_get_format_name);
+
 /**
  * drm_mode_object_get - allocate a new modeset identifier
  * @dev: DRM device
@@ -1834,7 +1857,8 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
if (fb->pixel_format == plane->format_types[i])
break;
if (i == plane->format_count) {
-   DRM_DEBUG_KMS("Invalid pixel format 0x%08x\n", 
fb->pixel_format);
+   DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(fb->pixel_format));
ret = -EINVAL;
goto out;
}
@@ -2312,7 +2336,8 @@ static int framebuffer_check(const struct 
drm_mode_fb_cmd2 *r)

ret = format_check(r);
if (ret) {
-   DRM_DEBUG_KMS("bad framebuffer format 0x%08x\n", 
r->pixel_format);
+   DRM_DEBUG_KMS("bad framebuffer format %s\n",
+ drm_get_format_name(r->pixel_format));
return ret;
}

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..2cbbfd4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1094,5 +1094,6 @@ extern int drm_format_num_planes(uint32_t format);
 extern int drm_format_plane_cpp(uint32_t format, int plane);
 extern int drm_format_horz_chroma_subsampling(uint32_t format);
 extern int drm_format_vert_chroma_subsampling(uint32_t format);
+extern char *drm_get_format_name(uint32_t format);

 #endif /* __DRM_CRTC_H__ */
-- 
1.8.1.5

[PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation

[Rahul Sharma]

This patch is already posted at
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg18331.html
and

Reviewed-by: Doug Anderson 

On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma  
wrote:
> From: Arun Kumar K 
>
> This patch corrects the HDMI clock number given wrongly
> in the documentation.
>
> Signed-off-by: Arun Kumar K 
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 781a627..1a05761 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -154,7 +154,7 @@ clock which they consume.
>dsim0341
>dp   342
>mixer343
> -  hdmi 345
> +  hdmi 344
>
>  Example 1: An example of a clock controller node is listed below.
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] drm/exynos: hdmi: use drm_display_mode to check the supported modes

[Rahul Sharma]

This patch renames check_timing to check_mode and removes the
unnecessary conversion of drm_display_mode to/from fb_videomode in
the hdmi driver.

v4:
1) Changed the commit message to add information related to renaming
the callbacks to check_mode.
2) Changed debug message to print 1/0 for interlace mode.

v3:
1) Replaced check_timing callbacks with check_mode.
2) Change the type of second parameter of check_mode callback from void
pointer paramenter to struct drm_display_mode pointer.

v2:
1) Removed convert_to_video_timing().
2) Corrected DRM_DEBUG_KMS to print the resolution properly.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   38 ++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |4 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |4 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   17 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |6 ++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |4 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   29 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |   15 +-
 8 files changed, 41 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ab3c6d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -58,37 +58,6 @@ convert_to_display_mode(struct drm_display_mode *mode,
mode->flags |= DRM_MODE_FLAG_DBLSCAN;
 }

-/* convert drm_display_mode to exynos_video_timings */
-static inline void
-convert_to_video_timing(struct fb_videomode *timing,
-   struct drm_display_mode *mode)
-{
-   DRM_DEBUG_KMS("%s\n", __FILE__);
-
-   memset(timing, 0, sizeof(*timing));
-
-   timing->pixclock = mode->clock * 1000;
-   timing->refresh = drm_mode_vrefresh(mode);
-
-   timing->xres = mode->hdisplay;
-   timing->right_margin = mode->hsync_start - mode->hdisplay;
-   timing->hsync_len = mode->hsync_end - mode->hsync_start;
-   timing->left_margin = mode->htotal - mode->hsync_end;
-
-   timing->yres = mode->vdisplay;
-   timing->lower_margin = mode->vsync_start - mode->vdisplay;
-   timing->vsync_len = mode->vsync_end - mode->vsync_start;
-   timing->upper_margin = mode->vtotal - mode->vsync_end;
-
-   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   timing->vmode = FB_VMODE_INTERLACED;
-   else
-   timing->vmode = FB_VMODE_NONINTERLACED;
-
-   if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
-   timing->vmode |= FB_VMODE_DOUBLE;
-}
-
 static int exynos_drm_connector_get_modes(struct drm_connector *connector)
 {
struct exynos_drm_connector *exynos_connector =
@@ -168,15 +137,12 @@ static int exynos_drm_connector_mode_valid(struct 
drm_connector *connector,
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
-   struct fb_videomode timing;
int ret = MODE_BAD;

DRM_DEBUG_KMS("%s\n", __FILE__);

-   convert_to_video_timing(&timing, mode);
-
-   if (display_ops && display_ops->check_timing)
-   if (!display_ops->check_timing(manager->dev, (void *)&timing))
+   if (display_ops && display_ops->check_mode)
+   if (!display_ops->check_mode(manager->dev, mode))
ret = MODE_OK;

return ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 680a7c1..eaa1966 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -142,7 +142,7 @@ struct exynos_drm_overlay {
  * @is_connected: check for that display is connected or not.
  * @get_edid: get edid modes from display driver.
  * @get_panel: get panel object from display driver.
- * @check_timing: check if timing is valid or not.
+ * @check_mode: check if mode is valid or not.
  * @power_on: display device on or off.
  */
 struct exynos_drm_display_ops {
@@ -151,7 +151,7 @@ struct exynos_drm_display_ops {
struct edid *(*get_edid)(struct device *dev,
struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
-   int (*check_timing)(struct device *dev, void *timing);
+   int (*check_mode)(struct device *dev, struct drm_display_mode *mode);
int (*power_on)(struct device *dev, int mode);
 };

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 279c3f8..d33e17d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -153,7 +153,7 @@ static void *fimd_get_panel(struct device *dev)
return ctx->panel;
 }

-static int fimd_check_timing(s

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

[joeyli]

? ??2013-06-09 ? 19:01 -0400?Matthew Garrett ???
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the ACPI
> backlight interface on these systems.
> 
> Signed-off-by: Matthew Garrett 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   /* Must be done after probing outputs */
>   intel_opregion_init(dev);
>   acpi_video_register();
> + /* Don't use ACPI backlight functions on Windows 8 platforms */
> + if (acpi_osi_version() >= ACPI_OSI_WIN_8)
> + acpi_video_backlight_unregister();
>   }
>  
>   if (IS_GEN5(dev))

This patch set works to me on Acer Aspire V3 notebook for unregister the
backlight interface of acpi video driver when i915 loaded. Acer Aspire
V3 has the Windows8 support in DSDT.

Tested-by: Lee, Chun-Yi 


Thanks a lot!
Joey Lee

[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem

[Rahul Sharma]

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

Arun Kumar K (1):
  clk/exynos5250: Fix HDMI clock number in documentation

Rahul Sharma (4):
  clk/exynos5250: add mout_hdmi mux clock for hdmi
  clk/exynos5250: add sclk_hdmiphy in the list of special clocks
  clk/exynos5250: add clock for tv sysmmu
  clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

 .../devicetree/bindings/clock/exynos5250-clock.txt   |   12 +++-
 drivers/clk/samsung/clk-exynos5250.c |   18 +-
 2 files changed, 24 insertions(+), 6 deletions(-)

-- 
1.7.10.4

[PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation

[Rahul Sharma]

From: Arun Kumar K 

This patch corrects the HDMI clock number given wrongly
in the documentation.

Signed-off-by: Arun Kumar K 
Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..1a05761 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,7 @@ clock which they consume.
   dsim0341
   dp   342
   mixer343
-  hdmi 345
+  hdmi 344

 Example 1: An example of a clock controller node is listed below.

-- 
1.7.10.4

[PATCH 2/5] clk/exynos5250: add mout_hdmi mux clock for hdmi

[Rahul Sharma]

hdmi driver needs to change the parent of hdmi clock
frequently between pixel clock and hdmiphy clock. hdmiphy is
not stable after power on and for a short interval while changing
the phy configuration. For this duration pixel clock is used to
clock hdmi.

This patch is exposing the mux for changing parent.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |8 
 drivers/clk/samsung/clk-exynos5250.c |5 -
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 1a05761..b337147 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -156,6 +156,14 @@ clock which they consume.
   mixer343
   hdmi 344

+
+   [Clock Muxes]
+
+  ClockID
+  
+  mout_hdmi1024
+
+
 Example 1: An example of a clock controller node is listed below.

clock: clock-controller at 0x1001 {
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 5c97e75..587d913 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -100,6 +100,9 @@ enum exynos5250_clks {
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,

+   /* mux clocks */
+   mout_hdmi = 1024,
+
nr_clks,
 };

@@ -231,7 +234,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = 
{
MUX(none, "mout_fimd1", mout_group1_p, SRC_DISP1_0, 0, 4),
MUX(none, "mout_mipi1", mout_group1_p, SRC_DISP1_0, 12, 4),
MUX(none, "mout_dp", mout_group1_p, SRC_DISP1_0, 16, 4),
-   MUX(none, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
+   MUX(mout_hdmi, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
MUX(none, "mout_audio0", mout_audio0_p, SRC_MAU, 0, 4),
MUX(none, "mout_mmc0", mout_group1_p, SRC_FSYS, 0, 4),
MUX(none, "mout_mmc1", mout_group1_p, SRC_FSYS, 4, 4),
-- 
1.7.10.4

[PATCH 3/5] clk/exynos5250: add sclk_hdmiphy in the list of special clocks

[Rahul Sharma]

hdmi driver needs hdmiphy clock which is one of the parent
for hdmi mux clock. This is required while changing the parent
of mux clock.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
 drivers/clk/samsung/clk-exynos5250.c |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index b337147..f333d61 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -59,6 +59,7 @@ clock which they consume.
   sclk_spi0154
   sclk_spi1155
   sclk_spi2156
+  sclk_hdmiphy 157


[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 587d913..88cdb13 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -87,6 +87,7 @@ enum exynos5250_clks {
sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
+   sclk_hdmiphy,

/* gate clocks */
gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
@@ -199,7 +200,7 @@ struct samsung_fixed_rate_clock 
exynos5250_fixed_rate_ext_clks[] __initdata = {

 /* fixed rate clocks generated inside the soc */
 struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
-   FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
+   FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 2700),
FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 4800),
-- 
1.7.10.4

[PATCH 4/5] clk/exynos5250: add clock for tv sysmmu

[Rahul Sharma]

Adding sysmmu clock for tv for exynos5250 SoC. It also
adds aclk200_disp1 mux which is the actual parent of the
disp1 block (contains hdmi, mixer, sysmmu_tv).

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
 drivers/clk/samsung/clk-exynos5250.c |6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index f333d61..f1c7e7f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -156,6 +156,7 @@ clock which they consume.
   dp   342
   mixer343
   hdmi 344
+  smmu_tv  345


[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 88cdb13..bb93d61 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -24,6 +24,7 @@
 #define SRC_CORE1  0x4204
 #define SRC_TOP0   0x10210
 #define SRC_TOP2   0x10218
+#define SRC_TOP3   0x1021C
 #define SRC_GSCL   0x10220
 #define SRC_DISP1_00x1022c
 #define SRC_MAU0x10240
@@ -99,7 +100,7 @@ enum exynos5250_clks {
spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
-   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, smmu_tv,

/* mux clocks */
mout_hdmi = 1024,
@@ -172,6 +173,7 @@ PNAME(mout_mpll_user_p) = { "fin_pll", "sclk_mpll" };
 PNAME(mout_bpll_user_p)= { "fin_pll", "sclk_bpll" };
 PNAME(mout_aclk166_p)  = { "sclk_cpll", "sclk_mpll_user" };
 PNAME(mout_aclk200_p)  = { "sclk_mpll_user", "sclk_bpll_user" };
+PNAME(mout_aclk200_disp1_sub_p) = { "fin_pll", "aclk200" };
 PNAME(mout_hdmi_p) = { "div_hdmi_pixel", "sclk_hdmiphy" };
 PNAME(mout_usb3_p) = { "sclk_mpll_user", "sclk_cpll" };
 PNAME(mout_group1_p)   = { "fin_pll", "fin_pll", "sclk_hdmi27m",
@@ -227,6 +229,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata = 
{
MUX(none, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(none, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(none, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+   MUX(none, "aclk200_disp1", mout_aclk200_disp1_sub_p, SRC_TOP3, 4, 1),
MUX(none, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
MUX(none, "mout_cam0", mout_group1_p, SRC_GSCL, 16, 4),
MUX(none, "mout_cam1", mout_group1_p, SRC_GSCL, 20, 4),
@@ -328,6 +331,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata 
= {
GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
+   GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
-- 
1.7.10.4

[PATCH 5/5] clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

[Rahul Sharma]

parent of hdmi and mixer block is mentioned as aclk200 which is
not correct. It is clocked by the ouput of aclk200_disp1. Hence
parent for mixer and hdmi clocks is changed to aclk200_disp1.

Signed-off-by: Rahul Sharma 
---
 drivers/clk/samsung/clk-exynos5250.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index bb93d61..2075f5f 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -468,8 +468,8 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata 
= {
GATE(mie1, "mie1", "aclk200", GATE_IP_DISP1, 1, 0, 0),
GATE(dsim0, "dsim0", "aclk200", GATE_IP_DISP1, 3, 0, 0),
GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
-   GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
-   GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
+   GATE(mixer, "mixer", "aclk200_disp1", GATE_IP_DISP1, 5, 0, 0),
+   GATE(hdmi, "hdmi", "aclk200_disp1", GATE_IP_DISP1, 6, 0, 0),
 };

 static __initdata struct of_device_id ext_clk_match[] = {
-- 
1.7.10.4

[PATCH 0/3] Fix backlight issues on some Windows 8 systems

[Rafael J. Wysocki]

Hi Matthew,

On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest
> thing to do would be to just disable ACPI backlight control entirely if the
> firmware indicates Windows 8 support, but it's entirely possible that
> individual graphics drivers might still make use of the ACPI functionality in
> preference to native control.
> 
> The first two patches in this series are picked from other patchesets aimed at
> solving similar problems. The last simply unregisters ACPI backlight control
> on Windows 8 systems when using an Intel GPU. Similar code could be added to
> other drivers, but I'm reluctant to do so without further investigation as
> to the behaviour of the vendor drivers under Windows.

I happen to know that alternative solution to this problem is being worked on,
so I'm going to wait until it is submitted and then we'll decide what to merge.

I'm slightly concerned about unregistering ACPI backlight control for all
systems declaring win8 support, even though it may actually work for them.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/6/6 Joonyoung Shim 

> On 06/06/2013 03:14 AM, Tomasz Figa wrote:
>
>> On Sunday 19 of May 2013 13:26:57 Tomasz Figa wrote:
>>
>>> Hi,
>>>
>>> On Wednesday 01 of May 2013 21:02:25 Tomasz Figa wrote:
>>>
>>>> Much of the code in Exynos DRM subsystem is generic enough to use
>>>> it for older (non-Exynos) Samsung SoCs as well, after minor
>>>> modifications.
>>>>
>>>> This series starts adding support for previous SoCs to Exynos DRM by
>>>> introducing S3C64xx support to exynos_drm_fimd driver.
>>>>
>>>> Adding support for remaining SoCs between S3C64xx and Exynos4
>>>> (S5PC100,
>>>> S5P64x0 and S5PV210) should be rather straightforward, but at the
>>>> moment I can test only on S3C6410, so I limited my changes only to
>>>> this SoC.
>>>>
>>>> On Tiny6410 (Mini6410-compatible) board based on Samsung S3C6410 SoC,
>>>> using my to-be-resubmitted patches for Device Tree support:
>>>>
>>>> Tested-by: Tomasz Figa 
>>>>
>>>> Tomasz Figa (4):
>>>>drm/exynos: fimd: Hold pointer to driver data in context struct
>>>>drm/exynos: fimd: Add support for FIMD versions without SHADOWCON
>>>> register
>>>>   drm/exynos: fimd: Add support for FIMD variants with clock
>>>> selection
>>>>drm/exynos: fimd: Add support for S3C64xx SoCs
>>>> drivers/gpu/drm/exynos/exynos_**drm_fimd.c | 90
>>>>
>>>> --**-- 1 file changed, 68 insertions(+), 22
>>>> deletions(-)
>>>>
>>> Any comments for this series?
>>>
>>> Best regards,
>>> Tomasz
>>>
>> Ping.
>>
>> Best regards,
>> Tomasz
>>
>>
>>
> This series looks good to me.
>
> Acked-by: Joonyoung Shim 
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  
> http://vger.kernel.org/**majordomo-info.html<http://vger.kernel.org/majordomo-info.html>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/f19102c8/attachment.html>

[PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Sebastian Hesselbarth]

On 06/09/13 21:29, Russell King wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs.  This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>acceleration
> - dual lcd0 and lcd1 crt operation
> - video overlay on each LCD crt
> - page flipping of the main scanout buffers
>
> Included in this commit is the core driver with no output support; output
> support is platform and encoder driver dependent.
>
> Signed-off-by: Russell King 
> ---
[...]
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> new file mode 100644
> index 000..e5ab4cb
> --- /dev/null
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -0,0 +1,766 @@
> +/*
> + * Copyright (C) 2012 Russell King
> + *  Rewritten from the dovefb driver, and Armada510 manuals.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
[...]
> +static void armada_drm_crtc_update(struct armada_crtc *dcrtc)
> +{
> + uint32_t dumb_ctrl;
> +
> + dumb_ctrl = dcrtc->cfg_dumb_ctrl;
> +
> + if (!dpms_blanked(dcrtc->dpms))
> + dumb_ctrl |= CFG_DUMB_ENA;
> +
> + /*
> +  * When a dumb interface isn't under 24bit, it might be
> +  * under SPI or GPIO.  If set to 7, this will force
> +  * LCD_D[23:0] to output blank color and damage GPIO
> +  * and SPI behaviour.  So leave it as-is unless in
> +  * DUMB24_RGB888_0 mode.
> +  */
> + if (dpms_blanked(dcrtc->dpms) &&
> + (dumb_ctrl & DUMB_MASK) == DUMB24_RGB888_0) {
> + dumb_ctrl &= ~DUMB_MASK;
> + dumb_ctrl |= DUMB_BLANK;
> + }
> +
> + /*
> +  * The spec is unclear about the polarities of the syncs.
> +  * We assume their non-inverted state is active high.
> +  */

nit: "We confirmed their non-inverted state is active high."

> + if (dcrtc->crtc.mode.flags & DRM_MODE_FLAG_NCSYNC)
> + dumb_ctrl |= CFG_INV_CSYNC;
> + if (dcrtc->crtc.mode.flags & DRM_MODE_FLAG_NHSYNC)
> + dumb_ctrl |= CFG_INV_HSYNC;
> + if (dcrtc->crtc.mode.flags & DRM_MODE_FLAG_NVSYNC)
> + dumb_ctrl |= CFG_INV_VSYNC;
> +
> + if (dcrtc->dumb_ctrl != dumb_ctrl) {
> + dcrtc->dumb_ctrl = dumb_ctrl;
> + writel_relaxed(dumb_ctrl, dcrtc->base + LCD_SPU_DUMB_CTRL);
> + }
> +}
[...]
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> new file mode 100644
> index 000..bb70cf5
> --- /dev/null
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -0,0 +1,326 @@
> +/*
> + * Copyright (C) 2012 Russell King
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "armada_crtc.h"
> +#include "armada_drm.h"
> +#include "armada_gem.h"
> +#include "armada_hw.h"
> +#include "armada_ioctl.h"
> +#include "armada_ioctlP.h"
> +
> +static int armada_drm_load(struct drm_device *dev, unsigned long flags)
> +{
> + struct armada_private *priv;
> + struct resource *res[ARRAY_SIZE(priv->dcrtc)];
> + struct resource *mem = NULL;
> + int ret, n, i;
> +
> + memset(res, 0, sizeof(res));
> +
> + for (n = i = 0; ; n++) {
> + struct resource *r = platform_get_resource(dev->platformdev,
> +IORESOURCE_MEM, n);
> + if (!r)
> + break;
> +
> + if (resource_size(r) > SZ_4K)
> + mem = r;

nit again: The register address window of Dove LCD is 64k although you 
are right an no more than 512B are used. Also a comment would be nice,
that everything above 4k (64k) is interpreted as gfx mem.

> + else if (i < ARRAY_SIZE(priv->dcrtc))
> + res[i++] = r;
> + else
> + return -EINVAL;
> + }
> +
> + if (!res[0] || !mem)
> + return -ENXIO;
> +
> + if (!devm_request_mem_region(dev->dev, mem->start,
> + resource_size(mem), "armada-drm"))
> + return -EBUSY;
> +
> + priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + DRM_ERROR("failed to allocate private\n");
> + ret = -ENOMEM;
> + goto err_buf;
> + }
> +
> + dev->dev_private = priv;
> +
> + /* Mode setting support */
> + drm_mode_config_init(dev);
> + dev->mode_config.min_width = 0;
> + dev->mode_config.min_height = 0;
> + dev->mode_config.max_width = 2048;
> + dev->mode_config.max_height = 2048;
> + dev->mode_config.pre

[PATCH 0/2] drm/exynos: clean up logs for next tree

[Inki Dae]

Applied.

Thanks,
Inki Dae


2013/6/5 Seung-Woo Kim 

> This patch set removes tracking logs and function name duplications.
> This is for the next tree and based on exynos-drm-next branch.
>
> YoungJun Cho (2):
>   drm/exynos: Remove tracking log functions
>   drm/exynos: Clean up logs for DRM_ERROR / DRM_DEBUG_KMS
>
>  drivers/gpu/drm/exynos/exynos_drm_buf.c   |7 -
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |   17 --
>  drivers/gpu/drm/exynos/exynos_drm_core.c  |   12 --
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   29 
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c|6 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |   20 ---
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   28 +
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|   10 --
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |8 -
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c  |  129 +++--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   46 +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |   23 ---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c   |  102 +
>  drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   42 -
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c   |  201
> 
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |   16 --
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c   |   53 +++-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   40 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |   42 +-
>  drivers/gpu/drm/exynos/exynos_mixer.c |   32 +
>  20 files changed, 193 insertions(+), 670 deletions(-)
>
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part ------
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/592c1047/attachment-0001.html>

[RPC 0/21] DRM: Add VIA DRM driver

[Konrad Rzeszutek Wilk]

On Sat, Jun 08, 2013 at 05:42:20PM +0100, James Simmons wrote:
> 
> Hello
> 
>   Here is the first run at inspection of the VIA openchrome dri 
> driver. Now that the Xorg driver has been out over a year with KMS support
> most people should be able to use this feature. The driver is totaly 
> complete but we wanted to merge it so people with newer hardware that has 
> HDMI/DVI-D support can be able to run X windows. Your xorg driver does not 
> implement HDMI/DVI in UMS mode and we don't have the resources to do this 
> work. Basic TTM/GEM is supported but currently you can't run any 
> acceleration with the command queue. Over the next 6 months this should be 
> implemented. Thank you.

Hey James,

I am not entirely sure what happend but it looks like you are using
Alpine mailer to send out the patches. The sad end result is that
all of the patches have the "DRM: Add VIA DRM driver" title instead
of the more appropiate title within the email.

Could you repost them with 'git send-email' please?

This link http://kernelnewbies.org/OPWfirstpatch
at the "Submit a patch" section has an excellent tutorial on how
to use different mailers. The "Setup your tools" has a nice
tutorial on .gitconfig setup. If you would like to use
me as test subject and send emails to me before the mailing list
please do.

I usually have this in my .gitconfig file:

[konrad at build-external ~]$ more .gitconfig
[user]
name = Konrad Rzeszutek Wilk
email = konrad.wilk at oracle.com
signingkey = F1DB09BF
[color]
branch = true
diff = true
[sendemail]
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpencryption = tls
smtpuser = ketuzsezr at gmail.com

and for sending emails to myself I do:

konrad at phenom:~/linux$ git format-patch --subject-prefix="v4" HEAD^^..
0001-xen-ring-Add-a-new-macro-to-detect-whether-there-is-.patch
0002-xen-blkback-Check-for-insane-amounts-of-request-on-t.patch

then:
konrad at phenom:~/linux: git send-email --suppress-cc=all --to konrad at 
kernel.org --compose --annotate --subject "[PATCH v4] Safety harness for the 
block driver." *.patch

edit in vim the changes, look over all of the patches, and then send.

Lastly, is there a git tree with these patches so that one may
just in one swoop test them out?

Thanks!
>  
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org

[Bug 65377] Backlight control via /sys/class/backlight/radeon_bl0 not working

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Alex Deucher  ---
Created attachment 80624
  --> https://bugs.freedesktop.org/attachment.cgi?id=80624&action=edit
don't register a radeon backlight

This patch should skip adding a radeon backlight interface on your mac.

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

[PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

[Alex Deucher]

Radeon probably needs something similar.  See attached untested patch.

Alex

On Sun, Jun 9, 2013 at 7:01 PM, Matthew Garrett
 wrote:
> Windows 8 leaves backlight control up to individual graphics drivers rather
> than making ACPI calls itself. There's plenty of evidence to suggest that
> the Intel driver for Windows doesn't use the ACPI interface, including the
> fact that it's broken on a bunch of machines when the OS claims to support
> Windows 8. The simplest thing to do appears to be to disable the ACPI
> backlight interface on these systems.
>
> Signed-off-by: Matthew Garrett 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1661,6 +1661,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
> /* Must be done after probing outputs */
> intel_opregion_init(dev);
> acpi_video_register();
> +   /* Don't use ACPI backlight functions on Windows 8 platforms 
> */
> +   if (acpi_osi_version() >= ACPI_OSI_WIN_8)
> +   acpi_video_backlight_unregister();
> }
>
> if (IS_GEN5(dev))
> --
> 1.8.2.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-don-t-provide-ACPI-backlight-if-firmware-.patch
Type: text/x-patch
Size: 1094 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130610/63595324/attachment.bin>

[Bug 65611] New: UVD accelerated decoding causes hangs (ARUBA - HD 7540D)

[bugzilla-dae...@freedesktop.org]

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

  Priority: medium
Bug ID: 65611
  Assignee: dri-devel at lists.freedesktop.org
   Summary: UVD accelerated decoding causes hangs (ARUBA - HD
7540D)
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: otaznik at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 80626
  --> https://bugs.freedesktop.org/attachment.cgi?id=80626&action=edit
relevant dmesg output

New UVD VDPAU decoding of VC-1 and MPEG-2 causes some kind of corruption and
ultimately hang of driver and whole system on the next try (cursor can be
moving for some time, even SysRq can work a few seconds after X totally hangs
but then only power off works).

Few notes (using mplayer):
ffmpeg12vdpau:
MPEG1 causes no harm, only decoding is really bad (software decoding works)
MPEG2 seems to cause really bad corruption

ffvc1vdpau:
VC-1 seems to cause problems (like attached dmesg) but not hangs.  There have
been decoding artifacts too, but it is not the rule.

divx and h264 seems to work flawless, unless previous corruption happened.

Hardware is ARUBA - A6-5400K Black Edition APU (Radeon HD 7540D).  Since this
particular hardware seems to be problematic (#65254 #60389) it might be unique
to this APU.

Test files:
VC1 http://samples.mplayerhq.hu/V-codecs/WVC1/Test_1440x576_WVC1_6Mbps.wmv
MPEG2 http://samples.mplayerhq.hu/MPEG2/vid_0x80.ts
MPEG1 http://samples.mplayerhq.hu/MPEG1/

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

[RPC 0/21] DRM: Add VIA DRM driver

[Daniel Vetter]

On Mon, Jun 10, 2013 at 09:31:38AM -0400, Konrad Rzeszutek Wilk wrote:
> On Sat, Jun 08, 2013 at 05:42:20PM +0100, James Simmons wrote:
> > 
> > Hello
> > 
> > Here is the first run at inspection of the VIA openchrome dri 
> > driver. Now that the Xorg driver has been out over a year with KMS support
> > most people should be able to use this feature. The driver is totaly 
> > complete but we wanted to merge it so people with newer hardware that has 
> > HDMI/DVI-D support can be able to run X windows. Your xorg driver does not 
> > implement HDMI/DVI in UMS mode and we don't have the resources to do this 
> > work. Basic TTM/GEM is supported but currently you can't run any 
> > acceleration with the command queue. Over the next 6 months this should be 
> > implemented. Thank you.
> 
> Hey James,
> 
> I am not entirely sure what happend but it looks like you are using
> Alpine mailer to send out the patches. The sad end result is that
> all of the patches have the "DRM: Add VIA DRM driver" title instead
> of the more appropiate title within the email.

At least in my mutt here the threading also seems to be broken ...
-Daniel

> 
> Could you repost them with 'git send-email' please?
> 
> This link http://kernelnewbies.org/OPWfirstpatch
> at the "Submit a patch" section has an excellent tutorial on how
> to use different mailers. The "Setup your tools" has a nice
> tutorial on .gitconfig setup. If you would like to use
> me as test subject and send emails to me before the mailing list
> please do.
> 
> I usually have this in my .gitconfig file:
> 
> [konrad at build-external ~]$ more .gitconfig
> [user]
> name = Konrad Rzeszutek Wilk
> email = konrad.wilk at oracle.com
> signingkey = F1DB09BF
> [color]
> branch = true
> diff = true
> [sendemail]
> smtpserver = smtp.gmail.com
> smtpserverport = 587
> smtpencryption = tls
> smtpuser = ketuzsezr at gmail.com
> 
> and for sending emails to myself I do:
> 
> konrad at phenom:~/linux$ git format-patch --subject-prefix="v4" HEAD^^..
> 0001-xen-ring-Add-a-new-macro-to-detect-whether-there-is-.patch
> 0002-xen-blkback-Check-for-insane-amounts-of-request-on-t.patch
> 
> then:
> konrad at phenom:~/linux: git send-email --suppress-cc=all --to konrad at 
> kernel.org --compose --annotate --subject "[PATCH v4] Safety harness for the 
> block driver." *.patch
> 
> edit in vim the changes, look over all of the patches, and then send.
> 
> Lastly, is there a git tree with these patches so that one may
> just in one swoop test them out?
> 
> Thanks!
> >  
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] drm/radeon: fix AVI infoframe generation

[Alex Deucher]

On Sat, Jun 8, 2013 at 7:46 AM, Rafa? Mi?ecki  wrote:
> 2013/6/7  :
>> From: Alex Deucher 
>>
>> - remove adding 2 to checksum, this breaks certain monitors
>> - properly emit the AVI infoframe version, not emitting
>> the version breaks some monitors.
>>
>> This should fix blank screen when HDMI audio is enabled on
>> certain monitors.
>
> Err, nack. I believe this it actually going to *break* some monitors
> compatibility.
>
> For some unknown reason AMD hardware uses 0x81 and 0x01 for type and
> version of infoframe. See this comment (written/published by you):
> /* The following packets and infoframes are required for HDMI:
>  * Packets:
>  * 0x00 - Null packet
>  * 0x01 - Audio clock regen
>  * 0x02 - Audio sample
>  * 0x03 - General Control
>  * Infoframes:
>  * 0x81 0x01 - AVI
>  * 0x83 0x03 - audio
>  */
>
> As you can see, AMD hardware uses 0x81 and 0x01. I've no idea why,
> according to the HDMI standard it should be 0x82 and 0x02. All other
> vendors seems to also use 0x82 and 0x02. In function
> hdmi_avi_infoframe_init type it set to 0x82 and 0x02.
>
> This type and version it's written anywhere, but they are used to
> calculate checksum. Checksum it what we store is frame[0x0]. We
> calculate checksum as 0x100 - sum (see hdmi_infoframe_checksum).
>
> Now... with common drm code we use 0x82 and 0x02 instead of 0x81 and
> 0x01. It means our "sum" is too big by 0x02. It means we have to use
> 0x100 - sum + 0x02 as checksum for AMD hardware.
>
> This whole hack was introduced in 92db7f6c860b8190571a9dc1fcbc16d003422fe8:
> drm/radeon/kms: workaround invalid AVI infoframe checksum issue
> and I'm pretty sure it was verified to fix somebody's HDMI mode. It
> also seems to be compatible with AMD specs (at least the part of it we
> can see in the quoted comment).
>
> For proof of fglrx doing the same, please see my e-mail where I
> provided dumps from registers when using fglrx:
> http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html
> (it was tested on 5 different cards!).

Actually, I think the patch is correct.  I think you were adding the
version twice:  From your examples:
[Rafa? Mi?ecki][RV620] fglrx:
0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0
0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2
0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x1F8 = 0x289
-0x289 = 0x77

The payload sum is not 0x1f8, it's 0x1f6.
00 + A8 + 5E + 00 +
00 + 28 + 00 + 10 +
00 + 48 + 00 + 28 +
00 + 48 =
0x1f6

Bits 25:24 of HDMI_VIDEOINFOFRAME_3 are the packet version, not part
of the payload.  So the total would be:
(0x82 + 0x2 + 0xD) + 0x1f6 = 0x287
-0x287 = 0x79

I think the issue is that we are not setting the version in bits 25:24
of HDMI_VIDEOINFOFRAME_3 so we were sending a version 0 AVI packet.

Alex

>
> When working on that patch I was talking & debugging with few people
> on IRC. That mean I don't have logs anymore, but I'm sure I was
> testing exactly that single value and it was immediately fixing
> selected displays. I mean testing by writing something like:
>
> avivotool regset 0x10884 0x00a85e4f
> vs.
> avivotool regset 0x10884 0x00a85e4d
>
> --
> Rafa?

[PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[Rob Clark]

On Sun, Jun 9, 2013 at 3:29 PM, Russell King
 wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs.  This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>   acceleration
> - dual lcd0 and lcd1 crt operation
> - video overlay on each LCD crt

Any particular reason for not exposing the overlays as drm_plane's?
That is probably something that should change before merging the
driver.

Other than that, it looks reasonably good, with just a few (mostly
minor) comments below.

> - page flipping of the main scanout buffers
>
> Included in this commit is the core driver with no output support; output
> support is platform and encoder driver dependent.
>
> Signed-off-by: Russell King 
> ---

[snip]

> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> new file mode 100644
> index 000..e5ab4cb
> --- /dev/null
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -0,0 +1,766 @@
> +/*
> + * Copyright (C) 2012 Russell King
> + *  Rewritten from the dovefb driver, and Armada510 manuals.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include "armada_crtc.h"
> +#include "armada_drm.h"
> +#include "armada_fb.h"
> +#include "armada_gem.h"
> +#include "armada_hw.h"
> +
> +struct armada_frame_work {
> +   struct drm_pending_vblank_event *event;
> +   struct armada_regs regs[4];
> +   struct drm_gem_object *old_fb_obj;
> +   struct work_struct work;
> +};
> +
> +/*
> + * A note about interlacing.  Let's consider HDMI 1920x1080i.
> + * The timing parameters we have from X are:
> + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
> + *  1920 2448 2492 2640  1080 1084 1094 1125
> + * Which get translated to:
> + *  Hact HsyA HsyI Htot  Vact VsyA VsyI Vtot
> + *  1920 2448 2492 2640   540  542  547  562
> + *
> + * This is how it is defined by CEA-861-D - line and pixel numbers are
> + * referenced to the rising edge of VSYNC and HSYNC.  Total clocks per
> + * line: 2640.  The odd frame, the first active line is at line 21, and
> + * the even frame, the first active line is 584.
> + *
> + * LN:560 561 562 563 567 568569
> + * DE:~~~|//__
> + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
> + * VSYNC: _|~~//~~~|__
> + *  22 blanking lines.  VSYNC at 1320 (referenced to the HSYNC rising edge).
> + *
> + * LN:1123   11241125  1   5   6  7
> + * DE:~~~|//__
> + * HSYNC: |~|_|~|_|~|_|~|_//__|~|_|~|_|~|_
> + * VSYNC: |~~~//~~|___
> + *  23 blanking lines
> + *
> + * The Armada LCD Controller line and pixel numbers are, like X timings,
> + * referenced to the top left of the active frame.
> + *
> + * So, translating these to our LCD controller:
> + *  Odd frame, 563 total lines, VSYNC at line 543-548, pixel 1128.
> + *  Even frame, 562 total lines, VSYNC at line 542-547, pixel 2448.
> + * Note: Vsync front porch remains constant!
> + *
> + * if (odd_frame) {
> + *   vtotal = mode->crtc_vtotal + 1;
> + *   vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay + 1;
> + *   vhorizpos = mode->crtc_hsync_start - mode->crtc_htotal / 2
> + * } else {
> + *   vtotal = mode->crtc_vtotal;
> + *   vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay;
> + *   vhorizpos = mode->crtc_hsync_start;
> + * }
> + * vfrontporch = mode->crtc_vtotal - mode->crtc_vsync_end;
> + *
> + * So, we need to reprogram these registers on each vsync event:
> + *  LCD_SPU_V_PORCH, LCD_SPU_ADV_REG, LCD_SPUT_V_H_TOTAL

ouch, proof that some hw designers must really hate driver writers ;-)

[snip]

> +/* The mode_config.mutex will be held for this call */
> +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> +   struct drm_framebuffer *old_fb)
> +{
> +   struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
> +   struct armada_regs regs[4];
> +   unsigned i;
> +
> +   i = armada_drm_crtc_calc_fb(crtc->fb, crtc->x, crtc->y, regs, 
> dcrtc->interlaced);
> +   armada_reg_queue_end(regs, i);
> +
> +   /* Wait for pending flips to complete */
> +   wait_event(dcrtc->frame_wait, !dcrtc->frame_work);
> +
> +   /* Take a reference to the new fb as we're using it */
> +   drm_gem_object_reference(&drm_fb_obj(crtc->fb)->obj);

note that you probably want to ref/unref the fb (and let the fb hold a
ref to the gem bo).. that will make life easier for planar formats too
(as the fb should hold

[Bug 65438] GTK apps crash X11 since last update of LLVMM

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Tom Stellard  ---
Created attachment 80630
  --> https://bugs.freedesktop.org/attachment.cgi?id=80630&action=edit
Possible Fix / Work Around

Can you try this patch?  It should fix the segfault, but it looks to me like
the real bug might be in the CFG Structurizer.  There are a number of PHI nodes
that take undef as an argument, and I'm not sure if that is correct.

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