[Bug 40211] texture probleme in wolfenstein enemy territory rv770

2012-10-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=40211

pitamila at free.fr changed:

   What|Removed |Added

Version|7.10|8.0

--- Comment #9 from pitamila at free.fr ---
Hi,

I updated my Debian Sid distro to mesa 8.0.4
unfortunately, Enemy Territory continue to have
- texture blinking
- error in drawing landscapes (I can see thru the walls)
- many objects (all the screen when enterring limbo menu)
appearing only a fraction of second then disappearing

Tell me if I can do any testing or provide some more log
to help diagnose the pb.

-- 
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/20121009/68edf543/attachment.html>


[Bug 40211] texture probleme in wolfenstein enemy territory rv770

2012-10-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=40211

pitamila at free.fr changed:

   What|Removed |Added

  Attachment #50399|0   |1
is obsolete||

--- Comment #8 from pitamila at free.fr ---
Created attachment 68363
  --> https://bugs.freedesktop.org/attachment.cgi?id=68363=edit
my glxinfo output with mesa 8.0.4

-- 
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/20121009/1adb211c/attachment.html>


[Bug 55819] Mouse cursor corruption when moving between monitors

2012-10-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=55819

Alex Deucher  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #5 from Alex Deucher  ---
What kernel are you using?  Make sure it has this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f60ec4c7df043df81e62891ac45383d012afe0da

-- 
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/20121009/7628903b/attachment.html>


[PATCH] drm/omap: fix allocation size for page addresses array

2012-10-09 Thread Vincent Penquerc'h
Signed-off-by: Rob Clark 
Signed-off-by: Vincent Penquerc'h 
---
 drivers/staging/omapdrm/omap_gem.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index c828743..4c1472c 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 * DSS, GPU, etc. are not cache coherent:
 */
if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-   addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
@@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
}
} else {
-   addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
-- 
1.7.9.5



[PATCH] drm: avoid passing null pointer to memset

2012-10-09 Thread Chris Wilson
On Tue,  9 Oct 2012 14:50:46 -0300, Rodrigo Vivi  
wrote:
> When cmd isn't IOC_IN | IOC_OUT a null "kdata" goes to "memset", which 
> dereferences it.
> 
usize should be 0 in that case, since the ioctl is neither copying data
in or out, for example I915_GEM_THROTTLE. To be on the safe side:
if (IOC_IN | IOC_OUT) { /* blah */ } else usize = 0;
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[PATCH] Fix calculation of memory needed for page handles

2012-10-09 Thread Vincent Penquerc'h
Hi,

Wrong sizeof used, fixed in attached patch, and below.


>From 7f430a4104bee5f75929580a66128b7b0e2859d9 Mon Sep 17 00:00:00 2001
From: Vincent Penquerc'h <vincent.penque...@collabora.co.uk>
Date: Tue, 9 Oct 2012 17:18:33 +0100
Subject: [PATCH] drm/omap: fix allocation size for page addresses array

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_gem.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index c828743..4c1472c 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct
drm_gem_object *obj)
 * DSS, GPU, etc. are not cache coherent:
 */
if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-   addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
@@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct
drm_gem_object *obj)
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
}
} else {
-   addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
-- 
1.7.9.5
-- next part --
A non-text attachment was scrubbed...
Name: 0001-omap_gem-fix-incorrect-allocation-size-for-page-addr.patch
Type: text/x-patch
Size: 1153 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/33ce3b0c/attachment.bin>


Update on the CEC API

2012-10-09 Thread Mauro Carvalho Chehab
Em Mon, 08 Oct 2012 19:45:14 +0200
Florian Fainelli  escreveu:

> On Monday 08 October 2012 17:49:00 Hans Verkuil wrote:
> > On Mon October 8 2012 17:06:20 Florian Fainelli wrote:
> > > Hi Hans,
> > > 
> > > On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
> > > > Hi all,
> > > > 
> > > > During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) 
> > > > had a
> > > > discussion on how to handle the CEC protocol that's part of the HDMI 
> > > standard.
> > > > 
> > > > The decision was made to create a CEC bus with CEC clients, each 
> > > > represented
> > > > by a /dev/cecX device. So this is independent of the V4L or DRM APIs. 
> > > > 
> > > > In addition interested subsystems (alsa for the Audio Return Channel, 
> > > > and
> > > > possibly networking as well for ethernet over HDMI) can intercept/send 
> > > > CEC
> > > > messages as well if needed. Particularly for the CEC additions made in
> > > > HDMI 1.4a it is no longer possible to handle the CEC protocol 
> > > > completely in
> > > > userspace, but part of the intelligence has to be moved to kernelspace.

...

> > Also remote control messages might optionally be handled through an input 
> > driver.
> 
> Ok, then maybe just stick to the standard CEC_UI_* key codes, and let people
> having proprietary UI functions do the rest in user-space, or write their own
> input driver.

No. The RC core already provides standard ways for userspace to read/add/replace
the scancode -> Linux keycode using the standard Kernel mechanisms for that.

All it is needed is to use an userspace program for that (with already exists).
So, there's absolutely no need for per-vendor kernelspace/userspace drivers.

The RC core also allows sending remote controller keystrokes. The userspace API
currently works only with IR raw codes. There are, however, discussions and some
RFC patches proposing some changes there to also accept scancodes (and/or 
Linux keycodes) to be passed for the Remote Controller TX drivers.

So, from remote controller standpoint, just one driver will be enough to handle 
HDMI CEC.

Regards,
Mauro


[PATCH] drm: avoid passing null pointer to memset

2012-10-09 Thread Rodrigo Vivi
When cmd isn't IOC_IN | IOC_OUT a null "kdata" goes to "memset", which 
dereferences it.

v2: simpler version just using usize = 0 instead of allocating useless memory

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 1490e76..f72dce5 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -444,7 +444,8 @@ long drm_ioctl(struct file *filp,
}
if (asize > usize)
memset(kdata + usize, 0, asize - usize);
-   }
+   } else
+   usize = 0;

if (cmd & IOC_IN) {
if (copy_from_user(kdata, (void __user *)arg,
-- 
1.7.11.4



[PATCH v5 1/3] drm: Add user-defined EDID quirks capability

2012-10-09 Thread Jani Nikula
On Fri, 28 Sep 2012, Ian Pilcher  wrote:
> Add the ability for users to define their own EDID quirks via a
> module parameter or sysfs attribute.

Hi Ian -

IMHO this patch should be chopped up to smaller pieces. For example,
change the edid_quirk_list format first (if you must), then add module
parameter support, then add sysfs support, in separate patches. It'll be
easier to review.

Please see some other comments inline.

BR,
Jani.

>
> Signed-off-by: Ian Pilcher 
> ---
>  Documentation/EDID/edid_quirks.txt | 126 ++
>  drivers/gpu/drm/drm_drv.c  |   2 +
>  drivers/gpu/drm/drm_edid.c | 500 
> -
>  drivers/gpu/drm/drm_stub.c |   6 +
>  drivers/gpu/drm/drm_sysfs.c|  19 ++
>  include/drm/drmP.h |  10 +
>  include/drm/drm_edid.h |  13 +-
>  7 files changed, 615 insertions(+), 61 deletions(-)
>  create mode 100644 Documentation/EDID/edid_quirks.txt
>
> diff --git a/Documentation/EDID/edid_quirks.txt 
> b/Documentation/EDID/edid_quirks.txt
> new file mode 100644
> index 000..0c9c746
> --- /dev/null
> +++ b/Documentation/EDID/edid_quirks.txt
> @@ -0,0 +1,126 @@
> +  EDID Quirks
> + =
> +   Ian Pilcher 
> +August 11, 2012
> +
> +
> +"EDID blocks out in the wild have a variety of bugs"
> +-- from drivers/gpu/drm/drm_edid.c
> +
> +
> +Overview
> +
> +
> +EDID quirks provide a mechanism for working around display hardware with 
> buggy
> +EDID data.
> +
> +An individual EDID quirk maps a display type (identified by its EDID
> +manufacturer ID and product code[1]) to a set of "quirk flags."  The kernel
> +includes a variety of built-in quirks.  (They are stored in the 
> edid_quirk_list
> +array in drivers/gpu/drm/drm_edid.c.)
> +
> +An example of a built-in EDID quirk is:
> +
> +ACR:0xad46:0x0001
> +
> +The first field is the manufacturer ID (Acer, Inc.), the second field is the
> +manufacturer's product code, and the third field contains the quirk flags for
> +that display type.
> +
> +The quirk flags are defined in drivers/gpu/drm/drm_edid.c.  Each flag has a
> +symbolic name beginning with EDID_QUIRK_, along with a numerical value.  Each
> +flag should also have an associated comment which provides an idea of its
> +effect.  Note that the values in the source file are expressed as bit 
> shifts[2]:
> +
> +* 1 << 0: 0x0001
> +* 1 << 1: 0x0002
> +* 1 << 2: 0x0004
> +* etc.
> +
> +
> +sysfs interface
> +===
> +
> +The current EDID quirk list can be read from /sys/class/drm/edid_quirks:
> +
> +# cat /sys/class/drm/edid_quirks
> +   ACR:0xad46:0x0001
> +   API:0x7602:0x0001
> +   ACR:0x0977:0x0020
> +0x9e6a:0x077e:0x0080
> +...
> +
> +("Nonconformant" manufacturer IDs are displayed as hexadecimal values.)
> +
> +The number of total "slots" in the list can be read from
> +/sys/class/drm/edid_quirks_size.  This total includes both occupied slots 
> (i.e.
> +the current list) and any slots available for additional quirks.  The number 
> of
> +available slots can be calculated by subtracting the number of quirks in the
> +current list from the total number of slots.
> +
> +If a slot is available, an additional quirk can be added to the list by 
> writing
> +it to /sys/class/drm/edid_quirks:
> +
> +# echo FOO:0x:0x100 > /sys/class/drm/edid_quirks
> +
> +Manufacturer IDs can also be specified numerically.  (This is the only way to
> +specify a nonconformant ID.) This command is equivalent to the previous one:
> +
> +# echo 0x19ef:0x:0x100 > /sys/class/drm/edid_quirks
> +
> +Numeric values can also be specified in decimal or octal formats; a number 
> that
> +begins with a 0 is assumed to be octal:
> +
> +# echo FOO:65535:0400 > /sys/class/drm/edid_quirks
> +
> +An existing quirk can be replaced by writing a new set of flags:
> +
> +# echo FOO:0x:0x200 > /sys/class/drm/edid_quirks
> +
> +A quirk can be deleted from the list by writing an empty flag set (0). This
> +makes the slot occupied by that quirk available.
> +
> +# echo FOO:0x:0 > /sys/class/drm/edid_quirks
> +
> +Writing an "at symbol" (@) clears the entire quirk list:
> +
> +# echo @ > /sys/class/drm/edid_quirks
> +
> +Multiple changes to the list can be specified in a comma (or newline) 
> separated
> +list. For example, the following command clears all of the existing quirks in
> +the list and adds 3 new quirks:
> +
> +# echo @,FOO:0x:0x100,BAR:0x:0x001,BAZ:0x:0x002 > \
> +/sys/class/drm/edid_quirks
> +
> +Note however, that any error (an incorrectly formatted quirk or an attempt to
> +add a quirk when no slot is available) will abort processing of any further
> +changes, potentially making it difficult to determine exactly which change
> +caused the error and what 

[PATCH] drm: avoid passing null pointer to memset

2012-10-09 Thread Rodrigo Vivi
When cmd isn't IOC_IN | IOC_OUT a null "kdata" goes to "memset", which 
dereferences it.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_drv.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 1490e76..5945920 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -452,8 +452,16 @@ long drm_ioctl(struct file *filp,
retcode = -EFAULT;
goto err_i1;
}
-   } else
+   } else {
+   if (!kdata) {
+   kdata = kmalloc(usize, GFP_KERNEL);
+   if (!kdata) {
+   retcode = -ENOMEM;
+   goto err_i1;
+   }
+   }
memset(kdata, 0, usize);
+   }

if (ioctl->flags & DRM_UNLOCKED)
retcode = func(dev, kdata, file_priv);
-- 
1.7.11.4



[Bug 55809] omap_drm: fix locking bug on error path

2012-10-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=55809

Rob Clark  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |rob at ti.com
   |.org|

-- 
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/20121009/718b92af/attachment.html>


[Bug 55809] New: omap_drm: fix locking bug on error path

2012-10-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=55809

  Priority: medium
Bug ID: 55809
  Assignee: dri-devel at lists.freedesktop.org
   Summary: omap_drm: fix locking bug on error path
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: vincent at collabora.co.uk
  Hardware: ARM
Status: NEW
   Version: XOrg CVS
 Component: libdrm
   Product: DRI

Created attachment 68338
  --> https://bugs.freedesktop.org/attachment.cgi?id=68338=edit
Fix for locking bug on error paths

omap_drm.c has a couple places where a lock is not released on an error path,
but should be.

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


[PATCH 00/11] page-flip cleanups and fixes

2012-10-09 Thread Inki Dae
2012/10/9 Rob Clark :
> From: Rob Clark 
>
> Add a helper fxn to send vblank event after pageflip, plus a handful
> of fixes for other issues that I noticed in the process.
>

patches 1, 5 and 6  are:
Reviewed-by: Inki Dae 


[PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2

2012-10-09 Thread Michel Dänzer
On Die, 2012-10-09 at 13:31 +0200, Christian K?nig wrote: 
> We want to use VMs without the IB pool in the future.
> 
> v2: also remove it from radeon_vm_finish.
> 
> Signed-off-by: Christian K?nig 

Reviewed-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer


[PATCH 3/3] drm/radeon: separate pt alloc from lru add

2012-10-09 Thread Christian König
Make it possible to allocate a persistent page table.

Signed-off-by: Christian K?nig 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon.h  |1 +
 drivers/gpu/drm/radeon/radeon_cs.c   |1 +
 drivers/gpu/drm/radeon/radeon_gart.c |   20 
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 54cf9b5..8c42d54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1851,6 +1851,7 @@ void radeon_vm_manager_fini(struct radeon_device *rdev);
 void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
 void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
 int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
+void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm);
 struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
   struct radeon_vm *vm, int ring);
 void radeon_vm_fence(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index d59eb59..023c67d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -478,6 +478,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
}

 out:
+   radeon_vm_add_to_lru(rdev, vm);
mutex_unlock(>mutex);
mutex_unlock(>vm_manager.lock);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 80f0331..08e0ddc 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -617,9 +617,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct 
radeon_vm *vm)
}

if (vm->page_directory != NULL) {
-   /* update lru */
-   list_del_init(>list);
-   list_add_tail(>list, >vm_manager.lru_vm);
return 0;
}

