[Bug 54581] Radeon: Failed to parse relocation, gem object lookup failed
https://bugzilla.kernel.org/show_bug.cgi?id=54581 --- Comment #1 from Alexander Mezin 2013-02-28 09:30:28 --- Created an attachment (id=94231) --> (https://bugzilla.kernel.org/attachment.cgi?id=94231) Syslog Video cards: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Subsystem: Hewlett-Packard Company Device 3388 Kernel driver in use: i915 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler XT [AMD Radeon HD 6700M Series] (rev ff) Kernel driver in use: radeon -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #28 from Marek Olšák --- Andreas Boll requested a branch of all my latest Mesa patches for people to test it. It's here: git://people.freedesktop.org/~mareko/mesa master -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not.
This will allow me to call functions that have multiple arguments if fastpath
fails.
This is required to support ticket mutexes, because they need to be able to
pass an
extra argument to the fail function.
Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg.
This ended up being just a duplication of the existing function, so a way to
test
if fastpath was called ended up being better.
This also cleaned up the reservation mutex patch some by being able to call an
atomic_set instead of atomic_xchg, and making it easier to detect if the wrong
unlock function was previously used.
Signed-off-by: Maarten Lankhorst
---
arch/ia64/include/asm/mutex.h| 10 --
arch/powerpc/include/asm/mutex.h | 10 --
arch/sh/include/asm/mutex-llsc.h |4 ++--
arch/x86/include/asm/mutex_32.h | 11 ---
arch/x86/include/asm/mutex_64.h | 11 ---
include/asm-generic/mutex-dec.h | 10 --
include/asm-generic/mutex-null.h |2 +-
include/asm-generic/mutex-xchg.h | 10 --
kernel/mutex.c | 32 ++--
9 files changed, 41 insertions(+), 59 deletions(-)
diff --git a/arch/ia64/include/asm/mutex.h b/arch/ia64/include/asm/mutex.h
index bed73a6..f41e66d 100644
--- a/arch/ia64/include/asm/mutex.h
+++ b/arch/ia64/include/asm/mutex.h
@@ -29,17 +29,15 @@ __mutex_fastpath_lock(atomic_t *count, void
(*fail_fn)(atomic_t *))
* __mutex_fastpath_lock_retval - try to take the lock by moving the count
* from 1 to a 0 value
* @count: pointer of type atomic_t
- * @fail_fn: function to call if the original value was not 1
*
- * Change the count from 1 to a value lower than 1, and call if
- * it wasn't 1 originally. This function returns 0 if the fastpath succeeds,
- * or anything the slow path function returns.
+ * Change the count from 1 to a value lower than 1. This function returns 0
+ * if the fastpath succeeds, or -1 otherwise.
*/
static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count)
{
if (unlikely(ia64_fetchadd4_acq(count, -1) != 1))
- return fail_fn(count);
+ return -1;
return 0;
}
diff --git a/arch/powerpc/include/asm/mutex.h b/arch/powerpc/include/asm/mutex.h
index 5399f7e..127ab23 100644
--- a/arch/powerpc/include/asm/mutex.h
+++ b/arch/powerpc/include/asm/mutex.h
@@ -82,17 +82,15 @@ __mutex_fastpath_lock(atomic_t *count, void
(*fail_fn)(atomic_t *))
* __mutex_fastpath_lock_retval - try to take the lock by moving the count
* from 1 to a 0 value
* @count: pointer of type atomic_t
- * @fail_fn: function to call if the original value was not 1
*
- * Change the count from 1 to a value lower than 1, and call if
- * it wasn't 1 originally. This function returns 0 if the fastpath succeeds,
- * or anything the slow path function returns.
+ * Change the count from 1 to a value lower than 1. This function returns 0
+ * if the fastpath succeeds, or -1 otherwise.
*/
static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count)
{
if (unlikely(__mutex_dec_return_lock(count) < 0))
- return fail_fn(count);
+ return -1;
return 0;
}
diff --git a/arch/sh/include/asm/mutex-llsc.h b/arch/sh/include/asm/mutex-llsc.h
index 090358a..dad29b6 100644
--- a/arch/sh/include/asm/mutex-llsc.h
+++ b/arch/sh/include/asm/mutex-llsc.h
@@ -37,7 +37,7 @@ __mutex_fastpath_lock(atomic_t *count, void
(*fail_fn)(atomic_t *))
}
static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count)
{
int __done, __res;
@@ -51,7 +51,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int
(*fail_fn)(atomic_t *))
: "t");
if (unlikely(!__done || __res != 0))
- __res = fail_fn(count);
+ __res = -1;
return __res;
}
diff --git a/arch/x86/include/asm/mutex_32.h b/arch/x86/include/asm/mutex_32.h
index 03f90c8..b7f6b34 100644
--- a/arch/x86/include/asm/mutex_32.h
+++ b/arch/x86/include/asm/mutex_32.h
@@ -42,17 +42,14 @@ do {
\
* __mutex_fastpath_lock_retval - try to take the lock by moving the count
* from 1 to a 0 value
* @count: pointer of type atomic_t
- * @fail_fn: function to call if the original value was not 1
*
- * Change the count from 1 to a value lower than 1, and call if it
- * wasn't 1 originally. This function returns 0 if the fastpath succeeds,
- * or anything the slow path function returns
+ * Change the count from 1 to a value lower than 1. This function returns 0
+ * if the fastpath succeeds, or 1 otherwise.
*/
-static inline int
[PATCH v2 2/3] mutex: add support for reservation style locks, v2
New version. All of the documentation has been moved from the commit log to
Documentation/reservation-mutex-design.txt
Missing at the moment, maybe TODO?
Add a lockdep check in the *_slow calls that verifies that the lock
being nested into has no nested lock any more? This would be a check
to make sure that mutex_unreserve_unlock has been called on all other
locks correctly.
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex_lock_retval_arg, add warnings when using wrong
combination of
mutex_(,reserve_)lock/unlock.
Changes since v1:
- Add __always_inline to __mutex_lock_common, otherwise reservation paths can
be
triggered from normal locks, because __builtin_constant_p might evaluate to
false
for the constant 0 in that case. Tests for this have been added in the next
patch.
- Updated documentation slightly.
Signed-off-by: Maarten Lankhorst
---
Documentation/reservation-mutex-design.txt | 136
include/linux/mutex.h | 86 +++
kernel/mutex.c | 326 +++-
3 files changed, 531 insertions(+), 17 deletions(-)
create mode 100644 Documentation/reservation-mutex-design.txt
diff --git a/Documentation/reservation-mutex-design.txt
b/Documentation/reservation-mutex-design.txt
new file mode 100644
index 000..4e2866c
--- /dev/null
+++ b/Documentation/reservation-mutex-design.txt
@@ -0,0 +1,136 @@
+Reservation type mutexes
+---
+
+Please read mutex-design.txt first, as it applies to reservation mutexes too.
+
+GPU's do operations that commonly involve many buffers. Those buffers
+can be shared across contexts/processes, exist in different memory
+domains (for example VRAM vs system memory), and so on. And with
+PRIME / dmabuf, they can even be shared across devices. So there are
+a handful of situations where the driver needs to wait for buffers to
+become ready. If you think about this in terms of waiting on a buffer
+mutex for it to become available, this presents a problem because
+there is no way to guarantee that buffers appear in a execbuf/batch in
+the same order in all contexts. That is directly under control of
+userspace, and a result of the sequence of GL calls that an application
+makes. Which results in the potential for deadlock. The problem gets
+more complex when you consider that the kernel may need to migrate the
+buffer(s) into VRAM before the GPU operates on the buffer(s), which
+may in turn require evicting some other buffers (and you don't want to
+evict other buffers which are already queued up to the GPU), but for a
+simplified understanding of the problem you can ignore this.
+
+The algorithm that TTM came up with for dealing with this problem is
+quite simple. For each group of buffers (execbuf) that need to be
+locked, the caller would be assigned a unique reservation_id, from a
+global counter. In case of deadlock while locking all the buffers
+associated with a execbuf, the one with the lowest reservation_id
+wins, and the one with the higher reservation_id unlocks all of the
+buffers that it has already locked, and then tries again.
+
+How it is used:
+---
+
+A very simplified version:
+
+int lock_execbuf(execbuf, ticket)
+{
+struct buf *res_buf = NULL;
+
+/* acquiring locks, before queuing up to GPU: */
+*ticket = assign_global_seqno();
+
+retry:
+for (buf in execbuf->buffers) {
+if (buf == res_buf) {
+res_buf = NULL;
+continue;
+}
+ret = mutex_reserve_lock(&buf->lock, ticket, ticket->seqno);
+if (ret < 0)
+goto err;
+}
+
+/* now everything is good to go, submit job to GPU: */
+...
+
+return 0;
+
+err:
+for (all buf2 before buf in execbuf->buffers)
+mutex_unreserve_unlock(&buf2->lock);
+if (res_buf)
+mutex_unreserve_unlock(&res_buf->lock);
+
+if (ret == -EAGAIN) {
+/* we lost out in a seqno race, lock and retry.. */
+mutex_reserve_lock_slow(&buf->lock, ticket, ticket->seqno);
+res_buf = buf;
+goto retry;
+}
+release_global_seqno(ticket);
+
+return ret;
+}
+
+int unlock_execbuf(execbuf, ticket)
+{
+/* when GPU is finished; */
+for (buf in execbuf->buffers)
+mutex_unreserve_unlock(&buf->lock);
+release_global_seqno(ticket);
+}
+
+Functions:
+--
+
+mutex_reserve_lock, and mutex_reserve_lock_interruptible:
+ Lock a reservation_lock with a reservation_id set. reservation_id must not
+ be set to 0, since this is a special value that means no reservation_id.
+
+ N
[PATCH v2 3/3] reservation: Add tests to lib/locking-selftest.c. v2
This stresses the lockdep code in some ways specifically useful to
reservations. It adds checks for most of the common locking errors.
Since the lockdep tests were originally written to stress the
reservation code, I duplicated some of the definitions into
lib/locking-selftest.c for now.
This will be cleaned up later when the api for reservations is
accepted. I don't expect the tests to change, since the discussion
is mostly about the fence aspect of reservations.
Changes since v1:
- Add tests to verify reservation_id is untouched.
- Use L() and U() macros where possible.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 588 ++--
1 file changed, 569 insertions(+), 19 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index c3eb261..2c52c0e 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -26,6 +26,67 @@
*/
static unsigned int debug_locks_verbose;
+/*
+ * These definitions are from the reservation objects patch series.
+ * For now we have to define it ourselves here. These definitions will
+ * be removed upon acceptance of that patch series.
+ */
+static const char reservation_object_name[] = "reservation_object";
+static struct lock_class_key reservation_object_class;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+static const char reservation_ticket_name[] = "reservation_ticket";
+static struct lock_class_key reservation_ticket_class;
+#endif
+
+struct reservation_object {
+ struct ticket_mutex lock;
+};
+
+struct reservation_ticket {
+ unsigned long seqno;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
+};
+
+static inline void
+reservation_object_init(struct reservation_object *obj)
+{
+ __ticket_mutex_init(&obj->lock, reservation_object_name,
+ &reservation_object_class);
+}
+
+static inline void
+reservation_object_fini(struct reservation_object *obj)
+{
+ mutex_destroy(&obj->lock.base);
+}
+
+static inline void
+reservation_ticket_init(struct reservation_ticket *t)
+{
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ /*
+* Make sure we are not reinitializing a held ticket:
+*/
+
+ debug_check_no_locks_freed((void *)t, sizeof(*t));
+ lockdep_init_map(&t->dep_map, reservation_ticket_name,
+&reservation_ticket_class, 0);
+#endif
+ mutex_acquire(&t->dep_map, 0, 0, _THIS_IP_);
+ t->seqno = 5;
+}
+
+static inline void
+reservation_ticket_fini(struct reservation_ticket *t)
+{
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ mutex_release(&t->dep_map, 0, _THIS_IP_);
+ t->seqno = 0;
+#endif
+}
+
static int __init setup_debug_locks_verbose(char *str)
{
get_option(&str, &debug_locks_verbose);
@@ -42,6 +103,7 @@ __setup("debug_locks_verbose=", setup_debug_locks_verbose);
#define LOCKTYPE_RWLOCK0x2
#define LOCKTYPE_MUTEX 0x4
#define LOCKTYPE_RWSEM 0x8
+#define LOCKTYPE_RESERVATION 0x10
/*
* Normal standalone locks, for the circular and irq-context
@@ -920,11 +982,17 @@ GENERATE_PERMUTATIONS_3_EVENTS(irq_read_recursion_soft)
static void reset_locks(void)
{
local_irq_disable();
+ lockdep_free_key_range(&reservation_object_class, 1);
+ lockdep_free_key_range(&reservation_ticket_class, 1);
+
I1(A); I1(B); I1(C); I1(D);
I1(X1); I1(X2); I1(Y1); I1(Y2); I1(Z1); I1(Z2);
lockdep_reset();
I2(A); I2(B); I2(C); I2(D);
init_shared_classes();
+
+ memset(&reservation_object_class, 0, sizeof(reservation_object_class));
+ memset(&reservation_ticket_class, 0, sizeof(reservation_ticket_class));
local_irq_enable();
}
@@ -938,7 +1006,6 @@ static int unexpected_testcase_failures;
static void dotest(void (*testcase_fn)(void), int expected, int lockclass_mask)
{
unsigned long saved_preempt_count = preempt_count();
- int expected_failure = 0;
WARN_ON(irqs_disabled());
@@ -946,26 +1013,16 @@ static void dotest(void (*testcase_fn)(void), int
expected, int lockclass_mask)
/*
* Filter out expected failures:
*/
+ if (debug_locks != expected) {
#ifndef CONFIG_PROVE_LOCKING
- if ((lockclass_mask & LOCKTYPE_SPIN) && debug_locks != expected)
- expected_failure = 1;
- if ((lockclass_mask & LOCKTYPE_RWLOCK) && debug_locks != expected)
- expected_failure = 1;
- if ((lockclass_mask & LOCKTYPE_MUTEX) && debug_locks != expected)
- expected_failure = 1;
- if ((lockclass_mask & LOCKTYPE_RWSEM) && debug_locks != expected)
- expected_failure = 1;
+ expected_testcase_failures++;
+ printk("failed|");
+#else
+ unexpected_testcase_failures++;
+ printk("FAILED|");
+
+ dump_stack();
#endif
- if (debug_locks != expected) {
- if (expected_failure) {
- expected_testcase_failures
Re: [PATCH v17 2/7] video: add display_timing and videomode
On 2013-02-27 18:05, Steffen Trumtrar wrote: > Ah, sorry. Forgot to answer this. > > On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote: >> Ping. >> >> On 2013-02-18 16:09, Tomi Valkeinen wrote: >>> Hi Steffen, >>> >>> On 2013-01-25 11:01, Steffen Trumtrar wrote: >>> +/* VESA display monitor timing parameters */ +#define VESA_DMT_HSYNC_LOWBIT(0) +#define VESA_DMT_HSYNC_HIGH BIT(1) +#define VESA_DMT_VSYNC_LOWBIT(2) +#define VESA_DMT_VSYNC_HIGH BIT(3) + +/* display specific flags */ +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */ +#define DISPLAY_FLAGS_DE_HIGH BIT(1) +#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(2) /* drive data on pos. edge */ +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(3) /* drive data on neg. edge */ +#define DISPLAY_FLAGS_INTERLACED BIT(4) +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5) >>> >>> >>> + unsigned int dmt_flags; /* VESA DMT flags */ + unsigned int data_flags; /* video data flags */ >>> >>> Why did you go for this approach? To be able to represent >>> true/false/not-specified? >>> > > We decided somewhere between v3 and v8 (I think), that those flags can be > high/low/ignored. Okay. Why aren't they enums, though? That always makes more clear which defines are to be used with which fields. >>> Would it be simpler to just have "flags" field? What does it give us to >>> have those two separately? >>> > > I decided to split them, so it is clear that some flags are VESA defined and > the others are "invented" for the display-timings framework and may be > extended. Hmm... Okay. Is it relevant that they are VESA defined? It just feels to complicate handling the flags =). >>> Should the above say raising edge/falling edge instead of positive >>> edge/negative edge? >>> > > Hm, I used posedge/negedge because it is shorter (and because of my Verilog > past > pretty natural to me :-) ). I don't know what others are thinking though. I guess it's quite clear, but it's still different terms than used elsewhere, e.g. documentation for videomodes. Another thing I noticed while using the new videomode, display_timings.h has a few names that are quite short and generic. Like "TE_MIN", which is now a global define. And "timing_entry". Either name could be well used internally in some .c file, and could easily clash. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On Wed, Feb 27, 2013 at 07:25:35PM +1000, Ben Skeggs wrote: > On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote: > > On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote: > > > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote: > > > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote: > > > > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote: > > > > > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH > > > > > > wrote: > > > > > > > Hi Ben, > > > > > > > > > > > > > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked > > > > > > > this > > > > > > > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 > > > > > > > (drm/nvd0/disp: > > > > > > > move link training helpers into core as display methods) > > > > > > > > > > > > > > Anything I can try to help solve this? > > > > > > > > > > > > > > Note, I'm using the Intel driver as the main controller for this > > > > > > > laptop, > > > > > > > well, I think I am, my xorg log is attached. > > > > > > > > > > > > No you are using the nvidia, the efi always boots nvidia enabled > > > > > > now. > > > > > > > > > > Really? When did that change? I thought I wanted to be using the > > > > > Intel > > > > > chip to save battery life. > > > > > > > > > > > btw I just tested my drm-next tree on mine and it resumed the > > > > > > display > > > > > > fine, something oopsed a few seconds later that I haven't tracked > > > > > > down > > > > > > > > > > > > git://git.freedesktop.org/~airlied/linux drm-next > > > > > > > > > > > > I'll be sending it to Linus this evening or tomorrow morning, once I > > > > > > fix my tree. > > > > > > > > > > Ok, I'll test again when it hits Linus's tree, and if that works, it > > > > > would be good to try to work out what patch fixes it to get them into > > > > > the 3.8-stable series so that others don't run into the same problem. > > > > > > > > I've tested Linus's tree now (I'm guessing it has all of your changes in > > > > it), and it works! > > > > > > > > I see a bunch of patches marked for the stable branch, so I'll try those > > > > out and see if they fix the problem. If not, I'll let you and Ben know. > > > > > > I've applied the radeon patches tagged for -stable and tested that on > > > 3.8.0, but that doesn't solve the resume problem. Any ideas of anything > > > else I can do to test this? Doing a "backwards" git-bisect is a pain, > > > but I guess I can do that to try to track down what patch fixed this, if > > > that's the only idea people have... > > > > Ok, after getting my brain warped by doing a reverse 'git bisect', I > > tracked it down to commit ac8cc241a81941932da44993242e68c62e115ec7 > > (drm/nv50/devinit: reverse the logic for running encoder init scripts) > > as the patch that solves the problem. > > > > So, I tried applying that patch on 3.8.1-rc1, but ran into the efifb bug > > that Dave fixed already, which took me a while, so I've queued that up > > for 3.8.1. Then I determined that it really also needs commit > > f3ed1048715f2edc10c4dda6148b60e93f6282ed (drm/nouveau/bios: parse > > external transmitter type if off-chip) and commit > > 8e992c8d9eebc2bd3246252ee5c0422dbbbce7ae (drm/nouveau/bios: store a > > type/mask hash in parsed dcb data) in order to build properly. > > > > With those three patches, plus the efifb fix, I can now properly boot, > > and suspend and resume my macbook on 3.8.1-rc1. Just like I can on > > Linus's tree. > > > > So, Ben, Dave, any objection to me including these 3 nouveau patches in > > the 3.8.1-final release? > Thanks for taking the time to track down exactly what's needed here. I > believe those three should be safe to apply. Ok, thanks for verifying, I've now applied all 3 of them. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm merge for 3.9-rc1
Hi, I am seeing this also on Linux-Next. /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! This seems to be hard reproducible... Laptop-LCD... Sandybridge Mobile-GT2. Is there a way to force the error? Possible patch see [1]. - Sedat - [1] https://patchwork.kernel.org/patch/2192721/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote: > Hi, > > I am seeing this also on Linux-Next. > > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > This seems to be hard reproducible... > Laptop-LCD... Sandybridge Mobile-GT2. > > Is there a way to force the error? > > Possible patch see [1]. > > - Sedat - > > [1] https://patchwork.kernel.org/patch/2192721/ Hmm, I tried to apply the test-patch against next-20130227 and it fails building the i915 kernel-module. - Sedat - LD drivers/gpu/drm/i915/built-in.o CC [M] drivers/gpu/drm/i915/i915_drv.o CC [M] drivers/gpu/drm/i915/i915_dma.o CC [M] drivers/gpu/drm/i915/i915_irq.o CC [M] drivers/gpu/drm/i915/i915_debugfs.o CC [M] drivers/gpu/drm/i915/i915_suspend.o CC [M] drivers/gpu/drm/i915/i915_gem.o CC [M] drivers/gpu/drm/i915/i915_gem_context.o CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CC [M] drivers/gpu/drm/i915/i915_sysfs.o CC [M] drivers/gpu/drm/i915/i915_trace_points.o CC [M] drivers/gpu/drm/i915/i915_ums.o CC [M] drivers/gpu/drm/i915/intel_display.o CC [M] drivers/gpu/drm/i915/intel_crt.o CC [M] drivers/gpu/drm/i915/intel_lvds.o CC [M] drivers/gpu/drm/i915/intel_bios.o CC [M] drivers/gpu/drm/i915/intel_ddi.o CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_aux_wait_done': drivers/gpu/drm/i915/intel_dp.c:352:1: error: invalid storage class for function 'intel_dp_aux_ch' drivers/gpu/drm/i915/intel_dp.c:351:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/gpu/drm/i915/intel_dp.c:492:1: error: invalid storage class for function 'intel_dp_aux_native_write' drivers/gpu/drm/i915/intel_dp.c:525:1: error: invalid storage class for function 'intel_dp_aux_native_write_1' drivers/gpu/drm/i915/intel_dp.c:533:1: error: invalid storage class for function 'intel_dp_aux_native_read' drivers/gpu/drm/i915/intel_dp.c:572:1: error: invalid storage class for function 'intel_dp_i2c_aux_ch' drivers/gpu/drm/i915/intel_dp.c:669:1: error: invalid storage class for function 'intel_dp_i2c_init' drivers/gpu/drm/i915/intel_dp.c:845:13: error: invalid storage class for function 'ironlake_set_pll_edp' drivers/gpu/drm/i915/intel_dp.c:872:1: error: invalid storage class for function 'intel_dp_mode_set' drivers/gpu/drm/i915/intel_dp.c:985:13: error: invalid storage class for function 'ironlake_wait_panel_status' drivers/gpu/drm/i915/intel_dp.c:1004:13: error: invalid storage class for function 'ironlake_wait_panel_on' drivers/gpu/drm/i915/intel_dp.c:1010:13: error: invalid storage class for function 'ironlake_wait_panel_off' drivers/gpu/drm/i915/intel_dp.c:1016:13: error: invalid storage class for function 'ironlake_wait_panel_power_cycle' drivers/gpu/drm/i915/intel_dp.c:1027:13: error: invalid storage class for function 'ironlake_get_pp_control' drivers/gpu/drm/i915/intel_dp.c:1075:13: error: invalid storage class for function 'ironlake_panel_vdd_off_sync' drivers/gpu/drm/i915/intel_dp.c:1097:13: error: invalid storage class for function 'ironlake_panel_vdd_work' drivers/gpu/drm/i915/intel_dp.c:1244:13: error: invalid storage class for function 'ironlake_edp_pll_on' drivers/gpu/drm/i915/intel_dp.c:1270:13: error: invalid storage class for function 'ironlake_edp_pll_off' drivers/gpu/drm/i915/intel_dp.c:1325:13: error: invalid storage class for function 'intel_dp_get_hw_state' drivers/gpu/drm/i915/intel_dp.c:1374:13: error: invalid storage class for function 'intel_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1390:13: error: invalid storage class for function 'intel_post_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1400:13: error: invalid storage class for function 'intel_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1419:13: error: invalid storage class for function 'intel_pre_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1432:1: error: invalid storage class for function 'intel_dp_aux_native_read_retry' drivers/gpu/drm/i915/intel_dp.c:1457:1: error: invalid storage class for function 'intel_dp_get_link_status' drivers/gpu/drm/i915/intel_dp.c:1483:1: error: invalid storage class for function 'intel_dp_voltage_max' drivers/gpu/drm/i915/intel_dp.c:1496:1: error: invalid storage class for function 'intel_dp_pre_emphasis_max' drivers/gpu/drm/i915/intel_dp.c:1538:1: error:
Re: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On 26 February 2013 18:11, James Courtier-Dutton wrote: > On 26 February 2013 17:35, Greg KH wrote: >> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote: >>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote: >>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote: >>> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH >>> > > wrote: >>> > > > Hi Ben, >>> > > > >>> > > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked this >>> > > > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 >>> > > > (drm/nvd0/disp: >>> > > > move link training helpers into core as display methods) >>> > > > >>> > > > Anything I can try to help solve this? >>> > > > >>> > > > Note, I'm using the Intel driver as the main controller for this >>> > > > laptop, >>> > > > well, I think I am, my xorg log is attached. >>> > > >>> > > No you are using the nvidia, the efi always boots nvidia enabled now. >>> > >>> > Really? When did that change? I thought I wanted to be using the Intel >>> > chip to save battery life. >>> > >>> > > btw I just tested my drm-next tree on mine and it resumed the display >>> > > fine, something oopsed a few seconds later that I haven't tracked down >>> > > >>> > > git://git.freedesktop.org/~airlied/linux drm-next >>> > > >>> > > I'll be sending it to Linus this evening or tomorrow morning, once I >>> > > fix my tree. >>> > >>> > Ok, I'll test again when it hits Linus's tree, and if that works, it >>> > would be good to try to work out what patch fixes it to get them into >>> > the 3.8-stable series so that others don't run into the same problem. >>> >>> I've tested Linus's tree now (I'm guessing it has all of your changes in >>> it), and it works! >>> >>> I see a bunch of patches marked for the stable branch, so I'll try those >>> out and see if they fix the problem. If not, I'll let you and Ben know. >> >> I've applied the radeon patches tagged for -stable and tested that on >> 3.8.0, but that doesn't solve the resume problem. Any ideas of anything >> else I can do to test this? Doing a "backwards" git-bisect is a pain, >> but I guess I can do that to try to track down what patch fixed this, if >> that's the only idea people have... >> > > If it helps, I have a similar resume problem here. > 3.7.8 good > 3.8.0 bad > > Laptop with no nvidia, no amd graphics, just Intel Graphics 4000, 3rd > Gen I5 CPU. Problem: "Backlight not coming on after resume." git finally bisected for my Samsung Serial 7 Laptop. Bisecting: 0 revisions left to test after this (roughly 0 steps) [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight harder <- This is the problem commit. Seems that fixing some machines breaks others, based on the existing comments on that patch. git bisect log git bisect start # bad: [09884964335e85e897876d17783c2ad33cf8a2e0] mm: do not grow the stack vma just because of an overrun on preceding vma git bisect bad 09884964335e85e897876d17783c2ad33cf8a2e0 # good: [6c5096e5538b455bc3bea2b02588c380f070d8c6] Merge tag 'boards' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 6c5096e5538b455bc3bea2b02588c380f070d8c6 # good: [21fbd5809ad126b949206d78e0a0e07ec872ea11] Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media git bisect good 21fbd5809ad126b949206d78e0a0e07ec872ea11 # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb # bad: [b81e059ec5a7128622ab5d74d78e9b4f361b54ae] Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next git bisect bad b81e059ec5a7128622ab5d74d78e9b4f361b54ae # good: [d6dd9eb1d96d2b7345fe4664066c2b7ed86da898] drm/i915: dynamic Haswell display power well support git bisect good d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 # good: [73ccd6962fff19e53a7d4baaa17cf9311284ac9c] Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next git bisect good 73ccd6962fff19e53a7d4baaa17cf9311284ac9c # good: [a4462f246c8821f625f45bce52c7ca7e0207dffe] staging/omapdrm: Use kmemdup rather than duplicating its implementation git bisect good a4462f246c8821f625f45bce52c7ca7e0207dffe # bad: [d84f031bd230fdf9c3b7734940c859bf28b90219] drm: Use C8 instead of RGB332 when determining the format from depth/bpp git bisect bad d84f031bd230fdf9c3b7734940c859bf28b90219 # bad: [f73f760725636b9d0c3786273e185b053516d1eb] drm/i915/ctx: Remove bad invariant git bisect bad f73f760725636b9d0c3786273e185b053516d1eb # bad: [26739f12cf210cb8df35969258a1f064e8e12b63] drm/i915: unify HDMI/DP hpd definitions git bisect bad 26739f12cf210cb8df35969258a1f064e8e12b63 # good: [b8efb17b3d687695b81485f606fc4e6c35a50f9a] i915: ignore lid open event when resuming git bisect good b8efb17b3d687695b81485f606fc4e6c35a50f9a # bad: [07ea0d85ac8adb87b817913d9720e3c76171b1f6] drm/i915: Clarify HW context size logic git bisect
Re: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On Wed, Feb 27, 2013 at 11:27:30PM +, James Courtier-Dutton wrote: > On 26 February 2013 18:11, James Courtier-Dutton > wrote: > > On 26 February 2013 17:35, Greg KH wrote: > >> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote: > >>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote: > >>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote: > >>> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH > >>> > > wrote: > >>> > > > Hi Ben, > >>> > > > > >>> > > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked > >>> > > > this > >>> > > > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 > >>> > > > (drm/nvd0/disp: > >>> > > > move link training helpers into core as display methods) > >>> > > > > >>> > > > Anything I can try to help solve this? > >>> > > > > >>> > > > Note, I'm using the Intel driver as the main controller for this > >>> > > > laptop, > >>> > > > well, I think I am, my xorg log is attached. > >>> > > > >>> > > No you are using the nvidia, the efi always boots nvidia enabled now. > >>> > > >>> > Really? When did that change? I thought I wanted to be using the Intel > >>> > chip to save battery life. > >>> > > >>> > > btw I just tested my drm-next tree on mine and it resumed the display > >>> > > fine, something oopsed a few seconds later that I haven't tracked down > >>> > > > >>> > > git://git.freedesktop.org/~airlied/linux drm-next > >>> > > > >>> > > I'll be sending it to Linus this evening or tomorrow morning, once I > >>> > > fix my tree. > >>> > > >>> > Ok, I'll test again when it hits Linus's tree, and if that works, it > >>> > would be good to try to work out what patch fixes it to get them into > >>> > the 3.8-stable series so that others don't run into the same problem. > >>> > >>> I've tested Linus's tree now (I'm guessing it has all of your changes in > >>> it), and it works! > >>> > >>> I see a bunch of patches marked for the stable branch, so I'll try those > >>> out and see if they fix the problem. If not, I'll let you and Ben know. > >> > >> I've applied the radeon patches tagged for -stable and tested that on > >> 3.8.0, but that doesn't solve the resume problem. Any ideas of anything > >> else I can do to test this? Doing a "backwards" git-bisect is a pain, > >> but I guess I can do that to try to track down what patch fixed this, if > >> that's the only idea people have... > >> > > > > If it helps, I have a similar resume problem here. > > 3.7.8 good > > 3.8.0 bad > > > > Laptop with no nvidia, no amd graphics, just Intel Graphics 4000, 3rd > > Gen I5 CPU. > > Problem: "Backlight not coming on after resume." > git finally bisected for my Samsung Serial 7 Laptop. > Bisecting: 0 revisions left to test after this (roughly 0 steps) > [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight > harder <- This is the problem commit. Seems that fixing some > machines breaks others, based on the existing comments on that patch. Hm, so, 3.8.0 works for you, but 3.8.1-rc1 doesn't? Or are you saying Linus's tree doesn't work for you? As you have a different issue here than the nvidia hardware I was dealing with, you might want to try to start over with a new thread and the needed info, and the needed people on it (i.e. the i915 maintainers and mailing list.) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On 28 February 2013 00:02, Greg KH wrote: > On Wed, Feb 27, 2013 at 11:27:30PM +, James Courtier-Dutton wrote: >> On 26 February 2013 18:11, James Courtier-Dutton >> wrote: >> > On 26 February 2013 17:35, Greg KH wrote: >> >> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote: >> >>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote: >> >>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote: >> >>> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH >> >>> > > wrote: >> >>> > > > Hi Ben, >> >>> > > > >> >>> > > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked >> >>> > > > this >> >>> > > > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 >> >>> > > > (drm/nvd0/disp: >> >>> > > > move link training helpers into core as display methods) >> >>> > > > >> >>> > > > Anything I can try to help solve this? >> >>> > > > >> >>> > > > Note, I'm using the Intel driver as the main controller for this >> >>> > > > laptop, >> >>> > > > well, I think I am, my xorg log is attached. >> >>> > > >> >>> > > No you are using the nvidia, the efi always boots nvidia enabled now. >> >>> > >> >>> > Really? When did that change? I thought I wanted to be using the >> >>> > Intel >> >>> > chip to save battery life. >> >>> > >> >>> > > btw I just tested my drm-next tree on mine and it resumed the display >> >>> > > fine, something oopsed a few seconds later that I haven't tracked >> >>> > > down >> >>> > > >> >>> > > git://git.freedesktop.org/~airlied/linux drm-next >> >>> > > >> >>> > > I'll be sending it to Linus this evening or tomorrow morning, once I >> >>> > > fix my tree. >> >>> > >> >>> > Ok, I'll test again when it hits Linus's tree, and if that works, it >> >>> > would be good to try to work out what patch fixes it to get them into >> >>> > the 3.8-stable series so that others don't run into the same problem. >> >>> >> >>> I've tested Linus's tree now (I'm guessing it has all of your changes in >> >>> it), and it works! >> >>> >> >>> I see a bunch of patches marked for the stable branch, so I'll try those >> >>> out and see if they fix the problem. If not, I'll let you and Ben know. >> >> >> >> I've applied the radeon patches tagged for -stable and tested that on >> >> 3.8.0, but that doesn't solve the resume problem. Any ideas of anything >> >> else I can do to test this? Doing a "backwards" git-bisect is a pain, >> >> but I guess I can do that to try to track down what patch fixed this, if >> >> that's the only idea people have... >> >> >> > >> > If it helps, I have a similar resume problem here. >> > 3.7.8 good >> > 3.8.0 bad >> > >> > Laptop with no nvidia, no amd graphics, just Intel Graphics 4000, 3rd >> > Gen I5 CPU. >> >> Problem: "Backlight not coming on after resume." >> git finally bisected for my Samsung Serial 7 Laptop. >> Bisecting: 0 revisions left to test after this (roughly 0 steps) >> [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight >> harder <- This is the problem commit. Seems that fixing some >> machines breaks others, based on the existing comments on that patch. > > Hm, so, 3.8.0 works for you, but 3.8.1-rc1 doesn't? Or are you saying > Linus's tree doesn't work for you? > > As you have a different issue here than the nvidia hardware I was > dealing with, you might want to try to start over with a new thread and > the needed info, and the needed people on it (i.e. the i915 > maintainers and mailing list.) > I little confusing sorry. I started using: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git For that 3.7.8 worked fine, 3.8 failed to restore X, but the backlight lights. I then moved to linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git On Linus tree the problem commit is: [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight harder The problem on the Linux tree is different from the stable tree. Linus tree: Backlight fails to light up after resume. linux-stable tree: Failed to restore X, but the backlight lights. So, I think the linus tree fixes the "failed to restore X" bit, but introduced a new regression for the backlight. I don't know which patch from the Linus tree would fix the stable 3.8 tree. I will send an email to the i915 maintainers tomorrow. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/9] drm/tegra: Implement page-flipping support
On 02/25/2013 08:06 AM, Thierry Reding wrote:
On Fri, Feb 22, 2013 at 05:13:47PM +0100, Mario Kleiner wrote:
On 02/21/2013 03:35 PM, Thierry Reding wrote:
All the necessary support bits like .mode_set_base() and VBLANK are now
available, so page-flipping case easily be implemented on top.
Signed-off-by: Thierry Reding
---
Changes in v3:
- use drm_send_vblank_event()
- set crtc->fb field
Changes in v4:
- fix a potential race by checking that a framebuffer base has been
latched when completing a page-flip
drivers/gpu/drm/tegra/dc.c | 66 +
drivers/gpu/drm/tegra/dc.h | 2 ++
drivers/gpu/drm/tegra/drm.c | 9 +++
drivers/gpu/drm/tegra/drm.h | 5
4 files changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 5f55a25..c5d825f 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -183,7 +183,72 @@ void tegra_dc_disable_vblank(struct tegra_dc *dc)
spin_unlock_irqrestore(&dc->lock, flags);
}
+static void tegra_dc_finish_page_flip(struct tegra_dc *dc)
+{
+ struct drm_device *drm = dc->base.dev;
+ struct drm_crtc *crtc = &dc->base;
+ struct drm_gem_cma_object *gem;
+ unsigned long flags, base;
+
The checks for properly latched scanout look good to me and should
fix the race between software and hardware. But shouldn't you
already spin_lock_irqsave() here, before checking dc->event and
performing write access on the DC_CMD_STATE_ACCESS registers? And
lock around most of the tegra_dc_page_flip() code below, like in
your previous iteration of the patch, to prevent a race between
pageflip ioctl and the vblank irq handler?
Currently there's nothing else that touches the DC_CMD_STATE_ACCESS
register, so that part should be safe.
ok.
As to the locking that I removed since the previous patch, I looked at
it more closely and didn't think it was necessary. Also nothing in my
tests seemed to point to any race here, though I probably didn't cover
everything.
+ if (!dc->event)
-> !dc->event may exit prematurely because the irq handler on one
core doesn't notice the new setup of dc->event by
tegra_dc_page_flip() on a different core? Don't know if that can
happen, don't know the memory ordering of arm, but could imagine
that this or the compiler reordering instructions could cause
trouble without lock protection.
I'm not sure I follow here. If the handler sees a NULL here, why would
it want to continue? It can safely assume that the page flip wasn't
setup for this interval, can't it?
If indeed the VBLANK interrupt happens exactly around the assignment to
dc->event, then we'll just schedule the page-flip for the next VBLANK.
I meant the other way round. dc->event is initially NULL. Then pageflip
ioctl is called, close to vblank, the code e.g., executing on core 1. if
(event) branch in tegra_dc_page_flip() executes, assigns dc->event =
event etc. calls tegra_dc_set_base() before onset of vblank, pageflip
completes in vblank, but the irq handler and thereby
tegra_dc_finish_page_flip() running on a different core doesn't notice
dc->event is non-NULL, because the changes haven't propagated to the
different core without some memory write barrier etc., thereby doesn't
run the flip completion in the vblank of actual flip completion. But i
now think my point is probably pointless, because the successive calls
to drm_vblank_get() and tegra_dc_set_base() contain enough locking and
implicit memory barriers that such a stale value there won't happen.
+ return;
+
+ gem = drm_fb_cma_get_gem_obj(crtc->fb, 0);
-> crtc->fb gets updated in tegra_dc_page_flip() after
tegra_dc_set_base() without lock -> possibly stale fb here?
Good point. That may indeed require a lock. I'll need to look more
closely.
Yep, i think here my argument from above may hold for crtc->fb, nothing
here to prevent a race afaics.
+ /* check if new start address has been latched */
+ tegra_dc_writel(dc, READ_MUX, DC_CMD_STATE_ACCESS);
+ base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
+ tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);
+
-> Can other code in the driver write to DC_CMD_STATE_ACCESS,
simultaneously to tegra_dc_page_flip writing->reading->writing and
cause trouble?
This is the only location where the DC_CMD_STATE_ACCESS register is
actually used in the driver so we should be safe for now.
Ok. I'm just paranoid about forgetting such things on later changes.
+static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer
*fb,
+ struct drm_pending_vblank_event *event)
+{
+ struct tegra_dc *dc = to_tegra_dc(crtc);
+ struct drm_device *drm = crtc->dev;
+
+ if (dc->event)
+ return -EBUSY;
+
-> Lock already here?
+ if (event) {
+ event->pipe = dc->pipe;
+ dc->event = event;
+ drm
[RFD] Proposal for merging Android sync driver in staging
I'd like to get a discussion going about submitting the Android sync driver to staging. I know there is currently some very similar work going on with the dmabuf-fences, and rather then both approaches being worked out individually on their own, I suspect there could be better collaboration around this effort. So my proposal is that we merge the Android sync driver into staging. In my mind, this has the following benefits: 1) It allows other drivers that depend on the sync interface to also be submitted to staging, rather then forcing those drivers to be hidden away in various out of tree git repos, location unknown. 2) It would provide a baseline view to the upstream community of the interface Android is using, providing a real-world, active use case of the functionality. Once the sync driver is in staging, if the dmabuf-fences work is fully sufficient to replace the Android sync driver, we should be able to whittle down the sync driver until its just a interface shim (and at which point efforts can be made to convert Android userland over to dmabuf-fences). However, if the dmabuf-fences work is not fully sufficient to replace the android sync driver, we should be able to at least to whittle down the driver to those specific differences, which would provide a concrete example of where the dmabuf-fences, or other work may need to be expanded, or if maybe the sync driver is the better approach. I've gone through the Android tree and reworked the sync driver to live in staging, while still preserving the full patch history/authorship. You can checkout the reworked patch queue here: http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/sync-staging If folks would take a look and let me know what they think of the changes as well as what they think about pushing it to staging, or other ideas for how to improve collaboration so we can have common interfaces here, I'd appreciate it. Also note: I've done this so far without any feedback from the Android devs (despite my reaching out to Erik a few times recently), so if they object to pushing it to staging, in deference to it being their code I'll back off, even though I do think it would be good to have the code get more visibility upstream in staging. I don't mean to step on anyone's toes. :) thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFD] Proposal for merging Android sync driver in staging
On Wed, Feb 27, 2013 at 06:14:24PM -0800, John Stultz wrote: > I'd like to get a discussion going about submitting the Android sync > driver to staging. > > I know there is currently some very similar work going on with the > dmabuf-fences, and rather then both approaches being worked out > individually on their own, I suspect there could be better > collaboration around this effort. > > So my proposal is that we merge the Android sync driver into staging. > > In my mind, this has the following benefits: > 1) It allows other drivers that depend on the sync interface to also > be submitted to staging, rather then forcing those drivers to be > hidden away in various out of tree git repos, location unknown. > > 2) It would provide a baseline view to the upstream community of the > interface Android is using, providing a real-world, active use case > of the functionality. > > Once the sync driver is in staging, if the dmabuf-fences work is > fully sufficient to replace the Android sync driver, we should be > able to whittle down the sync driver until its just a interface shim > (and at which point efforts can be made to convert Android userland > over to dmabuf-fences). Sounds like a good plan to me. > I've gone through the Android tree and reworked the sync driver to > live in staging, while still preserving the full patch > history/authorship. You can checkout the reworked patch queue here: > > http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/sync-staging I can't really look at a git tree at the moment, but will always be glad to review patches. Feel free to send them on and we can look at them then :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: modify the compatible string for exynos fimd
Thanks Mr. Shim.
On 28 February 2013 08:12, Joonyoung Shim wrote:
> On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
>>
>> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
>> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
>> value should be named after first specific SoC model in which this
>> particular IP version was included as discussed at
>> https://patchwork.kernel.org/patch/2144861/
>>
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..433ed35 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -109,9 +109,9 @@ struct fimd_context {
>> #ifdef CONFIG_OF
>> static const struct of_device_id fimd_driver_dt_match[] = {
>> - { .compatible = "samsung,exynos4-fimd",
>> + { .compatible = "samsung,exynos4210-fimd",
>> .data = &exynos4_fimd_driver_data },
>> - { .compatible = "samsung,exynos5-fimd",
>> + { .compatible = "samsung,exynos5250-fimd",
>> .data = &exynos5_fimd_driver_data },
>> {},
>> };
>
>
> Acked-by: Joonyoung Shim
>
> Thanks.
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 28 February 2013 08:07, Joonyoung Shim wrote:
> On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
>>
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exists and the NON-DT logic is still maintained under the 'else' part.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25
>> +
>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..7932dc2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> +#include
>> #include
>> #include
>> @@ -883,10 +884,26 @@ static int fimd_probe(struct platform_device
>> *pdev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> - pdata = pdev->dev.platform_data;
>> - if (!pdata) {
>> - dev_err(dev, "no platform data specified\n");
>> - return -EINVAL;
>> + if (pdev->dev.of_node) {
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + DRM_ERROR("memory allocation for pdata failed\n");
>> + return -ENOMEM;
>> + }
>> +
>> + ret = of_get_fb_videomode(dev->of_node,
>> &pdata->panel.timing,
>> + OF_USE_NATIVE_MODE);
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode()\n"
>> + "with return value: %d\n", ret);
>
>
> Could you make this error log to one line?
>
The Line was going beyond 80 line marks, hence I had to split it.
> except this,
> Acked-by: Joonyoung Shim
>
>
>> + return ret;
>> + }
>> + } else {
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + DRM_ERROR("no platform data specified\n");
>> + return -EINVAL;
>> + }
>> }
>> panel = &pdata->panel;
>
>
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFD] Proposal for merging Android sync driver in staging
On Wed, Feb 27, 2013 at 6:14 PM, John Stultz wrote: > Also note: I've done this so far without any feedback from the Android devs > (despite my reaching out to Erik a few times recently), so if they object to > pushing it to staging, in deference to it being their code I'll back off, > even though I do think it would be good to have the code get more visibility > upstream in staging. I don't mean to step on anyone's toes. :) Yeah, sorry about that. I kept meaning to get back to you but kept getting distracted. A little background on the patches: In Honeycomb where we introduced the Hardware Composer HAL. This is a userspace layer that allows composition acceleration on a per platform basis. Different SoC vendors have implemented this using overlays, 2d blitters, a combinations of both, or other clever/disgusting means. Along with the HWC we consolidated a lot of our camera and media pipeline to allow their input to be fed into the GPU or display(overlay.) In order to exploit parallelism the the graphics pipeline, this introduced lots of implicit synchronization dependancies. After a couple years of working with many different SoC vendors, we found that it was really difficult to communicate our system's expectations of the implicit contract and it was difficult for the SoC vendors to properly implement the implicit contract in each of their IP blocks (display, gpu, camera, video codecs). It was also incredibly difficult to debug when problems/deadlocks arose. In an effort to clean up the situation we decided to create set of simple synchronization primitives and have our compositor (SurfaceFlinger) manage the synchronization contract explicitly. We designed these primitives so that they can be passed across processes (much like ion/dma_buf handles), can be backed by hardware synchronization primitives, and can be combined with other sync dependancies in a heterogeneous manner. We also added enough debugging information to make pinpointing a synchronization deadlock bug easier. There are also OpenGL extensions added (which I believe have been ratified by Khronos) to convert a "native" sync object to a gl fence object and vise versa. So far shipped this system on two products (the Nexus 10 and 4) with two different SoCs (Samsung Exynos5250 and Qualcomm MSM8064.) These two projects were much easier to work out the kinks in the graphics/compositing pipelines. In addition we were able to use the telemetry and tracing features to track down the causes of dropped frames aka "jank." As for the implementation, I started with having the main driver op primitive be a wait() op. I quickly noticed that most of the tricky race condition prone code was ending up in the drivers wait() op. It also made handling asynchronous waits of more than one type of sync_pt difficult to manage. In the end I opted for something roughly like poll() where all the heavy lifting is done at the high level and the drivers only need to implement a simple check function. Happy to hear feedback and (especially) bug reports/fixes. Cheers, Erik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/2] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v8: - replaced IS_ERR() with IS_ERR_OR_NULL(), because devm_pinctrl_get_select_default can return NULL, If CONFIG_PINCTRL is disabled. - modified the error log, such that it shall NOT cross 80 column. - added Acked-by. changes since v7: - addressed comments from Joonyoung Shim to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae , to remove the allocation of 'fbmode' and replaced '-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel , to modify the commit message changes since v3: - addressed comments from Sean Paul , to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma ) changes since v1: - addressed comments from Sean Paul Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function video: drm: exynos: Add pinctrl support to fimd drivers/gpu/drm/exynos/exynos_drm_fimd.c | 33 ++ 1 file changed, 29 insertions(+), 4 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
Acked-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(dev, "no platform data specified\n");
- return -EINVAL;
+ if (pdev->dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR("memory allocation for pdata failed\n");
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR("no platform data specified\n");
+ return -EINVAL;
+ }
}
panel = &pdata->panel;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/2] video: drm: exynos: Add pinctrl support to fimd
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e323cf9..21ada8d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -879,6 +880,7 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
struct resource *res;
+ struct pinctrl *pctrl;
int win;
int ret = -EINVAL;
@@ -897,6 +899,13 @@ static int fimd_probe(struct platform_device *pdev)
DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
return ret;
}
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR("failed: devm_pinctrl_get_select_default():"
+ "%d\n", PTR_RET(pctrl));
+ return PTR_ERR(pctrl);
+ }
+
} else {
pdata = pdev->dev.platform_data;
if (!pdata) {
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote:
> > Hi,
> >
> > I am seeing this also on Linux-Next.
> >
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > This seems to be hard reproducible...
> > Laptop-LCD... Sandybridge Mobile-GT2.
> >
> > Is there a way to force the error?
> >
> > Possible patch see [1].
> >
> > - Sedat -
> >
> > [1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ {
That second '{' is the source of the compile error.
-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
Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
Hi Dave
Sorry, I was busy reworking the HIDP layer. I finally got time to
continue my work on this again. See below:
On Mon, Feb 18, 2013 at 12:47 AM, Dave Airlie wrote:
[..snap..]
> As I said maybe I'm concentrating on the problem you aren't trying to fix,
> but then I'm not sure I've enough information on the problem you are
> trying to fix,
>
> remove_confilicting_framebuffers might be ugly but it does 90% of what we
> want,
> I just want to understand why this will make it better,
Ok, let me describe the problem in more detail:
We currently have different drivers that can make use of "system
framebuffers" (as I call them for now):
- vgacon
- fbdev
- DRM
(- vgalog) (similar to fblog/drmlog but using vga/VBE)
Scenarios:
- Imagine you have CONFIG_FB=n but VGACON=y for debugging. Who is then
responsible of kicking out VGACON when DRM drivers are loaded? (and
vice versa)
- i915 is loaded and the user does a "modprobe vesafb". Who prevents
vesafb from loading?
- If I use vgalog, who unloads it when fbdev/DRM drivers are loaded?
(and vice versa)
Our current solution consists of "vgacon_cleanup()" and
"remove_conflicting_frambuffers()". We could add similar helpers for
all other scenarios, but I promise, this will get pretty complex.
Another problem: All VBE/EFI framebuffer drivers currently do something like:
platform_driver_register("my-device"...);
platform_device_add("my-device"...);
Why not provide a unique platform-device-name and add the device in
architecture setup code? This would prevent multiple drivers from
being probed on a single platform device.
My bus-solution was the most straightforward to implement and makes
testing really easy (as you can probe/remove drivers from userspace).
However, I understand if we don't want to introduce any ABI.
So I was rethinking this idea and maybe we simplify the bus-solution
and instead use some priority-based driver loading. That is, the
architecture code creates a platform-device for all available
system-framebuffers (which is probably always at most one device).
Then drivers simply provide platform-drivers that can be loaded on the
device. But instead of using platform_driver_register(), they use
vbe_driver_register() or something similar and pass in the
platform-driver _plus_ a priority. The wrapper then compares the
priorities, unloads the old driver and probes the new one.
This guarantees that a new driver will only replace the current driver
if it has a higher priority. vgacon/vgalog->fbdev->DRM
How does that fix the problems you described?
Well, it doesn't. But it makes them more obvious as there is now a
central place that manages the hand-over.
On the other hand, I don't understand why the problems you described
have anything to do with the hand-over itself? They also occur on
driver-unloading without any handover, don't they?
So I think we simply need to fix vesafb, efifb, ... to unmap any
pending user-space mappings during unloading. This also guarantees
that these mappings are dead when any other driver takes over. And
with the platform-devices that I want to introduce, we guarantee that
the drivers get unloaded correctly even during hand-over.
The remove_conflicting_framebuffers() call can stay for all other
conflicts, although I think these _really_ should be handled by
Kconfig. But ok, I don't mind this call. It doesn't break anything.
Why am I doing this?
To get dvbe/defi and vbelog working. I use these on my machine as
nouveau doesn't work and fbdev is just ugly to work with. I was also
told that they proved to be useful in virtualization environments.
I don't mind setting dvbe as "depends on ! &&
!CONFIG_FB && !CONFIG_VT" but I thought fixing this directly where it
is broken ought to be the better way.
So, any comments welcome.
If there are no major objections, I will try to implement it and also
try to fix vesafb to unmap the mmap()s during unloading. If that turns
out to work well, I can also fix the other drivers.
Thanks for the comments
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Fix build of swrast only without libdrm
Signed-off-by: Daniel Martin --- There's a small logic error preventing mesa to be build with swrast only and not having libdrm. configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 5701f8a..aa1b38a 100644 --- a/configure.ac +++ b/configure.ac @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then fi # if we are building any dri driver other than swrast or using the dri state tracker ... -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" = xyes; then +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" = xyes; then # ... libdrm is required if test "x$have_libdrm" != xyes; then AC_MSG_ERROR([DRI drivers requires libdrm >= $LIBDRM_REQUIRED]) -- 1.7.2.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
On Thu, Feb 28, 2013 at 1:20 PM, David Herrmann wrote:
> We currently have different drivers that can make use of "system
> framebuffers" (as I call them for now):
> - vgacon
> - fbdev
> - DRM
> (- vgalog) (similar to fblog/drmlog but using vga/VBE)
offb
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
Hi
2013/2/28 Chris Wilson :
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
>
> That second '{' is the source of the compile error.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #29 from Andreas Boll --- (In reply to comment #28) > Andreas Boll requested a branch of all my latest Mesa patches for people to > test it. It's here: > > git://people.freedesktop.org/~mareko/mesa master This branch fixes the garbled screen and improves the performance (~ 120 - 160%) here with tf2 and css on my rv770. Please test it! -- 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 6/8] drm/i915: Enable/Disable PSR
Hi
So now I finally have the correct spec in hands!
2013/2/25 Rodrigo Vivi :
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
> This patch is heavily based on initial PSR code by Sateesh Kavuri and
> Kumar Shobhit but in a different implementation.
>
> Credits-by: Sateesh Kavuri
> Credits-by: Shobhit Kumar
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 40 +
> drivers/gpu/drm/i915/intel_dp.c | 183
> +++
> drivers/gpu/drm/i915/intel_drv.h | 3 +
> 3 files changed, 226 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b715ecd..1e31f23 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -844,6 +844,8 @@
> #define SNB_CPU_FENCE_ENABLE (1<<29)
> #define DPFC_CPU_FENCE_OFFSET 0x100104
>
> +/* Framebuffer compression for Haswell */
> +#define HSW_FBC_CONTROL0x43208
>
> /*
> * GPIO regs
> @@ -1580,6 +1582,44 @@
> #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
> #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
>
> +/* HSW eDP PSR registers */
> +#define EDP_PSR_CTL0x64800
> +#define EDP_PSR_ENABLE (1<<31)
> +#define EDP_PSR_LINK_DISABLE (0<<27)
> +#define EDP_PSR_LINK_STANDBY (1<<27)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25)
> +#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
> +#define EDP_PSR_SKIP_AUX_EXIT(1<<12)
> +#define EDP_PSR_TP1_TP2_SEL (0<<11)
> +#define EDP_PSR_TP1_TP3_SEL (1<<11)
> +#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
> +#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
> +#define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
> +#define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
> +#define EDP_PSR_TP1_TIME_500us (0<<4)
> +#define EDP_PSR_TP1_TIME_100us (1<<4)
> +#define EDP_PSR_TP1_TIME_2500us (2<<4)
> +#define EDP_PSR_TP1_TIME_0us (3<<4)
> +#define EDP_PSR_IDLE_FRAME_SHIFT 0
> +
> +#define EDP_PSR_AUX_CTL0x64810
> +#define EDP_PSR_AUX_DATA1 0x64814
> +#define EDP_PSR_AUX_DATA2 0x64818
> +#define EDP_PSR_AUX_DATA3 0x6481c
> +#define EDP_PSR_AUX_DATA4 0x64820
> +#define EDP_PSR_AUX_DATA5 0x64824
> +
> +#define EDP_PSR_STATUS_CTL 0x64840
> +#define EDP_PSR_STATUS_STATE_MASK(7<<29)
> +
> +#define EDP_PSR_DEBUG_CTL 0x64860
> +#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> +#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
> +
> /* VGA port control */
> #define ADPA 0x61100
> #define PCH_ADPA0xe1100
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5cfa9f4..a420f0d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp
> *intel_dp)
> return intel_dig_port->base.base.dev;
> }
>
> +static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> +
> + return intel_dig_port->base.base.crtc;
> +}
> +
> static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
> {
> return enc_to_intel_dp(&intel_attached_encoder(connector)->base);
> @@ -1443,6 +1450,182 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
> (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED));
> }
>
> +static bool
> +intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
> +{
> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + return I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> +}
> +
> +static void
> +intel_edp_psr_enable_src(struct intel_dp *intel_dp)
> +{
> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + uint32_t max_sleep_time = 0x1f;
> + uint32_t val = 0x0;
> +
> + if (dev_priv->vbt.psr_idle_frames)
> + val |= dev_priv->vbt.psr_idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> + else
> + val |= 1 << EDP_PSR_IDLE_FRAME_SHIFT;
> +
> + if (intel_dp->psr_dpcd[1] & DP_PSR_NO_
Re: [PATCH] Fix build of swrast only without libdrm
On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin wrote: > > Signed-off-by: Daniel Martin > --- > There's a small logic error preventing mesa to be build with swrast only > and not having libdrm. > > configure.ac |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 5701f8a..aa1b38a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then > fi > > # if we are building any dri driver other than swrast or using the dri > state tracker ... > -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" > = xyes; then > +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" > = xyes; then While modifying this line of code, please change '&& test' to -a. (mesa patches to go mesa-dev, not dri-devel) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Enable/Disable PSR
Hi
2013/2/26 Ville Syrjälä :
> On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
>> Adding Enable and Disable PSR functionalities. This includes setting the
>> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
>> enabling PSR in the sink via DPCD register and finally enabling PSR on
>> the host.
>>
>> This patch is heavily based on initial PSR code by Sateesh Kavuri and
>> Kumar Shobhit but in a different implementation.
>>
>> Credits-by: Sateesh Kavuri
>> Credits-by: Shobhit Kumar
>> Signed-off-by: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 40 +
>> drivers/gpu/drm/i915/intel_dp.c | 183
>> +++
>> drivers/gpu/drm/i915/intel_drv.h | 3 +
>> 3 files changed, 226 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index b715ecd..1e31f23 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -844,6 +844,8 @@
>> #define SNB_CPU_FENCE_ENABLE (1<<29)
>> #define DPFC_CPU_FENCE_OFFSET0x100104
>>
>> +/* Framebuffer compression for Haswell */
>> +#define HSW_FBC_CONTROL 0x43208
>>
>> /*
>> * GPIO regs
>> @@ -1580,6 +1582,44 @@
>> #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
>> #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
>>
>> +/* HSW eDP PSR registers */
>> +#define EDP_PSR_CTL 0x64800
>> +#define EDP_PSR_ENABLE (1<<31)
>> +#define EDP_PSR_LINK_DISABLE (0<<27)
>> +#define EDP_PSR_LINK_STANDBY (1<<27)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES(0<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES(1<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES(2<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES(3<<25)
>> +#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
>> +#define EDP_PSR_SKIP_AUX_EXIT (1<<12)
>> +#define EDP_PSR_TP1_TP2_SEL(0<<11)
>> +#define EDP_PSR_TP1_TP3_SEL(1<<11)
>> +#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
>> +#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
>> +#define EDP_PSR_TP2_TP3_TIME_2500us(2<<8)
>> +#define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
>> +#define EDP_PSR_TP1_TIME_500us (0<<4)
>> +#define EDP_PSR_TP1_TIME_100us (1<<4)
>> +#define EDP_PSR_TP1_TIME_2500us(2<<4)
>> +#define EDP_PSR_TP1_TIME_0us (3<<4)
>> +#define EDP_PSR_IDLE_FRAME_SHIFT 0
>> +
>> +#define EDP_PSR_AUX_CTL 0x64810
>> +#define EDP_PSR_AUX_DATA10x64814
>> +#define EDP_PSR_AUX_DATA20x64818
>> +#define EDP_PSR_AUX_DATA30x6481c
>> +#define EDP_PSR_AUX_DATA40x64820
>> +#define EDP_PSR_AUX_DATA50x64824
>> +
>> +#define EDP_PSR_STATUS_CTL 0x64840
>> +#define EDP_PSR_STATUS_STATE_MASK (7<<29)
>> +
>> +#define EDP_PSR_DEBUG_CTL0x64860
>> +#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
>> +#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
>> +
>> /* VGA port control */
>> #define ADPA 0x61100
>> #define PCH_ADPA0xe1100
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 5cfa9f4..a420f0d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp
>> *intel_dp)
>> return intel_dig_port->base.base.dev;
>> }
>>
>> +static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
>> +{
>> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> +
>> + return intel_dig_port->base.base.crtc;
>> +}
>> +
>> static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
>> {
>> return enc_to_intel_dp(&intel_attached_encoder(connector)->base);
>> @@ -1443,6 +1450,182 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
>> (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED));
>> }
>>
>> +static bool
>> +intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + return I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>> +}
>> +
>> +static void
>> +intel_edp_psr_enable_src(struct intel_dp *intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + uint32_t max_sleep_time = 0x1f;
>> + uint32_t val = 0x0;
>> +
>> + if (dev_priv->vbt.psr_idle_frames)
>> + val |= dev_priv->vbt.psr_idle_frames << EDP
Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1
Hi
2013/2/28 Sedat Dilek :
> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>>> Hi
>>>
>>> 2013/2/28 Chris Wilson :
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
> wrote:
> > Hi,
> >
> > I am seeing this also on Linux-Next.
> >
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > This seems to be hard reproducible...
> > Laptop-LCD... Sandybridge Mobile-GT2.
> >
> > Is there a way to force the error?
> >
> > Possible patch see [1].
> >
> > - Sedat -
> >
> > [1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ {
>>>
>>> In addition to this, after the problem happens can you please dump the
>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>>> I915_READ(0xC4008).
>>>
>>
>> Do I need a specific version of intel-gpu-tools?
>> Ubuntu/precise has v1.2 in its archives - sufficient?
>> Note: The error was twice after dozenz of Linux-Next kernel builds.
>>
>> - Sedat -
>>
>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>>
>
> Installed intel-gpu-tools.
>
> # intel_reg_read
> Usage: intel_reg_read [-f | addr]
> -f : read back full range of registers.
> WARNING! This could be danger to hang the machine!
> addr : in 0x format
>
> # intel_reg_read 0x44008
> Couldn't map MMIO region: Resource temporarily unavailable
>
> [ 368.281707] intel_reg_read:3657 conflicting memory types
> f000-f040 uncached-minus<->write-combining
> [ 381.521912] intel_reg_read:3658 conflicting memory types
> f000-f040 uncached-minus<->write-combining
> [ 401.136291] intel_reg_read:3659 conflicting memory types
> f000-f040 uncached-minus<->write-combining
>
> Wrong i-g-t version? Missing enabled kernel-config option? Boot with
> i915 debug enabled?
Just build the version from git and it should work
(http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
>
> - Sedat -
>
>>> If you conclude that the value of 0x44008 is 0x0 while the value of
>>> 0xC4008 is not, then this patch should help:
>>> https://patchwork.kernel.org/patch/2177841/
>>>
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>>
>>>
>>> --
>>> Paulo Zanoni
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 Lucas Kannebley Tavares changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #32 from Lucas Kannebley Tavares --- After some further investigation, we found that despite the fact that we were disabling MSIs, the adapter was still using it. After we provided a 32-bit address to it, we got it to work properly. The solution to this will have to be done not in software, so I'm closing the bug. Thanks for all the help, guys -- 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: [Intel-gfx] [PATCH 7/8] drm/i915: Added debugfs support for PSR Status
Hi
2013/2/25 Rodrigo Vivi :
> Adding support for PSR Status, PSR entry counter and performance counters.
> Heavily based on initial work from Shobhit.
>
> Credits-by: Shobhit Kumar
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 92
> +
> drivers/gpu/drm/i915/i915_reg.h | 24 ++
> 2 files changed, 116 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7c65ab8..01021f6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1680,6 +1680,97 @@ static int i915_dpio_info(struct seq_file *m, void
> *data)
> return 0;
> }
>
> +
> +static int i915_edp_psr_status(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + unsigned int count;
> + u32 psrctl, psrstat, psrperf;
> +
> + psrctl = I915_READ(EDP_PSR_CTL);
> + seq_printf(m, "PSR Enabled: %s\n",
> + yesno(psrctl & EDP_PSR_ENABLE));
> +
> + psrstat = I915_READ(EDP_PSR_STATUS_CTL);
> +
> + seq_printf(m, "PSR Current State: ");
> + switch (psrstat & EDP_PSR_STATUS_STATE_MASK) {
> + case EDP_PSR_STATUS_STATE_IDLE:
> + seq_printf(m, "Reset state\n");
> + break;
> + case EDP_PSR_STATUS_STATE_SRDONACK:
> + seq_printf(m, "Wait for TG/Stream to send on frame of data
> after SRD conditions are met\n");
> + break;
> + case EDP_PSR_STATUS_STATE_SRDENT:
> + seq_printf(m, "SRD entry\n");
> + break;
> + case EDP_PSR_STATUS_STATE_BUFOFF:
> + seq_printf(m, "Wait for buffer turn off\n");
> + break;
> + case EDP_PSR_STATUS_STATE_BUFON:
> + seq_printf(m, "Wait for buffer turn on\n");
> + break;
> + case EDP_PSR_STATUS_STATE_AUXACK:
> + seq_printf(m, "Wait for AUX to acknowledge on SRD
> exit\n");
> + break;
> + case EDP_PSR_STATUS_STATE_SRDOFFACK:
> + seq_printf(m, "Wait for TG/Stream to acknowledge the
> SRD VDM exit\n");
> + break;
> + default:
> + seq_printf(m, "Unknown\n");
> + break;
> + }
> +
> + seq_printf(m, "Link Status: ");
> + switch (psrstat & EDP_PSR_STATUS_LINK_MASK) {
> + case EDP_PSR_STATUS_LINK_FULL_OFF:
> + seq_printf(m, "Link is fully off\n");
> + break;
> + case EDP_PSR_STATUS_LINK_FULL_ON:
> + seq_printf(m, "Link is fully on\n");
> + break;
> + case EDP_PSR_STATUS_LINK_STANDBY:
> + seq_printf(m, "Link is in standby\n");
> + break;
> + default:
> + seq_printf(m, "Unknown\n");
> + break;
> + }
> +
> + seq_printf(m, "PSR Entry Count: %u\n",
> + psrstat >> EDP_PSR_STATUS_COUNT_SHIFT &
> + EDP_PSR_STATUS_COUNT_MASK);
> +
> + seq_printf(m, "Max Sleep Timer Counter: %u\n",
> + psrstat >> EDP_PSR_STATUS_MAX_SLEEP_TIMER_SHIFT &
> + EDP_PSR_STATUS_MAX_SLEEP_TIMER_MASK);
> +
> + seq_printf(m, "Had AUX error: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_AUX_ERROR));
> +
> + seq_printf(m, "Sending AUX: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_AUX_SENDING));
> +
> + seq_printf(m, "Sending Idle: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_SENDING_IDLE));
> +
> + seq_printf(m, "Sending TP2 TP3: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_SENDING_TP2_TP3));
> +
> + seq_printf(m, "Sending TP1: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_SENDING_TP1));
> +
> + seq_printf(m, "Idle Count: %u\n",
> + psrstat & EDP_PSR_STATUS_IDLE_MASK);
> +
> + psrperf = (I915_READ(EDP_PSR_PERF_CNT)) & EDP_PSR_PERF_CNT_MASK;
> + seq_printf(m, "Performance Counter: %u\n", psrperf);
> +
> + return 0;
> +}
> +
> static ssize_t
> i915_wedged_read(struct file *filp,
> char __user *ubuf,
> @@ -2249,6 +2340,7 @@ static struct drm_info_list i915_debugfs_list[] = {
> {"i915_swizzle_info", i915_swizzle_info, 0},
> {"i915_ppgtt_info", i915_ppgtt_info, 0},
> {"i915_dpio", i915_dpio_info, 0},
> + {"i915_edp_psr_status", i915_edp_psr_status, 0},
> };
> #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1e31f23..1f7e666 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1615,6 +1615,30 @@
>
> #define EDP_PSR_STATUS_CTL 0x648
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Hook PSR functionality
Hi
2013/2/25 Rodrigo Vivi :
> PSR must be enabled after transcoder and port are running.
> And it is only available for HSW.
>
> v2: move enable/disable to intel_ddi
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 816c45c..bbfdcfd 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1321,6 +1321,7 @@ static void intel_enable_ddi(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> ironlake_edp_backlight_on(intel_dp);
> + intel_edp_enable_psr(intel_dp);
> }
>
> if (intel_crtc->eld_vld) {
> @@ -1345,6 +1346,7 @@ static void intel_disable_ddi(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> ironlake_edp_backlight_off(intel_dp);
> + intel_edp_disable_psr(intel_dp);
The spec suggests PSR should be disabled even before backlight (it
also suggests audio should be disabled before backlight, and I notice
this seems to be wrong in our code).
> }
>
> tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> --
> 1.8.1.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3
Hi 2013/2/25 Rodrigo Vivi : > PSR is an eDP feature that allows power saving even with static image at eDP > screen. > > v3: Accepted many suggestions that I received at v2 review, fixing, cleaning > and improving the code. > > v2: Main differences in this v2: > - Created vbt struct to get i915 dev_priv more organized and to avoid adding > more stuff into it. > - migrated hsw macros to use transcoder instead of pipes than I could address > eDP > - remove patch that was only adding edp psr registers and added them on demand > > v1: > Shobit Kumar has implemented this patch series some time ago, but had no eDP > panel with PSR capability to test them. > > I could test and verify that this series fully identify PSR capability and > enables it at HSW. > I also verified that it saves from 0.5-1W but only when in blank screen. It > seems it is not really entering in sleeping mode with static image at eDP > screen yet. What do you mean with "blank screen"? It seems we disable PSR before blanking the screen, so the 0.5-1W saving could be from the backlight. Did you try masking more bits on the SRD_DEBUG register to see if it enters PSR more easily? The first test I'd try would be to set 1 to all those mask regs and see what happens (maybe we'll enter PSR and never ever leave it again?). > > Please accept this series as the first part of PSR enabling while we continue > working to improve its functionality. > > Rodrigo Vivi (5): > drm/i915: Organize VBT stuff inside drm_i915_private > drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe > drm/i915: Enable/Disable PSR > drm/i915: Added debugfs support for PSR Status > drm/i915: Hook PSR functionality > > Shobhit Kumar (3): > drm/i915: Added SDP and VSC structures for handling PSR for eDP > drm/i915: Read the EDP DPCD and PSR Capability > drm/i915: VBT Parsing for the PSR Feature Block for HSW > > drivers/gpu/drm/i915/i915_debugfs.c | 92 > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 63 ++- > drivers/gpu/drm/i915/i915_reg.h | 82 -- > drivers/gpu/drm/i915/intel_bios.c| 126 + > drivers/gpu/drm/i915/intel_bios.h| 20 +++- > drivers/gpu/drm/i915/intel_crt.c | 4 +- > drivers/gpu/drm/i915/intel_ddi.c | 2 + > drivers/gpu/drm/i915/intel_display.c | 16 +-- > drivers/gpu/drm/i915/intel_dp.c | 208 > ++- > drivers/gpu/drm/i915/intel_drv.h | 4 + > drivers/gpu/drm/i915/intel_hdmi.c| 13 ++- > drivers/gpu/drm/i915/intel_lvds.c| 20 ++-- > drivers/gpu/drm/i915/intel_sdvo.c| 6 +- > drivers/gpu/drm/i915/intel_tv.c | 8 +- > include/drm/drm_dp_helper.h | 22 > 16 files changed, 569 insertions(+), 125 deletions(-) > > -- > 1.8.1.2 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3
On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote: > Hi > > 2013/2/25 Rodrigo Vivi : > > PSR is an eDP feature that allows power saving even with static image at > > eDP screen. > > > > v3: Accepted many suggestions that I received at v2 review, fixing, > > cleaning and improving the code. > > > > v2: Main differences in this v2: > > - Created vbt struct to get i915 dev_priv more organized and to avoid > > adding more stuff into it. > > - migrated hsw macros to use transcoder instead of pipes than I could > > address eDP > > - remove patch that was only adding edp psr registers and added them on > > demand > > > > v1: > > Shobit Kumar has implemented this patch series some time ago, but had no > > eDP panel with PSR capability to test them. > > > > I could test and verify that this series fully identify PSR capability and > > enables it at HSW. > > I also verified that it saves from 0.5-1W but only when in blank screen. It > > seems it is not really entering in sleeping mode with static image at eDP > > screen yet. > > What do you mean with "blank screen"? It seems we disable PSR before > blanking the screen, so the 0.5-1W saving could be from the backlight. > Did you try masking more bits on the SRD_DEBUG register to see if it > enters PSR more easily? The first test I'd try would be to set 1 to > all those mask regs and see what happens (maybe we'll enter PSR and > never ever leave it again?). One thing I'm wondering if we can even enable PSR w/o implementing the FBC tracking bits. I mean what happens if someone renders to the front buffer while PSR is active? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43751] [TTM] Out of kernel memory
https://bugzilla.kernel.org/show_bug.cgi?id=43751 --- Comment #12 from Peter Barth 2013-02-28 19:08:52 --- Seems to be fixed for me with 3.8.0. No kernel-crash/reboot for 3 days, yay! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #30 from Benjamin Bellec --- (In reply to comment #28) > Andreas Boll requested a branch of all my latest Mesa patches for people to > test it. It's here: > > git://people.freedesktop.org/~mareko/mesa master Awesome! With my RV770 all is rendering correctly now in CS:S! Moreover, I'm always at 60FPS (vsync certainly enabled) with all graphical options enabled (even MSAA 2x) (1680*1050)! Note that I'm using 3.7.9-201.fc18.x86_64. -- 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
radeon_gem_object_create:69 alloc size 139Mb bigger than 128Mb limit (RS780)
Running the latest Linus git kernel I occasionally see the following warning: radeon_gem_object_create:69 alloc size 139Mb bigger than 128Mb limit >From dmesg: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D). [drm] register mmio base: 0xFBEE [drm] register mmio size: 65536 ATOM BIOS: 113 radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M used) radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 32bits DDR [TTM] Zone kernel: Available graphics memory: 4083398 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm] PCIE GART of 512M enabled (table at 0xC004). radeon :01:05.0: WB enabled radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x8802163d1c00 radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8802163d1c0c radeon :01:05.0: setting latency timer to 64 [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D-1 [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xF0142000 [drm] vram apper at 0xF000 [drm] size 7299072 [drm] fb depth is 24 [drm]pitch is 6912 -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #22 from LRN --- Still getting this. Linux kernel 3.8.0 (9e2d59ad580d590134285f361a0e80f0e98c0207) xf86-video-ati 343b01c9bf35b125cd0c3df8db7c01a5fb227bda -- 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 v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
On Thu, Feb 28, 2013 at 2:51 AM, Joonyoung Shim wrote: > My mistake. If CONFIG_PINCTRL is disabled, devm_pinctrl_get_select_default > can return NULL. Yes, and that is perfectly legal and *NOT* an error. > devm_pinctrl_get_select() and pinctrl_get_select() also need IS_ERR_OR_NULL > instead of IS_ERR? No. In fact, IS_ERR_OR_NULL() shall not be used at all. Check the LKML mailinglist for Russells recent struggle to purge it from the kernel. > And many drivers using above functions don't check NULL, right? No, and they should not. Stub pinctrl handles, just like stub clocks and stub regulators, are perfectly legal, just that they have no effect. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #36 from Alexandre Demers --- This commit seems to have fixed the "GPU fault detected" message 62329d77b8065b5fd41179d6013c8adf6d86cfc7 Author Brian Paul Author date 2/25/13 8:00 PM Parent svga: fix comment typos Child r600g: synchronize streamout buffers on r6xx too (v3) Branch master (i965/fs: Put immediate operand as src2) Branch origin/master (i965/fs: Put immediate operand as src2) Follows snb-magic (graw: Add struct pipe_surface forward declaration.) winsys/null: fix var typo templet->templat Now, let's get back to the main bug: corruption. Is it me or is there a 4X4 pattern in the corruption? 2^4 or << 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 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #37 from Jakob Nixdorf --- Created attachment 75725 --> https://bugs.freedesktop.org/attachment.cgi?id=75725&action=edit Corruption in Trine 2 Yes it looks like some regular 4x4 pattern. I made a screenshoot of the Trine 2 startscreen with the corruption in the title and at the borders of the exit dialog. -- 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 60995] Account request for libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=60995 Tollef Fog Heen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tollef Fog Heen --- Account created, welcome. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 02/21/2013 04:18 PM, Joonyoung Shim wrote:
> On 02/21/2013 04:12 PM, Vikas Sajjan wrote:
>> Hi,
>>
>> On 21 February 2013 12:25, Joonyoung Shim
>> wrote:
>>> Hi,
>>>
>>>
>>> On 02/15/2013 03:43 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if
'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37
++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..8b2c0ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,7 +19,9 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -877,16 +879,43 @@ static int fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS("%s\n", __FILE__);
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(dev, "no platform data specified\n");
- return -EINVAL;
+ if (pdev->dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR("memory allocation for pdata
failed\n");
+ return -ENOMEM;
+ }
+
+ fbmode = &pdata->panel.timing;
+ ret = of_get_fb_videomode(dev->of_node, fbmode,
+ OF_USE_NATIVE_MODE);
>>>
>>> fbmode variable can be substituted to &pdata->panel.timing directly
>>> then can
>>> remove fbmode variable.
>>>
>> this is can be done.
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode()\n"
+ "with return value: %d\n", ret);
+ return ret;
+ }
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
>>>
>>> It's enough to "if (IS_ERR(pctrl)) {".
>>>
>> what if it returns NULL?
>
> devm_pinctrl_get_select_default() never return NULL.
>
My mistake. If CONFIG_PINCTRL is disabled,
devm_pinctrl_get_select_default can return NULL.
Linus,
devm_pinctrl_get_select() and pinctrl_get_select() also need
IS_ERR_OR_NULL instead of IS_ERR?
And many drivers using above functions don't check NULL, right?
Thanks.
>
+ DRM_ERROR("failed:
devm_pinctrl_get_select_default()\n"
+ "with return value: %d\n",
PTR_RET(pctrl));
+ return PTR_RET(pctrl);
>>>
>>> It's enough to "return PTR_ERR(pctrl);"
>>>
>> ok.
>>
+ }
>>>
>>> If this needs, parts for pinctrl should go to another patch.
>>>
>> I have it as a separate patch already. [PATCH v7 2/2] video: drm:
>> exynos: Add pinctrl support to fimd
+
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR("no platform data specified\n");
+ return -EINVAL;
+ }
}
panel = &pdata->panel;
>>>
>>> Thanks.
>>
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #34 from Alexandre Demers --- (In reply to comment #32) > Created attachment 75658 [details] [review] > align dma commands to 8 dwords > > Does this patch help? You might also try it in combination with this patch: > http://lists.freedesktop.org/archives/mesa-dev/2013-February/035347.html Tried proposed patch and the 5 patches from the link (the link and the 4 others) and still the same corruption. However, I noticed the errors seam to have gone with latest mesa from git (no link with the patches, tested with and without them). I ran steam and RendererFeatTest64 and no error appeared in dmesg anymore. What about you Jakob? -- 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/20130228/06f71aad/attachment.html>
[PATCH v8 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..7932dc2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -20,6 +20,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -883,10 +884,26 @@ static int fimd_probe(struct platform_device *pdev)
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(dev, "no platform data specified\n");
> - return -EINVAL;
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + DRM_ERROR("memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> +
> + ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
> + OF_USE_NATIVE_MODE);
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode()\n"
> + "with return value: %d\n", ret);
Could you make this error log to one line?
except this,
Acked-by: Joonyoung Shim
> + return ret;
> + }
> + } else {
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + DRM_ERROR("no platform data specified\n");
> + return -EINVAL;
> + }
> }
>
> panel = &pdata->panel;
[PATCH] drm/exynos: modify the compatible string for exynos fimd
On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
> value should be named after first specific SoC model in which this
> particular IP version was included as discussed at
> https://patchwork.kernel.org/patch/2144861/
>
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 9537761..433ed35 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -109,9 +109,9 @@ struct fimd_context {
>
> #ifdef CONFIG_OF
> static const struct of_device_id fimd_driver_dt_match[] = {
> - { .compatible = "samsung,exynos4-fimd",
> + { .compatible = "samsung,exynos4210-fimd",
> .data = &exynos4_fimd_driver_data },
> - { .compatible = "samsung,exynos5-fimd",
> + { .compatible = "samsung,exynos5250-fimd",
> .data = &exynos5_fimd_driver_data },
> {},
> };
Acked-by: Joonyoung Shim
Thanks.
[PATCH v8 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
On 02/28/2013 11:45 AM, Vikas Sajjan wrote:
> Hi,
>
> On 28 February 2013 08:07, Joonyoung Shim wrote:
>> On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
>>> Add support for parsing the display-timing node using video helper
>>> function.
>>>
>>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>>> exists and the NON-DT logic is still maintained under the 'else' part.
>>>
>>> Signed-off-by: Leela Krishna Amudala
>>> Signed-off-by: Vikas Sajjan
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25
>>> +
>>>1 file changed, 21 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 9537761..7932dc2 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -20,6 +20,7 @@
>>>#include
>>>#include
>>>+#include
>>>#include
>>>#include
>>>@@ -883,10 +884,26 @@ static int fimd_probe(struct platform_device
>>> *pdev)
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>>- pdata = pdev->dev.platform_data;
>>> - if (!pdata) {
>>> - dev_err(dev, "no platform data specified\n");
>>> - return -EINVAL;
>>> + if (pdev->dev.of_node) {
>>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>> + if (!pdata) {
>>> + DRM_ERROR("memory allocation for pdata failed\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + ret = of_get_fb_videomode(dev->of_node,
>>> &pdata->panel.timing,
>>> + OF_USE_NATIVE_MODE);
>>> + if (ret) {
>>> + DRM_ERROR("failed: of_get_fb_videomode()\n"
>>> + "with return value: %d\n", ret);
>>
>> Could you make this error log to one line?
>>
> The Line was going beyond 80 line marks, hence I had to split it.
So remove or contract some log messages, e.g. "with return value"
I think that is unnecessary.
>> except this,
>> Acked-by: Joonyoung Shim
>>
>>
>>> + return ret;
>>> + }
>>> + } else {
>>> + pdata = pdev->dev.platform_data;
>>> + if (!pdata) {
>>> + DRM_ERROR("no platform data specified\n");
>>> + return -EINVAL;
>>> + }
>>> }
>>> panel = &pdata->panel;
>>
>
>
[PATCH v8 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
On Thu, Feb 28, 2013 at 8:21 AM, Joonyoung Shim
wrote:
> On 02/28/2013 11:45 AM, Vikas Sajjan wrote:
>>
>> Hi,
>>
>> On 28 February 2013 08:07, Joonyoung Shim wrote:
>>>
>>> On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25
+
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..7932dc2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include
@@ -883,10 +884,26 @@ static int fimd_probe(struct platform_device
*pdev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(dev, "no platform data specified\n");
- return -EINVAL;
+ if (pdev->dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR("memory allocation for pdata
failed\n");
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev->of_node,
&pdata->panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode()\n"
+ "with return value: %d\n", ret);
>>>
>>>
>>> Could you make this error log to one line?
>>>
>> The Line was going beyond 80 line marks, hence I had to split it.
>
>
> So remove or contract some log messages, e.g. "with return value"
> I think that is unnecessary.
>
Will do and resend.
>
>>> except this,
>>> Acked-by: Joonyoung Shim
>>>
>>>
+ return ret;
+ }
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR("no platform data specified\n");
+ return -EINVAL;
+ }
}
panel = &pdata->panel;
>>>
>>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #35 from Jakob Nixdorf --- Yes, it seems the dmesg errors are gone. I will try piglit later to confirm this. -- 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/20130228/eb8512f8/attachment.html>
[Bug 54581] New: Radeon: Failed to parse relocation, gem object lookup failed
https://bugzilla.kernel.org/show_bug.cgi?id=54581 Summary: Radeon: Failed to parse relocation, gem object lookup failed Product: Drivers Version: 2.5 Kernel Version: 3.8 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: mezin.alexander at gmail.com Regression: No When I run Xonotic on discrete gpu (DRI_PRIME=1), sometimes I see only black screen, and dmesg is full of these messages: [ 5172.729073] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xa [ 5172.729078] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Radeon starts working again only after reboot -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 54581] Radeon: Failed to parse relocation, gem object lookup failed
https://bugzilla.kernel.org/show_bug.cgi?id=54581 --- Comment #1 from Alexander Mezin 2013-02-28 09:30:28 --- Created an attachment (id=94231) --> (https://bugzilla.kernel.org/attachment.cgi?id=94231) Syslog Video cards: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Subsystem: Hewlett-Packard Company Device 3388 Kernel driver in use: i915 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler XT [AMD Radeon HD 6700M Series] (rev ff) Kernel driver in use: radeon -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #28 from Marek Ol??k --- Andreas Boll requested a branch of all my latest Mesa patches for people to test it. It's here: git://people.freedesktop.org/~mareko/mesa master -- 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/20130228/fe732923/attachment.html>
[PATCH v2 1/3] arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not.
This will allow me to call functions that have multiple arguments if fastpath
fails.
This is required to support ticket mutexes, because they need to be able to
pass an
extra argument to the fail function.
Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg.
This ended up being just a duplication of the existing function, so a way to
test
if fastpath was called ended up being better.
This also cleaned up the reservation mutex patch some by being able to call an
atomic_set instead of atomic_xchg, and making it easier to detect if the wrong
unlock function was previously used.
Signed-off-by: Maarten Lankhorst
---
arch/ia64/include/asm/mutex.h| 10 --
arch/powerpc/include/asm/mutex.h | 10 --
arch/sh/include/asm/mutex-llsc.h |4 ++--
arch/x86/include/asm/mutex_32.h | 11 ---
arch/x86/include/asm/mutex_64.h | 11 ---
include/asm-generic/mutex-dec.h | 10 --
include/asm-generic/mutex-null.h |2 +-
include/asm-generic/mutex-xchg.h | 10 --
kernel/mutex.c | 32 ++--
9 files changed, 41 insertions(+), 59 deletions(-)
diff --git a/arch/ia64/include/asm/mutex.h b/arch/ia64/include/asm/mutex.h
index bed73a6..f41e66d 100644
--- a/arch/ia64/include/asm/mutex.h
+++ b/arch/ia64/include/asm/mutex.h
@@ -29,17 +29,15 @@ __mutex_fastpath_lock(atomic_t *count, void
(*fail_fn)(atomic_t *))
* __mutex_fastpath_lock_retval - try to take the lock by moving the count
* from 1 to a 0 value
* @count: pointer of type atomic_t
- * @fail_fn: function to call if the original value was not 1
*
- * Change the count from 1 to a value lower than 1, and call if
- * it wasn't 1 originally. This function returns 0 if the fastpath succeeds,
- * or anything the slow path function returns.
+ * Change the count from 1 to a value lower than 1. This function returns 0
+ * if the fastpath succeeds, or -1 otherwise.
*/
static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count)
{
if (unlikely(ia64_fetchadd4_acq(count, -1) != 1))
- return fail_fn(count);
+ return -1;
return 0;
}
diff --git a/arch/powerpc/include/asm/mutex.h b/arch/powerpc/include/asm/mutex.h
index 5399f7e..127ab23 100644
--- a/arch/powerpc/include/asm/mutex.h
+++ b/arch/powerpc/include/asm/mutex.h
@@ -82,17 +82,15 @@ __mutex_fastpath_lock(atomic_t *count, void
(*fail_fn)(atomic_t *))
* __mutex_fastpath_lock_retval - try to take the lock by moving the count
* from 1 to a 0 value
* @count: pointer of type atomic_t
- * @fail_fn: function to call if the original value was not 1
*
- * Change the count from 1 to a value lower than 1, and call if
- * it wasn't 1 originally. This function returns 0 if the fastpath succeeds,
- * or anything the slow path function returns.
+ * Change the count from 1 to a value lower than 1. This function returns 0
+ * if the fastpath succeeds, or -1 otherwise.
*/
static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count)
{
if (unlikely(__mutex_dec_return_lock(count) < 0))
- return fail_fn(count);
+ return -1;
return 0;
}
diff --git a/arch/sh/include/asm/mutex-llsc.h b/arch/sh/include/asm/mutex-llsc.h
index 090358a..dad29b6 100644
--- a/arch/sh/include/asm/mutex-llsc.h
+++ b/arch/sh/include/asm/mutex-llsc.h
@@ -37,7 +37,7 @@ __mutex_fastpath_lock(atomic_t *count, void
(*fail_fn)(atomic_t *))
}
static inline int
-__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
+__mutex_fastpath_lock_retval(atomic_t *count)
{
int __done, __res;
@@ -51,7 +51,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int
(*fail_fn)(atomic_t *))
: "t");
if (unlikely(!__done || __res != 0))
- __res = fail_fn(count);
+ __res = -1;
return __res;
}
diff --git a/arch/x86/include/asm/mutex_32.h b/arch/x86/include/asm/mutex_32.h
index 03f90c8..b7f6b34 100644
--- a/arch/x86/include/asm/mutex_32.h
+++ b/arch/x86/include/asm/mutex_32.h
@@ -42,17 +42,14 @@ do {
\
* __mutex_fastpath_lock_retval - try to take the lock by moving the count
* from 1 to a 0 value
* @count: pointer of type atomic_t
- * @fail_fn: function to call if the original value was not 1
*
- * Change the count from 1 to a value lower than 1, and call if it
- * wasn't 1 originally. This function returns 0 if the fastpath succeeds,
- * or anything the slow path function returns
+ * Change the count from 1 to a value lower than 1. This function returns 0
+ * if the fastpath succeeds, or 1 otherwise.
*/
-static inline int __mut
[PATCH v2 2/3] mutex: add support for reservation style locks, v2
New version. All of the documentation has been moved from the commit log to
Documentation/reservation-mutex-design.txt
Missing at the moment, maybe TODO?
Add a lockdep check in the *_slow calls that verifies that the lock
being nested into has no nested lock any more? This would be a check
to make sure that mutex_unreserve_unlock has been called on all other
locks correctly.
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex_lock_retval_arg, add warnings when using wrong
combination of
mutex_(,reserve_)lock/unlock.
Changes since v1:
- Add __always_inline to __mutex_lock_common, otherwise reservation paths can
be
triggered from normal locks, because __builtin_constant_p might evaluate to
false
for the constant 0 in that case. Tests for this have been added in the next
patch.
- Updated documentation slightly.
Signed-off-by: Maarten Lankhorst
---
Documentation/reservation-mutex-design.txt | 136
include/linux/mutex.h | 86 +++
kernel/mutex.c | 326 +++-
3 files changed, 531 insertions(+), 17 deletions(-)
create mode 100644 Documentation/reservation-mutex-design.txt
diff --git a/Documentation/reservation-mutex-design.txt
b/Documentation/reservation-mutex-design.txt
new file mode 100644
index 000..4e2866c
--- /dev/null
+++ b/Documentation/reservation-mutex-design.txt
@@ -0,0 +1,136 @@
+Reservation type mutexes
+---
+
+Please read mutex-design.txt first, as it applies to reservation mutexes too.
+
+GPU's do operations that commonly involve many buffers. Those buffers
+can be shared across contexts/processes, exist in different memory
+domains (for example VRAM vs system memory), and so on. And with
+PRIME / dmabuf, they can even be shared across devices. So there are
+a handful of situations where the driver needs to wait for buffers to
+become ready. If you think about this in terms of waiting on a buffer
+mutex for it to become available, this presents a problem because
+there is no way to guarantee that buffers appear in a execbuf/batch in
+the same order in all contexts. That is directly under control of
+userspace, and a result of the sequence of GL calls that an application
+makes. Which results in the potential for deadlock. The problem gets
+more complex when you consider that the kernel may need to migrate the
+buffer(s) into VRAM before the GPU operates on the buffer(s), which
+may in turn require evicting some other buffers (and you don't want to
+evict other buffers which are already queued up to the GPU), but for a
+simplified understanding of the problem you can ignore this.
+
+The algorithm that TTM came up with for dealing with this problem is
+quite simple. For each group of buffers (execbuf) that need to be
+locked, the caller would be assigned a unique reservation_id, from a
+global counter. In case of deadlock while locking all the buffers
+associated with a execbuf, the one with the lowest reservation_id
+wins, and the one with the higher reservation_id unlocks all of the
+buffers that it has already locked, and then tries again.
+
+How it is used:
+---
+
+A very simplified version:
+
+int lock_execbuf(execbuf, ticket)
+{
+struct buf *res_buf = NULL;
+
+/* acquiring locks, before queuing up to GPU: */
+*ticket = assign_global_seqno();
+
+retry:
+for (buf in execbuf->buffers) {
+if (buf == res_buf) {
+res_buf = NULL;
+continue;
+}
+ret = mutex_reserve_lock(&buf->lock, ticket, ticket->seqno);
+if (ret < 0)
+goto err;
+}
+
+/* now everything is good to go, submit job to GPU: */
+...
+
+return 0;
+
+err:
+for (all buf2 before buf in execbuf->buffers)
+mutex_unreserve_unlock(&buf2->lock);
+if (res_buf)
+mutex_unreserve_unlock(&res_buf->lock);
+
+if (ret == -EAGAIN) {
+/* we lost out in a seqno race, lock and retry.. */
+mutex_reserve_lock_slow(&buf->lock, ticket, ticket->seqno);
+res_buf = buf;
+goto retry;
+}
+release_global_seqno(ticket);
+
+return ret;
+}
+
+int unlock_execbuf(execbuf, ticket)
+{
+/* when GPU is finished; */
+for (buf in execbuf->buffers)
+mutex_unreserve_unlock(&buf->lock);
+release_global_seqno(ticket);
+}
+
+Functions:
+--
+
+mutex_reserve_lock, and mutex_reserve_lock_interruptible:
+ Lock a reservation_lock with a reservation_id set. reservation_id must not
+ be set to 0, since this is a special value that means no reservation_id.
+
+ N
[PATCH v2 3/3] reservation: Add tests to lib/locking-selftest.c. v2
This stresses the lockdep code in some ways specifically useful to
reservations. It adds checks for most of the common locking errors.
Since the lockdep tests were originally written to stress the
reservation code, I duplicated some of the definitions into
lib/locking-selftest.c for now.
This will be cleaned up later when the api for reservations is
accepted. I don't expect the tests to change, since the discussion
is mostly about the fence aspect of reservations.
Changes since v1:
- Add tests to verify reservation_id is untouched.
- Use L() and U() macros where possible.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 588 ++--
1 file changed, 569 insertions(+), 19 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index c3eb261..2c52c0e 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -26,6 +26,67 @@
*/
static unsigned int debug_locks_verbose;
+/*
+ * These definitions are from the reservation objects patch series.
+ * For now we have to define it ourselves here. These definitions will
+ * be removed upon acceptance of that patch series.
+ */
+static const char reservation_object_name[] = "reservation_object";
+static struct lock_class_key reservation_object_class;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+static const char reservation_ticket_name[] = "reservation_ticket";
+static struct lock_class_key reservation_ticket_class;
+#endif
+
+struct reservation_object {
+ struct ticket_mutex lock;
+};
+
+struct reservation_ticket {
+ unsigned long seqno;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
+};
+
+static inline void
+reservation_object_init(struct reservation_object *obj)
+{
+ __ticket_mutex_init(&obj->lock, reservation_object_name,
+ &reservation_object_class);
+}
+
+static inline void
+reservation_object_fini(struct reservation_object *obj)
+{
+ mutex_destroy(&obj->lock.base);
+}
+
+static inline void
+reservation_ticket_init(struct reservation_ticket *t)
+{
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ /*
+* Make sure we are not reinitializing a held ticket:
+*/
+
+ debug_check_no_locks_freed((void *)t, sizeof(*t));
+ lockdep_init_map(&t->dep_map, reservation_ticket_name,
+&reservation_ticket_class, 0);
+#endif
+ mutex_acquire(&t->dep_map, 0, 0, _THIS_IP_);
+ t->seqno = 5;
+}
+
+static inline void
+reservation_ticket_fini(struct reservation_ticket *t)
+{
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ mutex_release(&t->dep_map, 0, _THIS_IP_);
+ t->seqno = 0;
+#endif
+}
+
static int __init setup_debug_locks_verbose(char *str)
{
get_option(&str, &debug_locks_verbose);
@@ -42,6 +103,7 @@ __setup("debug_locks_verbose=", setup_debug_locks_verbose);
#define LOCKTYPE_RWLOCK0x2
#define LOCKTYPE_MUTEX 0x4
#define LOCKTYPE_RWSEM 0x8
+#define LOCKTYPE_RESERVATION 0x10
/*
* Normal standalone locks, for the circular and irq-context
@@ -920,11 +982,17 @@ GENERATE_PERMUTATIONS_3_EVENTS(irq_read_recursion_soft)
static void reset_locks(void)
{
local_irq_disable();
+ lockdep_free_key_range(&reservation_object_class, 1);
+ lockdep_free_key_range(&reservation_ticket_class, 1);
+
I1(A); I1(B); I1(C); I1(D);
I1(X1); I1(X2); I1(Y1); I1(Y2); I1(Z1); I1(Z2);
lockdep_reset();
I2(A); I2(B); I2(C); I2(D);
init_shared_classes();
+
+ memset(&reservation_object_class, 0, sizeof(reservation_object_class));
+ memset(&reservation_ticket_class, 0, sizeof(reservation_ticket_class));
local_irq_enable();
}
@@ -938,7 +1006,6 @@ static int unexpected_testcase_failures;
static void dotest(void (*testcase_fn)(void), int expected, int lockclass_mask)
{
unsigned long saved_preempt_count = preempt_count();
- int expected_failure = 0;
WARN_ON(irqs_disabled());
@@ -946,26 +1013,16 @@ static void dotest(void (*testcase_fn)(void), int
expected, int lockclass_mask)
/*
* Filter out expected failures:
*/
+ if (debug_locks != expected) {
#ifndef CONFIG_PROVE_LOCKING
- if ((lockclass_mask & LOCKTYPE_SPIN) && debug_locks != expected)
- expected_failure = 1;
- if ((lockclass_mask & LOCKTYPE_RWLOCK) && debug_locks != expected)
- expected_failure = 1;
- if ((lockclass_mask & LOCKTYPE_MUTEX) && debug_locks != expected)
- expected_failure = 1;
- if ((lockclass_mask & LOCKTYPE_RWSEM) && debug_locks != expected)
- expected_failure = 1;
+ expected_testcase_failures++;
+ printk("failed|");
+#else
+ unexpected_testcase_failures++;
+ printk("FAILED|");
+
+ dump_stack();
#endif
- if (debug_locks != expected) {
- if (expected_failure) {
- expected_testcase_failures++;
-
[git pull] drm merge for 3.9-rc1
u/drm/i915/intel_dp.c:1457:1: error: invalid storage class for function 'intel_dp_get_link_status' drivers/gpu/drm/i915/intel_dp.c:1483:1: error: invalid storage class for function 'intel_dp_voltage_max' drivers/gpu/drm/i915/intel_dp.c:1496:1: error: invalid storage class for function 'intel_dp_pre_emphasis_max' drivers/gpu/drm/i915/intel_dp.c:1538:1: error: invalid storage class for function 'intel_get_adjust_train' drivers/gpu/drm/i915/intel_dp.c:1569:1: error: invalid storage class for function 'intel_gen4_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1608:1: error: invalid storage class for function 'intel_gen6_edp_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1636:1: error: invalid storage class for function 'intel_gen7_edp_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1667:1: error: invalid storage class for function 'intel_hsw_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1701:1: error: invalid storage class for function 'intel_dp_set_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1728:1: error: invalid storage class for function 'intel_dp_set_link_train' drivers/gpu/drm/i915/intel_dp.c:1986:1: error: invalid storage class for function 'intel_dp_link_down' drivers/gpu/drm/i915/intel_dp.c:2065:1: error: invalid storage class for function 'intel_dp_get_dpcd' drivers/gpu/drm/i915/intel_dp.c:2096:1: error: invalid storage class for function 'intel_dp_probe_oui' drivers/gpu/drm/i915/intel_dp.c:2117:1: error: invalid storage class for function 'intel_dp_get_sink_irq' drivers/gpu/drm/i915/intel_dp.c:2131:1: error: invalid storage class for function 'intel_dp_handle_test_request' drivers/gpu/drm/i915/intel_dp.c:2195:1: error: invalid storage class for function 'intel_dp_detect_dpcd' drivers/gpu/drm/i915/intel_dp.c:2234:1: error: invalid storage class for function 'ironlake_dp_detect' drivers/gpu/drm/i915/intel_dp.c:2256:1: error: invalid storage class for function 'g4x_dp_detect' drivers/gpu/drm/i915/intel_dp.c:2284:1: error: invalid storage class for function 'intel_dp_get_edid' drivers/gpu/drm/i915/intel_dp.c:2310:1: error: invalid storage class for function 'intel_dp_get_edid_modes' drivers/gpu/drm/i915/intel_dp.c:2328:1: error: invalid storage class for function 'intel_dp_detect' drivers/gpu/drm/i915/intel_dp.c:2364:12: error: invalid storage class for function 'intel_dp_get_modes' drivers/gpu/drm/i915/intel_dp.c:2392:1: error: invalid storage class for function 'intel_dp_detect_audio' drivers/gpu/drm/i915/intel_dp.c:2408:1: error: invalid storage class for function 'intel_dp_set_property' drivers/gpu/drm/i915/intel_dp.c:2488:1: error: invalid storage class for function 'intel_dp_destroy' drivers/gpu/drm/i915/intel_dp.c:2522:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2522:2: error: (near initialization for 'intel_dp_helper_funcs.mode_fixup') drivers/gpu/drm/i915/intel_dp.c:2523:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2523:2: error: (near initialization for 'intel_dp_helper_funcs.mode_set') drivers/gpu/drm/i915/intel_dp.c:2528:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2528:2: error: (near initialization for 'intel_dp_connector_funcs.detect') drivers/gpu/drm/i915/intel_dp.c:2530:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2530:2: error: (near initialization for 'intel_dp_connector_funcs.set_property') drivers/gpu/drm/i915/intel_dp.c:2531:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2531:2: error: (near initialization for 'intel_dp_connector_funcs.destroy') drivers/gpu/drm/i915/intel_dp.c:2535:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2535:2: error: (near initialization for 'intel_dp_connector_helper_funcs.get_modes') drivers/gpu/drm/i915/intel_dp.c:2541:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2541:2: error: (near initialization for 'intel_dp_enc_funcs.destroy') drivers/gpu/drm/i915/intel_dp.c:2545:1: error: invalid storage class for function 'intel_dp_hot_plug' drivers/gpu/drm/i915/intel_dp.c:2592:1: error: invalid storage class for function 'intel_dp_add_properties' drivers/gpu/drm/i915/intel_dp.c:2611:1: error: invalid storage class for function 'intel_dp_init_panel_power_sequencer' drivers/gpu/drm/i915/intel_dp.c:2696:1: error: invalid storage class for function 'intel_dp_init_panel_power_sequencer_registers' drivers/gpu/drm/i915/intel_dp.c:2957:1: error: expected declaration or statement at end of input drivers/gpu/drm/i915/intel_dp.c:2957:1: error: expected declaration or statement at end of input drivers/gpu/drm/i915/intel_dp.c: At top level: drivers/gpu/drm/i915/intel_dp.c:110:13: warning: 'intel_dp_link_down' used but never defined [enabled by default] make[1]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1 make: *** [_module_drivers/gpu/drm/i915] Error 2 -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-i915-Add-some-debugging-to-intel_dp_aux_wait_don.patch Type: application/octet-stream Size: 1047 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130228/bac14375/attachment-0001.obj>
resume fails to light display on Macbook Pro Retina on 3.8-rc1
On 28 February 2013 00:02, Greg KH wrote: > On Wed, Feb 27, 2013 at 11:27:30PM +, James Courtier-Dutton wrote: >> On 26 February 2013 18:11, James Courtier-Dutton >> wrote: >> > On 26 February 2013 17:35, Greg KH wrote: >> >> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote: >> >>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote: >> >>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote: >> >>> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH > >>> > > linuxfoundation.org> wrote: >> >>> > > > Hi Ben, >> >>> > > > >> >>> > > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked >> >>> > > > this >> >>> > > > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 >> >>> > > > (drm/nvd0/disp: >> >>> > > > move link training helpers into core as display methods) >> >>> > > > >> >>> > > > Anything I can try to help solve this? >> >>> > > > >> >>> > > > Note, I'm using the Intel driver as the main controller for this >> >>> > > > laptop, >> >>> > > > well, I think I am, my xorg log is attached. >> >>> > > >> >>> > > No you are using the nvidia, the efi always boots nvidia enabled now. >> >>> > >> >>> > Really? When did that change? I thought I wanted to be using the >> >>> > Intel >> >>> > chip to save battery life. >> >>> > >> >>> > > btw I just tested my drm-next tree on mine and it resumed the display >> >>> > > fine, something oopsed a few seconds later that I haven't tracked >> >>> > > down >> >>> > > >> >>> > > git://git.freedesktop.org/~airlied/linux drm-next >> >>> > > >> >>> > > I'll be sending it to Linus this evening or tomorrow morning, once I >> >>> > > fix my tree. >> >>> > >> >>> > Ok, I'll test again when it hits Linus's tree, and if that works, it >> >>> > would be good to try to work out what patch fixes it to get them into >> >>> > the 3.8-stable series so that others don't run into the same problem. >> >>> >> >>> I've tested Linus's tree now (I'm guessing it has all of your changes in >> >>> it), and it works! >> >>> >> >>> I see a bunch of patches marked for the stable branch, so I'll try those >> >>> out and see if they fix the problem. If not, I'll let you and Ben know. >> >> >> >> I've applied the radeon patches tagged for -stable and tested that on >> >> 3.8.0, but that doesn't solve the resume problem. Any ideas of anything >> >> else I can do to test this? Doing a "backwards" git-bisect is a pain, >> >> but I guess I can do that to try to track down what patch fixed this, if >> >> that's the only idea people have... >> >> >> > >> > If it helps, I have a similar resume problem here. >> > 3.7.8 good >> > 3.8.0 bad >> > >> > Laptop with no nvidia, no amd graphics, just Intel Graphics 4000, 3rd >> > Gen I5 CPU. >> >> Problem: "Backlight not coming on after resume." >> git finally bisected for my Samsung Serial 7 Laptop. >> Bisecting: 0 revisions left to test after this (roughly 0 steps) >> [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight >> harder <- This is the problem commit. Seems that fixing some >> machines breaks others, based on the existing comments on that patch. > > Hm, so, 3.8.0 works for you, but 3.8.1-rc1 doesn't? Or are you saying > Linus's tree doesn't work for you? > > As you have a different issue here than the nvidia hardware I was > dealing with, you might want to try to start over with a new thread and > the needed info, and the needed people on it (i.e. the i915 > maintainers and mailing list.) > I little confusing sorry. I started using: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git For that 3.7.8 worked fine, 3.8 failed to restore X, but the backlight lights. I then moved to linus tree at: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git On Linus tree the problem commit is: [cf0a6584aa6d382f802f2c3cacac23ccbccde0cd] drm/i915: write backlight harder The problem on the Linux tree is different from the stable tree. Linus tree: Backlight fails to light up after resume. linux-stable tree: Failed to restore X, but the backlight lights. So, I think the linus tree fixes the "failed to restore X" bit, but introduced a new regression for the backlight. I don't know which patch from the Linus tree would fix the stable 3.8 tree. I will send an email to the i915 maintainers tomorrow.
[PATCH v4 6/9] drm/tegra: Implement page-flipping support
On 02/25/2013 08:06 AM, Thierry Reding wrote:
> On Fri, Feb 22, 2013 at 05:13:47PM +0100, Mario Kleiner wrote:
>> On 02/21/2013 03:35 PM, Thierry Reding wrote:
>>> All the necessary support bits like .mode_set_base() and VBLANK are now
>>> available, so page-flipping case easily be implemented on top.
>>>
>>> Signed-off-by: Thierry Reding
>>> ---
>>> Changes in v3:
>>> - use drm_send_vblank_event()
>>> - set crtc->fb field
>>>
>>> Changes in v4:
>>> - fix a potential race by checking that a framebuffer base has been
>>>latched when completing a page-flip
>>>
>>> drivers/gpu/drm/tegra/dc.c | 66
>>> +
>>> drivers/gpu/drm/tegra/dc.h | 2 ++
>>> drivers/gpu/drm/tegra/drm.c | 9 +++
>>> drivers/gpu/drm/tegra/drm.h | 5
>>> 4 files changed, 82 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index 5f55a25..c5d825f 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>> @@ -183,7 +183,72 @@ void tegra_dc_disable_vblank(struct tegra_dc *dc)
>>> spin_unlock_irqrestore(&dc->lock, flags);
>>> }
>>> +static void tegra_dc_finish_page_flip(struct tegra_dc *dc)
>>> +{
>>> + struct drm_device *drm = dc->base.dev;
>>> + struct drm_crtc *crtc = &dc->base;
>>> + struct drm_gem_cma_object *gem;
>>> + unsigned long flags, base;
>>> +
>>
>> The checks for properly latched scanout look good to me and should
>> fix the race between software and hardware. But shouldn't you
>> already spin_lock_irqsave() here, before checking dc->event and
>> performing write access on the DC_CMD_STATE_ACCESS registers? And
>> lock around most of the tegra_dc_page_flip() code below, like in
>> your previous iteration of the patch, to prevent a race between
>> pageflip ioctl and the vblank irq handler?
>
> Currently there's nothing else that touches the DC_CMD_STATE_ACCESS
> register, so that part should be safe.
>
ok.
> As to the locking that I removed since the previous patch, I looked at
> it more closely and didn't think it was necessary. Also nothing in my
> tests seemed to point to any race here, though I probably didn't cover
> everything.
>
>>> + if (!dc->event)
>>
>> -> !dc->event may exit prematurely because the irq handler on one
>> core doesn't notice the new setup of dc->event by
>> tegra_dc_page_flip() on a different core? Don't know if that can
>> happen, don't know the memory ordering of arm, but could imagine
>> that this or the compiler reordering instructions could cause
>> trouble without lock protection.
>
> I'm not sure I follow here. If the handler sees a NULL here, why would
> it want to continue? It can safely assume that the page flip wasn't
> setup for this interval, can't it?
>
> If indeed the VBLANK interrupt happens exactly around the assignment to
> dc->event, then we'll just schedule the page-flip for the next VBLANK.
>
I meant the other way round. dc->event is initially NULL. Then pageflip
ioctl is called, close to vblank, the code e.g., executing on core 1. if
(event) branch in tegra_dc_page_flip() executes, assigns dc->event =
event etc. calls tegra_dc_set_base() before onset of vblank, pageflip
completes in vblank, but the irq handler and thereby
tegra_dc_finish_page_flip() running on a different core doesn't notice
dc->event is non-NULL, because the changes haven't propagated to the
different core without some memory write barrier etc., thereby doesn't
run the flip completion in the vblank of actual flip completion. But i
now think my point is probably pointless, because the successive calls
to drm_vblank_get() and tegra_dc_set_base() contain enough locking and
implicit memory barriers that such a stale value there won't happen.
>>> + return;
>>> +
>>> + gem = drm_fb_cma_get_gem_obj(crtc->fb, 0);
>> -> crtc->fb gets updated in tegra_dc_page_flip() after
>> tegra_dc_set_base() without lock -> possibly stale fb here?
>
> Good point. That may indeed require a lock. I'll need to look more
> closely.
>
Yep, i think here my argument from above may hold for crtc->fb, nothing
here to prevent a race afaics.
>>> + /* check if new start address has been latched */
>>> + tegra_dc_writel(dc, READ_MUX, DC_CMD_STATE_ACCESS);
>>> + base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
>>> + tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);
>>> +
>>
>> -> Can other code in the driver write to DC_CMD_STATE_ACCESS,
>> simultaneously to tegra_dc_page_flip writing->reading->writing and
>> cause trouble?
>
> This is the only location where the DC_CMD_STATE_ACCESS register is
> actually used in the driver so we should be safe for now.
>
Ok. I'm just paranoid about forgetting such things on later changes.
>>> +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct
>>> drm_framebuffer *fb,
>>> + struct drm_pending_vblank_event *event)
>>> +{
>>> + struct tegra_dc *dc = to_tegra_dc(crtc);
>>> + struct drm_device *d
[PATCH] drm/exynos: modify the compatible string for exynos fimd
Thanks Mr. Shim.
On 28 February 2013 08:12, Joonyoung Shim wrote:
> On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
>>
>> modified compatible string for exynos4 fimd as "exynos4210-fimd" and
>> exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
>> value should be named after first specific SoC model in which this
>> particular IP version was included as discussed at
>> https://patchwork.kernel.org/patch/2144861/
>>
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..433ed35 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -109,9 +109,9 @@ struct fimd_context {
>> #ifdef CONFIG_OF
>> static const struct of_device_id fimd_driver_dt_match[] = {
>> - { .compatible = "samsung,exynos4-fimd",
>> + { .compatible = "samsung,exynos4210-fimd",
>> .data = &exynos4_fimd_driver_data },
>> - { .compatible = "samsung,exynos5-fimd",
>> + { .compatible = "samsung,exynos5250-fimd",
>> .data = &exynos5_fimd_driver_data },
>> {},
>> };
>
>
> Acked-by: Joonyoung Shim
>
> Thanks.
--
Thanks and Regards
Vikas Sajjan
[PATCH v8 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 28 February 2013 08:07, Joonyoung Shim wrote:
> On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
>>
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exists and the NON-DT logic is still maintained under the 'else' part.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25
>> +
>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 9537761..7932dc2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> +#include
>> #include
>> #include
>> @@ -883,10 +884,26 @@ static int fimd_probe(struct platform_device
>> *pdev)
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> - pdata = pdev->dev.platform_data;
>> - if (!pdata) {
>> - dev_err(dev, "no platform data specified\n");
>> - return -EINVAL;
>> + if (pdev->dev.of_node) {
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + DRM_ERROR("memory allocation for pdata failed\n");
>> + return -ENOMEM;
>> + }
>> +
>> + ret = of_get_fb_videomode(dev->of_node,
>> &pdata->panel.timing,
>> + OF_USE_NATIVE_MODE);
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode()\n"
>> + "with return value: %d\n", ret);
>
>
> Could you make this error log to one line?
>
The Line was going beyond 80 line marks, hence I had to split it.
> except this,
> Acked-by: Joonyoung Shim
>
>
>> + return ret;
>> + }
>> + } else {
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + DRM_ERROR("no platform data specified\n");
>> + return -EINVAL;
>> + }
>> }
>> panel = &pdata->panel;
>
>
--
Thanks and Regards
Vikas Sajjan
[PATCH v9 0/2] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v8: - replaced IS_ERR() with IS_ERR_OR_NULL(), because devm_pinctrl_get_select_default can return NULL, If CONFIG_PINCTRL is disabled. - modified the error log, such that it shall NOT cross 80 column. - added Acked-by. changes since v7: - addressed comments from Joonyoung Shim to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae , to remove the allocation of 'fbmode' and replaced '-1'in "of_get_fb_videomode(dev->of_node, fbmode, -1)" with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel , to modify the commit message changes since v3: - addressed comments from Sean Paul , to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma ) changes since v1: - addressed comments from Sean Paul Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function video: drm: exynos: Add pinctrl support to fimd drivers/gpu/drm/exynos/exynos_drm_fimd.c | 33 ++ 1 file changed, 29 insertions(+), 4 deletions(-) -- 1.7.9.5
[PATCH v9 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
Acked-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(dev, "no platform data specified\n");
- return -EINVAL;
+ if (pdev->dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR("memory allocation for pdata failed\n");
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR("no platform data specified\n");
+ return -EINVAL;
+ }
}
panel = &pdata->panel;
--
1.7.9.5
[PATCH v9 2/2] video: drm: exynos: Add pinctrl support to fimd
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e323cf9..21ada8d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -879,6 +880,7 @@ static int fimd_probe(struct platform_device *pdev)
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
struct resource *res;
+ struct pinctrl *pctrl;
int win;
int ret = -EINVAL;
@@ -897,6 +899,13 @@ static int fimd_probe(struct platform_device *pdev)
DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
return ret;
}
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR_OR_NULL(pctrl)) {
+ DRM_ERROR("failed: devm_pinctrl_get_select_default():"
+ "%d\n", PTR_RET(pctrl));
+ return PTR_ERR(pctrl);
+ }
+
} else {
pdata = pdev->dev.platform_data;
if (!pdata) {
--
1.7.9.5
[git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
> wrote:
> > Hi,
> >
> > I am seeing this also on Linux-Next.
> >
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > This seems to be hard reproducible...
> > Laptop-LCD... Sandybridge Mobile-GT2.
> >
> > Is there a way to force the error?
> >
> > Possible patch see [1].
> >
> > - Sedat -
> >
> > [1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ {
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 0/9] System Framebuffer Bus (sysfb)
Hi Dave
Sorry, I was busy reworking the HIDP layer. I finally got time to
continue my work on this again. See below:
On Mon, Feb 18, 2013 at 12:47 AM, Dave Airlie wrote:
[..snap..]
> As I said maybe I'm concentrating on the problem you aren't trying to fix,
> but then I'm not sure I've enough information on the problem you are
> trying to fix,
>
> remove_confilicting_framebuffers might be ugly but it does 90% of what we
> want,
> I just want to understand why this will make it better,
Ok, let me describe the problem in more detail:
We currently have different drivers that can make use of "system
framebuffers" (as I call them for now):
- vgacon
- fbdev
- DRM
(- vgalog) (similar to fblog/drmlog but using vga/VBE)
Scenarios:
- Imagine you have CONFIG_FB=n but VGACON=y for debugging. Who is then
responsible of kicking out VGACON when DRM drivers are loaded? (and
vice versa)
- i915 is loaded and the user does a "modprobe vesafb". Who prevents
vesafb from loading?
- If I use vgalog, who unloads it when fbdev/DRM drivers are loaded?
(and vice versa)
Our current solution consists of "vgacon_cleanup()" and
"remove_conflicting_frambuffers()". We could add similar helpers for
all other scenarios, but I promise, this will get pretty complex.
Another problem: All VBE/EFI framebuffer drivers currently do something like:
platform_driver_register("my-device"...);
platform_device_add("my-device"...);
Why not provide a unique platform-device-name and add the device in
architecture setup code? This would prevent multiple drivers from
being probed on a single platform device.
My bus-solution was the most straightforward to implement and makes
testing really easy (as you can probe/remove drivers from userspace).
However, I understand if we don't want to introduce any ABI.
So I was rethinking this idea and maybe we simplify the bus-solution
and instead use some priority-based driver loading. That is, the
architecture code creates a platform-device for all available
system-framebuffers (which is probably always at most one device).
Then drivers simply provide platform-drivers that can be loaded on the
device. But instead of using platform_driver_register(), they use
vbe_driver_register() or something similar and pass in the
platform-driver _plus_ a priority. The wrapper then compares the
priorities, unloads the old driver and probes the new one.
This guarantees that a new driver will only replace the current driver
if it has a higher priority. vgacon/vgalog->fbdev->DRM
How does that fix the problems you described?
Well, it doesn't. But it makes them more obvious as there is now a
central place that manages the hand-over.
On the other hand, I don't understand why the problems you described
have anything to do with the hand-over itself? They also occur on
driver-unloading without any handover, don't they?
So I think we simply need to fix vesafb, efifb, ... to unmap any
pending user-space mappings during unloading. This also guarantees
that these mappings are dead when any other driver takes over. And
with the platform-devices that I want to introduce, we guarantee that
the drivers get unloaded correctly even during hand-over.
The remove_conflicting_framebuffers() call can stay for all other
conflicts, although I think these _really_ should be handled by
Kconfig. But ok, I don't mind this call. It doesn't break anything.
Why am I doing this?
To get dvbe/defi and vbelog working. I use these on my machine as
nouveau doesn't work and fbdev is just ugly to work with. I was also
told that they proved to be useful in virtualization environments.
I don't mind setting dvbe as "depends on ! &&
!CONFIG_FB && !CONFIG_VT" but I thought fixing this directly where it
is broken ought to be the better way.
So, any comments welcome.
If there are no major objections, I will try to implement it and also
try to fix vesafb to unmap the mmap()s during unloading. If that turns
out to work well, I can also fix the other drivers.
Thanks for the comments
David
[PATCH] Fix build of swrast only without libdrm
Signed-off-by: Daniel Martin --- There's a small logic error preventing mesa to be build with swrast only and not having libdrm. configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 5701f8a..aa1b38a 100644 --- a/configure.ac +++ b/configure.ac @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then fi # if we are building any dri driver other than swrast or using the dri state tracker ... -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" = xyes; then +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" = xyes; then # ... libdrm is required if test "x$have_libdrm" != xyes; then AC_MSG_ERROR([DRI drivers requires libdrm >= $LIBDRM_REQUIRED]) -- 1.7.2.5
[PATCH 0/9] System Framebuffer Bus (sysfb)
On Thu, Feb 28, 2013 at 1:20 PM, David Herrmann
wrote:
> We currently have different drivers that can make use of "system
> framebuffers" (as I call them for now):
> - vgacon
> - fbdev
> - DRM
> (- vgalog) (similar to fblog/drmlog but using vga/VBE)
offb
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer wrote: > On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer wrote: >> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote: >>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote: On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: > Alex Deucher (29): > drm/radeon: halt engines before disabling MC (6xx/7xx) > drm/radeon: halt engines before disabling MC (evergreen) > drm/radeon: halt engines before disabling MC (cayman/TN) > drm/radeon: halt engines before disabling MC (si) > drm/radeon: use the reset mask to determine if rings are hung Something in this series of commits is causing the GPU to hang on reboot on my Dell XPS 8300 machine. That has a: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Caicos [Radeon HD 6450] card in it. After reboots, I get a screen that looks like this: http://t.co/tPnT6xQZUK I can hit it fairly consistently after a few reboots, so I tried doing a git bisect on the radeon driver and it came down to: ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>> >>> So I don't think that's actually the cause of the problem. Or at least >>> not that alone. I reverted it on top of Linus' latest tree and I still >>> get the lockups. >> >> Actually, git bisect does seem to have gotten it correct. Once I >> actually tested the revert of just that on top of Linus' tree (commit >> d895cb1af1), things seem to be working much better. I've rebooted a >> dozen times without a lockup. The most I've seen it take on a kernel >> with that commit included is 3 reboots, so that's definitely at least an >> improvement. > > I give up. GPU issues are not my thing. 2 reboots after I sent that it > gave me pretty rainbow static again. So it might have been an > improvement, but revert it is not a solution. > > Looking at there rest of the commits, the whole GPU rework might be > suspect, but I clearly have no clue. GPUs are tricky beasts :) ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the problem anyway since it only affects 6xx/7xx and your card is handled by the evergreen code. I'll put together some patches to help narrow down the problem. Alex
[Intel-gfx] [git pull] drm merge for 3.9-rc1
Hi
2013/2/28 Chris Wilson :
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>> wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
>
> That second '{' is the source of the compile error.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
[git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: > On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher > wrote: >> On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer wrote: >>> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer wrote: >>>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote: >>>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote: >>>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote: >>>>>>> Alex Deucher (29): >>>>>>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>>>>> drm/radeon: halt engines before disabling MC (evergreen) >>>>>>> drm/radeon: halt engines before disabling MC (cayman/TN) >>>>>>> drm/radeon: halt engines before disabling MC (si) >>>>>>> drm/radeon: use the reset mask to determine if rings are hung >>>>>> >>>>>> Something in this series of commits is causing the GPU to hang on reboot >>>>>> on my Dell XPS 8300 machine. That has a: >>>>>> >>>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>>>>> ATI Caicos [Radeon HD 6450] >>>>>> >>>>>> card in it. After reboots, I get a screen that looks like this: >>>>>> >>>>>> http://t.co/tPnT6xQZUK >>>>>> >>>>>> I can hit it fairly consistently after a few reboots, so I tried doing a >>>>>> git bisect on the radeon driver and it came down to: >>>>>> >>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>>> >>>>> So I don't think that's actually the cause of the problem. Or at least >>>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>>> get the lockups. >>>> >>>> Actually, git bisect does seem to have gotten it correct. Once I >>>> actually tested the revert of just that on top of Linus' tree (commit >>>> d895cb1af1), things seem to be working much better. I've rebooted a >>>> dozen times without a lockup. The most I've seen it take on a kernel >>>> with that commit included is 3 reboots, so that's definitely at least an >>>> improvement. >>> >>> I give up. GPU issues are not my thing. 2 reboots after I sent that it >>> gave me pretty rainbow static again. So it might have been an >>> improvement, but revert it is not a solution. >>> >>> Looking at there rest of the commits, the whole GPU rework might be >>> suspect, but I clearly have no clue. >> >> GPUs are tricky beasts :) > > Understatement ;). > >> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the >> problem anyway since it only affects 6xx/7xx and your card is handled >> by the evergreen code. I'll put together some patches to help narrow >> down the problem. > > Yeah, that's the biggest problem I have, not knowing which functions are > actually being executed for this card. It looks like a combination of > stuff in evergreen.c and ni.c, but I have no idea. > > Patches would be great. If nothing else, I'm really good at building > kernels and rebooting by now. Two possible fixes attached. The first attempts a full reset of all blocks if the MC (memory controller) is hung. That may work better than just resetting the MC. The second just disables MC reset. I'm not sure we can reliably tell if it's busy due to display requests hitting the MC periodically which would lead to needlessly resetting it possibly leading to failures like you are seeing. Alex -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch Type: text/x-patch Size: 991 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130228/d9eb9ea9/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch Type: text/x-patch Size: 1137 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130228/d9eb9ea9/attachment-0001.bin>
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #29 from Andreas Boll --- (In reply to comment #28) > Andreas Boll requested a branch of all my latest Mesa patches for people to > test it. It's here: > > git://people.freedesktop.org/~mareko/mesa master This branch fixes the garbled screen and improves the performance (~ 120 - 160%) here with tf2 and css on my rv770. Please test it! -- 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/20130228/0ef6fb47/attachment.html>
[PATCH 6/8] drm/i915: Enable/Disable PSR
Hi
So now I finally have the correct spec in hands!
2013/2/25 Rodrigo Vivi :
> Adding Enable and Disable PSR functionalities. This includes setting the
> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
> enabling PSR in the sink via DPCD register and finally enabling PSR on
> the host.
>
> This patch is heavily based on initial PSR code by Sateesh Kavuri and
> Kumar Shobhit but in a different implementation.
>
> Credits-by: Sateesh Kavuri
> Credits-by: Shobhit Kumar
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 40 +
> drivers/gpu/drm/i915/intel_dp.c | 183
> +++
> drivers/gpu/drm/i915/intel_drv.h | 3 +
> 3 files changed, 226 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b715ecd..1e31f23 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -844,6 +844,8 @@
> #define SNB_CPU_FENCE_ENABLE (1<<29)
> #define DPFC_CPU_FENCE_OFFSET 0x100104
>
> +/* Framebuffer compression for Haswell */
> +#define HSW_FBC_CONTROL0x43208
>
> /*
> * GPIO regs
> @@ -1580,6 +1582,44 @@
> #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
> #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
>
> +/* HSW eDP PSR registers */
> +#define EDP_PSR_CTL0x64800
> +#define EDP_PSR_ENABLE (1<<31)
> +#define EDP_PSR_LINK_DISABLE (0<<27)
> +#define EDP_PSR_LINK_STANDBY (1<<27)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25)
> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25)
> +#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
> +#define EDP_PSR_SKIP_AUX_EXIT(1<<12)
> +#define EDP_PSR_TP1_TP2_SEL (0<<11)
> +#define EDP_PSR_TP1_TP3_SEL (1<<11)
> +#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
> +#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
> +#define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
> +#define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
> +#define EDP_PSR_TP1_TIME_500us (0<<4)
> +#define EDP_PSR_TP1_TIME_100us (1<<4)
> +#define EDP_PSR_TP1_TIME_2500us (2<<4)
> +#define EDP_PSR_TP1_TIME_0us (3<<4)
> +#define EDP_PSR_IDLE_FRAME_SHIFT 0
> +
> +#define EDP_PSR_AUX_CTL0x64810
> +#define EDP_PSR_AUX_DATA1 0x64814
> +#define EDP_PSR_AUX_DATA2 0x64818
> +#define EDP_PSR_AUX_DATA3 0x6481c
> +#define EDP_PSR_AUX_DATA4 0x64820
> +#define EDP_PSR_AUX_DATA5 0x64824
> +
> +#define EDP_PSR_STATUS_CTL 0x64840
> +#define EDP_PSR_STATUS_STATE_MASK(7<<29)
> +
> +#define EDP_PSR_DEBUG_CTL 0x64860
> +#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> +#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
> +
> /* VGA port control */
> #define ADPA 0x61100
> #define PCH_ADPA0xe1100
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5cfa9f4..a420f0d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp
> *intel_dp)
> return intel_dig_port->base.base.dev;
> }
>
> +static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> +
> + return intel_dig_port->base.base.crtc;
> +}
> +
> static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
> {
> return enc_to_intel_dp(&intel_attached_encoder(connector)->base);
> @@ -1443,6 +1450,182 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
> (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED));
> }
>
> +static bool
> +intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
> +{
> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + return I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
> +}
> +
> +static void
> +intel_edp_psr_enable_src(struct intel_dp *intel_dp)
> +{
> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + uint32_t max_sleep_time = 0x1f;
> + uint32_t val = 0x0;
> +
> + if (dev_priv->vbt.psr_idle_frames)
> + val |= dev_priv->vbt.psr_idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> + else
> + val |= 1 << EDP_PSR_IDLE_FRAME_SHIFT;
> +
> + if (intel_dp->psr_dpcd[1] & DP_PSR_NO_
[PATCH] Fix build of swrast only without libdrm
On Thu, Feb 28, 2013 at 3:58 AM, Daniel Martin wrote: > > Signed-off-by: Daniel Martin > --- > There's a small logic error preventing mesa to be build with swrast only > and not having libdrm. > > configure.ac |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 5701f8a..aa1b38a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1089,7 +1089,7 @@ if test "x$enable_dri" = xyes; then > fi > > # if we are building any dri driver other than swrast or using the dri > state tracker ... > -if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast || test "x$enable_dri" > = xyes; then > +if test -n "$DRI_DIRS" -a x"$DRI_DIRS" != xswrast && test "x$enable_dri" > = xyes; then While modifying this line of code, please change '&& test' to -a. (mesa patches to go mesa-dev, not dri-devel)
[Intel-gfx] [PATCH 6/8] drm/i915: Enable/Disable PSR
Hi
2013/2/26 Ville Syrj?l? :
> On Mon, Feb 25, 2013 at 07:55:20PM -0300, Rodrigo Vivi wrote:
>> Adding Enable and Disable PSR functionalities. This includes setting the
>> PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
>> enabling PSR in the sink via DPCD register and finally enabling PSR on
>> the host.
>>
>> This patch is heavily based on initial PSR code by Sateesh Kavuri and
>> Kumar Shobhit but in a different implementation.
>>
>> Credits-by: Sateesh Kavuri
>> Credits-by: Shobhit Kumar
>> Signed-off-by: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 40 +
>> drivers/gpu/drm/i915/intel_dp.c | 183
>> +++
>> drivers/gpu/drm/i915/intel_drv.h | 3 +
>> 3 files changed, 226 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index b715ecd..1e31f23 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -844,6 +844,8 @@
>> #define SNB_CPU_FENCE_ENABLE (1<<29)
>> #define DPFC_CPU_FENCE_OFFSET0x100104
>>
>> +/* Framebuffer compression for Haswell */
>> +#define HSW_FBC_CONTROL 0x43208
>>
>> /*
>> * GPIO regs
>> @@ -1580,6 +1582,44 @@
>> #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
>> #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
>>
>> +/* HSW eDP PSR registers */
>> +#define EDP_PSR_CTL 0x64800
>> +#define EDP_PSR_ENABLE (1<<31)
>> +#define EDP_PSR_LINK_DISABLE (0<<27)
>> +#define EDP_PSR_LINK_STANDBY (1<<27)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES(0<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES(1<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES(2<<25)
>> +#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES(3<<25)
>> +#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
>> +#define EDP_PSR_SKIP_AUX_EXIT (1<<12)
>> +#define EDP_PSR_TP1_TP2_SEL(0<<11)
>> +#define EDP_PSR_TP1_TP3_SEL(1<<11)
>> +#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
>> +#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
>> +#define EDP_PSR_TP2_TP3_TIME_2500us(2<<8)
>> +#define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
>> +#define EDP_PSR_TP1_TIME_500us (0<<4)
>> +#define EDP_PSR_TP1_TIME_100us (1<<4)
>> +#define EDP_PSR_TP1_TIME_2500us(2<<4)
>> +#define EDP_PSR_TP1_TIME_0us (3<<4)
>> +#define EDP_PSR_IDLE_FRAME_SHIFT 0
>> +
>> +#define EDP_PSR_AUX_CTL 0x64810
>> +#define EDP_PSR_AUX_DATA10x64814
>> +#define EDP_PSR_AUX_DATA20x64818
>> +#define EDP_PSR_AUX_DATA30x6481c
>> +#define EDP_PSR_AUX_DATA40x64820
>> +#define EDP_PSR_AUX_DATA50x64824
>> +
>> +#define EDP_PSR_STATUS_CTL 0x64840
>> +#define EDP_PSR_STATUS_STATE_MASK (7<<29)
>> +
>> +#define EDP_PSR_DEBUG_CTL0x64860
>> +#define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
>> +#define EDP_PSR_DEBUG_MASK_HPD (1<<25)
>> +
>> /* VGA port control */
>> #define ADPA 0x61100
>> #define PCH_ADPA0xe1100
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 5cfa9f4..a420f0d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -83,6 +83,13 @@ static struct drm_device *intel_dp_to_dev(struct intel_dp
>> *intel_dp)
>> return intel_dig_port->base.base.dev;
>> }
>>
>> +static struct drm_crtc *intel_dp_to_crtc(struct intel_dp *intel_dp)
>> +{
>> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> +
>> + return intel_dig_port->base.base.crtc;
>> +}
>> +
>> static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
>> {
>> return enc_to_intel_dp(&intel_attached_encoder(connector)->base);
>> @@ -1443,6 +1450,182 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
>> (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED));
>> }
>>
>> +static bool
>> +intel_edp_is_psr_enabled(struct intel_dp* intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + return I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
>> +}
>> +
>> +static void
>> +intel_edp_psr_enable_src(struct intel_dp *intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + uint32_t max_sleep_time = 0x1f;
>> + uint32_t val = 0x0;
>> +
>> + if (dev_priv->vbt.psr_idle_frames)
>> + val |= dev_priv->vbt.psr_idle_frames << EDP
[Intel-gfx] [git pull] drm merge for 3.9-rc1
Hi
2013/2/28 Sedat Dilek :
> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>>> Hi
>>>
>>> 2013/2/28 Chris Wilson :
On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
> wrote:
> > Hi,
> >
> > I am seeing this also on Linux-Next.
> >
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> > (has irq: 1)!
> >
> > This seems to be hard reproducible...
> > Laptop-LCD... Sandybridge Mobile-GT2.
> >
> > Is there a way to force the error?
> >
> > Possible patch see [1].
> >
> > - Sedat -
> >
> > [1] https://patchwork.kernel.org/patch/2192721/
That was:
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ }
You applied
+ if (!done) {
+ status = I915_READ_NOTRACE(ch_ctl);
+ DRM_ERROR("dp aux hw did not signal timeout (has irq:
%i), status=%08x!\n",
+ has_aux_irq, status);
+ {
>>>
>>> In addition to this, after the problem happens can you please dump the
>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>>> I915_READ(0xC4008).
>>>
>>
>> Do I need a specific version of intel-gpu-tools?
>> Ubuntu/precise has v1.2 in its archives - sufficient?
>> Note: The error was twice after dozenz of Linux-Next kernel builds.
>>
>> - Sedat -
>>
>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>>
>
> Installed intel-gpu-tools.
>
> # intel_reg_read
> Usage: intel_reg_read [-f | addr]
> -f : read back full range of registers.
> WARNING! This could be danger to hang the machine!
> addr : in 0x format
>
> # intel_reg_read 0x44008
> Couldn't map MMIO region: Resource temporarily unavailable
>
> [ 368.281707] intel_reg_read:3657 conflicting memory types
> f000-f040 uncached-minus<->write-combining
> [ 381.521912] intel_reg_read:3658 conflicting memory types
> f000-f040 uncached-minus<->write-combining
> [ 401.136291] intel_reg_read:3659 conflicting memory types
> f000-f040 uncached-minus<->write-combining
>
> Wrong i-g-t version? Missing enabled kernel-config option? Boot with
> i915 debug enabled?
Just build the version from git and it should work
(http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
>
> - Sedat -
>
>>> If you conclude that the value of 0x44008 is 0x0 while the value of
>>> 0xC4008 is not, then this patch should help:
>>> https://patchwork.kernel.org/patch/2177841/
>>>
That second '{' is the source of the compile error.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>>
>>>
>>> --
>>> Paulo Zanoni
--
Paulo Zanoni
[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 Lucas Kannebley Tavares changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #32 from Lucas Kannebley Tavares --- After some further investigation, we found that despite the fact that we were disabling MSIs, the adapter was still using it. After we provided a 32-bit address to it, we got it to work properly. The solution to this will have to be done not in software, so I'm closing the bug. Thanks for all the help, guys -- 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/20130228/0cf1088d/attachment-0001.html>
[Intel-gfx] [PATCH 7/8] drm/i915: Added debugfs support for PSR Status
Hi
2013/2/25 Rodrigo Vivi :
> Adding support for PSR Status, PSR entry counter and performance counters.
> Heavily based on initial work from Shobhit.
>
> Credits-by: Shobhit Kumar
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 92
> +
> drivers/gpu/drm/i915/i915_reg.h | 24 ++
> 2 files changed, 116 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7c65ab8..01021f6 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1680,6 +1680,97 @@ static int i915_dpio_info(struct seq_file *m, void
> *data)
> return 0;
> }
>
> +
> +static int i915_edp_psr_status(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + unsigned int count;
> + u32 psrctl, psrstat, psrperf;
> +
> + psrctl = I915_READ(EDP_PSR_CTL);
> + seq_printf(m, "PSR Enabled: %s\n",
> + yesno(psrctl & EDP_PSR_ENABLE));
> +
> + psrstat = I915_READ(EDP_PSR_STATUS_CTL);
> +
> + seq_printf(m, "PSR Current State: ");
> + switch (psrstat & EDP_PSR_STATUS_STATE_MASK) {
> + case EDP_PSR_STATUS_STATE_IDLE:
> + seq_printf(m, "Reset state\n");
> + break;
> + case EDP_PSR_STATUS_STATE_SRDONACK:
> + seq_printf(m, "Wait for TG/Stream to send on frame of data
> after SRD conditions are met\n");
> + break;
> + case EDP_PSR_STATUS_STATE_SRDENT:
> + seq_printf(m, "SRD entry\n");
> + break;
> + case EDP_PSR_STATUS_STATE_BUFOFF:
> + seq_printf(m, "Wait for buffer turn off\n");
> + break;
> + case EDP_PSR_STATUS_STATE_BUFON:
> + seq_printf(m, "Wait for buffer turn on\n");
> + break;
> + case EDP_PSR_STATUS_STATE_AUXACK:
> + seq_printf(m, "Wait for AUX to acknowledge on SRD
> exit\n");
> + break;
> + case EDP_PSR_STATUS_STATE_SRDOFFACK:
> + seq_printf(m, "Wait for TG/Stream to acknowledge the
> SRD VDM exit\n");
> + break;
> + default:
> + seq_printf(m, "Unknown\n");
> + break;
> + }
> +
> + seq_printf(m, "Link Status: ");
> + switch (psrstat & EDP_PSR_STATUS_LINK_MASK) {
> + case EDP_PSR_STATUS_LINK_FULL_OFF:
> + seq_printf(m, "Link is fully off\n");
> + break;
> + case EDP_PSR_STATUS_LINK_FULL_ON:
> + seq_printf(m, "Link is fully on\n");
> + break;
> + case EDP_PSR_STATUS_LINK_STANDBY:
> + seq_printf(m, "Link is in standby\n");
> + break;
> + default:
> + seq_printf(m, "Unknown\n");
> + break;
> + }
> +
> + seq_printf(m, "PSR Entry Count: %u\n",
> + psrstat >> EDP_PSR_STATUS_COUNT_SHIFT &
> + EDP_PSR_STATUS_COUNT_MASK);
> +
> + seq_printf(m, "Max Sleep Timer Counter: %u\n",
> + psrstat >> EDP_PSR_STATUS_MAX_SLEEP_TIMER_SHIFT &
> + EDP_PSR_STATUS_MAX_SLEEP_TIMER_MASK);
> +
> + seq_printf(m, "Had AUX error: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_AUX_ERROR));
> +
> + seq_printf(m, "Sending AUX: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_AUX_SENDING));
> +
> + seq_printf(m, "Sending Idle: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_SENDING_IDLE));
> +
> + seq_printf(m, "Sending TP2 TP3: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_SENDING_TP2_TP3));
> +
> + seq_printf(m, "Sending TP1: %s\n",
> + yesno(psrstat & EDP_PSR_STATUS_SENDING_TP1));
> +
> + seq_printf(m, "Idle Count: %u\n",
> + psrstat & EDP_PSR_STATUS_IDLE_MASK);
> +
> + psrperf = (I915_READ(EDP_PSR_PERF_CNT)) & EDP_PSR_PERF_CNT_MASK;
> + seq_printf(m, "Performance Counter: %u\n", psrperf);
> +
> + return 0;
> +}
> +
> static ssize_t
> i915_wedged_read(struct file *filp,
> char __user *ubuf,
> @@ -2249,6 +2340,7 @@ static struct drm_info_list i915_debugfs_list[] = {
> {"i915_swizzle_info", i915_swizzle_info, 0},
> {"i915_ppgtt_info", i915_ppgtt_info, 0},
> {"i915_dpio", i915_dpio_info, 0},
> + {"i915_edp_psr_status", i915_edp_psr_status, 0},
> };
> #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1e31f23..1f7e666 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1615,6 +1615,30 @@
>
> #define EDP_PSR_STATUS_CTL 0x648
[Intel-gfx] [PATCH 8/8] drm/i915: Hook PSR functionality
Hi
2013/2/25 Rodrigo Vivi :
> PSR must be enabled after transcoder and port are running.
> And it is only available for HSW.
>
> v2: move enable/disable to intel_ddi
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 816c45c..bbfdcfd 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1321,6 +1321,7 @@ static void intel_enable_ddi(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> ironlake_edp_backlight_on(intel_dp);
> + intel_edp_enable_psr(intel_dp);
> }
>
> if (intel_crtc->eld_vld) {
> @@ -1345,6 +1346,7 @@ static void intel_disable_ddi(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>
> ironlake_edp_backlight_off(intel_dp);
> + intel_edp_disable_psr(intel_dp);
The spec suggests PSR should be disabled even before backlight (it
also suggests audio should be disabled before backlight, and I notice
this seems to be wrong in our code).
> }
>
> tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> --
> 1.8.1.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
[Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3
Hi 2013/2/25 Rodrigo Vivi : > PSR is an eDP feature that allows power saving even with static image at eDP > screen. > > v3: Accepted many suggestions that I received at v2 review, fixing, cleaning > and improving the code. > > v2: Main differences in this v2: > - Created vbt struct to get i915 dev_priv more organized and to avoid adding > more stuff into it. > - migrated hsw macros to use transcoder instead of pipes than I could address > eDP > - remove patch that was only adding edp psr registers and added them on demand > > v1: > Shobit Kumar has implemented this patch series some time ago, but had no eDP > panel with PSR capability to test them. > > I could test and verify that this series fully identify PSR capability and > enables it at HSW. > I also verified that it saves from 0.5-1W but only when in blank screen. It > seems it is not really entering in sleeping mode with static image at eDP > screen yet. What do you mean with "blank screen"? It seems we disable PSR before blanking the screen, so the 0.5-1W saving could be from the backlight. Did you try masking more bits on the SRD_DEBUG register to see if it enters PSR more easily? The first test I'd try would be to set 1 to all those mask regs and see what happens (maybe we'll enter PSR and never ever leave it again?). > > Please accept this series as the first part of PSR enabling while we continue > working to improve its functionality. > > Rodrigo Vivi (5): > drm/i915: Organize VBT stuff inside drm_i915_private > drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe > drm/i915: Enable/Disable PSR > drm/i915: Added debugfs support for PSR Status > drm/i915: Hook PSR functionality > > Shobhit Kumar (3): > drm/i915: Added SDP and VSC structures for handling PSR for eDP > drm/i915: Read the EDP DPCD and PSR Capability > drm/i915: VBT Parsing for the PSR Feature Block for HSW > > drivers/gpu/drm/i915/i915_debugfs.c | 92 > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 63 ++- > drivers/gpu/drm/i915/i915_reg.h | 82 -- > drivers/gpu/drm/i915/intel_bios.c| 126 + > drivers/gpu/drm/i915/intel_bios.h| 20 +++- > drivers/gpu/drm/i915/intel_crt.c | 4 +- > drivers/gpu/drm/i915/intel_ddi.c | 2 + > drivers/gpu/drm/i915/intel_display.c | 16 +-- > drivers/gpu/drm/i915/intel_dp.c | 208 > ++- > drivers/gpu/drm/i915/intel_drv.h | 4 + > drivers/gpu/drm/i915/intel_hdmi.c| 13 ++- > drivers/gpu/drm/i915/intel_lvds.c| 20 ++-- > drivers/gpu/drm/i915/intel_sdvo.c| 6 +- > drivers/gpu/drm/i915/intel_tv.c | 8 +- > include/drm/drm_dp_helper.h | 22 > 16 files changed, 569 insertions(+), 125 deletions(-) > > -- > 1.8.1.2 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni
[Intel-gfx] [PATCH 0/8] Enable eDP PSR functionality at HSW - v3
On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote: > Hi > > 2013/2/25 Rodrigo Vivi : > > PSR is an eDP feature that allows power saving even with static image at > > eDP screen. > > > > v3: Accepted many suggestions that I received at v2 review, fixing, > > cleaning and improving the code. > > > > v2: Main differences in this v2: > > - Created vbt struct to get i915 dev_priv more organized and to avoid > > adding more stuff into it. > > - migrated hsw macros to use transcoder instead of pipes than I could > > address eDP > > - remove patch that was only adding edp psr registers and added them on > > demand > > > > v1: > > Shobit Kumar has implemented this patch series some time ago, but had no > > eDP panel with PSR capability to test them. > > > > I could test and verify that this series fully identify PSR capability and > > enables it at HSW. > > I also verified that it saves from 0.5-1W but only when in blank screen. It > > seems it is not really entering in sleeping mode with static image at eDP > > screen yet. > > What do you mean with "blank screen"? It seems we disable PSR before > blanking the screen, so the 0.5-1W saving could be from the backlight. > Did you try masking more bits on the SRD_DEBUG register to see if it > enters PSR more easily? The first test I'd try would be to set 1 to > all those mask regs and see what happens (maybe we'll enter PSR and > never ever leave it again?). One thing I'm wondering if we can even enable PSR w/o implementing the FBC tracking bits. I mean what happens if someone renders to the front buffer while PSR is active? -- Ville Syrj?l? Intel OTC
[Bug 43751] [TTM] Out of kernel memory
https://bugzilla.kernel.org/show_bug.cgi?id=43751 --- Comment #12 from Peter Barth 2013-02-28 19:08:52 --- Seems to be fixed for me with 3.8.0. No kernel-crash/reboot for 3 days, yay! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 58042] [bisected] Garbled UI in Team Fortress 2 and Counter-Strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=58042 --- Comment #30 from Benjamin Bellec --- (In reply to comment #28) > Andreas Boll requested a branch of all my latest Mesa patches for people to > test it. It's here: > > git://people.freedesktop.org/~mareko/mesa master Awesome! With my RV770 all is rendering correctly now in CS:S! Moreover, I'm always at 60FPS (vsync certainly enabled) with all graphical options enabled (even MSAA 2x) (1680*1050)! Note that I'm using 3.7.9-201.fc18.x86_64. -- 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/20130228/0062095b/attachment.html>
radeon_gem_object_create:69 alloc size 139Mb bigger than 128Mb limit (RS780)
Running the latest Linus git kernel I occasionally see the following warning: radeon_gem_object_create:69 alloc size 139Mb bigger than 128Mb limit >From dmesg: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D). [drm] register mmio base: 0xFBEE [drm] register mmio size: 65536 ATOM BIOS: 113 radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M used) radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 32bits DDR [TTM] Zone kernel: Available graphics memory: 4083398 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RS780 Microcode [drm] PCIE GART of 512M enabled (table at 0xC004). radeon :01:05.0: WB enabled radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x8802163d1c00 radeon :01:05.0: fence driver on ring 3 use gpu addr 0xac0c and cpu addr 0x8802163d1c0c radeon :01:05.0: setting latency timer to 64 [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D-1 [drm] HPD3 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_KLDSCP_LVTMA [drm] radeon: power management initialized [drm] fb mappable at 0xF0142000 [drm] vram apper at 0xF000 [drm] size 7299072 [drm] fb depth is 24 [drm]pitch is 6912 -- Markus
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #22 from LRN --- Still getting this. Linux kernel 3.8.0 (9e2d59ad580d590134285f361a0e80f0e98c0207) xf86-video-ati 343b01c9bf35b125cd0c3df8db7c01a5fb227bda -- 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/20130228/b5269ccf/attachment.html>
[PATCH] libdrm/exynos: add test application for 2d gpu.
Just curious, but the 2d blitter have it's own sort of
command-processor, ie. can you feed it a list of different blits in
one batch and then it will process them one after another?
If so, that would make the separate ioctls for SET_CMDLIST on each
blit operation, and then EXEC a bit awkward, and give you a huge # of
ioctls for something like EXA/x11 trying to use the blitter.
Is there some documentation about G2D somewhere that I could read?
Just curious, because I have a chromebook on the way and was wondering
about trying to give x11 a bit help by means of G2D..
BR,
-R
On Mon, Feb 18, 2013 at 7:51 AM, Inki Dae wrote:
> This patch adds library and test application for g2d gpu(fimg2d).
>
> The fimg2d hardware is a 2D graphics accelerator(G2D) that
> supports Bit Block Transfer(BitBLT).
>
> The library includes the following primitive drawing operations:
> .solid fill - This operation fills the given buffer with
> the given color data.
> .copy - This operation copies contents in source buffer to
> destination buffer.
> .copy_with_scale - This operation copies contents in source buffer
> to destination buffer scaling up or down properly.
> .blend - This operation blends contents in source buffer with
> the ones in destination buffer.
>
> And the above operations uses gem handle or user space address
> allocated by malloc() as source or destination buffer.
>
> And the test application includes just simple primitive drawing
> tests with the above library.
> And the guide to test is as the following,
> "#exynos_fimg2d_test -s connector_id at crtc_id:mode"
>
> With this above simple command, four primitive drawing operations
> would be called step by step and also rendered on the output device
> to the given connector and crtc id.
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> configure.ac |1 +
> exynos/Makefile.am|2 +-
> exynos/exynos_drm.h | 52 +++
> exynos/exynos_fimg2d.c| 630 +
> exynos/fimg2d.h | 325 +
> exynos/fimg2d_reg.h | 114 ++
> tests/Makefile.am |4 +
> tests/exynos/Makefile.am | 19 +
> tests/exynos/exynos_fimg2d_test.c | 695
> +
> 9 files changed, 1841 insertions(+), 1 deletions(-)
> create mode 100644 exynos/exynos_fimg2d.c
> create mode 100644 exynos/fimg2d.h
> create mode 100644 exynos/fimg2d_reg.h
> create mode 100644 tests/exynos/Makefile.am
> create mode 100644 tests/exynos/exynos_fimg2d_test.c
>
> diff --git a/configure.ac b/configure.ac
> index e2e3466..2896f91 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -364,6 +364,7 @@ AC_CONFIG_FILES([
> tests/kmstest/Makefile
> tests/radeon/Makefile
> tests/vbltest/Makefile
> + tests/exynos/Makefile
> include/Makefile
> include/drm/Makefile
> man/Makefile
> diff --git a/exynos/Makefile.am b/exynos/Makefile.am
> index e782d34..539aea0 100644
> --- a/exynos/Makefile.am
> +++ b/exynos/Makefile.am
> @@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
> libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
>
> -libdrm_exynos_la_SOURCES = exynos_drm.c
> +libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
>
> libdrm_exynoscommonincludedir = ${includedir}/exynos
> libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
> diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
> index aa97b22..c3c6579 100644
> --- a/exynos/exynos_drm.h
> +++ b/exynos/exynos_drm.h
> @@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
> EXYNOS_BO_WC
> };
>
> +struct drm_exynos_g2d_get_ver {
> + __u32 major;
> + __u32 minor;
> +};
> +
> +struct drm_exynos_g2d_cmd {
> + __u32 offset;
> + __u32 data;
> +};
> +
> +enum drm_exynos_g2d_buf_type {
> + G2D_BUF_USERPTR = 1 << 31,
> +};
> +
> +enum drm_exynos_g2d_event_type {
> + G2D_EVENT_NOT,
> + G2D_EVENT_NONSTOP,
> + G2D_EVENT_STOP, /* not yet */
> +};
> +
> +struct drm_exynos_g2d_userptr {
> + unsigned long userptr;
> + unsigned long size;
> +};
> +
> +struct drm_exynos_g2d_set_cmdlist {
> + __u64 cmd;
> + __u64 cmd_buf;
> + __u32 cmd_nr;
> + __u32 cmd_buf_nr;
> +
> + /* for g2d event */
> + __u64 event_type;
> + __u64 user_data;
> +};
> +
> +struct drm_exynos_g2d_exec {
> + __u64 async;
> +};
> +
> #define DRM_EXYNOS_GEM_CREATE 0x00
> #define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
> #define D
[git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson
wrote:
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>> wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
>
> That second '{' is the source of the compile error.
Schei**e, OK I try with a v2.
A hint how to force the error?
- Sedat -
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Chris Wilson :
>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>>> wrote:
>>> > Hi,
>>> >
>>> > I am seeing this also on Linux-Next.
>>> >
>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> >
>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>>> > (has irq: 1)!
>>> >
>>> > This seems to be hard reproducible...
>>> > Laptop-LCD... Sandybridge Mobile-GT2.
>>> >
>>> > Is there a way to force the error?
>>> >
>>> > Possible patch see [1].
>>> >
>>> > - Sedat -
>>> >
>>> > [1] https://patchwork.kernel.org/patch/2192721/
>>
>> That was:
>>
>> + if (!done) {
>> + status = I915_READ_NOTRACE(ch_ctl);
>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>> %i), status=%08x!\n",
>> + has_aux_irq, status);
>> + }
>>
>> You applied
>>
>> + if (!done) {
>> + status = I915_READ_NOTRACE(ch_ctl);
>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>> %i), status=%08x!\n",
>> + has_aux_irq, status);
>> + {
>
> In addition to this, after the problem happens can you please dump the
> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
> by running intel-reg-read (from intel-gpu-tools) or by changing the
> DRM_ERROR above to also print the result of I915_READ(0x44008) and
> I915_READ(0xC4008).
>
Do I need a specific version of intel-gpu-tools?
Ubuntu/precise has v1.2 in its archives - sufficient?
Note: The error was twice after dozenz of Linux-Next kernel builds.
- Sedat -
[1] http://packages.ubuntu.com/precise/intel-gpu-tools
> If you conclude that the value of 0x44008 is 0x0 while the value of
> 0xC4008 is not, then this patch should help:
> https://patchwork.kernel.org/patch/2177841/
>
>>
>> That second '{' is the source of the compile error.
>> -Chris
>>
>> --
>> Chris Wilson, Intel Open Source Technology Centre
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>> Hi
>>
>> 2013/2/28 Chris Wilson :
>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
wrote:
> Hi,
>
> I am seeing this also on Linux-Next.
>
> /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
> [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> (has irq: 1)!
> /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
> [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> (has irq: 1)!
>
> /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
> [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
> (has irq: 1)!
>
> This seems to be hard reproducible...
> Laptop-LCD... Sandybridge Mobile-GT2.
>
> Is there a way to force the error?
>
> Possible patch see [1].
>
> - Sedat -
>
> [1] https://patchwork.kernel.org/patch/2192721/
>>>
>>> That was:
>>>
>>> + if (!done) {
>>> + status = I915_READ_NOTRACE(ch_ctl);
>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>> %i), status=%08x!\n",
>>> + has_aux_irq, status);
>>> + }
>>>
>>> You applied
>>>
>>> + if (!done) {
>>> + status = I915_READ_NOTRACE(ch_ctl);
>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
>>> %i), status=%08x!\n",
>>> + has_aux_irq, status);
>>> + {
>>
>> In addition to this, after the problem happens can you please dump the
>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
>> by running intel-reg-read (from intel-gpu-tools) or by changing the
>> DRM_ERROR above to also print the result of I915_READ(0x44008) and
>> I915_READ(0xC4008).
>>
>
> Do I need a specific version of intel-gpu-tools?
> Ubuntu/precise has v1.2 in its archives - sufficient?
> Note: The error was twice after dozenz of Linux-Next kernel builds.
>
> - Sedat -
>
> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>
Installed intel-gpu-tools.
# intel_reg_read
Usage: intel_reg_read [-f | addr]
-f : read back full range of registers.
WARNING! This could be danger to hang the machine!
addr : in 0x format
# intel_reg_read 0x44008
Couldn't map MMIO region: Resource temporarily unavailable
[ 368.281707] intel_reg_read:3657 conflicting memory types
f000-f040 uncached-minus<->write-combining
[ 381.521912] intel_reg_read:3658 conflicting memory types
f000-f040 uncached-minus<->write-combining
[ 401.136291] intel_reg_read:3659 conflicting memory types
f000-f040 uncached-minus<->write-combining
Wrong i-g-t version? Missing enabled kernel-config option? Boot with
i915 debug enabled?
- Sedat -
>> If you conclude that the value of 0x44008 is 0x0 while the value of
>> 0xC4008 is not, then this patch should help:
>> https://patchwork.kernel.org/patch/2177841/
>>
>>>
>>> That second '{' is the source of the compile error.
>>> -Chris
>>>
>>> --
>>> Chris Wilson, Intel Open Source Technology Centre
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>
>>
>> --
>> Paulo Zanoni
[Intel-gfx] [git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni wrote:
> Hi
>
> 2013/2/28 Sedat Dilek :
>> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek
>> wrote:
>>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
Hi
2013/2/28 Chris Wilson :
> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek
>> wrote:
>> > Hi,
>> >
>> > I am seeing this also on Linux-Next.
>> >
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280]
>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
>> > (has irq: 1)!
>> >
>> > This seems to be hard reproducible...
>> > Laptop-LCD... Sandybridge Mobile-GT2.
>> >
>> > Is there a way to force the error?
>> >
>> > Possible patch see [1].
>> >
>> > - Sedat -
>> >
>> > [1] https://patchwork.kernel.org/patch/2192721/
>
> That was:
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + }
>
> You applied
>
> + if (!done) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i), status=%08x!\n",
> + has_aux_irq, status);
> + {
In addition to this, after the problem happens can you please dump the
registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either
by running intel-reg-read (from intel-gpu-tools) or by changing the
DRM_ERROR above to also print the result of I915_READ(0x44008) and
I915_READ(0xC4008).
>>>
>>> Do I need a specific version of intel-gpu-tools?
>>> Ubuntu/precise has v1.2 in its archives - sufficient?
>>> Note: The error was twice after dozenz of Linux-Next kernel builds.
>>>
>>> - Sedat -
>>>
>>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools
>>>
>>
>> Installed intel-gpu-tools.
>>
>> # intel_reg_read
>> Usage: intel_reg_read [-f | addr]
>> -f : read back full range of registers.
>> WARNING! This could be danger to hang the machine!
>> addr : in 0x format
>>
>> # intel_reg_read 0x44008
>> Couldn't map MMIO region: Resource temporarily unavailable
>>
>> [ 368.281707] intel_reg_read:3657 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>> [ 381.521912] intel_reg_read:3658 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>> [ 401.136291] intel_reg_read:3659 conflicting memory types
>> f000-f040 uncached-minus<->write-combining
>>
>> Wrong i-g-t version? Missing enabled kernel-config option? Boot with
>> i915 debug enabled?
>
> Just build the version from git and it should work
> (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/).
>
NO.
$ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
intel-gpu-tools-git
$ cd intel-gpu-tools-git/
$ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x
$ sudo ./tools/intel_reg_read 0x44008
0x44008 : 0x0
$ sudo ./tools/intel_reg_read 0xC4008
0xC4008 : 0x0
$ sudo ./tools/intel_reg_dumper > /tmp/intel_reg_dumper.txt <--- see attachment
Does this help you?
- Sedat -
>>
>> - Sedat -
>>
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
>
> That second '{' is the source of the compile error.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
>
>
>
> --
> Paulo Zanoni
-- next part --
PGETBL_CTL: 0x
GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x
CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
DISPLAY_PORT_PLL_BIOS_0: 0x
DISPLAY_PORT_PLL_BIOS_1: 0x
DISPLAY_PORT_PLL_BIOS_2: 0x
FDI_PLL_FREQ_
[RFD] Proposal for merging Android sync driver in staging
On 02/27/2013 06:32 PM, Greg KH wrote: > On Wed, Feb 27, 2013 at 06:14:24PM -0800, John Stultz wrote: >> I'd like to get a discussion going about submitting the Android sync >> driver to staging. >> >> I know there is currently some very similar work going on with the >> dmabuf-fences, and rather then both approaches being worked out >> individually on their own, I suspect there could be better >> collaboration around this effort. >> >> So my proposal is that we merge the Android sync driver into staging. >> >> In my mind, this has the following benefits: >> 1) It allows other drivers that depend on the sync interface to also >> be submitted to staging, rather then forcing those drivers to be >> hidden away in various out of tree git repos, location unknown. >> >> 2) It would provide a baseline view to the upstream community of the >> interface Android is using, providing a real-world, active use case >> of the functionality. >> >> Once the sync driver is in staging, if the dmabuf-fences work is >> fully sufficient to replace the Android sync driver, we should be >> able to whittle down the sync driver until its just a interface shim >> (and at which point efforts can be made to convert Android userland >> over to dmabuf-fences). > Sounds like a good plan to me. > >> I've gone through the Android tree and reworked the sync driver to >> live in staging, while still preserving the full patch >> history/authorship. You can checkout the reworked patch queue here: >> >> http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/sync-staging > I can't really look at a git tree at the moment, but will always be glad > to review patches. Feel free to send them on and we can look at them > then :) Ok, since I preserved the patch history, its currently 30 patches, and I didn't want to flood everyone's inboxes with patches (Greg: I know you'd never do such a thing! :) before making sure there weren't any objections to the idea in concept. I'll send out the stack later today. thanks -john
[git pull] drm merge for 3.9-rc1
On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer wrote: > On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher > wrote: >> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer wrote: >>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher >>> wrote: ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>> >>> So I don't think that's actually the cause of the problem. Or at least >>> not that alone. I reverted it on top of Linus' latest tree and I still >>> get the lockups. >> >> Actually, git bisect does seem to have gotten it correct. Once I >> actually tested the revert of just that on top of Linus' tree (commit >> d895cb1af1), things seem to be working much better. I've rebooted a >> dozen times without a lockup. The most I've seen it take on a kernel >> with that commit included is 3 reboots, so that's definitely at least an >> improvement. > > I give up. GPU issues are not my thing. 2 reboots after I sent that it > gave me pretty rainbow static again. So it might have been an > improvement, but revert it is not a solution. > > Looking at there rest of the commits, the whole GPU rework might be > suspect, but I clearly have no clue. GPUs are tricky beasts :) >>> >>> Understatement ;). >>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the problem anyway since it only affects 6xx/7xx and your card is handled by the evergreen code. I'll put together some patches to help narrow down the problem. >>> >>> Yeah, that's the biggest problem I have, not knowing which functions are >>> actually being executed for this card. It looks like a combination of >>> stuff in evergreen.c and ni.c, but I have no idea. >>> >>> Patches would be great. If nothing else, I'm really good at building >>> kernels and rebooting by now. >> >> Two possible fixes attached. The first attempts a full reset of all >> blocks if the MC (memory controller) is hung. That may work better >> than just resetting the MC. The second just disables MC reset. I'm >> not sure we can reliably tell if it's busy due to display requests >> hitting the MC periodically which would lead to needlessly resetting >> it possibly leading to failures like you are seeing. > > OK. I'll test them individually. It will probably take a bit because > I'll want to do numerous reboots if things seem "fixed" with one or the > other. > > I'll let you know how things go. I applied each individually on top of Linus' tree as of this morning (commit 2a7d2b96d5) built, installed, and tested. 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in two reboots. 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone 21 reboots without a hang/rainbow static. You'll understand if I'm hesitant to declare success, but resetting the MC does indeed appear to be the issue. I'll keep rebooting for a while to make sure. josh
[PATCH v9 2/2] video: drm: exynos: Add pinctrl support to fimd
On 02/28/2013 05:12 AM, Vikas Sajjan wrote:
> Adds support for pinctrl to drm fimd
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index e323cf9..21ada8d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -879,6 +880,7 @@ static int fimd_probe(struct platform_device *pdev)
> struct exynos_drm_fimd_pdata *pdata;
> struct exynos_drm_panel_info *panel;
> struct resource *res;
> + struct pinctrl *pctrl;
> int win;
> int ret = -EINVAL;
>
> @@ -897,6 +899,13 @@ static int fimd_probe(struct platform_device *pdev)
> DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
> return ret;
> }
> + pctrl = devm_pinctrl_get_select_default(dev);
> + if (IS_ERR_OR_NULL(pctrl)) {
> + DRM_ERROR("failed: devm_pinctrl_get_select_default():"
> + "%d\n", PTR_RET(pctrl));
> + return PTR_ERR(pctrl);
In situations like this I really side attempts to remove IS_ERR_OR_NULL()
macro from the kernel completely ([1], [2]). What is the value returned
from
fimd_probe() when devm_pinctrl_get_select_default() returns NULL ?
What header file have you added to use struct pinctrl in this driver ?
Is this data structure fully declared there ? Are drivers supposed to
dereference struct pinctrl at all ?
I believe original intention was to have the pinctrl handle as an opaque
cookie, and as long as it is used with the pinctrl API only and tested
for errors with *IS_ERR()*, everything should be fine. The pinctrl API
should handle any NULL pointer as it returned it to a driver in the first
place.
Please just use IS_ERR(), let's stop this IS_ERR_OR_NULL() insanity.
> + }
> +
> } else {
> pdata = pdev->dev.platform_data;
> if (!pdata) {
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html
[2] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg78030.html
[PATCH v9 2/2] video: drm: exynos: Add pinctrl support to fimd
On Thu, Feb 28, 2013 at 11:03:57PM +0100, Sylwester Nawrocki wrote: > Please just use IS_ERR(), let's stop this IS_ERR_OR_NULL() insanity. Yes, indeed. On that topic (and off-topic for this thread, sorry) I've committed a set of patches to remove most users of IS_ERR_OR_NULL() from arch/arm. These are the last remaining ones there - and I don't want to see any more appearing: arch/arm/plat-samsung/clock.c: if (IS_ERR_OR_NULL(clk)) arch/arm/plat-samsung/clock.c: if (!IS_ERR_OR_NULL(clk) && clk->ops && clk->ops->round_rate) arch/arm/plat-samsung/clock.c: if (IS_ERR_OR_NULL(clk)) arch/arm/plat-samsung/clock.c: if (IS_ERR_OR_NULL(clk) || IS_ERR_OR_NULL(parent)) arch/arm/mach-imx/devices/platform-ipu-core.c: if (IS_ERR_OR_NULL(imx_ipu_coredev)) arch/arm/mach-imx/devices/platform-ipu-core.c: if (IS_ERR_OR_NULL(imx_ipu_coredev)) arch/arm/kernel/smp_twd.c: * We use IS_ERR_OR_NULL() here, because if the clock stubs arch/arm/kernel/smp_twd.c: if (!IS_ERR_OR_NULL(twd_clk)) They currently all legal uses of it - though I'm sure that the samsung clock uses can be reduced to just IS_ERR(). The IMX use looks "valid" in that imx_ipu_coredev really can be an error pointer (on failure) or NULL if the platform device hasn't yet been created. The TWD one is explained in the comments in the code (if people had to write explanations for using IS_ERR_OR_NULL(), we'd probably have it used correctly!)
[PATCH] drm/edid: kernel-doc minimal cleanup
Some basic cleanups for kernel-doc errors or missing documentation parameters. Warnings generated by ./scripts/kernel-doc drivers/gpu/drm/drm_edid.c >Kerr Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'adapter' Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'buf' Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'block' Warning(drivers/gpu/drm/drm_edid.c:997): No description found for parameter 'len' Warning(drivers/gpu/drm/drm_edid.c:1138): No description found for parameter 'adapter' Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 'connector' Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 'edid' Warning(drivers/gpu/drm/drm_edid.c:1467): No description found for parameter 'revision' Warning(drivers/gpu/drm/drm_edid.c:1467): Excess function parameter 'timing_level' description in 'drm_mode_std' Warning(drivers/gpu/drm/drm_edid.c:2010): No description found for parameter 'connector' Warning(drivers/gpu/drm/drm_edid.c:2072): No description found for parameter 'connector' Warning(drivers/gpu/drm/drm_edid.c:2237): No description found for parameter 'edid' Warning(drivers/gpu/drm/drm_edid.c:2616): No description found for parameter 'edid' Warning(drivers/gpu/drm/drm_edid.c:2658): No description found for parameter 'edid' Cc: David Airlie Cc: Dave Airlie Cc: Adam Jackson Cc: Rodrigo Vivi Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nishanth Menon --- It does seem the drm_edid.c could do with some amount of documentation cleanup, but I have stayed with the bare minimum. the above error is based off: master de1a226 Merge tag 'writeback-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linux from: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git defconfig used: omap2plus_defconfig Disclaimer: I am no drm expert, and I tried to use my best judgement about what the meaning of the parameters might be, hope it helps. drivers/gpu/drm/drm_edid.c | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index c194f4e..f604c5f 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -982,14 +982,14 @@ EXPORT_SYMBOL(drm_edid_is_valid); #define DDC_SEGMENT_ADDR 0x30 /** - * Get EDID information via I2C. - * - * \param adapter : i2c device adaptor - * \param buf : EDID data buffer to be filled - * \param len : EDID data buffer length - * \return 0 on success or -1 on failure. + * drm_do_probe_ddc_edid() - Get EDID information via I2C. + * @adapter: i2c device adaptor + * @buf: EDID data buffer to be filled + * @block: EDID block to get + * @len: EDID data buffer length * * Try to fetch EDID information by calling i2c driver function. + * Return 0 on success or -1 on failure. */ static int drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, @@ -1128,10 +1128,10 @@ out: } /** - * Probe DDC presence. + * drm_probe_ddc() - Probe DDC presence + * @adapter: i2c device adaptor * - * \param adapter : i2c device adaptor - * \return 1 on success + * returns 1 on success */ bool drm_probe_ddc(struct i2c_adapter *adapter) @@ -1455,8 +1455,10 @@ bad_std_timing(u8 a, u8 b) /** * drm_mode_std - convert standard mode info (width, height, refresh) into mode + * @connector: connector corresponding to the HDMI/DP sink + * @edid: EDID data * @t: standard timing params - * @timing_level: standard timing level + * @revision: EDID revision * * Take the standard timing params (in this case width, aspect, and refresh) * and convert them into a real mode using CVT/GTF/DMT. @@ -2000,6 +2002,7 @@ do_established_modes(struct detailed_timing *timing, void *c) /** * add_established_modes - get est. modes from EDID and add them + * @connector: connector corresponding to the HDMI/DP sink * @edid: EDID block to scan * * Each EDID block contains a bitmap of the supported "established modes" list @@ -2062,6 +2065,7 @@ do_standard_modes(struct detailed_timing *timing, void *c) /** * add_standard_modes - get std. modes from EDID and add them + * @connector: connector corresponding to the HDMI/DP sink * @edid: EDID block to scan * * Standard modes can be calculated using the appropriate standard (DMT, @@ -2192,7 +2196,7 @@ do_detailed_mode(struct detailed_timing *timing, void *c) } } -/* +/** * add_detailed_modes - Add modes from detailed timings * @connector: attached connector * @edid: EDID block to scan @@ -2231,7 +2235,8 @@ add_detailed_modes(struct drm_connector *connector, struct edid *edid, #define EDID_CEA_VCDB_QS (1 << 6) /** - * Search EDID for CEA extension block. + * drm_find_cea_extension() - Search EDID for CEA extension block. + * @edid: EDID block to scan */ u8 *drm_find_cea_extension(struct
[RFC][PATCH 00/30] staging: Android sync driver
As proposed yesterday, here's the Android sync driver patches for staging. I've preserved the commit history, but moved all the changes over to be against the staging directory (instead of drivers/base). The goal of submitting this driver to staging is to try to get more collaberation, as there are some similar efforts going on in the community with dmabuf-fences. My email from yesterday with more details for how I hope this goes is here: http://comments.gmane.org/gmane.linux.kernel/1448420 Erik also provided a nice background on the patch set in his reply yesterday, which I'll quote here: "In Honeycomb where we introduced the Hardware Composer HAL. This is a userspace layer that allows composition acceleration on a per platform basis. Different SoC vendors have implemented this using overlays, 2d blitters, a combinations of both, or other clever/disgusting means. Along with the HWC we consolidated a lot of our camera and media pipeline to allow their input to be fed into the GPU or display(overlay.) In order to exploit parallelism the the graphics pipeline, this introduced lots of implicit synchronization dependancies. After a couple years of working with many different SoC vendors, we found that it was really difficult to communicate our system's expectations of the implicit contract and it was difficult for the SoC vendors to properly implement the implicit contract in each of their IP blocks (display, gpu, camera, video codecs). It was also incredibly difficult to debug when problems/deadlocks arose. In an effort to clean up the situation we decided to create set of simple synchronization primitives and have our compositor (SurfaceFlinger) manage the synchronization contract explicitly. We designed these primitives so that they can be passed across processes (much like ion/dma_buf handles), can be backed by hardware synchronization primitives, and can be combined with other sync dependancies in a heterogeneous manner. We also added enough debugging information to make pinpointing a synchronization deadlock bug easier. There are also OpenGL extensions added (which I believe have been ratified by Khronos) to convert a "native" sync object to a gl fence object and vise versa. So far shipped this system on two products (the Nexus 10 and 4) with two different SoCs (Samsung Exynos5250 and Qualcomm MSM8064.) These two projects were much easier to work out the kinks in the graphics/compositing pipelines. In addition we were able to use the telemetry and tracing features to track down the causes of dropped frames aka "jank." As for the implementation, I started with having the main driver op primitive be a wait() op. I quickly noticed that most of the tricky race condition prone code was ending up in the drivers wait() op. It also made handling asynchronous waits of more than one type of sync_pt difficult to manage. In the end I opted for something roughly like poll() where all the heavy lifting is done at the high level and the drivers only need to implement a simple check function." Anyway, let me know what you think of the patches, and hopefully this is something that could be considered for staging for 3.10 thanks -john Cc: Maarten Lankhorst Cc: Erik Gilling Cc: Daniel Vetter Cc: Rob Clark Cc: Sumit Semwal Cc: Greg KH Cc: dri-devel at lists.freedesktop.org Cc: linaro-mm-sig at lists.linaro.org Cc: Android Kernel Team Erik Gilling (26): staging: sync: Add synchronization framework staging: sw_sync: Add cpu based sync driver staging: sync: Add timestamps to sync_pts staging: sync: Add debugfs support staging: sw_sync: Add debug support staging: sync: Add ioctl to get fence data staging: sw_sync: Add fill_driver_data support staging: sync: Add poll support staging: sync: Allow async waits to be canceled staging: sync: Export sync API symbols staging: sw_sync: Export sw_sync API staging: sync: Reorder sync_fence_release staging: sync: Optimize fence merges staging: sync: Add internal refcounting to fences staging: sync: Add reference counting to timelines staging: sync: Change wait timeout to mirror poll semantics staging: sync: Dump sync state to console on timeout staging: sync: Improve timeout dump messages staging: sync: Dump sync state on fence errors staging: sync: Protect unlocked access to fence status staging: sync: Update new fence status with sync_fence_signal_pt staging: sync: Use proper barriers when waiting indefinitely staging: sync: Refactor sync debug printing staging: sw_sync: Convert to use new value_str debug ops staging: sync: Add tracepoint support staging: sync: Don't log wait timeouts when timeout = 0 Jamie Gennis (1): staging: sync: Fix timeout = 0 wait behavior Rebecca Schultz Zavin (2): staging: sync: Fix error paths staging: sw_sync: Fix error paths ?rjan Eide (1): staging: sync: Fix race condition between merge and signal drivers/staging/android/Kconfig | 27 + drivers
[PATCH 01/30] staging: sync: Add synchronization framework
From: Erik Gilling
Sync is a framework for synchronization between multiple
drivers. Sync implementations can take advantage of hardware
synchronization built into devices like GPUs.
Cc: Maarten Lankhorst
Cc: Erik Gilling
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sumit Semwal
Cc: Greg KH
Cc: dri-devel at lists.freedesktop.org
Cc: Android Kernel Team
Signed-off-by: Erik Gilling
[jstultz: Added commit message, moved to staging, squished minor fix in]
Signed-off-by: John Stultz
---
drivers/staging/android/Kconfig |9 +
drivers/staging/android/Makefile |1 +
drivers/staging/android/sync.c | 525 ++
drivers/staging/android/sync.h | 314 +++
4 files changed, 849 insertions(+)
create mode 100644 drivers/staging/android/sync.c
create mode 100644 drivers/staging/android/sync.h
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 465a28c..c95aede 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -72,6 +72,15 @@ config ANDROID_INTF_ALARM_DEV
elapsed realtime, and a non-wakeup alarm on the monotonic clock.
Also exports the alarm interface to user-space.
+config SYNC
+ bool "Synchronization framework"
+ default n
+ select ANON_INODES
+ help
+ This option enables the framework for synchronization between multiple
+ drivers. Sync implementations can take advantage of hardware
+ synchronization built into devices like GPUs.
+
endif # if ANDROID
endmenu
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index b35a631..22c656c 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT) += timed_output.o
obj-$(CONFIG_ANDROID_TIMED_GPIO) += timed_gpio.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
obj-$(CONFIG_ANDROID_INTF_ALARM_DEV) += alarm-dev.o
+obj-$(CONFIG_SYNC) += sync.o
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
new file mode 100644
index 000..4a9e63d
--- /dev/null
+++ b/drivers/staging/android/sync.c
@@ -0,0 +1,525 @@
+/*
+ * drivers/base/sync.c
+ *
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sync.h"
+
+static void sync_fence_signal_pt(struct sync_pt *pt);
+static int _sync_pt_has_signaled(struct sync_pt *pt);
+
+struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
+ int size, const char *name)
+{
+ struct sync_timeline *obj;
+
+ if (size < sizeof(struct sync_timeline))
+ return NULL;
+
+ obj = kzalloc(size, GFP_KERNEL);
+ if (obj == NULL)
+ return NULL;
+
+ obj->ops = ops;
+ strlcpy(obj->name, name, sizeof(obj->name));
+
+ INIT_LIST_HEAD(&obj->child_list_head);
+ spin_lock_init(&obj->child_list_lock);
+
+ INIT_LIST_HEAD(&obj->active_list_head);
+ spin_lock_init(&obj->active_list_lock);
+
+ return obj;
+}
+
+void sync_timeline_destroy(struct sync_timeline *obj)
+{
+ unsigned long flags;
+ bool needs_freeing;
+
+ spin_lock_irqsave(&obj->child_list_lock, flags);
+ obj->destroyed = true;
+ needs_freeing = list_empty(&obj->child_list_head);
+ spin_unlock_irqrestore(&obj->child_list_lock, flags);
+
+ if (needs_freeing)
+ kfree(obj);
+ else
+ sync_timeline_signal(obj);
+}
+
+static void sync_timeline_add_pt(struct sync_timeline *obj, struct sync_pt *pt)
+{
+ unsigned long flags;
+
+ pt->parent = obj;
+
+ spin_lock_irqsave(&obj->child_list_lock, flags);
+ list_add_tail(&pt->child_list, &obj->child_list_head);
+ spin_unlock_irqrestore(&obj->child_list_lock, flags);
+}
+
+static void sync_timeline_remove_pt(struct sync_pt *pt)
+{
+ struct sync_timeline *obj = pt->parent;
+ unsigned long flags;
+ bool needs_freeing;
+
+ spin_lock_irqsave(&obj->active_list_lock, flags);
+ if (!list_empty(&pt->active_list))
+ list_del_init(&pt->active_list);
+ spin_unlock_irqrestore(&obj->active_list_lock, flags);
+
+ spin_lock_irqsave(&obj->child_list_lock, flags);
+ list_del(&pt->child_list);
+ needs_freeing = obj->destroyed && list_empty(&obj->chi
[PATCH 02/30] staging: sw_sync: Add cpu based sync driver
From: Erik Gilling
Adds a base sync driver that uses the cpu for serialization.
Cc: Maarten Lankhorst
Cc: Erik Gilling
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sumit Semwal
Cc: Greg KH
Cc: dri-devel at lists.freedesktop.org
Cc: Android Kernel Team
Signed-off-by: Erik Gilling
[jstultz: Add commit message, whitespace fixes and move to
staging directory]
Signed-off-by: John Stultz
---
drivers/staging/android/Kconfig | 18 +++
drivers/staging/android/Makefile |1 +
drivers/staging/android/sw_sync.c | 224 +
drivers/staging/android/sw_sync.h | 58 ++
4 files changed, 301 insertions(+)
create mode 100644 drivers/staging/android/sw_sync.c
create mode 100644 drivers/staging/android/sw_sync.h
diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index c95aede..cc406cc 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -81,6 +81,24 @@ config SYNC
drivers. Sync implementations can take advantage of hardware
synchronization built into devices like GPUs.
+config SW_SYNC
+ bool "Software synchronization objects"
+ default n
+ depends on SYNC
+ help
+ A sync object driver that uses a 32bit counter to coordinate
+ syncrhronization. Useful when there is no hardware primitive backing
+ the synchronization.
+
+config SW_SYNC_USER
+ bool "Userspace API for SW_SYNC"
+ default n
+ depends on SW_SYNC
+ help
+ Provides a user space API to the sw sync object.
+ *WARNING* improper use of this can result in deadlocking kernel
+ drivers from userspace.
+
endif # if ANDROID
endmenu
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 22c656c..c136299 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_ANDROID_TIMED_GPIO)+= timed_gpio.o
obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
obj-$(CONFIG_ANDROID_INTF_ALARM_DEV) += alarm-dev.o
obj-$(CONFIG_SYNC) += sync.o
+obj-$(CONFIG_SW_SYNC) += sw_sync.o
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
new file mode 100644
index 000..c27004c
--- /dev/null
+++ b/drivers/staging/android/sw_sync.c
@@ -0,0 +1,224 @@
+/*
+ * drivers/base/sw_sync.c
+ *
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sw_sync.h"
+
+static int sw_sync_cmp(u32 a, u32 b)
+{
+ if (a == b)
+ return 0;
+
+ return ((s32)a - (s32)b) < 0 ? -1 : 1;
+}
+
+struct sync_pt *sw_sync_pt_create(struct sw_sync_timeline *obj, u32 value)
+{
+ struct sw_sync_pt *pt;
+
+ pt = (struct sw_sync_pt *)
+ sync_pt_create(&obj->obj, sizeof(struct sw_sync_pt));
+
+ pt->value = value;
+
+ return (struct sync_pt *)pt;
+}
+
+static struct sync_pt *sw_sync_pt_dup(struct sync_pt *sync_pt)
+{
+ struct sw_sync_pt *pt = (struct sw_sync_pt *) sync_pt;
+ struct sw_sync_timeline *obj =
+ (struct sw_sync_timeline *)sync_pt->parent;
+
+ return (struct sync_pt *) sw_sync_pt_create(obj, pt->value);
+}
+
+static int sw_sync_pt_has_signaled(struct sync_pt *sync_pt)
+{
+ struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
+ struct sw_sync_timeline *obj =
+ (struct sw_sync_timeline *)sync_pt->parent;
+
+ return sw_sync_cmp(obj->value, pt->value) >= 0;
+}
+
+static int sw_sync_pt_compare(struct sync_pt *a, struct sync_pt *b)
+{
+ struct sw_sync_pt *pt_a = (struct sw_sync_pt *)a;
+ struct sw_sync_pt *pt_b = (struct sw_sync_pt *)b;
+
+ return sw_sync_cmp(pt_a->value, pt_b->value);
+}
+
+struct sync_timeline_ops sw_sync_timeline_ops = {
+ .driver_name = "sw_sync",
+ .dup = sw_sync_pt_dup,
+ .has_signaled = sw_sync_pt_has_signaled,
+ .compare = sw_sync_pt_compare,
+};
+
+
+struct sw_sync_timeline *sw_sync_timeline_create(const char *name)
+{
+ struct sw_sync_timeline *obj = (struct sw_sync_timeline *)
+ sync_timeline_create(&sw_sync_timeline_ops,
+sizeof(struct sw_sync_timeline),
+name);
+
+ return obj;
+}
+
+void sw_sync_timeline_inc(struct sw_sync_timeline *obj, u32 inc)
+{
+ obj->value += inc;
+
+ sy
[PATCH 03/30] staging: sync: Add timestamps to sync_pts
From: Erik Gilling
Add ktime timestamps to sync_pt structure and
update them when signaled
Cc: Maarten Lankhorst
Cc: Erik Gilling
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Sumit Semwal
Cc: Greg KH
Cc: dri-devel at lists.freedesktop.org
Cc: Android Kernel Team
Signed-off-by: Erik Gilling
[jstultz: Added commit message]
Signed-off-by: John Stultz
---
drivers/staging/android/sync.c |5 +
drivers/staging/android/sync.h |5 +
2 files changed, 10 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 4a9e63d..88d7e66 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -155,12 +155,17 @@ void sync_pt_free(struct sync_pt *pt)
/* call with pt->parent->active_list_lock held */
static int _sync_pt_has_signaled(struct sync_pt *pt)
{
+ int old_status = pt->status;
+
if (!pt->status)
pt->status = pt->parent->ops->has_signaled(pt);
if (!pt->status && pt->parent->destroyed)
pt->status = -ENOENT;
+ if (pt->status != old_status)
+ pt->timestamp = ktime_get();
+
return pt->status;
}
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 388acd1..a8e289d 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -16,6 +16,7 @@
#include
#ifdef __KERNEL__
+#include
#include
#include
#include
@@ -90,6 +91,8 @@ struct sync_timeline {
* @fence: sync_fence to which the sync_pt belongs
* @pt_list: membership in sync_fence.pt_list_head
* @status:1: signaled, 0:active, <0: error
+ * @timestamp: time which sync_pt status transitioned from active to
+ * singaled or error.
*/
struct sync_pt {
struct sync_timeline*parent;
@@ -102,6 +105,8 @@ struct sync_pt {
/* protected by parent->active_list_lock */
int status;
+
+ ktime_t timestamp;
};
/**
--
1.7.10.4
