[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font

[H. Peter Anvin]

We should clear this bit presumably on switching either from or to 512-char 
mode, since the bit doesn't really make sense either way.

Dave Airlie  wrote:

>From: Dave Airlie 
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpreted. The bit that
>holds
>the high bit of the 9-bit font, may have been previously set, and thus
>the new font misrenders.
>
>The problem case we see is grub2 writes spaces with the bit set, so it
>ends up with data like 0x820, which gets reinterpreted into 0x120 char
>which the font translates into G with a circumflex. This flashes up on
>screen at boot and is quite ugly.
>
>A current side effect of this patch though is that any rendering on the
>screen changes color to a slightly darker color, but at least the
>screen
>no longer corrupts.
>
>Signed-off-by: Dave Airlie 
>---
> drivers/tty/vt/vt.c|  2 +-
> drivers/video/console/vgacon.c | 19 ---
> include/linux/vt_kern.h|  1 +
> 3 files changed, 14 insertions(+), 8 deletions(-)
>
>diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>index 8fd8968..c8067ae 100644
>--- a/drivers/tty/vt/vt.c
>+++ b/drivers/tty/vt/vt.c
>@@ -638,7 +638,7 @@ static inline void save_screen(struct vc_data *vc)
>  *Redrawing of screen
>  */
> 
>-static void clear_buffer_attributes(struct vc_data *vc)
>+void clear_buffer_attributes(struct vc_data *vc)
> {
>   unsigned short *p = (unsigned short *)vc->vc_origin;
>   int count = vc->vc_screenbuf_size / 2;
>diff --git a/drivers/video/console/vgacon.c
>b/drivers/video/console/vgacon.c
>index d449a74..271b5d0 100644
>--- a/drivers/video/console/vgacon.c
>+++ b/drivers/video/console/vgacon.c
>@@ -1064,7 +1064,7 @@ static int vgacon_do_font_op(struct vgastate
>*state,char *arg,int set,int ch512)
>   unsigned short video_port_status = vga_video_port_reg + 6;
>   int font_select = 0x00, beg, i;
>   char *charmap;
>-  
>+  bool clear_attribs = false;
>   if (vga_video_type != VIDEO_TYPE_EGAM) {
>   charmap = (char *) VGA_MAP_MEM(colourmap, 0);
>   beg = 0x0e;
>@@ -1169,12 +1169,6 @@ static int vgacon_do_font_op(struct vgastate
>*state,char *arg,int set,int ch512)
> 
>   /* if 512 char mode is already enabled don't re-enable it. */
>   if ((set) && (ch512 != vga_512_chars)) {
>-  /* attribute controller */
>-  for (i = 0; i < MAX_NR_CONSOLES; i++) {
>-  struct vc_data *c = vc_cons[i].d;
>-  if (c && c->vc_sw == _con)
>-  c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
>-  }
>   vga_512_chars = ch512;
>   /* 256-char: enable intensity bit
>  512-char: disable intensity bit */
>@@ -1185,8 +1179,19 @@ static int vgacon_do_font_op(struct vgastate
>*state,char *arg,int set,int ch512)
>  it means, but it works, and it appears necessary */
>   inb_p(video_port_status);
>   vga_wattr(state->vgabase, VGA_AR_ENABLE_DISPLAY, 0);
>+  clear_attribs = true;
>   }
>   raw_spin_unlock_irq(_lock);
>+
>+  if (clear_attribs) {
>+  for (i = 0; i < MAX_NR_CONSOLES; i++) {
>+  struct vc_data *c = vc_cons[i].d;
>+  if (c && c->vc_sw == _con) {
>+  clear_buffer_attributes(c);
>+  c->vc_hi_font_mask = ch512 ? 0x0800 : 0;
>+  }
>+  }
>+  }
>   return 0;
> }
> 
>diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
>index 50ae7d0..1f55665 100644
>--- a/include/linux/vt_kern.h
>+++ b/include/linux/vt_kern.h
>@@ -47,6 +47,7 @@ int con_set_cmap(unsigned char __user *cmap);
> int con_get_cmap(unsigned char __user *cmap);
> void scrollback(struct vc_data *vc, int lines);
> void scrollfront(struct vc_data *vc, int lines);
>+void clear_buffer_attributes(struct vc_data *vc);
>void update_region(struct vc_data *vc, unsigned long start, int count);
> void redraw_screen(struct vc_data *vc, int is_switch);
> #define update_screen(x) redraw_screen(x, 0)

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

[PATCH] drm/exynos: add check for the device power status

[Shirish S]

V2: Add mutex protection, while read.

The hdmi and mixer win_commit calls currently are
not checking the status of IP before updating the
respective registers, this patch adds this check.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 7 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..05335ae 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2170,6 +2170,13 @@ static void hdmi_commit(void *ctx)

DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);

+   mutex_lock(>hdmi_mutex);
+   if (!hdata->powered) {
+   mutex_unlock(>hdmi_mutex);
+   return;
+   }
+   mutex_unlock(>hdmi_mutex);
+
hdmi_conf_apply(hdata);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21db895..9fba6bd 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -775,6 +775,13 @@ static void mixer_win_commit(void *ctx, int win)

DRM_DEBUG_KMS("[%d] %s, win: %d\n", __LINE__, __func__, win);

+   mutex_lock(_ctx->mixer_mutex);
+   if (!mixer_ctx->powered) {
+   mutex_unlock(_ctx->mixer_mutex);
+   return;
+   }
+   mutex_unlock(_ctx->mixer_mutex);
+
if (win > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, win);
else
-- 
1.8.0

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

--- Comment #24 from Seth Forshee  ---
Created attachment 73542
  --> https://bugs.freedesktop.org/attachment.cgi?id=73542=edit
Add quirk to efifb for iMac 12,1

Here's a patch to try. But after some more poking around I'm wondering why this
is needed. The kernel seems to get the information about the GOP framebuffer
for most recent Macs without quirking, so it makes me wonder why it doesn't
work on this machine.

Just to check one obvious point, are you either running with the stock Ubuntu
kernels or else with CONFIG_FB_EFI=y? An easy way to verify this is to boot the
machine and run 'grep CONFIG_FB_EFI /boot/config-$(uname -r)'. This should
output 'CONFIG_FB_EFI=y' if your kernel is configured to include the EFI
framebuffer support.

-- 
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/20130123/29ee980d/attachment.html>

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #12 from Andy Furniss  ---
(In reply to comment #10)
> Can you test with this new patch ? (Remove the previous one)
> It adds dummy export to vs outputs

It works OK with the new patch.

-- 
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/20130123/f05adcca/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

--- Comment #23 from William  ---
Here the information from the output:

 <"Apple Inc.">
 <"iMac12,1">
FrameBuff erBase: 0x9001
PixelsPerScanLine: 1920
HorizontalResolution: 1920
VerticalResolution: 1080

-- 
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/20130123/a8029fe0/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

--- Comment #22 from Seth Forshee  ---
(In reply to comment #21)
> Hi Seth,
> 
> the output is:
> bios vendor: Apple Inc.
> system product name: iMac12,1

Rats, it turns out there's more information required. If you can boot into OS X
and run the following command in a terminal, it's supposed to give all the
required information.

sudo ioreg -lw0 |grep manufacturer|cut -b25-80;sudo ioreg -lw0|grep
"product-name"|cut -b 25-80;sudo dtrace -qn 'BEGIN{boot_args=((struct
boot_args*)(`PE_state).bootArgs);printf("FrameBuff erBase:
0x%08x\nPixelsPerScanLine: %d\nHorizontalResolution: %d\nVerticalResolution:
%d", boot_args->Video.v_baseAddr, boot_args->Video.v_rowBytes/4,
boot_args->Video.v_width, boot_args->Video.v_height);exit(0)} '

> Could that also explain why X is not working?

I don't know much at all about X, but I suspect it might be at least
contributing. Maybe X is also trying to use the Intel graphics based on the
same information.

-- 
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/20130123/a3c1e53d/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

--- Comment #21 from William  ---
Hi Seth,

the output is:
bios vendor: Apple Inc.
system product name: iMac12,1

Could that also explain why X is not working?

-- 
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/20130123/0b0451b9/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

--- Comment #20 from Seth Forshee  ---
Okay, thanks.

I suspect at least part of the problem may be related to efifb. I don't see
that it's being used on your machine, and I note that it has a bunch of quirks
for making it work with various Mac hardware. If we add a quirk for your
machine efifb should then be able to identify the radeon as the default vga
device and use it for the console framebuffer. I'm guessing this won't fix the
problem with the 32-bit builds, but it should at least remove the need for
i915.disable=1 with the 64-bit build.

To make a patch I'll need some DMI information for your machine. Could you send
me the output from the following commands?

 dmidecode -s bios-vendor
 dmidecode -s system-product-name

-- 
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/20130123/40424a1a/attachment-0001.html>

[Linaro-mm-sig] [PATCH 4/7] fence: dma-buf cross-device synchronization (v11)

[Francesco Lavra]

On 01/23/2013 03:56 PM, Maarten Lankhorst wrote:
> Thanks for the review, how does this delta look?
> 
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> index d9f091d..831ed0a 100644
> --- a/include/linux/fence.h
> +++ b/include/linux/fence.h
> @@ -42,7 +42,10 @@ struct fence_cb;
>   * @ops: fence_ops associated with this fence
>   * @cb_list: list of all callbacks to call
>   * @lock: spin_lock_irqsave used for locking
> - * @priv: fence specific private data
> + * @context: execution context this fence belongs to, returned by
> + *   fence_context_alloc()
> + * @seqno: the sequence number of this fence inside the executation context,

s/executation/execution

Otherwise, looks good to me.

--
Francesco

[PATCH 1/2] fb: Rework locking to fix lock ordering on takeover

[Daniel Vetter]

On Wed, Jan 23, 2013 at 5:38 PM, Takashi Iwai  wrote:
> At Wed, 23 Jan 2013 17:25:08 +0100,
> Daniel Vetter wrote:
>>
>> From: Alan Cox 
>>
>> Adjust the console layer to allow a take over call where the caller already
>> holds the locks. Make the fb layer lock in order.
>>
>> This s partly a band aid, the fb layer is terminally confused about the
>> locking rules it uses for its notifiers it seems.
>>
>> Signed-off-by: Alan Cox 
>> [danvet: Tiny whitespace cleanup.]
>> Reported-and-tested-by: Hugh Dickins 
>> Reported-and-tested-by: Sasha Levin 
>> References: https://lkml.org/lkml/2012/10/25/516
>> Signed-off-by: Daniel Vetter 
>
> FYI, the latest patch of this is found in mm tree:
>   
> http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>
> Also I hit the same problem in another code paths (for unbind and
> unregister):
>   http://marc.info/?t=13530939643=1=2
>
> My additional patch is found in mm tree, too:
>   
> http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch

Indeed, there's more stuff :( And I've missed the export_symbol fix
for the first patch. Still, is there any chance we can at least merge
the first one (I don't think that many people unload framebuffers)
into 3.8 with cc: stable? I'd like to get at least rid of the known
deadlocks at kms takeover time, since we have quite a few unexplained
such bug reports floating around ... Andrew, Dave?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] fb: Rework locking to fix lock ordering on takeover

[Takashi Iwai]

At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
> 
> From: Alan Cox 
> 
> Adjust the console layer to allow a take over call where the caller already
> holds the locks. Make the fb layer lock in order.
> 
> This s partly a band aid, the fb layer is terminally confused about the
> locking rules it uses for its notifiers it seems.
> 
> Signed-off-by: Alan Cox 
> [danvet: Tiny whitespace cleanup.]
> Reported-and-tested-by: Hugh Dickins 
> Reported-and-tested-by: Sasha Levin 
> References: https://lkml.org/lkml/2012/10/25/516
> Signed-off-by: Daniel Vetter 

FYI, the latest patch of this is found in mm tree:
  
http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch

Also I hit the same problem in another code paths (for unbind and
unregister):
  http://marc.info/?t=13530939643=1=2

My additional patch is found in mm tree, too:
  
http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch


Takashi

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

--- Comment #19 from William  ---
Hi Seth,

i have been testing with raring using 3.8 kernel.

On 64 bit kernel i get a console screen using the i915.disable=1 but not on the
32bit kernel. see also the dmesg files attached.

When using the 3.5 kernel from quantal i get an oops with a 32bit kernel but
not when i use the option i915.i915_enable_ppgtt=0 but then i still have a
blank screen.

-- 
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/20130123/c332b96d/attachment.html>

[PATCH 2/2] drm/i915: fixup per-crtc locking in intel_release_load_detect_pipe

[Daniel Vetter]

One of the early return cases missed the mutex unlocking. Hilarity
ensued.

This regression has been introduced in

commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
Author: Daniel Vetter 
Date:   Wed Dec 12 00:35:33 2012 +0100

drm: don't hold crtc mutexes for connector ->detect callbacks

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59750
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 26df9e3..ece4afd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6522,6 +6522,7 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
drm_framebuffer_unreference(old->release_fb);
}

+   mutex_unlock(>mutex);
return;
}

-- 
1.7.10.4

[PATCH 1/2] fb: Rework locking to fix lock ordering on takeover

[Daniel Vetter]

From: Alan Cox 

Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.

This s partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

Signed-off-by: Alan Cox 
[danvet: Tiny whitespace cleanup.]
Reported-and-tested-by: Hugh Dickins 
Reported-and-tested-by: Sasha Levin 
References: https://lkml.org/lkml/2012/10/25/516
Signed-off-by: Daniel Vetter 
---
 drivers/tty/vt/vt.c   |   81 +++--
 drivers/video/console/fbcon.c |   30 ++-
 drivers/video/fbmem.c |5 +--
 drivers/video/fbsysfs.c   |3 ++
 include/linux/console.h   |1 +
 5 files changed, 97 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8fd8968..a38d9d1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2987,7 +2987,7 @@ int __init vty_init(const struct file_operations 
*console_fops)

 static struct class *vtconsole_class;

-static int bind_con_driver(const struct consw *csw, int first, int last,
+static int do_bind_con_driver(const struct consw *csw, int first, int last,
   int deflt)
 {
struct module *owner = csw->owner;
@@ -2998,7 +2998,7 @@ static int bind_con_driver(const struct consw *csw, int 
first, int last,
if (!try_module_get(owner))
return -ENODEV;

-   console_lock();
+   WARN_CONSOLE_UNLOCKED();

/* check if driver is registered */
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
@@ -3083,11 +3083,22 @@ static int bind_con_driver(const struct consw *csw, int 
first, int last,

retval = 0;
 err:
-   console_unlock();
module_put(owner);
return retval;
 };

+
+static int bind_con_driver(const struct consw *csw, int first, int last,
+  int deflt)
+{
+   int ret;
+
+   console_lock();
+   ret = do_bind_con_driver(csw, first, last, deflt);
+   console_unlock();
+   return ret;
+}
+
 #ifdef CONFIG_VT_HW_CONSOLE_BINDING
 static int con_is_graphics(const struct consw *csw, int first, int last)
 {
@@ -3199,9 +3210,9 @@ int unbind_con_driver(const struct consw *csw, int first, 
int last, int deflt)
if (!con_is_bound(csw))
con_driver->flag &= ~CON_DRIVER_FLAG_INIT;

-   console_unlock();
/* ignore return value, binding should not fail */
-   bind_con_driver(defcsw, first, last, deflt);
+   do_bind_con_driver(defcsw, first, last, deflt);
+   console_unlock();
 err:
module_put(owner);
return retval;
@@ -3492,28 +3503,18 @@ int con_debug_leave(void)
 }
 EXPORT_SYMBOL_GPL(con_debug_leave);

-/**
- * register_con_driver - register console driver to console layer
- * @csw: console driver
- * @first: the first console to take over, minimum value is 0
- * @last: the last console to take over, maximum value is MAX_NR_CONSOLES -1
- *
- * DESCRIPTION: This function registers a console driver which can later
- * bind to a range of consoles specified by @first and @last. It will
- * also initialize the console driver by calling con_startup().
- */
-int register_con_driver(const struct consw *csw, int first, int last)
+static int do_register_con_driver(const struct consw *csw, int first, int last)
 {
struct module *owner = csw->owner;
struct con_driver *con_driver;
const char *desc;
int i, retval = 0;

+   WARN_CONSOLE_UNLOCKED();
+
if (!try_module_get(owner))
return -ENODEV;

-   console_lock();
-
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
con_driver = _con_driver[i];

@@ -3566,10 +3567,29 @@ int register_con_driver(const struct consw *csw, int 
first, int last)
}

 err:
-   console_unlock();
module_put(owner);
return retval;
 }
+
+/**
+ * register_con_driver - register console driver to console layer
+ * @csw: console driver
+ * @first: the first console to take over, minimum value is 0
+ * @last: the last console to take over, maximum value is MAX_NR_CONSOLES -1
+ *
+ * DESCRIPTION: This function registers a console driver which can later
+ * bind to a range of consoles specified by @first and @last. It will
+ * also initialize the console driver by calling con_startup().
+ */
+int register_con_driver(const struct consw *csw, int first, int last)
+{
+   int retval;
+
+   console_lock();
+   retval = do_register_con_driver(csw, first, last);
+   console_unlock();
+   return retval;
+}
 EXPORT_SYMBOL(register_con_driver);

 /**
@@ -3625,6 +3645,29 @@ EXPORT_SYMBOL(unregister_con_driver);
  *
  *  take_over_console is basically a register followed by unbind
  */
+int do_take_over_console(const struct consw *csw, int first, int last, int 
deflt)
+{
+   int err;
+
+   err = do_register_con_driver(csw, first, last);
+   

[PATCH 0/2] fbcon+i915 locking fixes

[Daniel Vetter]

Hi Dave,

First patch is a resend of Alan's fbcon vs. fb notifier deadlock fix.
Without this lockdep is pretty much useless for debugging drm locking
issues, and it looks like quite a few bootup hangs could be blamed on this
one, too.

Since the fbdev maintainer seems to be awol, please merge this through
your drm tree. I've looked through the patch and the new locking seems to
be sane so feel free to smash a

Reviewed-by: Daniel Vetter 

onto it.

2nd patch is a locking bug in the i915 driver with the new kms locking.
Since the bug only happens in your drm-next tree, please apply the patch
there directly.

Thanks, Daniel

Alan Cox (1):
  fb: Rework locking to fix lock ordering on takeover

Daniel Vetter (1):
  drm/i915: fixup crtc locking in intel_release_load_detect_pipe

 drivers/gpu/drm/i915/intel_display.c |1 +
 drivers/tty/vt/vt.c  |   81 ++
 drivers/video/console/fbcon.c|   30 -
 drivers/video/fbmem.c|5 +--
 drivers/video/fbsysfs.c  |3 ++
 include/linux/console.h  |1 +
 6 files changed, 98 insertions(+), 23 deletions(-)

-- 
1.7.10.4

[PATCH 4/5] drm/tegra: Implement VBLANK support

[Mark Zhang]

On 01/23/2013 02:21 AM, Jon Mayo wrote:
> On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding
>  wrote:
>> Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
>> special in this case because it doesn't use the generic IRQ support
>> provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one
>> interrupt handler for each display controller.
>>
>> While at it, clean up the way that interrupts are enabled to ensure
>> that the VBLANK interrupt only gets enabled when required.
>>
>> Signed-off-by: Thierry Reding 
>> ---
> 
> Sorry Thierry, but is this a useful feature? Are applications really
> making use of it? Because it means that that an IRQ will have to
> trigger every 16.67ms when it is taken, which means the device can't
> sleep. (probably OK because it should go back to idle when the app
> lets go of the vblank). But worse, for one-shot panels there is no
> continuous vblank. I've been doing weird hacks to run a timer when the
> smart panel is idle to trick applications into thinking they have a
> vblank pulse. But really I think the whole feature of a vblank pulse
> is pretty lame and I wish it would die. Were you going to use it for
> something specific, or just adding it for completeness?
> 

I guess people don't use this to really wait vblanks because that can be
done by polling drm fd. Normally they use this ioctl to get the vblank
counts which may be useful for their applications.

Mark
> - Jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 43751] [TTM] Out of kernel memory

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

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


am.devel at gmail.com changed:

   What|Removed |Added

 CC||am.devel at gmail.com




--- Comment #7 from am.devel at gmail.com  2013-01-23 17:02:02 ---
Has this been resolved? I'm using 3.4.20 and I see this issue every time.

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

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #11 from vincent  ---
Created attachment 73532
  --> https://bugs.freedesktop.org/attachment.cgi?id=73532=edit
Add dummy vs export

-- 
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/20130123/b16afee9/attachment.html>

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #10 from vincent  ---
Can you test with this new patch ? (Remove the previous one)
It adds dummy export to vs outputs

-- 
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/20130123/a4c3cc6a/attachment.html>

[Linaro-mm-sig] [PATCH 4/7] fence: dma-buf cross-device synchronization (v11)

[Maarten Lankhorst]

Op 22-01-13 16:13, Francesco Lavra schreef:
> Hi,
>
> On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
> [...]
>> diff --git a/include/linux/fence.h b/include/linux/fence.h
>> new file mode 100644
>> index 000..d9f091d
>> --- /dev/null
>> +++ b/include/linux/fence.h
>> @@ -0,0 +1,347 @@
>> +/*
>> + * Fence mechanism for dma-buf to allow for asynchronous dma access
>> + *
>> + * Copyright (C) 2012 Canonical Ltd
>> + * Copyright (C) 2012 Texas Instruments
>> + *
>> + * Authors:
>> + * Rob Clark 
>> + * Maarten Lankhorst 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program.  If not, see .
>> + */
>> +
>> +#ifndef __LINUX_FENCE_H
>> +#define __LINUX_FENCE_H
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct fence;
>> +struct fence_ops;
>> +struct fence_cb;
>> +
>> +/**
>> + * struct fence - software synchronization primitive
>> + * @refcount: refcount for this fence
>> + * @ops: fence_ops associated with this fence
>> + * @cb_list: list of all callbacks to call
>> + * @lock: spin_lock_irqsave used for locking
>> + * @priv: fence specific private data
>> + * @flags: A mask of FENCE_FLAG_* defined below
>> + *
>> + * the flags member must be manipulated and read using the appropriate
>> + * atomic ops (bit_*), so taking the spinlock will not be needed most
>> + * of the time.
>> + *
>> + * FENCE_FLAG_SIGNALED_BIT - fence is already signaled
>> + * FENCE_FLAG_ENABLE_SIGNAL_BIT - enable_signaling might have been called*
>> + * FENCE_FLAG_USER_BITS - start of the unused bits, can be used by the
>> + * implementer of the fence for its own purposes. Can be used in different
>> + * ways by different fence implementers, so do not rely on this.
>> + *
>> + * *) Since atomic bitops are used, this is not guaranteed to be the case.
>> + * Particularly, if the bit was set, but fence_signal was called right
>> + * before this bit was set, it would have been able to set the
>> + * FENCE_FLAG_SIGNALED_BIT, before enable_signaling was called.
>> + * Adding a check for FENCE_FLAG_SIGNALED_BIT after setting
>> + * FENCE_FLAG_ENABLE_SIGNAL_BIT closes this race, and makes sure that
>> + * after fence_signal was called, any enable_signaling call will have either
>> + * been completed, or never called at all.
>> + */
>> +struct fence {
>> +struct kref refcount;
>> +const struct fence_ops *ops;
>> +struct list_head cb_list;
>> +spinlock_t *lock;
>> +unsigned context, seqno;
>> +unsigned long flags;
>> +};
> The documentation above should be updated with the new structure members
> context and seqno.
>
>> +
>> +enum fence_flag_bits {
>> +FENCE_FLAG_SIGNALED_BIT,
>> +FENCE_FLAG_ENABLE_SIGNAL_BIT,
>> +FENCE_FLAG_USER_BITS, /* must always be last member */
>> +};
>> +
>> +typedef void (*fence_func_t)(struct fence *fence, struct fence_cb *cb, void 
>> *priv);
>> +
>> +/**
>> + * struct fence_cb - callback for fence_add_callback
>> + * @func: fence_func_t to call
>> + * @priv: value of priv to pass to function
>> + *
>> + * This struct will be initialized by fence_add_callback, additional
>> + * data can be passed along by embedding fence_cb in another struct.
>> + */
>> +struct fence_cb {
>> +struct list_head node;
>> +fence_func_t func;
>> +void *priv;
>> +};
> Documentation should be updated here too.
>
>> +
>> +/**
>> + * struct fence_ops - operations implemented for fence
>> + * @enable_signaling: enable software signaling of fence
>> + * @signaled: [optional] peek whether the fence is signaled
>> + * @release: [optional] called on destruction of fence
>> + *
>> + * Notes on enable_signaling:
>> + * For fence implementations that have the capability for hw->hw
>> + * signaling, they can implement this op to enable the necessary
>> + * irqs, or insert commands into cmdstream, etc.  This is called
>> + * in the first wait() or add_callback() path to let the fence
>> + * implementation know that there is another driver waiting on
>> + * the signal (ie. hw->sw case).
>> + *
>> + * This function can be called called from atomic context, but not
>> + * from irq context, so normal spinlocks can be used.
>> + *
>> + * A return value of false indicates the fence already passed,
>> + * or some failure occured that made it impossible to enable
>> + * signaling. True indicates succesful enabling.
>> + *
>> + * Calling fence_signal before enable_signaling is called 

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

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

Seth Forshee  changed:

   What|Removed |Added

 CC||seth.forshee at canonical.com

--- Comment #18 from Seth Forshee  ---
(In reply to comment #15)
> Ok, this is the apple gmux. The display is connected to the discrete radeon
> GPU and you need to manually switch it over to the igfx (using the mux).
> That it is blank upon booting is because not only is the video muxed, so are
> the control lines which are still being reversed engineered as to how to
> setup the gmux.

I got pointed at this bug since the gmux came up.

Chris: I don't really understand this comment. I can't see that anything is
trying to switch gpus. There are likely problems getting i915 to correctly
detect which outputs are attached since the display is muxed to the radeon at
boot and macs have a bad habit of not supplying VBTs, but i915 still shouldn't
oops (but it sounds like this is fixed?), and radeon should still be able to
drive the panel.

William: I don't think I have a clear handle on the current state of this
problem. Am I correct in understanding that you no longer get the stack trace
on the screen when you boot an i386 kernel, but get a blank screen instead?
Does the behavior change at all in 3.8 based on whether or not you pass
i915.disable=1?

-- 
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/20130123/e9a8d622/attachment.html>

[PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

[Herton Ronaldo Krzesinski]

On Wed, Jan 23, 2013 at 12:21:29PM -0500, Ilija Hadzic wrote:
> On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
>  wrote:
> > On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
> >> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> >> > Actually, the code path affected by your patch is not executed in UMS 
> >> > mode
> >> > at all. Notice that radeon_cs_parser_fini is only called from
> >> > radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
> >> >
> >> > The equivalent of the fix you are trying to do is in
> >> > a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is
> >> > the one used by legacy-CS ioctl), which you should go together
> >> > with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS
> >> > fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode.
> >> >
> >> > -- Ilija
> >>
> >> Thanks. I will take a look at a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e.
> >> I sent back-ported ff4bd0827764e10a428a9d39e6814c5478863f94 patch to
> >> stable and I will back-port and send
> >> a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e as well.
> >
> > While at it, also looks like commit
> > 25d8999780f8c1f53928f4a24a09c01550423109 could also be added to stables.
> > But while looking at it, while the patch itself is correct, I noted that
> > there is a possibility of double free: if either of the
> > p->chunks[p->chunk_ib_idx].kpage[] items are non NULL, we will free it in
> > radeon_cs_parser_init and also when calling one of the fini functions
> > (radeon_cs_parser_fini or r600_cs_parser_fini). So either we need to set
> > kpage[n] to NULL after kfree, or just return the error.
> >
> 
> Yes you are right. The error-handling path should force both kpage[]
> pointers to NULL before returning -ENOMEM. That would fix the double
> free.
> 
> Regarding, inclusion of 25d8999780f8c1f53928f4a24a09c01550423109 into
> stable (and possible follow-up patch to fix potential double-kfree),
> does this pass the "no fixes for theoretical problems in stable"
> criterion ?
> 
> It is an obvious bug, but it happens so rarely that I am not surprised
> that it has never happened: You need an (old) AGP card *and* you need
> to run out of kmalloc memory.

About the "theoretical problem" criteria, I think it applies more to
race conditions not detected in practice, things that are not obvious/
deterministic etc., but indeed commit 25d89997 looks not be worth to be
added on stables.

> 
> -- Ilija
> 

-- 
[]'s
Herton

[PATCH] drm/radeon: fix a rare case of double kfree

[Alex Deucher]

On Wed, Jan 23, 2013 at 1:59 PM, Ilija Hadzic
 wrote:
> If one (but not both) allocations of p->chunks[].kpage[]
> in radeon_cs_parser_init fail, the error path will free
> the successfully allocated page, but leave a stale pointer
> value in the kpage[] field. This will later cause a
> double-free when radeon_cs_parser_fini is called.
> This patch fixes the issue by forcing both pointers to NULL
> after kfree in the error path.
>
> The circumstances under which the problem happens are very
> rare. The card must be AGP and the system must run out of
> kmalloc area just at the right time so that one allocation
> succeeds, while the other fails.
>
> Signed-off-by: Ilija Hadzic 
> Cc: Herton Ronaldo Krzesinski 

Thanks, Added to my -fixes queue.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_cs.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 469661f..5407459 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -286,6 +286,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
> void *data)
> p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {
> kfree(p->chunks[p->chunk_ib_idx].kpage[0]);
> kfree(p->chunks[p->chunk_ib_idx].kpage[1]);
> +   p->chunks[p->chunk_ib_idx].kpage[0] = NULL;
> +   p->chunks[p->chunk_ib_idx].kpage[1] = NULL;
> return -ENOMEM;
> }
> }
> --
> 1.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

[Herton Ronaldo Krzesinski]

On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
> > Actually, the code path affected by your patch is not executed in UMS mode 
> > at all. Notice that radeon_cs_parser_fini is only called from 
> > radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
> > 
> > The equivalent of the fix you are trying to do is in
> > a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is 
> > the one used by legacy-CS ioctl), which you should go together 
> > with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS 
> > fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode.
> > 
> > -- Ilija
> 
> Thanks. I will take a look at a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e.
> I sent back-ported ff4bd0827764e10a428a9d39e6814c5478863f94 patch to
> stable and I will back-port and send
> a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e as well.

While at it, also looks like commit
25d8999780f8c1f53928f4a24a09c01550423109 could also be added to stables.
But while looking at it, while the patch itself is correct, I noted that
there is a possibility of double free: if either of the
p->chunks[p->chunk_ib_idx].kpage[] items are non NULL, we will free it in
radeon_cs_parser_init and also when calling one of the fini functions
(radeon_cs_parser_fini or r600_cs_parser_fini). So either we need to set
kpage[n] to NULL after kfree, or just return the error.

> 
> -- Shuah

-- 
[]'s
Herton

[PATCH] drm/radeon: fix a rare case of double kfree

[Ilija Hadzic]

If one (but not both) allocations of p->chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issue by forcing both pointers to NULL
after kfree in the error path.

The circumstances under which the problem happens are very
rare. The card must be AGP and the system must run out of
kmalloc area just at the right time so that one allocation
succeeds, while the other fails.

Signed-off-by: Ilija Hadzic 
Cc: Herton Ronaldo Krzesinski 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 469661f..5407459 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -286,6 +286,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {
kfree(p->chunks[p->chunk_ib_idx].kpage[0]);
kfree(p->chunks[p->chunk_ib_idx].kpage[1]);
+   p->chunks[p->chunk_ib_idx].kpage[0] = NULL;
+   p->chunks[p->chunk_ib_idx].kpage[1] = NULL;
return -ENOMEM;
}
}
-- 
1.8.1

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #9 from Alex Deucher  ---
Regarding the conversation on IRC, the vertex shader has to export at least one
generic param (not counting special exports like position).  So if the vertex
shader doesn't export any params, you need a dummy one.

-- 
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/20130123/917f5472/attachment.html>

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Russell King - ARM Linux]

On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine  
> wrote:
> > Hi Rob,
> >
> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> > I had a look at your IT LCD driver. Comments below.
> 
> Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
> (just in case that wasn't clear).

Great, this chip is also used on the cubox too.

The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
that are provided to the TDA9988x chip.  On the cubox, I have to adjust
the mode parameters such that the polarities are fixed up thusly:

adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
 DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
 DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);

/* The TDA19988 always requires negative VSYNC? */
adjusted->flags |= DRM_MODE_FLAG_NVSYNC;

/* The TDA19988 requires positive HSYNC on 1080p or 720p */
if ((adjusted->hdisplay == 1920 && adjusted->vdisplay == 1080) ||
(adjusted->hdisplay == 1280 && adjusted->vdisplay == 720))
adjusted->flags |= DRM_MODE_FLAG_PHSYNC;
else
adjusted->flags |= DRM_MODE_FLAG_NHSYNC;

return true;

for these resolutions to be displayed correctly.

Also, when the only output is the HDMI device, reporting the display
"disconnected" and without any modes seems to cause problems - I have to
report "unknown" status when there's nothing connected, and also provide
a default (720p) mode when no EDID is received.

[patch] drm/nouveau/disp: sizeof() wrong pointer

[Bernd Petrovitsch]

On Mit, 2013-01-23 at 11:38 +0300, Dan Carpenter wrote:
> On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
> > 
> > Did you find this by manual inspection or did you use some tool?
> 
> I found this because it caused a problem in a parser I was working
> on but Sparse warns about "warning: expression using sizeof(void)".

gcc's -Wpointer-arith option also reports this.
Never tried it on the kernel though .

Bernd
-- 
Bernd Petrovitsch  Email : bernd at petrovitsch.priv.at
 LUGA : http://www.luga.at

[PATCH] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

[Ilija Hadzic]

On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
 wrote:
> On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
>> On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
>> > Actually, the code path affected by your patch is not executed in UMS mode
>> > at all. Notice that radeon_cs_parser_fini is only called from
>> > radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
>> >
>> > The equivalent of the fix you are trying to do is in
>> > a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is
>> > the one used by legacy-CS ioctl), which you should go together
>> > with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS
>> > fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode.
>> >
>> > -- Ilija
>>
>> Thanks. I will take a look at a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e.
>> I sent back-ported ff4bd0827764e10a428a9d39e6814c5478863f94 patch to
>> stable and I will back-port and send
>> a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e as well.
>
> While at it, also looks like commit
> 25d8999780f8c1f53928f4a24a09c01550423109 could also be added to stables.
> But while looking at it, while the patch itself is correct, I noted that
> there is a possibility of double free: if either of the
> p->chunks[p->chunk_ib_idx].kpage[] items are non NULL, we will free it in
> radeon_cs_parser_init and also when calling one of the fini functions
> (radeon_cs_parser_fini or r600_cs_parser_fini). So either we need to set
> kpage[n] to NULL after kfree, or just return the error.
>

Yes you are right. The error-handling path should force both kpage[]
pointers to NULL before returning -ENOMEM. That would fix the double
free.

Regarding, inclusion of 25d8999780f8c1f53928f4a24a09c01550423109 into
stable (and possible follow-up patch to fix potential double-kfree),
does this pass the "no fixes for theoretical problems in stable"
criterion ?

It is an obvious bug, but it happens so rarely that I am not surprised
that it has never happened: You need an (old) AGP card *and* you need
to run out of kmalloc memory.

-- Ilija

linux-3.7.4: Regression causing a kmemleak in drm_pci_set_busid()

[Martin Mokrejs]

Hi,
  I have kmemleak detector enabled since 3.7.1 but now, with 3.7.4 I get the 
following:

  comm "X", pid 5475, jiffies 4294992244 (age 133695.910s)
  hex dump (first 32 bytes):
69 39 31 35 40 70 63 69 3a 30 30 30 30 3a 30 30  i915 at pci::00
3a 30 32 2e 30 00 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  :02.0.k.
  backtrace:
[] kmemleak_alloc+0x21/0x3e
[] slab_post_alloc_hook+0x28/0x2a
[] __kmalloc+0xf2/0x104
[] drm_pci_set_busid+0xf6/0x12b [drm]
[] drm_setversion+0xaf/0x177 [drm]
[] drm_ioctl+0x309/0x3c9 [drm]
[] do_vfs_ioctl+0x462/0x4a3
[] sys_ioctl+0x47/0x69
[] system_call_fastpath+0x1a/0x1f
[] 0x

Hope this helps,
Martin
-- next part --
[0.00] Linux version 3.7.4-default (root at vostro) (gcc version 4.6.3 
(Gentoo 4.6.3 p1.8, pie-0.5.2) ) #2 SMP Mon Jan 21 22:45:22 MET 2013
[0.00] Command line: root=/dev/sda5 pciehp.pciehp_debug=1 
slub_debug=AFPZ pcie_aspm=off
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d3ff] usable
[0.00] BIOS-e820: [mem 0x0009d400-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xda4e4fff] usable
[0.00] BIOS-e820: [mem 0xda4e5000-0xda527fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xda528000-0xda792fff] usable
[0.00] BIOS-e820: [mem 0xda793000-0xda966fff] reserved
[0.00] BIOS-e820: [mem 0xda967000-0xdaa88fff] usable
[0.00] BIOS-e820: [mem 0xdaa89000-0xdad67fff] reserved
[0.00] BIOS-e820: [mem 0xdad68000-0xdafe7fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdafe8000-0xdaff] ACPI data
[0.00] BIOS-e820: [mem 0xdb80-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00041fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Dell Inc. Vostro 3550/, BIOS A11 08/03/2012
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] No AGP bridge found
[0.00] e820: last_pfn = 0x41fe00 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-E7FFF uncachable
[0.00]   E8000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask C write-back
[0.00]   1 base 4 mask FE000 write-back
[0.00]   2 base 0DB80 mask FFF80 uncachable
[0.00]   3 base 0DC00 mask FFC00 uncachable
[0.00]   4 base 0E000 mask FE000 uncachable
[0.00]   5 base 41FE0 mask FFFE0 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820: update [mem 0xdb80-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xdaa89 max_arch_pfn = 0x4
[0.00] initial memory mapped: [mem 0x-0x1fff]
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] reserving inaccessible SNB gfx pages
[0.00] init_memory_mapping: [mem 0x-0xdaa88fff]
[0.00]  [mem 0x-0xda9f] page 2M
[0.00]  [mem 0xdaa0-0xdaa88fff] page 4k
[0.00] kernel direct mapping tables up to 0xdaa88fff @ [mem 
0x1fffa000-0x1fff]
[0.00] init_memory_mapping: [mem 0x1-0x41fdf]
[0.00]  [mem 0x1-0x41fdf] page 2M
[0.00] kernel direct mapping tables up to 0x41fdf @ [mem 
0xdaa7b000-0xdaa88fff]
[0.00] ACPI: RSDP 000f0410 00024 (v02   DELL)

[patch] drm/nouveau/disp: sizeof() wrong pointer

[Dan Carpenter]

On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
> 
> Did you find this by manual inspection or did you use some tool?
> 

I found this because it caused a problem in a parser I was working
on but Sparse warns about "warning: expression using sizeof(void)".

It's sort of hard to run Sparse on nouveau because you can't build
the individual .o files.

$ kchecker --sparse drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `relocs'.
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
:1223:2: warning: #warning syscall finit_module not implemented [-Wcpp]
scripts/Makefile.build:44: 
/home/dcarpenter/progs/kernel/devel/drivers/gpu/drm/nouveau/core/engine/disp/Makefile:
 No such file or directory
make[1]: *** No rule to make target 
`/home/dcarpenter/progs/kernel/devel/drivers/gpu/drm/nouveau/core/engine/disp/Makefile'.
  Stop.
make: *** [drivers/gpu/drm/nouveau/core/engine/disp/nv50.o] Error 2

regards,
dan carpenter

[patch v2] drm/nouveau/disp: sizeof() wrong pointer

[Dan Carpenter]

"data" is a void pointer and "args" is "data" after we have casted it to
a struct.  We care about the size of the struct here.  Btw,
sizeof(*data) is 1.

Signed-off-by: Dan Carpenter 
---
v2: tweaked the commit message

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
index ca1a7d7..eb9c489 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
@@ -335,7 +335,7 @@ nv50_disp_sync_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;

-   if (size < sizeof(*data) || args->head > 1)
+   if (size < sizeof(*args) || args->head > 1)
return -EINVAL;

ret = nv50_disp_dmac_create_(parent, engine, oclass, args->pushbuf,
@@ -374,7 +374,7 @@ nv50_disp_ovly_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;

-   if (size < sizeof(*data) || args->head > 1)
+   if (size < sizeof(*args) || args->head > 1)
return -EINVAL;

ret = nv50_disp_dmac_create_(parent, engine, oclass, args->pushbuf,
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
index 9e38ebf..f28725a 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
@@ -230,7 +230,7 @@ nvd0_disp_sync_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;

-   if (size < sizeof(*data) || args->head >= priv->head.nr)
+   if (size < sizeof(*args) || args->head >= priv->head.nr)
return -EINVAL;

ret = nv50_disp_dmac_create_(parent, engine, oclass, args->pushbuf,
@@ -270,7 +270,7 @@ nvd0_disp_ovly_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;

-   if (size < sizeof(*data) || args->head >= priv->head.nr)
+   if (size < sizeof(*args) || args->head >= priv->head.nr)
return -EINVAL;

ret = nv50_disp_dmac_create_(parent, engine, oclass, args->pushbuf,

[PATCH V2 RESEND] drm_crtc: check if fb_create return NULL

[Su, Xuemin]

From: xueminsu 
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL

Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.

Signed-off-by: xueminsu 
---
 drivers/gpu/drm/drm_crtc.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f2d667b..b748498 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2172,6 +2172,13 @@ int drm_mode_addfb(struct drm_device *dev,
ret = PTR_ERR(fb);
goto out;
}
+   /* some buggy driver may return NULL here, which may cause panic */
+   if (!fb) {
+   WARN(1, "%pf should not return NULL.",
+   dev->mode_config.funcs->fb_create);
+   ret = -EINVAL;
+   goto out;
+   }

or->fb_id = fb->base.id;
list_add(>filp_head, _priv->fbs);
-- 
1.7.6

[Bug 58272] Rv670 AGP drm-next ttm errors

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

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

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Andy Furniss  ---
Current drm-fixes is working for me now.

The remaining etqw issue was fixed by -

Revert "drm/radeon: do not move bo to different placement at each cs"

-- 
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/20130123/c2c778d6/attachment.html>

[PATCH V2 RESEND] drm_crtc: check if fb_create return NULL

[Daniel Vetter]

On Wed, Jan 23, 2013 at 11:19:27AM +0800, Su, Xuemin wrote:
> From: xueminsu 
> Date: Tue, 22 Jan 2013 22:39:39 +0800
> Subject: [PATCH] drm_crtc: check if fb_create return NULL
> 
> Some buggy driver may still return NULL in fb_create,
> which leads to kernel panic.
> 
> Signed-off-by: xueminsu 

Imo just BUG_ON(!fb); and call it a day. Makes it pretty clear what's
expected of the drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/4] drm/i2c: nxp-tda998x (v2)

[Jean-Francois Moine]

On Tue, 22 Jan 2013 16:36:23 -0600
Rob Clark  wrote:

> Driver for the NXP TDA998X i2c hdmi encoder slave.
> 
> v1: original
> v2: fix npix/nline programming
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/i2c/Makefile  |   3 +
>  drivers/gpu/drm/i2c/tda998x_drv.c | 908 
> ++
>  2 files changed, 911 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
[snip]
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> new file mode 100644
> index 000..02054e8
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -0,0 +1,908 @@
[snip]
> +static void __exit
> +tda998x_exit(void)
> +{
> + DBG("");
> + drm_i2c_encoder_unregister(_driver);
> +}
> +
> +MODULE_DESCRIPTION("NXP Semiconductors TDA998X TMDS transmitter driver");
> +
> +MODULE_AUTHOR("Rob Clark  +MODULE_DESCRIPTION("NXP Semiconductors TDA998X HDMI Encoder");
> +MODULE_LICENSE("GPL");
> +
> +module_init(tda998x_init);
> +module_exit(tda998x_exit);

There are 2 MODULE_DESCRIPTION().

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Jean-Francois Moine]

Hi Rob,

As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
I had a look at your IT LCD driver. Comments below.

On Tue, 22 Jan 2013 16:36:22 -0600
Rob Clark  wrote:

> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
> CMA helpers.  Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape).  There are also various LCD
> displays, for which support can be added (as I get hw to test on),
> and an external i2c HDMI encoder found on some boards.
> 
> The display controller supports a single CRTC.  And the encoder+
> connector are split out into sub-devices.  Depending on which LCD
> or external encoder is actually present, the appropriate output
> module(s) will be loaded.
> 
> v1: original
> v2: fix fb refcnting and few other cleanups
> v3: get +/- vsync/hsync from timings rather than panel-info, add
> option DT max-bandwidth field so driver doesn't attempt to
> pick a display mode with too high memory bandwidth, and other
> small cleanups
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tilcdc/Kconfig |  10 +
>  drivers/gpu/drm/tilcdc/Makefile|   8 +
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 
> +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 +
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 +
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 ++
>  10 files changed, 1985 insertions(+)
>  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
[snip]
> diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
> new file mode 100644
> index 000..ee9b592
> --- /dev/null
> +++ b/drivers/gpu/drm/tilcdc/Kconfig
> @@ -0,0 +1,10 @@
> +config DRM_TILCDC
> + tristate "DRM Support for TI LCDC Display Controller"
> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_GEM_CMA_HELPER
> + help
> +   Choose this option if you have an TI SoC with LCDC display
> +   controller, for example AM33xx in beagle-bone, DA8xx, or
> +   OMAP-L1xx.  This driver replaces the FB_DA8XX fbdev driver.
> diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
> new file mode 100644
> index 000..1359cc2
> --- /dev/null
> +++ b/drivers/gpu/drm/tilcdc/Makefile
> @@ -0,0 +1,8 @@
> +ccflags-y := -Iinclude/drm -Werror
> +
> +tilcdc-y := \
> + tilcdc_crtc.o \
> + tilcdc_tfp410.o \
> + tilcdc_drv.o

As I understand, this means that the 3 objects will go into the
resident kernel.

I though that the device tree was created for Linux distributors who
might generate generic ARM kernels, the choice of the drivers being
done according the local device tree.

[PATCH] drm_crtc: check if fb_create return NULL

[Su, Xuemin]

From: xueminsu 
Date: Tue, 22 Jan 2013 22:39:39 +0800
Subject: [PATCH] drm_crtc: check if fb_create return NULL

Some buggy driver may still return NULL in fb_create,
which leads to kernel panic.

Signed-off-by: xueminsu 
---
 drivers/gpu/drm/drm_crtc.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f2d667b..4ed0aed 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2172,6 +2172,12 @@ int drm_mode_addfb(struct drm_device *dev,
ret = PTR_ERR(fb);
goto out;
}
+   /* some buggy driver may return NULL here, which may cause panic */
+   if (!fb) {
+   WARN(1, "%pf should not return NULL.",
+   dev->mode_config.funcs->fb_create);
+   return -EINVAL;
+   }

or->fb_id = fb->base.id;
list_add(>filp_head, _priv->fbs);
-- 
1.7.6

[PATCH] radeon_display: Use pointer return error codes

[Su, Xuemin]

From: xueminsu 
Date: Tue, 22 Jan 2013 22:16:53 +0800
Subject: [PATCH] radeon_display: Use pointer return error codes

drm_mode_addfb() expects fb_create return error code
instead of NULL.

Signed-off-by: xueminsu 
---
 drivers/gpu/drm/radeon/radeon_display.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 1da2386..ff3def7 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1122,7 +1122,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
if (ret) {
kfree(radeon_fb);
drm_gem_object_unreference_unlocked(obj);
-   return NULL;
+   return ERR_PTR(ret);
}

return _fb->base;
-- 
1.7.6

[PATCH v16 RESEND 0/7] of: add display helper

[Steffen Trumtrar]

On Tue, Jan 22, 2013 at 03:50:48PM -0600, Rob Clark wrote:
> On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar
>  wrote:
> > Hi!
> >
> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the
> > series. So, this is just a resend.
> > The patches were tested with:
> >
> > - v15 on Tegra by Thierry
> > - sh-mobile-lcdcfb by Laurent
> > - MX53QSB by Marek
> > - Exynos: smdk5250 by Leela
> > - AM335X EVM & AM335X EVM-SK by Afzal
> > - imx6q: sabrelite, sabresd by Philipp and me
> > - imx53: tqma53/mba53 by me
> 
> 
> btw, you can add my tested-by for this series..  I've been using them
> for the tilcdc lcd-panel output driver support.
> 

Thanks. The more drivers the merrier ;-)

Steffen

> >
> >
> > Changes since v15:
> > - move include/linux/{videomode,display_timing}.h to include/video
> > - move include/linux/of_{videomode,display_timing}.h to 
> > include/video
> > - reimplement flags: add VESA flags and data flags
> > - let pixelclock in struct videomode be unsigned long
> > - rename of_display_timings_exists to of_display_timings_exist
> > - revise logging/error messages: replace __func__ with np->full_name
> > - rename pixelclk-inverted to pixelclk-active
> > - revise comments in code
> >
> > Changes since v14:
> > - fix "const struct *" warning
> > (reported by: Leela Krishna Amudala  > samsung.com>)
> > - return -EINVAL when htotal or vtotal are zero
> > - remove unreachable code in of_get_display_timings
> > - include headers in .c files and not implicit in .h
> > - sort includes alphabetically
> > - fix lower/uppercase in binding documentation
> > - rebase onto v3.7-rc7
> >
> > Changes since v13:
> > - fix "const struct *" warning
> > (reported by: Laurent Pinchart  > ideasonboard.com>)
> > - prevent division by zero in fb_videomode_from_videomode
> >
> > Changes since v12:
> > - rename struct display_timing to via_display_timing in via 
> > subsystem
> > - fix refreshrate calculation
> > - fix "const struct *" warnings
> > (reported by: Manjunathappa, Prakash )
> > - some CodingStyle fixes
> > - rewrite parts of commit messages and display-timings.txt
> > - let display_timing_get_value get all values instead of just 
> > typical
> >
> > Changes since v11:
> > - make pointers const where applicable
> > - add reviewed-by Laurent Pinchart
> >
> > Changes since v10:
> > - fix function name (drm_)display_mode_from_videomode
> > - add acked-by, reviewed-by, tested-by
> >
> > Changes since v9:
> > - don't leak memory when previous timings were correct
> > - CodingStyle fixes
> > - move blank lines around
> >
> > Changes since v8:
> > - fix memory leaks
> > - change API to be more consistent (foo_from_bar(struct bar, struct 
> > foo))
> > - include headers were necessary
> > - misc minor bugfixes
> >
> > Changes since v7:
> > - move of_xxx to drivers/video
> > - remove non-binding documentation from display-timings.txt
> > - squash display_timings and videomode in one patch
> > - misc minor fixes
> >
> > Changes since v6:
> > - get rid of some empty lines etc.
> > - move functions to their subsystems
> > - split of_ from non-of_ functions
> > - add at least some kerneldoc to some functions
> >
> > Changes since v5:
> > - removed all display stuff and just describe timings
> >
> > Changes since v4:
> > - refactored functions
> >
> > Changes since v3:
> > - print error messages
> > - free alloced memory
> > - general cleanup
> >
> > Changes since v2:
> > - use hardware-near property-names
> > - provide a videomode structure
> > - allow ranges for all properties ()
> > - functions to get display_mode or fb_videomode
> >
> >
> > Regards,
> > Steffen
> >
> >
> > Steffen Trumtrar (7):
> >   viafb: rename display_timing to via_display_timing
> >   video: add display_timing and videomode
> >   video: add of helper for display timings/videomode
> >   fbmon: add videomode helpers
> >   fbmon: add of_videomode helpers
> >   drm_modes: add videomode helpers
> >   drm_modes: add of_videomode helpers
> >
> >  .../devicetree/bindings/video/display-timing.txt   |  109 +
> >  drivers/gpu/drm/drm_modes.c|   70 ++
> >  drivers/video/Kconfig  |   21 ++
> >  drivers/video/Makefile |4 +
> >  drivers/video/display_timing.c |   24 ++
> >  drivers/video/fbmon.c  |   94 
> >  drivers/video/of_display_timing.c  |  239 
> > 

[PATCH v2 4/5] drm/tegra: Implement VBLANK support

[Terje Bergström]

On 22.01.2013 21:59, Mario Kleiner wrote:
> The current swap scheduling is based on having an accurate software 
> vblank counter. Atm. that counter is maintained in software, incremented 
> during vblank irq. At irq off -> on transition we need a hw counter to 
> reinitialize. And there is a timeout between dropping the last reference 
> to a counter via drm_vblank_put() and actually disabling the vblank irq. 
> If the timeout is long enough and a timing sensitive app is aware that 
> vblank counters may be inaccurate/unreliable over long time periods, it 
> can work around the problem.

We have a hardware counter that can be used as VBLANK counter - host1x
sync point register numbers 26 and 27. tegradrm already sets them up in
dc init (DC_CMD_CONT_SYNCPT_VSYNC). Basic syncpt support (read, wait) is
part of my patch set to implement 2D acceleration.

Terje

[PATCH] drm/exynos: add check for the device power status

[Sean Paul]

On Wed, Jan 23, 2013 at 5:10 AM, Shirish S  wrote:
> The hdmi and mixer win_commit calls currently are
> not checking the status of IP before updating the
> respective registers, this patch adds this check.
>
> Signed-off-by: Shirish S 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 3 +++
>  drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2c46b6c..ae79688 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2170,6 +2170,9 @@ static void hdmi_commit(void *ctx)
>
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>
> +   if (!hdata->powered)

The rest of the driver protects reads & writes to powered with hdmi_mutex

> +   return;
> +
> hdmi_conf_apply(hdata);
>  }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 21db895..4f5433f 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -775,6 +775,9 @@ static void mixer_win_commit(void *ctx, int win)
>
> DRM_DEBUG_KMS("[%d] %s, win: %d\n", __LINE__, __func__, win);
>
> +   if (!mixer_ctx->powered)

This is also protected everywhere else in the driver.

> +   return;
> +
> if (win > 1 && mixer_ctx->vp_enabled)
> vp_video_buffer(mixer_ctx, win);
> else
> --
> 1.8.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon_display: Use pointer return error codes

[Alex Deucher]

On Tue, Jan 22, 2013 at 9:27 PM, Su, Xuemin  wrote:
> From: xueminsu 
> Date: Tue, 22 Jan 2013 22:16:53 +0800
> Subject: [PATCH] radeon_display: Use pointer return error codes
>
> drm_mode_addfb() expects fb_create return error code
> instead of NULL.
>
> Signed-off-by: xueminsu 

Thanks.  Added to my fixes queue.

Alex


> ---
>  drivers/gpu/drm/radeon/radeon_display.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 1da2386..ff3def7 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1122,7 +1122,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
> if (ret) {
> kfree(radeon_fb);
> drm_gem_object_unreference_unlocked(obj);
> -   return NULL;
> +   return ERR_PTR(ret);
> }
>
> return _fb->base;
> --
> 1.7.6
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] TI LCDC DRM driver

[Sascha Hauer]

Hi Rob,

On Tue, Jan 22, 2013 at 04:36:21PM -0600, Rob Clark wrote:
> 
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/i2c/Makefile   |   3 +
>  drivers/gpu/drm/i2c/tda998x_drv.c  | 908 
> +
>  drivers/gpu/drm/tilcdc/Kconfig |  25 +
>  drivers/gpu/drm/tilcdc/Makefile|  10 +
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 ++
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 611 ++
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 ++
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 443 
>  drivers/gpu/drm/tilcdc/tilcdc_panel.h  |  26 +
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 ++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 380 ++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 +
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 +
>  16 files changed, 3794 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

I'm missing Documentation/devicetree/bindings/drm/tilcdc/ in the
diffstat. This is required for adding devicetree bindings.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 2/4] drm/i2c: nxp-tda998x (v2)

[Koen Kooi]

Op 22 jan. 2013, om 23:36 heeft Rob Clark  het volgende 
geschreven:

> Driver for the NXP TDA998X i2c hdmi encoder slave.
> 
> v1: original
> v2: fix npix/nline programming
> 
> Signed-off-by: Rob Clark 

Tested on a  beaglebone-black:

Tested-by: Koen Kooi 

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Koen Kooi]

Op 22 jan. 2013, om 23:36 heeft Rob Clark  het volgende 
geschreven:

> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
> CMA helpers.  Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape).  There are also various LCD
> displays, for which support can be added (as I get hw to test on),
> and an external i2c HDMI encoder found on some boards.
> 
> The display controller supports a single CRTC.  And the encoder+
> connector are split out into sub-devices.  Depending on which LCD
> or external encoder is actually present, the appropriate output
> module(s) will be loaded.
> 
> v1: original
> v2: fix fb refcnting and few other cleanups
> v3: get +/- vsync/hsync from timings rather than panel-info, add
>option DT max-bandwidth field so driver doesn't attempt to
>pick a display mode with too high memory bandwidth, and other
>small cleanups
> 
> Signed-off-by: Rob Clark 

Tested on a beaglebone and beaglebone-black:

Tested-by: Koen Kooi 

thoughts on requiring multi-arch support for arm drm drivers?

[Sascha Hauer]

On Wed, Jan 23, 2013 at 02:29:25AM +0100, Laurent Pinchart wrote:
> Hi Rob,
> 
> On Monday 21 January 2013 09:54:01 Rob Clark wrote:
> > On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart wrote:
> > > On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
> > >> One thing I've run into in the past when trying to make changes in drm
> > >> core, and Daniel Vetter has mentioned the same, is that it is a bit of
> > >> a pain to compile test things for the arm drivers that do not support
> > >> CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
> > >> the low hanging fruit (basically the drivers that just needed a
> > >> Kconfig change).  But, IIRC some of the backlight related code in
> > >> shmob had some non-trivial plat dependencies.
> > > 
> > > I've just compiled the shmob-drm driver without any error on x86_64. The
> > > CMA GEM helpers don't compile due to missing
> > > dma_(alloc|free)_writecombine though (but that would only be an issue if
> > > we require no arch dependency at all, not with multiarch).
> > 
> > ahh, ok.. maybe I should try again.  I'm pretty sure I was hitting
> > some issues around the backlight code before, but maybe that has been
> > fixed since then.
> > 
> > Anyways, if it builds for multi-platform, maybe you could send a patch
> > for the kconfig?
> 
> Do you prefer a dependency on (ARM || SUPERH) or (ARCH_MULTIPLATFORM || 
> SUPERH) ?

I suggest ARM instead of ARCH_MULTIPLATFORM since the former is the real
requirement for being able to compile it.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Rob Clark]

On Wed, Jan 23, 2013 at 8:13 AM, Rob Clark  wrote:
> On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
>  wrote:
>> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine  
>>> wrote:
>>> > Hi Rob,
>>> >
>>> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
>>> > I had a look at your IT LCD driver. Comments below.
>>>
>>> Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
>>> (just in case that wasn't clear).
>>
>> Great, this chip is also used on the cubox too.
>
> cool, it would be great if other platforms could benefit from this as
> well.. the out-of-tree nxp driver is just horrid ;-)
>
>> The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
>> that are provided to the TDA9988x chip.  On the cubox, I have to adjust
>> the mode parameters such that the polarities are fixed up thusly:
>>
>> adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
>>  DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
>>  DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);
>>
>> /* The TDA19988 always requires negative VSYNC? */
>> adjusted->flags |= DRM_MODE_FLAG_NVSYNC;
>>
>> /* The TDA19988 requires positive HSYNC on 1080p or 720p */
>> if ((adjusted->hdisplay == 1920 && adjusted->vdisplay == 1080) ||
>> (adjusted->hdisplay == 1280 && adjusted->vdisplay == 720))
>> adjusted->flags |= DRM_MODE_FLAG_PHSYNC;
>> else
>> adjusted->flags |= DRM_MODE_FLAG_NHSYNC;
>>
>> return true;
>>
>> for these resolutions to be displayed correctly.
>
> hmm, I didn't come across this.  Although 1080p seems to be a bit more
> than what the little board I'm working on can drive.  I didn't have to
> do any special fixup for 720p..

one thought.. I haven't enabled any hdmi features like audio yet..
which could be a reason that I didn't hit some of these issues.  I'm
not really much of an audio/asoc expert so I'm not really sure how
this should hook in for audio stuff, but if someone out there with
some hw with a similar nxp encoder chip does have some better audio
experience, I'd be interested to work together on that.

BR,
-R

> I wonder if you are having to do that with the nxp out of tree driver?
>  Maybe it is related to how that driver it is configuring the hw?  It
> would be interesting if you hit the same issue w/ the i2c encoder
> slave version.
>
> At any rate, if it turns out to be needed, we can add this in
> tda998x_encoder_mode_fixup().
>
>> Also, when the only output is the HDMI device, reporting the display
>> "disconnected" and without any modes seems to cause problems - I have to
>> report "unknown" status when there's nothing connected, and also provide
>> a default (720p) mode when no EDID is received.
>
> hmm, also did not run into any issues here on my end.  What sort of
> problems did you hit?
>
> BR,
> -R

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Rob Clark]

On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
 wrote:
> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine  
>> wrote:
>> > Hi Rob,
>> >
>> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
>> > I had a look at your IT LCD driver. Comments below.
>>
>> Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
>> (just in case that wasn't clear).
>
> Great, this chip is also used on the cubox too.

cool, it would be great if other platforms could benefit from this as
well.. the out-of-tree nxp driver is just horrid ;-)

> The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
> that are provided to the TDA9988x chip.  On the cubox, I have to adjust
> the mode parameters such that the polarities are fixed up thusly:
>
> adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
>  DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
>  DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);
>
> /* The TDA19988 always requires negative VSYNC? */
> adjusted->flags |= DRM_MODE_FLAG_NVSYNC;
>
> /* The TDA19988 requires positive HSYNC on 1080p or 720p */
> if ((adjusted->hdisplay == 1920 && adjusted->vdisplay == 1080) ||
> (adjusted->hdisplay == 1280 && adjusted->vdisplay == 720))
> adjusted->flags |= DRM_MODE_FLAG_PHSYNC;
> else
> adjusted->flags |= DRM_MODE_FLAG_NHSYNC;
>
> return true;
>
> for these resolutions to be displayed correctly.

hmm, I didn't come across this.  Although 1080p seems to be a bit more
than what the little board I'm working on can drive.  I didn't have to
do any special fixup for 720p..

I wonder if you are having to do that with the nxp out of tree driver?
 Maybe it is related to how that driver it is configuring the hw?  It
would be interesting if you hit the same issue w/ the i2c encoder
slave version.

At any rate, if it turns out to be needed, we can add this in
tda998x_encoder_mode_fixup().

> Also, when the only output is the HDMI device, reporting the display
> "disconnected" and without any modes seems to cause problems - I have to
> report "unknown" status when there's nothing connected, and also provide
> a default (720p) mode when no EDID is received.

hmm, also did not run into any issues here on my end.  What sort of
problems did you hit?

BR,
-R

[PATCH 2/4] drm/i2c: nxp-tda998x (v2)

[Rob Clark]

On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine  wrote:
> On Tue, 22 Jan 2013 16:36:23 -0600
> Rob Clark  wrote:
>
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>>
>> v1: original
>> v2: fix npix/nline programming
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/i2c/Makefile  |   3 +
>>  drivers/gpu/drm/i2c/tda998x_drv.c | 908 
>> ++
>>  2 files changed, 911 insertions(+)
>>  create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
> [snip]
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> new file mode 100644
>> index 000..02054e8
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -0,0 +1,908 @@
> [snip]
>> +static void __exit
>> +tda998x_exit(void)
>> +{
>> + DBG("");
>> + drm_i2c_encoder_unregister(_driver);
>> +}
>> +
>> +MODULE_DESCRIPTION("NXP Semiconductors TDA998X TMDS transmitter driver");
>> +
>> +MODULE_AUTHOR("Rob Clark > +MODULE_DESCRIPTION("NXP Semiconductors TDA998X HDMI Encoder");
>> +MODULE_LICENSE("GPL");
>> +
>> +module_init(tda998x_init);
>> +module_exit(tda998x_exit);
>
> There are 2 MODULE_DESCRIPTION().

oh, whoops.. I'll fix that

BR,
-R

> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef |   http://moinejf.free.fr/

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Rob Clark]

On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine  wrote:
> Hi Rob,
>
> As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> I had a look at your IT LCD driver. Comments below.

Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
(just in case that wasn't clear).

It may be that we need to add some configuration info struct, if for
example there are some differences in video signal mux on the dove
board, but that shouldn't be a big deal.  I figure we can see what is
needed as others start to use it and add as needed.

> On Tue, 22 Jan 2013 16:36:22 -0600
> Rob Clark  wrote:
>
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
>> CMA helpers.  Currently only the TFP410 DVI encoder is supported
>> (tested with beaglebone + DVI cape).  There are also various LCD
>> displays, for which support can be added (as I get hw to test on),
>> and an external i2c HDMI encoder found on some boards.
>>
>> The display controller supports a single CRTC.  And the encoder+
>> connector are split out into sub-devices.  Depending on which LCD
>> or external encoder is actually present, the appropriate output
>> module(s) will be loaded.
>>
>> v1: original
>> v2: fix fb refcnting and few other cleanups
>> v3: get +/- vsync/hsync from timings rather than panel-info, add
>> option DT max-bandwidth field so driver doesn't attempt to
>> pick a display mode with too high memory bandwidth, and other
>> small cleanups
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/Kconfig|   2 +
>>  drivers/gpu/drm/Makefile   |   1 +
>>  drivers/gpu/drm/tilcdc/Kconfig |  10 +
>>  drivers/gpu/drm/tilcdc/Makefile|   8 +
>>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 
>> 
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 
>> +
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 +
>>  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 +
>>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
>>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 ++
>>  10 files changed, 1985 insertions(+)
>>  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>>  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
> [snip]
>> diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
>> new file mode 100644
>> index 000..ee9b592
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tilcdc/Kconfig
>> @@ -0,0 +1,10 @@
>> +config DRM_TILCDC
>> + tristate "DRM Support for TI LCDC Display Controller"
>> + depends on DRM && OF
>> + select DRM_KMS_HELPER
>> + select DRM_KMS_CMA_HELPER
>> + select DRM_GEM_CMA_HELPER
>> + help
>> +   Choose this option if you have an TI SoC with LCDC display
>> +   controller, for example AM33xx in beagle-bone, DA8xx, or
>> +   OMAP-L1xx.  This driver replaces the FB_DA8XX fbdev driver.
>> diff --git a/drivers/gpu/drm/tilcdc/Makefile 
>> b/drivers/gpu/drm/tilcdc/Makefile
>> new file mode 100644
>> index 000..1359cc2
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tilcdc/Makefile
>> @@ -0,0 +1,8 @@
>> +ccflags-y := -Iinclude/drm -Werror
>> +
>> +tilcdc-y := \
>> + tilcdc_crtc.o \
>> + tilcdc_tfp410.o \
>> + tilcdc_drv.o
>
> As I understand, this means that the 3 objects will go into the
> resident kernel.
>
> I though that the device tree was created for Linux distributors who
> might generate generic ARM kernels, the choice of the drivers being
> done according the local device tree.
>
> From this point of vue, it would be nicer to have 2 separate modules:
> tilcdc and tfp410, tilcdc_crtc being included in one of these ones
> (I did not look deep enough at the code to know which).

drv and crtc are the "core" driver... arguably the tfp410 part could
be optional.  I'd prefer *not* as a separate module, as this implies
some independence of module lifetime, which is not true.  I generally
prefer to start simple and add complexity later if someone really
thinks they need it, which is why I avoided adding a bunch of kconfig
options to start with.

> [snip]
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
>> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> new file mode 100644
>> index 000..cf1fddc
>> --- /dev/null
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> @@ -0,0 +1,605 @@
> [snip]
>> +static struct drm_driver tilcdc_driver = {
>> + .driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET,
>> + .load   = 

[Bug 58667] Random crashes on CAYMAN

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

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

--- Comment #41 from Thomas Rohloff  ---
I got a crash with a BUG message. I'm sorry for the bad image quality but I had
no better camera available (that's why I made that many images)

http://img571.imageshack.us/img571/5517/dsc02036ws.jpg
http://img254.imageshack.us/img254/6779/dsc02037i.jpg
http://img834.imageshack.us/img834/4889/dsc02038cz.jpg
http://img835.imageshack.us/img835/5993/dsc02039s.jpg
http://img338.imageshack.us/img338/1946/dsc02040b.jpg
http://img5.imageshack.us/img5/5683/dsc02041hc.jpg
http://img69.imageshack.us/img69/8716/dsc02042vj.jpg
http://img594.imageshack.us/img594/8600/dsc02043cnt.jpg

I also have a video, so if the images aren't enough just ask.

-- 
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/20130123/0b848160/attachment.html>

[Bug 59492] piglit dlist-color-material test fail

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

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

--- Comment #22 from smoki  ---

 And of course dlist-color-material piglit test should pass ;).

-- 
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/20130123/e7b568bb/attachment-0001.html>

[Bug 59492] piglit dlist-color-material test fail

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

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

--- Comment #21 from smoki  ---

 But must say, this patch however worked perfectly here for supertuxkart ;), no
issues spotted in any other games i tried these few days. 

 Maybe someone who use r200 driver can test:

 http://supertuxkart.sourceforge.net/Downloads

 0.8 version with or without patch, without patch whole olivermath track have
broken colors and lights are broken but not always can be easely spoted. Anyway
you can immediately broke lights if do one skid/ding on any single track. With
a patch all these lighting/color issues should be fixed.

-- 
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/20130123/03fa018a/attachment.html>

[PATCH] drm/exynos: add check for the device power status

[Shirish S]

The hdmi and mixer win_commit calls currently are
not checking the status of IP before updating the
respective registers, this patch adds this check.

Signed-off-by: Shirish S 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 3 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..ae79688 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2170,6 +2170,9 @@ static void hdmi_commit(void *ctx)

DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);

+   if (!hdata->powered)
+   return;
+
hdmi_conf_apply(hdata);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21db895..4f5433f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -775,6 +775,9 @@ static void mixer_win_commit(void *ctx, int win)

DRM_DEBUG_KMS("[%d] %s, win: %d\n", __LINE__, __func__, win);

+   if (!mixer_ctx->powered)
+   return;
+
if (win > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, win);
else
-- 
1.8.0

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

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

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





--- Comment #19 from Fernando Chaves   2013-01-23 
04:15:42 ---
I would like to inform that this motherboard uses UEFI.

And, obviously, I'm using Legacy Boot.

This requires some [video] emulation, right?

There is any known issue with Xen about motherboards that uses UEFI? If I
install an UEFI-aware bootloader, like rEFInd or grub-efi, can I boot the
hypervisor?

Big observations made since last message sent:
- BIOS-aware bootloaders (GRUB Legacy, GRUB 2, ISOLINUX, PXELINUX) have a
slower keyboard response AND very slow screen refresh. keystrokes under those
bootloaders have a ~500ms response delay. Also screen refresh is [much] slower,
when entering submenus.
- All behaviors previously mentioned disappears when adding an video card.
Tested with a 10 year-old ATI Rage XL 16MB PCI.

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

thoughts on requiring multi-arch support for arm drm drivers?

[Laurent Pinchart]

Hi Rob,

On Monday 21 January 2013 09:54:01 Rob Clark wrote:
> On Mon, Jan 21, 2013 at 9:47 AM, Laurent Pinchart wrote:
> > On Sunday 20 January 2013 09:08:34 Rob Clark wrote:
> >> One thing I've run into in the past when trying to make changes in drm
> >> core, and Daniel Vetter has mentioned the same, is that it is a bit of
> >> a pain to compile test things for the arm drivers that do not support
> >> CONFIG_ARCH_MULTIPLATFORM.  I went through a while back and fixed up
> >> the low hanging fruit (basically the drivers that just needed a
> >> Kconfig change).  But, IIRC some of the backlight related code in
> >> shmob had some non-trivial plat dependencies.
> > 
> > I've just compiled the shmob-drm driver without any error on x86_64. The
> > CMA GEM helpers don't compile due to missing
> > dma_(alloc|free)_writecombine though (but that would only be an issue if
> > we require no arch dependency at all, not with multiarch).
> 
> ahh, ok.. maybe I should try again.  I'm pretty sure I was hitting
> some issues around the backlight code before, but maybe that has been
> fixed since then.
> 
> Anyways, if it builds for multi-platform, maybe you could send a patch
> for the kconfig?

Do you prefer a dependency on (ARM || SUPERH) or (ARCH_MULTIPLATFORM || 
SUPERH) ?

> >> And I think when tegra came in, it introduced some non-trivial plat
> >> dependencies.
> >> 
> >> What do others think about requiring multiarch or no arch dependencies
> >> for new drivers, and cleaning up existing drivers.  Even if it is at
> >> reduced functionality (like maybe #ifdef CONFIG_ARCH_SHMOBILE for some
> >> of the backlight code in shmob) or doesn't even work but is just for
> >> the purpose of being able to compile test the rest of the code?
> >> 
> >> Thoughts?
> > 
> > That sounds good to me, but would result in many drivers being exposed on
> > x86 even though they're useless on that platform. Would it make sense to
> > add a new CONFIG_COMPILE_TEST (or similar) Kconfig option used for
> > compilation tests only ? The shmob driver would then depend on SUPERH ||
> > ARCH_MULTIPLATFORM || COMPILE_TEST.
> 
> fwiw, CONFIG_OF seems to filter things out on x86..  but I could live
> doing one arm build and one x86 build to compile test things.
> 
> CONFIG_COMPILE_TEST might be a good idea if we need stub fxn hacks to
> build (ie. driver is known not to be functional).. sounds like that
> will shortly not be an issue for tegra, and if shmobile already buids
> on multiplatform, then maybe we won't need this.

CONFIG_COMPILE_TEST could be used to avoid exposing drivers on platforms where 
they're not useful, while still enabling an easy way to compile them all. The 
shmob-drm driver would then depend on

(ARCH_SHMOBILE || SUPERH || COMPILE_TEST)

> > I'm pretty sure I've seen a similar proposal quite recently but I can't
> > remember where.

-- 
Regards,

Laurent Pinchart

[Bug 37117] configure fails in git/master

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

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

Matt Turner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Matt Turner  ---
I can only find fd3ed34a2070fca3804baf54ece40d0bc2666226 which touched
LT_PREREQ, and it added

LT_PREREQ([2.2])

not

LT_PREREQ(2.2)

so I can't guess what the problem you saw was. Given that 18 months have passed
without any more updates to this bug or reports of it happening to other
people, I'm going to close it. Reopen if you are able to reproduce it still.

-- 
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/20130123/e4fe55b5/attachment.html>

[PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Daniel Vetter]

On Tue, Jan 22, 2013 at 04:36:22PM -0600, Rob Clark wrote:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
> CMA helpers.  Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape).  There are also various LCD
> displays, for which support can be added (as I get hw to test on),
> and an external i2c HDMI encoder found on some boards.
> 
> The display controller supports a single CRTC.  And the encoder+
> connector are split out into sub-devices.  Depending on which LCD
> or external encoder is actually present, the appropriate output
> module(s) will be loaded.
> 
> v1: original
> v2: fix fb refcnting and few other cleanups
> v3: get +/- vsync/hsync from timings rather than panel-info, add
> option DT max-bandwidth field so driver doesn't attempt to
> pick a display mode with too high memory bandwidth, and other
> small cleanups
> 
> Signed-off-by: Rob Clark 

Ok, read through it, looks nice. No idea whether this should use the panel
stuff, but since no-one else does who cares. A few nits and questions
below. Was a nice reading to learn about kfifo and the runtime power
stuff.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tilcdc/Kconfig |  10 +
>  drivers/gpu/drm/tilcdc/Makefile|   8 +
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 
> +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 +
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 +
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 ++
>  10 files changed, 1985 insertions(+)
>  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
> 

[cut]

> +struct tilcdc_crtc {
> + struct drm_crtc base;
> +
> + const struct tilcdc_panel_info *info;
> + uint32_t dirty;
> + dma_addr_t start, end;
> + struct drm_pending_vblank_event *event;
> + int dpms;
> + wait_queue_head_t frame_done_wq;
> + bool frame_done;
> +
> + /* fb currently set to scanout 0/1: */
> + struct drm_framebuffer *scanout[2];
> +
> + /* for deferred fb unref's: */
> + DECLARE_KFIFO_PTR(unref_fifo, struct drm_framebuffer *);
> + struct work_struct work;
> +};
> +#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
> +
> +static void unref_worker(struct work_struct *work)
> +{
> + struct tilcdc_crtc *tilcdc_crtc = container_of(work, struct 
> tilcdc_crtc, work);
> + struct drm_device *dev = tilcdc_crtc->base.dev;
> + struct drm_framebuffer *fb;
> +
> + mutex_lock(>mode_config.mutex);
> + while (kfifo_get(_crtc->unref_fifo, ))
> + drm_framebuffer_unreference(fb);
> + mutex_unlock(>mode_config.mutex);

Hm, just learned about the kfifo api. It looks like the locking here still
works even with the new modeset locking, since kfifo explicitly allows
concurrent readers and writers without locking, as long as there's only on
of each kind. But maybe switch over to crtc->mutex to make things less
tricky.

Also, kfifo seems to have a new api which allows embedding of the kfifo
thing and needs to be used with kfifo_in/out.

[cut]

> +static void update_scanout(struct drm_crtc *crtc)
> +{
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct drm_framebuffer *fb = crtc->fb;
> + struct drm_gem_cma_object *gem;
> + unsigned int depth, bpp;
> +
> + drm_fb_get_bpp_depth(fb->pixel_format, , );
> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> +
> + tilcdc_crtc->start = gem->paddr + fb->offsets[0] +
> + (crtc->y * fb->pitches[0]) + (crtc->x * bpp/8);
> +
> + tilcdc_crtc->end = tilcdc_crtc->start +
> + (crtc->mode.vdisplay * fb->pitches[0]);
> +
> + if (tilcdc_crtc->dpms == DRM_MODE_DPMS_ON) {
> + /* already enabled, so just mark the frames that need
> +  * updating and they will be updated on vblank:
> +  */
> + tilcdc_crtc->dirty |= LCDC_END_OF_FRAME0 | LCDC_END_OF_FRAME1;
> + drm_vblank_get(dev, 0);
> + } else {
> + /* not enabled yet, so update registers immediately: */
> + set_scanout(crtc, 0);
> + set_scanout(crtc, 1);

At least on intel we 

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #8 from Andy Furniss  ---
The patch also fixes the minor issue I reported with some mesa demos.

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

-- 
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/20130123/8ee53097/attachment.html>

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

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

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

--- Comment #7 from Andy Furniss  ---
Created attachment 73485
  --> https://bugs.freedesktop.org/attachment.cgi?id=73485=edit
compressed etqw shaders working with patch

-- 
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/20130123/516eb70c/attachment-0001.html>

[patch v2] drm/nouveau/disp: sizeof() wrong pointer

[Dan Carpenter]

data is a void pointer and args is data after we have casted it to
a struct.  We care about the size of the struct here.  Btw,
sizeof(*data) is 1.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: tweaked the commit message

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
index ca1a7d7..eb9c489 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
@@ -335,7 +335,7 @@ nv50_disp_sync_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;
 
-   if (size  sizeof(*data) || args-head  1)
+   if (size  sizeof(*args) || args-head  1)
return -EINVAL;
 
ret = nv50_disp_dmac_create_(parent, engine, oclass, args-pushbuf,
@@ -374,7 +374,7 @@ nv50_disp_ovly_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;
 
-   if (size  sizeof(*data) || args-head  1)
+   if (size  sizeof(*args) || args-head  1)
return -EINVAL;
 
ret = nv50_disp_dmac_create_(parent, engine, oclass, args-pushbuf,
diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
index 9e38ebf..f28725a 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
@@ -230,7 +230,7 @@ nvd0_disp_sync_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;
 
-   if (size  sizeof(*data) || args-head = priv-head.nr)
+   if (size  sizeof(*args) || args-head = priv-head.nr)
return -EINVAL;
 
ret = nv50_disp_dmac_create_(parent, engine, oclass, args-pushbuf,
@@ -270,7 +270,7 @@ nvd0_disp_ovly_ctor(struct nouveau_object *parent,
struct nv50_disp_dmac *dmac;
int ret;
 
-   if (size  sizeof(*data) || args-head = priv-head.nr)
+   if (size  sizeof(*args) || args-head = priv-head.nr)
return -EINVAL;
 
ret = nv50_disp_dmac_create_(parent, engine, oclass, args-pushbuf,

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

Re: [patch] drm/nouveau/disp: sizeof() wrong pointer

[Dan Carpenter]

On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
 
 Did you find this by manual inspection or did you use some tool?
 

I found this because it caused a problem in a parser I was working
on but Sparse warns about warning: expression using sizeof(void).

It's sort of hard to run Sparse on nouveau because you can't build
the individual .o files.

$ kchecker --sparse drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `relocs'.
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
stdin:1223:2: warning: #warning syscall finit_module not implemented [-Wcpp]
scripts/Makefile.build:44: 
/home/dcarpenter/progs/kernel/devel/drivers/gpu/drm/nouveau/core/engine/disp/Makefile:
 No such file or directory
make[1]: *** No rule to make target 
`/home/dcarpenter/progs/kernel/devel/drivers/gpu/drm/nouveau/core/engine/disp/Makefile'.
  Stop.
make: *** [drivers/gpu/drm/nouveau/core/engine/disp/nv50.o] Error 2

regards,
dan carpenter

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

Re: [PATCH 4/5] drm/tegra: Implement VBLANK support

[Mark Zhang]

On 01/23/2013 02:21 AM, Jon Mayo wrote:
 On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding
 thierry.red...@avionic-design.de wrote:
 Implement support for the VBLANK IOCTL. Note that Tegra is somewhat
 special in this case because it doesn't use the generic IRQ support
 provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one
 interrupt handler for each display controller.

 While at it, clean up the way that interrupts are enabled to ensure
 that the VBLANK interrupt only gets enabled when required.

 Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
 ---
 
 Sorry Thierry, but is this a useful feature? Are applications really
 making use of it? Because it means that that an IRQ will have to
 trigger every 16.67ms when it is taken, which means the device can't
 sleep. (probably OK because it should go back to idle when the app
 lets go of the vblank). But worse, for one-shot panels there is no
 continuous vblank. I've been doing weird hacks to run a timer when the
 smart panel is idle to trick applications into thinking they have a
 vblank pulse. But really I think the whole feature of a vblank pulse
 is pretty lame and I wish it would die. Were you going to use it for
 something specific, or just adding it for completeness?
 

I guess people don't use this to really wait vblanks because that can be
done by polling drm fd. Normally they use this ioctl to get the vblank
counts which may be useful for their applications.

Mark
 - Jon
 --
 To unsubscribe from this list: send the line unsubscribe linux-tegra 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 v16 RESEND 0/7] of: add display helper

[Steffen Trumtrar]

On Tue, Jan 22, 2013 at 03:50:48PM -0600, Rob Clark wrote:
 On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar
 s.trumt...@pengutronix.de wrote:
  Hi!
 
  There was still no maintainer, that commented, ack'd, nack'd, apply'd the
  series. So, this is just a resend.
  The patches were tested with:
 
  - v15 on Tegra by Thierry
  - sh-mobile-lcdcfb by Laurent
  - MX53QSB by Marek
  - Exynos: smdk5250 by Leela
  - AM335X EVM  AM335X EVM-SK by Afzal
  - imx6q: sabrelite, sabresd by Philipp and me
  - imx53: tqma53/mba53 by me
 
 
 btw, you can add my tested-by for this series..  I've been using them
 for the tilcdc lcd-panel output driver support.
 

Thanks. The more drivers the merrier ;-)

Steffen

 
 
  Changes since v15:
  - move include/linux/{videomode,display_timing}.h to include/video
  - move include/linux/of_{videomode,display_timing}.h to 
  include/video
  - reimplement flags: add VESA flags and data flags
  - let pixelclock in struct videomode be unsigned long
  - rename of_display_timings_exists to of_display_timings_exist
  - revise logging/error messages: replace __func__ with np-full_name
  - rename pixelclk-inverted to pixelclk-active
  - revise comments in code
 
  Changes since v14:
  - fix const struct * warning
  (reported by: Leela Krishna Amudala l.kris...@samsung.com)
  - return -EINVAL when htotal or vtotal are zero
  - remove unreachable code in of_get_display_timings
  - include headers in .c files and not implicit in .h
  - sort includes alphabetically
  - fix lower/uppercase in binding documentation
  - rebase onto v3.7-rc7
 
  Changes since v13:
  - fix const struct * warning
  (reported by: Laurent Pinchart 
  laurent.pinch...@ideasonboard.com)
  - prevent division by zero in fb_videomode_from_videomode
 
  Changes since v12:
  - rename struct display_timing to via_display_timing in via 
  subsystem
  - fix refreshrate calculation
  - fix const struct * warnings
  (reported by: Manjunathappa, Prakash prakash...@ti.com)
  - some CodingStyle fixes
  - rewrite parts of commit messages and display-timings.txt
  - let display_timing_get_value get all values instead of just 
  typical
 
  Changes since v11:
  - make pointers const where applicable
  - add reviewed-by Laurent Pinchart
 
  Changes since v10:
  - fix function name (drm_)display_mode_from_videomode
  - add acked-by, reviewed-by, tested-by
 
  Changes since v9:
  - don't leak memory when previous timings were correct
  - CodingStyle fixes
  - move blank lines around
 
  Changes since v8:
  - fix memory leaks
  - change API to be more consistent (foo_from_bar(struct bar, struct 
  foo))
  - include headers were necessary
  - misc minor bugfixes
 
  Changes since v7:
  - move of_xxx to drivers/video
  - remove non-binding documentation from display-timings.txt
  - squash display_timings and videomode in one patch
  - misc minor fixes
 
  Changes since v6:
  - get rid of some empty lines etc.
  - move functions to their subsystems
  - split of_ from non-of_ functions
  - add at least some kerneldoc to some functions
 
  Changes since v5:
  - removed all display stuff and just describe timings
 
  Changes since v4:
  - refactored functions
 
  Changes since v3:
  - print error messages
  - free alloced memory
  - general cleanup
 
  Changes since v2:
  - use hardware-near property-names
  - provide a videomode structure
  - allow ranges for all properties (min,typ,max)
  - functions to get display_mode or fb_videomode
 
 
  Regards,
  Steffen
 
 
  Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
 
   .../devicetree/bindings/video/display-timing.txt   |  109 +
   drivers/gpu/drm/drm_modes.c|   70 ++
   drivers/video/Kconfig  |   21 ++
   drivers/video/Makefile |4 +
   drivers/video/display_timing.c |   24 ++
   drivers/video/fbmon.c  |   94 
   drivers/video/of_display_timing.c  |  239 
  
   drivers/video/of_videomode.c   |   54 +
   drivers/video/via/hw.c |6 +-
   drivers/video/via/hw.h | 

Re: [PATCH V2 RESEND] drm_crtc: check if fb_create return NULL

[Daniel Vetter]

On Wed, Jan 23, 2013 at 11:19:27AM +0800, Su, Xuemin wrote:
 From: xueminsu xuemin...@intel.com
 Date: Tue, 22 Jan 2013 22:39:39 +0800
 Subject: [PATCH] drm_crtc: check if fb_create return NULL
 
 Some buggy driver may still return NULL in fb_create,
 which leads to kernel panic.
 
 Signed-off-by: xueminsu xuemin...@intel.com

Imo just BUG_ON(!fb); and call it a day. Makes it pretty clear what's
expected of the drivers.
-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 58272] Rv670 AGP drm-next ttm errors

[bugzilla-daemon]

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

Andy Furniss li...@andyfurniss.entadsl.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Andy Furniss li...@andyfurniss.entadsl.com ---
Current drm-fixes is working for me now.

The remaining etqw issue was fixed by -

Revert drm/radeon: do not move bo to different placement at each cs

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

Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Rob Clark]

On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine moin...@free.fr wrote:
 Hi Rob,

 As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
 I had a look at your IT LCD driver. Comments below.

Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
(just in case that wasn't clear).

It may be that we need to add some configuration info struct, if for
example there are some differences in video signal mux on the dove
board, but that shouldn't be a big deal.  I figure we can see what is
needed as others start to use it and add as needed.

 On Tue, 22 Jan 2013 16:36:22 -0600
 Rob Clark robdcl...@gmail.com wrote:

 A simple DRM/KMS driver for the TI LCD Controller found in various
 smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
 CMA helpers.  Currently only the TFP410 DVI encoder is supported
 (tested with beaglebone + DVI cape).  There are also various LCD
 displays, for which support can be added (as I get hw to test on),
 and an external i2c HDMI encoder found on some boards.

 The display controller supports a single CRTC.  And the encoder+
 connector are split out into sub-devices.  Depending on which LCD
 or external encoder is actually present, the appropriate output
 module(s) will be loaded.

 v1: original
 v2: fix fb refcnting and few other cleanups
 v3: get +/- vsync/hsync from timings rather than panel-info, add
 option DT max-bandwidth field so driver doesn't attempt to
 pick a display mode with too high memory bandwidth, and other
 small cleanups

 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/Kconfig|   2 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/tilcdc/Kconfig |  10 +
  drivers/gpu/drm/tilcdc/Makefile|   8 +
  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 
 
  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 
 +
  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 +
  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 +
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 ++
  10 files changed, 1985 insertions(+)
  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
 [snip]
 diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
 new file mode 100644
 index 000..ee9b592
 --- /dev/null
 +++ b/drivers/gpu/drm/tilcdc/Kconfig
 @@ -0,0 +1,10 @@
 +config DRM_TILCDC
 + tristate DRM Support for TI LCDC Display Controller
 + depends on DRM  OF
 + select DRM_KMS_HELPER
 + select DRM_KMS_CMA_HELPER
 + select DRM_GEM_CMA_HELPER
 + help
 +   Choose this option if you have an TI SoC with LCDC display
 +   controller, for example AM33xx in beagle-bone, DA8xx, or
 +   OMAP-L1xx.  This driver replaces the FB_DA8XX fbdev driver.
 diff --git a/drivers/gpu/drm/tilcdc/Makefile 
 b/drivers/gpu/drm/tilcdc/Makefile
 new file mode 100644
 index 000..1359cc2
 --- /dev/null
 +++ b/drivers/gpu/drm/tilcdc/Makefile
 @@ -0,0 +1,8 @@
 +ccflags-y := -Iinclude/drm -Werror
 +
 +tilcdc-y := \
 + tilcdc_crtc.o \
 + tilcdc_tfp410.o \
 + tilcdc_drv.o

 As I understand, this means that the 3 objects will go into the
 resident kernel.

 I though that the device tree was created for Linux distributors who
 might generate generic ARM kernels, the choice of the drivers being
 done according the local device tree.

 From this point of vue, it would be nicer to have 2 separate modules:
 tilcdc and tfp410, tilcdc_crtc being included in one of these ones
 (I did not look deep enough at the code to know which).

drv and crtc are the core driver... arguably the tfp410 part could
be optional.  I'd prefer *not* as a separate module, as this implies
some independence of module lifetime, which is not true.  I generally
prefer to start simple and add complexity later if someone really
thinks they need it, which is why I avoided adding a bunch of kconfig
options to start with.

 [snip]
 diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
 b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
 new file mode 100644
 index 000..cf1fddc
 --- /dev/null
 +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
 @@ -0,0 +1,605 @@
 [snip]
 +static struct drm_driver tilcdc_driver = {
 + .driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET,
 + .load   = tilcdc_load,
 + .unload = tilcdc_unload,
 + .preclose   = tilcdc_preclose,
 + .lastclose  = 

Re: [PATCH 2/4] drm/i2c: nxp-tda998x (v2)

[Rob Clark]

On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine moin...@free.fr wrote:
 On Tue, 22 Jan 2013 16:36:23 -0600
 Rob Clark robdcl...@gmail.com wrote:

 Driver for the NXP TDA998X i2c hdmi encoder slave.

 v1: original
 v2: fix npix/nline programming

 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/i2c/Makefile  |   3 +
  drivers/gpu/drm/i2c/tda998x_drv.c | 908 
 ++
  2 files changed, 911 insertions(+)
  create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
 [snip]
 diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
 b/drivers/gpu/drm/i2c/tda998x_drv.c
 new file mode 100644
 index 000..02054e8
 --- /dev/null
 +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
 @@ -0,0 +1,908 @@
 [snip]
 +static void __exit
 +tda998x_exit(void)
 +{
 + DBG();
 + drm_i2c_encoder_unregister(tda998x_driver);
 +}
 +
 +MODULE_DESCRIPTION(NXP Semiconductors TDA998X TMDS transmitter driver);
 +
 +MODULE_AUTHOR(Rob Clark robdcl...@gmail.com);
 +MODULE_DESCRIPTION(NXP Semiconductors TDA998X HDMI Encoder);
 +MODULE_LICENSE(GPL);
 +
 +module_init(tda998x_init);
 +module_exit(tda998x_exit);

 There are 2 MODULE_DESCRIPTION().

oh, whoops.. I'll fix that

BR,
-R

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

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher ag...@yahoo.com ---
Regarding the conversation on IRC, the vertex shader has to export at least one
generic param (not counting special exports like position).  So if the vertex
shader doesn't export any params, you need a dummy one.

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

Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Rob Clark]

On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
 On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine moin...@free.fr wrote:
  Hi Rob,
 
  As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
  I had a look at your IT LCD driver. Comments below.

 Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
 (just in case that wasn't clear).

 Great, this chip is also used on the cubox too.

cool, it would be great if other platforms could benefit from this as
well.. the out-of-tree nxp driver is just horrid ;-)

 The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
 that are provided to the TDA9988x chip.  On the cubox, I have to adjust
 the mode parameters such that the polarities are fixed up thusly:

 adjusted-flags = ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
  DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
  DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);

 /* The TDA19988 always requires negative VSYNC? */
 adjusted-flags |= DRM_MODE_FLAG_NVSYNC;

 /* The TDA19988 requires positive HSYNC on 1080p or 720p */
 if ((adjusted-hdisplay == 1920  adjusted-vdisplay == 1080) ||
 (adjusted-hdisplay == 1280  adjusted-vdisplay == 720))
 adjusted-flags |= DRM_MODE_FLAG_PHSYNC;
 else
 adjusted-flags |= DRM_MODE_FLAG_NHSYNC;

 return true;

 for these resolutions to be displayed correctly.

hmm, I didn't come across this.  Although 1080p seems to be a bit more
than what the little board I'm working on can drive.  I didn't have to
do any special fixup for 720p..

I wonder if you are having to do that with the nxp out of tree driver?
 Maybe it is related to how that driver it is configuring the hw?  It
would be interesting if you hit the same issue w/ the i2c encoder
slave version.

At any rate, if it turns out to be needed, we can add this in
tda998x_encoder_mode_fixup().

 Also, when the only output is the HDMI device, reporting the display
 disconnected and without any modes seems to cause problems - I have to
 report unknown status when there's nothing connected, and also provide
 a default (720p) mode when no EDID is received.

hmm, also did not run into any issues here on my end.  What sort of
problems did you hit?

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

Re: [PATCH] radeon_display: Use pointer return error codes

[Alex Deucher]

On Tue, Jan 22, 2013 at 9:27 PM, Su, Xuemin xuemin...@intel.com wrote:
 From: xueminsu xuemin...@intel.com
 Date: Tue, 22 Jan 2013 22:16:53 +0800
 Subject: [PATCH] radeon_display: Use pointer return error codes

 drm_mode_addfb() expects fb_create return error code
 instead of NULL.

 Signed-off-by: xueminsu xuemin...@intel.com

Thanks.  Added to my fixes queue.

Alex


 ---
  drivers/gpu/drm/radeon/radeon_display.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
 b/drivers/gpu/drm/radeon/radeon_display.c
 index 1da2386..ff3def7 100644
 --- a/drivers/gpu/drm/radeon/radeon_display.c
 +++ b/drivers/gpu/drm/radeon/radeon_display.c
 @@ -1122,7 +1122,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
 if (ret) {
 kfree(radeon_fb);
 drm_gem_object_unreference_unlocked(obj);
 -   return NULL;
 +   return ERR_PTR(ret);
 }

 return radeon_fb-base;
 --
 1.7.6



 ___
 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 2/4] drm/i2c: nxp-tda998x (v2)

[Koen Kooi]

Op 22 jan. 2013, om 23:36 heeft Rob Clark robdcl...@gmail.com het volgende 
geschreven:

 Driver for the NXP TDA998X i2c hdmi encoder slave.
 
 v1: original
 v2: fix npix/nline programming
 
 Signed-off-by: Rob Clark robdcl...@gmail.com

Tested on a  beaglebone-black:

Tested-by: Koen Kooi k...@dominion.thruhere.net

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

Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Jean-Francois Moine]

Hi Rob,

As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
I had a look at your IT LCD driver. Comments below.

On Tue, 22 Jan 2013 16:36:22 -0600
Rob Clark robdcl...@gmail.com wrote:

 A simple DRM/KMS driver for the TI LCD Controller found in various
 smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
 CMA helpers.  Currently only the TFP410 DVI encoder is supported
 (tested with beaglebone + DVI cape).  There are also various LCD
 displays, for which support can be added (as I get hw to test on),
 and an external i2c HDMI encoder found on some boards.
 
 The display controller supports a single CRTC.  And the encoder+
 connector are split out into sub-devices.  Depending on which LCD
 or external encoder is actually present, the appropriate output
 module(s) will be loaded.
 
 v1: original
 v2: fix fb refcnting and few other cleanups
 v3: get +/- vsync/hsync from timings rather than panel-info, add
 option DT max-bandwidth field so driver doesn't attempt to
 pick a display mode with too high memory bandwidth, and other
 small cleanups
 
 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/Kconfig|   2 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/tilcdc/Kconfig |  10 +
  drivers/gpu/drm/tilcdc/Makefile|   8 +
  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 
  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 
 +
  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 +
  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 +
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 ++
  10 files changed, 1985 insertions(+)
  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
[snip]
 diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
 new file mode 100644
 index 000..ee9b592
 --- /dev/null
 +++ b/drivers/gpu/drm/tilcdc/Kconfig
 @@ -0,0 +1,10 @@
 +config DRM_TILCDC
 + tristate DRM Support for TI LCDC Display Controller
 + depends on DRM  OF
 + select DRM_KMS_HELPER
 + select DRM_KMS_CMA_HELPER
 + select DRM_GEM_CMA_HELPER
 + help
 +   Choose this option if you have an TI SoC with LCDC display
 +   controller, for example AM33xx in beagle-bone, DA8xx, or
 +   OMAP-L1xx.  This driver replaces the FB_DA8XX fbdev driver.
 diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
 new file mode 100644
 index 000..1359cc2
 --- /dev/null
 +++ b/drivers/gpu/drm/tilcdc/Makefile
 @@ -0,0 +1,8 @@
 +ccflags-y := -Iinclude/drm -Werror
 +
 +tilcdc-y := \
 + tilcdc_crtc.o \
 + tilcdc_tfp410.o \
 + tilcdc_drv.o

As I understand, this means that the 3 objects will go into the
resident kernel.

I though that the device tree was created for Linux distributors who
might generate generic ARM kernels, the choice of the drivers being
done according the local device tree.

From this point of vue, it would be nicer to have 2 separate modules:
tilcdc and tfp410, tilcdc_crtc being included in one of these ones
(I did not look deep enough at the code to know which).

[snip]
 diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
 b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
 new file mode 100644
 index 000..cf1fddc
 --- /dev/null
 +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
 @@ -0,0 +1,605 @@
[snip]
 +static struct drm_driver tilcdc_driver = {
 + .driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET,
 + .load   = tilcdc_load,
 + .unload = tilcdc_unload,
 + .preclose   = tilcdc_preclose,
 + .lastclose  = tilcdc_lastclose,
 + .irq_handler= tilcdc_irq,
 + .irq_preinstall = tilcdc_irq_preinstall,
 + .irq_postinstall= tilcdc_irq_postinstall,
 + .irq_uninstall  = tilcdc_irq_uninstall,
 + .get_vblank_counter = drm_vblank_count,
 + .enable_vblank  = tilcdc_enable_vblank,
 + .disable_vblank = tilcdc_disable_vblank,
 + .gem_free_object= drm_gem_cma_free_object,
 + .gem_vm_ops = drm_gem_cma_vm_ops,
 + .dumb_create= drm_gem_cma_dumb_create,
 + .dumb_map_offset= drm_gem_cma_dumb_map_offset,
 + .dumb_destroy   = drm_gem_cma_dumb_destroy,
 +#ifdef CONFIG_DEBUG_FS
 + .debugfs_init   = tilcdc_debugfs_init,
 + .debugfs_cleanup= tilcdc_debugfs_cleanup,
 +#endif
 + .fops   = fops,
 + .name  

Re: [PATCH 2/4] drm/i2c: nxp-tda998x (v2)

[Jean-Francois Moine]

On Tue, 22 Jan 2013 16:36:23 -0600
Rob Clark robdcl...@gmail.com wrote:

 Driver for the NXP TDA998X i2c hdmi encoder slave.
 
 v1: original
 v2: fix npix/nline programming
 
 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/i2c/Makefile  |   3 +
  drivers/gpu/drm/i2c/tda998x_drv.c | 908 
 ++
  2 files changed, 911 insertions(+)
  create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
[snip]
 diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
 b/drivers/gpu/drm/i2c/tda998x_drv.c
 new file mode 100644
 index 000..02054e8
 --- /dev/null
 +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
 @@ -0,0 +1,908 @@
[snip]
 +static void __exit
 +tda998x_exit(void)
 +{
 + DBG();
 + drm_i2c_encoder_unregister(tda998x_driver);
 +}
 +
 +MODULE_DESCRIPTION(NXP Semiconductors TDA998X TMDS transmitter driver);
 +
 +MODULE_AUTHOR(Rob Clark robdcl...@gmail.com);
 +MODULE_DESCRIPTION(NXP Semiconductors TDA998X HDMI Encoder);
 +MODULE_LICENSE(GPL);
 +
 +module_init(tda998x_init);
 +module_exit(tda998x_exit);

There are 2 MODULE_DESCRIPTION().

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

[PATCH] drm/exynos: add check for the device power status

[Shirish S]

The hdmi and mixer win_commit calls currently are
not checking the status of IP before updating the
respective registers, this patch adds this check.

Signed-off-by: Shirish S s.shir...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 3 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..ae79688 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2170,6 +2170,9 @@ static void hdmi_commit(void *ctx)
 
DRM_DEBUG_KMS([%d] %s\n, __LINE__, __func__);
 
+   if (!hdata-powered)
+   return;
+
hdmi_conf_apply(hdata);
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21db895..4f5433f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -775,6 +775,9 @@ static void mixer_win_commit(void *ctx, int win)
 
DRM_DEBUG_KMS([%d] %s, win: %d\n, __LINE__, __func__, win);
 
+   if (!mixer_ctx-powered)
+   return;
+
if (win  1  mixer_ctx-vp_enabled)
vp_video_buffer(mixer_ctx, win);
else
-- 
1.8.0

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

Re: [patch] drm/nouveau/disp: sizeof() wrong pointer

[Bernd Petrovitsch]

On Mit, 2013-01-23 at 11:38 +0300, Dan Carpenter wrote:
 On Tue, Jan 22, 2013 at 10:42:25AM +0100, Paul Menzel wrote:
  
  Did you find this by manual inspection or did you use some tool?
 
 I found this because it caused a problem in a parser I was working
 on but Sparse warns about warning: expression using sizeof(void).

gcc's -Wpointer-arith option also reports this.
Never tried it on the kernel though .

Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at

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

Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Russell King - ARM Linux]

On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
 On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine moin...@free.fr wrote:
  Hi Rob,
 
  As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
  I had a look at your IT LCD driver. Comments below.
 
 Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
 (just in case that wasn't clear).

Great, this chip is also used on the cubox too.

The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
that are provided to the TDA9988x chip.  On the cubox, I have to adjust
the mode parameters such that the polarities are fixed up thusly:

adjusted-flags = ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
 DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
 DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);

/* The TDA19988 always requires negative VSYNC? */
adjusted-flags |= DRM_MODE_FLAG_NVSYNC;

/* The TDA19988 requires positive HSYNC on 1080p or 720p */
if ((adjusted-hdisplay == 1920  adjusted-vdisplay == 1080) ||
(adjusted-hdisplay == 1280  adjusted-vdisplay == 720))
adjusted-flags |= DRM_MODE_FLAG_PHSYNC;
else
adjusted-flags |= DRM_MODE_FLAG_NHSYNC;

return true;

for these resolutions to be displayed correctly.

Also, when the only output is the HDMI device, reporting the display
disconnected and without any modes seems to cause problems - I have to
report unknown status when there's nothing connected, and also provide
a default (720p) mode when no EDID is received.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Rob Clark]

On Wed, Jan 23, 2013 at 8:13 AM, Rob Clark robdcl...@gmail.com wrote:
 On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
 On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine moin...@free.fr 
 wrote:
  Hi Rob,
 
  As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
  I had a look at your IT LCD driver. Comments below.

 Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
 (just in case that wasn't clear).

 Great, this chip is also used on the cubox too.

 cool, it would be great if other platforms could benefit from this as
 well.. the out-of-tree nxp driver is just horrid ;-)

 The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
 that are provided to the TDA9988x chip.  On the cubox, I have to adjust
 the mode parameters such that the polarities are fixed up thusly:

 adjusted-flags = ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
  DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
  DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);

 /* The TDA19988 always requires negative VSYNC? */
 adjusted-flags |= DRM_MODE_FLAG_NVSYNC;

 /* The TDA19988 requires positive HSYNC on 1080p or 720p */
 if ((adjusted-hdisplay == 1920  adjusted-vdisplay == 1080) ||
 (adjusted-hdisplay == 1280  adjusted-vdisplay == 720))
 adjusted-flags |= DRM_MODE_FLAG_PHSYNC;
 else
 adjusted-flags |= DRM_MODE_FLAG_NHSYNC;

 return true;

 for these resolutions to be displayed correctly.

 hmm, I didn't come across this.  Although 1080p seems to be a bit more
 than what the little board I'm working on can drive.  I didn't have to
 do any special fixup for 720p..

one thought.. I haven't enabled any hdmi features like audio yet..
which could be a reason that I didn't hit some of these issues.  I'm
not really much of an audio/asoc expert so I'm not really sure how
this should hook in for audio stuff, but if someone out there with
some hw with a similar nxp encoder chip does have some better audio
experience, I'd be interested to work together on that.

BR,
-R

 I wonder if you are having to do that with the nxp out of tree driver?
  Maybe it is related to how that driver it is configuring the hw?  It
 would be interesting if you hit the same issue w/ the i2c encoder
 slave version.

 At any rate, if it turns out to be needed, we can add this in
 tda998x_encoder_mode_fixup().

 Also, when the only output is the HDMI device, reporting the display
 disconnected and without any modes seems to cause problems - I have to
 report unknown status when there's nothing connected, and also provide
 a default (720p) mode when no EDID is received.

 hmm, also did not run into any issues here on my end.  What sort of
 problems did you hit?

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

Re: [PATCH] drm/exynos: add check for the device power status

[Sean Paul]

On Wed, Jan 23, 2013 at 5:10 AM, Shirish S s.shir...@samsung.com wrote:
 The hdmi and mixer win_commit calls currently are
 not checking the status of IP before updating the
 respective registers, this patch adds this check.

 Signed-off-by: Shirish S s.shir...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c  | 3 +++
  drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
  2 files changed, 6 insertions(+)

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 2c46b6c..ae79688 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -2170,6 +2170,9 @@ static void hdmi_commit(void *ctx)

 DRM_DEBUG_KMS([%d] %s\n, __LINE__, __func__);

 +   if (!hdata-powered)

The rest of the driver protects reads  writes to powered with hdmi_mutex

 +   return;
 +
 hdmi_conf_apply(hdata);
  }

 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 21db895..4f5433f 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -775,6 +775,9 @@ static void mixer_win_commit(void *ctx, int win)

 DRM_DEBUG_KMS([%d] %s, win: %d\n, __LINE__, __func__, win);

 +   if (!mixer_ctx-powered)

This is also protected everywhere else in the driver.

 +   return;
 +
 if (win  1  mixer_ctx-vp_enabled)
 vp_video_buffer(mixer_ctx, win);
 else
 --
 1.8.0

 ___
 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: [Linaro-mm-sig] [PATCH 4/7] fence: dma-buf cross-device synchronization (v11)

[Maarten Lankhorst]

Op 22-01-13 16:13, Francesco Lavra schreef:
 Hi,

 On 01/15/2013 01:34 PM, Maarten Lankhorst wrote:
 [...]
 diff --git a/include/linux/fence.h b/include/linux/fence.h
 new file mode 100644
 index 000..d9f091d
 --- /dev/null
 +++ b/include/linux/fence.h
 @@ -0,0 +1,347 @@
 +/*
 + * Fence mechanism for dma-buf to allow for asynchronous dma access
 + *
 + * Copyright (C) 2012 Canonical Ltd
 + * Copyright (C) 2012 Texas Instruments
 + *
 + * Authors:
 + * Rob Clark rob.cl...@linaro.org
 + * Maarten Lankhorst maarten.lankho...@canonical.com
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 as published 
 by
 + * the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but 
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License along 
 with
 + * this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +
 +#ifndef __LINUX_FENCE_H
 +#define __LINUX_FENCE_H
 +
 +#include linux/err.h
 +#include linux/wait.h
 +#include linux/list.h
 +#include linux/bitops.h
 +#include linux/kref.h
 +#include linux/sched.h
 +#include linux/printk.h
 +
 +struct fence;
 +struct fence_ops;
 +struct fence_cb;
 +
 +/**
 + * struct fence - software synchronization primitive
 + * @refcount: refcount for this fence
 + * @ops: fence_ops associated with this fence
 + * @cb_list: list of all callbacks to call
 + * @lock: spin_lock_irqsave used for locking
 + * @priv: fence specific private data
 + * @flags: A mask of FENCE_FLAG_* defined below
 + *
 + * the flags member must be manipulated and read using the appropriate
 + * atomic ops (bit_*), so taking the spinlock will not be needed most
 + * of the time.
 + *
 + * FENCE_FLAG_SIGNALED_BIT - fence is already signaled
 + * FENCE_FLAG_ENABLE_SIGNAL_BIT - enable_signaling might have been called*
 + * FENCE_FLAG_USER_BITS - start of the unused bits, can be used by the
 + * implementer of the fence for its own purposes. Can be used in different
 + * ways by different fence implementers, so do not rely on this.
 + *
 + * *) Since atomic bitops are used, this is not guaranteed to be the case.
 + * Particularly, if the bit was set, but fence_signal was called right
 + * before this bit was set, it would have been able to set the
 + * FENCE_FLAG_SIGNALED_BIT, before enable_signaling was called.
 + * Adding a check for FENCE_FLAG_SIGNALED_BIT after setting
 + * FENCE_FLAG_ENABLE_SIGNAL_BIT closes this race, and makes sure that
 + * after fence_signal was called, any enable_signaling call will have either
 + * been completed, or never called at all.
 + */
 +struct fence {
 +struct kref refcount;
 +const struct fence_ops *ops;
 +struct list_head cb_list;
 +spinlock_t *lock;
 +unsigned context, seqno;
 +unsigned long flags;
 +};
 The documentation above should be updated with the new structure members
 context and seqno.

 +
 +enum fence_flag_bits {
 +FENCE_FLAG_SIGNALED_BIT,
 +FENCE_FLAG_ENABLE_SIGNAL_BIT,
 +FENCE_FLAG_USER_BITS, /* must always be last member */
 +};
 +
 +typedef void (*fence_func_t)(struct fence *fence, struct fence_cb *cb, void 
 *priv);
 +
 +/**
 + * struct fence_cb - callback for fence_add_callback
 + * @func: fence_func_t to call
 + * @priv: value of priv to pass to function
 + *
 + * This struct will be initialized by fence_add_callback, additional
 + * data can be passed along by embedding fence_cb in another struct.
 + */
 +struct fence_cb {
 +struct list_head node;
 +fence_func_t func;
 +void *priv;
 +};
 Documentation should be updated here too.

 +
 +/**
 + * struct fence_ops - operations implemented for fence
 + * @enable_signaling: enable software signaling of fence
 + * @signaled: [optional] peek whether the fence is signaled
 + * @release: [optional] called on destruction of fence
 + *
 + * Notes on enable_signaling:
 + * For fence implementations that have the capability for hw-hw
 + * signaling, they can implement this op to enable the necessary
 + * irqs, or insert commands into cmdstream, etc.  This is called
 + * in the first wait() or add_callback() path to let the fence
 + * implementation know that there is another driver waiting on
 + * the signal (ie. hw-sw case).
 + *
 + * This function can be called called from atomic context, but not
 + * from irq context, so normal spinlocks can be used.
 + *
 + * A return value of false indicates the fence already passed,
 + * or some failure occured that made it impossible to enable
 + * signaling. True indicates succesful enabling.
 + *
 + * Calling fence_signal before enable_signaling is called allows
 + * for a tiny race window in which enable_signaling is called during,
 + * before, or after fence_signal. To fight this, 

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

Seth Forshee seth.fors...@canonical.com changed:

   What|Removed |Added

 CC||seth.fors...@canonical.com

--- Comment #18 from Seth Forshee seth.fors...@canonical.com ---
(In reply to comment #15)
 Ok, this is the apple gmux. The display is connected to the discrete radeon
 GPU and you need to manually switch it over to the igfx (using the mux).
 That it is blank upon booting is because not only is the video muxed, so are
 the control lines which are still being reversed engineered as to how to
 setup the gmux.

I got pointed at this bug since the gmux came up.

Chris: I don't really understand this comment. I can't see that anything is
trying to switch gpus. There are likely problems getting i915 to correctly
detect which outputs are attached since the display is muxed to the radeon at
boot and macs have a bad habit of not supplying VBTs, but i915 still shouldn't
oops (but it sounds like this is fixed?), and radeon should still be able to
drive the panel.

William: I don't think I have a clear handle on the current state of this
problem. Am I correct in understanding that you no longer get the stack trace
on the screen when you boot an i386 kernel, but get a blank screen instead?
Does the behavior change at all in 3.8 based on whether or not you pass
i915.disable=1?

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

[Bug 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #10 from vincent v...@ovi.com ---
Can you test with this new patch ? (Remove the previous one)
It adds dummy export to vs outputs

-- 
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 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #11 from vincent v...@ovi.com ---
Created attachment 73532
  -- https://bugs.freedesktop.org/attachment.cgi?id=73532action=edit
Add dummy vs export

-- 
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/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

[Herton Ronaldo Krzesinski]

On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
 On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
  Actually, the code path affected by your patch is not executed in UMS mode 
  at all. Notice that radeon_cs_parser_fini is only called from 
  radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
  
  The equivalent of the fix you are trying to do is in
  a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is 
  the one used by legacy-CS ioctl), which you should go together 
  with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS 
  fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode.
  
  -- Ilija
 
 Thanks. I will take a look at a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e.
 I sent back-ported ff4bd0827764e10a428a9d39e6814c5478863f94 patch to
 stable and I will back-port and send
 a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e as well.

While at it, also looks like commit
25d8999780f8c1f53928f4a24a09c01550423109 could also be added to stables.
But while looking at it, while the patch itself is correct, I noted that
there is a possibility of double free: if either of the
p-chunks[p-chunk_ib_idx].kpage[] items are non NULL, we will free it in
radeon_cs_parser_init and also when calling one of the fini functions
(radeon_cs_parser_fini or r600_cs_parser_fini). So either we need to set
kpage[n] to NULL after kfree, or just return the error.

 
 -- Shuah

-- 
[]'s
Herton
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] fbcon+i915 locking fixes

[Daniel Vetter]

Hi Dave,

First patch is a resend of Alan's fbcon vs. fb notifier deadlock fix.
Without this lockdep is pretty much useless for debugging drm locking
issues, and it looks like quite a few bootup hangs could be blamed on this
one, too.

Since the fbdev maintainer seems to be awol, please merge this through
your drm tree. I've looked through the patch and the new locking seems to
be sane so feel free to smash a

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

onto it.

2nd patch is a locking bug in the i915 driver with the new kms locking.
Since the bug only happens in your drm-next tree, please apply the patch
there directly.

Thanks, Daniel

Alan Cox (1):
  fb: Rework locking to fix lock ordering on takeover

Daniel Vetter (1):
  drm/i915: fixup crtc locking in intel_release_load_detect_pipe

 drivers/gpu/drm/i915/intel_display.c |1 +
 drivers/tty/vt/vt.c  |   81 ++
 drivers/video/console/fbcon.c|   30 -
 drivers/video/fbmem.c|5 +--
 drivers/video/fbsysfs.c  |3 ++
 include/linux/console.h  |1 +
 6 files changed, 98 insertions(+), 23 deletions(-)

-- 
1.7.10.4

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

[PATCH 1/2] fb: Rework locking to fix lock ordering on takeover

[Daniel Vetter]

From: Alan Cox a...@lxorguk.ukuu.org.uk

Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.

This s partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

Signed-off-by: Alan Cox a...@linux.intel.com
[danvet: Tiny whitespace cleanup.]
Reported-and-tested-by: Hugh Dickins hu...@google.com
Reported-and-tested-by: Sasha Levin levinsasha...@gmail.com
References: https://lkml.org/lkml/2012/10/25/516
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/tty/vt/vt.c   |   81 +++--
 drivers/video/console/fbcon.c |   30 ++-
 drivers/video/fbmem.c |5 +--
 drivers/video/fbsysfs.c   |3 ++
 include/linux/console.h   |1 +
 5 files changed, 97 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8fd8968..a38d9d1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2987,7 +2987,7 @@ int __init vty_init(const struct file_operations 
*console_fops)
 
 static struct class *vtconsole_class;
 
-static int bind_con_driver(const struct consw *csw, int first, int last,
+static int do_bind_con_driver(const struct consw *csw, int first, int last,
   int deflt)
 {
struct module *owner = csw-owner;
@@ -2998,7 +2998,7 @@ static int bind_con_driver(const struct consw *csw, int 
first, int last,
if (!try_module_get(owner))
return -ENODEV;
 
-   console_lock();
+   WARN_CONSOLE_UNLOCKED();
 
/* check if driver is registered */
for (i = 0; i  MAX_NR_CON_DRIVER; i++) {
@@ -3083,11 +3083,22 @@ static int bind_con_driver(const struct consw *csw, int 
first, int last,
 
retval = 0;
 err:
-   console_unlock();
module_put(owner);
return retval;
 };
 
+
+static int bind_con_driver(const struct consw *csw, int first, int last,
+  int deflt)
+{
+   int ret;
+
+   console_lock();
+   ret = do_bind_con_driver(csw, first, last, deflt);
+   console_unlock();
+   return ret;
+}
+
 #ifdef CONFIG_VT_HW_CONSOLE_BINDING
 static int con_is_graphics(const struct consw *csw, int first, int last)
 {
@@ -3199,9 +3210,9 @@ int unbind_con_driver(const struct consw *csw, int first, 
int last, int deflt)
if (!con_is_bound(csw))
con_driver-flag = ~CON_DRIVER_FLAG_INIT;
 
-   console_unlock();
/* ignore return value, binding should not fail */
-   bind_con_driver(defcsw, first, last, deflt);
+   do_bind_con_driver(defcsw, first, last, deflt);
+   console_unlock();
 err:
module_put(owner);
return retval;
@@ -3492,28 +3503,18 @@ int con_debug_leave(void)
 }
 EXPORT_SYMBOL_GPL(con_debug_leave);
 
-/**
- * register_con_driver - register console driver to console layer
- * @csw: console driver
- * @first: the first console to take over, minimum value is 0
- * @last: the last console to take over, maximum value is MAX_NR_CONSOLES -1
- *
- * DESCRIPTION: This function registers a console driver which can later
- * bind to a range of consoles specified by @first and @last. It will
- * also initialize the console driver by calling con_startup().
- */
-int register_con_driver(const struct consw *csw, int first, int last)
+static int do_register_con_driver(const struct consw *csw, int first, int last)
 {
struct module *owner = csw-owner;
struct con_driver *con_driver;
const char *desc;
int i, retval = 0;
 
+   WARN_CONSOLE_UNLOCKED();
+
if (!try_module_get(owner))
return -ENODEV;
 
-   console_lock();
-
for (i = 0; i  MAX_NR_CON_DRIVER; i++) {
con_driver = registered_con_driver[i];
 
@@ -3566,10 +3567,29 @@ int register_con_driver(const struct consw *csw, int 
first, int last)
}
 
 err:
-   console_unlock();
module_put(owner);
return retval;
 }
+
+/**
+ * register_con_driver - register console driver to console layer
+ * @csw: console driver
+ * @first: the first console to take over, minimum value is 0
+ * @last: the last console to take over, maximum value is MAX_NR_CONSOLES -1
+ *
+ * DESCRIPTION: This function registers a console driver which can later
+ * bind to a range of consoles specified by @first and @last. It will
+ * also initialize the console driver by calling con_startup().
+ */
+int register_con_driver(const struct consw *csw, int first, int last)
+{
+   int retval;
+
+   console_lock();
+   retval = do_register_con_driver(csw, first, last);
+   console_unlock();
+   return retval;
+}
 EXPORT_SYMBOL(register_con_driver);
 
 /**
@@ -3625,6 +3645,29 @@ EXPORT_SYMBOL(unregister_con_driver);
  *
  *  take_over_console is basically a register followed by unbind
  */
+int do_take_over_console(const struct consw *csw, int first, int last, int 

[PATCH 2/2] drm/i915: fixup per-crtc locking in intel_release_load_detect_pipe

[Daniel Vetter]

One of the early return cases missed the mutex unlocking. Hilarity
ensued.

This regression has been introduced in

commit 7b24056be6db7ce907baffdd4cf142ab774ea60c
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Wed Dec 12 00:35:33 2012 +0100

drm: don't hold crtc mutexes for connector -detect callbacks

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59750
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_display.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 26df9e3..ece4afd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6522,6 +6522,7 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
drm_framebuffer_unreference(old-release_fb);
}
 
+   mutex_unlock(crtc-mutex);
return;
}
 
-- 
1.7.10.4

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

Re: [PATCH 1/2] fb: Rework locking to fix lock ordering on takeover

[Takashi Iwai]

At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
 
 From: Alan Cox a...@lxorguk.ukuu.org.uk
 
 Adjust the console layer to allow a take over call where the caller already
 holds the locks. Make the fb layer lock in order.
 
 This s partly a band aid, the fb layer is terminally confused about the
 locking rules it uses for its notifiers it seems.
 
 Signed-off-by: Alan Cox a...@linux.intel.com
 [danvet: Tiny whitespace cleanup.]
 Reported-and-tested-by: Hugh Dickins hu...@google.com
 Reported-and-tested-by: Sasha Levin levinsasha...@gmail.com
 References: https://lkml.org/lkml/2012/10/25/516
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

FYI, the latest patch of this is found in mm tree:
  
http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch

Also I hit the same problem in another code paths (for unbind and
unregister):
  http://marc.info/?t=13530939643r=1w=2

My additional patch is found in mm tree, too:
  
http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch


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

[Bug 43751] [TTM] Out of kernel memory

[bugzilla-daemon]

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


am.de...@gmail.com changed:

   What|Removed |Added

 CC||am.de...@gmail.com




--- Comment #7 from am.de...@gmail.com  2013-01-23 17:02:02 ---
Has this been resolved? I'm using 3.4.20 and I see this issue every time.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

--- Comment #19 from William k...@cobradevil.org ---
Hi Seth,

i have been testing with raring using 3.8 kernel.

On 64 bit kernel i get a console screen using the i915.disable=1 but not on the
32bit kernel. see also the dmesg files attached.

When using the 3.5 kernel from quantal i get an oops with a 32bit kernel but
not when i use the option i915.i915_enable_ppgtt=0 but then i still have a
blank screen.

-- 
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/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()

[Herton Ronaldo Krzesinski]

On Wed, Jan 23, 2013 at 12:21:29PM -0500, Ilija Hadzic wrote:
 On Wed, Jan 23, 2013 at 11:07 AM, Herton Ronaldo Krzesinski
 herton.krzesin...@canonical.com wrote:
  On Thu, Jan 17, 2013 at 10:09:42AM -0700, Shuah Khan wrote:
  On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote:
   Actually, the code path affected by your patch is not executed in UMS 
   mode
   at all. Notice that radeon_cs_parser_fini is only called from
   radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c).
  
   The equivalent of the fix you are trying to do is in
   a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is
   the one used by legacy-CS ioctl), which you should go together
   with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS
   fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode.
  
   -- Ilija
 
  Thanks. I will take a look at a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e.
  I sent back-ported ff4bd0827764e10a428a9d39e6814c5478863f94 patch to
  stable and I will back-port and send
  a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e as well.
 
  While at it, also looks like commit
  25d8999780f8c1f53928f4a24a09c01550423109 could also be added to stables.
  But while looking at it, while the patch itself is correct, I noted that
  there is a possibility of double free: if either of the
  p-chunks[p-chunk_ib_idx].kpage[] items are non NULL, we will free it in
  radeon_cs_parser_init and also when calling one of the fini functions
  (radeon_cs_parser_fini or r600_cs_parser_fini). So either we need to set
  kpage[n] to NULL after kfree, or just return the error.
 
 
 Yes you are right. The error-handling path should force both kpage[]
 pointers to NULL before returning -ENOMEM. That would fix the double
 free.
 
 Regarding, inclusion of 25d8999780f8c1f53928f4a24a09c01550423109 into
 stable (and possible follow-up patch to fix potential double-kfree),
 does this pass the no fixes for theoretical problems in stable
 criterion ?
 
 It is an obvious bug, but it happens so rarely that I am not surprised
 that it has never happened: You need an (old) AGP card *and* you need
 to run out of kmalloc memory.

About the theoretical problem criteria, I think it applies more to
race conditions not detected in practice, things that are not obvious/
deterministic etc., but indeed commit 25d89997 looks not be worth to be
added on stables.

 
 -- Ilija
 

-- 
[]'s
Herton
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

--- Comment #20 from Seth Forshee seth.fors...@canonical.com ---
Okay, thanks.

I suspect at least part of the problem may be related to efifb. I don't see
that it's being used on your machine, and I note that it has a bunch of quirks
for making it work with various Mac hardware. If we add a quirk for your
machine efifb should then be able to identify the radeon as the default vga
device and use it for the console framebuffer. I'm guessing this won't fix the
problem with the 32-bit builds, but it should at least remove the need for
i915.disable=1 with the 64-bit build.

To make a patch I'll need some DMI information for your machine. Could you send
me the output from the following commands?

 dmidecode -s bios-vendor
 dmidecode -s system-product-name

-- 
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 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

--- Comment #21 from William k...@cobradevil.org ---
Hi Seth,

the output is:
bios vendor: Apple Inc.
system product name: iMac12,1

Could that also explain why X is not 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

[PATCH] drm/radeon: fix a rare case of double kfree

[Ilija Hadzic]

If one (but not both) allocations of p-chunks[].kpage[]
in radeon_cs_parser_init fail, the error path will free
the successfully allocated page, but leave a stale pointer
value in the kpage[] field. This will later cause a
double-free when radeon_cs_parser_fini is called.
This patch fixes the issue by forcing both pointers to NULL
after kfree in the error path.

The circumstances under which the problem happens are very
rare. The card must be AGP and the system must run out of
kmalloc area just at the right time so that one allocation
succeeds, while the other fails.

Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
Cc: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
---
 drivers/gpu/drm/radeon/radeon_cs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 469661f..5407459 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -286,6 +286,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void 
*data)
p-chunks[p-chunk_ib_idx].kpage[1] == NULL) {
kfree(p-chunks[p-chunk_ib_idx].kpage[0]);
kfree(p-chunks[p-chunk_ib_idx].kpage[1]);
+   p-chunks[p-chunk_ib_idx].kpage[0] = NULL;
+   p-chunks[p-chunk_ib_idx].kpage[1] = NULL;
return -ENOMEM;
}
}
-- 
1.8.1

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

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

--- Comment #22 from Seth Forshee seth.fors...@canonical.com ---
(In reply to comment #21)
 Hi Seth,
 
 the output is:
 bios vendor: Apple Inc.
 system product name: iMac12,1

Rats, it turns out there's more information required. If you can boot into OS X
and run the following command in a terminal, it's supposed to give all the
required information.

sudo ioreg -lw0 |grep manufacturer|cut -b25-80;sudo ioreg -lw0|grep
product-name|cut -b 25-80;sudo dtrace -qn 'BEGIN{boot_args=((struct
boot_args*)(`PE_state).bootArgs);printf(FrameBuff erBase:
0x%08x\nPixelsPerScanLine: %d\nHorizontalResolution: %d\nVerticalResolution:
%d, boot_args-Video.v_baseAddr, boot_args-Video.v_rowBytes/4,
boot_args-Video.v_width, boot_args-Video.v_height);exit(0)} '

 Could that also explain why X is not working?