@@ -653,11 +650,26 @@ retry:
return -ENOMEM;
}

-   list_add_tail(>list, >vm_manager.lru_vm);
return 0;
 }

 /**
+ * radeon_vm_add_to_lru - add VMs page table to LRU list
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to add to LRU
+ *
+ * Add the allocated page table to the LRU list (cayman+).
+ *
+ * Global mutex must be locked!
+ */
+void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm)
+{
+   list_del_init(>list);
+   list_add_tail(>list, >vm_manager.lru_vm);
+}
+
+/**
  * radeon_vm_grab_id - allocate the next free VMID
  *
  * @rdev: radeon_device pointer
-- 
1.7.9.5



[PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2

2012-10-09 Thread Christian König
We want to use VMs without the IB pool in the future.

v2: also remove it from radeon_vm_finish.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h  |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c |   34 +++---
 drivers/gpu/drm/radeon/radeon_kms.c  |   22 +-
 3 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index bc6b56b..54cf9b5 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1848,7 +1848,7 @@ extern void radeon_ttm_set_active_vram_size(struct 
radeon_device *rdev, u64 size
  */
 int radeon_vm_manager_init(struct radeon_device *rdev);
 void radeon_vm_manager_fini(struct radeon_device *rdev);
-int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
+void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
 void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
 int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
 struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index b36b615..80f0331 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -602,7 +602,6 @@ int radeon_vm_evict(struct radeon_device *rdev, struct 
radeon_vm *vm)
  * @vm: vm to bind
  *
  * Allocate a page table for the requested vm (cayman+).
- * Also starts to populate the page table.
  * Returns 0 for success, error for failure.
  *
  * Global and local mutex must be locked!
@@ -655,8 +654,7 @@ retry:
}

list_add_tail(>list, >vm_manager.lru_vm);
-   return radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo,
-  >ring_tmp_bo.bo->tbo.mem);
+   return 0;
 }

 /**
@@ -1241,30 +1239,15 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,
  * @rdev: radeon_device pointer
  * @vm: requested vm
  *
- * Init @vm (cayman+).
- * Map the IB pool and any other shared objects into the VM
- * by default as it's used by all VMs.
- * Returns 0 for success, error for failure.
+ * Init @vm fields (cayman+).
  */
-int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm)
+void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm)
 {
-   struct radeon_bo_va *bo_va;
-   int r;
-
vm->id = 0;
vm->fence = NULL;
mutex_init(>mutex);
INIT_LIST_HEAD(>list);
INIT_LIST_HEAD(>va);
-
-   /* map the ib pool buffer at 0 in virtual address space, set
-* read only
-*/
-   bo_va = radeon_vm_bo_add(rdev, vm, rdev->ring_tmp_bo.bo);
-   r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET,
- RADEON_VM_PAGE_READABLE |
- RADEON_VM_PAGE_SNOOPED);
-   return r;
 }

 /**
@@ -1286,17 +1269,6 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
radeon_vm_free_pt(rdev, vm);
mutex_unlock(>vm_manager.lock);

-   /* remove all bo at this point non are busy any more because unbind
-* waited for the last vm fence to signal
-*/
-   r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
-   if (!r) {
-   bo_va = radeon_vm_bo_find(vm, rdev->ring_tmp_bo.bo);
-   list_del_init(_va->bo_list);
-   list_del_init(_va->vm_list);
-   radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
-   kfree(bo_va);
-   }
if (!list_empty(>va)) {
dev_err(rdev->dev, "still active bo inside vm\n");
}
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index cb8e94d..c97d49b 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -420,6 +420,7 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
/* new gpu have virtual address space support */
if (rdev->family >= CHIP_CAYMAN) {
struct radeon_fpriv *fpriv;
+   struct radeon_bo_va *bo_va;
int r;

fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
@@ -427,7 +428,15 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
return -ENOMEM;
}

-   r = radeon_vm_init(rdev, >vm);
+   radeon_vm_init(rdev, >vm);
+
+   /* map the ib pool buffer read only into
+* virtual address space */
+   bo_va = radeon_vm_bo_add(rdev, >vm,
+rdev->ring_tmp_bo.bo);
+   r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET,
+ RADEON_VM_PAGE_READABLE |
+ RADEON_VM_PAGE_SNOOPED);
 

[PATCH 1/3] drm/radeon: allocate page tables on demand v4

2012-10-09 Thread Christian König
Based on Dmitries work, but splitting the code into page
directory and page table handling makes it far more
readable and (hopefully) more reliable.

Allocations of page tables are made from the SA on demand,
that should still work fine since all page tables are of
the same size.

Also using the fact that allocations from the SA are mostly
continuously (except for end of buffer wraps and under very
high memory pressure) to group updates send to the chipset
specific code into larger chunks.

v3: mostly a rewrite of Dmitries previous patch.
v4: fix some typos and coding style

Signed-off-by: Dmitry Cherkasov 
Signed-off-by: Christian K?nig 
Tested-by: Michel D?nzer 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ni.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h  |   11 +-
 drivers/gpu/drm/radeon/radeon_gart.c |  322 ++
 3 files changed, 262 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9a46f7d..48e2337 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1576,7 +1576,7 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
radeon_ring_write(ring, 0);

radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + 
(vm->id << 2), 0));
-   radeon_ring_write(ring, vm->last_pfn);
+   radeon_ring_write(ring, rdev->vm_manager.max_pfn);

radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm->id << 2), 0));
radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b04c064..bc6b56b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -663,9 +663,14 @@ struct radeon_vm {
struct list_headlist;
struct list_headva;
unsignedid;
-   unsignedlast_pfn;
-   u64 pd_gpu_addr;
-   struct radeon_sa_bo *sa_bo;
+
+   /* contains the page directory */
+   struct radeon_sa_bo *page_directory;
+   uint64_tpd_gpu_addr;
+
+   /* array of page tables, one for each page directory entry */
+   struct radeon_sa_bo **page_tables;
+
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 753b7ca..b36b615 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -423,6 +423,18 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */

 /**
+ * radeon_vm_num_pde - return the number of page directory entries
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Calculate the number of page directory entries (cayman+).
+ */
+static unsigned radeon_vm_num_pdes(struct radeon_device *rdev)
+{
+   return rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE;
+}
+
+/**
  * radeon_vm_directory_size - returns the size of the page directory in bytes
  *
  * @rdev: radeon_device pointer
@@ -431,7 +443,7 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */
 static unsigned radeon_vm_directory_size(struct radeon_device *rdev)
 {
-   return (rdev->vm_manager.max_pfn >> RADEON_VM_BLOCK_SIZE) * 8;
+   return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8);
 }

 /**
@@ -451,11 +463,11 @@ int radeon_vm_manager_init(struct radeon_device *rdev)

if (!rdev->vm_manager.enabled) {
/* allocate enough for 2 full VM pts */
-   size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
-   size += RADEON_GPU_PAGE_ALIGN(rdev->vm_manager.max_pfn * 8);
+   size = radeon_vm_directory_size(rdev);
+   size += rdev->vm_manager.max_pfn * 8;
size *= 2;
r = radeon_sa_bo_manager_init(rdev, 
>vm_manager.sa_manager,
- size,
+ RADEON_GPU_PAGE_ALIGN(size),
  RADEON_GEM_DOMAIN_VRAM);
if (r) {
dev_err(rdev->dev, "failed to allocate vm bo (%dKB)\n",
@@ -476,7 +488,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)

/* restore page table */
list_for_each_entry(vm, >vm_manager.lru_vm, list) {
-   if (vm->sa_bo == NULL)
+   if (vm->page_directory == NULL)
continue;

list_for_each_entry(bo_va, >va, vm_list) {
@@ -500,16 +512,25 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
 {
struct radeon_bo_va *bo_va;
+   int i;

-   if (!vm->sa_bo)
+   if (!vm->page_directory)
   

[RFC 1/4] time: export getnstime_raw_and_real for DRM

2012-10-09 Thread Imre Deak
On Fri, 2012-10-05 at 12:14 -0400, Kristian H?gsberg wrote:
> On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak  wrote:
> > Needed by the upcoming DRM raw monotonic timestamp support.
> 
> I just had a quick look at driver/input/evdev.c, since evdev devices
> did a similar change recently to allow evdev timestamp from the
> monotonic clock.  They're using a different time API:
> 
>   time_mono = ktime_get();
> time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());
> 
> and
> 
> event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ?
>   mono : real);
> 
> I'm not really up-to-date on kernel time APIs, but I wonder if that
> may be better?  At least, I suspect we wouldn't need changes outside
> drm if we use this API.


Thanks, I will use this instead of getnstime_raw_and_real.

The reason is as discussed on #intel-gfx that this provides a monotonic
vs. raw monotonic time and that as you say it won't require a change in
the time keeping code.

--Imre

> 
> Kristian
> 
> 
> > Signed-off-by: Imre Deak 
> > ---
> >  kernel/time/timekeeping.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> > index d3b91e7..073d262 100644
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > @@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts)
> >  }
> >  EXPORT_SYMBOL_GPL(ktime_get_ts);
> >
> > -#ifdef CONFIG_NTP_PPS
> > +#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || 
> > defined(CONFIG_DRM_MODULE)
> >
> >  /**
> >   * getnstime_raw_and_real - get day and raw monotonic time in timespec 
> > format
> > --
> > 1.7.9.5
> >




[PATCH] drm/omap: fix allocation size for page addresses array

2012-10-09 Thread Vincent Penquerc'h
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_gem.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index c828743..4c1472c 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 * DSS, GPU, etc. are not cache coherent:
 */
if (omap_obj->flags & (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-   addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
@@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
}
} else {
-   addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
-- 
1.7.9.5



[PATCH 11/11] drm/omap: page-flip fixes

2012-10-09 Thread Imre Deak
On Tue, 2012-10-09 at 12:35 +0300, Imre Deak wrote:
> On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote:
> > From: Rob Clark 
> > 
> > Userspace might not request a vblank event.  So it is not an error
> > for 'event' to be NULL, and we shouldn't use it to determine if
> > there is a pending flip already.
> > 
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/staging/omapdrm/omap_crtc.c |6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/omapdrm/omap_crtc.c 
> > b/drivers/staging/omapdrm/omap_crtc.c
> > index 74e019a..317b854 100644
> > --- a/drivers/staging/omapdrm/omap_crtc.c
> > +++ b/drivers/staging/omapdrm/omap_crtc.c
> > @@ -119,7 +119,6 @@ static void vblank_cb(void *arg)
> > struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> > unsigned long flags;
> >  
> > -   WARN_ON(!event);
> > spin_lock_irqsave(>event_lock, flags);
> >  
> > /* wakeup userspace */
> > @@ -127,6 +126,7 @@ static void vblank_cb(void *arg)
> > drm_send_vblank_event(dev, -1, omap_crtc->event);
> >  
> > omap_crtc->event = NULL;
> > +   omap_crtc->old_fb = NULL;
> 
> Is old_fb used anywhere? If not we could just remove it.
> 
> Otherwise nice work! On the series:
> 
> Reviewed-by: Imre Deak 
> 
> >  
> > spin_unlock_irqrestore(>event_lock, flags);
> >  }
> > @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg)
> > struct drm_framebuffer *old_fb = omap_crtc->old_fb;
> > struct drm_gem_object *bo;
> >  
> > -   omap_crtc->old_fb = NULL;
> > -
> > omap_crtc_mode_set_base(crtc, crtc->x, crtc->y, old_fb);
> >  
> > /* really we'd like to setup the callback atomically w/ setting the
> > @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc 
> > *crtc,
> >  
> > DBG("%d -> %d", crtc->fb ? crtc->fb->base.id : -1, fb->base.id);
> >  
> > -   if (omap_crtc->event) {
> > +   if (omap_crtc->old_fb) {

Ah, just noticed this adds the use for it :) So ignore my comment above.

--Imre

> > dev_err(dev->dev, "already a pending flip\n");
> > return -EINVAL;
> > }
> 




[PATCH 11/11] drm/omap: page-flip fixes

2012-10-09 Thread Imre Deak
On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Userspace might not request a vblank event.  So it is not an error
> for 'event' to be NULL, and we shouldn't use it to determine if
> there is a pending flip already.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/staging/omapdrm/omap_crtc.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/omapdrm/omap_crtc.c 
> b/drivers/staging/omapdrm/omap_crtc.c
> index 74e019a..317b854 100644
> --- a/drivers/staging/omapdrm/omap_crtc.c
> +++ b/drivers/staging/omapdrm/omap_crtc.c
> @@ -119,7 +119,6 @@ static void vblank_cb(void *arg)
>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>   unsigned long flags;
>  
> - WARN_ON(!event);
>   spin_lock_irqsave(>event_lock, flags);
>  
>   /* wakeup userspace */
> @@ -127,6 +126,7 @@ static void vblank_cb(void *arg)
>   drm_send_vblank_event(dev, -1, omap_crtc->event);
>  
>   omap_crtc->event = NULL;
> + omap_crtc->old_fb = NULL;

Is old_fb used anywhere? If not we could just remove it.

Otherwise nice work! On the series:

Reviewed-by: Imre Deak 

