[PATCH 02/11] ivtv: use kthread_worker instead of workqueue
From: Tejun Heo t...@kernel.org
Upcoming workqueue updates will no longer guarantee fixed workqueue to
worker kthread association, so giving RT priority to the irq worker
won't work. Use kthread_worker which guarantees specific kthread
association instead. This also makes setting the priority cleaner.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Andy Walls awa...@md.metrocast.net
Cc: Andrew Morton a...@linux-foundation.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Bhanu Prakash Gollapudi bprak...@broadcom.com
---
drivers/media/video/ivtv/ivtv-driver.c | 26 --
drivers/media/video/ivtv/ivtv-driver.h |8
drivers/media/video/ivtv/ivtv-irq.c| 15 +++
drivers/media/video/ivtv/ivtv-irq.h|2 +-
4 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index fe7847b..3994642 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -706,6 +706,8 @@ done:
*/
static int __devinit ivtv_init_struct1(struct ivtv *itv)
{
+ struct sched_param param = { .sched_priority = 99 };
+
itv-base_addr = pci_resource_start(itv-pdev, 0);
itv-enc_mbox.max_mbox = 2; /* the encoder has 3 mailboxes (0-2) */
itv-dec_mbox.max_mbox = 1; /* the decoder has 2 mailboxes (0-1) */
@@ -717,13 +719,17 @@ static int __devinit ivtv_init_struct1(struct ivtv *itv)
spin_lock_init(itv-lock);
spin_lock_init(itv-dma_reg_lock);
- itv-irq_work_queues =
create_singlethread_workqueue(itv-v4l2_dev.name);
- if (itv-irq_work_queues == NULL) {
- IVTV_ERR(Could not create ivtv workqueue\n);
+ init_kthread_worker(itv-irq_worker);
+ itv-irq_worker_task = kthread_run(kthread_worker_fn, itv-irq_worker,
+ itv-v4l2_dev.name);
+ if (IS_ERR(itv-irq_worker_task)) {
+ IVTV_ERR(Could not create ivtv task\n);
return -1;
}
+ /* must use the FIFO scheduler as it is realtime sensitive */
+ sched_setscheduler(itv-irq_worker_task, SCHED_FIFO, param);
- INIT_WORK(itv-irq_work_queue, ivtv_irq_work_handler);
+ init_kthread_work(itv-irq_work, ivtv_irq_work_handler);
/* start counting open_id at 1 */
itv-open_id = 1;
@@ -1013,7 +1019,7 @@ static int __devinit ivtv_probe(struct pci_dev *pdev,
/* PCI Device Setup */
retval = ivtv_setup_pci(itv, pdev, pci_id);
if (retval == -EIO)
- goto free_workqueue;
+ goto free_worker;
if (retval == -ENXIO)
goto free_mem;
@@ -1241,8 +1247,8 @@ free_mem:
release_mem_region(itv-base_addr + IVTV_REG_OFFSET, IVTV_REG_SIZE);
if (itv-has_cx23415)
release_mem_region(itv-base_addr + IVTV_DECODER_OFFSET,
IVTV_DECODER_SIZE);
-free_workqueue:
- destroy_workqueue(itv-irq_work_queues);
+free_worker:
+ kthread_stop(itv-irq_worker_task);
err:
if (retval == 0)
retval = -ENODEV;
@@ -1381,9 +1387,9 @@ static void ivtv_remove(struct pci_dev *pdev)
ivtv_set_irq_mask(itv, 0x);
del_timer_sync(itv-dma_timer);
- /* Stop all Work Queues */
- flush_workqueue(itv-irq_work_queues);
- destroy_workqueue(itv-irq_work_queues);
+ /* Kill irq worker */
+ flush_kthread_worker(itv-irq_worker);
+ kthread_stop(itv-irq_worker_task);
ivtv_streams_cleanup(itv, 1);
ivtv_udma_free(itv);
diff --git a/drivers/media/video/ivtv/ivtv-driver.h
b/drivers/media/video/ivtv/ivtv-driver.h
index e8137a2..04bacdb 100644
--- a/drivers/media/video/ivtv/ivtv-driver.h
+++ b/drivers/media/video/ivtv/ivtv-driver.h
@@ -51,7 +51,7 @@
#include linux/unistd.h
#include linux/pagemap.h
#include linux/scatterlist.h
-#include linux/workqueue.h
+#include linux/kthread.h
#include linux/mutex.h
#include linux/slab.h
#include asm/uaccess.h
@@ -261,7 +261,6 @@ struct ivtv_mailbox_data {
#define IVTV_F_I_DEC_PAUSED 20 /* the decoder is paused */
#define IVTV_F_I_INITED 21 /* set after first open */
#define IVTV_F_I_FAILED 22 /* set if first open failed */
-#define IVTV_F_I_WORK_INITED 23 /* worker thread was initialized */
/* Event notifications */
#define IVTV_F_I_EV_DEC_STOPPED 28 /* decoder stopped event */
@@ -668,8 +667,9 @@ struct ivtv {
/* Interrupts DMA */
u32 irqmask;/* active interrupts */
u32 irq_rr_idx; /* round-robin stream index */
- struct workqueue_struct *irq_work_queues; /* workqueue for
PIO/YUV/VBI actions */
- struct work_struct irq_work_queue; /* work entry */
+ struct kthread_worker irq_worker; /* kthread worker for
PIO/YUV/VBI actions */
+
Re: [RFC PATCH] Modify volatile auto cluster handling as per earlier discussions
On Thursday, August 25, 2011 22:22:28 Hans de Goede wrote:
Hi,
First of all thanks for doing this! Overall it looks good,
see below for several (small) remarks which I have.
Thanks for the review!
On 08/09/2011 06:40 PM, Hans Verkuil wrote:
This patch modifies the way autoclusters work when the 'foo' controls are
volatile if autofoo is on.
E.g.: if autogain is true, then gain returns the gain set by the autogain
circuitry.
This patch makes the following changes:
1) The V4L2_CTRL_FLAG_VOLATILE flag is added to let userspace know that a
certain
control is volatile. Currently this is internal information only.
2) If v4l2_ctrl_auto_cluster() is called with the last 'set_volatile'
argument set
to true, then the cluster has the following behavior:
- when in manual mode you can set the manual values normally.
- when in auto mode any new manual values will be ignored. When you
read the manual values you will get those as determined by the auto
mode.
- when switching from auto to manual mode the manual values from the
auto
mode are obtained through g_volatile_ctrl first. Any manual values
explicitly
set by the application will replace those obtained from the automode
and the
final set of values is sent to the driver with s_ctrl.
- when in auto mode the V4L2_CTRL_FLAG_VOLATILE and INACTIVE flags are
set for
the 'foo' controls. These flags are cleared when in manual mode.
This patch modifies existing users of is_volatile and simplifies the pwc
driver
that required this behavior.
The only thing missing is the documentation update and some code comments.
I have to admit that it works quite well.
Hans, can you verify that this does what you wanted it to do?
Regards,
Hans
snip
diff --git a/drivers/media/video/pwc/pwc-v4l.c
b/drivers/media/video/pwc/pwc-v4l.c
index e9a0e94..4ce00bf 100644
--- a/drivers/media/video/pwc/pwc-v4l.c
+++ b/drivers/media/video/pwc/pwc-v4l.c
snip
@@ -632,52 +634,28 @@ static int pwc_set_awb(struct pwc_device *pdev)
{
int ret = 0;
- if (pdev-auto_white_balance-is_new) {
+ if (pdev-auto_white_balance-is_new)
ret = pwc_set_u8_ctrl(pdev, SET_CHROM_CTL,
- WB_MODE_FORMATTER,
- pdev-auto_white_balance-val);
- if (ret)
- return ret;
+ WB_MODE_FORMATTER,
+ pdev-auto_white_balance-val);
+ if (ret)
+ return ret;
- /* Update val when coming from auto or going to a preset */
- if (pdev-red_balance-is_volatile ||
- pdev-auto_white_balance-val == awb_indoor ||
- pdev-auto_white_balance-val == awb_outdoor ||
- pdev-auto_white_balance-val == awb_fl) {
- if (!pdev-red_balance-is_new)
- pwc_get_u8_ctrl(pdev, GET_STATUS_CTL,
- READ_RED_GAIN_FORMATTER,
- pdev-red_balance-val);
- if (!pdev-blue_balance-is_new)
- pwc_get_u8_ctrl(pdev, GET_STATUS_CTL,
- READ_BLUE_GAIN_FORMATTER,
- pdev-blue_balance-val);
- }
- if (pdev-auto_white_balance-val == awb_auto) {
- pdev-red_balance-is_volatile = true;
- pdev-blue_balance-is_volatile = true;
- pdev-color_bal_valid = false; /* Force cache update */
- } else {
- pdev-red_balance-is_volatile = false;
- pdev-blue_balance-is_volatile = false;
- }
+ if (pdev-auto_white_balance-val != awb_manual) {
+ pdev-color_bal_valid = false; /* Force cache update */
+ return 0;
}
The setting of pdev-color_bal_valid = false should happen inside
the if (pdev-auto_white_balance-is_new) block (under the same
pdev-auto_white_balance-val != awb_manual condition), the way it
is now if someone tries to say write blue bal while in awb mode, not
only will the write get ignored (good), but this will also invalidate
the cached values (bad).
True.
- if (ret == 0 pdev-red_balance-is_new) {
- if (pdev-auto_white_balance-val != awb_manual)
- return -EBUSY;
+ if (pdev-red_balance-is_new)
ret = pwc_set_u8_ctrl(pdev, SET_CHROM_CTL,
- PRESET_MANUAL_RED_GAIN_FORMATTER,
- pdev-red_balance-val);
- }
-
- if (ret == 0 pdev-blue_balance-is_new) {
- if (pdev-auto_white_balance-val != awb_manual)
- return -EBUSY;
+ PRESET_MANUAL_RED_GAIN_FORMATTER,
+
Re: Is DVB ioctl FE_SET_FRONTEND broken?
--- On Fri, 26/8/11, Andreas Oberritter o...@linuxtv.org wrote:
can you please test whether https://patchwork.kernel.org/patch/1036132/
restores the old behaviour?
These three pending patches are also related to frontend events:
https://patchwork.kernel.org/patch/1036112/
https://patchwork.kernel.org/patch/1036142/
https://patchwork.kernel.org/patch/1036122/
Andreas,
I've only reviewed these patches so far, but I am concerned that we both have a
different understanding of what the FE_SET_FRONTEND ioctl is supposed to do.
According to the documentation:
The result of this call will be successful if the parameters were valid and
the tuning could be initiated. The result of the tuning operation in itself,
however, will arrive asynchronously as an event.
However, your comment in your first patch reads:
FE_SET_FRONTEND triggers an initial frontend event with status = 0, which
copies output parameters to userspace.
To my mind, these are conflicting statements because how can there be such
thing as an initial frontend event? I am not expecting the kernel to send any
event until the tuning has finished and it can give me real information. I am
*definitely* not expecting the kernel to send my input parameters straight back
to me.
Given the documented description of this ioctl, I would write the following
(pseudo)code in userspace:
int rc;
rc = ioctl(fd, FE_SET_FRONTEND, args);
if (rc != 0) {
printf(Error: could not start tuning.\n);
} else {
struct pollfd pfd;
pfd.fd = fd;
pfd.events = POLLIN;
pfd.revents = 0;
// Wait 5 seconds for tuning to finish.
rc = poll(pfd, 1, 5000);
if (rc 0) {
printf(Error!\n);
} else if (rc == 0) {
printf(Still not tuned after 5 seconds - give up!\n);
} else {
printf(YAY! WE ARE TUNED!\n);
}
}
But your code adds an event to the queue as the ioctl() exits, which means that
my pseudocode is never going to print the Still not tuned after 5 seconds
message but jump straight to YAY! WE ARE TUNED! instead while tuning is
actually still in progress.
So I'm going to say No, your patches don't restore the old behaviour.
Cheers,
Chris
--
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] media: Fix a UVC performance problem on systems with non-coherent DMA.
Hi Al,
Thanks for the patch.
On Thursday 18 August 2011 15:28:29 Al Cooper wrote:
The UVC driver uses usb_alloc_coherent() to allocate DMA data buffers.
On systems without coherent DMA this ends up allocating buffers in
uncached memory. The subsequent memcpy's done to coalesce the DMA
chunks into contiguous buffers then run VERY slowly. On a MIPS test
system the memcpy is about 200 times slower. This issue prevents the
system from keeping up with 720p YUYV data at 10fps.
The following patch uses kmalloc to alloc the DMA buffers instead of
uab_alloc_coherent on systems without coherent DMA. With this patch
the system was easily able to keep up with 720p at 10fps.
Signed-off-by: Al Cooper alcoop...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I will push it to v3.2.
---
drivers/media/video/uvc/uvc_video.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c index 4999479..30c18b4 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -790,8 +790,12 @@ static void uvc_free_urb_buffers(struct uvc_streaming
*stream)
for (i = 0; i UVC_URBS; ++i) {
if (stream-urb_buffer[i]) {
+#ifndef CONFIG_DMA_NONCOHERENT
usb_free_coherent(stream-dev-udev, stream-urb_size,
stream-urb_buffer[i], stream-urb_dma[i]);
+#else
+ kfree(stream-urb_buffer[i]);
+#endif
stream-urb_buffer[i] = NULL;
}
}
@@ -831,9 +835,15 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream, for (; npackets 1; npackets /= 2) {
for (i = 0; i UVC_URBS; ++i) {
stream-urb_size = psize * npackets;
+#ifndef CONFIG_DMA_NONCOHERENT
stream-urb_buffer[i] = usb_alloc_coherent(
stream-dev-udev, stream-urb_size,
gfp_flags | __GFP_NOWARN, stream-urb_dma[i]);
+#else
+ stream-urb_buffer[i] =
+ kmalloc(stream-urb_size, gfp_flags | __GFP_NOWARN);
+#endif
+
if (!stream-urb_buffer[i]) {
uvc_free_urb_buffers(stream);
break;
@@ -908,10 +918,14 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream, urb-context = stream;
urb-pipe = usb_rcvisocpipe(stream-dev-udev,
ep-desc.bEndpointAddress);
+#ifndef CONFIG_DMA_NONCOHERENT
urb-transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
+ urb-transfer_dma = stream-urb_dma[i];
+#else
+ urb-transfer_flags = URB_ISO_ASAP;
+#endif
urb-interval = ep-desc.bInterval;
urb-transfer_buffer = stream-urb_buffer[i];
- urb-transfer_dma = stream-urb_dma[i];
urb-complete = uvc_video_complete;
urb-number_of_packets = npackets;
urb-transfer_buffer_length = size;
@@ -969,8 +983,10 @@ static int uvc_init_video_bulk(struct uvc_streaming
*stream, usb_fill_bulk_urb(urb, stream-dev-udev, pipe,
stream-urb_buffer[i], size, uvc_video_complete,
stream);
+#ifndef CONFIG_DMA_NONCOHERENT
urb-transfer_flags = URB_NO_TRANSFER_DMA_MAP;
urb-transfer_dma = stream-urb_dma[i];
+#endif
stream-urb[i] = urb;
}
--
Regards,
Laurent Pinchart
--
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: Is DVB ioctl FE_SET_FRONTEND broken?
Hi Chris,
reading your first message again, I realize that I was misunderstanding
you. I first thought that you were talking about a regression in Linux
3.0.x.
On 26.08.2011 10:50, Chris Rankin wrote:
--- On Fri, 26/8/11, Andreas Oberritter o...@linuxtv.org wrote:
can you please test whether https://patchwork.kernel.org/patch/1036132/
restores the old behaviour?
These three pending patches are also related to frontend events:
https://patchwork.kernel.org/patch/1036112/
https://patchwork.kernel.org/patch/1036142/
https://patchwork.kernel.org/patch/1036122/
Andreas,
I've only reviewed these patches so far, but I am concerned that we both have
a different understanding of what the FE_SET_FRONTEND ioctl is supposed to
do. According to the documentation:
The result of this call will be successful if the parameters were valid and
the tuning could be initiated. The result of the tuning operation in itself,
however, will arrive asynchronously as an event.
The quoted text is right.
Result of this call and result of the tuning operation are distinct,
where result of this call means that ioctl() will return 0. The
result of a tuning operation is not a single value (success/failure),
but a series of changes. I.e., you'll get an event for every status
change reported by the tuner, e.g. also when a signal is lost.
However, your comment in your first patch reads:
FE_SET_FRONTEND triggers an initial frontend event with status = 0, which
copies output parameters to userspace.
To my mind, these are conflicting statements because how can there be such
thing as an initial frontend event? I am not expecting the kernel to send
any event until the tuning has finished and it can give me real information.
I am *definitely* not expecting the kernel to send my input parameters
straight back to me.
This initial event with status=0 exists since 2002. It's used to notify
a new tuning operation to the event listener.
http://www.linuxtv.org/cgi-bin/viewvc.cgi/DVB/driver/dvb_frontend.c?revision=1.6.2.30view=markup
Given the documented description of this ioctl, I would write the following
(pseudo)code in userspace:
int rc;
rc = ioctl(fd, FE_SET_FRONTEND, args);
if (rc != 0) {
printf(Error: could not start tuning.\n);
} else {
struct pollfd pfd;
pfd.fd = fd;
pfd.events = POLLIN;
pfd.revents = 0;
// Wait 5 seconds for tuning to finish.
rc = poll(pfd, 1, 5000);
if (rc 0) {
printf(Error!\n);
} else if (rc == 0) {
printf(Still not tuned after 5 seconds - give up!\n);
} else {
printf(YAY! WE ARE TUNED!\n);
}
}
But your code adds an event to the queue as the ioctl() exits, which means
that my pseudocode is never going to print the Still not tuned after 5
seconds message but jump straight to YAY! WE ARE TUNED! instead while
tuning is actually still in progress.
It's not my code and my patch doesn't create any new event.
Your example code can't work. You need to call FE_GET_EVENT or
FE_READ_STATUS.
So I'm going to say No, your patches don't restore the old behaviour.
Yes. The patch is restoring a different old behaviour. The behaviour
you're referring to has never been in the kernel. ;-)
Regards,
Andreas
--
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 1/2] DVB: dvb_frontend: convert semaphore to mutex
On 24.08.2011 20:54, Devin Heitmueller wrote: On Wed, Aug 24, 2011 at 2:08 PM, Andreas Oberritter o...@linuxtv.org wrote: Instead of wasting your time with theory, you could have easily reviewed my patch. It's really *very* simple any anyone having used semphores or mutexes in the kernel should be able to see that. There's no need to resort to belittlement. Both of us have a non-trivial number of commits to the Linux kernel. My concern is that in the kernel a semaphore with a unit of one is *not* necessarily the same as a mutex. In particular you need to take into account the calling context since mutexes do more enforcement of certain conditions that may have been acceptable for a semaphore. From http://www.kernel.org/doc/Documentation/mutex-design.txt : === - 'struct mutex' semantics are well-defined and are enforced if CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have virtually no debugging code or instrumentation. The mutex subsystem checks and enforces the following rules: * - only one task can hold the mutex at a time * - only the owner can unlock the mutex * - multiple unlocks are not permitted * - recursive locking is not permitted * - a mutex object must be initialized via the API * - a mutex object must not be initialized via memset or copying * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized * - mutexes may not be used in hardware or software interrupt * contexts such as tasklets and timers === and: === Disadvantages - The stricter mutex API means you cannot use mutexes the same way you can use semaphores: e.g. they cannot be used from an interrupt context, nor can they be unlocked from a different context that which acquired it. [ I'm not aware of any other (e.g. performance) disadvantages from using mutexes at the moment, please let me know if you find any. ] === In short, you cannot just arbitrarily replace one with the other. You need to look at all the possible call paths and ensure that there aren't any cases for example where the mutex is set in one but cleared in the other. Did you evaluate your change in the context of each of the differences described in the list above? You're right. There's one place where the semaphore is taken in user context and released by the frontend thread. I'm going to investigate whether this complicated locking is required. It might as well be possible to move the initialization steps from the beginning of the thread to dvb_frontend_start(), thus rendering this use of the semaphore unnecessary, and therefore making the code easier to understand and maintain. Unfortunately, I couldn't find any pointers as to why unlocking a mutex in a different context is not allowed. The only drawback seems to be a warning (which doesn't show up if there was any previous warning...), if mutex debugging is enabled. Besides that, I didn't notice any problem during runtime tests (on mips with SMP enabled). Regards, Andreas -- 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: dvb_frontend.c warning: can 'timeout' be removed?
Hello Hans, On 25.08.2011 15:29, Hans Verkuil wrote: This is the warning the daily build gives: v4l-dvb-git/drivers/media/dvb/dvb-core/dvb_frontend.c: In function 'dvb_frontend_thread': v4l-dvb-git/drivers/media/dvb/dvb-core/dvb_frontend.c:540:16: warning: variable 'timeout' set but not used [-Wunused-but-set-variable] The 'timeout' variable is indeed not used, but should it? I'm not familiar enough with this code to decide. you can safely remove this variable. The code always behaves the same way, be it woken up by a timeout or on demand (unless freezing or stopping the thread). Regards, Andreas -- 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
omap3isp and tvp5150 hangs
Hi, i need some help to debug a kernel hang on an igep board (+ expansion) when using omap3-isp and tvp5150 video capture. Kernel version is mainline 3.0.1 When i modprobe omap3-isp (after iommu2) the device is correctly recognized: root@igep0020:~# modprobe omap3-isp [ 122.162200] Linux video capture interface: v2.00 [ 122.183319] _regulator_get: omap3isp supply VDD_CSIPHY1 not found, using dummy regulator [ 122.192413] _regulator_get: omap3isp supply VDD_CSIPHY2 not found, using dummy regulator [ 122.201416] omap3isp omap3isp: Revision 2.0 found [ 122.206390] omap-iommu omap-iommu.0: isp: version 1.1 [ 122.262359] tvp5150 2-005c: chip found @ 0xb8 (OMAP I2C adapter) [ 122.363830] tvp5150 2-005c: *** unknown tvp5151 chip detected. [ 122.369964] tvp5150 2-005c: *** Rom ver is 1.0 but then it immediatly hangs. Sysrq show regs: [ 125.420349] Pid: 310, comm: modprobe [ 125.425170] CPU: 0Not tainted (3.0.1+ #22) [ 125.429931] PC is at media_entity_create_link+0x3c/0xe8 [ 125.435485] LR is at isp_probe+0x770/0x97c [omap3_isp] [ 125.440887] pc : [c03420b8]lr : [bf0ddd80]psr: 6013 [ 125.440887] sp : de405de8 ip : fp : c0615998 [ 125.452911] r10: de468800 r9 : r8 : c062f088 [ 125.458374] r7 : deefdc78 r6 : r5 : r4 : [ 125.465240] r3 : r2 : deefdc78 r1 : r0 : de468800 [ 125.472076] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 125.479553] Control: 10c5387d Table: 9e418019 DAC: 0015 Since i had to manually edit default u-boot mux data for some pins, can you confirm this is the right setup? Don't look at the comments because for now i didn't update them to match mux config. CAM_WEN and CAM_STROBE are used for reset/power down and are configured as gpios. MUX_VAL(CP(CAM_HS),(IEN | PTU | EN | M0)) /* GPIO_94 - PDN (Rev. B) */\ MUX_VAL(CP(CAM_VS),(IEN | PTU | EN | M0)) /* GPIO_95 - RESET_N_W (Rev. B) */\ MUX_VAL(CP(CAM_XCLKA), (IDIS | PTD | DIS | M0)) /* CAM_XCLKA */\ MUX_VAL(CP(CAM_PCLK), (IEN | PTU | EN | M0)) /* CAM_PCLK */\ MUX_VAL(CP(CAM_FLD),(IEN | PTD | DIS | M0)) /* GPIO_98 */\ MUX_VAL(CP(CAM_XCLKB), (IDIS | PTD | DIS | M0)) /* CAM_XCLKB */\ MUX_VAL(CP(CAM_D0),(IEN | PTD | DIS | M0)) /* GPIO_99 */\ MUX_VAL(CP(CAM_D1),(IEN | PTD | DIS | M0)) /* GPIO_100 */\ MUX_VAL(CP(CAM_D2),(IEN | PTD | DIS | M0)) /* CAM_D2*/\ MUX_VAL(CP(CAM_D3),(IEN | PTD | DIS | M0)) /* CAM_D3*/\ MUX_VAL(CP(CAM_D4),(IEN | PTD | DIS | M0)) /* CAM_D4*/\ MUX_VAL(CP(CAM_D5),(IEN | PTD | DIS | M0)) /* CAM_D5*/\ MUX_VAL(CP(CAM_D6),(IEN | PTD | DIS | M0)) /* GPIO_105 - RF_CTRL */\ MUX_VAL(CP(CAM_D7),(IEN | PTD | DIS | M0)) /* GPIO_106 - RF_STANDBY */\ MUX_VAL(CP(CAM_D8),(IEN | PTD | DIS | M0)) /* GPIO_107 - RF_INT */\ MUX_VAL(CP(CAM_D9),(IEN | PTD | DIS | M0)) /* GPIO_108 - RF_SYNCB*/\ MUX_VAL(CP(CAM_D10), (IEN | PTD | DIS | M0)) /* CAM_D10 */\ MUX_VAL(CP(CAM_D11), (IEN | PTD | DIS | M0)) /* CAM_D11 */\ I just tried it also with kernel 3.1.0-rc3+ from tmlind repository, it doesn't hang but it segfaults with: [ 70.227844] kernel BUG at drivers/media/media-entity.c:346! [ 70.239471] Unable to handle kernel NULL pointer dereference at virtual address [ 70.248046] pgd = dfbec000 [ 70.250885] [] *pgd=9eeb4831, *pte=, *ppte= [ 70.257476] Internal error: Oops: 817 [#1] [ 70.261779] Modules linked in: tvp5150 omap3_isp(+) v4l2_common videodev iovmm iommu2 iommu libertas_sdio libertas cfg80211 rfkill twl4030_wdt twl4030_pwrbutton omap_wdt [last unloaded: iommu] [ 70.279785] CPU: 0Not tainted (3.1.0-rc3+ #2) [ 70.284820] PC is at __bug+0x1c/0x28 [ 70.288574] LR is at __bug+0x18/0x28 [ 70.292327] pc : [c0010430]lr : [c001042c]psr: 2013 [ 70.292327] sp : dec75de0 ip : fp : c04b8a48 [ 70.304351] r10: dec1bc00 r9 : r8 : c04c5124 [ 70.309814] r7 : dec7da68 r6 : r5 : r4 : [ 70.316680] r3 : r2 : dec75dd4 r1 : c040182a r0 : 0045 [ 70.323516] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 70.330993] Control: 10c5387d Table: 9fbec019 DAC: 0015 [ 70.337005] Process modprobe (pid: 320, stack limit = 0xdec742f0) [ 70.343383] Stack: (0xdec75de0 to 0xdec76000) [ 70.347961] 5de0: c027d390 0008 c04c51b8 dec1bc00 c04c51b8 c04c5124 dec7da68 [ 70.356536] 5e00: dec78000 bf0e2d04 dec78000 df806f18 dec7e0b8 dec7edd8 [ 70.365112] 5e20: c04b8a7c c04b8a48 c04b8a7c bf0f59ac bf0f59ac 0023 001c [ 70.373687] 5e40: c0212c7c c0212c68 c0211c00 c04b8a48 c04b8a7c bf0f59ac [ 70.382263] 5e60: c0211d1c bf0f59ac dec75e78 c0211cbc
Re: omap3isp and tvp5150 hangs
On 2011-08-26 04:42, Enrico wrote: Hi, i need some help to debug a kernel hang on an igep board (+ expansion) when using omap3-isp and tvp5150 video capture. Kernel version is mainline 3.0.1 When i modprobe omap3-isp (after iommu2) the device is correctly recognized: root@igep0020:~# modprobe omap3-isp [ 122.162200] Linux video capture interface: v2.00 [ 122.183319] _regulator_get: omap3isp supply VDD_CSIPHY1 not found, using dummy regulator [ 122.192413] _regulator_get: omap3isp supply VDD_CSIPHY2 not found, using dummy regulator [ 122.201416] omap3isp omap3isp: Revision 2.0 found [ 122.206390] omap-iommu omap-iommu.0: isp: version 1.1 [ 122.262359] tvp5150 2-005c: chip found @ 0xb8 (OMAP I2C adapter) [ 122.363830] tvp5150 2-005c: *** unknown tvp5151 chip detected. [ 122.369964] tvp5150 2-005c: *** Rom ver is 1.0 but then it immediatly hangs. Sysrq show regs: I found that this driver is not compatible with the [new] v4l2_subdev setup. In particular, it does not define any pads and the call to media_entity_create_link() in omap3isp/isp.c:1803 fires a BUG_ON() for this condition. [ 125.420349] Pid: 310, comm: modprobe [ 125.425170] CPU: 0Not tainted (3.0.1+ #22) [ 125.429931] PC is at media_entity_create_link+0x3c/0xe8 [ 125.435485] LR is at isp_probe+0x770/0x97c [omap3_isp] [ 125.440887] pc : [c03420b8]lr : [bf0ddd80]psr: 6013 [ 125.440887] sp : de405de8 ip : fp : c0615998 [ 125.452911] r10: de468800 r9 : r8 : c062f088 [ 125.458374] r7 : deefdc78 r6 : r5 : r4 : [ 125.465240] r3 : r2 : deefdc78 r1 : r0 : de468800 [ 125.472076] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 125.479553] Control: 10c5387d Table: 9e418019 DAC: 0015 Since i had to manually edit default u-boot mux data for some pins, can you confirm this is the right setup? Don't look at the comments because for now i didn't update them to match mux config. CAM_WEN and CAM_STROBE are used for reset/power down and are configured as gpios. MUX_VAL(CP(CAM_HS),(IEN | PTU | EN | M0)) /* GPIO_94 - PDN (Rev. B) */\ MUX_VAL(CP(CAM_VS),(IEN | PTU | EN | M0)) /* GPIO_95 - RESET_N_W (Rev. B) */\ MUX_VAL(CP(CAM_XCLKA), (IDIS | PTD | DIS | M0)) /* CAM_XCLKA */\ MUX_VAL(CP(CAM_PCLK), (IEN | PTU | EN | M0)) /* CAM_PCLK */\ MUX_VAL(CP(CAM_FLD),(IEN | PTD | DIS | M0)) /* GPIO_98 */\ MUX_VAL(CP(CAM_XCLKB), (IDIS | PTD | DIS | M0)) /* CAM_XCLKB */\ MUX_VAL(CP(CAM_D0),(IEN | PTD | DIS | M0)) /* GPIO_99 */\ MUX_VAL(CP(CAM_D1),(IEN | PTD | DIS | M0)) /* GPIO_100 */\ MUX_VAL(CP(CAM_D2),(IEN | PTD | DIS | M0)) /* CAM_D2*/\ MUX_VAL(CP(CAM_D3),(IEN | PTD | DIS | M0)) /* CAM_D3*/\ MUX_VAL(CP(CAM_D4),(IEN | PTD | DIS | M0)) /* CAM_D4*/\ MUX_VAL(CP(CAM_D5),(IEN | PTD | DIS | M0)) /* CAM_D5*/\ MUX_VAL(CP(CAM_D6),(IEN | PTD | DIS | M0)) /* GPIO_105 - RF_CTRL */\ MUX_VAL(CP(CAM_D7),(IEN | PTD | DIS | M0)) /* GPIO_106 - RF_STANDBY */\ MUX_VAL(CP(CAM_D8),(IEN | PTD | DIS | M0)) /* GPIO_107 - RF_INT */\ MUX_VAL(CP(CAM_D9),(IEN | PTD | DIS | M0)) /* GPIO_108 - RF_SYNCB*/\ MUX_VAL(CP(CAM_D10), (IEN | PTD | DIS | M0)) /* CAM_D10 */\ MUX_VAL(CP(CAM_D11), (IEN | PTD | DIS | M0)) /* CAM_D11 */\ I just tried it also with kernel 3.1.0-rc3+ from tmlind repository, it doesn't hang but it segfaults with: [ 70.227844] kernel BUG at drivers/media/media-entity.c:346! [ 70.239471] Unable to handle kernel NULL pointer dereference at virtual address [ 70.248046] pgd = dfbec000 [ 70.250885] [] *pgd=9eeb4831, *pte=, *ppte= [ 70.257476] Internal error: Oops: 817 [#1] [ 70.261779] Modules linked in: tvp5150 omap3_isp(+) v4l2_common videodev iovmm iommu2 iommu libertas_sdio libertas cfg80211 rfkill twl4030_wdt twl4030_pwrbutton omap_wdt [last unloaded: iommu] [ 70.279785] CPU: 0Not tainted (3.1.0-rc3+ #2) [ 70.284820] PC is at __bug+0x1c/0x28 [ 70.288574] LR is at __bug+0x18/0x28 [ 70.292327] pc : [c0010430]lr : [c001042c]psr: 2013 [ 70.292327] sp : dec75de0 ip : fp : c04b8a48 [ 70.304351] r10: dec1bc00 r9 : r8 : c04c5124 [ 70.309814] r7 : dec7da68 r6 : r5 : r4 : [ 70.316680] r3 : r2 : dec75dd4 r1 : c040182a r0 : 0045 [ 70.323516] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 70.330993] Control: 10c5387d Table: 9fbec019 DAC: 0015 [ 70.337005] Process modprobe (pid: 320, stack limit = 0xdec742f0) [ 70.343383] Stack: (0xdec75de0 to 0xdec76000) [ 70.347961] 5de0: c027d390 0008 c04c51b8 dec1bc00 c04c51b8 c04c5124 dec7da68 [ 70.356536] 5e00: dec78000 bf0e2d04 dec78000 df806f18 dec7e0b8 dec7edd8
Re: Is DVB ioctl FE_SET_FRONTEND broken?
--- On Fri, 26/8/11, Andreas Oberritter o...@linuxtv.org wrote: I first thought that you were talking about a regression in Linux 3.0.x. Heh, yes and no. I am talking about a regression that I am definitely seeing in 3.0.x. However, I cannot say which kernel the problem first appeared in. This initial event with status=0 exists since 2002. It's used to notify a new tuning operation to the event listener. http://www.linuxtv.org/cgi-bin/viewvc.cgi/DVB/driver/dvb_frontend.c?revision=1.6.2.30view=markup OK, that's different. I've only noticed this regression because xine has started having trouble using a brand new DVB adapter. Debugging the problem has shown that the first event received after a FE_SET_FRONTEND ioctl() has frequency == 0, which is considered an error. Reading the documentation for FE_SET_FRONTEND lead me to believe that it would send only a single event once tuning had completed, which is not what the code does. It's not my code and my patch doesn't create any new event. Those patches don't, no. I was assuming that you were patching code that you had patched earlier. My bad, it seems. Your example code can't work. You need to call FE_GET_EVENT or FE_READ_STATUS. And that's why I only called it pseudocode :-). So I'm going to say No, your patches don't restore the old behaviour. Yes. The patch is restoring a different old behaviour. The behaviour you're referring to has never been in the kernel. ;-) Yikes! Documentation bug, anyone? Cheers, Chris -- 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
[RFCv2 PATCH 0/8] Add V4L2_CTRL_FLAG_VOLATILE and change volatile autocluster handling.
This is the second patch for this. The first is here: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/36650 This second version changes the pwc code as suggested by Hans de Goede and it adds documentation. The v4l2-ctrls.c code has also been improved to avoid unnecessary calls to update_from_auto_cluster(). Thanks to Hans de Goede for pointing me in the right direction. If there are no additional comments, then I will make a pull request early next week. This will also be the basis for converting soc-camera to the control framework. Regards, Hans -- 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
[RFCv2 PATCH 1/8] videodev2.h: add V4L2_CTRL_FLAG_VOLATILE.
From: Hans Verkuil hans.verk...@cisco.com
Add a new VOLATILE control flag that is set for volatile controls.
That way applications know whether the value of the control is volatile
(i.e. can change continuously) or not.
Until now this was an internal property, but it is useful to know in
userspace as well.
A typical use case is the gain value when autogain is on. In that case the
hardware will continuously adjust the gain based various environmental
factors.
This patch just adds and documents the flag, it's not yet used.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/DocBook/media/v4l/compat.xml |8
Documentation/DocBook/media/v4l/v4l2.xml |9 -
.../DocBook/media/v4l/vidioc-queryctrl.xml |9 +
include/linux/videodev2.h |1 +
4 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/compat.xml
b/Documentation/DocBook/media/v4l/compat.xml
index ce1004a..91410b6 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2370,6 +2370,14 @@ that used it. It was originally scheduled for removal in
2.6.35.
/listitem
/orderedlist
/section
+section
+ titleV4L2 in Linux 3.2/title
+ orderedlist
+listitem
+ paraV4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls
to userspace./para
+/listitem
+ /orderedlist
+/section
section id=other
titleRelation of V4L2 to other Linux multimedia APIs/title
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml
b/Documentation/DocBook/media/v4l/v4l2.xml
index 0d05e87..40132c2 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the
history chapter
applications. --
revision
+ revnumber3.2/revnumber
+ date2011-08-26/date
+ authorinitialshv/authorinitials
+ revremarkAdded V4L2_CTRL_FLAG_VOLATILE./revremark
+ /revision
+
+ revision
revnumber3.1/revnumber
date2011-06-27/date
authorinitialsmcc, po, hv/authorinitials
@@ -410,7 +417,7 @@ and discussions on the V4L mailing list./revremark
/partinfo
titleVideo for Linux Two API Specification/title
- subtitleRevision 3.1/subtitle
+ subtitleRevision 3.2/subtitle
chapter id=common
sub-common;
diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
index 677ea64..0ac0057 100644
--- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
@@ -406,6 +406,15 @@ flag is typically present for relative controls or action
controls where
writing a value will cause the device to carry out a given action
(eg; motor control) but no meaningful value can be returned./entry
/row
+ row
+ entryconstantV4L2_CTRL_FLAG_VOLATILE/constant/entry
+ entry0x0080/entry
+ entryThis control is volatile, which means that the value of the
control
+changes continuously. A typical example would be the current gain value if the
device
+is in auto-gain mode. In such a case the hardware calculates the gain value
based on
+the lighting conditions which can change over time. Note that setting a new
value for
+a volatile control will have no effect. The new value will just be
ignored./entry
+ /row
/tbody
/tgroup
/table
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..c027766 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1082,6 +1082,7 @@ struct v4l2_querymenu {
#define V4L2_CTRL_FLAG_INACTIVE0x0010
#define V4L2_CTRL_FLAG_SLIDER 0x0020
#define V4L2_CTRL_FLAG_WRITE_ONLY 0x0040
+#define V4L2_CTRL_FLAG_VOLATILE0x0080
/* Query flag, to be ORed with the control ID */
#define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
--
1.7.5.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
[RFCv2 PATCH 3/8] v4l2-ctrls: implement new volatile autocluster scheme.
From: Hans Verkuil hans.verk...@cisco.com
The problem tackled in this patch is how to handle volatile autoclusters
correctly. A volatile autocluster is a cluster of related controls where one
control is the control that toggles between manual and auto mode and the other
controls are the values for the manual mode. For example autogain and gain,
autoexposure and exposure, etc.
If the hardware lets you read out the automatically calculated manual values
while in automode, then those manual controls should be marked volatile.
E.g.: if autogain is on, and the hardware allows you to read out the current
gain value as calculated by the autogain circuitry, then you would mark the
gain control as volatile (i.e. continuously changing).
The question in such use cases is what to do when switching from the auto
mode to the manual mode. Should we switch to the last set manual values or
should the volatile values be copied and used as the initial manual values.
For example: suppose the mode is manual gain and gain is set to 5. Then
autogain is turned on and the gain is set by the hardware to 2. Finally
the user switches back to manual gain. What should the gain be? 2 or 5?
After a long discussion the decisions was made to keep the last value as
calculated by the auto mode (so 2 in the example above).
The reason is that webcams that do such things will adapt themselves to
the current light conditions and when you switch back to manual mode you
expect that you keep the same picture. If you would switch back to old
manual values, then that would give you a suddenly different picture,
which is jarring for the user.
Additionally, this would be difficult to implement in applications that
store and restore the control values at application exit and start.
If you want to keep the old manual values when you switch from auto to
manual, then there would have to be a way for applications to get hold
of those old values while in auto mode, but there isn't.
So this patch will do all the heavy lifting in v4l2-ctrls.c: if you go
from auto mode to manual mode and the manual controls are volatile, then
g_volatile_ctrl will be called to get the current values for the manual
controls before switching to manual mode.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 74 +
include/media/v4l2-ctrls.h |3 ++
2 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 1667621..fc8666a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -937,9 +937,14 @@ static void new_to_cur(struct v4l2_fh *fh, struct
v4l2_ctrl *ctrl,
break;
}
if (update_inactive) {
- ctrl-flags = ~V4L2_CTRL_FLAG_INACTIVE;
- if (!is_cur_manual(ctrl-cluster[0]))
+ /* Note: update_inactive can only be true for auto clusters. */
+ ctrl-flags =
+ ~(V4L2_CTRL_FLAG_INACTIVE | V4L2_CTRL_FLAG_VOLATILE);
+ if (!is_cur_manual(ctrl-cluster[0])) {
ctrl-flags |= V4L2_CTRL_FLAG_INACTIVE;
+ if (ctrl-cluster[0]-has_volatiles)
+ ctrl-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ }
}
if (changed || update_inactive) {
/* If a control was changed that was not one of the controls
@@ -1489,6 +1494,7 @@ EXPORT_SYMBOL(v4l2_ctrl_add_handler);
/* Cluster controls */
void v4l2_ctrl_cluster(unsigned ncontrols, struct v4l2_ctrl **controls)
{
+ bool has_volatiles = false;
int i;
/* The first control is the master control and it must not be NULL */
@@ -1498,8 +1504,11 @@ void v4l2_ctrl_cluster(unsigned ncontrols, struct
v4l2_ctrl **controls)
if (controls[i]) {
controls[i]-cluster = controls;
controls[i]-ncontrols = ncontrols;
+ if (controls[i]-flags V4L2_CTRL_FLAG_VOLATILE)
+ has_volatiles = true;
}
}
+ controls[0]-has_volatiles = has_volatiles;
}
EXPORT_SYMBOL(v4l2_ctrl_cluster);
@@ -1507,18 +1516,21 @@ void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct
v4l2_ctrl **controls,
u8 manual_val, bool set_volatile)
{
struct v4l2_ctrl *master = controls[0];
- u32 flag;
+ u32 flag = 0;
int i;
v4l2_ctrl_cluster(ncontrols, controls);
WARN_ON(ncontrols = 1);
WARN_ON(manual_val master-minimum || manual_val master-maximum);
+ WARN_ON(set_volatile !has_op(master, g_volatile_ctrl));
master-is_auto = true;
+ master-has_volatiles = set_volatile;
master-manual_mode_value = manual_val;
master-flags |= V4L2_CTRL_FLAG_UPDATE;
- flag = is_cur_manual(master) ? 0 :
[RFCv2 PATCH 2/8] v4l2-ctrls: replace is_volatile with V4L2_CTRL_FLAG_VOLATILE.
From: Hans Verkuil hans.verk...@cisco.com
With the new flag there is no need anymore to have a separate is_volatile
field. Modify all users to use the new flag.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/video4linux/v4l2-controls.txt | 13 -
drivers/media/radio/radio-wl1273.c |2 +-
drivers/media/radio/wl128x/fmdrv_v4l2.c |2 +-
drivers/media/video/adp1653.c |2 +-
drivers/media/video/pwc/pwc-v4l.c | 10 +++---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c |4 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c |2 +-
drivers/media/video/saa7115.c |2 +-
drivers/media/video/v4l2-ctrls.c| 36 --
include/media/v4l2-ctrls.h | 12 +
10 files changed, 36 insertions(+), 49 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index 9346fc8..f92ee30 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -285,11 +285,11 @@ implement g_volatile_ctrl like this:
Note that you use the 'new value' union as well in g_volatile_ctrl. In general
controls that need to implement g_volatile_ctrl are read-only controls.
-To mark a control as volatile you have to set the is_volatile flag:
+To mark a control as volatile you have to set V4L2_CTRL_FLAG_VOLATILE:
ctrl = v4l2_ctrl_new_std(sd-ctrl_handler, ...);
if (ctrl)
- ctrl-is_volatile = 1;
+ ctrl-flags |= V4L2_CTRL_FLAG_VOLATILE;
For try/s_ctrl the new values (i.e. as passed by the user) are filled in and
you can modify them in try_ctrl or set them in s_ctrl. The 'cur' union
@@ -367,8 +367,7 @@ Driver specific controls can be created using
v4l2_ctrl_new_custom():
The last argument is the priv pointer which can be set to driver-specific
private data.
-The v4l2_ctrl_config struct also has fields to set the is_private and
is_volatile
-flags.
+The v4l2_ctrl_config struct also has a field to set the is_private flag.
If the name field is not set, then the framework will assume this is a standard
control and will fill in the name, type and flags fields accordingly.
@@ -506,8 +505,8 @@ operation should return the value that the hardware's
automatic mode set up
automatically.
If the cluster is put in manual mode, then the manual controls should become
-active again and the is_volatile flag should be ignored (so g_volatile_ctrl is
-no longer called while in manual mode).
+active again and V4L2_CTRL_FLAG_VOLATILE should be ignored (so g_volatile_ctrl
+is no longer called while in manual mode).
Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since
changing that control affects the control flags of the manual controls.
@@ -520,7 +519,7 @@ void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct
v4l2_ctrl **controls,
The first two arguments are identical to v4l2_ctrl_cluster. The third argument
tells the framework which value switches the cluster into manual mode. The
-last argument will optionally set the is_volatile flag for the non-auto
controls.
+last argument will optionally set V4L2_CTRL_FLAG_VOLATILE for the non-auto
controls.
The first control of the cluster is assumed to be the 'auto' control.
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 46cacf8..6d1e4e7 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -2109,7 +2109,7 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
V4L2_CID_TUNE_ANTENNA_CAPACITOR,
0, 255, 1, 255);
if (ctrl)
- ctrl-is_volatile = 1;
+ ctrl-flags |= V4L2_CTRL_FLAG_VOLATILE;
if (radio-ctrl_handler.error) {
r = radio-ctrl_handler.error;
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
index 8c0e192..54b34e5 100644
--- a/drivers/media/radio/wl128x/fmdrv_v4l2.c
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -557,7 +557,7 @@ int fm_v4l2_init_video_device(struct fmdev *fmdev, int
radio_nr)
255, 1, 255);
if (ctrl)
- ctrl-is_volatile = 1;
+ ctrl-flags |= V4L2_CTRL_FLAG_VOLATILE;
return 0;
}
diff --git a/drivers/media/video/adp1653.c b/drivers/media/video/adp1653.c
index 279d75d..d0e8ac1 100644
--- a/drivers/media/video/adp1653.c
+++ b/drivers/media/video/adp1653.c
@@ -258,7 +258,7 @@ static int adp1653_init_controls(struct adp1653_flash
*flash)
if (flash-ctrls.error)
return flash-ctrls.error;
- fault-is_volatile = 1;
+ fault-flags |= V4L2_CTRL_FLAG_VOLATILE;
flash-subdev.ctrl_handler = flash-ctrls;
return 0;
diff --git a/drivers/media/video/pwc/pwc-v4l.c
[RFCv2 PATCH 6/8] vivi: add support for VIDIOC_LOG_STATUS.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/vivi.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index a848bd2..da6149c 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -948,6 +948,14 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type i)
return vb2_streamoff(dev-vb_vidq, i);
}
+static int vidioc_log_status(struct file *file, void *priv)
+{
+ struct vivi_dev *dev = video_drvdata(file);
+
+ v4l2_ctrl_handler_log_status(dev-ctrl_handler, dev-v4l2_dev.name);
+ return 0;
+}
+
static int vidioc_s_std(struct file *file, void *priv, v4l2_std_id *i)
{
return 0;
@@ -1191,6 +1199,7 @@ static const struct v4l2_ioctl_ops vivi_ioctl_ops = {
.vidioc_s_input = vidioc_s_input,
.vidioc_streamon = vidioc_streamon,
.vidioc_streamoff = vidioc_streamoff,
+ .vidioc_log_status= vidioc_log_status,
.vidioc_subscribe_event = vidioc_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
--
1.7.5.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
[RFCv2 PATCH 4/8] v4l2-controls.txt: update auto cluster documentation.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/video4linux/v4l2-controls.txt | 34 +- 1 files changed, 12 insertions(+), 22 deletions(-) diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index f92ee30..26aa057 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt @@ -495,18 +495,20 @@ Handling autogain/gain-type Controls with Auto Clusters A common type of control cluster is one that handles 'auto-foo/foo'-type controls. Typical examples are autogain/gain, autoexposure/exposure, -autowhitebalance/red balance/blue balance. In all cases you have one controls +autowhitebalance/red balance/blue balance. In all cases you have one control that determines whether another control is handled automatically by the hardware, or whether it is under manual control from the user. If the cluster is in automatic mode, then the manual controls should be -marked inactive. When the volatile controls are read the g_volatile_ctrl -operation should return the value that the hardware's automatic mode set up -automatically. +marked inactive and volatile. When the volatile controls are read the +g_volatile_ctrl operation should return the value that the hardware's automatic +mode set up automatically. If the cluster is put in manual mode, then the manual controls should become -active again and V4L2_CTRL_FLAG_VOLATILE should be ignored (so g_volatile_ctrl -is no longer called while in manual mode). +active again and the volatile flag is cleared (so g_volatile_ctrl is no longer +called while in manual mode). In addition just before switching to manual mode +the current values as determined by the auto mode are copied as the new manual +values. Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since changing that control affects the control flags of the manual controls. @@ -520,6 +522,10 @@ void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls, The first two arguments are identical to v4l2_ctrl_cluster. The third argument tells the framework which value switches the cluster into manual mode. The last argument will optionally set V4L2_CTRL_FLAG_VOLATILE for the non-auto controls. +If it is false, then the manual controls are never volatile. You would typically +use that if the hardware does not give you the option to read back to values as +determined by the auto mode (e.g. if autogain is on, the hardware doesn't allow +you to obtain the current gain value). The first control of the cluster is assumed to be the 'auto' control. @@ -680,16 +686,6 @@ if there are no controls at all. count if nothing was done yet. If it is less than count then only the controls up to error_idx-1 were successfully applied. -3) When attempting to read a button control the framework will return -EACCES -instead of -EINVAL as stated in the spec. It seems to make more sense since -button controls are write-only controls. - -4) Attempting to write to a read-only control will return -EACCES instead of --EINVAL as the spec says. - -5) The spec does not mention what should happen when you try to set/get a -control class controls. The framework will return -EACCES. - Proposals for Extensions @@ -702,9 +698,3 @@ decimal. Useful for e.g. video_mute_yuv. 2) It is possible to mark in the controls array which controls have been successfully written and which failed by for example adding a bit to the control ID. Not sure if it is worth the effort, though. - -3) Trying to set volatile inactive controls should result in -EACCESS. - -4) Add a new flag to mark volatile controls. Any application that wants -to store the state of the controls can then skip volatile inactive controls. -Currently it is not possible to detect such controls. -- 1.7.5.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
[RFCv2 PATCH 7/8] pwc: add support for VIDIOC_LOG_STATUS.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/pwc/pwc-v4l.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pwc/pwc-v4l.c
b/drivers/media/video/pwc/pwc-v4l.c
index d15ae89..bdc369c 100644
--- a/drivers/media/video/pwc/pwc-v4l.c
+++ b/drivers/media/video/pwc/pwc-v4l.c
@@ -1078,6 +1078,14 @@ static int pwc_enum_frameintervals(struct file *file,
void *fh,
return 0;
}
+static int pwc_log_status(struct file *file, void *priv)
+{
+ struct pwc_device *pdev = video_drvdata(file);
+
+ v4l2_ctrl_handler_log_status(pdev-ctrl_handler, PWC_NAME);
+ return 0;
+}
+
static long pwc_default(struct file *file, void *fh, bool valid_prio,
int cmd, void *arg)
{
@@ -1101,6 +1109,7 @@ const struct v4l2_ioctl_ops pwc_ioctl_ops = {
.vidioc_dqbuf = pwc_dqbuf,
.vidioc_streamon= pwc_streamon,
.vidioc_streamoff = pwc_streamoff,
+ .vidioc_log_status = pwc_log_status,
.vidioc_enum_framesizes = pwc_enum_framesizes,
.vidioc_enum_frameintervals = pwc_enum_frameintervals,
.vidioc_default = pwc_default,
--
1.7.5.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
[RFCv2 PATCH 5/8] pwc: switch to the new auto-cluster volatile handling.
From: Hans Verkuil hans.verk...@cisco.com
Now that the auto cluster core changed to a different scheme of how to
handle volatile controls (including how to switch from auto to manual mode)
the pwc code can be simplified to use that new core support.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/pwc/pwc-v4l.c | 127 +++-
1 files changed, 53 insertions(+), 74 deletions(-)
diff --git a/drivers/media/video/pwc/pwc-v4l.c
b/drivers/media/video/pwc/pwc-v4l.c
index b6c20aa..d15ae89 100644
--- a/drivers/media/video/pwc/pwc-v4l.c
+++ b/drivers/media/video/pwc/pwc-v4l.c
@@ -83,6 +83,7 @@ static const struct v4l2_ctrl_config pwc_contour_cfg = {
.id = PWC_CID_CUSTOM(contour),
.type = V4L2_CTRL_TYPE_INTEGER,
.name = Contour,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
.min= 0,
.max= 63,
.step = 1,
@@ -206,8 +207,7 @@ int pwc_init_controls(struct pwc_device *pdev)
pdev-blue_balance = v4l2_ctrl_new_std(hdl, pwc_ctrl_ops,
V4L2_CID_BLUE_BALANCE, 0, 255, 1, def);
- v4l2_ctrl_auto_cluster(3, pdev-auto_white_balance, awb_manual,
- pdev-auto_white_balance-cur.val == awb_auto);
+ v4l2_ctrl_auto_cluster(3, pdev-auto_white_balance, awb_manual, true);
/* autogain, gain */
r = pwc_get_u8_ctrl(pdev, GET_LUM_CTL, AGC_MODE_FORMATTER, def);
@@ -331,12 +331,12 @@ int pwc_init_controls(struct pwc_device *pdev)
pdev-restore_user = v4l2_ctrl_new_custom(hdl, pwc_restore_user_cfg,
NULL);
if (pdev-restore_user)
- pdev-restore_user-flags = V4L2_CTRL_FLAG_UPDATE;
+ pdev-restore_user-flags |= V4L2_CTRL_FLAG_UPDATE;
pdev-restore_factory = v4l2_ctrl_new_custom(hdl,
pwc_restore_factory_cfg,
NULL);
if (pdev-restore_factory)
- pdev-restore_factory-flags = V4L2_CTRL_FLAG_UPDATE;
+ pdev-restore_factory-flags |= V4L2_CTRL_FLAG_UPDATE;
if (!pdev-features FEATURE_MOTOR_PANTILT)
return hdl-error;
@@ -563,8 +563,10 @@ static int pwc_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_AUTO_WHITE_BALANCE:
- if (pdev-color_bal_valid time_before(jiffies,
- pdev-last_color_bal_update + HZ / 4)) {
+ if (pdev-color_bal_valid
+ (pdev-auto_white_balance-val != awb_auto ||
+time_before(jiffies,
+ pdev-last_color_bal_update + HZ / 4))) {
pdev-red_balance-val = pdev-last_red_balance;
pdev-blue_balance-val = pdev-last_blue_balance;
break;
@@ -630,7 +632,7 @@ leave:
static int pwc_set_awb(struct pwc_device *pdev)
{
- int ret = 0;
+ int ret;
if (pdev-auto_white_balance-is_new) {
ret = pwc_set_u8_ctrl(pdev, SET_CHROM_CTL,
@@ -639,52 +641,34 @@ static int pwc_set_awb(struct pwc_device *pdev)
if (ret)
return ret;
- /* Update val when coming from auto or going to a preset */
- if ((pdev-red_balance-flags V4L2_CTRL_FLAG_VOLATILE) ||
- pdev-auto_white_balance-val == awb_indoor ||
- pdev-auto_white_balance-val == awb_outdoor ||
- pdev-auto_white_balance-val == awb_fl) {
- if (!pdev-red_balance-is_new)
- pwc_get_u8_ctrl(pdev, GET_STATUS_CTL,
- READ_RED_GAIN_FORMATTER,
- pdev-red_balance-val);
- if (!pdev-blue_balance-is_new)
- pwc_get_u8_ctrl(pdev, GET_STATUS_CTL,
- READ_BLUE_GAIN_FORMATTER,
- pdev-blue_balance-val);
- }
- if (pdev-auto_white_balance-val == awb_auto) {
- pdev-red_balance-flags |= V4L2_CTRL_FLAG_VOLATILE;
- pdev-blue_balance-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ if (pdev-auto_white_balance-val != awb_manual)
pdev-color_bal_valid = false; /* Force cache update */
- } else {
- pdev-red_balance-flags = ~V4L2_CTRL_FLAG_VOLATILE;
- pdev-blue_balance-flags = ~V4L2_CTRL_FLAG_VOLATILE;
- }
}
+ if (pdev-auto_white_balance-val != awb_manual)
+ return 0;
- if (ret == 0 pdev-red_balance-is_new) {
- if (pdev-auto_white_balance-val != awb_manual)
- return -EBUSY;
+ if
[RFCv2 PATCH 8/8] saa7115: use the new auto cluster support.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/saa7115.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/saa7115.c b/drivers/media/video/saa7115.c
index e443d0d..cee98ea 100644
--- a/drivers/media/video/saa7115.c
+++ b/drivers/media/video/saa7115.c
@@ -793,7 +793,6 @@ static int saa711x_s_ctrl(struct v4l2_ctrl *ctrl)
saa711x_write(sd, R_0F_CHROMA_GAIN_CNTL,
state-gain-val);
else
saa711x_write(sd, R_0F_CHROMA_GAIN_CNTL,
state-gain-val | 0x80);
- v4l2_ctrl_activate(state-gain, !state-agc-val);
break;
default:
@@ -1601,7 +1600,6 @@ static int saa711x_probe(struct i2c_client *client,
V4L2_CID_CHROMA_AGC, 0, 1, 1, 1);
state-gain = v4l2_ctrl_new_std(hdl, saa711x_ctrl_ops,
V4L2_CID_CHROMA_GAIN, 0, 127, 1, 40);
- state-gain-flags |= V4L2_CTRL_FLAG_VOLATILE;
sd-ctrl_handler = hdl;
if (hdl-error) {
int err = hdl-error;
@@ -1610,8 +1608,7 @@ static int saa711x_probe(struct i2c_client *client,
kfree(state);
return err;
}
- state-agc-flags |= V4L2_CTRL_FLAG_UPDATE;
- v4l2_ctrl_cluster(2, state-agc);
+ v4l2_ctrl_auto_cluster(2, state-agc, 0, true);
state-input = -1;
state-output = SAA7115_IPORT_ON;
--
1.7.5.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
Re: Is DVB ioctl FE_SET_FRONTEND broken?
On 26.08.2011 13:31, Chris Rankin wrote: --- On Fri, 26/8/11, Andreas Oberritter o...@linuxtv.org wrote: I first thought that you were talking about a regression in Linux 3.0.x. Heh, yes and no. I am talking about a regression that I am definitely seeing in 3.0.x. However, I cannot say which kernel the problem first appeared in. [...] Debugging the problem has shown that the first event received after a FE_SET_FRONTEND ioctl() has frequency == 0, which is considered an error. OK, this is actually the problem, which the proposed patch tries to address: https://patchwork.kernel.org/patch/1036132/ What you're observing is the stale data mentioned in the patch description. You should definitely try the patch. Yes. The patch is restoring a different old behaviour. The behaviour you're referring to has never been in the kernel. ;-) Yikes! Documentation bug, anyone? Large parts of the documentation haven't been updated since about 10 years, besides some renamed enums and functions here and there, when it was merged into Linux 2.5. Contributions are welcome, of course. Regards, Andreas -- 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 v4 0/5] v4l: extended crop/compose api
Hello Everyone,
This is the fourth version of extended crop/compose RFC. The patch-set
introduces new ioctls to V4L2 APIi for configuration of selection rectangles
like crop and compose areas. Please refer to discussion below for more details
about api development.
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/32152
Changelog:
v3:
- added target for padded buffer
- reduced number of constraint flags to SIZE_LE and SIZE_GE
- removed try flag
- added documentation for selection ioctls
- added documentation for new model of cropping, composing and scaling
- support of selection api for s5p-tv
- fixed returning ioctl's structures on failure
v2:
- reduced number of hints and its semantics to be more practical and less
restrictive
- combined EXTCROP and COMPOSE ioctls into VIDIOC_{S/G}_SELECTION
- introduced crop and compose targets
- introduced try flag that prevents passing configuration to a hardware
- added usage examples
Tomasz Stanislawski (5):
[media] v4l: add support for selection api
[media] v4l: add documentation for selection API
[media] v4l: simulate old crop API using extended crop/compose API
[media] v4l: fix copying ioctl results on failure
[media] v4l: s5p-tv: mixer: add support for selection API
Documentation/DocBook/media/constraints.png.b64| 134 +
Documentation/DocBook/media/selection.png.b64 | 2937
Documentation/DocBook/media/v4l/common.xml |4 +-
Documentation/DocBook/media/v4l/selection-api.xml | 278 ++
Documentation/DocBook/media/v4l/v4l2.xml |1 +
.../DocBook/media/v4l/vidioc-g-selection.xml | 283 ++
drivers/media/video/s5p-tv/mixer.h | 14 +-
drivers/media/video/s5p-tv/mixer_grp_layer.c | 157 +-
drivers/media/video/s5p-tv/mixer_video.c | 329 ++-
drivers/media/video/s5p-tv/mixer_vp_layer.c| 108 +-
drivers/media/video/v4l2-compat-ioctl32.c |2 +
drivers/media/video/v4l2-ioctl.c | 116 +-
include/linux/videodev2.h | 27 +
include/media/v4l2-ioctl.h |4 +
14 files changed, 4186 insertions(+), 208 deletions(-)
create mode 100644 Documentation/DocBook/media/constraints.png.b64
create mode 100644 Documentation/DocBook/media/selection.png.b64
create mode 100644 Documentation/DocBook/media/v4l/selection-api.xml
create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-selection.xml
--
1.7.6
--
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 4/5] [media] v4l: fix copying ioctl results on failure
This patch fix the handling of data passed to V4L2 ioctls. The content of the structures is not copied if the ioctl fails. It blocks ability to obtain any information about occurred error other then errno code. This patch fix this issue. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/v4l2-ioctl.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 543405b..9f54114 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -2490,8 +2490,6 @@ video_usercopy(struct file *file, unsigned int cmd, unsigned long arg, err = -EFAULT; goto out_array_args; } - if (err 0) - goto out; out_array_args: /* Copy results into user buffer */ -- 1.7.6 -- 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 1/5] [media] v4l: add support for selection api
This patch introduces new api for a precise control of cropping and composing
features for video devices. The new ioctls are VIDIOC_S_SELECTION and
VIDIOC_G_SELECTION.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |2 ++
drivers/media/video/v4l2-ioctl.c | 28
include/linux/videodev2.h | 27 +++
include/media/v4l2-ioctl.h|4
4 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 61979b7..f3b9d15 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -927,6 +927,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_CROPCAP:
case VIDIOC_G_CROP:
case VIDIOC_S_CROP:
+ case VIDIOC_G_SELECTION:
+ case VIDIOC_S_SELECTION:
case VIDIOC_G_JPEGCOMP:
case VIDIOC_S_JPEGCOMP:
case VIDIOC_QUERYSTD:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 002ce13..6e02b45 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -225,6 +225,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_CROPCAP)] = VIDIOC_CROPCAP,
[_IOC_NR(VIDIOC_G_CROP)] = VIDIOC_G_CROP,
[_IOC_NR(VIDIOC_S_CROP)] = VIDIOC_S_CROP,
+ [_IOC_NR(VIDIOC_G_SELECTION)] = VIDIOC_G_SELECTION,
+ [_IOC_NR(VIDIOC_S_SELECTION)] = VIDIOC_S_SELECTION,
[_IOC_NR(VIDIOC_G_JPEGCOMP)] = VIDIOC_G_JPEGCOMP,
[_IOC_NR(VIDIOC_S_JPEGCOMP)] = VIDIOC_S_JPEGCOMP,
[_IOC_NR(VIDIOC_QUERYSTD)] = VIDIOC_QUERYSTD,
@@ -1714,6 +1716,32 @@ static long __video_do_ioctl(struct file *file,
ret = ops-vidioc_s_crop(file, fh, p);
break;
}
+ case VIDIOC_G_SELECTION:
+ {
+ struct v4l2_selection *p = arg;
+
+ if (!ops-vidioc_g_selection)
+ break;
+
+ dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
+
+ ret = ops-vidioc_g_selection(file, fh, p);
+ if (!ret)
+ dbgrect(vfd, , p-r);
+ break;
+ }
+ case VIDIOC_S_SELECTION:
+ {
+ struct v4l2_selection *p = arg;
+
+ if (!ops-vidioc_s_selection)
+ break;
+ dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
+ dbgrect(vfd, , p-r);
+
+ ret = ops-vidioc_s_selection(file, fh, p);
+ break;
+ }
case VIDIOC_CROPCAP:
{
struct v4l2_cropcap *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..fad4fb3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,29 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
+
+enum v4l2_sel_target {
+ V4L2_SEL_CROP_ACTIVE = 0,
+ V4L2_SEL_CROP_DEFAULT = 1,
+ V4L2_SEL_CROP_BOUNDS = 2,
+ V4L2_SEL_COMPOSE_ACTIVE = 256 + 0,
+ V4L2_SEL_COMPOSE_DEFAULT = 256 + 1,
+ V4L2_SEL_COMPOSE_BOUNDS = 256 + 2,
+ V4L2_SEL_COMPOSE_PADDED = 256 + 3,
+};
+
+struct v4l2_selection {
+ enum v4l2_buf_type type;
+ enum v4l2_sel_targettarget;
+ __u32 flags;
+ struct v4l2_rectr;
+ __u32 reserved[9];
+};
+
+
/*
* A N A L O G V I D E O S T A N D A R D
*/
@@ -2182,6 +2205,10 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
+/* Experimental crop/compose API */
+#define VIDIOC_G_SELECTION _IOWR('V', 92, struct v4l2_selection)
+#define VIDIOC_S_SELECTION _IOWR('V', 93, struct v4l2_selection)
+
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index dd9f1e7..2c0396b 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -194,6 +194,10 @@ struct v4l2_ioctl_ops {
struct v4l2_crop *a);
int (*vidioc_s_crop) (struct file *file, void *fh,
struct v4l2_crop *a);
+ int (*vidioc_g_selection) (struct file *file, void *fh,
+ struct
[PATCH 3/5] [media] v4l: simulate old crop API using extended crop/compose API
This patch allows new video drivers to work correctly with applications that
use the old-style crop API. The old crop ioctl is simulated by using selection
callbacks.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ioctl.c | 86 +
1 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 6e02b45..543405b 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1696,11 +1696,31 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops-vidioc_g_crop)
+ dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
+
+ if (ops-vidioc_g_crop) {
+ ret = ops-vidioc_g_crop(file, fh, p);
+ } else
+ if (ops-vidioc_g_selection) {
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p-type,
+ .target = V4L2_SEL_CROP_ACTIVE,
+ };
+
+ /* crop means compose for output devices */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_ACTIVE;
+
+ ret = ops-vidioc_g_selection(file, fh, s);
+
+ /* copying results to old structure on success */
+ if (!ret)
+ p-c = s.r;
+ } else {
break;
+ }
- dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
- ret = ops-vidioc_g_crop(file, fh, p);
if (!ret)
dbgrect(vfd, , p-c);
break;
@@ -1709,11 +1729,26 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops-vidioc_s_crop)
- break;
dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
dbgrect(vfd, , p-c);
- ret = ops-vidioc_s_crop(file, fh, p);
+
+ if (ops-vidioc_s_crop) {
+ ret = ops-vidioc_s_crop(file, fh, p);
+ } else
+ if (ops-vidioc_s_selection) {
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p-type,
+ .target = V4L2_SEL_CROP_ACTIVE,
+ .r = p-c,
+ };
+
+ /* crop means compose for output devices */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_ACTIVE;
+
+ ret = ops-vidioc_s_selection(file, fh, s);
+ }
break;
}
case VIDIOC_G_SELECTION:
@@ -1746,12 +1781,43 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_cropcap *p = arg;
- /*FIXME: Should also show v4l2_fract pixelaspect */
- if (!ops-vidioc_cropcap)
+ dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
+ if (ops-vidioc_cropcap) {
+ ret = ops-vidioc_cropcap(file, fh, p);
+ } else
+ if (ops-vidioc_g_selection) {
+ struct v4l2_selection s = { .type = p-type };
+ struct v4l2_rect bounds;
+
+ /* obtaining bounds */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_BOUNDS;
+ else
+ s.target = V4L2_SEL_CROP_BOUNDS;
+ ret = ops-vidioc_g_selection(file, fh, s);
+ if (ret)
+ break;
+ bounds = s.r;
+
+ /* obtaining defrect */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_DEFAULT;
+ else
+ s.target = V4L2_SEL_CROP_DEFAULT;
+ ret = ops-vidioc_g_selection(file, fh, s);
+ if (ret)
+ break;
+
+ /* storing results */
+ p-bounds = bounds;
+ p-defrect = s.r;
+ p-pixelaspect.numerator = 1;
+ p-pixelaspect.denominator = 1;
+ } else {
break;
+
[PATCH 5/5] [media] v4l: s5p-tv: mixer: add support for selection API
This patch add support for V4L2 selection API to s5p-tv driver. Moreover it
removes old API for cropping. Old applications would still work because the
crop ioctls are emulated using the selection API.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-tv/mixer.h | 14 +-
drivers/media/video/s5p-tv/mixer_grp_layer.c | 157 ++---
drivers/media/video/s5p-tv/mixer_video.c | 329 -
drivers/media/video/s5p-tv/mixer_vp_layer.c | 108 ++---
4 files changed, 413 insertions(+), 195 deletions(-)
diff --git a/drivers/media/video/s5p-tv/mixer.h
b/drivers/media/video/s5p-tv/mixer.h
index e224224..dc71e59 100644
--- a/drivers/media/video/s5p-tv/mixer.h
+++ b/drivers/media/video/s5p-tv/mixer.h
@@ -86,6 +86,17 @@ struct mxr_crop {
unsigned int field;
};
+/** stages of geometry operations */
+enum mxr_geometry_stage {
+ MXR_GEOMETRY_SINK,
+ MXR_GEOMETRY_COMPOSE,
+ MXR_GEOMETRY_CROP,
+ MXR_GEOMETRY_SOURCE,
+};
+
+/* flag indicating that offset should be 0 */
+#define MXR_NO_OFFSET 0x8000
+
/** description of transformation from source to destination image */
struct mxr_geometry {
/** cropping for source image */
@@ -135,7 +146,8 @@ struct mxr_layer_ops {
/** streaming stop/start */
void (*stream_set)(struct mxr_layer *, int);
/** adjusting geometry */
- void (*fix_geometry)(struct mxr_layer *);
+ void (*fix_geometry)(struct mxr_layer *,
+ enum mxr_geometry_stage, unsigned long);
};
/** layer instance, a single window and content displayed on output */
diff --git a/drivers/media/video/s5p-tv/mixer_grp_layer.c
b/drivers/media/video/s5p-tv/mixer_grp_layer.c
index 58f0ba4..882ad7d 100644
--- a/drivers/media/video/s5p-tv/mixer_grp_layer.c
+++ b/drivers/media/video/s5p-tv/mixer_grp_layer.c
@@ -101,47 +101,132 @@ static void mxr_graph_format_set(struct mxr_layer *layer)
layer-fmt, layer-geo);
}
-static void mxr_graph_fix_geometry(struct mxr_layer *layer)
+static inline unsigned int closest(unsigned int x, unsigned int a,
+ unsigned int b, unsigned long flags)
+{
+ unsigned int mid = (a + b) / 2;
+
+ /* choosing closest value with constraints according to table:
+* -+-+-+-+---+
+* flags| 0 | LE | GE | LE|GE |
+* -+-+-+-+---+
+* x = a | a | a | a | a |
+* a x = mid | a | a | b | a |
+* mid x b | b | a | b | b |
+* b = x | b | b | b | b |
+* -+-+-+-+---+
+*/
+
+ /* remove all non-constraint flags */
+ flags = V4L2_SEL_SIZE_LE | V4L2_SEL_SIZE_GE;
+
+ if (x = a)
+ return a;
+ if (x = b)
+ return b;
+ if (flags == V4L2_SEL_SIZE_LE)
+ return a;
+ if (flags == V4L2_SEL_SIZE_GE)
+ return b;
+ if (x = mid)
+ return a;
+ return b;
+}
+
+static inline unsigned int do_center(unsigned int center,
+ unsigned int size, unsigned int upper, unsigned int flags)
+{
+ unsigned int lower;
+
+ if (flags MXR_NO_OFFSET)
+ return 0;
+
+ lower = center - min(center, size / 2);
+ return min(lower, upper - size);
+}
+
+static void mxr_graph_fix_geometry(struct mxr_layer * layer,
+ enum mxr_geometry_stage stage, unsigned long flags)
{
struct mxr_geometry *geo = layer-geo;
+ struct mxr_crop *src = geo-src;
+ struct mxr_crop *dst = geo-dst;
+ unsigned int x_center, y_center;
- /* limit to boundary size */
- geo-src.full_width = clamp_val(geo-src.full_width, 1, 32767);
- geo-src.full_height = clamp_val(geo-src.full_height, 1, 2047);
- geo-src.width = clamp_val(geo-src.width, 1, geo-src.full_width);
- geo-src.width = min(geo-src.width, 2047U);
- /* not possible to crop of Y axis */
- geo-src.y_offset = min(geo-src.y_offset, geo-src.full_height - 1);
- geo-src.height = geo-src.full_height - geo-src.y_offset;
- /* limitting offset */
- geo-src.x_offset = min(geo-src.x_offset,
- geo-src.full_width - geo-src.width);
-
- /* setting position in output */
- geo-dst.width = min(geo-dst.width, geo-dst.full_width);
- geo-dst.height = min(geo-dst.height, geo-dst.full_height);
-
- /* Mixer supports only 1x and 2x scaling */
- if (geo-dst.width = 2 * geo-src.width) {
- geo-x_ratio = 1;
- geo-dst.width = 2 * geo-src.width;
- } else {
- geo-x_ratio = 0;
- geo-dst.width = geo-src.width;
- }
+ switch (stage) {
- if (geo-dst.height = 2 * geo-src.height) {
- geo-y_ratio = 1;
-
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? -- Regards, Laurent Pinchart -- 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: Satelco DVBS CAM initialisation failing
I think I have located the problem and I would like to get your opinion
about it.
I have patch my budget-av driver to increase a sleep during cam reset
and it seems to solve a problem of initialisation with two different CAM
model (one NEOTION and one SmartDTV) on all my machine.
Because I'm not really aware about how this driver works I would like to
get your opinion about this change and know if it is as harmless as it
looks like. I've done several test over several machine with my Satelco
EasyWatch DVBS + 4 different CAM model and everything seems to be OK
(Aston Viacess Pro, Neotion Viacess Pro, SmarDTV irDeto, PowerCam, Aston
Conax Pro)
-
Here is my modification :
static int ciintf_slot_reset(struct dvb_ca_en50221 *ca, int slot)
{
struct budget_av *budget_av = (struct budget_av *) ca-data;
struct saa7146_dev *saa = budget_av-budget.dev;
if (slot != 0)
return -EINVAL;
dprintk(1, ciintf_slot_reset\n);
budget_av-slot_status = SLOTSTATUS_RESET;
saa7146_setgpio(saa, 2, SAA7146_GPIO_OUTHI); /* disable card */
saa7146_setgpio(saa, 0, SAA7146_GPIO_OUTHI); /* Vcc off */
msleep(2);
saa7146_setgpio(saa, 0, SAA7146_GPIO_OUTLO); /* Vcc on */
+msleep(750);
-msleep(20); /* 20 ms Vcc settling time */
saa7146_setgpio(saa, 2, SAA7146_GPIO_OUTLO); /* enable card */
ttpci_budget_set_video_port(saa, BUDGET_VIDEO_PORTB);
msleep(20);
/* reinitialise the frontend if necessary */
if (budget_av-reinitialise_demod)
dvb_frontend_reinitialise(budget_av-budget.dvb_frontend);
return 0;
}
-
Thanks for your help and yours comments,
Stéphane Railhet
--
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: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: Hi Mauro, On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. While I am not opposed to creating such userspace maps I also think it is a bit of a poor-man's solution. In particular I am worried that we get a lot of those mappings (just think of ivtv with its 8 or 9 devices). I can think of: webcam, tv, compressed (mpeg), tv-out, compressed-out, mem2mem. But a 'tv' node might also be able to handle compressed video (depending on how the hardware is organized), so how do you handle that? It can all be solved, I'm sure, but I'm not sure if such userspace mappings will scale that well with the increasing hardware complexity. Regards, Hans -- 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 1/5] [media] v4l: add support for selection api
Hi Tomasz,
Thanks for the patch.
On Friday 26 August 2011 15:06:03 Tomasz Stanislawski wrote:
This patch introduces new api for a precise control of cropping and
composing features for video devices. The new ioctls are
VIDIOC_S_SELECTION and VIDIOC_G_SELECTION.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |2 ++
drivers/media/video/v4l2-ioctl.c | 28
include/linux/videodev2.h |
27 +++ include/media/v4l2-ioctl.h|
4
4 files changed, 61 insertions(+), 0 deletions(-)
[snip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..fad4fb3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,29 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
+
+enum v4l2_sel_target {
+ V4L2_SEL_CROP_ACTIVE = 0,
+ V4L2_SEL_CROP_DEFAULT = 1,
+ V4L2_SEL_CROP_BOUNDS = 2,
+ V4L2_SEL_COMPOSE_ACTIVE = 256 + 0,
+ V4L2_SEL_COMPOSE_DEFAULT = 256 + 1,
+ V4L2_SEL_COMPOSE_BOUNDS = 256 + 2,
+ V4L2_SEL_COMPOSE_PADDED = 256 + 3,
+};
+
+struct v4l2_selection {
+ enum v4l2_buf_type type;
+ enum v4l2_sel_targettarget;
You should avoid using enums in public APIs, as their size will depend on the
ABI version on some platforms.
+ __u32 flags;
+ struct v4l2_rectr;
+ __u32 reserved[9];
+};
+
+
/*
* A N A L O G V I D E O S T A N D A R D
*/
--
Regards,
Laurent Pinchart
--
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 1/5] [media] v4l: add support for selection api
Hi Tomasz,
On Friday 26 August 2011 15:06:03 Tomasz Stanislawski wrote:
This patch introduces new api for a precise control of cropping and
composing features for video devices. The new ioctls are
VIDIOC_S_SELECTION and VIDIOC_G_SELECTION.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |2 ++
drivers/media/video/v4l2-ioctl.c | 28
include/linux/videodev2.h |
27 +++ include/media/v4l2-ioctl.h|
4
4 files changed, 61 insertions(+), 0 deletions(-)
[snip]
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..fad4fb3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,29 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
+
+enum v4l2_sel_target {
+ V4L2_SEL_CROP_ACTIVE = 0,
+ V4L2_SEL_CROP_DEFAULT = 1,
+ V4L2_SEL_CROP_BOUNDS = 2,
+ V4L2_SEL_COMPOSE_ACTIVE = 256 + 0,
+ V4L2_SEL_COMPOSE_DEFAULT = 256 + 1,
+ V4L2_SEL_COMPOSE_BOUNDS = 256 + 2,
+ V4L2_SEL_COMPOSE_PADDED = 256 + 3,
+};
+
+struct v4l2_selection {
+ enum v4l2_buf_type type;
+ enum v4l2_sel_targettarget;
+ __u32 flags;
+ struct v4l2_rectr;
Maybe rect instead of r ? Lines such as
p-c = s.r;
in patch 3/5 look a bit cryptic.
+ __u32 reserved[9];
+};
+
+
/*
* A N A L O G V I D E O S T A N D A R D
*/
[snip]
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index dd9f1e7..2c0396b 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -194,6 +194,10 @@ struct v4l2_ioctl_ops {
struct v4l2_crop *a);
int (*vidioc_s_crop) (struct file *file, void *fh,
struct v4l2_crop *a);
+ int (*vidioc_g_selection) (struct file *file, void *fh,
+ struct v4l2_selection *a);
+ int (*vidioc_s_selection) (struct file *file, void *fh,
+ struct v4l2_selection *a);
Why 'a' ? Don't blindly copy past mistakes :-) 'sel' would be a more
descriptive parameter name.
/* Compression ioctls */
int (*vidioc_g_jpegcomp) (struct file *file, void *fh,
struct v4l2_jpegcompression *a);
--
Regards,
Laurent Pinchart
--
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: omap3isp and tvp5150 hangs
On Fri, Aug 26, 2011 at 12:52 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2011-08-26 04:42, Enrico wrote:
Hi,
i need some help to debug a kernel hang on an igep board (+ expansion)
when using omap3-isp and tvp5150 video capture. Kernel version is
mainline 3.0.1
I found that this driver is not compatible with the [new] v4l2_subdev setup.
In particular, it does not define any pads and the call to
media_entity_create_link()
in omap3isp/isp.c:1803 fires a BUG_ON() for this condition.
So basically what is needed is to implement pad functions and do
something like this:
static struct v4l2_subdev_pad_ops mt9v032_subdev_pad_ops = {
.enum_mbus_code = mt9v032_enum_mbus_code,
.enum_frame_size = mt9v032_enum_frame_size,
.get_fmt = mt9v032_get_format,
.set_fmt = mt9v032_set_format,
.get_crop = mt9v032_get_crop,
.set_crop = mt9v032_set_crop,
};
and add media init/cleanup functions? Can someone confirm this? Is
someone already working on this?
Enrico
--
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 3/5] [media] v4l: simulate old crop API using extended crop/compose API
Hi Tomasz,
Thanks for the patch.
On Friday 26 August 2011 15:06:05 Tomasz Stanislawski wrote:
This patch allows new video drivers to work correctly with applications
that use the old-style crop API. The old crop ioctl is simulated by using
selection callbacks.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ioctl.c | 86
+ 1 files changed, 76 insertions(+),
10 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 6e02b45..543405b 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1696,11 +1696,31 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops-vidioc_g_crop)
+ dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
+
+ if (ops-vidioc_g_crop) {
+ ret = ops-vidioc_g_crop(file, fh, p);
+ } else
+ if (ops-vidioc_g_selection) {
Does this construct (and the two identical ones in the next two hunks) pass
checkpatch.pl ?
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p-type,
+ .target = V4L2_SEL_CROP_ACTIVE,
+ };
+
+ /* crop means compose for output devices */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_ACTIVE;
You use
/* obtaining bounds */
if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
s.target = V4L2_SEL_COMPOSE_BOUNDS;
else
s.target = V4L2_SEL_CROP_BOUNDS;
below instead of pre-initializing .target. Can you use the same method in all
locations ?
+
+ ret = ops-vidioc_g_selection(file, fh, s);
+
+ /* copying results to old structure on success */
+ if (!ret)
+ p-c = s.r;
+ } else {
break;
+ }
You can remove the last 'else'.
- dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
- ret = ops-vidioc_g_crop(file, fh, p);
if (!ret)
dbgrect(vfd, , p-c);
break;
@@ -1709,11 +1729,26 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops-vidioc_s_crop)
- break;
dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
dbgrect(vfd, , p-c);
- ret = ops-vidioc_s_crop(file, fh, p);
+
+ if (ops-vidioc_s_crop) {
+ ret = ops-vidioc_s_crop(file, fh, p);
+ } else
+ if (ops-vidioc_s_selection) {
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p-type,
+ .target = V4L2_SEL_CROP_ACTIVE,
+ .r = p-c,
+ };
+
+ /* crop means compose for output devices */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_ACTIVE;
+
+ ret = ops-vidioc_s_selection(file, fh, s);
+ }
break;
}
case VIDIOC_G_SELECTION:
@@ -1746,12 +1781,43 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_cropcap *p = arg;
- /*FIXME: Should also show v4l2_fract pixelaspect */
- if (!ops-vidioc_cropcap)
+ dbgarg(cmd, type=%s\n, prt_names(p-type, v4l2_type_names));
+ if (ops-vidioc_cropcap) {
+ ret = ops-vidioc_cropcap(file, fh, p);
+ } else
+ if (ops-vidioc_g_selection) {
+ struct v4l2_selection s = { .type = p-type };
+ struct v4l2_rect bounds;
+
+ /* obtaining bounds */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_BOUNDS;
+ else
+ s.target = V4L2_SEL_CROP_BOUNDS;
+ ret = ops-vidioc_g_selection(file, fh, s);
+ if (ret)
+ break;
+ bounds = s.r;
You can assign p-bounds directly here, removing the need for the intermediate
bounds variable.
+
+ /* obtaining defrect */
+
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
Hi Tomasz, On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote: This patch fix the handling of data passed to V4L2 ioctls. The content of the structures is not copied if the ioctl fails. It blocks ability to obtain any information about occurred error other then errno code. This patch fix this issue. Does the V4L2 spec say anything on this topic ? We might have applications that rely on the ioctl argument structure not being touched when a failure occurs. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/v4l2-ioctl.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 543405b..9f54114 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -2490,8 +2490,6 @@ video_usercopy(struct file *file, unsigned int cmd, unsigned long arg, err = -EFAULT; goto out_array_args; } - if (err 0) - goto out; out_array_args: /* Copy results into user buffer */ -- Regards, Laurent Pinchart -- 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: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Em 26-08-2011 11:16, Hans Verkuil escreveu: On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: Hi Mauro, On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA(MEDIA_ENT_T_DEVNODE + 3) #define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4) So, a MC aware application also needs to be a hardware-dependent application, as it will need to use something else, like the media entity name, to discover for what purpose a media node is meant to be used. While I am not opposed to creating such userspace maps I also think it is a bit of a poor-man's solution. The creation of per-type devices is part of the current API: radio and vbi nodes are examples of that (except that they aren't aliases, but real devices, but the idea is the same: different names for different types of usage). In particular I am worried that we get a lot of those mappings (just think of ivtv with its 8 or 9 devices). I can think of: webcam, tv, compressed (mpeg), tv-out, compressed-out, mem2mem. But a 'tv' node might also be able to handle compressed video (depending on how the hardware is organized), so how do you handle that? Well, What you've called as compressed is, in IMO, encoder. It probably makes sense to have, also decoder. I'm in doubt about webcam, as there are some grabber devices with analog camera inputs for video surveillance. Maybe camera is a better name for it. It can all be solved, I'm sure, but I'm not sure if such userspace mappings will scale that well with the increasing hardware complexity. Not all video nodes would need an alias. Just the ones where it makes sense for an application to open it. Regards, Mauro -- 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: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
On Friday, August 26, 2011 17:09:02 Mauro Carvalho Chehab wrote: Em 26-08-2011 11:16, Hans Verkuil escreveu: On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: Hi Mauro, On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. It's for consistency so applications know what to expect. For all the simple drivers you'd just need some simple core support to add a MC. What I always thought would be handy is for applications to just iterate over all MCs and show which video/dvb/audio hardware the user has in its system. Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB(MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) #define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4) That's because we never added meta information like that. As long as the MC is only used for SoC/complex drivers there is no point in adding such info. It would be trivial to add precisely this type of information, though. So, a MC aware application also needs to be a hardware-dependent application, as it will need to use something else, like the media entity name, to discover for what purpose a media node is meant to be used. While I am not opposed to creating such userspace maps I also think it is a bit of a poor-man's solution. The creation of per-type devices is part of the current API: radio and vbi nodes are examples of that (except that they aren't aliases, but real devices, but the idea is the same: different names for different types of usage). That's why I'm not opposed to it. I'm just not sure how detailed/extensive that mapping should be. In particular I am worried that we get a lot of those mappings (just think of ivtv with its 8 or 9 devices). I can think of: webcam, tv, compressed (mpeg), tv-out, compressed-out, mem2mem. But a 'tv' node might also be able to handle compressed video (depending
[PATCH] drxd: fix divide error
Fix division by zero in drxd triggered by running femon before any DVB tuning has been done (by scandvb or anything else). Signed-off-by: Edward Sheldrake ejsheldr...@gmail.com --- drivers/media/dvb/frontends/drxd_hard.c | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/frontends/drxd_hard.c b/drivers/media/dvb/frontends/drxd_hard.c index 2238bf0..bcad01c 100644 --- a/drivers/media/dvb/frontends/drxd_hard.c +++ b/drivers/media/dvb/frontends/drxd_hard.c @@ -889,10 +889,15 @@ static int ReadIFAgc(struct drxd_state *state, u32 * pValue) u32 R2 = state-if_agc_cfg.R2; u32 R3 = state-if_agc_cfg.R3; - u32 Vmax = (3300 * R2) / (R1 + R2); - u32 Rpar = (R2 * R3) / (R3 + R2); - u32 Vmin = (3300 * Rpar) / (R1 + Rpar); - u32 Vout = Vmin + ((Vmax - Vmin) * Value) / 1024; + u32 Vmax, Rpar, Vmin, Vout; + + if (R2 == 0 (R1 == 0 || R3 == 0)) + return 0; + + Vmax = (3300 * R2) / (R1 + R2); + Rpar = (R2 * R3) / (R3 + R2); + Vmin = (3300 * Rpar) / (R1 + Rpar); + Vout = Vmin + ((Vmax - Vmin) * Value) / 1024; *pValue = Vout; } -- 1.7.6 -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
hope we're close to the final thing now. Just a few minor issues.
On 08/19/2011 09:37 AM, Laurent Pinchart wrote:
This API will be used to support YUV frame buffer formats in a standard
way.
Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/fb/api.txt | 299
++
include/linux/fb.h | 27 -
2 files changed, 320 insertions(+), 6 deletions(-)
create mode 100644 Documentation/fb/api.txt
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d6836c..c6baf28 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -69,6 +69,7 @@
#define FB_VISUAL_PSEUDOCOLOR3 /* Pseudo color (like
atari) */
#define FB_VISUAL_DIRECTCOLOR4 /* Direct color */
#define FB_VISUAL_STATIC_PSEUDOCOLOR 5 /* Pseudo color readonly */
+#define FB_VISUAL_FOURCC 6 /* Visual identified by a V4L2
FOURCC */
#define FB_ACCEL_NONE0 /* no hardware accelerator
*/
#define FB_ACCEL_ATARIBLITT 1 /* Atari Blitter*/
@@ -154,6 +155,8 @@
#define FB_ACCEL_PUV3_UNIGFX 0xa0/* PKUnity-v3 Unigfx*/
+#define FB_CAP_FOURCC1 /* Device supports FOURCC-based
formats */
+
struct fb_fix_screeninfo {
char id[16];/* identification string eg TT
Builtin */
unsigned long smem_start; /* Start of frame buffer mem */
@@ -171,7 +174,8 @@ struct fb_fix_screeninfo {
__u32 mmio_len; /* Length of Memory Mapped I/O */
__u32 accel;/* Indicate to driver which */
/* specific chip/card we have */
- __u16 reserved[3]; /* Reserved for future compatibility */
+ __u16 capabilities; /* see FB_CAP_* */
+ __u16 reserved[2]; /* Reserved for future compatibility */
};
/* Interpretation of offset for color fields: All offsets are from the right,
@@ -246,12 +250,23 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
- __u32 grayscale;/* != 0 Graylevels instead of colors */
- struct fb_bitfield red; /* bitfield in fb mem if true color, */
- struct fb_bitfield green; /* else only length is significant */
- struct fb_bitfield blue;
- struct fb_bitfield transp; /* transparency */
+ union {
+ struct {/* Legacy format API*/
+ __u32 grayscale; /* != 0 Graylevels instead of colors */
You should adjust the comment as well, to avoid misleading crazy people ;)
Needs also be fixed in the documentation at some places.
+ /* bitfields in fb mem if true color, else only */
+ /* length is significant*/
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp; /* transparency */
+ };
+ struct {/* FOURCC-based format API */
+ __u32 fourcc; /* FOURCC format*/
+ __u32 colorspace;
So we have again fields that are not always used. Okay, as we still have 11 left
that shouldn't be a big problem, I think.
+ __u32 reserved[11];
+ } format;
Ugh, if you want this union to have a name I suggest 'fourcc' and not 'format'
as the other struct contains format information as well and who knows, maybe in
10 or 20 years we'll have yet another format description that can do things none
of the existing can do.
+ };
__u32 nonstd; /* != 0 Non standard pixel format */
Thanks,
Florian Tobias Schandinat
--
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/RFC v2 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API
Hi Laurent,
On 08/19/2011 09:37 AM, Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-shmobile/board-ag5evm.c |2 +-
arch/arm/mach-shmobile/board-ap4evb.c |4 +-
arch/arm/mach-shmobile/board-mackerel.c |4 +-
drivers/video/sh_mobile_lcdcfb.c| 342
---
include/video/sh_mobile_lcdc.h |4 +-
5 files changed, 230 insertions(+), 126 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c
b/arch/arm/mach-shmobile/board-ag5evm.c
index ce5c251..e6dabaa 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -270,7 +270,7 @@ static struct sh_mobile_lcdc_info lcdc0_info = {
.flags = LCDC_FLAGS_DWPOL,
.lcd_size_cfg.width = 44,
.lcd_size_cfg.height = 79,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = lcdc0_modes,
.num_cfg = ARRAY_SIZE(lcdc0_modes),
.board_cfg = {
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index 9e0856b..6f5db07 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -489,7 +489,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.meram_dev = meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = ap4evb_lcdc_modes,
.num_cfg = ARRAY_SIZE(ap4evb_lcdc_modes),
.meram_cfg = lcd_meram_cfg,
@@ -783,7 +783,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc1_info = {
.meram_dev = meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 6e3c2df..6e36349 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -387,7 +387,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = mackerel_lcdc_modes,
.num_cfg = ARRAY_SIZE(mackerel_lcdc_modes),
.interface_type = RGB24,
@@ -450,7 +450,7 @@ static struct sh_mobile_lcdc_info hdmi_lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/drivers/video/sh_mobile_lcdcfb.c
b/drivers/video/sh_mobile_lcdcfb.c
index 97ab8ba..ea3f619 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/interrupt.h
+#include linux/videodev2.h
#include linux/vmalloc.h
#include linux/ioctl.h
#include linux/slab.h
@@ -101,7 +102,7 @@ struct sh_mobile_lcdc_priv {
struct sh_mobile_lcdc_chan ch[2];
struct notifier_block notifier;
int started;
- int forced_bpp; /* 2 channel LCDC must share bpp setting */
+ int forced_fourcc; /* 2 channel LCDC must share fourcc setting */
struct sh_mobile_meram_info *meram_dev;
};
@@ -214,6 +215,42 @@ struct sh_mobile_lcdc_sys_bus_ops
sh_mobile_lcdc_sys_bus_ops = {
lcdc_sys_read_data,
};
+static int sh_mobile_format_fourcc(const struct fb_var_screeninfo *var)
+{
+ if (var-format.fourcc 1)
+ return var-format.fourcc;
+
+ switch (var-bits_per_pixel) {
+ case 16:
+ return V4L2_PIX_FMT_RGB565;
+ case 24:
+ return V4L2_PIX_FMT_BGR24;
+ case 32:
+ return V4L2_PIX_FMT_BGR32;
+ default:
+ return 0;
+ }
+}
+
+static bool sh_mobile_format_yuv(const struct fb_var_screeninfo *var)
+{
+ if (var-format.fourcc = 1)
+ return false;
+
+ switch (var-format.fourcc) {
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ return true;
+
+ default:
+ return false;
+ }
+}
+
static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
{
if (atomic_inc_and_test(priv-hw_usecnt)) {
@@ -434,7 +471,6 @@ static void __sh_mobile_lcdc_start(struct
sh_mobile_lcdc_priv *priv)
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Em 26-08-2011 12:29, Hans Verkuil escreveu: On Friday, August 26, 2011 17:09:02 Mauro Carvalho Chehab wrote: Em 26-08-2011 11:16, Hans Verkuil escreveu: On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: Hi Mauro, On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. It's for consistency so applications know what to expect. I've already said it before: We won't be implementing an API for a device just for consistency without any real reason. For all the simple drivers you'd just need some simple core support to add a MC. What I always thought would be handy is for applications to just iterate over all MCs and show which video/dvb/audio hardware the user has in its system. MC doesn't work for audio yet, as snd-usb-audio doesn't use it. So, it will fail for a large amount of devices whose audio is implemented using standard USB Audio Class. Adding MC support for it doesn't sound trivial, and won't offer any gain over the sysfs equivalent. Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) #define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4) That's because we never added meta information like that. As long as the MC is only used for SoC/complex drivers there is no point in adding such info. Even For SoC, such info would probably be useful. As I said before, with the current way, I can't see how a generic MC aware application would do the right thing for the devices that currently implement the MC api, simply because there's no way for an application to know what pipelines need to be configured, as no entity at the MC (or elsewhere on some userspace library) describes what pipelines are meant to be used by the common usecase. It would be trivial to add precisely this type of information, though. Yes, adding a new field to indicate what type of V4L devnode is there won't be hard, but it would
Re: radio-si470x-usb.c warning: can I remove 'buf'?
Hi Hans, While going through the compile warnings generated in the daily build I came across this one: v4l-dvb-git/drivers/media/radio/si470x/radio-si470x-usb.c: In function 'si470x_int_in_callback': v4l-dvb-git/drivers/media/radio/si470x/radio-si470x-usb.c:398:16: warning: variable 'buf' set but not used [-Wunused-but-set-variable] The 'unsigned char buf[RDS_REPORT_SIZE];' is indeed unused, but can I just remove it? There is this single assignment to buf: 'buf[0] = RDS_REPORT;'. This makes me wonder if it is perhaps supposed to be used after all. Please let me know if I can remove it, or if it is a bug that someone needs to fix. this is an artifact from shifting the rds processing function into interrupt context. Yes, this can safely be removed. Can you do this? Bye, Toby -- 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] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Aug 26 19:00:31 CEST 2011 git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification 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