I don't know much at all about X, but I suspect it might be at least
contributing. Maybe X is also trying to use the Intel graphics based on the
same information.

-- 
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/radeon: fix a rare case of double kfree

[Alex Deucher]

On Wed, Jan 23, 2013 at 1:59 PM, Ilija Hadzic
ihad...@research.bell-labs.com wrote:
 If one (but not both) allocations of p-chunks[].kpage[]
 in radeon_cs_parser_init fail, the error path will free
 the successfully allocated page, but leave a stale pointer
 value in the kpage[] field. This will later cause a
 double-free when radeon_cs_parser_fini is called.
 This patch fixes the issue by forcing both pointers to NULL
 after kfree in the error path.

 The circumstances under which the problem happens are very
 rare. The card must be AGP and the system must run out of
 kmalloc area just at the right time so that one allocation
 succeeds, while the other fails.

 Signed-off-by: Ilija Hadzic ihad...@research.bell-labs.com
 Cc: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com

Thanks, Added to my -fixes queue.

Alex

 ---
  drivers/gpu/drm/radeon/radeon_cs.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 469661f..5407459 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -286,6 +286,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
 void *data)
 p-chunks[p-chunk_ib_idx].kpage[1] == NULL) {
 kfree(p-chunks[p-chunk_ib_idx].kpage[0]);
 kfree(p-chunks[p-chunk_ib_idx].kpage[1]);
 +   p-chunks[p-chunk_ib_idx].kpage[0] = NULL;
 +   p-chunks[p-chunk_ib_idx].kpage[1] = NULL;
 return -ENOMEM;
 }
 }
 --
 1.8.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

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