>  
>   spin_unlock_irqrestore(>event_lock, flags);
>  }
> @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg)
>   struct drm_framebuffer *old_fb = omap_crtc->old_fb;
>   struct drm_gem_object *bo;
>  
> - omap_crtc->old_fb = NULL;
> -
>   omap_crtc_mode_set_base(crtc, crtc->x, crtc->y, old_fb);
>  
>   /* really we'd like to setup the callback atomically w/ setting the
> @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc 
> *crtc,
>  
>   DBG("%d -> %d", crtc->fb ? crtc->fb->base.id : -1, fb->base.id);
>  
> - if (omap_crtc->event) {
> + if (omap_crtc->old_fb) {
>   dev_err(dev->dev, "already a pending flip\n");
>   return -EINVAL;
>   }




[PATCH] drm: Add missing break in the command line mode parsing code

2012-10-09 Thread Damien Lespiau
From: Damien Lespiau 

As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_modes.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 28637c1..50bd5c1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1054,6 +1054,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
was_digit = false;
} else
goto done;
+   break;
case '0' ... '9':
was_digit = true;
break;
-- 
1.7.7.5



[PATCH] drm: Fix kdoc comment for drm_crtc_convert_umode

2012-10-09 Thread mika.kuopp...@intel.com
From: Mika Kuoppala 

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/drm_crtc.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ef1b221..bb4c686 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1148,9 +1148,9 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
 }

 /**
- * drm_crtc_convert_to_umode - convert a modeinfo into a drm_display_mode
- * @out: drm_display_mode to return to the user
- * @in: drm_mode_modeinfo to use
+ * drm_crtc_convert_umode - convert a modeinfo into a drm_display_mode
+ * @out: drm_display_mode to return to the caller
+ * @in: drm_mode_modeinfo from user
  *
  * LOCKING:
  * None.
-- 
1.7.9.5



[PATCH v2] Documentation: kernel-parameters.txt Add drm_kms_helper.poll

2012-10-09 Thread mika.kuopp...@intel.com
From: Mika Kuoppala 

Possibility to disable polling to find connected displays was
introduced by commit [1]:

commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
Author: Chris Wilson 
Date:   Fri Aug 20 09:13:36 2010 +0100

drm/kms: Add a module parameter to disable polling

Add description for this parameter to kernel-parameters.txt

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9

Signed-off-by: Mika Kuoppala 
---
 Documentation/kernel-parameters.txt |   16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index f777fa9..0f0f071 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -741,6 +741,22 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
if its name and a colon are prepended to the EDID
name.

+   drm_kms_helper.poll=
+   Polling for connected display devices on older systems
+   without Hot Plug Detect (HPD) support, can be quite
+   expensive. Poll will happen periodically and can in
+   worst cases take several hundred milliseconds,
+   depending on the hardware. This will cause visible
+   stalls, for example in video playback. These stalls
+   might happen even when your video is on HDP output
+   but you have other non HDP outputs in your hw
+   configuration. If you experience stalls in display
+   output occurring every 10 seconds, disabling polling
+   might help. With polling disabled you need to manually
+   use xrandr to trigger detection.
+   Format:   (1/Y/y=enable, 0/N/n=disable)
+   default: enabled
+
dscc4.setup=[NET]

dyndbg[="val"]  [KNL,DYNAMIC_DEBUG]
-- 
1.7.9.5



[PATCH] drm/omap: fix allocation size for page addresses array

2012-10-09 Thread Greg KH
On Tue, Oct 09, 2012 at 01:01:08PM -0500, Vincent Penquerc'h wrote:
> Signed-off-by: Rob Clark 
> ---
>  drivers/staging/omapdrm/omap_gem.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Having a patch "From:" someone else is fine, but please get a
signed-off-by from them as well.

Care to resend?

Also, take a look at Documentation/SubmittingPatches which shows how to
put the "From:" line in the body of the changelog area so that the From:
part shows up correctly when I commit it.

thanks,

greg k-h


[PATCH v5 0/3] Enhanced EDID quirk functionality

2012-10-09 Thread Adam Jackson
On 10/8/12 7:22 PM, Ian Pilcher wrote:
> On 09/28/2012 02:03 AM, Ian Pilcher wrote:
>> As promised, this patch series does only the following:
>>
>> * Add user-defined EDID quirks -- via sysfs or a module parameter
>> * Add an EDID quirk flag to disable all HDMI functionality
>>(InfoFrames)
>> * Add a quirk to disable HDMI InfoFrames for the LG L246WP
>>
>
> ACK?  NACK?  I'm on crack?
>
> (I'm starting to think that this is some sort of hazing ritual.)

Sorry, I'm just not paying close attention to EDID stuff at the moment.

The series as is is clearly better than what we've got.  I still think 
there's something fundamentally amiss with a display that doesn't want 
to accept InfoFrames, but without having it in hand to mess with - and 
without wanting to play telephone to figure it out - I'm fine with this.

Reviewed-by: Adam Jackson 

- ajax


[PATCH] drm/radeon/cayman: set VM max pfn at MC init

2012-10-09 Thread Christian König
On 08.10.2012 18:25, alexdeucher at gmail.com wrote:
> From: Alex Deucher 
>
> No need to emit them at VM flush as we no longer use
> variable sized page tables now that we support 2 level
> page tables.  This matches the behavior of SI (which
> does not support variable sized page tables).
>
> Signed-off-by: Alex Deucher 
Yeah, wanted to do so also, but have somehow forgotten it.

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/ni.c |8 +---
>   1 files changed, 1 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index cfb9276..cc0701a 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -776,7 +776,7 @@ static int cayman_pcie_gart_enable(struct radeon_device 
> *rdev)
>*/
>   for (i = 1; i < 8; i++) {
>   WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (i << 2), 0);
> - WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i << 2), 0);
> + WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i << 2), 
> rdev->vm_manager.max_pfn);
>   WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i << 2),
>   rdev->gart.table_addr >> 12);
>   }
> @@ -1576,12 +1576,6 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
> ridx, struct radeon_vm *vm)
>   if (vm == NULL)
>   return;
>   
> - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR + 
> (vm->id << 2), 0));
> - radeon_ring_write(ring, 0);
> -
> - radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + 
> (vm->id << 2), 0));
> - radeon_ring_write(ring, rdev->vm_manager.max_pfn);
> -
>   radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
> (vm->id << 2), 0));
>   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
>   



[PATCH] drm/radeon: check if pcie gen 2 is already enabled (v2)

2012-10-09 Thread alexdeuc...@gmail.com
From: Alex Deucher 

If so, skip enabling it to save time.

v2: coding style fixes

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c |7 ++-
 drivers/gpu/drm/radeon/r600.c  |6 ++
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index a1f49c5..14313ad 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3431,9 +3431,14 @@ void evergreen_pcie_gen2_enable(struct radeon_device 
*rdev)
if (!(mask & DRM_PCIE_SPEED_50))
return;

+   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
+   if (speed_cntl & LC_CURRENT_DATA_RATE) {
+   DRM_INFO("PCIE gen 2 link speeds already enabled\n");
+   return;
+   }
+
DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0\n");

