[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 maarten.lankho...@canonical.com
---
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 fail_fn 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 fail_fn 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 fail_fn 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
[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 maarten.lankho...@canonical.com
---
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
[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 maarten.lankho...@canonical.com
---
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++;
-
[RFC][PATCH]
Hey all, as an original Austrian, I was curious about the current status of the at DVB-T scan tables. I found that neither the original source was any longer available, nor where all frequencies listed. I thus located the new list [1] and updated the list accordingly. I am not aware if any of the original authors of at-Official (from git log) that are actual employees of the ORS and thus renamed the file to at-All as that is more representative and more in line with other files. With regard to the content of the scan table, I could not find information on any of the parameters except for the bandwith so I assumed they where all identical (3/4 QAM16 8K 1/4). The only exception is 578 MHz, which has been both 1/4 and 1/8th guard-interval and thus left it as such. Since I'm many kilometers away from Austria I have no way of scanning all those frequencies. While I assume the list from the ORS is accurate, some confirmation before pushing would be appreciated. I'll wait a while before pushing this one from my local repository. Oliver [1] http://www.ors.at/fileadmin/user_upload/downloads/DVB-T_Kanalbezeichnungen_und_Mittenfrequenzen.pdf From 3cda18f8369c515bd47d1ae1e2ffc88cfbb97436 Mon Sep 17 00:00:00 2001 From: Oliver Schinagl oli...@schinagl.nl Date: Thu, 28 Feb 2013 11:16:20 +0100 Subject: [PATCH] Update for Austrian DVB-T Renamed at-Official to at-All. Added and updated all frequencies. from http://www.ors.at/fileadmin/user_upload/downloads/DVB-T_Kanalbezeichnungen_und_Mittenfrequenzen.pdf No further details are given besides an 8MHz bandwith so assuming the previous settings for now. --- dvb-t/at-All | 53 + dvb-t/at-Official | 24 2 files changed, 53 insertions(+), 24 deletions(-) create mode 100644 dvb-t/at-All delete mode 100644 dvb-t/at-Official diff --git a/dvb-t/at-All b/dvb-t/at-All new file mode 100644 index 000..183dc0c --- /dev/null +++ b/dvb-t/at-All @@ -0,0 +1,53 @@ +# Austria, all DVB-T transmitters run by ORS +# Created from +# http://www.ors.at/fileadmin/user_upload/downloads/DVB-T_Kanalbezeichnungen_und_Mittenfrequenzen.pdf +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +T 47400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 48200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 49000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 49800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 50600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 51400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 52200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 53000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 53800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 54600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 55400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 56200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 57000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 57800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 57800 8MHz 3/4 NONE QAM16 8k 1/8 NONE +T 58600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 59400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 60200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 61000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 61800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 62600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 63400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 64200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 65000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 65800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 66600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 67400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 68200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 69000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 69800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 70600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 71400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 72200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 73000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 73800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 74600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 75400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 76200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 77000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 77800 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 78600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 79400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 80200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 81000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 82600 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 83400 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 84200 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 85000 8MHz 3/4 NONE QAM16 8k 1/4 NONE +T 85800 8MHz 3/4 NONE QAM16 8k 1/4 NONE diff --git a/dvb-t/at-Official b/dvb-t/at-Official deleted file mode 100644 index cdb221c..000 --- a/dvb-t/at-Official +++ /dev/null @@ -1,24 +0,0 @@ -# Austria, all DVB-T transmitters run by ORS -# Created from http://www.ors.at/view08/ors.php?mid=94 -# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 47400 8MHz 3/4 NONE QAM16 8k 1/4 NONE -T 49000 8MHz 3/4 NONE QAM16 8k 1/4 NONE -T 49800 8MHz 3/4 NONE QAM16 8k 1/4 NONE -T 51400 8MHz 3/4 NONE QAM16 8k 1/4 NONE -T 52200 8MHz
Re: SMDKV210 support issue in kernel 3.8 (dma-pl330 and HDMI failed)
于 2013/2/28 5:41, Sylwester Nawrocki 写道: On 02/27/2013 04:48 PM, Lonsn wrote: 于 2013/2/27 23:13, Lonsn 写道: On 02/26/2013 09:07 PM, Sylwester Nawrocki wrote: On 02/26/2013 01:59 PM, Lonsn wrote: [...] Now kernel prints the following HDMI related: m2m-testdev m2m-testdev.0: mem2mem-testdevDevice registered as /dev/video0 s5p-jpeg s5p-jpeg.0: encoder device registered as /dev/video1 s5p-jpeg s5p-jpeg.0: decoder device registered as /dev/video2 s5p-jpeg s5p-jpeg.0: Samsung S5P JPEG codec s5p-mfc s5p-mfc: decoder registered as /dev/video3 s5p-mfc s5p-mfc: encoder registered as /dev/video4 s5p-hdmi s5pv210-hdmi: probe start s5p-hdmi s5pv210-hdmi: HDMI resource init s5p-hdmiphy 3-0038: probe successful s5p-hdmi s5pv210-hdmi: probe successful Samsung TV Mixer driver, (c) 2010-2011 Samsung Electronics Co., Ltd. s5p-mixer s5p-mixer: probe start s5p-mixer s5p-mixer: resources acquired s5p-mixer s5p-mixer: added output 'S5P HDMI connector' from module 's5p-hdmi' s5p-mixer s5p-mixer: module s5p-sdo provides no subdev! s5p-mixer s5p-mixer: registered layer graph0 as /dev/video5 s5p-mixer s5p-mixer: registered layer graph1 as /dev/video6 s5p-mixer s5p-mixer: registered layer video0 as /dev/video7 s5p-mixer s5p-mixer: probe successful How can I test the HDMI output whether it's OK? Which /dev/video is real HDMI output? I have used http://git.infradead.org/users/kmpark/public-apps hdmi test program buf failed: root@linaro-developer:/opt# ./tvdemo /dev/video7 720 480 0 0 ERROR(main.c:80) : VIDIOC_S_FMT failed: Invalid argument It failed because you've opened device node of the Video Processor, which supports only NV12/21(MT) formats. I believe the v4l2-hdmi-example application, which renders some simple test images, needs to be run with one the graphics layer video nodes as an argument. Doesn't it work when you try on /dev/video5 or /dev/video6 ? I have tested /dev/video5 and /dev/video6, the same output as following: root@linaro-developer:/opt# ./tvdemo /dev/video5 720 480 0 0 start ERROR(main.c:256) : VIDIOC_DQBUF failed: Invalid argument Aborted root@linaro-developer:/opt# dmesg s5p-mixer s5p-mixer: mxr_video_open:762 s5p-mixer s5p-mixer: resume - start s5p-mixer s5p-mixer: resume - finished s5p-hdmi s5pv210-hdmi: hdmi_g_mbus_fmt s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: mxr_s_fmt:322 s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: mxr_g_fmt:301 s5p-mixer s5p-mixer: mxr_g_fmt:301 s5p-mixer s5p-mixer: mxr_reqbufs:672 s5p-mixer s5p-mixer: queue_setup s5p-mixer s5p-mixer: fmt = ARGB s5p-mixer s5p-mixer: size[0] = 00151800 s5p-mixer s5p-mixer: mxr_querybuf:680 s5p-mixer s5p-mixer: mxr_video_mmap:829 s5p-mixer s5p-mixer: mxr_querybuf:680 s5p-mixer s5p-mixer: mxr_video_mmap:829 s5p-mixer s5p-mixer: mxr_querybuf:680 s5p-mixer s5p-mixer: mxr_video_mmap:829 s5p-mixer s5p-mixer: mxr_s_selection: rect: 720x480@0,0 s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: mxr_qbuf:688(0) s5p-mixer s5p-mixer: mxr_qbuf:688(1) s5p-mixer s5p-mixer: mxr_qbuf:688(2) s5p-mixer s5p-mixer: mxr_streamon:713 s5p-mixer s5p-mixer: queuing buffer s5p-mixer s5p-mixer: queuing buffer s5p-mixer s5p-mixer: queuing buffer s5p-mixer s5p-mixer: start_streaming s5p-mixer s5p-mixer: mxr_output_get(1) s5p-hdmi s5pv210-hdmi: hdmi_runtime_resume s5p-hdmi
Re: SMDKV210 support issue in kernel 3.8 (dma-pl330 and HDMI failed)
HDMI output is OK now, it's a variable init question in 'struct v4l2_buffer buf' when call ioctl(fd, VIDIOC_DQBUF, buf) in the hdmi example application. Add m.planes in buf then OK. Thanks all! I will continue to test the mfc decoder for s5pv210. Regards, 于 2013/2/28 20:28, Lonsn 写道: 于 2013/2/28 5:41, Sylwester Nawrocki 写道: On 02/27/2013 04:48 PM, Lonsn wrote: 于 2013/2/27 23:13, Lonsn 写道: On 02/26/2013 09:07 PM, Sylwester Nawrocki wrote: On 02/26/2013 01:59 PM, Lonsn wrote: [...] Now kernel prints the following HDMI related: m2m-testdev m2m-testdev.0: mem2mem-testdevDevice registered as /dev/video0 s5p-jpeg s5p-jpeg.0: encoder device registered as /dev/video1 s5p-jpeg s5p-jpeg.0: decoder device registered as /dev/video2 s5p-jpeg s5p-jpeg.0: Samsung S5P JPEG codec s5p-mfc s5p-mfc: decoder registered as /dev/video3 s5p-mfc s5p-mfc: encoder registered as /dev/video4 s5p-hdmi s5pv210-hdmi: probe start s5p-hdmi s5pv210-hdmi: HDMI resource init s5p-hdmiphy 3-0038: probe successful s5p-hdmi s5pv210-hdmi: probe successful Samsung TV Mixer driver, (c) 2010-2011 Samsung Electronics Co., Ltd. s5p-mixer s5p-mixer: probe start s5p-mixer s5p-mixer: resources acquired s5p-mixer s5p-mixer: added output 'S5P HDMI connector' from module 's5p-hdmi' s5p-mixer s5p-mixer: module s5p-sdo provides no subdev! s5p-mixer s5p-mixer: registered layer graph0 as /dev/video5 s5p-mixer s5p-mixer: registered layer graph1 as /dev/video6 s5p-mixer s5p-mixer: registered layer video0 as /dev/video7 s5p-mixer s5p-mixer: probe successful How can I test the HDMI output whether it's OK? Which /dev/video is real HDMI output? I have used http://git.infradead.org/users/kmpark/public-apps hdmi test program buf failed: root@linaro-developer:/opt# ./tvdemo /dev/video7 720 480 0 0 ERROR(main.c:80) : VIDIOC_S_FMT failed: Invalid argument It failed because you've opened device node of the Video Processor, which supports only NV12/21(MT) formats. I believe the v4l2-hdmi-example application, which renders some simple test images, needs to be run with one the graphics layer video nodes as an argument. Doesn't it work when you try on /dev/video5 or /dev/video6 ? I have tested /dev/video5 and /dev/video6, the same output as following: root@linaro-developer:/opt# ./tvdemo /dev/video5 720 480 0 0 start ERROR(main.c:256) : VIDIOC_DQBUF failed: Invalid argument Aborted root@linaro-developer:/opt# dmesg s5p-mixer s5p-mixer: mxr_video_open:762 s5p-mixer s5p-mixer: resume - start s5p-mixer s5p-mixer: resume - finished s5p-hdmi s5pv210-hdmi: hdmi_g_mbus_fmt s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: mxr_s_fmt:322 s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: mxr_g_fmt:301 s5p-mixer s5p-mixer: mxr_g_fmt:301 s5p-mixer s5p-mixer: mxr_reqbufs:672 s5p-mixer s5p-mixer: queue_setup s5p-mixer s5p-mixer: fmt = ARGB s5p-mixer s5p-mixer: size[0] = 00151800 s5p-mixer s5p-mixer: mxr_querybuf:680 s5p-mixer s5p-mixer: mxr_video_mmap:829 s5p-mixer s5p-mixer: mxr_querybuf:680 s5p-mixer s5p-mixer: mxr_video_mmap:829 s5p-mixer s5p-mixer: mxr_querybuf:680 s5p-mixer s5p-mixer: mxr_video_mmap:829 s5p-mixer s5p-mixer: mxr_s_selection: rect: 720x480@0,0 s5p-mixer s5p-mixer: src.full_size = (720, 480) s5p-mixer s5p-mixer: src.size = (720, 480) s5p-mixer s5p-mixer: src.offset = (0, 0) s5p-mixer s5p-mixer: dst.full_size = (720, 480) s5p-mixer s5p-mixer: dst.size = (720, 480) s5p-mixer s5p-mixer: dst.offset = (0, 0) s5p-mixer s5p-mixer: ratio = (0, 0) s5p-mixer s5p-mixer: mxr_qbuf:688(0) s5p-mixer s5p-mixer: mxr_qbuf:688(1) s5p-mixer s5p-mixer:
Re: [PATCH 1/3] [media] v4l2-mem2mem: use CAPTURE queue lock
On Wed, Feb 6, 2013 at 4:03 PM, John Sheu s...@google.com wrote:
From: John Sheu s...@chromium.org
In v4l2_m2m_try_schedule(), use the CAPTURE queue lock when accessing
the CAPTURE queue, instead of relying on just holding the OUTPUT queue
lock.
Signed-off-by: John Sheu s...@google.com
Acked-by: Pawel Osciak pa...@osciak.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 438ea45..c52a2c5 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -230,12 +230,15 @@ static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx
*m2m_ctx)
dprintk(No input buffers available\n);
return;
}
+ spin_lock_irqsave(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
if (list_empty(m2m_ctx-cap_q_ctx.rdy_queue)) {
+ spin_unlock_irqrestore(m2m_ctx-cap_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
dprintk(No output buffers available\n);
return;
}
+ spin_unlock_irqrestore(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock, flags);
if (m2m_dev-m2m_ops-job_ready
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media]: v4l2-mem2mem: drop rdy_queue on STREAMOFF
On Wed, Feb 6, 2013 at 4:03 PM, John Sheu s...@google.com wrote:
From: John Sheu s...@chromium.org
When a v4l2-mem2mem context gets a STREAMOFF call on either its CAPTURE
or OUTPUT queues, we should:
* Drop the corresponding rdy_queue, since a subsequent STREAMON expects
an empty queue.
* Deschedule the context, as it now has at least one empty queue and
cannot run.
Signed-off-by: John Sheu s...@google.com
Acked-by: Pawel Osciak pa...@osciak.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index c52a2c5..c5c9d24 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -408,10 +408,35 @@ EXPORT_SYMBOL_GPL(v4l2_m2m_streamon);
int v4l2_m2m_streamoff(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
enum v4l2_buf_type type)
{
- struct vb2_queue *vq;
+ struct v4l2_m2m_dev *m2m_dev;
+ struct v4l2_m2m_queue_ctx *q_ctx;
+ unsigned long flags_job, flags;
+ int ret;
- vq = v4l2_m2m_get_vq(m2m_ctx, type);
- return vb2_streamoff(vq, type);
+ q_ctx = get_queue_ctx(m2m_ctx, type);
+ ret = vb2_streamoff(q_ctx-q, type);
+ if (ret)
+ return ret;
+
+ m2m_dev = m2m_ctx-m2m_dev;
+ spin_lock_irqsave(m2m_dev-job_spinlock, flags_job);
+ /* We should not be scheduled anymore, since we're dropping a queue.
*/
+ INIT_LIST_HEAD(m2m_ctx-queue);
+ m2m_ctx-job_flags = 0;
+
+ spin_lock_irqsave(q_ctx-rdy_spinlock, flags);
+ /* Drop queue, since streamoff returns device to the same state as
after
+* calling reqbufs. */
+ INIT_LIST_HEAD(q_ctx-rdy_queue);
+ spin_unlock_irqrestore(q_ctx-rdy_spinlock, flags);
+
+ if (m2m_dev-curr_ctx == m2m_ctx) {
+ m2m_dev-curr_ctx = NULL;
+ wake_up(m2m_ctx-finished);
+ }
+ spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(v4l2_m2m_streamoff);
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SMDKV210 support issue in kernel 3.8 (dma-pl330 and HDMI failed)
On 02/28/2013 04:09 PM, Lonsn wrote: HDMI output is OK now, it's a variable init question in 'struct v4l2_buffer buf' when call ioctl(fd, VIDIOC_DQBUF, buf) in the hdmi example application. Add m.planes in buf then OK. Thanks all! I will continue to test the mfc decoder for s5pv210. Well done! I was going to suggest exactly that to you. It's due to some change in v4l2-core in recent versions of the kernel. I'll try to update the example application when I find some time. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rc: ir-rx51: Fix compilation
From: Joni Lapilainen joni.lapilai...@gmail.com Signed-off-by: Joni Lapilainen joni.lapilai...@gmail.com --- drivers/media/rc/ir-rx51.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c index 8ead492..3971192 100644 --- a/drivers/media/rc/ir-rx51.c +++ b/drivers/media/rc/ir-rx51.c @@ -27,7 +27,8 @@ #include linux/wait.h #include plat/dmtimer.h -#include plat/clock.h + +#include ../../../arch/arm/mach-omap2/clock.h #include media/lirc.h #include media/lirc_dev.h @@ -209,7 +210,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51) } clk_fclk = omap_dm_timer_get_fclk(lirc_rx51-pwm_timer); - lirc_rx51-fclk_khz = clk_fclk-rate / 1000; + lirc_rx51-fclk_khz = clk_get_rate(clk_fclk) / 1000; return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Feb 28 19:00:16 CET 2013 git branch: for_v3.9 git hash: ed72d37a33fdf43dc47787fe220532cdec9da528 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-blackfin: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 Amudalal.kris...@samsung.com
Signed-off-by: Vikas Sajjanvikas.saj...@linaro.org
---
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 @@
#includelinux/clk.h
#includelinux/of_device.h
#includelinux/pm_runtime.h
+#includelinux/pinctrl/consumer.h
#includevideo/of_display_timing.h
#includevideo/samsung_fimd.h
@@ -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@vger.kernel.org/msg78030.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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!) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx231xx : Add support for OTG102 aka EZGrabber2
OTG102.patch Description: Binary data
cx231xx : Add support for OTG102 aka EZGrabber2
The text was inadvertently dropped from my first email, reincluding here. - This is a patch I have created that enables basic support for a product marketed as EZGrabber2, which is identified as an OTG102 board by dmesg and lsusb. I have documented some detail about the product and this patch at http://linuxtv.org/wiki/index.php/OTG102. In summary, it has a peculiarly marked chipset, CX78921-11z, although the packaged windows drivers looked similar enough to the cx23100 series. With some experimentation, was able to get the device to operate properly by replicating much of the code for the CX231XX_BOARD_CNXT_VIDEO_GRABBER, but with the agc_analog_digital_select_gpio information from the windows driver inf file and defining .dont_use_port_3. The vendor documentation states the device supports hardware encoding of MPEG1/2/4. If I don't include the .has_417=1 option in the device definition, it creates a single /dev/video0 device which works and provides uncompressed video. If I do include that option, the working device is moved to video1, and video0 is created but no data comes out of it. The Geniatech driver also contains a firmware image called cx416enc.rom which is very similar (in binary comparison) to the v4l-cx23885-enc.fw/ hcw85enc.rom. The patch is against my local gentoo-3.6 kernel. As I am a first time contributor to this mailing list, and only have a superficial understanding of the cx231xx and related drivers and the v4l2 framework (and c programming in general), any stylistic or procedural guidance for improving the patch for eventual submission, information posted to the linuxtv wiki, etc, would be welcome. Also considering the recently submitted patch for the Elgato Video Capture V2 which also adds device 16 to cx2311.h and the many recent patches by Hans Verkuil, this may take some further working to align it with a moving target. If you desire any further information, let me know. Thanks. Matt OTG102.patch Description: Binary data
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 jy0922.s...@samsung.com 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 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 v9: - replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL() will be depreciated, as discussed at http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html 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 jy0922.s...@samsung.com to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae inki@samsung.com to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae inki@samsung.com, 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 paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, 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 r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 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 l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
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 linux/of_device.h
#include linux/pm_runtime.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 2/2] video: drm: exynos: Add pinctrl support to fimd
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
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..c00aa4a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include linux/clk.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include video/of_display_timing.h
#include video/samsung_fimd.h
@@ -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(pctrl)) {
+ DRM_ERROR(failed: devm_pinctrl_get_select_default():\n
+ %d\n, PTR_RET(pctrl));
+ return PTR_ERR(pctrl);
+ }
+
} else {
pdata = pdev-dev.platform_data;
if (!pdata) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx231xx : Add support for OTG102 aka EZGrabber2
On Fri March 1 2013 00:34:38 Matt Gomboc wrote:
This is a patch I have created that enables basic support for a product
marketed as EZGrabber2, which is identified as an OTG102 board by dmesg and
lsusb.
I have documented some detail about the product and this patch at
http://linuxtv.org/wiki/index.php/OTG102. In summary, it has a peculiarly
marked chipset, CX78921-11z, although the packaged windows drivers looked
similar enough to the cx23100 series. With some experimentation, was able to
get the device to operate properly by replicating much of the code for the
CX231XX_BOARD_CNXT_VIDEO_GRABBER, but with the
agc_analog_digital_select_gpio information from the windows driver inf file
and defining .dont_use_port_3.
The vendor documentation states the device supports hardware encoding of
MPEG1/2/4. If I don't include the .has_417=1 option in the device
definition, it creates a single /dev/video0 device which works and provides
uncompressed video. If I do include that option, the working device is moved
to video1, and video0 is created but no data comes out of it. The Geniatech
driver also contains a firmware image called cx416enc.rom which is very
similar (in binary comparison) to the v4l-cx23885-enc.fw/ hcw85enc.rom.
Yeah, I never was able to get the 417 part working either. The code for
that seems to be highly unstable.
The patch is against my local gentoo-3.6 kernel. As I am a first time
contributor to this mailing list, and only have a superficial understanding
of the cx231xx and related drivers and the v4l2 framework (and c programming
in general), any stylistic or procedural guidance for improving the patch
for eventual submission, information posted to the linuxtv wiki, etc, would
be welcome.
It's not bad for a first time :-)
The main thing to remember is to post the patch as part of the email, not as
an attachment. That makes it easier for us to review.
I also need a 'Signed-of-by' line before a patch can be submitted. See:
http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches
Also considering the recently submitted patch for the Elgato Video Capture
V2 which also adds device 16 to cx2311.h and the many recent patches by
Hans Verkuil, this may take some further working to align it with a moving
target.
It shouldn't be too bad, but it probably makes life easier if we wait with
applying this patch until after my patch series has been merged.
If you desire any further information, let me know. Thanks.
Matt
Some small comments regarding this patch:
diff -uprN linux-3.6/drivers/media/video/cx231xx/cx231xx-avcore.c
linux-3.6.new/drivers/media/video/cx231xx/cx231xx-avcore.c
--- linux-3.6/drivers/media/video/cx231xx/cx231xx-avcore.c2012-09-30
17:47:46.0 -0600
+++ linux-3.6.new/drivers/media/video/cx231xx/cx231xx-avcore.c
2013-02-26 19:58:51.096793077 -0700
@@ -352,6 +352,7 @@ int cx231xx_afe_update_power_control(str
case CX231XX_BOARD_CNXT_RDE_253S:
case CX231XX_BOARD_CNXT_RDU_253S:
case CX231XX_BOARD_CNXT_VIDEO_GRABBER:
+ case CX231XX_BOARD_OTG102:
case CX231XX_BOARD_HAUPPAUGE_EXETER:
case CX231XX_BOARD_HAUPPAUGE_USBLIVE2:
case CX231XX_BOARD_PV_PLAYTV_USB_HYBRID:
@@ -1719,6 +1720,7 @@ int cx231xx_dif_set_standard(struct cx23
case CX231XX_BOARD_CNXT_SHELBY:
case CX231XX_BOARD_CNXT_RDU_250:
case CX231XX_BOARD_CNXT_VIDEO_GRABBER:
+ case CX231XX_BOARD_OTG102:
case CX231XX_BOARD_HAUPPAUGE_EXETER:
func_mode = 0x03;
break;
diff -uprN linux-3.6/drivers/media/video/cx231xx/cx231xx-cards.c
linux-3.6.new/drivers/media/video/cx231xx/cx231xx-cards.c
--- linux-3.6/drivers/media/video/cx231xx/cx231xx-cards.c 2012-09-30
17:47:46.0 -0600
+++ linux-3.6.new/drivers/media/video/cx231xx/cx231xx-cards.c 2013-02-28
12:23:58.925869674 -0700
@@ -280,6 +280,37 @@ struct cx231xx_board cx231xx_boards[] =
}
},
},
+ [CX231XX_BOARD_OTG102] = {
+.name = Geniatech OTG102,
+.tuner_type = TUNER_ABSENT,
+.decoder = CX231XX_AVDECODER,
+.output_mode = OUT_MODE_VIP11,
+.ctl_pin_status_mask = 0xFFC4,
+.agc_analog_digital_select_gpio = 0x0c, /* According with PV
CxPlrCAP.inf file */
+.gpio_pin_status_mask = 0x4001000,
+.norm = V4L2_STD_NTSC,
+.no_alt_vanc = 1,
+.external_av = 1,
+.dont_use_port_3 = 1,
+ //.has_417 = 1,
Don't use //, always use /* */ (coding style issue).
+ /* this board has hardware encoding chip supporting mpeg1/2/4,
but as the 417 is apparently not working for the
+reference board it is not on this one either. building the
driver with this option and then loading the module
+creates a second video device