--- Comment #23 from William k...@cobradevil.org ---
Here the information from the output:

 Apple Inc.
 iMac12,1
FrameBuff erBase: 0x9001
PixelsPerScanLine: 1920
HorizontalResolution: 1920
VerticalResolution: 1080

-- 
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 59588] llvm rv790 etqw gpu lock since r600g/llvm: tgsi to llvm emits store.swizzle intrinsic for vs/fs output

[bugzilla-daemon]

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

--- Comment #12 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #10)
 Can you test with this new patch ? (Remove the previous one)
 It adds dummy export to vs outputs

It works OK with the new patch.

-- 
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 59431] [snb efi gmux] imac 12,1 blank screen upon booting

[bugzilla-daemon]

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

--- Comment #24 from Seth Forshee seth.fors...@canonical.com ---
Created attachment 73542
  -- https://bugs.freedesktop.org/attachment.cgi?id=73542action=edit
Add quirk to efifb for iMac 12,1

Here's a patch to try. But after some more poking around I'm wondering why this
is needed. The kernel seems to get the information about the GOP framebuffer
for most recent Macs without quirking, so it makes me wonder why it doesn't
work on this machine.

Just to check one obvious point, are you either running with the stock Ubuntu
kernels or else with CONFIG_FB_EFI=y? An easy way to verify this is to boot the
machine and run 'grep CONFIG_FB_EFI /boot/config-$(uname -r)'. This should
output 'CONFIG_FB_EFI=y' if your kernel is configured to include the EFI
framebuffer support.

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