-   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
if ((speed_cntl & LC_OTHER_SIDE_EVER_SENT_GEN2) ||
(speed_cntl & LC_OTHER_SIDE_SUPPORTS_GEN2)) {

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 70c800f..cda280d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3703,6 +3703,12 @@ static void r600_pcie_gen2_enable(struct radeon_device 
*rdev)
if (!(mask & DRM_PCIE_SPEED_50))
return;

+   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
+   if (speed_cntl & LC_CURRENT_DATA_RATE) {
+   DRM_INFO("PCIE gen 2 link speeds already enabled\n");
+   return;
+   }
+
DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0\n");

/* 55 nm r6xx asics */
-- 
1.7.7.5



[PATCH v5 1/3] drm: Add user-defined EDID quirks capability

2012-10-09 Thread Ian Pilcher
r, struct edid *edid)
> > -{
> > +{
> >   struct detailed_mode_closure closure = {
> >   connector, edid, 0, 0, 0
> >   };
> > @@ -1615,15 +2004,12 @@ void drm_edid_to_eld(struct drm_connector
> *connector, struct edid *edid)
> >
> >   eld[0] = 2 << 3;/* ELD version: 2 */
> >
> > - eld[16] = edid->mfg_id[0];
> > - eld[17] = edid->mfg_id[1];
> > - eld[18] = edid->prod_code[0];
> > - eld[19] = edid->prod_code[1];
> > + *(u32 *)([16]) = edid->display_id.u;
> >
> >   if (cea[1] >= 3)
> >   for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
> >   dbl = db[0] & 0x1f;
> > -
> > +
> >   switch ((db[0] & 0xe0) >> 5) {
> >   case AUDIO_BLOCK:
> >   /* Audio Data Block, contains SADs */
> > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> > index 21bcd4a..b939d51 100644
> > --- a/drivers/gpu/drm/drm_stub.c
> > +++ b/drivers/gpu/drm/drm_stub.c
> > @@ -46,16 +46,22 @@ EXPORT_SYMBOL(drm_vblank_offdelay);
> >  unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
> >  EXPORT_SYMBOL(drm_timestamp_precision);
> >
> > +char *drm_edid_quirks = NULL;
> > +EXPORT_SYMBOL(drm_edid_quirks);
> > +
> >  MODULE_AUTHOR(CORE_AUTHOR);
> >  MODULE_DESCRIPTION(CORE_DESC);
> >  MODULE_LICENSE("GPL and additional rights");
> >  MODULE_PARM_DESC(debug, "Enable debug output");
> >  MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable
> [msecs]");
> >  MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps
> [usecs]");
> > +MODULE_PARM_DESC(edid_quirks, "MFG:prod:flags[,MFG:prod:flags[...]]\n"
> > +   "(See Documentation/EDID/edid_quirks.txt)");
> >
> >  module_param_named(debug, drm_debug, int, 0600);
> >  module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
> >  module_param_named(timestamp_precision_usec, drm_timestamp_precision,
> int, 0600);
> > +module_param_named(edid_quirks, drm_edid_quirks, charp, 0400);
> >
> >  struct idr drm_minors_idr;
> >
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 45ac8d6..84dc365 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -84,6 +84,11 @@ static CLASS_ATTR_STRING(version, S_IRUGO,
> >   __stringify(CORE_PATCHLEVEL) " "
> >   CORE_DATE);
> >
> > +static CLASS_ATTR(edid_quirks_size, 0400, drm_edid_quirks_size_show, 0);
> > +
> > +static CLASS_ATTR(edid_quirks, 0600, drm_edid_quirks_show,
> > +   drm_edid_quirks_store);
> > +
> >  /**
> >   * drm_sysfs_create - create a struct drm_sysfs_class structure
> >   * @owner: pointer to the module that is to "own" this struct
> drm_sysfs_class
> > @@ -113,10 +118,22 @@ struct class *drm_sysfs_create(struct module
> *owner, char *name)
> >   if (err)
> >   goto err_out_class;
> >
> > + err = class_create_file(class, _attr_edid_quirks_size);
> > + if (err)
> > + goto err_out_version;
> > +
> > + err = class_create_file(class, _attr_edid_quirks);
> > + if (err)
> > + goto err_out_quirks_size;
> > +
> >   class->devnode = drm_devnode;
> >
> >   return class;
> >
> > +err_out_quirks_size:
> > + class_remove_file(class, _attr_edid_quirks_size);
> > +err_out_version:
> > + class_remove_file(class, _attr_version.attr);
> >  err_out_class:
> >   class_destroy(class);
> >  err_out:
> > @@ -132,6 +149,8 @@ void drm_sysfs_destroy(void)
> >  {
> >   if ((drm_class == NULL) || (IS_ERR(drm_class)))
> >   return;
> > + class_remove_file(drm_class, _attr_edid_quirks);
> > + class_remove_file(drm_class, _attr_edid_quirks_size);
> >   class_remove_file(drm_class, _attr_version.attr);
> >   class_destroy(drm_class);
> >   drm_class = NULL;
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index d6b67bb..c947f3e 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1501,6 +1501,7 @@ extern unsigned int drm_debug;
> >
> >  extern unsigned int drm_vblank_offdelay;
> >  extern unsigned int drm_timestamp_precision;
> > +extern char *drm_edid_quirks;
> >
> >  extern struct class *drm_class;
> >  extern struct proc_dir_entry *drm_proc_root;
> > @@ -1612,6 +1613,15 @@ void drm_gem_vm_open(struct vm_area_struct *vma);
> >  void drm_gem_vm_close(struct vm_area_struct *vma);
> >  int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
> >
> > + /* EDID support (drm_edid.c) */
> > +void drm_edid_quirks_param_process(void);
> > +ssize_t drm_edid_quirks_size_show(struct class *class,
> > +   struct class_attribute *attr, char *buf);
> > +ssize_t drm_edid_quirks_show(struct class *class, struct
> class_attribute *attr,
> > +  char *buf);
> > +ssize_t drm_edid_quirks_store(struct class *class, struct
> class_attribute *attr,
> > +   const char *buf, size_t count);
> > +
> >  #include "drm_global.h"
> >
> >  static inline void
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 0cac551..713229b 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -202,11 +202,18 @@ struct detailed_timing {
> >  #define DRM_EDID_FEATURE_PM_SUSPEND   (1 << 6)
> >  #define DRM_EDID_FEATURE_PM_STANDBY   (1 << 7)
> >
> > +union edid_display_id {
> > + struct {
> > + __be16 mfg_id;
> > + __le16 prod_code;
> > + } __attribute__((packed)) s;
> > + u32 u;
> > +};
>
> I think adding this union is counterproductive. The u32 version is
> helpful in one comparison and one assignment, while making all the rest
> just slightly more confusing.
>
> > +
> >  struct edid {
> >   u8 header[8];
> >   /* Vendor & product info */
> > - u8 mfg_id[2];
> > - u8 prod_code[2];
> > + union edid_display_id display_id;
> >   u32 serial; /* FIXME: byte order */
> >   u8 mfg_week;
> >   u8 mfg_year;
> > @@ -242,8 +249,6 @@ struct edid {
> >   u8 checksum;
> >  } __attribute__((packed));
> >
> > -#define EDID_PRODUCT_ID(e) ((e)->prod_code[0] | ((e)->prod_code[1] <<
> 8))
> > -
> >  struct drm_encoder;
> >  struct drm_connector;
> >  struct drm_display_mode;
> > --
> > 1.7.11.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/7ec2da10/attachment-0001.html>


[PATCH 02/11] drm/i915: use drm_send_vblank_event() helper

2012-10-09 Thread Daniel Vetter
On Mon, Oct 08, 2012 at 02:50:40PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Signed-off-by: Rob Clark 

Maybe note in the commit message that after this change pageflip events
will also fire the vblank_event_delivered tracepoint.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c |   15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f5bcf6f..4716c83 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6158,8 +6158,6 @@ static void do_intel_finish_page_flip(struct drm_device 
> *dev,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_unpin_work *work;
>   struct drm_i915_gem_object *obj;
> - struct drm_pending_vblank_event *e;
> - struct timeval tvbl;
>   unsigned long flags;
>  
>   /* Ignore early vblank irqs */
> @@ -6175,17 +6173,8 @@ static void do_intel_finish_page_flip(struct 
> drm_device *dev,
>  
>   intel_crtc->unpin_work = NULL;
>  
> - if (work->event) {
> - e = work->event;
> - e->event.sequence = drm_vblank_count_and_time(dev, 
> intel_crtc->pipe, );
> -
> - e->event.tv_sec = tvbl.tv_sec;
> - e->event.tv_usec = tvbl.tv_usec;
> -
> - list_add_tail(>base.link,
> -   >base.file_priv->event_list);
> - wake_up_interruptible(>base.file_priv->event_wait);
> - }
> + if (work->event)
> + drm_send_vblank_event(dev, intel_crtc->pipe, work->event);
>  
>   drm_vblank_put(dev, intel_crtc->pipe);
>  
> -- 
> 1.7.9.5
> 

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


[PATCH 2/2 v6] of: add generic videomode description

2012-10-09 Thread Steffen Trumtrar
Hi Laurent,

On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
> 
> On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
> > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
> > > > Get videomode from devicetree in a format appropriate for the
> > > > backend. drm_display_mode and fb_videomode are supported atm.
> > > > Uses the display signal timings from of_display_timings
> > > > 
> > > > Signed-off-by: Steffen Trumtrar 
> > > > ---
> > > > 
> > > >  drivers/of/Kconfig   |5 +
> > > >  drivers/of/Makefile  |1 +
> > > >  drivers/of/of_videomode.c|  212 +++
> > > >  include/linux/of_videomode.h |   41 
> > > >  4 files changed, 259 insertions(+)
> > > >  create mode 100644 drivers/of/of_videomode.c
> > > >  create mode 100644 include/linux/of_videomode.h
> 
> [snip]
> 
> > > > diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> > > > new file mode 100644
> > > > index 000..76ac16e
> > > > --- /dev/null
> > > > +++ b/drivers/of/of_videomode.c
> 
> [snip]
> 
> > > > +int videomode_from_timing(struct display_timings *disp, struct
> > > > videomode *vm,
> > > > +   int index)
> > > > +{
> > > > +   struct signal_timing *st = NULL;
> > > > +
> > > > +   if (!vm)
> > > > +   return -EINVAL;
> > > > +
> > > 
> > > What about making vm a mandatory argument ? It looks to me like a caller
> > > bug if vm is NULL.
> > 
> > The caller must provide the struct videomode, yes. Wouldn't the kernel hang
> > itself with a NULL pointer exception, if I just work with it ?
> 
> The kernel would oops, clearly showing the caller that a non-null vm is 
> needed 
> :-)
> 

Okay. No error checking it is then.

> > > > +   st = display_timings_get(disp, index);
> > > > +
> > > 
> > > You can remove the blank line.
> > > 
> > > > +   if (!st) {
> > > > +   pr_err("%s: no signal timings found\n", __func__);
> > > > +   return -EINVAL;
> > > > +   }
> > > > +
> > > > +   vm->pixelclock = signal_timing_get_value(>pixelclock, 0);
> > > > +   vm->hactive = signal_timing_get_value(>hactive, 0);
> > > > +   vm->hfront_porch = signal_timing_get_value(>hfront_porch, 
> > > > 0);
> > > > +   vm->hback_porch = signal_timing_get_value(>hback_porch, 0);
> > > > +   vm->hsync_len = signal_timing_get_value(>hsync_len, 0);
> > > > +
> > > > +   vm->vactive = signal_timing_get_value(>vactive, 0);
> > > > +   vm->vfront_porch = signal_timing_get_value(>vfront_porch, 
> > > > 0);
> > > > +   vm->vback_porch = signal_timing_get_value(>vback_porch, 0);
> > > > +   vm->vsync_len = signal_timing_get_value(>vsync_len, 0);
> > > > +
> > > > +   vm->vah = st->vsync_pol_active_high;
> > > > +   vm->hah = st->hsync_pol_active_high;
> > > > +   vm->interlaced = st->interlaced;
> > > > +   vm->doublescan = st->doublescan;
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int
> > > > index)
> > > 
> > > I wonder how to avoid abuse of this functions. It's a useful helper for
> > > drivers that need to get a video mode once only, but would result in lower
> > > performances if a driver calls it for every mode. Drivers must call
> > > of_get_display_timing_list instead in that case and case the display
> > > timings. I'm wondering whether we should really expose of_get_videomode.
> > 
> > The intent was to let the driver decide. That way all the other overhead may
> > be skipped.
> 
> My point is that driver writers might just call of_get_videomode() in a loop, 
> not knowing that it's expensive. I want to avoid that. We need to at least 
> add 
> kerneldoc to the function stating that this shouldn't be done.
> 

You're right. That should be made clear in the code.

> > > > +{
> > > > +   struct display_timings *disp;
> > > > +   int ret = 0;
> > > 
> > > No need to assign ret to 0 here.
> > 
> > Ah, yes. Unneeded in this case.
> > 
> > > > +
> > > > +   disp = of_get_display_timing_list(np);
> > > > +
> > > 
> > > You can remove the blank line.
> > > 
> > > > +   if (!disp) {
> > > > +   pr_err("%s: no timings specified\n", __func__);
> > > > +   return -EINVAL;
> > > > +   }
> > > > +
> > > > +   if (index == OF_DEFAULT_TIMING)
> > > > +   index = disp->default_timing;
> > > > +
> > > > +   ret = videomode_from_timing(disp, vm, index);
> > > > +
> > > 
> > > No need for a blank line.
> > > 
> > > > +   if (ret)
> > > > +   return ret;
> > > > +
> > > > +   display_timings_release(disp);
> > > > +
> > > > +   if (!vm) {
> > > > +   pr_err("%s: could not get videomode %d\n", __func__, 
> > > > index);
> > > > +   return -EINVAL;
> > > > +   

[PATCH 0/3] Android support

2012-10-09 Thread Tapani Pälli
On 10/08/2012 06:37 PM, Eric Anholt wrote:
> Tapani P?lli  writes:
> 
>> Upstreaming old set of patches here to enable Android support in libdrm.
>> Some little rebasing was required for the first one.
>>
>> Chad Versace (2):
>>   libdrm,intel: Factor source file lists into sources.mk
>>   libdrm,intel: Add Android makefiles (v2)
> 
> Couldn't this just be done with androgenizer without making a
> maintenance mess in the upstream code?
> 

We do not have androgenizer tool in our Android tree but I will check if
it can successfully compile libdrm and if we would be able to use it.

My main goal here is to get setup where we could use libdrm master as it
is without patching it, we have some additional patches on top of these
too but I want to make myself more familiar with those before sending them.


Thanks;

-- 

// Tapani


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/8197482c/attachment.pgp>


[PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Rafał Miłecki
2012/10/8  :
> +   if (speed_cntl & LC_CURRENT_DATA_RATE) {
> +   DRM_INFO("PCIE gen 2 link speeds already enabled\n");
> +   return;
> +   } else
> +   DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
> radeon.pcie_gen2=0\n");
> +

See documentation/CodingStyle:

> This does not apply if only one branch of a conditional statement is a single
> statement; in the latter case use braces in both branches:

Your else should use braces :)

-- 
Rafa?


[PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Alex Deucher
On Tue, Oct 9, 2012 at 3:05 AM, Rafa? Mi?ecki  wrote:
> 2012/10/8  :
>> +   if (speed_cntl & LC_CURRENT_DATA_RATE) {
>> +   DRM_INFO("PCIE gen 2 link speeds already enabled\n");
>> +   return;
>> +   } else
>> +   DRM_INFO("enabling PCIE gen 2 link speeds, disable with 
>> radeon.pcie_gen2=0\n");
>> +
>
> See documentation/CodingStyle:
>
>> This does not apply if only one branch of a conditional statement is a single
>> statement; in the latter case use braces in both branches:
>
> Your else should use braces :)

I'll fix that up.

Alex


[PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Alex Deucher
On Tue, Oct 9, 2012 at 2:26 AM, Paul Menzel
 wrote:
> Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeucher at gmail.com:
>> From: Alex Deucher 
>>
>> If so, skip enabling it.
>
> Does that fix any error/problem or is it just for speed reasons?

It doesn't fix anything that I know of.  Just speed.

Alex

>
>> Signed-off-by: Alex Deucher 
>> ---
>>  drivers/gpu/drm/radeon/evergreen.c |8 ++--
>>  drivers/gpu/drm/radeon/r600.c  |7 ++-
>>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> [?]
>
>
> Thanks,
>
> Paul


[PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Paul Menzel
Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeucher at gmail.com:
> From: Alex Deucher 
> 
> If so, skip enabling it.

Does that fix any error/problem or is it just for speed reasons?

> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/radeon/evergreen.c |8 ++--
>  drivers/gpu/drm/radeon/r600.c  |7 ++-
>  2 files changed, 12 insertions(+), 3 deletions(-)

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121009/7ee68b1c/attachment.pgp>


[PATCH v3 3/3] Android.mk: use LOCAL_COPY_HEADERS to export headers.

2012-10-09 Thread Oliver McFadden
On Mon, Oct 08, 2012 at 03:52:20PM +0300, Tapani P?lli wrote:
> From: Haitao Huang 
> 
> Export necessary header files used by other components for Android,
> such as libva intel-driver, gralloc, hwcomposer, etc.
> 
> Signed-off-by: Haitao Huang 
> Signed-off-by: Chad Versace 
Reviewed-by: Oliver McFadden 
> ---
> [chad: Fixed inconsistent indentation.]
>  Android.mk | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/Android.mk b/Android.mk
> index 1029dc6..68db5df 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -1,5 +1,5 @@
>  #
> -# Copyright ? 2011 Intel Corporation
> +# Copyright ? 2011-2012 Intel Corporation
>  #
>  # Permission is hereby granted, free of charge, to any person obtaining a
>  # copy of this software and associated documentation files (the "Software"),
> @@ -45,6 +45,16 @@ LOCAL_C_INCLUDES := \
>  LOCAL_CFLAGS := \
>   -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
>  
> +LOCAL_COPY_HEADERS :=\
> + xf86drm.h\
> + include/drm/drm_fourcc.h \
> + include/drm/drm.h\
> + include/drm/drm_mode.h   \
> + include/drm/drm_sarea.h  \
> + include/drm/i915_drm.h   \
> + intel/intel_bufmgr.h \
> +
> +LOCAL_COPY_HEADERS_TO := libdrm
>  include $(BUILD_SHARED_LIBRARY)
>  
>  include $(LOCAL_PATH)/intel/Android.mk
> -- 
> 1.7.11.7
> 

-- 
Oliver McFadden.


[RFC 1/4] time: export getnstime_raw_and_real for DRM

2012-10-09 Thread Mario Kleiner
On 08.10.12 13:35, Imre Deak wrote:
> On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
>> [...]
>>
>> But then Psychtoolbox checks each timestamp it gets from somewhere
>> "outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps,
>> network receive timestamps, evdev, x11, ...) if it is in gettimeofday()
>> aka CLOCK_REALTIME aka wall time or in CLOCK_MONOTONIC time and just
>> remaps to whatever its reference clock is.
>>
>> There's no way around this than to have no fixed expectations, but to
>> remap stuff on the fly, because different parts of the Linux universe
>> have decided on different time bases, or even switched somewhere from
>> one kernel version to the next in the last years, e.g., ALSA, which at
>> some time switched from wall clock to CLOCK_MONOTONIC. Sometimes
>> clock_gettime() wasn't available at all in older setups, so there only
>> was gettimeofday(). Or toolkits like GStreamer use different timebases
>> dependent on OS and sometimes even on plugins.
>>
>> I would expect that other timing sensitive apps have to have ways to
>> handle this in similar ways.
>
> I think the question is, can we be sure? I don't think there is any
> guarantee that random application X will not be confused by an
> unconditional switch to monotonic timestamps.
>
>> Wrt. to the drm vblank/pageflip timestamps, the userspace extensions
>> which expose these (INTEL_swap_events, OML_sync_control) don't allow
>> apps to select which timebase to use, they define monotonic time as what
>> is returned, so i don't know how a userspace app could actually ask the
>> DRM for one or the other format? So i guess just switching to
>> CLOCK_MONOTONIC shouldn't be that bad.
>
> An application could just use the kernel DRM interface directly. I admit
> this is not very likely but this is what should determine the rules by
> which we change the ABI.
>

Ok, that's a good point, agreed.
-mario


[PATCH 00/11] page-flip cleanups and fixes

2012-10-09 Thread Marcin Slusarz
On Mon, Oct 08, 2012 at 02:50:38PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> Add a helper fxn to send vblank event after pageflip, plus a handful
> of fixes for other issues that I noticed in the process.

FWIW, patches 1-5 and 7 (with a fix to 1st) are:
Reviewed-by: Marcin Slusarz 

> 
> Other than OMAP, the changes are just compile tested, so would be
> good to get a quick look from the maintainers of various drivers.
> 
> Rob Clark (11):
>   drm: add drm_send_vblank_event() helper
>   drm/i915: use drm_send_vblank_event() helper
>   drm/nouveau: use drm_send_vblank_event() helper
>   drm/radeon: use drm_send_vblank_event() helper
>   drm/exynos: use drm_send_vblank_event() helper
>   drm/exynos: page flip fixes
>   drm/shmob: use drm_send_vblank_event() helper
>   drm/imx: use drm_send_vblank_event() helper
>   drm/imx: page flip fixes
>   drm/omap: use drm_send_vblank_event() helper
>   drm/omap: page-flip fixes
> 
>  drivers/gpu/drm/drm_irq.c |   65 
> +++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |1 -
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   10 +
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   10 +
>  drivers/gpu/drm/exynos/exynos_mixer.c |9 +---
>  drivers/gpu/drm/i915/intel_display.c  |   15 +--
>  drivers/gpu/drm/nouveau/nouveau_display.c |   13 +-
>  drivers/gpu/drm/radeon/radeon_display.c   |   13 ++
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c |   19 ++---
>  drivers/staging/imx-drm/ipuv3-crtc.c  |   32 --
>  drivers/staging/omapdrm/omap_crtc.c   |   37 
>  include/drm/drmP.h|2 +
>  12 files changed, 78 insertions(+), 148 deletions(-)
> 
> -- 


[PATCH 01/11] drm: add drm_send_vblank_event() helper

2012-10-09 Thread Marcin Slusarz
On Mon, Oct 08, 2012 at 02:50:39PM -0500, Rob Clark wrote:
> From: Rob Clark 
> 
> A helper that drivers can use to send vblank event after a pageflip.
> If the driver doesn't support proper vblank irq based time/seqn then
> just pass -1 for the pipe # to get do_gettimestamp() behavior (since
> there are a lot of drivers that don't use drm_vblank_count_and_time())
> 
> Also an internal send_vblank_event() helper for the various other code
> paths within drm_irq that also need to send vblank events.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_irq.c |   65 
> +
>  include/drm/drmP.h|2 ++
>  2 files changed, 44 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 076c4a8..7a00d94 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -802,6 +802,43 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, 
> int crtc,
>  }
>  EXPORT_SYMBOL(drm_vblank_count_and_time);
>  
> +static void send_vblank_event(struct drm_pending_vblank_event *e,
> + unsigned long seq, struct timeval *now)
> +{
> + e->event.sequence = seq;
> + e->event.tv_sec = now->tv_sec;
> + e->event.tv_usec = now->tv_usec;
> +
> + list_add_tail(>base.link,
> +   >base.file_priv->event_list);
> + wake_up_interruptible(>base.file_priv->event_wait);
> + trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> +  e->event.sequence);
> +}
> +
> +/**
> + * drm_send_vblank_event - helper to send vblank event after pageflip
> + * @dev: DRM device
> + * @crtc: CRTC in question
> + * @e: the event to send
> + *
> + * Updates sequence # and timestamp on event, and sends it to userspace.
> + */
> +void drm_send_vblank_event(struct drm_device *dev, int crtc,
> + struct drm_pending_vblank_event *e)
> +{
> + struct timeval now;
> + unsigned int seq;
> + if (crtc >= 0) {
> + seq = drm_vblank_count_and_time(dev, crtc, );
> + } else {
> + seq = 0;
> + do_gettimeofday();
> + }
> + send_vblank_event(e, seq, );
> +}
> +EXPORT_SYMBOL(drm_send_vblank_event);
> +
>  /**
>   * drm_update_vblank_count - update the master vblank counter
>   * @dev: DRM device
> @@ -955,15 +992,9 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
>   DRM_DEBUG("Sending premature vblank event on disable: \
> wanted %d, current %d\n",
> e->event.sequence, seq);
> -
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(>base.link);
>   drm_vblank_put(dev, e->pipe);
> - list_move_tail(>base.link, >base.file_priv->event_list);
> - wake_up_interruptible(>base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> -  e->event.sequence);
> + send_vblank_event(e, seq, );
>   }
>  
>   spin_unlock_irqrestore(>vbl_lock, irqflags);
> @@ -1107,15 +1138,8 @@ static int drm_queue_vblank_event(struct drm_device 
> *dev, int pipe,
>  
>   e->event.sequence = vblwait->request.sequence;
>   if ((seq - vblwait->request.sequence) <= (1 << 23)) {
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
>   drm_vblank_put(dev, pipe);
> - list_add_tail(>base.link, >base.file_priv->event_list);
> - wake_up_interruptible(>base.file_priv->event_wait);
> - vblwait->reply.sequence = seq;

D?j? vu

http://lists.freedesktop.org/archives/dri-devel/2011-April/010693.html

:)

> - trace_drm_vblank_event_delivered(current->pid, pipe,
> -  vblwait->request.sequence);
> + send_vblank_event(e, seq, );
>   } else {
>   /* drm_handle_vblank_events will call drm_vblank_put */
>   list_add_tail(>base.link, >vblank_event_list);
> @@ -1256,14 +1280,9 @@ static void drm_handle_vblank_events(struct drm_device 
> *dev, int crtc)
>   DRM_DEBUG("vblank event on %d, current %d\n",
> e->event.sequence, seq);
>  
> - e->event.sequence = seq;
> - e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + list_del(>base.link);
>   drm_vblank_put(dev, e->pipe);
> - list_move_tail(>base.link, >base.file_priv->event_list);
> - wake_up_interruptible(>base.file_priv->event_wait);
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> -  e->event.sequence);
> + send_vblank_event(e, seq, );
>   }
>  
>  

[PATCH] drm/nv40/pm: silence GCC warnings

2012-10-09 Thread Paul Bolle
Building nv40_pm.o triggers these GCC warnings:
drivers/gpu/drm/nouveau/nv40_pm.c: In function 'nv40_pm_clocks_pre':
drivers/gpu/drm/nouveau/nv40_pm.c:164:41: warning: 'log2P' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:38: warning: 'M2' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:45: warning: 'M1' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:25: warning: 'N2' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:51: warning: 'N1' may be used 
uninitialized in this function [-Wmaybe-uninitialized]

But these variables seem to be initialized when used there. If the
preceding call of nv40_calc_pll() fails it will return a negative value
and this code will never be run. And if that call succeeds it will
return zero and all those five variables ought to be initialized when
used there.

Anyhow, it turns out that these warnings can be silenced by giving GCC
slightly more detailed information a little earlier. See,
get_pll_limits() returns an error-code integer (ie, negative on failure,
zero on success). And a trivial tweak to nv40_calc_pll() that takes this
into account makes these errors go away.

Signed-off-by: Paul Bolle 
---
0) I noticed these warnings while building recent releases (eg,
v3.6-rc7, v3.6, and v3.6.1) on current Fedora 17, using Fedora's default
config. But I found identical warnings in a build log for release
v3.4-rc1. I didn't bother checking earlier releases.

1) Compile tested only (I do not have the hardware involved at hand).

2) This is not the only place where get_pll_limits()'s return value is
checked. But this is apparently the only place where GCC needs to know
that any non-zero return will be negative.

 drivers/gpu/drm/nouveau/nv40_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c 
b/drivers/gpu/drm/nouveau/nv40_pm.c
index e66273a..3df30cb 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -114,7 +114,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct 
pll_lims *pll,
int ret;

ret = get_pll_limits(dev, reg, pll);
-   if (ret)
+   if (ret < 0)
return ret;

if (clk < pll->vco1.maxfreq)
-- 
1.7.11.4



Re: [PATCH 0/3] Android support

2012-10-09 Thread Tapani Pälli
On 10/08/2012 06:37 PM, Eric Anholt wrote:
 Tapani Pälli tapani.pa...@intel.com writes:
 
 Upstreaming old set of patches here to enable Android support in libdrm.
 Some little rebasing was required for the first one.

 Chad Versace (2):
   libdrm,intel: Factor source file lists into sources.mk
   libdrm,intel: Add Android makefiles (v2)
 
 Couldn't this just be done with androgenizer without making a
 maintenance mess in the upstream code?
 

We do not have androgenizer tool in our Android tree but I will check if
it can successfully compile libdrm and if we would be able to use it.

My main goal here is to get setup where we could use libdrm master as it
is without patching it, we have some additional patches on top of these
too but I want to make myself more familiar with those before sending them.


Thanks;

-- 

// Tapani




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2] gma500: medfield: drop bogus NULL check in mdfld_dsi_output_init()

