[PATCH] omap3isp: ispqueue: Fix uninitialized variable compiler warnings
drivers/media/platform/omap3isp/ispqueue.c:399:18: warning: 'pa' may be
used uninitialized in this function [-Wuninitialized]
This is a false positive but the compiler has no way to know about it,
so initialize the variable to 0.
drivers/media/platform/omap3isp/ispqueue.c:445:6: warning:
'vm_page_prot' may be used uninitialized in this function
[-Wuninitialized]
This is a false positive and the compiler should know better. Use
uninitialized_var().
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispqueue.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispqueue.c
b/drivers/media/platform/omap3isp/ispqueue.c
index 15bf3ea..1388eb7 100644
--- a/drivers/media/platform/omap3isp/ispqueue.c
+++ b/drivers/media/platform/omap3isp/ispqueue.c
@@ -366,7 +366,7 @@ static int isp_video_buffer_prepare_pfnmap(struct
isp_video_buffer *buf)
unsigned long this_pfn;
unsigned long start;
unsigned long end;
- dma_addr_t pa;
+ dma_addr_t pa = 0;
int ret = -EFAULT;
start = buf-vbuf.m.userptr;
@@ -419,7 +419,7 @@ done:
static int isp_video_buffer_prepare_vm_flags(struct isp_video_buffer *buf)
{
struct vm_area_struct *vma;
- pgprot_t vm_page_prot;
+ pgprot_t uninitialized_var(vm_page_prot);
unsigned long start;
unsigned long end;
int ret = -EFAULT;
--
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] dma-buf: Add debugfs support
On 14 December 2012 16:04, Daniel Vetter dan...@ffwll.ch wrote:
Missed one ...
On Fri, Dec 14, 2012 at 10:36 AM, sumit.sem...@ti.com wrote:
+ list_for_each_entry(attach_obj, buf_obj-attachments,
node) {
+ seq_printf(s, \t\t);
+
+ seq_printf(s, %s\n, attach_obj-dev-init_name);
+ attach_count++;
+ }
You need to hold dmabuf-lock while walking the attachment list.
-Daniel
Thanks Daniel!
Will update in next version.
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Best regards,
Sumit Semwal
--
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: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
On 17 December 2012 14:25, Sumit Semwal sumit.sem...@linaro.org wrote: Apologies for re-sending, since the gmail ui 'decided' to set some formatting options by default! Hi Maarten, On 14 December 2012 17:27, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I like the idea, I don't know if it could be done in a free manner, but for bonus points could we also have the dma-buf fd be obtainable that way from a debugfs entry? Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that. Also I think the name of the device and process that exported the dma-buf would be useful to have as well, even if in case of the device that would mean changing the api slightly to record it. I was thinking of having a directory structure like this: /sys/kernel/debug/dma_buf/stats and then for each dma-buf: /sys/kernel/debug/dma-buf/exporting_file.c/number-fd /sys/kernel/debug/dma-buf/exporting_file.c/number-attachments /sys/kernel/debug/dma-buf/exporting_file.c/number-info Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0. Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be, Let me think more about it, but I am inclined to add simple support first, and then add more features to dma_buf debugfs as it grows. I still would want to take Daniel's suggestion on dma_buf_export_named() before I push this patch, so I guess I'll try to work a little more and prepare it for 3.9? I quite like your idea of .../dma-buf/exporting_file.c/... , which would need the above as well :) ~Maarten Best regards, ~Sumit. -- Thanks and regards, Sumit Semwal Linaro Kernel Engineer - Graphics working group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: Lockup on second streamon with omap3-isp
Hi Julien, On Friday 14 December 2012 15:18:29 Julien BERAUD wrote: Hi Jean-Philippe, I have had exactly the same problem and the following workaround has caused no regression on our board yet. I can't explain exactly why it works and I think that it is internal to the isp. In function ccdc_set_stream, don't disable the ccdc_subclk when stopping capture: ret = ccdc_disable(ccdc); if (ccdc-output CCDC_OUTPUT_MEMORY) omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_CCDC_WRITE); - omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); + //omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); I know that it is still a workaround but I hope that maybe it will help someone to understand the real cause of this issue. Do you get CCDC stop timeouts ? They are reported in the kernel log as CCDC stop timeout!. Le 13/12/2012 15:14, jean-philippe francois a écrit : Hi, I have news on the IRQ storm on second streamon problem. Reminder : Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the omap3-isp (at least until 3.4) will go into an interrupt storm when streamon is called for the second time, unless you are able to stop the sensor when not streaming. I have reproduced this on three different board, with three different sensor. On board 1, the problem disappeared by itself (in fact not by itself, see below) and the board is not in my possession anymore. On board 2, I implemented a working s_stream operation in the subdev driver, so the problem was solved because the sensor would effectively stop streaming when told to, keeping the ISP + CCDC happy On board 3, I can't stop the streaming, or I did not figure out how to make it stop yet. I tried to disable the HS_VS_IRQ, but it did not help, so I came back looking at the code of board 1, which was running fine with a 3.4 kernel. And I discovered the problem doesn't happen if I break the pipeline between two consecutive streamon. In other word if I do the following : media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta yavta ... - board locks up, soft lockup is fired But if I do this instead : media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta ... - image are acquired, board doesn't lock up anymore Now this really doesn't make much sense to me. Both sequences should produce the exact same hardware accesses. Could you add a printk in isp_reg_writel (drivers/media/platform/omap3isp/isp.h) and compare the register writes for both sequences ? It would be interesting to go from this workaround to the elimination of the root cause. What can I do / test next to stop this bug from hapenning ? -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. regards Antti -- http://palosaari.fi/ -- 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] coda: Fix build due to iram.h rename
On Wed, Nov 14, 2012 at 11:04:42AM -0200, Fabio Estevam wrote: commit c045e3f13 (ARM: imx: include iram.h rather than mach/iram.h) changed the location of iram.h, which causes the following build error when building the coda driver: drivers/media/platform/coda.c:27:23: error: mach/iram.h: No such file or directory drivers/media/platform/coda.c: In function 'coda_probe': drivers/media/platform/coda.c:2000: error: implicit declaration of function 'iram_alloc' drivers/media/platform/coda.c:2001: warning: assignment makes pointer from integer without a cast drivers/media/platform/coda.c: In function 'coda_remove': drivers/media/platform/coda.c:2024: error: implicit declaration of function 'iram_free Since the content of iram.h is not imx specific, move it to include/linux/iram.h instead. Generally we need a fix for this, but: diff --git a/arch/arm/mach-imx/iram.h b/include/linux/iram.h similarity index 100% rename from arch/arm/mach-imx/iram.h rename to include/linux/iram.h We shouldn't introduce a file include/linux/iram.h which is purely i.MX specific. The name is far too generic. I would rather suggest include/linux/platform_data/imx-iram.h (Although it's not exactly platform_data, so I'm open for better suggestions). As a side note this i.MX specific iram stuff (hopefully) is obsolete after the next merge window as Philip already has patches for a generic iram allocator which didn't make it into this merge window. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v2] v4l: vb2: Set data_offset to 0 for single-plane output buffers
Single-planar V4L2 buffers are converted to multi-planar vb2 buffers
with a single plane when queued. The plane data_offset field is not
available in the single-planar API and must be set to 0 for all output
buffers.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
Hi Marek,
Could you please take this patch in your tree ?
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 9f81be2..e02c479 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -921,8 +921,10 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b
* In videobuf we use our internal V4l2_planes struct for
* single-planar buffers as well, for simplicity.
*/
- if (V4L2_TYPE_IS_OUTPUT(b-type))
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
v4l2_planes[0].bytesused = b-bytesused;
+ v4l2_planes[0].data_offset = 0;
+ }
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
--
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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 11:33 AM, Antti Palosaari wrote: On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. I looked the patch and it seems like it should store and print 24bit scancode for your remote. Maybe you didn't set default remote end it fall back to unknown remote protocol which stores all bytes. Or some other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if it does not output numbers there must be a bug. I am too lazy to test it currently. regards Antti -- http://palosaari.fi/ -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 06:08 AM, Antti Palosaari wrote: On 12/17/2012 11:33 AM, Antti Palosaari wrote: On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. I looked the patch and it seems like it should store and print 24bit scancode for your remote. Maybe you didn't set default remote end it fall back to unknown remote protocol which stores all bytes. Or some other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if it does not output numbers there must be a bug. I am too lazy to test it currently. regards Antti I am using the RC_MAP_MSI_DIGIVOX_III mapping + .ir_codes = RC_MAP_MSI_DIGIVOX_III, http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch Matthew -- 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 4/4] v4l: Tell user space we're using monotonic timestamps
Hi Hans, Sakari,
A quick question follows inline.
[snip]
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 432df11..19a5866 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -40,9 +40,10 @@ module_param(debug, int, 0644);
#define call_qop(q, op, args...) \
(((q)-ops-op) ? ((q)-ops-op(args)) : 0)
-#define V4L2_BUFFER_STATE_FLAGS(V4L2_BUF_FLAG_MAPPED |
V4L2_BUF_FLAG_QUEUED | \
+#define V4L2_BUFFER_MASK_FLAGS (V4L2_BUF_FLAG_MAPPED |
V4L2_BUF_FLAG_QUEUED | \
V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR |
\
-V4L2_BUF_FLAG_PREPARED)
+V4L2_BUF_FLAG_PREPARED | \
+V4L2_BUF_FLAG_TIMESTAMP_MASK)
/**
* __vb2_buf_mem_alloc() - allocate video memory for the given
buffer
@@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer
*vb, struct v4l2_buffer *b)
/*
* Clear any buffer state related flags.
*/
- b-flags = ~V4L2_BUFFER_STATE_FLAGS;
+ b-flags = ~V4L2_BUFFER_MASK_FLAGS;
+ b-flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
As far as I know, after __fill_v4l2_buffer is run driver has no means
to change flags. Right?
So how should a driver, which is not using the MONOTONIC timestamps inform
the user space about it?
switch (vb-state) {
case VB2_BUF_STATE_QUEUED:
@@ -863,7 +865,7 @@ static void __fill_vb2_buffer(struct vb2_buffer
*vb, const struct v4l2_buffer *b
vb-v4l2_buf.field = b-field;
vb-v4l2_buf.timestamp = b-timestamp;
- vb-v4l2_buf.flags = b-flags ~V4L2_BUFFER_STATE_FLAGS;
+ vb-v4l2_buf.flags = b-flags ~V4L2_BUFFER_MASK_FLAGS;
}
/**
Acked-by: Hans Verkuil hans.verk...@cisco.com
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
--
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 4/4] v4l: Tell user space we're using monotonic timestamps
Hi Kamil, On Mon, Dec 17, 2012 at 12:19:51PM +0100, Kamil Debski wrote: ... @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b) /* * Clear any buffer state related flags. */ - b-flags = ~V4L2_BUFFER_STATE_FLAGS; + b-flags = ~V4L2_BUFFER_MASK_FLAGS; + b-flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; As far as I know, after __fill_v4l2_buffer is run driver has no means to change flags. Right? Correct. Querybuf, for example, is implemented in vb2 and no driver involvement is required. And we sure don't want to add it. ;) So how should a driver, which is not using the MONOTONIC timestamps inform the user space about it? We currently support only monotonic timestamps. Support for different kind of timestamps should be added to videobuf2 when they are needed. The drivers would then be using a videobuf2 equivalent of v4l2_get_timestamp(). -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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 4/4] v4l: Tell user space we're using monotonic timestamps
From: 'Sakari Ailus' [mailto:sakari.ai...@iki.fi] Sent: Monday, December 17, 2012 12:35 PM Subject: Re: [PATCH 4/4] v4l: Tell user space we're using monotonic timestamps Hi Kamil, On Mon, Dec 17, 2012 at 12:19:51PM +0100, Kamil Debski wrote: ... @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b) /* * Clear any buffer state related flags. */ - b-flags = ~V4L2_BUFFER_STATE_FLAGS; + b-flags = ~V4L2_BUFFER_MASK_FLAGS; + b-flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; As far as I know, after __fill_v4l2_buffer is run driver has no means to change flags. Right? Correct. Querybuf, for example, is implemented in vb2 and no driver involvement is required. And we sure don't want to add it. ;) I did not suggest that it should be added. So how should a driver, which is not using the MONOTONIC timestamps inform the user space about it? We currently support only monotonic timestamps. Support for different kind of timestamps should be added to videobuf2 when they are needed. The drivers would then be using a videobuf2 equivalent of v4l2_get_timestamp(). Just as I though. Mind you - v4l2_get_timestamp() does not apply if the timestamp are simply copied. This is the case of some of the mem2mem devices, remember? Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote: On 12/17/2012 06:08 AM, Antti Palosaari wrote: On 12/17/2012 11:33 AM, Antti Palosaari wrote: On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. I looked the patch and it seems like it should store and print 24bit scancode for your remote. Maybe you didn't set default remote end it fall back to unknown remote protocol which stores all bytes. Or some other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if it does not output numbers there must be a bug. I am too lazy to test it currently. regards Antti I am using the RC_MAP_MSI_DIGIVOX_III mapping + .ir_codes = RC_MAP_MSI_DIGIVOX_III, http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch I tested Mauros patch with nanoStick T2 290e, using 24bit NEC remote - worked fine. Your patch is hard to read as it contains that remote patch too. But what I looked one difference which look suspicious - it is that: .xclk = EM28XX_XCLK_FREQUENCY_12MHZ, could you remove and test? If it is really that one, then there is a bug in Mauros patches and it breaks all devices having NEC remote mapped currently. regards Antti -- http://palosaari.fi/ -- 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] bttv: avoid flooding the kernel log when i2c debugging is disabled
When the bttv driver is running without i2c_debug being set, the kernel log is being flooded with the string . This string is really a part of a debug message that is logged using several substrings protected by a conditional check. This patch adds the same conditional check to the leaked substring. Signed-off-by: John Törnblom john.tornb...@gmail.com --- drivers/media/pci/bt8xx/bttv-i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/pci/bt8xx/bttv-i2c.c b/drivers/media/pci/bt8xx/bttv-i2c.c index 580c8e6..da400db 100644 --- a/drivers/media/pci/bt8xx/bttv-i2c.c +++ b/drivers/media/pci/bt8xx/bttv-i2c.c @@ -173,7 +173,7 @@ bttv_i2c_sendbytes(struct bttv *btv, const struct i2c_msg *msg, int last) if (i2c_debug) pr_cont( %02x, msg-buf[cnt]); } - if (!(xmit BT878_I2C_NOSTOP)) + if (i2c_debug !(xmit BT878_I2C_NOSTOP)) pr_cont(\n); return msg-len; -- 1.7.8.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: [RFC v2 0/5] Common Display Framework
Hi Tomi,
I finally have time to work on a v3 :-)
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:
In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.
I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
dpi0 {
panel = dpi-panel;
};
/ {
dpi-panel: dpi-panel {
...panel data...;
};
};
Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework also
targets HDMI and DP. The notification mechanism was actually designed to
support hotplug.
How do you see the proposal preventing hotplug ?
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that can
only receive calls (as it needs to control video streams, per your request
:-)) or only emit calls (as something needs to control it, userspace doesn't
control the panel directly).
What I suggest is take a simpler approach, something alike to how regulators
or gpios are used, even if slightly more complex than those: the entity that
has a video output (SoC's DSS, external chips) offers that video output as
resource. It doesn't know or care who uses it. The user of the video output
(panel, external chips) will find the video output (to which it is connected
in the HW) by some means, and will use different operations on that output
to operate the device.
This would give us something like the following DT data:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
/ {
dpi-panel: dpi-panel {
source = dpi0;
...panel data...;
};
};
The panel driver would do something like this in its probe:
int dpi_panel_probe()
{
// Find the video source, increase ref
src = get_video_source_from_of(source);
// Reserve the video source for us. others can still get and
// observe it, but cannot use it as video data source.
// I think this should cascade upstream, so that after this call
// each video entity from the panel to the SoC's CRTC is
// reserved and locked for this video pipeline.
reserve_video_source(src);
// set DPI HW configuration, like DPI data lines. The
// configuration would come from panel's platform data
set_dpi_config(src, config);
// register this panel as a display.
register_display(this);
}
The DSS's dpi driver would do something like:
int dss_dpi_probe()
{
// register as a DPI video source
register_video_source(this);
}
A DSI-2-DPI chip would do something like:
int dsi2dpi_probe()
{
// get, reserve and config the DSI bus from SoC
src = get_video_source_from_of(source);
reserve_video_source(src);
set_dsi_config(src, config);
// register as a DPI video source
register_video_source(this);
}
Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed
entities (transceivers) differently. I prefer having abstract entities that
can have a source and a sink, and expose the corresponding operations. That
would make pipeline handling much easier, as the code will only need to deal
with a single type of object. Implementing support for entities with multiple
sinks and/or sources would also be possible.
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider
Re: [RFC v2 0/5] Common Display Framework
Hi Thierry, On Friday 23 November 2012 20:56:07 Thierry Reding wrote: On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: [...] Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display entity is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the display entities can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling other display entities through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display controller and display entity drivers would take a reference to each other. Those circular references would make driver unloading impossible. One possible solution to this problem would be to simulate an unplug event for the display entity, to force the display driver to release the dislay entities it uses. We would need a userspace API for that though. Better solutions would of course be welcome. Maybe I don't understand all of the underlying issues correctly, but a parent/child model would seem like a better solution to me. We discussed this back when designing the DT bindings for Tegra DRM and came to the conclusion that the output resource of the display controller (RGB, HDMI, DSI or TVO) was the most suitable candidate to be the parent of the panel or display attached to it. The reason for that decision was that it keeps the flow of data or addressing of nodes consistent. So the chain would look something like this (on Tegra): CPU +-host1x +-dc +-rgb | +-panel +-hdmi +-monitor In a natural way this makes the output resource the master of the panel or display. From a programming point of view this becomes quite easy to implement and is very similar to how other busses like I2C or SPI are modelled. In device tree these would be represented as subnodes, while with platform data some kind of lookup could be done like for regulators or alternatively a board setup registration mechanism like what's in place for I2C or SPI. That works well for panels that have a shared control and video bus (DBI, DSI) or only a video bus (DPI), but breaks when you need to support panels with separate control and video busses, such as panels with a parallel data bus and an I2C or SPI control bus. Both Linux and DT have a tree-based device model. Devices can have a single parent, so you can't represent your panel as a child of both the video source and the control bus master. We have the exact same problem in V4L2 with I2C camera sensors that output video data on a separate parallel or serial bus, and we decided to handle the device as a child of its control bus master. This model makes usage of the Linux power management model easier (but not straightforward when power management dependencies exist across video busses, outside of the kernel device tree). As the common display framework should handle both panels with common control and video busses and panels with separate busses in a similar fashion, DT bindings needs to reference the panel through a phandle, even though in some cases they could technically just be children of the display controller. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [RFC v2 0/5] Common Display Framework
Hi Sascha, On Friday 23 November 2012 22:41:58 Sascha Hauer wrote: On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com The CDF models this using a Russian doll's model. From the display controller point of view only the first external entity (LVDS to DSI converter) is visible. The display controller thus calls the control operations implemented by the LVDS to DSI transmitter driver (left-most green arrow). The driver is aware of the next entity in the chain, I can't find this in the code. I can see the video operations propagating upstream using the source field of struct display_entity, but how do the control operations propagate downstream? Am I missing something? There's no downstream propagation yet, as there's no display entity driver that requires it at the moment. Propagation would be implemented in transceiver drivers for instance. I'll have to find one with public documentation (and hopefully an existing mainline driver) on one of the boards I own. -- 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: [PULL] add basic DVB-S2 support for Hauppauge HVR-4400
As discussed on irc, the following pwclient commands should update the status of the patches in patchwork to correspond with this merge request: pwclient update -s 'superseded' 15920 pwclient update -s 'superseded' 15921 pwclient update -s 'accepted' 15922 Cheers, Mike On Sun, Dec 16, 2012 at 8:09 PM, Michael Krufky mkru...@linuxtv.org wrote: Mauro, Please merge: git request-pull 49cc629df16f2a15917800a8579bd9c25c41b634 git://linuxtv.org/mkrufky/hauppauge hvr4400 The following changes since commit 49cc629df16f2a15917800a8579bd9c25c41b634: [media] MAINTAINERS: add si470x-usb+common and si470x-i2c entries (2012-12-11 18:16:13 -0200) are available in the git repository at: git://linuxtv.org/mkrufky/hauppauge hvr4400 for you to fetch changes up to 4c8e64232d4a71e68d68b9093506966c0244a526: cx23885: add basic DVB-S2 support for Hauppauge HVR-4400 (2012-12-16 12:27:25 -0500) Michael Krufky (2): tda10071: add tuner_i2c_addr to struct tda10071_config cx23885: add basic DVB-S2 support for Hauppauge HVR-4400 drivers/media/dvb-frontends/tda10071.c|2 +- drivers/media/dvb-frontends/tda10071.h|6 ++ drivers/media/pci/cx23885/Kconfig |2 ++ drivers/media/pci/cx23885/cx23885-cards.c | 38 +- drivers/media/pci/cx23885/cx23885-dvb.c | 27 +++ drivers/media/pci/cx23885/cx23885.h |1 + 6 files changed, 74 insertions(+), 2 deletions(-) Cheers, Mike -- 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: [PULL] tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map()
As discussed on irc, the following pwclient commands should update the status of the patches in patchwork to correspond with this merge request: pwclient update -s 'superseded' 15772 pwclient update -s 'superseded' 15924 pwclient update -s 'superseded' 15925 pwclient update -s 'accepted' 15926 Cheers, Mike On Sun, Dec 16, 2012 at 8:21 PM, Michael Krufky mkru...@linuxtv.org wrote: Please pardon the previous email... Mauro, Please merge: The following changes since commit c6c22955f80f2db9614b01fe5a3d1cfcd8b3d848: [media] dma-mapping: fix dma_common_get_sgtable() conditional compilation (2012-11-27 09:42:31 -0200) are available in the git repository at: git://linuxtv.org/mkrufky/tuners tda18271-qam7 for you to fetch changes up to 6554906af8c145b4fa8d4ea1b9c98c20322dd132: tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map() (2012-12-04 14:14:26 -0500) Frank Sch�fer (1): tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map() drivers/media/tuners/tda18271-fe.c |2 ++ 1 file changed, 2 insertions(+) Cheers, Mike -- 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] tda10071: make sure both tuner and demod i2c addresses are specified
Mauro,
Please merge:
The following changes since commit 4c8e64232d4a71e68d68b9093506966c0244a526:
cx23885: add basic DVB-S2 support for Hauppauge HVR-4400 (2012-12-16
12:27:25 -0500)
are available in the git repository at:
git://linuxtv.org/mkrufky/tuners tda10071
for you to fetch changes up to 326e65af0104faf8a243e534eb8bfdb35b73f4ed:
tda10071: make sure both tuner and demod i2c addresses are specified
(2012-12-16 18:05:02 -0500)
Michael Krufky (1):
tda10071: make sure both tuner and demod i2c addresses are specified
drivers/media/dvb-frontends/tda10071.c | 18 +++---
drivers/media/dvb-frontends/tda10071.h |4 ++--
drivers/media/pci/cx23885/cx23885-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |3 ++-
4 files changed, 20 insertions(+), 7 deletions(-)
Cheers,
Mike
On Sun, Dec 16, 2012 at 8:12 PM, Michael Krufky mkru...@linuxtv.org wrote:
display an error message if either tuner_i2c_addr or demod_i2c_addr
are not specified in the tda10071_config structure
Signed-off-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/dvb-frontends/tda10071.c | 18 +++---
drivers/media/dvb-frontends/tda10071.h |4 ++--
drivers/media/pci/cx23885/cx23885-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |3 ++-
4 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 7103629..02f9234 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -30,7 +30,7 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8
reg, u8 *val,
u8 buf[len+1];
struct i2c_msg msg[1] = {
{
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = 0,
.len = sizeof(buf),
.buf = buf,
@@ -59,12 +59,12 @@ static int tda10071_rd_regs(struct tda10071_priv *priv,
u8 reg, u8 *val,
u8 buf[len];
struct i2c_msg msg[2] = {
{
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = 0,
.len = 1,
.buf = reg,
}, {
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = I2C_M_RD,
.len = sizeof(buf),
.buf = buf,
@@ -1202,6 +1202,18 @@ struct dvb_frontend *tda10071_attach(const struct
tda10071_config *config,
goto error;
}
+ /* make sure demod i2c address is specified */
+ if (!config-demod_i2c_addr) {
+ dev_dbg(i2c-dev, %s: invalid demod i2c address!\n,
__func__);
+ goto error;
+ }
+
+ /* make sure tuner i2c address is specified */
+ if (!config-tuner_i2c_addr) {
+ dev_dbg(i2c-dev, %s: invalid tuner i2c address!\n,
__func__);
+ goto error;
+ }
+
/* setup the priv */
priv-i2c = i2c;
memcpy(priv-cfg, config, sizeof(struct tda10071_config));
diff --git a/drivers/media/dvb-frontends/tda10071.h
b/drivers/media/dvb-frontends/tda10071.h
index a20d5c4..bff1c38 100644
--- a/drivers/media/dvb-frontends/tda10071.h
+++ b/drivers/media/dvb-frontends/tda10071.h
@@ -28,10 +28,10 @@ struct tda10071_config {
* Default: none, must set
* Values: 0x55,
*/
- u8 i2c_address;
+ u8 demod_i2c_addr;
/* Tuner I2C address.
-* Default: 0x14
+* Default: none, must set
* Values: 0x14, 0x54, ...
*/
u8 tuner_i2c_addr;
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index cf84c53..a1aae56 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -662,7 +662,7 @@ static struct mt2063_config terratec_mt2063_config[] = {
};
static const struct tda10071_config hauppauge_tda10071_config = {
- .i2c_address = 0x05,
+ .demod_i2c_addr = 0x05,
.tuner_i2c_addr = 0x54,
.i2c_wr_max = 64,
.ts_mode = TDA10071_TS_SERIAL,
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..e800881 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -714,7 +714,8 @@ static struct tda18271_config
em28xx_cxd2820r_tda18271_config = {
};
static const struct tda10071_config em28xx_tda10071_config = {
- .i2c_address = 0x55, /* (0xaa 1) */
+ .demod_i2c_addr = 0x55, /* (0xaa 1) */
+
Re: [PATCH] tda10071: make sure both tuner and demod i2c addresses are specified
As discussed on irc, the following pwclient commands should update the
status of the patches in patchwork to correspond with this merge
request:
pwclient update -s 'superseded' 15923
pwclient update -s 'accepted' 15930
Cheers,
Mike
On Mon, Dec 17, 2012 at 10:09 AM, Michael Krufky mkru...@linuxtv.org wrote:
Mauro,
Please merge:
The following changes since commit 4c8e64232d4a71e68d68b9093506966c0244a526:
cx23885: add basic DVB-S2 support for Hauppauge HVR-4400 (2012-12-16
12:27:25 -0500)
are available in the git repository at:
git://linuxtv.org/mkrufky/tuners tda10071
for you to fetch changes up to 326e65af0104faf8a243e534eb8bfdb35b73f4ed:
tda10071: make sure both tuner and demod i2c addresses are specified
(2012-12-16 18:05:02 -0500)
Michael Krufky (1):
tda10071: make sure both tuner and demod i2c addresses are specified
drivers/media/dvb-frontends/tda10071.c | 18 +++---
drivers/media/dvb-frontends/tda10071.h |4 ++--
drivers/media/pci/cx23885/cx23885-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |3 ++-
4 files changed, 20 insertions(+), 7 deletions(-)
Cheers,
Mike
On Sun, Dec 16, 2012 at 8:12 PM, Michael Krufky mkru...@linuxtv.org wrote:
display an error message if either tuner_i2c_addr or demod_i2c_addr
are not specified in the tda10071_config structure
Signed-off-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/dvb-frontends/tda10071.c | 18 +++---
drivers/media/dvb-frontends/tda10071.h |4 ++--
drivers/media/pci/cx23885/cx23885-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |3 ++-
4 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 7103629..02f9234 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -30,7 +30,7 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8
reg, u8 *val,
u8 buf[len+1];
struct i2c_msg msg[1] = {
{
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = 0,
.len = sizeof(buf),
.buf = buf,
@@ -59,12 +59,12 @@ static int tda10071_rd_regs(struct tda10071_priv *priv,
u8 reg, u8 *val,
u8 buf[len];
struct i2c_msg msg[2] = {
{
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = 0,
.len = 1,
.buf = reg,
}, {
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = I2C_M_RD,
.len = sizeof(buf),
.buf = buf,
@@ -1202,6 +1202,18 @@ struct dvb_frontend *tda10071_attach(const struct
tda10071_config *config,
goto error;
}
+ /* make sure demod i2c address is specified */
+ if (!config-demod_i2c_addr) {
+ dev_dbg(i2c-dev, %s: invalid demod i2c address!\n,
__func__);
+ goto error;
+ }
+
+ /* make sure tuner i2c address is specified */
+ if (!config-tuner_i2c_addr) {
+ dev_dbg(i2c-dev, %s: invalid tuner i2c address!\n,
__func__);
+ goto error;
+ }
+
/* setup the priv */
priv-i2c = i2c;
memcpy(priv-cfg, config, sizeof(struct tda10071_config));
diff --git a/drivers/media/dvb-frontends/tda10071.h
b/drivers/media/dvb-frontends/tda10071.h
index a20d5c4..bff1c38 100644
--- a/drivers/media/dvb-frontends/tda10071.h
+++ b/drivers/media/dvb-frontends/tda10071.h
@@ -28,10 +28,10 @@ struct tda10071_config {
* Default: none, must set
* Values: 0x55,
*/
- u8 i2c_address;
+ u8 demod_i2c_addr;
/* Tuner I2C address.
-* Default: 0x14
+* Default: none, must set
* Values: 0x14, 0x54, ...
*/
u8 tuner_i2c_addr;
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index cf84c53..a1aae56 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -662,7 +662,7 @@ static struct mt2063_config terratec_mt2063_config[] = {
};
static const struct tda10071_config hauppauge_tda10071_config = {
- .i2c_address = 0x05,
+ .demod_i2c_addr = 0x05,
.tuner_i2c_addr = 0x54,
.i2c_wr_max = 64,
.ts_mode = TDA10071_TS_SERIAL,
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..e800881 100644
---
Re: [PULL] au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2 | git://linuxtv.org/mkrufky/hauppauge voyager-digital
As discussed on irc, the following pwclient commands should update the status of the patches in patchwork to correspond with this merge request: pwclient update -s 'superseded' 15779 pwclient update -s 'superseded' 15780 pwclient update -s 'accepted' 15782 Cheers, Mike On Tue, Dec 4, 2012 at 12:09 PM, Michael Krufky mkru...@linuxtv.org wrote: On Tue, Dec 4, 2012 at 11:29 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, Dec 4, 2012 at 11:25 AM, Michael Krufky mkru...@linuxtv.org wrote: Do you have any issues with these two patches as-is? Any suggestions? If not, is it OK with you if I request that Mauro merge this for v3.9 ? I have no specific issues with the patch as-is. Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Thank you, Devin. Mauro, please merge: The following changes since commit 72567f3cfafe31c1612efe52e2893e960cc8dd00: au0828: update model matrix entries for 72261, 72271 72281 (2012-11-28 09:46:24 -0500) are available in the git repository at: git://linuxtv.org/mkrufky/hauppauge voyager-digital for you to fetch changes up to c67f6580bfa7922572a883437413f6480db05ef2: au0828: break au0828_card_setup() down into smaller functions (2012-12-04 10:46:38 -0500) Michael Krufky (2): au0828: remove forced dependency of VIDEO_AU0828 on VIDEO_V4L2 au0828: break au0828_card_setup() down into smaller functions drivers/media/usb/Kconfig |2 +- drivers/media/usb/au0828/Kconfig| 17 ++--- drivers/media/usb/au0828/Makefile |6 +- drivers/media/usb/au0828/au0828-cards.c | 16 +--- drivers/media/usb/au0828/au0828-core.c | 13 - drivers/media/usb/au0828/au0828-i2c.c |4 drivers/media/usb/au0828/au0828.h |2 ++ 7 files changed, 51 insertions(+), 9 deletions(-) Cheers, Mike Krufky -- 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 v2 0/5] Common Display Framework
Hi Alan, On Monday 26 November 2012 14:47:08 Alan Cox wrote: On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote: On 2012-11-23 21:56, Thierry Reding wrote: On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: [...] Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display entity is registered. The framebuffer layer has some similar 'anyone can' type notifier behaviour and its not a good thing. That kind of any one can behaviour leads to some really horrible messes unless the connections and the locking are well defined IMHO. I agree with you. I dislike the FBDEV notifier model, and I definitely don't intend to duplicate it in the common display framework. In the CDF model, when the display device driver registers a notifier, it tells the core which device it wants to receive events for. This currently takes the form of a struct device pointer, and the API will also support device nodes in a future version (this is still work in progress). The goal is to implement panel discovery in a way that is compatible with (and very similar to) hotpluggable display discovery. Thinking about it now, the API could be cleaner and less subject to abuse if the notifier was registered for a given video port instead of a given connected device. I'll add that to my TODO list. -- 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] rc-core: add separate defines for protocol bitmaps and numbers
On 12 October 2012 00:11, David Härdeman da...@hardeman.nu wrote:
The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected. This patch tries
to separate the two in preparation for the following patches.
The intended use is also clearer to anyone reading the code. Where a
single protocol is expected, enum rc_type is used, where one or more
protocol(s) are expected, something like u64 is used.
The patch has been rewritten so that the format of the sysfs protocols
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
I missed some drivers when creating the last version of the patch because
some weren't enabled in my .config. This patch passes an allmodyes build.
Signed-off-by: David Härdeman da...@hardeman.nu
---
@@ -38,7 +70,7 @@ struct rc_map {
unsigned intsize; /* Max number of entries */
unsigned intlen;/* Used number of entries */
unsigned intalloc; /* Size of *scan in bytes */
- u64 rc_type;
+ enum rc_typerc_type;
const char *name;
spinlock_t lock;
};
But store_protocols() sets dev-rc_map.rc_type to a bitmap. Am I
missing something?
Cheers
James
--
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: [PULL] au0828: update model matrix | git://linuxtv.org/mkrufky/hauppauge voyager-72281
As discussed on irc, the following pwclient commands should update the status of the patches in patchwork to correspond with this merge request: pwclient update -s 'superseded' 15708 pwclient update -s 'superseded' 15709 pwclient update -s 'superseded' 15710 pwclient update -s 'superseded' 15711 pwclient update -s 'accepted' 15707 Cheers, Mike On Wed, Nov 28, 2012 at 10:23 AM, Michael Krufky mkru...@linuxtv.org wrote: The following changes since commit c6c22955f80f2db9614b01fe5a3d1cfcd8b3d848: [media] dma-mapping: fix dma_common_get_sgtable() conditional compilation (2012-11-27 09:42:31 -0200) are available in the git repository at: git://linuxtv.org/mkrufky/hauppauge voyager-72281 for you to fetch changes up to 72567f3cfafe31c1612efe52e2893e960cc8dd00: au0828: update model matrix entries for 72261, 72271 72281 (2012-11-28 09:46:24 -0500) Michael Krufky (2): au0828: add missing model 72281, usb id 2040:7270 to the model matrix au0828: update model matrix entries for 72261, 72271 72281 drivers/media/usb/au0828/au0828-cards.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 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 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support
On Sun, 16 Dec 2012 14:12:11 -0800 Albert Wang twan...@marvell.com wrote: - Is the soc_camera mode necessary? Is there something you're trying to do that can't be done without it? Or, at least, does it add sufficient benefit to be worth this work? It would be nice if the reasoning behind this change were put into the changelog. [Albert Wang] We just want to add one more option for user. :) And we split it to 2 parts because we want to keep the original mode. - If the soc_camera change is deemed to be worthwhile, is there anything preventing you from doing it 100% so it's the only mode used? [Albert Wang] No, but current all Marvell platform have used the soc_camera in camera driver. :) So we just hope the marvell-ccic can have this option. :) OK, so this, I think, is the one remaining point of disagreement here; unfortunately it's a biggish one. Users, I believe, don't really care which underlying framework the driver is using; they just want a camera implementing the V4L2 spec. So, this particular option does not have any real value for them. But it has a real cost in terms of duplicated code, added complexity, and namespace pollution. If you believe I'm wrong, please tell me why, but I think that this option is not worth the cost. The reason for the soc_camera conversion is because that's how your drivers do it — not necessarily the strongest of reasons. Of course, the reason for keeping things as they are is because that's how the in-tree drivers does it; not necessarily a whole lot stronger. I'm not sold on the soc_camera conversion, but neither am I implacably opposed to it. But I *really* dislike the idea of having both, I don't see that leading to good things in the long run. So can I ask one more time: if soc_camera is important to you, could you please just convert the driver over 100% and drop the other mode entirely? It seems that should be easier than trying to support both, and it should certainly be easier to maintain in the future. I'm sorry to be obnoxious about this. Meanwhile, the bulk of this last patch series seems good; most of them have my acks, and I saw acks from Guennadi on some as well. I would recommend that you separate those out into a different series and submit them for merging, presumably for 3.9. That will give you a bit less code to carry going forward as this last part gets worked out. Thanks again for doing this work and persevering with it! jon -- 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 v2 0/5] Common Display Framework
On 2012-12-17 16:36, Laurent Pinchart wrote:
Hi Tomi,
I finally have time to work on a v3 :-)
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:
In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.
I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
dpi0 {
panel = dpi-panel;
};
/ {
dpi-panel: dpi-panel {
...panel data...;
};
};
Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework
also
targets HDMI and DP. The notification mechanism was actually designed to
support hotplug.
HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a
cable hotplug, handled inside a driver, which doesn't have any effect on
the linux devices.
If we do implement HDMI and DP monitors with real linux drivers, then
yes, we could use real hotplug. But we could as well have the monitor
driver always registered, and just have a driver internal cable-hotplug
system.
To be honest, I'm not sure if implementing real hotplug is easily
possible, as we don't have real, probable (probe-able =) busses. So even
if we'd get a hotplug event of a new display device, what kind of device
would the bus master register? It has no way to know that.
How do you see the proposal preventing hotplug ?
Well, probably it doesn't prevent. But it doesn't feel right to me.
Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be
probed. In the probe function it should somehow register itself to the
cdf, or perhaps the previous entity in the chain.
This sounds to me that the link is from the panel to the previous
entity, not the other way around as you describe, and also the previous
entity doesn't know of the panel entities.
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that
can
only receive calls (as it needs to control video streams, per your request
:-)) or only emit calls (as something needs to control it, userspace doesn't
control the panel directly).
Right, but as I see it, the destination of the panel's calls, and the
source of the calls to panel are different things. The destination is
the bus layer, dealing with the video signal being transferred. The
source is a bit higher level thing, something that's controlling the
display in general.
Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed
entities (transceivers) differently. I prefer having abstract entities that
can have a source and a sink, and expose the corresponding operations. That
would make pipeline handling much easier, as the code will only need to deal
with a single type of object. Implementing support for entities with multiple
sinks and/or sources would also be possible.
Ok. I think having pure sources is simpler model, but it's true that if
we need to iterate and study the pipeline during runtime, it's probably
better to have single entities with multiple sources/sinks.
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while
Re: Lockup on second streamon with omap3-isp
2012/12/17 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Julien, On Friday 14 December 2012 15:18:29 Julien BERAUD wrote: Hi Jean-Philippe, I have had exactly the same problem and the following workaround has caused no regression on our board yet. I can't explain exactly why it works and I think that it is internal to the isp. In function ccdc_set_stream, don't disable the ccdc_subclk when stopping capture: ret = ccdc_disable(ccdc); if (ccdc-output CCDC_OUTPUT_MEMORY) omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_CCDC_WRITE); - omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); + //omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); I know that it is still a workaround but I hope that maybe it will help someone to understand the real cause of this issue. Do you get CCDC stop timeouts ? They are reported in the kernel log as CCDC stop timeout!. Le 13/12/2012 15:14, jean-philippe francois a écrit : Hi, I have news on the IRQ storm on second streamon problem. Reminder : Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the omap3-isp (at least until 3.4) will go into an interrupt storm when streamon is called for the second time, unless you are able to stop the sensor when not streaming. I have reproduced this on three different board, with three different sensor. On board 1, the problem disappeared by itself (in fact not by itself, see below) and the board is not in my possession anymore. On board 2, I implemented a working s_stream operation in the subdev driver, so the problem was solved because the sensor would effectively stop streaming when told to, keeping the ISP + CCDC happy On board 3, I can't stop the streaming, or I did not figure out how to make it stop yet. I tried to disable the HS_VS_IRQ, but it did not help, so I came back looking at the code of board 1, which was running fine with a 3.4 kernel. And I discovered the problem doesn't happen if I break the pipeline between two consecutive streamon. In other word if I do the following : media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta yavta ... - board locks up, soft lockup is fired But if I do this instead : media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta ... - image are acquired, board doesn't lock up anymore Now this really doesn't make much sense to me. Both sequences should produce the exact same hardware accesses. Could you add a printk in isp_reg_writel (drivers/media/platform/omap3isp/isp.h) and compare the register writes for both sequences ? And you are right, it was pure coincidence, the issue is still there. Sorry for the inaccurate report. Regards, Jean-Philippe François It would be interesting to go from this workaround to the elimination of the root cause. What can I do / test next to stop this bug from hapenning ? -- 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 -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
Em 17-12-2012 10:30, Antti Palosaari escreveu:
On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote:
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew, could you please validate your test results and try Mauros
patches ? If it doesn't work, please create another USB-log.
Sorry it took me so long to test the patch, but the results look
promising, I actually got various keycodes!
dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
evtest was also generating output
Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
value
61d618e7
Event: time 1355705906.950551, -- SYN_REPORT
This is the current patch I'm using:
http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
What needs to be done to generate a keymap file?
Is there anything I can collect or try to do, to get channel scanning
working?
Just let me know what you need me to do. I really appreciate all the
help!
You don't need to do nothing as that remote is already there. Just
ensure buttons are same and we are happy.
http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
to load correct keytable by default. You could test it easily, just
add
following definition
.ir_codes = RC_MAP_MSI_DIGIVOX_III,
to em28xx-cards.c board config and it is all.
regards
Antti
Maybe I'm missing something but these are different key codes and
lengths.
tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump
11
tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III
9
0x61d643bc == 0x61d643
0x61d601fe == 0x61d601
Those are same codes, other (debug) is just 32bit full format. Last byte
in that case is dropped out as it is used for parity check - formula: DD
== ~DD
As I understand it, this was the whole reason for the patches that
Mauros wrote.
Nope, the reason was it didn't support 32bit at all.
I looked the patch and it seems like it should store and print 24bit
scancode for your remote. Maybe you didn't set default remote end it
fall back to unknown remote protocol which stores all bytes. Or some
other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
it does not output numbers there must be a bug. I am too lazy to test it
currently.
regards
Antti
I am using the RC_MAP_MSI_DIGIVOX_III mapping
+ .ir_codes = RC_MAP_MSI_DIGIVOX_III,
http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch
I tested Mauros patch with nanoStick T2 290e, using 24bit NEC remote - worked
fine. Your patch is hard to read as it contains that remote patch too. But what
I looked one difference which look suspicious - it is that:
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
could you remove and test?
If it is really that one, then there is a bug in Mauros patches and it breaks
all devices having NEC remote mapped currently.
The em28xx-input should not be touching on xclk frequency changes. Some devices
require specific settings there in order to work, and mangling it is a very
bad idea.
Btw, I don't think that are there any bugs with regards to that, as we use
em28xx_write_reg_bits():
/*
* em28xx_write_reg_bits()
* sets only some bits (specified by bitmask) of a register, by first reading
* the actual value
*/
int em28xx_write_reg_bits(struct em28xx *dev, u16 reg, u8 val,
u8 bitmask)
{
...
newval = (((u8) oldval) ~bitmask) | (val bitmask);
return em28xx_write_regs(dev, reg, newval, 1);
}
From patch 2/2:
+ if (*rc_type RC_BIT_RC5) {
+ dev-board.xclk |= EM28XX_XCLK_IR_RC5_MODE;
+ ir-full_code = 1;
+ *rc_type = RC_BIT_RC5;
+ } else if (*rc_type RC_BIT_NEC) {
+ dev-board.xclk = ~EM28XX_XCLK_IR_RC5_MODE;
+ ir-full_code = 1;
+ *rc_type = RC_BIT_NEC;
+ } else if (*rc_type RC_BIT_UNKNOWN) {
+ *rc_type = RC_BIT_UNKNOWN;
+ } else {
+ *rc_type = ir-rc_type;
+ return -EINVAL;
+ }
+ ir-get_key = default_polling_getkey;
+ em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev-board.xclk,
+ EM28XX_XCLK_IR_RC5_MODE);
(this is for em2860 code, but em2874_ir_change_protocol() has a similar
logic - the only exception is the support for RC6_0 as well)
This line:
em28xx_write_reg_bits(dev, EM28XX_R0F_XCLK, dev-board.xclk,
EM28XX_XCLK_IR_RC5_MODE);
Warrants that only the EM28XX_XCLK_IR_RC5_MODE bit is affected.
So, except if I'm missing something, the implementation looks correct
on my eyes.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
Re: Lockup on second streamon with omap3-isp
Hi Jean-Philippe, On Monday 17 December 2012 16:41:29 jean-philippe francois wrote: 2012/12/17 Laurent Pinchart: On Friday 14 December 2012 15:18:29 Julien BERAUD wrote: Hi Jean-Philippe, I have had exactly the same problem and the following workaround has caused no regression on our board yet. I can't explain exactly why it works and I think that it is internal to the isp. In function ccdc_set_stream, don't disable the ccdc_subclk when stopping capture: ret = ccdc_disable(ccdc); if (ccdc-output CCDC_OUTPUT_MEMORY) omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_CCDC_WRITE); - omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); + //omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); I know that it is still a workaround but I hope that maybe it will help someone to understand the real cause of this issue. Do you get CCDC stop timeouts ? They are reported in the kernel log as CCDC stop timeout!. Does Julien's patch fix your issue ? Le 13/12/2012 15:14, jean-philippe francois a écrit : Hi, I have news on the IRQ storm on second streamon problem. Reminder : Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the omap3-isp (at least until 3.4) will go into an interrupt storm when streamon is called for the second time, unless you are able to stop the sensor when not streaming. I have reproduced this on three different board, with three different sensor. On board 1, the problem disappeared by itself (in fact not by itself, see below) and the board is not in my possession anymore. On board 2, I implemented a working s_stream operation in the subdev driver, so the problem was solved because the sensor would effectively stop streaming when told to, keeping the ISP + CCDC happy On board 3, I can't stop the streaming, or I did not figure out how to make it stop yet. I tried to disable the HS_VS_IRQ, but it did not help, so I came back looking at the code of board 1, which was running fine with a 3.4 kernel. And I discovered the problem doesn't happen if I break the pipeline between two consecutive streamon. In other word if I do the following : media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta yavta ... - board locks up, soft lockup is fired But if I do this instead : media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta ... - image are acquired, board doesn't lock up anymore Now this really doesn't make much sense to me. Both sequences should produce the exact same hardware accesses. Could you add a printk in isp_reg_writel (drivers/media/platform/omap3isp/isp.h) and compare the register writes for both sequences ? And you are right, it was pure coincidence, the issue is still there. Thought so :-) Sorry for the inaccurate report. No worries. It would be interesting to go from this workaround to the elimination of the root cause. What can I do / test next to stop this bug from hapenning ? -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
Hi Matthew, Em 17-12-2012 09:17, Matthew Gyurgyik escreveu: On 12/17/2012 06:08 AM, Antti Palosaari wrote: On 12/17/2012 11:33 AM, Antti Palosaari wrote: On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. I looked the patch and it seems like it should store and print 24bit scancode for your remote. Maybe you didn't set default remote end it fall back to unknown remote protocol which stores all bytes. Or some other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if it does not output numbers there must be a bug. I am too lazy to test it currently. regards Antti I am using the RC_MAP_MSI_DIGIVOX_III mapping + .ir_codes = RC_MAP_MSI_DIGIVOX_III, http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch From this log: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt You clearly have a standard NEC-extended IR - e. g. 24 bits per scancode, 16 bits for address, 8 bits for command. Instead of using evtest, I really recomend you to use ir-keytable (part of v4l-utils package). You can compile it directly from our git tree: http://git.linuxtv.org/v4l-utils.git with: $ autoreconf -vfi $ ./configure $ make # make install The version there has a few updates to provide a more complete report. In order to use it in test mode, you can just do: # ir-keycode -t If your IR is at rc0 (otherwise, you'll need to use the -s rc1 parameter). It should print all events produced by an input device, including the scancodes (EV_MSC) and keystrokes (EV_KEY). One question: are you compiling a 32 bits or a 64 bits kernel? The is/were a bug with gcc and switch() when a 64 bits int is used on switch. Maybe we'll need to change the switch at the nec handling by a series of IFs due to such bug. Regards, Mauro Matthew -- 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 v2 0/5] Common Display Framework
Hi Laurent -
On Mon, 17 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
Hi Tomi,
I finally have time to work on a v3 :-)
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:
In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.
I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
dpi0 {
panel = dpi-panel;
};
/ {
dpi-panel: dpi-panel {
...panel data...;
};
};
Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework
also
targets HDMI and DP. The notification mechanism was actually designed to
support hotplug.
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
BR,
Jani.
How do you see the proposal preventing hotplug ?
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
I don't see any way around that. The panel is not a standalone entity that
can
only receive calls (as it needs to control video streams, per your request
:-)) or only emit calls (as something needs to control it, userspace doesn't
control the panel directly).
What I suggest is take a simpler approach, something alike to how regulators
or gpios are used, even if slightly more complex than those: the entity that
has a video output (SoC's DSS, external chips) offers that video output as
resource. It doesn't know or care who uses it. The user of the video output
(panel, external chips) will find the video output (to which it is connected
in the HW) by some means, and will use different operations on that output
to operate the device.
This would give us something like the following DT data:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
/ {
dpi-panel: dpi-panel {
source = dpi0;
...panel data...;
};
};
The panel driver would do something like this in its probe:
int dpi_panel_probe()
{
// Find the video source, increase ref
src = get_video_source_from_of(source);
// Reserve the video source for us. others can still get and
// observe it, but cannot use it as video data source.
// I think this should cascade upstream, so that after this call
// each video entity from the panel to the SoC's CRTC is
// reserved and locked for this video pipeline.
reserve_video_source(src);
// set DPI HW configuration, like DPI data lines. The
// configuration would come from panel's platform data
set_dpi_config(src, config);
// register this panel as a display.
register_display(this);
}
The DSS's dpi driver would do something like:
int dss_dpi_probe()
{
// register as a DPI video source
register_video_source(this);
}
A DSI-2-DPI chip would do something like:
int dsi2dpi_probe()
{
// get, reserve and config the DSI bus from SoC
src = get_video_source_from_of(source);
reserve_video_source(src);
set_dsi_config(src, config);
// register as a DPI video source
register_video_source(this);
}
Here we wouldn't have similar display_entity as you have, but video sources
and displays. Video sources are elements in the video pipeline, and a video
source is used only by the next downstream element. The last element in the
pipeline would not be a video source, but a display, which would be used by
the upper layer.
I don't think we should handle pure sources, pure sinks (displays) and mixed
entities (transceivers) differently. I prefer having abstract entities that
can have a source and a sink, and
Re: [PATCH RFC 2/2] V4L: Add V4L2_CID_AUTO_FOCUS_AREA control
Hi Sylwester and Sakari, On 17.12.2012 01:11, Sylwester Nawrocki wrote: Hi Sakari, On 12/16/2012 04:00 PM, Sakari Ailus wrote: diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..9d4af8a 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3347,6 +3347,51 @@ use its minimum possible distance for auto focus./entry /row rowentry/entry/row +row id=v4l2-auto-focus-area +entry spanname=id + constantV4L2_CID_AUTO_FOCUS_AREA/constantnbsp;/entry + entryenumnbsp;v4l2_auto_focus_area/entry +/row +rowentry spanname=descrDetermines the area of the frame that +the camera uses for automatic focus. The corresponding coordinates of the +focusing spot or rectangle can be specified and queried using the selection API. +To change the auto focus region of interest applications first select required +mode of this control and then set the rectangle or spot coordinates by means +of theVIDIOC-SUBDEV-S-SELECTION; orVIDIOC-S-SELECTION; ioctl. In order to +trigger again a one shot auto focus with same coordinates applications should +use theconstantV4L2_CID_AUTO_FOCUS_START/constant control. Or alternatively Extra space above.^ +invoke aVIDIOC-SUBDEV-S-SELECTION; or aVIDIOC-S-SELECTION; ioctl again. How about requiring explicit V4L2_CID_AUTO_FOCUS_START? If you need to specify several AF selection windows, then on which one do you start the algorithm? A bitmask control explicitly telling which ones are active would also be needed --- but that's for the future. I think now we just need to ascertain we don't make that difficult. :-) Do you mean only V4L2_CID_AUTO_FOCUS_START should start AF? What about continuous auto-focus (CAF)? In case of the sensor I am working on, face detection can work in both AF and CAF. Continuous AF needs to be an exception to that. It's controlled by V4L2_CID_FOCUS_AUTO, which interestingly doesn't even mention continuous AF. I think it does, maybe not exactly in these words, but continuous automatic focus adjustments doesn't sound like a difference thing to me. Should CAF be restarted (ie stopped and started again), to use face detection? I wonder if V4L2_CID_AUTO_FOCUS_START should be defined to restart CAF when V4L2_CID_FOCUS_AUTO is enabled. I don't think we currently have a way to do that; the current definition says that using V4L2_CID_AUTO_FOCUS_START is undefined then. What do you think? Yes, it might be worth to reconsider this. However, I would like to see real use cases first where V4L2_CID_AUTO_FOCUS_START control is needed in continuous AF mode. All in all, we have V4L2_AUTO_FOCUS_STATUS_FAILED AF status control value and I can't see anything preventing it to be applicable to CAF. So it might make sense to define in the API what needs to be done to bring CAF out of this state. And what about using again V4L2_CID_FOCUS_AUTO=true? Regarding the proposition that setting V4L2_CID_AUTO_FOCUS_AREA should not trigger AF/CAF. I am not sure if it will be good in case of CAF. After setting this control but before restarting CAF driver will not reflect hardware state. It does not seem to be dangerous but I do not see why we should allow for such situation anyway. In case of AF it seems to me OK. FOCUS_AREA is a setting which will be used only when AF action is started, ie. only in V4L2_CID_AUTO_FOCUS_START. Documentation should clearly state that only V4L2_CID_AUTO_FOCUS_START starts AF. +In the latter case the new pixel coordinates are applied to hardware only when +the focus area control was set to +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant./entry +/row +row +entrytbl spanname=descr cols=2 +tbody valign=top +row + entryconstantV4L2_AUTO_FOCUS_AREA_ALL/constantnbsp;/entry +entryNormal auto focus, the focusing area extends over the +entire frame./entry Does this need to be explicitly specified? Shouldn't the user just choose the largest possible AF window instead? I'd even expect that the AF window might span the whole frame by default (up to driver, hardware etc.). Yes it could be removed. There are two reasons I have left it: 1. If hardware support only AF on spots, V4L2_AUTO_FOCUS_AREA_ALL seems to be more natural than focusing on the whole image. If the hardware only supports spots, then wouldn't V4L2_AUTO_FOCUS_AREA_ALL give false information to the user, suggesting the focus area is actually the whole image? I think Andrzej meant to say that there can be hardware that supports: a. AF where region of interest is whole frame, b. AF where region of interest is some rectangle of size that may be not known exactly, and position (center) of that rectangle only is defined through AF selections. So you would be really switching AF algorithms by manipulating AF selection rectangle only. That said I really
Re: cannot make this Asus my cinema-u3100miniplusv2 work under linux
i am testing this antenna 30db on an aluminum bowl reception still sketchy at times but a bit better which is in your opinion the most powerful portable antenna ? can i amplify the signal to improve reception ? why with the bowl is better ? http://unixproducts.com/antenna2.jpg http://www.ebay.it/itm/130786205629?ssPageName=STRK:MEWNX:IT_trksid=p3984.m1497.l2649#ht_2055wt_1165 Il 16/12/2012 22:26 Renato Gallo ha scritto: I will be honored if my name will be added as reporter, thanks for your kind and fast advice. I have ordered another portable (30 db) antenna and will talk about that in a future reply to this thread :) Il 16/12/2012 22:22 Antti Palosaari ha scritto: That antenna is your problem. I will send that patch to the Kernel 3.8, but as I think it is maybe too late for 3.8 it will eventually go to the 3.9 which is out sometime near beginning of next summer. If you wish I add your name as reporter then reply. Otherwise case closed. Feedback from the better antenna could be nice too. Antti On 12/16/2012 11:16 PM, Renato Gallo wrote: stock one that came with the device http://unixproducts.com/antenna.jpg Il 16/12/2012 21:34 Antti Palosaari ha scritto: It is very likely weak signal issue as I said. What kind of antenna you are using? Antti On 12/16/2012 10:13 PM, Renato Gallo wrote: i found it is a problem with kaffeine, with other programs i can lock a signal but reception is very very sketchy (like in unviewable). GlovX xine-lib # dmesg |grep e4000 GlovX xine-lib # dmesg |grep FC0012 GlovX xine-lib # dmesg |grep FC0013 [ 28.281685] fc0013: Fitipower FC0013 successfully attached. GlovX xine-lib # dmesg |grep FC2580 GlovX xine-lib # dmesg |grep TUA GlovX xine-lib # Il 16/12/2012 18:55 Antti Palosaari ha scritto: On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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 -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Dec 17 19:00:28 CET 2012 git hash:49cc629df16f2a15917800a8579bd9c25c41b634 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK 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-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: ERRORS 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-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
Re: cannot make this Asus my cinema-u3100miniplusv2 work under linux
Al 17/12/12 20:57, En/na Renato Gallo ha escrit: can i amplify the signal to improve reception ? an amplifier will amplify the noise as well as the signal (i.e., an amplifier is only useful to compensate for the losses in the cable, not to improve the signal). why with the bowl is better ? http://en.wikipedia.org/wiki/Monopole_antenna The bowl acts as a ground plane Bye -- Luca -- 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 v2 0/5] Common Display Framework
Hi Jani,
On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
On Mon, 17 Dec 2012, Laurent Pinchart wrote:
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:
In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.
I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
dpi0 {
panel = dpi-panel;
};
/ {
dpi-panel: dpi-panel {
...panel data...;
};
};
Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework
also targets HDMI and DP. The notification mechanism was actually
designed to support hotplug.
I can see the need for a framework for DSI panels and such (in fact Tomi
and I have talked about it like 2-3 years ago already!) but what is the
story for HDMI and DP? In particular, what's the relationship between
DRM and CDF here? Is there a world domination plan to switch the DRM
drivers to use this framework too? ;) Do you have some rough plans how
DRM and CDF should work together in general?
There's always a world domination plan, isn't there ? :-)
I certainly want CDF to be used by DRM (or more accurately KMS). That's what
the C stands for, common refers to sharing panel and other display entity
drivers between FBDEV, KMS and V4L2.
I currently have no plan to expose CDF internals to userspace through the KMS
API. We might have to do so later if the hardware complexity grows in such a
way that finer control than what KMS provides needs to be exposed to
userspace, but I don't think we're there yet. The CDF API will thus only be
used internally in the kernel by display controller drivers. The KMS core
might get functions to handle common display entity operations, but the bulk
of the work will be in the display controller drivers to start with. We will
then see what can be abstracted in KMS helper functions.
Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF
API. That's just a thought for now, I haven't tried to implement them, but it
would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic way.
Do you have thoughts to share on this topic ?
--
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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
is there any kind of filter so that i can filter out the noise and then amplify the signal ? Il 17/12/2012 22:45 Luca Olivetti ha scritto: Al 17/12/12 20:57, En/na Renato Gallo ha escrit: can i amplify the signal to improve reception ? an amplifier will amplify the noise as well as the signal (i.e., an amplifier is only useful to compensate for the losses in the cable, not to improve the signal). why with the bowl is better ? http://en.wikipedia.org/wiki/Monopole_antenna The bowl acts as a ground plane Bye -- 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 v2 0/5] Common Display Framework
Hi Tomi,
On Monday 17 December 2012 17:29:15 Tomi Valkeinen wrote:
On 2012-12-17 16:36, Laurent Pinchart wrote:
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:
In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.
I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
dpi0 {
panel = dpi-panel;
};
/ {
dpi-panel: dpi-panel {
...panel data...;
};
};
Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Hotplug definitely needs to be supported, as the common display framework
also targets HDMI and DP. The notification mechanism was actually
designed to support hotplug.
HDMI or DP hotplug may or may not be a different thing than what I talk
about here. We may have two kinds of hotplug: real linux device hotplug,
i.e. a linux device appears or is removed during runtime, or just a cable
hotplug, handled inside a driver, which doesn't have any effect on the linux
devices.
If we do implement HDMI and DP monitors with real linux drivers, then yes,
we could use real hotplug. But we could as well have the monitor driver
always registered, and just have a driver internal cable-hotplug system.
To be honest, I'm not sure if implementing real hotplug is easily possible,
as we don't have real, probable (probe-able =) busses. So even if we'd get a
hotplug event of a new display device, what kind of device would the bus
master register? It has no way to know that.
I get your point.
My design goal is to handle both HDMI/DP and panels through a single hotplug
interface. I believe it would be simpler for display controller drivers to
handle all display entities with a common API instead of implementing support
for HDMI/DP and panels separately. This would require real HDMI and DP monitor
drivers. I share your concern, I don't know whether this can work in the end,
the only way to find out will be to try it.
How do you see the proposal preventing hotplug ?
Well, probably it doesn't prevent. But it doesn't feel right to me.
Say, if we have a DPI panel, controlled via foo-bus, which has a probing
mechanism. When the foo-bus master detects a new hardware device, it'll
create linux device for it. The driver for this device will then be probed.
That's correct. That's how Linux handles devices, and I don't think we should
diverge from that model without a very good reason to do so. In my
understanding you agree with me here, could you please confirm that ?
In the probe function it should somehow register itself to the cdf, or
perhaps the previous entity in the chain.
The panel driver would register the panel device to CDF in its probe function.
From a panel point of view I think we agree that two sets of operations exist.
- The panel control operations are called by an upper layer component (let's
call it A) to control the panel (retrieve the list of modes, enable the panel,
...). That upper layer component will usually call the panel in response to a
userspace request (that can go through several layers in the kernel before
reaching the panel), but can also call it in response to a hotplug event,
without userspace being involved.
- The panel calls video operations of the entity that provides it with a video
stream (the video source entity, let's call it B) to configure and control the
video bus.
A and B could be implemented in the same driver or in two separate drivers,
but at the end of the day I don't think that matters much. A needs a reference
to the panel, and the panel needs a reference to B, that's all we need to
provide, regardless of whether A and B come from the same kernel module or
not.
This sounds to me that the link is from the panel to the previous entity,
not the other way around as you describe, and also the previous entity
doesn't know of the panel entities.
The data flows from the video source to the panel (I'm 100% confident that we
agree on that :-)), and the video source is controlled by the panel as per
your request. The link is thus from the video source to the panel, but is
controlled by the sink, not the source.
Third, it kinda creates a
[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
Cc: Aaron Plattner aplatt...@nvidia.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Cheers, Daniel
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c| 42 ++-
include/linux/dma-buf.h | 4 +++-
3 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three
steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf-lock mutex.
3. Finish access
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..36af5de 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file-private_data;
+ BUG_ON(dmabuf-vmapping_counter);
+
dmabuf-ops-release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
- if (dmabuf-ops-vmap)
- return dmabuf-ops-vmap(dmabuf);
- return NULL;
+ if (!dmabuf-ops-vmap)
+ return NULL;
+
+ mutex_lock(dmabuf-lock);
+ if (dmabuf-vmapping_counter) {
+ dmabuf-vmapping_counter++;
+ BUG_ON(!dmabuf-vmap_ptr);
+ ptr = dmabuf-vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dmabuf-vmap_ptr);
+
+ ptr = dmabuf-ops-vmap(dmabuf);
+ if (IS_ERR_OR_NULL(ptr))
+ goto out_unlock;
+
+ dmabuf-vmap_ptr = ptr;
+ dmabuf-vmapping_counter = 1;
+
+out_unlock:
+ mutex_unlock(dmabuf-lock);
+ return ptr;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
@@ -501,7 +525,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- if (dmabuf-ops-vunmap)
- dmabuf-ops-vunmap(dmabuf, vaddr);
+ BUG_ON(!dmabuf-vmap_ptr);
+ BUG_ON(dmabuf-vmapping_counter 0);
+
+ mutex_lock(dmabuf-lock);
+ if (--dmabuf-vmapping_counter == 0) {
+ if (dmabuf-ops-vunmap)
+ dmabuf-ops-vunmap(dmabuf, vaddr);
+ dmabuf-vmap_ptr = NULL;
+ }
+ mutex_unlock(dmabuf-lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
- /* mutex to serialize list manipulation and attach/detach */
+ /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+ unsigned vmapping_counter;
+ void *vmap_ptr;
void *priv;
};
--
1.7.11.7
--
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] [RFC] dma-buf: implement vmap refcounting in the interface logic
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters with statically allocated backing storage, and more
dynamic drivers have decent issues already anyway.
Inspired by some refactoring patches from Aaron Plattner, who
implemented the same idea, but only for drm/prime drivers.
v2: Check in dma_buf_release that no dangling vmaps are left.
Suggested by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
v3: Check whether the passed-in vmap address matches with the cached
one for vunmap. Eventually we might want to remove that parameter -
compared to the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
Cc: Aaron Plattner aplatt...@nvidia.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Cheers, Daniel
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c| 43 ++-
include/linux/dma-buf.h | 4 +++-
3 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 0188903..4966b1b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three
steps:
void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
The vmap call can fail if there is no vmap support in the exporter, or if it
- runs out of vmalloc space. Fallback to kmap should be implemented.
+ runs out of vmalloc space. Fallback to kmap should be implemented. Note that
+ the dma-buf layer keeps a reference count for all vmap access and calls down
+ into the exporter's vmap function only when no vmapping exists, and only
+ unmaps it once. Protection against concurrent vmap/vunmap calls is provided
+ by taking the dma_buf-lock mutex.
3. Finish access
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..67d3cd5 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file-private_data;
+ BUG_ON(dmabuf-vmapping_counter);
+
dmabuf-ops-release(dmabuf);
kfree(dmabuf);
return 0;
@@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
*/
void *dma_buf_vmap(struct dma_buf *dmabuf)
{
+ void *ptr;
+
if (WARN_ON(!dmabuf))
return NULL;
- if (dmabuf-ops-vmap)
- return dmabuf-ops-vmap(dmabuf);
- return NULL;
+ if (!dmabuf-ops-vmap)
+ return NULL;
+
+ mutex_lock(dmabuf-lock);
+ if (dmabuf-vmapping_counter) {
+ dmabuf-vmapping_counter++;
+ BUG_ON(!dmabuf-vmap_ptr);
+ ptr = dmabuf-vmap_ptr;
+ goto out_unlock;
+ }
+
+ BUG_ON(dmabuf-vmap_ptr);
+
+ ptr = dmabuf-ops-vmap(dmabuf);
+ if (IS_ERR_OR_NULL(ptr))
+ goto out_unlock;
+
+ dmabuf-vmap_ptr = ptr;
+ dmabuf-vmapping_counter = 1;
+
+out_unlock:
+ mutex_unlock(dmabuf-lock);
+ return ptr;
}
EXPORT_SYMBOL_GPL(dma_buf_vmap);
@@ -501,7 +525,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
if (WARN_ON(!dmabuf))
return;
- if (dmabuf-ops-vunmap)
- dmabuf-ops-vunmap(dmabuf, vaddr);
+ BUG_ON(!dmabuf-vmap_ptr);
+ BUG_ON(dmabuf-vmapping_counter 0);
+ BUG_ON(dmabuf-vmap_ptr != vaddr);
+
+ mutex_lock(dmabuf-lock);
+ if (--dmabuf-vmapping_counter == 0) {
+ if (dmabuf-ops-vunmap)
+ dmabuf-ops-vunmap(dmabuf, vaddr);
+ dmabuf-vmap_ptr = NULL;
+ }
+ mutex_unlock(dmabuf-lock);
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..e3bf2f6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -119,8 +119,10 @@ struct dma_buf {
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
- /* mutex to serialize list manipulation and attach/detach */
+ /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
+ unsigned vmapping_counter;
+ void *vmap_ptr;
void *priv;
};
--
1.7.11.7
--
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
[PULL] dvb-frontends: use %*ph[N] to dump small buffers
Mauro, Please apply the following to update status in patchwork along with the following merge request... pwclient update -s 'superseded' 15687 pwclient update -s 'changes requested' 15688 I am marking 15687 as superseded because I broke the patch into two separate patches. (see merge request below) 15688 causes new build warnings, so I've asked Andy to resubmit. Please merge: The following changes since commit 5b7d8de7d2328f7b25fe4645eafee7e48f9b7df3: [media] au0828: break au0828_card_setup() down into smaller functions (2012-12-17 14:34:27 -0200) are available in the git repository at: git://git.linuxtv.org/mkrufky/tuners frontends for you to fetch changes up to 34c87fa2214d134c0028c97d7aab3dd769bb3bf0: ix2505v: use %*ph[N] to dump small buffers (2012-12-17 20:12:29 -0500) Andy Shevchenko (2): or51211: use %*ph[N] to dump small buffers ix2505v: use %*ph[N] to dump small buffers drivers/media/dvb-frontends/ix2505v.c |2 +- drivers/media/dvb-frontends/or51211.c |5 + 2 files changed, 2 insertions(+), 5 deletions(-) Cheers, Mike -- 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] omap3isp: Add support for interlaced input data
If the remote video sensor reports an interlaced video mode, the CCDC block
should configure itself appropriately.
---
drivers/media/platform/omap3isp/ispccdc.c | 16 ++--
include/media/omap3isp.h |3 +++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispccdc.c
b/drivers/media/platform/omap3isp/ispccdc.c
index 60e60aa..5443ef4 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -970,10 +970,11 @@ void omap3isp_ccdc_max_rate(struct isp_ccdc_device *ccdc,
* @ccdc: Pointer to ISP CCDC device.
* @pdata: Parallel interface platform data (may be NULL)
* @data_size: Data size
+ * @interlaced: Use interlaced mode instead of progressive mode
*/
static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
struct isp_parallel_platform_data *pdata,
- unsigned int data_size)
+ unsigned int data_size, bool interlaced)
{
struct isp_device *isp = to_isp_device(ccdc);
const struct v4l2_mbus_framefmt *format;
@@ -1004,9 +1005,15 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
break;
}
+ if (interlaced)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
if (pdata pdata-data_pol)
syn_mode |= ISPCCDC_SYN_MODE_DATAPOL;
+ if (pdata pdata-fld_pol)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDPOL;
+
if (pdata pdata-hs_pol)
syn_mode |= ISPCCDC_SYN_MODE_HDPOL;
@@ -,6 +1118,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
const struct v4l2_rect *crop;
const struct isp_format_info *fmt_info;
struct v4l2_subdev_format fmt_src;
+ bool src_interlaced = false;
unsigned int depth_out;
unsigned int depth_in = 0;
struct media_pad *pad;
@@ -1132,6 +1140,10 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
fmt_src.pad = pad-index;
fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL, fmt_src)) {
+ if (fmt_src.format.field == V4L2_FIELD_INTERLACED ||
+ fmt_src.format.field == V4L2_FIELD_INTERLACED_TB ||
+ fmt_src.format.field == V4L2_FIELD_INTERLACED_BT)
+ src_interlaced = true;
fmt_info = omap3isp_video_format_info(fmt_src.format.code);
depth_in = fmt_info-width;
}
@@ -1150,7 +1162,7 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
omap3isp_configure_bridge(isp, ccdc-input, pdata, shift, bridge);
- ccdc_config_sync_if(ccdc, pdata, depth_out);
+ ccdc_config_sync_if(ccdc, pdata, depth_out, src_interlaced);
syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 9584269..32d85c2 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -57,6 +57,8 @@ enum {
* ISP_LANE_SHIFT_6 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Sample on rising edge, 1 - Sample on falling edge
+ * @fld_pol: Field identification signal polarity
+ * 0 - Active high, 1 - Active low
* @hs_pol: Horizontal synchronization polarity
* 0 - Active high, 1 - Active low
* @vs_pol: Vertical synchronization polarity
@@ -67,6 +69,7 @@ enum {
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
+ unsigned int fld_pol:1;
unsigned int hs_pol:1;
unsigned int vs_pol:1;
unsigned int data_pol:1;
--
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
dvb: or51211: apply pr_fmt and use pr_* macros instead of printk
Andy, Your patch from Nov 28 entitled, dvb: or51211: apply pr_fmt and use pr_* macros instead of printk located in patchwork at the URL: http://patchwork.linuxtv.org/patch/15688/ ...creates the following build warning: CC [M] drivers/media/dvb-frontends/or51211.o drivers/media/dvb-frontends/or51211.c:45:0: warning: pr_fmt redefined [enabled by default] In file included from include/linux/kernel.h:13:0, from drivers/media/dvb-frontends/or51211.c:33: include/linux/printk.h:180:0: note: this is the location of the previous definition drivers/media/dvb-frontends/or51211.c:45:0: warning: pr_fmt redefined [enabled by default] In file included from include/linux/kernel.h:13:0, from drivers/media/dvb-frontends/or51211.c:33: include/linux/printk.h:180:0: note: this is the location of the previous definition Please take a look at your patch and send a revised version if you think it's appropriate. I will have the other use %*ph[N] to dump small buffers patches merged -- thanks for your contribution! Regards, Mike Krufky -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 11:14 AM, Mauro Carvalho Chehab wrote: Hi Matthew, Em 17-12-2012 09:17, Matthew Gyurgyik escreveu: On 12/17/2012 06:08 AM, Antti Palosaari wrote: On 12/17/2012 11:33 AM, Antti Palosaari wrote: On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. I looked the patch and it seems like it should store and print 24bit scancode for your remote. Maybe you didn't set default remote end it fall back to unknown remote protocol which stores all bytes. Or some other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if it does not output numbers there must be a bug. I am too lazy to test it currently. regards Antti I am using the RC_MAP_MSI_DIGIVOX_III mapping + .ir_codes = RC_MAP_MSI_DIGIVOX_III, http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch From this log: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt You clearly have a standard NEC-extended IR - e. g. 24 bits per scancode, 16 bits for address, 8 bits for command. Instead of using evtest, I really recomend you to use ir-keytable (part of v4l-utils package). You can compile it directly from our git tree: http://git.linuxtv.org/v4l-utils.git with: $ autoreconf -vfi $ ./configure $ make # make install The version there has a few updates to provide a more complete report. In order to use it in test mode, you can just do: # ir-keycode -t If your IR is at rc0 (otherwise, you'll need to use the -s rc1 parameter). It should print all events produced by an input device, including the scancodes (EV_MSC) and keystrokes (EV_KEY). One question: are you compiling a 32 bits or a 64 bits kernel? The is/were a bug with gcc and switch() when a 64 bits int is used on switch. Maybe we'll need to change the switch at the nec handling by a series of IFs due to such bug. I am compiling a 64 bit kernel. I attempted to build a new kernel, however I am running into some difficulties. With the upcoming holiday I probably won't be able to get test results until the beginning of January, due to not having access to my PC. I hope this is ok. Regards, Mauro Matthew -- 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 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 23:29
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2
parts for
soc_camera support
On Sun, 16 Dec 2012 14:12:11 -0800
Albert Wang twan...@marvell.com wrote:
- Is the soc_camera mode necessary? Is there something you're trying
to do that can't be done without it? Or, at least, does it add
sufficient benefit to be worth this work? It would be nice if the
reasoning behind this change were put into the changelog.
[Albert Wang] We just want to add one more option for user. :)
And we split it to 2 parts because we want to keep the original mode.
- If the soc_camera change is deemed to be worthwhile, is there
anything preventing you from doing it 100% so it's the only mode
used?
[Albert Wang] No, but current all Marvell platform have used the soc_camera
in camera
driver. :)
So we just hope the marvell-ccic can have this option. :)
OK, so this, I think, is the one remaining point of disagreement here;
unfortunately it's a biggish one.
Users, I believe, don't really care which underlying framework the driver
is using; they just want a camera implementing the V4L2 spec. So, this
particular option does not have any real value for them. But it has a
real cost in terms of duplicated code, added complexity, and namespace
pollution. If you believe I'm wrong, please tell me why, but I think that
this option is not worth the cost.
The reason for the soc_camera conversion is because that's how your
drivers do it — not necessarily the strongest of reasons. Of course, the
reason for keeping things as they are is because that's how the in-tree
drivers does it; not necessarily a whole lot stronger.
I'm not sold on the soc_camera conversion, but neither am I implacably
opposed to it. But I *really* dislike the idea of having both, I don't
see that leading to good things in the long run. So can I ask one more
time: if soc_camera is important to you, could you please just convert the
driver over 100% and drop the other mode entirely? It seems that should
be easier than trying to support both, and it should certainly be easier
to maintain in the future.
[Albert Wang] So if we add B_DMA_SG and B_VMALLOC support and OLPC XO 1.0
support in soc_camera mode.
Then we can just remove the original mode and only support soc_camera mode in
marvell-ccic?
I'm sorry to be obnoxious about this.
Meanwhile, the bulk of this last patch series seems good; most of them
have my acks, and I saw acks from Guennadi on some as well. I would
recommend that you separate those out into a different series and submit
them for merging, presumably for 3.9. That will give you a bit less code
to carry going forward as this last part gets worked out.
Thanks again for doing this work and persevering with it!
jon
Thanks
Albert Wang
86-21-61092656
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 11:14 AM, Mauro Carvalho Chehab wrote: Hi Matthew, Em 17-12-2012 09:17, Matthew Gyurgyik escreveu: On 12/17/2012 06:08 AM, Antti Palosaari wrote: On 12/17/2012 11:33 AM, Antti Palosaari wrote: On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote: On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 0x61d643bc == 0x61d643 0x61d601fe == 0x61d601 Those are same codes, other (debug) is just 32bit full format. Last byte in that case is dropped out as it is used for parity check - formula: DD == ~DD As I understand it, this was the whole reason for the patches that Mauros wrote. Nope, the reason was it didn't support 32bit at all. I looked the patch and it seems like it should store and print 24bit scancode for your remote. Maybe you didn't set default remote end it fall back to unknown remote protocol which stores all bytes. Or some other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if it does not output numbers there must be a bug. I am too lazy to test it currently. regards Antti I am using the RC_MAP_MSI_DIGIVOX_III mapping + .ir_codes = RC_MAP_MSI_DIGIVOX_III, http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch From this log: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt You clearly have a standard NEC-extended IR - e. g. 24 bits per scancode, 16 bits for address, 8 bits for command. Instead of using evtest, I really recomend you to use ir-keytable (part of v4l-utils package). You can compile it directly from our git tree: http://git.linuxtv.org/v4l-utils.git with: $ autoreconf -vfi $ ./configure $ make # make install The version there has a few updates to provide a more complete report. In order to use it in test mode, you can just do: # ir-keycode -t If your IR is at rc0 (otherwise, you'll need to use the -s rc1 parameter). Here is the report (I pressed every key on the remote): http://pyther.net/a/digivox_atsc/dec17/ir-keytables.txt It should print all events produced by an input device, including the scancodes (EV_MSC) and keystrokes (EV_KEY). One question: are you compiling a 32 bits or a 64 bits kernel? The is/were a bug with gcc and switch() when a 64 bits int is used on switch. Maybe we'll need to change the switch at the nec handling by a series of IFs due to such bug. I am compiling a 64 bit kernel. Regards, Mauro I can test patches Tue and Wed this week. Afterwards, I probably won't be able to test anything until Dec 28th/29th as I will be away from my workstation. In regards to my issue compiling my kernel, it helps if I include devtmpfs. :) Thanks, Matthew -- 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] mx2_camera: Convert it to platform driver
Hi Guennadi, On Fri, Nov 30, 2012 at 1:06 PM, Fabio Estevam fabio.este...@freescale.com wrote: Converting it to platform code can make the code smaller. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Does this patch look good? Regards, Fabio Estevam -- 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 v2 0/5] Common Display Framework
Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are shared with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. Dave. -- 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 v2 0/5] Common Display Framework
Hi All, On 17 December 2012 20:55, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Vikas, Sorry for the late reply. I now have more time to work on CDF, so delays should be much shorter. On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote: Hi Laurent, I was thinking of porting CDF to samsung EXYNOS 5250 platform, what I found is that, the exynos display controller is MIPI DSI based controller. But if I look at CDF patches, it has only support for MIPI DBI based Display controller. So my question is, do we have any generic framework for MIPI DSI based display controller? basically I wanted to know, how to go about porting CDF for such kind of display controller. MIPI DSI support is not available yet. The only reason for that is that I don't have any MIPI DSI hardware to write and test the code with :-) The common display framework should definitely support MIPI DSI. I think the existing MIPI DBI code could be used as a base, so the implementation shouldn't be too high. Yeah, i was also thinking in similar lines, below is my though for MIPI DSI support in CDF. o MIPI DSI support as part of CDF framework will expose mipi_dsi_register_device(mpi_device) (will be called mach-xxx-dt.c file ) mipi_dsi_register_driver(mipi_driver, bus ops) (will be called from platform specific init driver call ) · bus ops will be o read data o write data o write command MIPI DSI will be registered as bus_register() When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI) will initialize the MIPI DSI HW IP. This probe will also parse the DT file for MIPI DSI based panel, add the panel device (device_add() ) to kernel and register the display entity with its control and video ops with CDF. I can give this a try. Does the existing Exynos 5250 driver support MIPI DSI ? Is the device documentation publicly available ? Can you point me to a MIPI DSI panel with public documentation (preferably with an existing mainline driver if possible) ? yeah, existing Exynos 5250 driver support MIPI DSI ass well as eDP. i think device documentation is NOT available publicly. -- Regards, Laurent Pinchart -- Thanks and Regards Vikas Sajjan -- 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 v2 0/5] Common Display Framework
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie airl...@gmail.com wrote: Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? I tend to think that sub-devices are useful just to have a way to probe hw which may or may not be there, since on ARM we often don't have any alternative.. but beyond that, suspend/resume, and other life-cycle aspects, they should really be treated as all one device. Especially to avoid undefined suspend/resume ordering. CDF or some sort of mechanism to share panel drivers between drivers is useful. Keeping it within drm, is probably a good idea, if nothing else to simplify re-use of helper fxns (like avi-infoframe stuff, for example) and avoid dealing with merging changes across multiple trees. Treating them more like shared libraries and less like sub-devices which can be dynamically loaded/unloaded (ie. they should be not built as separate modules or suspend/resumed or probed/removed independently of the master driver) is a really good idea to avoid uncovering nasty synchronization issues later (remove vs modeset or pageflip) or surprising userspace in bad ways. The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are shared with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. yeah, let's not have multiple frameworks to do the same thing.. For fbdev, it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is perhaps bit more flexible when it comes to random arbitrary hw pipelines than kms. But to take advantage of that, your userspace isn't going to be portable anyways, so you might as well use driver specific properties/ioctls. But I tend to think that is more useful for cameras. And from userspace perspective, kms planes are less painful to use for output than v4l2, so lets stick to drm/kms for output (and not try to add camera/capture support to kms).. k, thx BR, -R Dave. ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
