Re: [PATCH v3 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver
Hi Sylwester,
Thanks for the comments.
On Mon, Sep 16, 2013 at 3:58 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
Hi Shaik,
Thanks for addressing my comments, it really looks much better now.
I have few more comments, mostly minor issues.
[...]
+
+const struct scaler_fmt *scaler_find_fmt(u32 *pixelformat,
+ u32 *mbus_code, u32 index)
+{
+ const struct scaler_fmt *fmt, *def_fmt = NULL;
+ unsigned int i;
+
+ if (index= ARRAY_SIZE(scaler_formats))
+ return NULL;
+
+ for (i = 0; i ARRAY_SIZE(scaler_formats); ++i) {
+ fmt = scaler_get_format(i);
+ if (pixelformat fmt-pixelformat == *pixelformat)
+ return fmt;
+ if (mbus_code fmt-mbus_code == *mbus_code)
+ return fmt;
is mbus_code ever used ?
Yes. Currently not used. Will remove this field for now..
+ if (index == i)
+ def_fmt = fmt;
+ }
+
+ return def_fmt;
+}
[...]
+
+int scaler_try_fmt_mplane(struct scaler_ctx *ctx, struct v4l2_format *f)
+{
+ struct scaler_dev *scaler = ctx-scaler_dev;
+ struct device *dev =scaler-pdev-dev;
+ struct scaler_variant *variant = scaler-variant;
+ struct v4l2_pix_format_mplane *pix_mp =f-fmt.pix_mp;
[...]
+
+ /*
+* Nothing mentioned about the colorspace in SCALER. Default value
is
+* set to V4L2_COLORSPACE_REC709.
+*/
Isn't scaler_hw_set_csc_coef() function configuring the colorspace ?
Actually speaking this function should do the color space setting part.
What the SCALER ip supports is CSC offset value for Y
YCbCr to RGB : Zero offset of -16 offset for input
RGB to YCbCr : Zero offset of +16 offset for output
I think user should provide this information through some controls.
Anyways, will take it later.
+ pix_mp-colorspace = V4L2_COLORSPACE_REC709;
+
+ for (i = 0; i pix_mp-num_planes; ++i) {
+ int bpl = (pix_mp-width * fmt-depth[i]) 3;
+ pix_mp-plane_fmt[i].bytesperline = bpl;
+ pix_mp-plane_fmt[i].sizeimage = bpl * pix_mp-height;
+
+ scaler_dbg(scaler, [%d]: bpl: %d, sizeimage: %d,
+ i, bpl, pix_mp-plane_fmt[i].sizeimage);
+ }
+
+ return 0;
+}
+
[...]
+static int scaler_runtime_resume(struct device *dev)
+{
+ struct scaler_dev *scaler = dev_get_drvdata(dev);
+ int ret = 0;
+ scaler_dbg(scaler, state: 0x%lx, scaler-state);
+
+ ret = clk_enable(scaler-clock);
+ if (ret 0)
+ return ret;
+
+ scaler_sw_reset(scaler);
+
+ return scaler_m2m_resume(scaler);
Shouldn't there be clk_disable() when this function fails ?
this funciton scaler_m2m_resume() never fails.
Regards,
Shaik Ameer Basha
--
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
[GIT PULL] 2 3.12 fixes: mx3-camera and VOU
Hi Mauro I was postponing these two patch to push them together with potential em28xx fixes, but since we still cannot agree on those, I decided to push these ones out: The following changes since commit 2a65ef5e5e5863af7848680909478fdc79e726d7: Add linux-next specific files for 20130917 (2013-09-17 13:07:03 +1000) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 3.12-rc1-fixes Dan Carpenter (2): sh_vou: almost forever loop in sh_vou_try_fmt_vid_out() mx3-camera: locking cleanup in mx3_videobuf_queue() drivers/media/platform/sh_vou.c|2 +- drivers/media/platform/soc_camera/mx3_camera.c |5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v7 01/13] [media] exynos5-is: Adding media device driver for exynos5
Hi Sylwester,
I'd like to propose a little re-design of this binding. The reason is that
I've noticed issues related to the power domain and FIMC-LITE, FIMC-IS
clocks
handling sequences. This lead to a failure to disable the ISP power domain
and to complete the system suspend/resume cycle. Not sure if this happens on
Exynos5 SoCs, nevertheless IMHO it would be more reasonable to make
FIMC-LITE
device nodes child nodes of FIMC-IS. FIMC-LITE seems to be an integral part
of the FIMC-IS subsystem.
Then fimc-is node would be placed at root level, with fimc-lite nodes as its
subnodes:
fimc-is {
compatible = exynos5250-fimc-is;
reg = ...;
...
#address-cells = 1;
#size-cells = 1;
ranges;
fimc_lite_0: fimc-lite@1239 {
compatible = samsung,exynos4212-fimc-lite;
...
};
fimc_lite_1: fimc-lite@123A {
compatible = samsung,exynos4212-fimc-lite;
...
};
fimc_lite_2: fimc-lite@123B {
compatible = samsung,exynos4212-fimc-lite;
...
};
i2c0_isp: i2c-isp@1213 {
...
};
...
};
Wont this make fimc-is to be enabled to use fimc-lite?
As such there is no dependency like that in hardware and we can
use fimc-lite alone in DMA out mode without fimc-is.
If its modified as per your suggestion, how will the scenario of
sensor - mipi-csis - fimc-lite - memory look like without fimc-is?
Regards
Arun
--
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 v3 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver
Hi sylwester, Isn't scaler_hw_set_csc_coef() function configuring the colorspace ? Actually speaking this function should do the color space setting part. What the SCALER ip supports is CSC offset value for Y YCbCr to RGB : Zero offset of -16 offset for input RGB to YCbCr : Zero offset of +16 offset for output small spelling mistake here.. YCbCr to RGB : Zero offset or -16 offset for input RGB to YCbCr : Zero offset or +16 offset for output Regards, Shaik Ameer Basha I think user should provide this information through some controls. Anyways, will take it later. -- 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 v9 0/2] Introduce buffer synchronization framework
Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism, and is rebased on linux-3.12-rc1 The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. Changelog v9: - Delete only one sync object matched at DEL_OBJ_FROM_RSV macro. - Fix memory leak issue at dmabuf_sync_single_lock() Changelog v8: Consider the write-and-then-read ordering pointed out by David Herrmann, - The ordering issue means that a task don't take a lock to the dmabuf so this task would be stalled even though this task requested a lock to the dmabuf between other task unlocked and tries to lock the dmabuf again. For this, we have added a wait event mechanism using only generic APIs, wait_event_timeout and wake_up functions. The below is how to handle the ordering issue using this mechanism: 1. Check if there is a sync object added prior to current task's one. 2. If exists, it unlocks the dmabuf so that other task can take a lock to the dmabuf first. 3. Wait for the wake up event from other task: current task will be waked up when other task unlocks the dmabuf. 4. Take a lock to the dmabuf again. - Code cleanups. Changelog v7: Fix things pointed out by Konrad Rzeszutek Wilk, - Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL. - Make sure to unlock and unreference all dmabuf objects when dmabuf_sync_fini() is called. - Add more comments. - Code cleanups. Changelog v6: - Fix sync lock to multiple reads. - Add select system call support. . Wake up poll_wait when a dmabuf is unlocked. - Remove unnecessary the use of mutex lock. - Add private backend ops callbacks. . This ops has one callback for device drivers to clean up their sync object resource when the sync object is freed. For this, device drivers should implement the free callback properly. - Update document file. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. For generic user mode interface, we have used fcntl and select system call[3]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. And select() call means to wait for the completion of CPU or DMA access to the dma-buf without locking. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ There are some cases user-space process needs this buffer synchronization framework. One of which is to primarily enhance GPU rendering performance in case that 3D app draws somthing in a buffer using CPU, and other process composes the buffer with its own backbuffer using GPU. In case of 3D app, the app calls glFlush to submit 3d commands to GPU driver instead of glFinish for more performance. The reason, we call glFlush, is that glFinish blocks caller's task until the execution of the 3d commands is completed. So that makes GPU and CPU more idle. As a result, 3d rendering performance with glFinish is quite lower than glFlush. However, the use of glFlush has one issue that the the buffer shared with GPU could be broken when CPU accesses the buffer just after glFlush because CPU cannot be aware of the completion of GPU access to the buffer. Of course, the app can be aware of that time using eglWaitGL but this function is valid only in case of the same context. The below summarizes how app's window is displayed on Tizen[4] platform: 1. X client requests a window buffer to Xorg. 2. X client draws something in the window buffer using CPU. 3. X client requests SWAP to Xorg. 4. Xorg notifies a damage event to Composite Manager. 5. Composite Manager gets the window buffer (front buffer) through DRI2GetBuffers. 6. Composite Manager composes the window buffer and its own back buffer using GPU. At this time, eglSwapBuffers is called: internally, 3d commands are flushed to gpu driver. 7. Composite Manager requests SWAP to Xorg. 8. Xorg performs drm page flip. At this time, the window buffer is displayed on screen. Web app based on HTML5 also has
[PATCH v9 1/2] dmabuf-sync: Add a buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and and based on ww-mutexes[2] for lock mechanism, and is rebased on linux-3.12-rc1 The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and user application. This framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v9: - Delete only one sync object matched at DEL_OBJ_FROM_RSV macro. - Fix memory leak issue at dmabuf_sync_single_lock() Changelog v8: Consider the write-and-then-read ordering pointed out by David Herrmann, - The ordering issue means that a task don't take a lock to the dmabuf so this task would be stalled even though this task requested a lock to the dmabuf between other task unlocked and tries to lock the dmabuf again. For this, we have added a wait event mechanism using only generic APIs, wait_event_timeout and wake_up functions. The below is how to handle the ordering issue using this mechanism: 1. Check if there is a sync object added prior to current task's one. 2. If exists, it unlocks the dmabuf so that other task can take a lock to the dmabuf first. 3. Wait for the wake up event from other task: current task will be waked up when other task unlocks the dmabuf. 4. Take a lock to the dmabuf again. - Code cleanups. Changelog v7: Fix things pointed out by Konrad Rzeszutek Wilk, - Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL. - make sure to unlock and unreference all dmabuf objects when dmabuf_sync_fini() is called. - Add more comments. - code cleanups. Changelog v6: - Fix sync lock to multiple reads. - Add select system call support. . Wake up poll_wait when a dmabuf is unlocked. - Remove unnecessary the use of mutex lock. - Add private backend ops callbacks. . This ops has one callback for device drivers to clean up their sync object resource when the sync object is freed. For this, device drivers should implement the free callback properly. - Update document file. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct
[PATCH v2 2/2] dma-buf: Add user interfaces for dmabuf sync support
This patch adds lock and poll callbacks to dma buf file operations,
and these callbacks will be called by fcntl and select system calls.
fcntl and select system calls can be used to wait for the completion
of DMA or CPU access to a shared dmabuf. The difference of them is
fcntl system call takes a lock after the completion but select system
call doesn't. So in case of fcntl system call, it's useful when a task
wants to access a shared dmabuf without any broken. On the other hand,
it's useful when a task wants to just wait for the completion.
Changelog v2:
- Add select system call support.
. The purpose of this feature is to wait for the completion of DMA or
CPU access to a dmabuf without that caller locks the dmabuf again
after the completion.
That is useful when caller wants to be aware of the completion of
DMA access to the dmabuf, and the caller doesn't use intefaces for
the DMA device driver.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/base/dma-buf.c | 81
1 file changed, 81 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 3985751..73234ba 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -29,6 +29,7 @@
#include linux/export.h
#include linux/debugfs.h
#include linux/seq_file.h
+#include linux/poll.h
#include linux/dmabuf-sync.h
static inline int is_dma_buf_file(struct file *);
@@ -106,10 +107,90 @@ static loff_t dma_buf_llseek(struct file *file, loff_t
offset, int whence)
return base + offset;
}
+static unsigned int dma_buf_poll(struct file *filp,
+ struct poll_table_struct *poll)
+{
+ struct dma_buf *dmabuf;
+ struct dmabuf_sync_reservation *robj;
+ int ret = 0;
+
+ if (!is_dma_buf_file(filp))
+ return POLLERR;
+
+ dmabuf = filp-private_data;
+ if (!dmabuf || !dmabuf-sync)
+ return POLLERR;
+
+ robj = dmabuf-sync;
+
+ mutex_lock(robj-lock);
+
+ robj-polled = true;
+
+ /*
+* CPU or DMA access to this buffer has been completed, and
+* the blocked task has been waked up. Return poll event
+* so that the task can get out of select().
+*/
+ if (robj-poll_event) {
+ robj-poll_event = false;
+ mutex_unlock(robj-lock);
+ return POLLIN | POLLOUT;
+ }
+
+ /*
+* There is no anyone accessing this buffer so just return.
+*/
+ if (!robj-locked) {
+ mutex_unlock(robj-lock);
+ return POLLIN | POLLOUT;
+ }
+
+ poll_wait(filp, robj-poll_wait, poll);
+
+ mutex_unlock(robj-lock);
+
+ return ret;
+}
+
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ struct dma_buf *dmabuf;
+ unsigned int type;
+ bool wait = false;
+
+ if (!is_dma_buf_file(file))
+ return -EINVAL;
+
+ dmabuf = file-private_data;
+
+ if ((fl-fl_type F_UNLCK) == F_UNLCK) {
+ dmabuf_sync_single_unlock(dmabuf);
+ return 0;
+ }
+
+ /* convert flock type to dmabuf sync type. */
+ if ((fl-fl_type F_WRLCK) == F_WRLCK)
+ type = DMA_BUF_ACCESS_W;
+ else if ((fl-fl_type F_RDLCK) == F_RDLCK)
+ type = DMA_BUF_ACCESS_R;
+ else
+ return -EINVAL;
+
+ if (fl-fl_flags FL_SLEEP)
+ wait = true;
+
+ /* TODO. the locking to certain region should also be considered. */
+
+ return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+ .poll = dma_buf_poll,
+ .lock = dma_buf_lock,
};
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.13] videobuf2 updates
Hi Mauro, This includes videobuf2-dma-sg allocator enhancements, videobuf-core cleanup and debug logs addition. The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v3.13-videobuf2 for you to fetch changes up to de727541f8be1de8163bf831b38aaf2181d6284e: videobuf2: Add debug print for the output buffer plane lengths checks (2013-09-17 13:46:54 +0200) Ricardo Ribalda (3): videobuf2: Fix vb2_write prototype videobuf2-dma-sg: Allocate pages as contiguous as possible videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table Seung-Woo Kim (1): videobuf2: Add log for size checking error in __qbuf_userptr Sylwester Nawrocki (1): videobuf2: Add debug print for the output buffer plane lengths checks drivers/media/platform/marvell-ccic/mcam-core.c| 14 +- drivers/media/v4l2-core/videobuf2-core.c | 16 ++- drivers/media/v4l2-core/videobuf2-dma-sg.c | 149 +++- drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 20 +-- include/media/videobuf2-core.h |4 +- include/media/videobuf2-dma-sg.h | 10 +- 6 files changed, 119 insertions(+), 94 deletions(-) -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] 3.12 (mostly videobuf2) fixes
Hi Mauro, Here are couple regression fixes for 3.12-rc. I'm planning to send backport patches of the videobuf2-dma-contig allocator patch for -stable. The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git v3.12-fixes-1 for you to fetch changes up to 99f2689e2d05b42d51bf087850c84da2000ded1e: s5p-jpeg: Initialize vfd_decoder-vfl_dir field (2013-09-17 13:21:59 +0200) Jacek Anaszewski (1): s5p-jpeg: Initialize vfd_decoder-vfl_dir field Marek Szyprowski (1): videobuf2-dc: Fix support for mappings without struct page in userptr mode Sylwester Nawrocki (1): vb2: Allow queuing OUTPUT buffers with zeroed 'bytesused' drivers/media/platform/s5p-jpeg/jpeg-core.c|1 + drivers/media/v4l2-core/videobuf2-core.c |4 +- drivers/media/v4l2-core/videobuf2-dma-contig.c | 87 ++-- 3 files changed, 86 insertions(+), 6 deletions(-) -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: avermedia A306 / PCIe-minicard (laptop) / CX23885
Hello
Hello Remi!
Thank you for looking at the Avercard with the CX23885 driver.
Antti, redirected me toward you,
What exactly is your question?
And
If it's at the least at the same stage as the HC81 , I think it deserve's to
be listed in cards.h
Possibly. Tell us again 1) what you have working reliably 2) what
isn't working but the driver is exposing and 3) what the driver is
exposing but has not been tested.
So people will know right away, that this card has been identified by the V4L
community, and dont have
Anyone working on that card would arrive here on the mailing list, I
don't think that's going to be an issue. I suggest you focus on
getting feature of the card working reliably, produce a patchset and
I'm sure it will get reviewed, refined then eventually merged.
Other comments below.
+ [CX23885_BOARD_AVERMEDIA_A306] = {
+.name = AVerTV Hybrid Minicard PCIe A306,
+.tuner_type = TUNER_XC2028,
+.tuner_addr = 0x61, /* 0xc2 1 */
+.tuner_bus = 1,
+.porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_ENCODER,
+.input = {{
+.type = CX23885_VMUX_TELEVISION,
+.vmux = CX25840_VIN2_CH1 |
+ CX25840_VIN5_CH2 |
+ CX25840_NONE0_CH3 |
+ CX25840_NONE1_CH3,
+.amux = CX25840_AUDIO8,
+}, {
+.type = CX23885_VMUX_SVIDEO,
+.vmux = CX25840_VIN8_CH1 |
+ CX25840_NONE_CH2 |
+ CX25840_VIN7_CH3 |
+ CX25840_SVIDEO_ON,
+.amux = CX25840_AUDIO6,
+}, {
+.type = CX23885_VMUX_COMPONENT,
+.vmux = CX25840_VIN1_CH1 |
+ CX25840_NONE_CH2 |
+ CX25840_NONE0_CH3 |
+ CX25840_NONE1_CH3,
+.amux = CX25840_AUDIO6,
+}},
+
+ }
Does the card have a MPEG2 hardware compressor and is it functioning
properly? (/dev/video1)
Are both svideo and component inputs working correctly in tvtime?
What about audio inputs? Does the card have any audio inputs and is
the driver acting and exposing those features correctly?
If not then please remove any of these sections.
+case CX23885_BOARD_AVERMEDIA_A306:
+cx_clear(MC417_CTL, 1);
+/* GPIO-0,1,2 setup direction as output */
+cx_set(GP0_IO, 0x0007);
+mdelay(10);
+/* AF9013 demod reset */
+cx_set(GP0_IO, 0x00010001);
+mdelay(10);
+cx_clear(GP0_IO, 0x00010001);
+mdelay(10);
+cx_set(GP0_IO, 0x00010001);
+mdelay(10);
+/* demod tune? */
+cx_clear(GP0_IO, 0x00030003);
+mdelay(10);
+cx_set(GP0_IO, 0x00020002);
+mdelay(10);
+cx_set(GP0_IO, 0x00010001);
+mdelay(10);
+cx_clear(GP0_IO, 0x00020002);
+/* XC3028L tuner reset */
+cx_set(GP0_IO, 0x00040004);
+cx_clear(GP0_IO, 0x00040004);
+cx_set(GP0_IO, 0x00040004);
+mdelay(60);
+break;
You're setting and clearing the GPIO direction enable registers (upper
16 bits), this isn't a good idea.
If you want to drive a GPIO in a specific direction (lower 8 bits),
perhaps for a reset, instead do this:
/* AF9013 demod reset */
cx_set(GP0_IO, 0x00010001); /* Establish the direction of the GPIO and
it's signal level)
mdelay(10);
cx_clear(GP0_IO, 0x0001); /* change the signal level, drive to low */
mdelay(10);
cx_set(GP0_IO, 0x0001); /* back to high */
mdelay(10);
Repeat this example for other other 'demod tune' and 3028 resets you
are doing, don't toggle the upper 16bits, else you leave the GPIO
floating, a bad idea.
- Steve
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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: Canvassing for Linux support for Startech PEXHDCAP
On 16/09/2013 19:09, Devin Heitmueller wrote: To be clear, this card is a *raw* capture card. It does not have any hardware compression for H.264. It's done entirely in software. Ok, well I misunderstood that. And, in addition, I also thought that hardware encoding *reduced* latency, something you seem to indicate is not true. If this is stored in a file, somehow it needs to be encoded, I just imagined that metal was faster than code. Aside from the Mstar video decoder (for which there is no public documentation), you would also need a driver for the saa7160 chip, which there have been various half-baked drivers floating around but nothing upstream, and none of them currently support HD capture (AFAIK). Well the chip thing is confusing me. 1) I don't understand the difference between the MST3367CMK-LF-170 and the saa7160. Is one analogue and one digital? Or do they perform different steps in the process (like one does encoding and one does the DMA thing? 2) If you look here, http://katocctv.en.alibaba.com/product/594834688-213880911/1080p_PCIe_Video_Grabber_Video_Capture_Card.html You'll see a very similar card with an extra chip. You can just see that it is produced by Gennum (but I can't see the number). There is also another chip on the underside, maybe this is the saa7160? And maybe it's on the underside of the PEXHDCAP too. This is actually the one I saw working. As I say it was very fast and high quality, but under windows. Scroll down and you see this: Operation System: WINDOWS XP /VISTA/ 7 Linux 2.6. 14 or higher (32-bit and 64-bit) Drilling into this, it appeared the statement was more aspirational than actual, but that it *had* been compatible, but there was not yet an available driver. They would need to recompile something to include the latest linux libraries before it would be possible to write the drivers. I've no idea what this could mean. Although 2 clients had indeed written gstreamer drivers, one was Cisco systems, but had kept the code to themselves. and none of them currently support HD capture (AFAIK). What does this mean? No saa7160 drivers, or no drivers period? I have the Intensity Pro doing full-screen 1080i capture with minimal latency, but I hate the decklinksrc module. It just does nearly nothing. Maybe it could be re-written for v4l2src, but anyway it only accepts YPbPr, as I said before. As always, a driver *can* be written, but it would be a rather large project (probably several weeks of an engineer working full time on it, assuming the engineer has experience in this area). In this case it's worse because a significant amount of reverse engineering would be required. Kato Vision agreed with you. They were saying a few months (maybe two or three). They didn't offer to write it, but they offered technical support with the driver-writing. Thanks for your input. Regards Steve -- 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 v11 0/8] PHY framework
On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. Alright, thanks. Just a gentle ping on this one... cheers -- balbi signature.asc Description: Digital signature
Re: avermedia A306 / PCIe-minicard (laptop) / CX23885
Hello :)
Thnx for the reply !
Well, I do not have the cables ... it's a laptop card, orginally for a Dell,
I am doing my tests on an Acer,
The Video0 dev , composite/s-video is showing an analog signal, i guess a
noise picture because not hooked-up,
but bottom half is sometimes green .
Analog scanning/reception = NULL , I might have to check again the antenna
connexion,
For the Mpeg, negative, it's a 9013 chip, I still have to discecte the 9015
driver and pull-out
the 9013 spcific data , iguess .
What I need the most, Is a big picture of the V4L API , like an organigram of
what is where ( initialising this or that,
handeling setups - and controls)
I code, but going thru others Code, is always like playing Maze ... :)
especially an API in a whole System Package...
But I am searching on my side :)
I there a dummy /test driver for PCIe cards I can study ?
Best regards
Rémi.
Le 17 septembre 2013 à 15:38, Steven Toth st...@kernellabs.com a écrit :
Hello
Hello Remi!
Thank you for looking at the Avercard with the CX23885 driver.
Antti, redirected me toward you,
What exactly is your question?
And
If it's at the least at the same stage as the HC81 , I think it deserve's
to
be listed in cards.h
Possibly. Tell us again 1) what you have working reliably 2) what
isn't working but the driver is exposing and 3) what the driver is
exposing but has not been tested.
So people will know right away, that this card has been identified by the
V4L
community, and dont have
Anyone working on that card would arrive here on the mailing list, I
don't think that's going to be an issue. I suggest you focus on
getting feature of the card working reliably, produce a patchset and
I'm sure it will get reviewed, refined then eventually merged.
Other comments below.
+ [CX23885_BOARD_AVERMEDIA_A306] = {
+ .name = AVerTV Hybrid Minicard PCIe A306,
+ .tuner_type = TUNER_XC2028,
+ .tuner_addr = 0x61, /* 0xc2 1 */
+ .tuner_bus = 1,
+ .porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_ENCODER,
+ .input = {{
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_VIN2_CH1 |
+ CX25840_VIN5_CH2 |
+ CX25840_NONE0_CH3 |
+ CX25840_NONE1_CH3,
+ .amux = CX25840_AUDIO8,
+ }, {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_VIN8_CH1 |
+ CX25840_NONE_CH2 |
+ CX25840_VIN7_CH3 |
+ CX25840_SVIDEO_ON,
+ .amux = CX25840_AUDIO6,
+ }, {
+ .type = CX23885_VMUX_COMPONENT,
+ .vmux = CX25840_VIN1_CH1 |
+ CX25840_NONE_CH2 |
+ CX25840_NONE0_CH3 |
+ CX25840_NONE1_CH3,
+ .amux = CX25840_AUDIO6,
+ }},
+
+ }
Does the card have a MPEG2 hardware compressor and is it functioning
properly? (/dev/video1)
Are both svideo and component inputs working correctly in tvtime?
What about audio inputs? Does the card have any audio inputs and is
the driver acting and exposing those features correctly?
If not then please remove any of these sections.
+ case CX23885_BOARD_AVERMEDIA_A306:
+ cx_clear(MC417_CTL, 1);
+ /* GPIO-0,1,2 setup direction as output */
+ cx_set(GP0_IO, 0x0007);
+ mdelay(10);
+ /* AF9013 demod reset */
+ cx_set(GP0_IO, 0x00010001);
+ mdelay(10);
+ cx_clear(GP0_IO, 0x00010001);
+ mdelay(10);
+ cx_set(GP0_IO, 0x00010001);
+ mdelay(10);
+ /* demod tune? */
+ cx_clear(GP0_IO, 0x00030003);
+ mdelay(10);
+ cx_set(GP0_IO, 0x00020002);
+ mdelay(10);
+ cx_set(GP0_IO, 0x00010001);
+ mdelay(10);
+ cx_clear(GP0_IO, 0x00020002);
+ /* XC3028L tuner reset */
+ cx_set(GP0_IO, 0x00040004);
+ cx_clear(GP0_IO, 0x00040004);
+ cx_set(GP0_IO, 0x00040004);
+ mdelay(60);
+ break;
You're setting and clearing the GPIO direction enable registers (upper
16 bits), this isn't a good idea.
If you want to drive a GPIO in a specific direction
Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
Hi, I'm trying to consolidate the list of interested people on participating at this year's the media mini-summit. From what I got from the discussions, we have, so far: Benjamin Gaignard benjamin.gaign...@linaro.org Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hverk...@xs4all.nl Hugues FRUCHET hugues.fruc...@st.com Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab m.che...@samsung.com Michael Krufky mkru...@kernellabs.com Oliver Schinagl oliver+l...@schinagl.nl Pawel Osciak posc...@chromium.org Peter Senna Tschudin peter.se...@gmail.com Ricardo Ribalda Delgado ricardo.riba...@gmail.com Sakari Ailus sakari.ai...@iki.fi Please let me know if I'm missing someone, or if one of the above won't be able to go to the meeting, as my plan is to send the invitations tomorrow. Thank you! 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: avermedia A306 / PCIe-minicard (laptop) / CX23885
Hello :) Thnx for the reply ! You are welcome. Well, I do not have the cables ... it's a laptop card, orginally for a Dell, I am doing my tests on an Acer, So you don't have a valid signal to test your changes with? The Video0 dev , composite/s-video is showing an analog signal, i guess a noise picture because not hooked-up, Hmm. Possibly, or possible the video decoder and video patch is not configured. but bottom half is sometimes green . So you haven't seen ANY stable video from any analog input? Analog scanning/reception = NULL , I might have to check again the antenna connexion, OK. For the Mpeg, negative, it's a 9013 chip, I still have to discecte the 9015 driver and pull-out the 9013 spcific data , iguess . OK. No mpeg either. So you don't have anything working so far, that's my reading of your current state. What I need the most, Is a big picture of the V4L API , like an organigram of what is where ( initialising this or that, linuxtv.org handeling setups - and controls) V4L2 Specification at linuxtv.org I there a dummy /test driver for PCIe cards I can study ? CX23885 is a good place to start. It's fully functional and matches the hardware you have to experiment with. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: Canvassing for Linux support for Startech PEXHDCAP
On 17/09/2013 12:38, Devin Heitmueller wrote: Nope, the opposite. In order to compress the video you need to store enough context to look for repetition. Ok, quite intuitive, once you know what to look for. Yup. We've been through the exercise several times with various HD capture boards. Adjust the multiplier based on the level of experience of the developer doing the work. So it is do-able. That's good to know. If I want to capture 480i/576i and 1080i analogue my alternatives seem to be: - Something like Dazzle, $50 (480i/576i only - s-video and composite), - Intensity Pro, $200 (480i in s-video and composite, plus, 480i/576i 1080i in Component but YPbPr only). S-Video and Component in 480i/576i seem to have very similar picture quality. Which leaves me with how to capture RGBS 1080i composite synch. What do you think of Epiphan VGA2USB (with the internal PCIe mounting kit)? The basic model at $299 doesn't cover RGBS, but it does do 1080i. Maybe I could use a sync splitter and inverter, like the LS1881n, to make the RGBS composite synch fit the VGA H+V pins. The LR at $799 doesn't seem to capture 1080i. I thought it did, but now I look at the website again, I can't see it. Have you used it? If not those then there is only the HR at $1,600 :( But Epiphan appears to support v4l2 and gstreamer. Is it fast? I guess it doesn't do S-Video and Composite. If not Epiphan then what? The Epixinc PIXCI® A310? It seems quite a hard problem. Regards Steve. -- 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
[RFC 1/1] v4l: return POLLERR on V4L2 sub-devices if no events are subscribed
From: Teemu Tuominen teemux.tuomi...@intel.com
Add check and return POLLERR from subdev_poll() in case of no events
subscribed and wakeup once the last event subscription is removed.
This change is essentially done to add possibility to wakeup polling
with concurrent unsubscribe.
Signed-off-by: Teemu Tuominen teemux.tuomi...@intel.com
Move the check after calling poll_wait(). Otherwise it's possible that we go
to sleep without getting notified if the subscription went away between the
two.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
Tested-by: Teemu Tuominen teemux.tuomi...@intel.com
---
Hi all,
Poll for events will sleep forever if there are no events subscribed.
Calling poll from an application that has not subscribed any event indeed
sounds silly, but un multi-threaded applications this is not quite as
straightforward.
Assume the following: an application has two threads where one handles
event subscription and the other handles the events. The first thread
unsubscribes the events and the latter will sleep forever. And do this while
the program intends to quit without an intention to subscribe for any
further events, and there's a deadlock.
Alternative solutions to handle this are signals (rather a nuisance if the
application happens to be a library instead) or a pipe (2) between the
threads. Pipe is workable, but instead of being a proper solution to the
problem still looks like a workaround instead.
This patch fixes the issue on kernel side by waking up the processes
sleeping in poll and returning POLLERR when the last subscribed event is
gone. The behaviour mirrors that of videobuf2 which will return POLLERR if
either streaming is disabled or no buffers are queued.
Just waking up the sleeping threads once is not an option: threads are not
visible to the kernel at this level and just waking them up isn't either
since poll will go back to sleep before returning the control back to user
space as long as it would return zero.
(Thinking about it --- similar change should probably be made to videobuf2
event poll handling as well.)
Kind regards,
Sakari
drivers/media/v4l2-core/v4l2-event.c | 15 +++
drivers/media/v4l2-core/v4l2-subdev.c | 3 +++
include/media/v4l2-event.h| 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c
index 86dcb54..b53897e 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -107,6 +107,19 @@ static struct v4l2_subscribed_event *v4l2_event_subscribed(
return NULL;
}
+bool v4l2_event_has_subscribed(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+ bool rval;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ rval = !list_empty(fh-subscribed);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+
+ return rval;
+}
+EXPORT_SYMBOL(v4l2_event_has_subscribed);
+
static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event
*ev,
const struct timespec *ts)
{
@@ -299,6 +312,8 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh,
fh-navailable--;
}
list_del(sev-list);
+ if (list_empty(fh-subscribed))
+ wake_up_all(fh-wait);
}
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 996c248..f2aa00f 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -382,6 +382,9 @@ static unsigned int subdev_poll(struct file *file,
poll_table *wait)
if (v4l2_event_pending(fh))
return POLLPRI;
+ if (!v4l2_event_has_subscribed(fh))
+ return POLLERR;
+
return 0;
}
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index be05d01..a9ca2b5 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -121,6 +121,7 @@ struct v4l2_subscribed_event {
int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event,
int nonblocking);
+bool v4l2_event_has_subscribed(struct v4l2_fh *fh);
void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event *ev);
void v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event *ev);
int v4l2_event_pending(struct v4l2_fh *fh);
--
1.8.3.2
--
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: [Bug] 0ac8:0321 Vimicro generic vc0321 Camera is not working and causes crashes since 3.2
On 09/09/2013 02:09 PM, Hans de Goede wrote: Thanks for the bug report, looking at the bug reports, they all report an error of -71 which is EPROTO, which typically means something is wrong at the USB level. And nothing has changed for the driver in question between 3.1 and 3.2 , so I believe this regression is caused by changes to the usb sub-system, likely changes to the EHCI driver. I have tested the new 3.12.0-rc1 kernel and the regression is still present. It causes that Cheese crashes with a segmentation fault and I get the following errors [ 139.868628] gspca_main: ISOC data error: [21] len=0, status=-71 [ 139.904620] gspca_main: ISOC data error: [12] len=0, status=-71 [ 139.936595] gspca_main: ISOC data error: [9] len=0, status=-71 [ 139.968576] gspca_main: ISOC data error: [17] len=0, status=-71 [ 140.036571] gspca_main: ISOC data error: [16] len=0, status=-71 [ 140.037364] video_source:sr[2570]: segfault at 8 ip 7f0430d6868c sp 7f0406c02900 error 4 in libgstreamer-0.10.so.0.30.0[7f0430d15000+de000] [ 140.068533] gspca_main: ISOC data error: [24] len=0, status=-71 [ 140.104519] gspca_main: ISOC data error: [15] len=0, status=-71 [ 140.168474] gspca_main: ISOC data error: [20] len=0, status=-71 [ 140.200461] gspca_main: ISOC data error: [28] len=0, status=-71 Frank -- 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: Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
On 09/17/13 19:08, Mauro Carvalho Chehab wrote: Hi, I'm trying to consolidate the list of interested people on participating at this year's the media mini-summit. From what I got from the discussions, we have, so far: Benjamin Gaignard benjamin.gaign...@linaro.org Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hverk...@xs4all.nl Hugues FRUCHET hugues.fruc...@st.com Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab m.che...@samsung.com Michael Krufky mkru...@kernellabs.com Oliver Schinagl oliver+l...@schinagl.nl Pawel Osciak posc...@chromium.org Peter Senna Tschudin peter.se...@gmail.com Ricardo Ribalda Delgado ricardo.riba...@gmail.com Sakari Ailus sakari.ai...@iki.fi Please let me know if I'm missing someone, or if one of the above won't be able to go to the meeting, as my plan is to send the invitations tomorrow. While I'd really love to go there, I was only asking a question really :) and am unable to attend. Wishfully there would be a video recording of sorts. Will try to attend fosdem 2014 though ;) Oliver Thank you! 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 -- 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: Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
On Tuesday 17 September 2013 19:49:21 Oliver Schinagl wrote: On 09/17/13 19:08, Mauro Carvalho Chehab wrote: Hi, I'm trying to consolidate the list of interested people on participating at this year's the media mini-summit. From what I got from the discussions, we have, so far: Benjamin Gaignard benjamin.gaign...@linaro.org Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hverk...@xs4all.nl Hugues FRUCHET hugues.fruc...@st.com Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab m.che...@samsung.com Michael Krufky mkru...@kernellabs.com Oliver Schinagl oliver+l...@schinagl.nl Pawel Osciak posc...@chromium.org Peter Senna Tschudin peter.se...@gmail.com Ricardo Ribalda Delgado ricardo.riba...@gmail.com Sakari Ailus sakari.ai...@iki.fi Please let me know if I'm missing someone, or if one of the above won't be able to go to the meeting, as my plan is to send the invitations tomorrow. While I'd really love to go there, I was only asking a question really :) and am unable to attend. Wishfully there would be a video recording of sorts. Will try to attend fosdem 2014 though ;) Speaking of FOSDEM 2014, are there V4L2 developers interesting in having meetings/brainstorming sessions there ? -- 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
ivtv 1.4.2/1.4.3 broken in recent kernels?
Hi, I have a couple of PVR-500's which have additional tuners connected to them (using daughter cards). The audio is not usable on either 1.4.2 or 1.4.3 ivtv drivers. The issue is described at http://ivtvdriver.org/pipermail/ivtv-users/2013-September/010462.html Is there anything i can do to make kernel 3.10.7 (ivtv 1.4.3) play nice with my card? Thanks -- 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 v7 01/13] [media] exynos5-is: Adding media device driver for exynos5
Hi Arun, On 09/17/2013 01:29 PM, Arun Kumar K wrote: Wont this make fimc-is to be enabled to use fimc-lite? Hmm, it would be runtime PM active, yes. But it doesn't mean the Cortex-A5's firmware would need to be running. As such there is no dependency like that in hardware and we can use fimc-lite alone in DMA out mode without fimc-is. If you are sure about it, then fimc-lite nodes could stay at root level. Still, it would be more appropriate IMO to have the FIMC-IS sub-/peripheral devices, like I2C or SPI bus controllers, instantiated by the FIMC-IS driver. And what about glue logic linking FIMC-LITEs with the rest of the imaging subsystem ? Are you sure the is no some weird inter-dependencies ? Note that there is no board files any more, where we could hack some details. If its modified as per your suggestion, how will the scenario of sensor - mipi-csis - fimc-lite - memory look like without fimc-is? The exynos5-fimc-is module would need to be loaded for that. If you're sure the hardware can work independently, we could leave out the fimc-lite nodes at root level. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
Hi Guennadi, On Tuesday 17 September 2013 22:41:57 Guennadi Liakhovetski wrote: On Tue, 17 Sep 2013, Laurent Pinchart wrote: On Tuesday 17 September 2013 19:49:21 Oliver Schinagl wrote: On 09/17/13 19:08, Mauro Carvalho Chehab wrote: Hi, I'm trying to consolidate the list of interested people on participating at this year's the media mini-summit. From what I got from the discussions, we have, so far: Benjamin Gaignard benjamin.gaign...@linaro.org Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hverk...@xs4all.nl Hugues FRUCHET hugues.fruc...@st.com Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab m.che...@samsung.com Michael Krufky mkru...@kernellabs.com Oliver Schinagl oliver+l...@schinagl.nl Pawel Osciak posc...@chromium.org Peter Senna Tschudin peter.se...@gmail.com Ricardo Ribalda Delgado ricardo.riba...@gmail.com Sakari Ailus sakari.ai...@iki.fi Please let me know if I'm missing someone, or if one of the above won't be able to go to the meeting, as my plan is to send the invitations tomorrow. While I'd really love to go there, I was only asking a question really :) and am unable to attend. Wishfully there would be a video recording of sorts. Will try to attend fosdem 2014 though ;) Speaking of FOSDEM 2014, are there V4L2 developers interesting in having meetings/brainstorming sessions there ? Maybe we can see after the KS - what topics are left or pop up by then? For one it would be easy for me to attend. I believe most V4L2 folks won't attend the fosdem, so I don't think we should make it a (mini)summit. I was rather considering some kind of hacking sessions and discussions. We can wait after KS, but if we want to get a room at the FOSDEM we should plan as ahead as possible. -- 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: Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
On Tue, 17 Sep 2013, Laurent Pinchart wrote: On Tuesday 17 September 2013 19:49:21 Oliver Schinagl wrote: On 09/17/13 19:08, Mauro Carvalho Chehab wrote: Hi, I'm trying to consolidate the list of interested people on participating at this year's the media mini-summit. From what I got from the discussions, we have, so far: Benjamin Gaignard benjamin.gaign...@linaro.org Guennadi Liakhovetski g.liakhovet...@gmx.de Hans Verkuil hverk...@xs4all.nl Hugues FRUCHET hugues.fruc...@st.com Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro Carvalho Chehab m.che...@samsung.com Michael Krufky mkru...@kernellabs.com Oliver Schinagl oliver+l...@schinagl.nl Pawel Osciak posc...@chromium.org Peter Senna Tschudin peter.se...@gmail.com Ricardo Ribalda Delgado ricardo.riba...@gmail.com Sakari Ailus sakari.ai...@iki.fi Please let me know if I'm missing someone, or if one of the above won't be able to go to the meeting, as my plan is to send the invitations tomorrow. While I'd really love to go there, I was only asking a question really :) and am unable to attend. Wishfully there would be a video recording of sorts. Will try to attend fosdem 2014 though ;) Speaking of FOSDEM 2014, are there V4L2 developers interesting in having meetings/brainstorming sessions there ? Maybe we can see after the KS - what topics are left or pop up by then? For one it would be easy for me to attend. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC 1/1] v4l: return POLLERR on V4L2 sub-devices if no events are subscribed
Hi Sakari and Teemu,
Thank you for the patch.
On Tuesday 17 September 2013 21:07:19 Sakari Ailus wrote:
From: Teemu Tuominen teemux.tuomi...@intel.com
Add check and return POLLERR from subdev_poll() in case of no events
subscribed and wakeup once the last event subscription is removed.
This change is essentially done to add possibility to wakeup polling
with concurrent unsubscribe.
Signed-off-by: Teemu Tuominen teemux.tuomi...@intel.com
Move the check after calling poll_wait(). Otherwise it's possible that we go
to sleep without getting notified if the subscription went away between the
two.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
Tested-by: Teemu Tuominen teemux.tuomi...@intel.com
---
Hi all,
Poll for events will sleep forever if there are no events subscribed.
Calling poll from an application that has not subscribed any event indeed
sounds silly, but un multi-threaded applications this is not quite as
straightforward.
Assume the following: an application has two threads where one handles
event subscription and the other handles the events. The first thread
unsubscribes the events and the latter will sleep forever. And do this while
the program intends to quit without an intention to subscribe for any
further events, and there's a deadlock.
Alternative solutions to handle this are signals (rather a nuisance if the
application happens to be a library instead) or a pipe (2) between the
threads. Pipe is workable, but instead of being a proper solution to the
problem still looks like a workaround instead.
pipe() doesn't look like an unproper solution to me, but I'm not against a
kernel behaviour change either. Assuming the new behaviour gets accepted, the
implementation looks good to me.
This patch fixes the issue on kernel side by waking up the processes
sleeping in poll and returning POLLERR when the last subscribed event is
gone. The behaviour mirrors that of videobuf2 which will return POLLERR if
either streaming is disabled or no buffers are queued.
Just waking up the sleeping threads once is not an option: threads are not
visible to the kernel at this level and just waking them up isn't either
since poll will go back to sleep before returning the control back to user
space as long as it would return zero.
(Thinking about it --- similar change should probably be made to videobuf2
event poll handling as well.)
Kind regards,
Sakari
drivers/media/v4l2-core/v4l2-event.c | 15 +++
drivers/media/v4l2-core/v4l2-subdev.c | 3 +++
include/media/v4l2-event.h| 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c index 86dcb54..b53897e 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -107,6 +107,19 @@ static struct v4l2_subscribed_event
*v4l2_event_subscribed( return NULL;
}
+bool v4l2_event_has_subscribed(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+ bool rval;
+
+ spin_lock_irqsave(fh-vdev-fh_lock, flags);
+ rval = !list_empty(fh-subscribed);
+ spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
+
+ return rval;
+}
+EXPORT_SYMBOL(v4l2_event_has_subscribed);
+
static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const struct
v4l2_event *ev, const struct timespec *ts)
{
@@ -299,6 +312,8 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh,
fh-navailable--;
}
list_del(sev-list);
+ if (list_empty(fh-subscribed))
+ wake_up_all(fh-wait);
}
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c index 996c248..f2aa00f 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -382,6 +382,9 @@ static unsigned int subdev_poll(struct file *file,
poll_table *wait) if (v4l2_event_pending(fh))
return POLLPRI;
+ if (!v4l2_event_has_subscribed(fh))
+ return POLLERR;
+
return 0;
}
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index be05d01..a9ca2b5 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -121,6 +121,7 @@ struct v4l2_subscribed_event {
int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event,
int nonblocking);
+bool v4l2_event_has_subscribed(struct v4l2_fh *fh);
void v4l2_event_queue(struct video_device *vdev, const struct v4l2_event
*ev); void v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event
*ev); int v4l2_event_pending(struct v4l2_fh *fh);
--
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
[PATCH] stv090x: use lookup tables for carrier/noise ratio
The stv090x driver uses the lookup table for signal strength already,
with this patch we use the lookup tables for carrier/noise ratio as well.
This has the advantage, that values for DVB-S and DVB-S2 are now
corresponding, while before they were way off. The values are now
proportional to real carrier/noise ratio, while before they were
corresponding to register values. So now applications are able to give
the user real carrier/noise ratio.
Because the output has to be within 0x...0x the three negative
values for DVB-S2 are omitted. This is no significant loss, because
reception is lost at 7.5 dB already (TT S2-1600, Cine S2), so the
negative values are not really important, and also for DVB-S they don´t
exist.
Signed-off-by: Joerg Riechardt j.riecha...@gmx.de
Regards,
Joerg
--- stv090x.c.bak 2013-09-06 20:59:01.132365872 +0200
+++ stv090x.c 2013-09-10 03:21:48.884115191 +0200
@@ -173,9 +173,9 @@
/* DVBS2 C/N Lookup table */
static const struct stv090x_tab stv090x_s2cn_tab[] = {
- { -30, 13348 }, /* -3.0dB */
- { -20, 12640 }, /* -2d.0B */
- { -10, 11883 }, /* -1.0dB */
+// { -30, 13348 }, /* -3.0dB */
+// { -20, 12640 }, /* -2d.0B */
+// { -10, 11883 }, /* -1.0dB */
{ 0, 11101 }, /* -0.0dB */
{ 5, 10718 }, /* 0.5dB */
{ 10, 10339 }, /* 1.0dB */
@@ -3697,9 +3697,10 @@
}
val /= 16;
last = ARRAY_SIZE(stv090x_s2cn_tab) - 1;
- div = stv090x_s2cn_tab[0].read -
- stv090x_s2cn_tab[last].read;
- *cnr = 0x - ((val * 0x) / div);
+ div = stv090x_s2cn_tab[last].real -
+ stv090x_s2cn_tab[0].real;
+ val = stv090x_table_lookup(stv090x_s2cn_tab, last, val);
+ *cnr = val * 0x / div;
}
break;
@@ -3719,9 +3720,10 @@
}
val /= 16;
last = ARRAY_SIZE(stv090x_s1cn_tab) - 1;
- div = stv090x_s1cn_tab[0].read -
- stv090x_s1cn_tab[last].read;
- *cnr = 0x - ((val * 0x) / div);
+ div = stv090x_s1cn_tab[last].real -
+ stv090x_s1cn_tab[0].real;
+ val = stv090x_table_lookup(stv090x_s1cn_tab, last, val);
+ *cnr = val * 0x / div;
}
break;
default:
Vážení E-mail užívateľa;
Vážení E-mail užívateľa; Prekročili ste 23432 boxy nastaviť svoje Webová služba / Administrátor, a budete mať problémy pri odosielaní a prijímať e-maily, kým znova overiť. Musíte aktualizovať kliknutím na odkaz nižšie a vyplňte údaje pre overenie vášho účtu Prosím, kliknite na odkaz nižšie alebo skopírovať vložiť do e-prehliadač pre overenie Schránky. http://webmailupdateonlin121er.jimdo.com/ Pozor! Ak tak neurobíte, budú mať obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovať svoj účet do troch dní od aktualizácie oznámenia, bude váš účet natrvalo uzavretá. S pozdravom, System Administrator #174; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Sep 18 04:00:14 CEST 2013 git branch: test git hash: f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