2012-10-09 Thread Wei Yongjun
From: Wei Yongjun yongjun_...@trendmicro.com.cn

Drop the NULL test for dev since it never be NULL.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 32dba2a..b6f49d9 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -506,7 +506,7 @@ void mdfld_dsi_output_init(struct drm_device *dev,
 
dev_dbg(dev-dev, init DSI output on pipe %d\n, pipe);
 
-   if (!dev || ((pipe != 0)  (pipe != 2))) {
+   if ((pipe != 0)  (pipe != 2)) {
DRM_ERROR(Invalid parameter\n);
return;
}


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


Re: Update on the CEC API

2012-10-09 Thread Florian Fainelli
Hi Hans,

On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
 Hi all,
 
 During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) had a
 discussion on how to handle the CEC protocol that's part of the HDMI 
standard.
 
 The decision was made to create a CEC bus with CEC clients, each represented
 by a /dev/cecX device. So this is independent of the V4L or DRM APIs. 
 
 In addition interested subsystems (alsa for the Audio Return Channel, and
 possibly networking as well for ethernet over HDMI) can intercept/send CEC
 messages as well if needed. Particularly for the CEC additions made in
 HDMI 1.4a it is no longer possible to handle the CEC protocol completely in
 userspace, but part of the intelligence has to be moved to kernelspace.

What kind of intelligence are you talking about? I see nothing in HDMI 1.4a 
or earlier that requires doing stuff in kernelspace besides managing control to 
the hardware, but I might be missing something.

In my opinion ARC is just a control mechanism, and can be dealt with in user-
space, since you really want to just have hints about when ARC is 
enabled/disabled to take appropriate actions on the audio outputs or your 
system.

 
 I've started working on this API but I am still at the stage of playing
 around with it and thinking about the best way this functionality should
 be exposed. At least I managed to get the first CEC packets transferred
 today :-)
 
 It will probably be a few weeks before I post something, but in the meantime
 if you want to use CEC and have certain requirements that need to be met,
 please let me know. If only so that I can be certain I haven't forgotten
 anything.

Here is my wish-list, if I may:
- allow for a CEC adapter to be in detached / attached mode, particularly 
useful if the hardware doing CEC can process a basic set of messages to act a 
a global wake-up source for the system

- allow for a CEC adapter to define several receive modes: unicast and 
promiscuous, which is useful for dumping the CEC bus messages

- make the CEC adapter API asynchronous for the data path, so it is easy for a 
driver to report completion of a successfully transmitted/received CEC frame

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


Re: [PATCH v2] gma500: medfield: drop bogus NULL check in mdfld_dsi_output_init()

2012-10-09 Thread Kirill A. Shutemov
On Mon, Oct 08, 2012 at 10:44:06PM +0800, Wei Yongjun wrote:
 From: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 Drop the NULL test for dev since it never be NULL.
 
 dpatch engine is used to auto generate this patch.
 (https://github.com/weiyj/dpatch)
 
 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
 ---
  drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
 b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
 index 32dba2a..b6f49d9 100644
 --- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
 +++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
 @@ -506,7 +506,7 @@ void mdfld_dsi_output_init(struct drm_device *dev,
  
   dev_dbg(dev-dev, init DSI output on pipe %d\n, pipe);
  
 - if (!dev || ((pipe != 0)  (pipe != 2))) {
 + if ((pipe != 0)  (pipe != 2)) {

It would be nice to remove redundant parentheses while you're there.

Otherwise
Acked-by: Kirill A. Shutemov kirill.shute...@linux.intel.com

   DRM_ERROR(Invalid parameter\n);
   return;
   }
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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


Re: [PATCH 1/2 v6] of: add helper to parse display timings

2012-10-09 Thread Mitch Bradley
On 10/7/2012 11:01 PM, Tomi Valkeinen wrote:
 On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
 
 In general, I might be misunderstanding something, but don't we have to 
 distinguish between 2 types of information about display timings: (1) is 
 defined by the display controller requirements, is known to the display 
 driver and doesn't need to be present in timings DT. We did have some of 
 these parameters in board data previously, because we didn't have proper 
 display controller drivers... (2) is board specific configuration, and is 
 such it has to be present in DT.

 In that way, doesn't interlaced belong to type (1) and thus doesn't need 
 to be present in DT?
 
 As I see it, this DT data is about the display (most commonly LCD
 panel), i.e. what video mode(s) the panel supports. If things were done
 my way, the panel's supported timings would be defined in the driver for
 the panel, and DT would be left to describe board specific data, but
 this approach has its benefits.
 
 Thus, if you connect an interlaced panel to your board,


Do interlaced panels exist?  I have never seen one.


 you need to tell
 the display controller that this panel requires interlace signal. Also,
 pixel clock source doesn't make sense in this context, as this doesn't
 describe the actual used configuration, but only what the panel
 supports.
 
 Of course, if this is about describing the hardware, the default-mode
 property doesn't really fit in...
 
  Tomi
 
 
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Update on the CEC API

2012-10-09 Thread Florian Fainelli
On Monday 08 October 2012 17:49:00 Hans Verkuil wrote:
 On Mon October 8 2012 17:06:20 Florian Fainelli wrote:
  Hi Hans,
  
  On Thursday 27 September 2012 16:33:30 Hans Verkuil wrote:
   Hi all,
   
   During the Linux Plumbers Conference we (i.e. V4L2 and DRM developers) 
   had a
   discussion on how to handle the CEC protocol that's part of the HDMI 
  standard.
   
   The decision was made to create a CEC bus with CEC clients, each 
   represented
   by a /dev/cecX device. So this is independent of the V4L or DRM APIs. 
   
   In addition interested subsystems (alsa for the Audio Return Channel, and
   possibly networking as well for ethernet over HDMI) can intercept/send CEC
   messages as well if needed. Particularly for the CEC additions made in
   HDMI 1.4a it is no longer possible to handle the CEC protocol completely 
   in
   userspace, but part of the intelligence has to be moved to kernelspace.
  
  What kind of intelligence are you talking about? I see nothing in HDMI 
  1.4a 
  or earlier that requires doing stuff in kernelspace besides managing 
  control to 
  the hardware, but I might be missing something.
 
 Most notably: handling the new hotplug message. That's something that kernel
 drivers need to know. Some ARC messages might be relevant for ALSA drivers as
 well, but I need to look into those more carefully.
 
 Also remote control messages might optionally be handled through an input 
 driver.

Ok, then maybe just stick to the standard CEC_UI_* key codes, and let people
having proprietary UI functions do the rest in user-space, or write their own
input driver.

 
  In my opinion ARC is just a control mechanism, and can be dealt with in 
  user-
  space, since you really want to just have hints about when ARC is 
  enabled/disabled to take appropriate actions on the audio outputs or your 
  system.
  
   
   I've started working on this API but I am still at the stage of playing
   around with it and thinking about the best way this functionality should
   be exposed. At least I managed to get the first CEC packets transferred
   today :-)
   
   It will probably be a few weeks before I post something, but in the 
   meantime
   if you want to use CEC and have certain requirements that need to be met,
   please let me know. If only so that I can be certain I haven't forgotten
   anything.
  
  Here is my wish-list, if I may:
  - allow for a CEC adapter to be in detached / attached mode, 
  particularly 
  useful if the hardware doing CEC can process a basic set of messages to act 
  a 
  a global wake-up source for the system
 
 I have hardware that can do that, so I want to look into supporting this.
 
  - allow for a CEC adapter to define several receive modes: unicast and 
  promiscuous, which is useful for dumping the CEC bus messages
 
 I don't think I have hardware for that, but it shouldn't be difficult to add.

Definitively not, just let a driver writer specify a flag to advertise this
capability and have a getter/setter to specify the receive mode.

 
  - make the CEC adapter API asynchronous for the data path, so it is easy 
  for a 
  driver to report completion of a successfully transmitted/received CEC frame
 
 Already done.

Great, thanks!
--
Florian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Paul Menzel
Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeuc...@gmail.com:
 From: Alex Deucher alexander.deuc...@amd.com
 
 If so, skip enabling it.

Does that fix any error/problem or is it just for speed reasons?

 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/evergreen.c |8 ++--
  drivers/gpu/drm/radeon/r600.c  |7 ++-
  2 files changed, 12 insertions(+), 3 deletions(-)

[…]


Thanks,

Paul


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


Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Rafał Miłecki
2012/10/8  alexdeuc...@gmail.com:
 +   if (speed_cntl  LC_CURRENT_DATA_RATE) {
 +   DRM_INFO(PCIE gen 2 link speeds already enabled\n);
 +   return;
 +   } else
 +   DRM_INFO(enabling PCIE gen 2 link speeds, disable with 
 radeon.pcie_gen2=0\n);
 +

See documentation/CodingStyle:

 This does not apply if only one branch of a conditional statement is a single
 statement; in the latter case use braces in both branches:

Your else should use braces :)

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


Re: [PATCH 2/2 v6] of: add generic videomode description

2012-10-09 Thread Steffen Trumtrar
Hi Laurent,

On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
 Hi Steffen,
 
 On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
  On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
   On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings

Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---

 drivers/of/Kconfig   |5 +
 drivers/of/Makefile  |1 +
 drivers/of/of_videomode.c|  212 +++
 include/linux/of_videomode.h |   41 
 4 files changed, 259 insertions(+)
 create mode 100644 drivers/of/of_videomode.c
 create mode 100644 include/linux/of_videomode.h
 
 [snip]
 
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 000..76ac16e
--- /dev/null
+++ b/drivers/of/of_videomode.c
 
 [snip]
 
+int videomode_from_timing(struct display_timings *disp, struct
videomode *vm,
+   int index)
+{
+   struct signal_timing *st = NULL;
+
+   if (!vm)
+   return -EINVAL;
+
   
   What about making vm a mandatory argument ? It looks to me like a caller
   bug if vm is NULL.
  
  The caller must provide the struct videomode, yes. Wouldn't the kernel hang
  itself with a NULL pointer exception, if I just work with it ?
 
 The kernel would oops, clearly showing the caller that a non-null vm is 
 needed 
 :-)
 

Okay. No error checking it is then.

+   st = display_timings_get(disp, index);
+
   
   You can remove the blank line.
   
+   if (!st) {
+   pr_err(%s: no signal timings found\n, __func__);
+   return -EINVAL;
+   }
+
+   vm-pixelclock = signal_timing_get_value(st-pixelclock, 0);
+   vm-hactive = signal_timing_get_value(st-hactive, 0);
+   vm-hfront_porch = signal_timing_get_value(st-hfront_porch, 
0);
+   vm-hback_porch = signal_timing_get_value(st-hback_porch, 0);
+   vm-hsync_len = signal_timing_get_value(st-hsync_len, 0);
+
+   vm-vactive = signal_timing_get_value(st-vactive, 0);
+   vm-vfront_porch = signal_timing_get_value(st-vfront_porch, 
0);
+   vm-vback_porch = signal_timing_get_value(st-vback_porch, 0);
+   vm-vsync_len = signal_timing_get_value(st-vsync_len, 0);
+
+   vm-vah = st-vsync_pol_active_high;
+   vm-hah = st-hsync_pol_active_high;
+   vm-interlaced = st-interlaced;
+   vm-doublescan = st-doublescan;
+
+   return 0;
+}
+
+int of_get_videomode(struct device_node *np, struct videomode *vm, int
index)
   
   I wonder how to avoid abuse of this functions. It's a useful helper for
   drivers that need to get a video mode once only, but would result in lower
   performances if a driver calls it for every mode. Drivers must call
   of_get_display_timing_list instead in that case and case the display
   timings. I'm wondering whether we should really expose of_get_videomode.
  
  The intent was to let the driver decide. That way all the other overhead may
  be skipped.
 
 My point is that driver writers might just call of_get_videomode() in a loop, 
 not knowing that it's expensive. I want to avoid that. We need to at least 
 add 
 kerneldoc to the function stating that this shouldn't be done.
 

You're right. That should be made clear in the code.

+{
+   struct display_timings *disp;
+   int ret = 0;
   
   No need to assign ret to 0 here.
  
  Ah, yes. Unneeded in this case.
  
+
+   disp = of_get_display_timing_list(np);
+
   
   You can remove the blank line.
   
+   if (!disp) {
+   pr_err(%s: no timings specified\n, __func__);
+   return -EINVAL;
+   }
+
+   if (index == OF_DEFAULT_TIMING)
+   index = disp-default_timing;
+
+   ret = videomode_from_timing(disp, vm, index);
+
   
   No need for a blank line.
   
+   if (ret)
+   return ret;
+
+   display_timings_release(disp);
+
+   if (!vm) {
+   pr_err(%s: could not get videomode %d\n, __func__, 
index);
+   return -EINVAL;
+   }
   
   This can't happen. If vm is NULL the videomode_from_timing call above will
   return -EINVAL, and this function will then return immediately without
   reaching this code block.
  
  Okay.
  
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_videomode);
 
 -- 
 Regards,
 
 Laurent Pinchart
 
 

Regards,

Steffen

-- 
Pengutronix e.K.   | |

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

2012-10-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=47481


Anisse Astier ani...@astier.eu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




--- Comment #9 from Anisse Astier ani...@astier.eu  2012-10-09 07:53:11 ---
I was able to reproduce this bug on an AMD E2-1800 with kernel 3.6. I can
confirm that backporting those two patches fixes the problem:

4a15903 drm/radeon/dce4+: don't use radeon_crtc for vblank callback
62444b7 drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)


It would be great if they could be imported to stable, if they are not demmed
too invasive.

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


Re: [PATCH 02/11] drm/i915: use drm_send_vblank_event() helper

2012-10-09 Thread Daniel Vetter
On Mon, Oct 08, 2012 at 02:50:40PM -0500, Rob Clark wrote:
 From: Rob Clark r...@ti.com
 
 Signed-off-by: Rob Clark r...@ti.com

Maybe note in the commit message that after this change pageflip events
will also fire the vblank_event_delivered tracepoint.

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

 ---
  drivers/gpu/drm/i915/intel_display.c |   15 ++-
  1 file changed, 2 insertions(+), 13 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index f5bcf6f..4716c83 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -6158,8 +6158,6 @@ static void do_intel_finish_page_flip(struct drm_device 
 *dev,
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
   struct intel_unpin_work *work;
   struct drm_i915_gem_object *obj;
 - struct drm_pending_vblank_event *e;
 - struct timeval tvbl;
   unsigned long flags;
  
   /* Ignore early vblank irqs */
 @@ -6175,17 +6173,8 @@ static void do_intel_finish_page_flip(struct 
 drm_device *dev,
  
   intel_crtc-unpin_work = NULL;
  
 - if (work-event) {
 - e = work-event;
 - e-event.sequence = drm_vblank_count_and_time(dev, 
 intel_crtc-pipe, tvbl);
 -
 - e-event.tv_sec = tvbl.tv_sec;
 - e-event.tv_usec = tvbl.tv_usec;
 -
 - list_add_tail(e-base.link,
 -   e-base.file_priv-event_list);
 - wake_up_interruptible(e-base.file_priv-event_wait);
 - }
 + if (work-event)
 + drm_send_vblank_event(dev, intel_crtc-pipe, work-event);
  
   drm_vblank_put(dev, intel_crtc-pipe);
  
 -- 
 1.7.9.5
 

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


Re: [PATCH] drm/radeon/cayman: set VM max pfn at MC init

2012-10-09 Thread Christian König

On 08.10.2012 18:25, alexdeuc...@gmail.com wrote:

From: Alex Deucher alexander.deuc...@amd.com

No need to emit them at VM flush as we no longer use
variable sized page tables now that we support 2 level
page tables.  This matches the behavior of SI (which
does not support variable sized page tables).

Signed-off-by: Alex Deucher alexander.deuc...@amd.com

Yeah, wanted to do so also, but have somehow forgotten it.

Reviewed-by: Christian König christian.koe...@amd.com


---
  drivers/gpu/drm/radeon/ni.c |8 +---
  1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index cfb9276..cc0701a 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -776,7 +776,7 @@ static int cayman_pcie_gart_enable(struct radeon_device 
*rdev)
 */
for (i = 1; i  8; i++) {
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (i  2), 0);
-   WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i  2), 0);
+   WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i  2), 
rdev-vm_manager.max_pfn);
WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i  2),
rdev-gart.table_addr  12);
}
@@ -1576,12 +1576,6 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
if (vm == NULL)
return;
  
-	radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (vm-id  2), 0));

-   radeon_ring_write(ring, 0);
-
-   radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (vm-id 
 2), 0));
-   radeon_ring_write(ring, rdev-vm_manager.max_pfn);
-
radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm-id 
 2), 0));
radeon_ring_write(ring, vm-pd_gpu_addr  12);
  


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


Re: [PATCH 11/11] drm/omap: page-flip fixes

2012-10-09 Thread Imre Deak
On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote:
 From: Rob Clark r...@ti.com
 
 Userspace might not request a vblank event.  So it is not an error
 for 'event' to be NULL, and we shouldn't use it to determine if
 there is a pending flip already.
 
 Signed-off-by: Rob Clark r...@ti.com
 ---
  drivers/staging/omapdrm/omap_crtc.c |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/staging/omapdrm/omap_crtc.c 
 b/drivers/staging/omapdrm/omap_crtc.c
 index 74e019a..317b854 100644
 --- a/drivers/staging/omapdrm/omap_crtc.c
 +++ b/drivers/staging/omapdrm/omap_crtc.c
 @@ -119,7 +119,6 @@ static void vblank_cb(void *arg)
   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
   unsigned long flags;
  
 - WARN_ON(!event);
   spin_lock_irqsave(dev-event_lock, flags);
  
   /* wakeup userspace */
 @@ -127,6 +126,7 @@ static void vblank_cb(void *arg)
   drm_send_vblank_event(dev, -1, omap_crtc-event);
  
   omap_crtc-event = NULL;
 + omap_crtc-old_fb = NULL;

Is old_fb used anywhere? If not we could just remove it.

Otherwise nice work! On the series:

Reviewed-by: Imre Deak imre.d...@intel.com

  
   spin_unlock_irqrestore(dev-event_lock, flags);
  }
 @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg)
   struct drm_framebuffer *old_fb = omap_crtc-old_fb;
   struct drm_gem_object *bo;
  
 - omap_crtc-old_fb = NULL;
 -
   omap_crtc_mode_set_base(crtc, crtc-x, crtc-y, old_fb);
  
   /* really we'd like to setup the callback atomically w/ setting the
 @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc 
 *crtc,
  
   DBG(%d - %d, crtc-fb ? crtc-fb-base.id : -1, fb-base.id);
  
 - if (omap_crtc-event) {
 + if (omap_crtc-old_fb) {
   dev_err(dev-dev, already a pending flip\n);
   return -EINVAL;
   }


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


Re: [PATCH 11/11] drm/omap: page-flip fixes

2012-10-09 Thread Imre Deak
On Tue, 2012-10-09 at 12:35 +0300, Imre Deak wrote:
 On Mon, 2012-10-08 at 14:50 -0500, Rob Clark wrote:
  From: Rob Clark r...@ti.com
  
  Userspace might not request a vblank event.  So it is not an error
  for 'event' to be NULL, and we shouldn't use it to determine if
  there is a pending flip already.
  
  Signed-off-by: Rob Clark r...@ti.com
  ---
   drivers/staging/omapdrm/omap_crtc.c |6 ++
   1 file changed, 2 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/staging/omapdrm/omap_crtc.c 
  b/drivers/staging/omapdrm/omap_crtc.c
  index 74e019a..317b854 100644
  --- a/drivers/staging/omapdrm/omap_crtc.c
  +++ b/drivers/staging/omapdrm/omap_crtc.c
  @@ -119,7 +119,6 @@ static void vblank_cb(void *arg)
  struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
  unsigned long flags;
   
  -   WARN_ON(!event);
  spin_lock_irqsave(dev-event_lock, flags);
   
  /* wakeup userspace */
  @@ -127,6 +126,7 @@ static void vblank_cb(void *arg)
  drm_send_vblank_event(dev, -1, omap_crtc-event);
   
  omap_crtc-event = NULL;
  +   omap_crtc-old_fb = NULL;
 
 Is old_fb used anywhere? If not we could just remove it.
 
 Otherwise nice work! On the series:
 
 Reviewed-by: Imre Deak imre.d...@intel.com
 
   
  spin_unlock_irqrestore(dev-event_lock, flags);
   }
  @@ -138,8 +138,6 @@ static void page_flip_cb(void *arg)
  struct drm_framebuffer *old_fb = omap_crtc-old_fb;
  struct drm_gem_object *bo;
   
  -   omap_crtc-old_fb = NULL;
  -
  omap_crtc_mode_set_base(crtc, crtc-x, crtc-y, old_fb);
   
  /* really we'd like to setup the callback atomically w/ setting the
  @@ -162,7 +160,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc 
  *crtc,
   
  DBG(%d - %d, crtc-fb ? crtc-fb-base.id : -1, fb-base.id);
   
  -   if (omap_crtc-event) {
  +   if (omap_crtc-old_fb) {

Ah, just noticed this adds the use for it :) So ignore my comment above.

--Imre

  dev_err(dev-dev, already a pending flip\n);
  return -EINVAL;
  }
 


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


Re: [RFC 1/4] time: export getnstime_raw_and_real for DRM

2012-10-09 Thread Imre Deak
On Fri, 2012-10-05 at 12:14 -0400, Kristian Høgsberg wrote:
 On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak imre.d...@intel.com wrote:
  Needed by the upcoming DRM raw monotonic timestamp support.
 
 I just had a quick look at driver/input/evdev.c, since evdev devices
 did a similar change recently to allow evdev timestamp from the
 monotonic clock.  They're using a different time API:
 
   time_mono = ktime_get();
 time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());
 
 and
 
 event-time = ktime_to_timeval(client-clkid == CLOCK_MONOTONIC ?
   mono : real);
 
 I'm not really up-to-date on kernel time APIs, but I wonder if that
 may be better?  At least, I suspect we wouldn't need changes outside
 drm if we use this API.


Thanks, I will use this instead of getnstime_raw_and_real.

The reason is as discussed on #intel-gfx that this provides a monotonic
vs. raw monotonic time and that as you say it won't require a change in
the time keeping code.

--Imre

 
 Kristian
 
 
  Signed-off-by: Imre Deak imre.d...@intel.com
  ---
   kernel/time/timekeeping.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
  index d3b91e7..073d262 100644
  --- a/kernel/time/timekeeping.c
  +++ b/kernel/time/timekeeping.c
  @@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts)
   }
   EXPORT_SYMBOL_GPL(ktime_get_ts);
 
  -#ifdef CONFIG_NTP_PPS
  +#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || 
  defined(CONFIG_DRM_MODULE)
 
   /**
* getnstime_raw_and_real - get day and raw monotonic time in timespec 
  format
  --
  1.7.9.5
 


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


[PATCH v2] Documentation: kernel-parameters.txt Add drm_kms_helper.poll

2012-10-09 Thread mika . kuoppala
From: Mika Kuoppala mika.kuopp...@intel.com

Possibility to disable polling to find connected displays was
introduced by commit [1]:

commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Fri Aug 20 09:13:36 2010 +0100

drm/kms: Add a module parameter to disable polling

Add description for this parameter to kernel-parameters.txt

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9

Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
 Documentation/kernel-parameters.txt |   16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index f777fa9..0f0f071 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -741,6 +741,22 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
if its name and a colon are prepended to the EDID
name.
 
+   drm_kms_helper.poll=
+   Polling for connected display devices on older systems
+   without Hot Plug Detect (HPD) support, can be quite
+   expensive. Poll will happen periodically and can in
+   worst cases take several hundred milliseconds,
+   depending on the hardware. This will cause visible
+   stalls, for example in video playback. These stalls
+   might happen even when your video is on HDP output
+   but you have other non HDP outputs in your hw
+   configuration. If you experience stalls in display
+   output occurring every 10 seconds, disabling polling
+   might help. With polling disabled you need to manually
+   use xrandr to trigger detection.
+   Format: bool  (1/Y/y=enable, 0/N/n=disable)
+   default: enabled
+
dscc4.setup=[NET]
 
dyndbg[=val]  [KNL,DYNAMIC_DEBUG]
-- 
1.7.9.5

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


[PATCH] drm: Fix kdoc comment for drm_crtc_convert_umode

2012-10-09 Thread mika . kuoppala
From: Mika Kuoppala mika.kuopp...@intel.com

Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
 drivers/gpu/drm/drm_crtc.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ef1b221..bb4c686 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1148,9 +1148,9 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
 }
 
 /**
- * drm_crtc_convert_to_umode - convert a modeinfo into a drm_display_mode
- * @out: drm_display_mode to return to the user
- * @in: drm_mode_modeinfo to use
+ * drm_crtc_convert_umode - convert a modeinfo into a drm_display_mode
+ * @out: drm_display_mode to return to the caller
+ * @in: drm_mode_modeinfo from user
  *
  * LOCKING:
  * None.
-- 
1.7.9.5

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


[PATCH] drm: Add missing break in the command line mode parsing code

2012-10-09 Thread Damien Lespiau
From: Damien Lespiau damien.lesp...@intel.com

As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/drm_modes.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 28637c1..50bd5c1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1054,6 +1054,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
was_digit = false;
} else
goto done;
+   break;
case '0' ... '9':
was_digit = true;
break;
-- 
1.7.7.5

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


[PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2

2012-10-09 Thread Christian König
We want to use VMs without the IB pool in the future.

v2: also remove it from radeon_vm_finish.

Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/radeon.h  |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c |   34 +++---
 drivers/gpu/drm/radeon/radeon_kms.c  |   22 +-
 3 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index bc6b56b..54cf9b5 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1848,7 +1848,7 @@ extern void radeon_ttm_set_active_vram_size(struct 
radeon_device *rdev, u64 size
  */
 int radeon_vm_manager_init(struct radeon_device *rdev);
 void radeon_vm_manager_fini(struct radeon_device *rdev);
-int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
+void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
 void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
 int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
 struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index b36b615..80f0331 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -602,7 +602,6 @@ int radeon_vm_evict(struct radeon_device *rdev, struct 
radeon_vm *vm)
  * @vm: vm to bind
  *
  * Allocate a page table for the requested vm (cayman+).
- * Also starts to populate the page table.
  * Returns 0 for success, error for failure.
  *
  * Global and local mutex must be locked!
@@ -655,8 +654,7 @@ retry:
}
 
list_add_tail(vm-list, rdev-vm_manager.lru_vm);
-   return radeon_vm_bo_update_pte(rdev, vm, rdev-ring_tmp_bo.bo,
-  rdev-ring_tmp_bo.bo-tbo.mem);
+   return 0;
 }
 
 /**
@@ -1241,30 +1239,15 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,
  * @rdev: radeon_device pointer
  * @vm: requested vm
  *
- * Init @vm (cayman+).
- * Map the IB pool and any other shared objects into the VM
- * by default as it's used by all VMs.
- * Returns 0 for success, error for failure.
+ * Init @vm fields (cayman+).
  */
-int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm)
+void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm)
 {
-   struct radeon_bo_va *bo_va;
-   int r;
-
vm-id = 0;
vm-fence = NULL;
mutex_init(vm-mutex);
INIT_LIST_HEAD(vm-list);
INIT_LIST_HEAD(vm-va);
-
-   /* map the ib pool buffer at 0 in virtual address space, set
-* read only
-*/
-   bo_va = radeon_vm_bo_add(rdev, vm, rdev-ring_tmp_bo.bo);
-   r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET,
- RADEON_VM_PAGE_READABLE |
- RADEON_VM_PAGE_SNOOPED);
-   return r;
 }
 
 /**
@@ -1286,17 +1269,6 @@ void radeon_vm_fini(struct radeon_device *rdev, struct 
radeon_vm *vm)
radeon_vm_free_pt(rdev, vm);
mutex_unlock(rdev-vm_manager.lock);
 
-   /* remove all bo at this point non are busy any more because unbind
-* waited for the last vm fence to signal
-*/
-   r = radeon_bo_reserve(rdev-ring_tmp_bo.bo, false);
-   if (!r) {
-   bo_va = radeon_vm_bo_find(vm, rdev-ring_tmp_bo.bo);
-   list_del_init(bo_va-bo_list);
-   list_del_init(bo_va-vm_list);
-   radeon_bo_unreserve(rdev-ring_tmp_bo.bo);
-   kfree(bo_va);
-   }
if (!list_empty(vm-va)) {
dev_err(rdev-dev, still active bo inside vm\n);
}
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index cb8e94d..c97d49b 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -420,6 +420,7 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
/* new gpu have virtual address space support */
if (rdev-family = CHIP_CAYMAN) {
struct radeon_fpriv *fpriv;
+   struct radeon_bo_va *bo_va;
int r;
 
fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
@@ -427,7 +428,15 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
return -ENOMEM;
}
 
-   r = radeon_vm_init(rdev, fpriv-vm);
+   radeon_vm_init(rdev, fpriv-vm);
+
+   /* map the ib pool buffer read only into
+* virtual address space */
+   bo_va = radeon_vm_bo_add(rdev, fpriv-vm,
+rdev-ring_tmp_bo.bo);
+   r = radeon_vm_bo_set_addr(rdev, bo_va, RADEON_VA_IB_OFFSET,
+ RADEON_VM_PAGE_READABLE |
+ 

[PATCH 1/3] drm/radeon: allocate page tables on demand v4

2012-10-09 Thread Christian König
Based on Dmitries work, but splitting the code into page
directory and page table handling makes it far more
readable and (hopefully) more reliable.

Allocations of page tables are made from the SA on demand,
that should still work fine since all page tables are of
the same size.

Also using the fact that allocations from the SA are mostly
continuously (except for end of buffer wraps and under very
high memory pressure) to group updates send to the chipset
specific code into larger chunks.

v3: mostly a rewrite of Dmitries previous patch.
v4: fix some typos and coding style

Signed-off-by: Dmitry Cherkasov dmitrii.cherka...@amd.com
Signed-off-by: Christian König deathsim...@vodafone.de
Tested-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/ni.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h  |   11 +-
 drivers/gpu/drm/radeon/radeon_gart.c |  322 ++
 3 files changed, 262 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9a46f7d..48e2337 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1576,7 +1576,7 @@ void cayman_vm_flush(struct radeon_device *rdev, int 
ridx, struct radeon_vm *vm)
radeon_ring_write(ring, 0);
 
radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_END_ADDR + 
(vm-id  2), 0));
-   radeon_ring_write(ring, vm-last_pfn);
+   radeon_ring_write(ring, rdev-vm_manager.max_pfn);
 
radeon_ring_write(ring, PACKET0(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm-id  2), 0));
radeon_ring_write(ring, vm-pd_gpu_addr  12);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b04c064..bc6b56b 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -663,9 +663,14 @@ struct radeon_vm {
struct list_headlist;
struct list_headva;
unsignedid;
-   unsignedlast_pfn;
-   u64 pd_gpu_addr;
-   struct radeon_sa_bo *sa_bo;
+
+   /* contains the page directory */
+   struct radeon_sa_bo *page_directory;
+   uint64_tpd_gpu_addr;
+
+   /* array of page tables, one for each page directory entry */
+   struct radeon_sa_bo **page_tables;
+
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 753b7ca..b36b615 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -423,6 +423,18 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */
 
 /**
+ * radeon_vm_num_pde - return the number of page directory entries
+ *
+ * @rdev: radeon_device pointer
+ *
+ * Calculate the number of page directory entries (cayman+).
+ */
+static unsigned radeon_vm_num_pdes(struct radeon_device *rdev)
+{
+   return rdev-vm_manager.max_pfn  RADEON_VM_BLOCK_SIZE;
+}
+
+/**
  * radeon_vm_directory_size - returns the size of the page directory in bytes
  *
  * @rdev: radeon_device pointer
@@ -431,7 +443,7 @@ void radeon_gart_fini(struct radeon_device *rdev)
  */
 static unsigned radeon_vm_directory_size(struct radeon_device *rdev)
 {
-   return (rdev-vm_manager.max_pfn  RADEON_VM_BLOCK_SIZE) * 8;
+   return RADEON_GPU_PAGE_ALIGN(radeon_vm_num_pdes(rdev) * 8);
 }
 
 /**
@@ -451,11 +463,11 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
 
if (!rdev-vm_manager.enabled) {
/* allocate enough for 2 full VM pts */
-   size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
-   size += RADEON_GPU_PAGE_ALIGN(rdev-vm_manager.max_pfn * 8);
+   size = radeon_vm_directory_size(rdev);
+   size += rdev-vm_manager.max_pfn * 8;
size *= 2;
r = radeon_sa_bo_manager_init(rdev, 
rdev-vm_manager.sa_manager,
- size,
+ RADEON_GPU_PAGE_ALIGN(size),
  RADEON_GEM_DOMAIN_VRAM);
if (r) {
dev_err(rdev-dev, failed to allocate vm bo (%dKB)\n,
@@ -476,7 +488,7 @@ int radeon_vm_manager_init(struct radeon_device *rdev)
 
/* restore page table */
list_for_each_entry(vm, rdev-vm_manager.lru_vm, list) {
-   if (vm-sa_bo == NULL)
+   if (vm-page_directory == NULL)
continue;
 
list_for_each_entry(bo_va, vm-va, vm_list) {
@@ -500,16 +512,25 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
 {
struct 

[PATCH 3/3] drm/radeon: separate pt alloc from lru add

2012-10-09 Thread Christian König
Make it possible to allocate a persistent page table.

Signed-off-by: Christian König deathsim...@vodafone.de
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon.h  |1 +
 drivers/gpu/drm/radeon/radeon_cs.c   |1 +
 drivers/gpu/drm/radeon/radeon_gart.c |   20 
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 54cf9b5..8c42d54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1851,6 +1851,7 @@ void radeon_vm_manager_fini(struct radeon_device *rdev);
 void radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm);
 void radeon_vm_fini(struct radeon_device *rdev, struct radeon_vm *vm);
 int radeon_vm_alloc_pt(struct radeon_device *rdev, struct radeon_vm *vm);
+void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm);
 struct radeon_fence *radeon_vm_grab_id(struct radeon_device *rdev,
   struct radeon_vm *vm, int ring);
 void radeon_vm_fence(struct radeon_device *rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index d59eb59..023c67d 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -478,6 +478,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
}
 
 out:
+   radeon_vm_add_to_lru(rdev, vm);
mutex_unlock(vm-mutex);
mutex_unlock(rdev-vm_manager.lock);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 80f0331..08e0ddc 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -617,9 +617,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct 
radeon_vm *vm)
}
 
if (vm-page_directory != NULL) {
-   /* update lru */
-   list_del_init(vm-list);
-   list_add_tail(vm-list, rdev-vm_manager.lru_vm);
return 0;
}
 
@@ -653,11 +650,26 @@ retry:
return -ENOMEM;
}
 
-   list_add_tail(vm-list, rdev-vm_manager.lru_vm);
return 0;
 }
 
 /**
+ * radeon_vm_add_to_lru - add VMs page table to LRU list
+ *
+ * @rdev: radeon_device pointer
+ * @vm: vm to add to LRU
+ *
+ * Add the allocated page table to the LRU list (cayman+).
+ *
+ * Global mutex must be locked!
+ */
+void radeon_vm_add_to_lru(struct radeon_device *rdev, struct radeon_vm *vm)
+{
+   list_del_init(vm-list);
+   list_add_tail(vm-list, rdev-vm_manager.lru_vm);
+}
+
+/**
  * radeon_vm_grab_id - allocate the next free VMID
  *
  * @rdev: radeon_device pointer
-- 
1.7.9.5

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


Re: [PATCH 2/3] drm/radeon: don't add the IB pool to all VMs v2

2012-10-09 Thread Michel Dänzer
On Die, 2012-10-09 at 13:31 +0200, Christian König wrote: 
 We want to use VMs without the IB pool in the future.
 
 v2: also remove it from radeon_vm_finish.
 
 Signed-off-by: Christian König deathsim...@vodafone.de

Reviewed-by: Michel Dänzer michel.daen...@amd.com


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 1/3] drm: Add user-defined EDID quirks capability

2012-10-09 Thread Jani Nikula
On Fri, 28 Sep 2012, Ian Pilcher arequip...@gmail.com wrote:
 Add the ability for users to define their own EDID quirks via a
 module parameter or sysfs attribute.

Hi Ian -

IMHO this patch should be chopped up to smaller pieces. For example,
change the edid_quirk_list format first (if you must), then add module
parameter support, then add sysfs support, in separate patches. It'll be
easier to review.

Please see some other comments inline.

BR,
Jani.


 Signed-off-by: Ian Pilcher arequip...@gmail.com
 ---
  Documentation/EDID/edid_quirks.txt | 126 ++
  drivers/gpu/drm/drm_drv.c  |   2 +
  drivers/gpu/drm/drm_edid.c | 500 
 -
  drivers/gpu/drm/drm_stub.c |   6 +
  drivers/gpu/drm/drm_sysfs.c|  19 ++
  include/drm/drmP.h |  10 +
  include/drm/drm_edid.h |  13 +-
  7 files changed, 615 insertions(+), 61 deletions(-)
  create mode 100644 Documentation/EDID/edid_quirks.txt

 diff --git a/Documentation/EDID/edid_quirks.txt 
 b/Documentation/EDID/edid_quirks.txt
 new file mode 100644
 index 000..0c9c746
 --- /dev/null
 +++ b/Documentation/EDID/edid_quirks.txt
 @@ -0,0 +1,126 @@
 +  EDID Quirks
 + =
 +   Ian Pilcher arequip...@gmail.com
 +August 11, 2012
 +
 +
 +EDID blocks out in the wild have a variety of bugs
 +-- from drivers/gpu/drm/drm_edid.c
 +
 +
 +Overview
 +
 +
 +EDID quirks provide a mechanism for working around display hardware with 
 buggy
 +EDID data.
 +
 +An individual EDID quirk maps a display type (identified by its EDID
 +manufacturer ID and product code[1]) to a set of quirk flags.  The kernel
 +includes a variety of built-in quirks.  (They are stored in the 
 edid_quirk_list
 +array in drivers/gpu/drm/drm_edid.c.)
 +
 +An example of a built-in EDID quirk is:
 +
 +ACR:0xad46:0x0001
 +
 +The first field is the manufacturer ID (Acer, Inc.), the second field is the
 +manufacturer's product code, and the third field contains the quirk flags for
 +that display type.
 +
 +The quirk flags are defined in drivers/gpu/drm/drm_edid.c.  Each flag has a
 +symbolic name beginning with EDID_QUIRK_, along with a numerical value.  Each
 +flag should also have an associated comment which provides an idea of its
 +effect.  Note that the values in the source file are expressed as bit 
 shifts[2]:
 +
 +* 1  0: 0x0001
 +* 1  1: 0x0002
 +* 1  2: 0x0004
 +* etc.
 +
 +
 +sysfs interface
 +===
 +
 +The current EDID quirk list can be read from /sys/class/drm/edid_quirks:
 +
 +# cat /sys/class/drm/edid_quirks
 +   ACR:0xad46:0x0001
 +   API:0x7602:0x0001
 +   ACR:0x0977:0x0020
 +0x9e6a:0x077e:0x0080
 +...
 +
 +(Nonconformant manufacturer IDs are displayed as hexadecimal values.)
 +
 +The number of total slots in the list can be read from
 +/sys/class/drm/edid_quirks_size.  This total includes both occupied slots 
 (i.e.
 +the current list) and any slots available for additional quirks.  The number 
 of
 +available slots can be calculated by subtracting the number of quirks in the
 +current list from the total number of slots.
 +
 +If a slot is available, an additional quirk can be added to the list by 
 writing
 +it to /sys/class/drm/edid_quirks:
 +
 +# echo FOO:0x:0x100  /sys/class/drm/edid_quirks
 +
 +Manufacturer IDs can also be specified numerically.  (This is the only way to
 +specify a nonconformant ID.) This command is equivalent to the previous one:
 +
 +# echo 0x19ef:0x:0x100  /sys/class/drm/edid_quirks
 +
 +Numeric values can also be specified in decimal or octal formats; a number 
 that
 +begins with a 0 is assumed to be octal:
 +
 +# echo FOO:65535:0400  /sys/class/drm/edid_quirks
 +
 +An existing quirk can be replaced by writing a new set of flags:
 +
 +# echo FOO:0x:0x200  /sys/class/drm/edid_quirks
 +
 +A quirk can be deleted from the list by writing an empty flag set (0). This
 +makes the slot occupied by that quirk available.
 +
 +# echo FOO:0x:0  /sys/class/drm/edid_quirks
 +
 +Writing an at symbol (@) clears the entire quirk list:
 +
 +# echo @  /sys/class/drm/edid_quirks
 +
 +Multiple changes to the list can be specified in a comma (or newline) 
 separated
 +list. For example, the following command clears all of the existing quirks in
 +the list and adds 3 new quirks:
 +
 +# echo @,FOO:0x:0x100,BAR:0x:0x001,BAZ:0x:0x002  \
 +/sys/class/drm/edid_quirks
 +
 +Note however, that any error (an incorrectly formatted quirk or an attempt to
 +add a quirk when no slot is available) will abort processing of any further
 +changes, potentially making it difficult to determine exactly which change
 +caused the error and what changes were made.  For this reason, making changes
 +one at a time is recommended, particularly 

Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Alex Deucher
On Tue, Oct 9, 2012 at 2:26 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
 Am Montag, den 08.10.2012, 17:48 -0400 schrieb alexdeuc...@gmail.com:
 From: Alex Deucher alexander.deuc...@amd.com

 If so, skip enabling it.

 Does that fix any error/problem or is it just for speed reasons?

It doesn't fix anything that I know of.  Just speed.

Alex


 Signed-off-by: Alex Deucher alexander.deuc...@amd.com
 ---
  drivers/gpu/drm/radeon/evergreen.c |8 ++--
  drivers/gpu/drm/radeon/r600.c  |7 ++-
  2 files changed, 12 insertions(+), 3 deletions(-)

 […]


 Thanks,

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


Re: [PATCH] drm/radeon: check if pcie gen 2 is already enabled

2012-10-09 Thread Alex Deucher
On Tue, Oct 9, 2012 at 3:05 AM, Rafał Miłecki zaj...@gmail.com wrote:
 2012/10/8  alexdeuc...@gmail.com:
 +   if (speed_cntl  LC_CURRENT_DATA_RATE) {
 +   DRM_INFO(PCIE gen 2 link speeds already enabled\n);
 +   return;
 +   } else
 +   DRM_INFO(enabling PCIE gen 2 link speeds, disable with 
 radeon.pcie_gen2=0\n);
 +

 See documentation/CodingStyle:

 This does not apply if only one branch of a conditional statement is a single
 statement; in the latter case use braces in both branches:

 Your else should use braces :)

I'll fix that up.

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


[PATCH] drm/radeon: check if pcie gen 2 is already enabled (v2)

2012-10-09 Thread alexdeucher
From: Alex Deucher alexander.deuc...@amd.com

If so, skip enabling it to save time.

v2: coding style fixes

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen.c |7 ++-
 drivers/gpu/drm/radeon/r600.c  |6 ++
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index a1f49c5..14313ad 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3431,9 +3431,14 @@ void evergreen_pcie_gen2_enable(struct radeon_device 
*rdev)
if (!(mask  DRM_PCIE_SPEED_50))
return;
 
+   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
+   if (speed_cntl  LC_CURRENT_DATA_RATE) {
+   DRM_INFO(PCIE gen 2 link speeds already enabled\n);
+   return;
+   }
+
DRM_INFO(enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0\n);
 
-   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
if ((speed_cntl  LC_OTHER_SIDE_EVER_SENT_GEN2) ||
(speed_cntl  LC_OTHER_SIDE_SUPPORTS_GEN2)) {
 
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 70c800f..cda280d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3703,6 +3703,12 @@ static void r600_pcie_gen2_enable(struct radeon_device 
*rdev)
if (!(mask  DRM_PCIE_SPEED_50))
return;
 
+   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
+   if (speed_cntl  LC_CURRENT_DATA_RATE) {
+   DRM_INFO(PCIE gen 2 link speeds already enabled\n);
+   return;
+   }
+
DRM_INFO(enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0\n);
 
/* 55 nm r6xx asics */
-- 
1.7.7.5

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


[Bug 55809] New: omap_drm: fix locking bug on error path

2012-10-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55809

  Priority: medium
Bug ID: 55809
  Assignee: dri-devel@lists.freedesktop.org
   Summary: omap_drm: fix locking bug on error path
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: vinc...@collabora.co.uk
  Hardware: ARM
Status: NEW
   Version: XOrg CVS
 Component: libdrm
   Product: DRI

Created attachment 68338
  -- https://bugs.freedesktop.org/attachment.cgi?id=68338action=edit
Fix for locking bug on error paths

omap_drm.c has a couple places where a lock is not released on an error path,
but should be.

-- 
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 55809] omap_drm: fix locking bug on error path

2012-10-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55809

Rob Clark r...@ti.com changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |r...@ti.com
   |.org|

-- 
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 v5 0/3] Enhanced EDID quirk functionality

2012-10-09 Thread Adam Jackson

On 10/8/12 7:22 PM, Ian Pilcher wrote:

On 09/28/2012 02:03 AM, Ian Pilcher wrote:

As promised, this patch series does only the following:

* Add user-defined EDID quirks -- via sysfs or a module parameter
* Add an EDID quirk flag to disable all HDMI functionality
   (InfoFrames)
* Add a quirk to disable HDMI InfoFrames for the LG L246WP



ACK?  NACK?  I'm on crack?

(I'm starting to think that this is some sort of hazing ritual.)


Sorry, I'm just not paying close attention to EDID stuff at the moment.

The series as is is clearly better than what we've got.  I still think 
there's something fundamentally amiss with a display that doesn't want 
to accept InfoFrames, but without having it in hand to mess with - and 
without wanting to play telephone to figure it out - I'm fine with this.


Reviewed-by: Adam Jackson a...@redhat.com

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


[PATCH] drm: avoid passing null pointer to memset

2012-10-09 Thread Rodrigo Vivi
When cmd isn't IOC_IN | IOC_OUT a null kdata goes to memset, which 
dereferences it.

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
 drivers/gpu/drm/drm_drv.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 1490e76..5945920 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -452,8 +452,16 @@ long drm_ioctl(struct file *filp,
retcode = -EFAULT;
goto err_i1;
}
-   } else
+   } else {
+   if (!kdata) {
+   kdata = kmalloc(usize, GFP_KERNEL);
+   if (!kdata) {
+   retcode = -ENOMEM;
+   goto err_i1;
+   }
+   }
memset(kdata, 0, usize);
+   }
 
if (ioctl-flags  DRM_UNLOCKED)
retcode = func(dev, kdata, file_priv);
-- 
1.7.11.4

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


[PATCH] drm/omap: fix allocation size for page addresses array

2012-10-09 Thread Vincent Penquerc'h
Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/omap_gem.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index c828743..4c1472c 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 * DSS, GPU, etc. are not cache coherent:
 */
if (omap_obj-flags  (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-   addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
@@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
}
} else {
-   addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
-- 
1.7.9.5

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


Re: [PATCH] drm: avoid passing null pointer to memset

2012-10-09 Thread Chris Wilson
On Tue,  9 Oct 2012 14:50:46 -0300, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
 When cmd isn't IOC_IN | IOC_OUT a null kdata goes to memset, which 
 dereferences it.
 
usize should be 0 in that case, since the ioctl is neither copying data
in or out, for example I915_GEM_THROTTLE. To be on the safe side:
if (IOC_IN | IOC_OUT) { /* blah */ } else usize = 0;
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/omap: fix allocation size for page addresses array

2012-10-09 Thread Vincent Penquerc'h
Signed-off-by: Rob Clark r...@ti.com
Signed-off-by: Vincent Penquerc'h vincent.penque...@collabora.co.uk
---
 drivers/staging/omapdrm/omap_gem.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index c828743..4c1472c 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -246,7 +246,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
 * DSS, GPU, etc. are not cache coherent:
 */
if (omap_obj-flags  (OMAP_BO_WC|OMAP_BO_UNCACHED)) {
-   addrs = kmalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kmalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
@@ -257,7 +257,7 @@ static int omap_gem_attach_pages(struct drm_gem_object *obj)
0, PAGE_SIZE, DMA_BIDIRECTIONAL);
}
} else {
-   addrs = kzalloc(npages * sizeof(addrs), GFP_KERNEL);
+   addrs = kzalloc(npages * sizeof(*addrs), GFP_KERNEL);
if (!addrs) {
ret = -ENOMEM;
goto free_pages;
-- 
1.7.9.5

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


[PATCH] drm: avoid passing null pointer to memset

2012-10-09 Thread Rodrigo Vivi
When cmd isn't IOC_IN | IOC_OUT a null kdata goes to memset, which 
dereferences it.

v2: simpler version just using usize = 0 instead of allocating useless memory

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
 drivers/gpu/drm/drm_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 1490e76..f72dce5 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -444,7 +444,8 @@ long drm_ioctl(struct file *filp,
}
if (asize  usize)
memset(kdata + usize, 0, asize - usize);
-   }
+   } else
+   usize = 0;
 
if (cmd  IOC_IN) {
if (copy_from_user(kdata, (void __user *)arg,
-- 
1.7.11.4

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


[Bug 55819] Mouse cursor corruption when moving between monitors

2012-10-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55819

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

   What|Removed |Added

   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
 QA Contact|xorg-t...@lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #5 from Alex Deucher ag...@yahoo.com ---
What kernel are you using?  Make sure it has this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f60ec4c7df043df81e62891ac45383d012afe0da

-- 
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 40211] texture probleme in wolfenstein enemy territory rv770

2012-10-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=40211

pitam...@free.fr changed:

   What|Removed |Added

  Attachment #50399|0   |1
is obsolete||

--- Comment #8 from pitam...@free.fr ---
Created attachment 68363
  -- https://bugs.freedesktop.org/attachment.cgi?id=68363action=edit
my glxinfo output with mesa 8.0.4

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


[Bug 40211] texture probleme in wolfenstein enemy territory rv770

2012-10-09 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=40211

pitam...@free.fr changed:

   What|Removed |Added

Version|7.10|8.0

--- Comment #9 from pitam...@free.fr ---
Hi,

I updated my Debian Sid distro to mesa 8.0.4
unfortunately, Enemy Territory continue to have
- texture blinking
- error in drawing landscapes (I can see thru the walls)
- many objects (all the screen when enterring limbo menu)
appearing only a fraction of second then disappearing

Tell me if I can do any testing or provide some more log
to help diagnose the pb.

-- 
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 10/11] drm/omap: use drm_send_vblank_event() helper

2012-10-09 Thread Mario Kleiner

On 08.10.12 21:50, Rob Clark wrote:

From: Rob Clark r...@ti.com

Signed-off-by: Rob Clark r...@ti.com
---
  drivers/staging/omapdrm/omap_crtc.c |   31 ++-
  1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 732f2ad..74e019a 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -114,40 +114,21 @@ static void omap_crtc_load_lut(struct drm_crtc *crtc)

  static void vblank_cb(void *arg)
  {
-   static uint32_t sequence = 0;
struct drm_crtc *crtc = arg;
struct drm_device *dev = crtc-dev;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   struct drm_pending_vblank_event *event = omap_crtc-event;
unsigned long flags;
-   struct timeval now;

WARN_ON(!event);
+   spin_lock_irqsave(dev-event_lock, flags);
+
+   /* wakeup userspace */
+   if (omap_crtc-event)
+   drm_send_vblank_event(dev, -1, omap_crtc-event);

omap_crtc-event = NULL;

-   /* wakeup userspace */
-   if (event) {
-   do_gettimeofday(now);
-
-   spin_lock_irqsave(dev-event_lock, flags);
-   /* TODO: we can't yet use the vblank time accounting,
-* because omapdss lower layer is the one that knows
-* the irq # and registers the handler, which more or
-* less defeats how drm_irq works.. for now just fake
-* the sequence number and use gettimeofday..
-*
-   event-event.sequence = drm_vblank_count_and_time(
-   dev, omap_crtc-id, now);
-*/


I think this TOO comment should be retained as a reminder that there is 
work to do.



-   event-event.sequence = sequence++;


This is problematic. You lose the pseudo vblank counter implemented 
here, which is a violation of the spec, and from my own experience it 
causes extra pain and the need for awful workarounds in userspace 
clients. Nouveau-kms has the same problem for no good reason.


But then, on second thought, the way it is implemented here in the 
original is even more wrong, returning zero might be better.


-mario



-   event-event.tv_sec = now.tv_sec;
-   event-event.tv_usec = now.tv_usec;
-   list_add_tail(event-base.link,
-   event-base.file_priv-event_list);
-   wake_up_interruptible(event-base.file_priv-event_wait);
-   spin_unlock_irqrestore(dev-event_lock, flags);
-   }
+   spin_unlock_irqrestore(dev-event_lock, flags);
  }

  static void page_flip_cb(void *arg)


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