RE: [RFC v2 2/7] media: rc: Add cec protocol handling
Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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] stk1160: Make sure current buffer is released
The available (i.e. not used) buffers are returned by stk1160_clear_queue(),
on the stop_streaming() path. However, this is insufficient and the current
buffer must be released as well. Fix it.
Cc: sta...@vger.kernel.org
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
drivers/media/usb/stk1160/stk1160-v4l.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-v4l.c
b/drivers/media/usb/stk1160/stk1160-v4l.c
index 2330543..f6d0334 100644
--- a/drivers/media/usb/stk1160/stk1160-v4l.c
+++ b/drivers/media/usb/stk1160/stk1160-v4l.c
@@ -244,6 +244,11 @@ static int stk1160_stop_streaming(struct stk1160 *dev)
if (mutex_lock_interruptible(dev-v4l_lock))
return -ERESTARTSYS;
+ /*
+* Once URBs are cancelled, the URB complete handler
+* won't be running. This is required to safely release the
+* current buffer (dev-isoc_ctl.buf).
+*/
stk1160_cancel_isoc(dev);
/*
@@ -624,8 +629,16 @@ void stk1160_clear_queue(struct stk1160 *dev)
stk1160_info(buffer [%p/%d] aborted\n,
buf, buf-vb.v4l2_buf.index);
}
- /* It's important to clear current buffer */
- dev-isoc_ctl.buf = NULL;
+
+ /* It's important to release the current buffer */
+ if (dev-isoc_ctl.buf) {
+ buf = dev-isoc_ctl.buf;
+ dev-isoc_ctl.buf = NULL;
+
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ stk1160_info(buffer [%p/%d] aborted\n,
+ buf, buf-vb.v4l2_buf.index);
+ }
spin_unlock_irqrestore(dev-buf_lock, flags);
}
--
2.3.0
--
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: em38xx locking question
On 03/10/2015 10:46 AM, Hans Verkuil wrote: On 03/10/2015 02:29 PM, Ezequiel Garcia wrote: On 03/10/2015 10:26 AM, Hans Verkuil wrote: On 03/10/2015 02:18 PM, Ezequiel Garcia wrote: Mauro, Function drivers/media/usb/em28xx/em28xx-video.c:get_next_buf (copy pasted below for reference) does not take the list spinlock, yet it modifies the list. Is that correct? That looks wrong to me. You really need spinlocks here. OK, second question then. Is there any way to guarantee the URBs irq handler is *not* running, when vb2_ops are called (e.g. stop_streaming)? That depends on the op. But stop_streaming is the op that is supposed to turn off the streaming (and thus the irq), so it depends on the order of how things are done in that function. Ah, right. As long as you kill the urbs before you try to access the current buffer, everything is OK. Otherwise, given stop_streaming will return the current buffer to vb2 (dev-usb_ctl.vid_buf), I believe that will race against the irq handler, which is processing it. It seems that's currently racy as well. Hmm, the stop_streaming code looks fine at first sight, but I think there is a race if you start streaming both video and vbi, and then stop streaming one of the two. I think the code might keep calling get_next_buf() in that case, even if for that stream the streaming was stopped. This is a problem anyway: get_next_buf() should do this check at the beginning: if (!vb2_start_streaming_called(vb2_queue)) return NULL; to prevent it from using buffer before start_streaming was actually called. I'd say get_next_buf() is called only in the URB complete handler path, and hence only after start_streaming. However, maybe there's a subtle issue here: URB complete handler can be called _while_ start_streaming is still running. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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: em38xx locking question
On 03/10/2015 02:18 PM, Ezequiel Garcia wrote:
Mauro,
Function drivers/media/usb/em28xx/em28xx-video.c:get_next_buf
(copy pasted below for reference) does not take the list spinlock,
yet it modifies the list. Is that correct?
That looks wrong to me. You really need spinlocks here.
Regards,
Hans
static inline struct em28xx_buffer *get_next_buf(struct em28xx *dev,
struct em28xx_dmaqueue
*dma_q)
{
struct em28xx_buffer *buf;
if (list_empty(dma_q-active)) {
em28xx_isocdbg(No active queue to serve\n);
return NULL;
}
/* Get the next buffer */
buf = list_entry(dma_q-active.next, struct em28xx_buffer, list);
/* Cleans up buffer - Useful for testing for frame/URB loss */
list_del(buf-list);
buf-pos = 0;
buf-vb_buf = buf-mem;
return buf;
}
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em38xx locking question
On 03/10/2015 10:26 AM, Hans Verkuil wrote: On 03/10/2015 02:18 PM, Ezequiel Garcia wrote: Mauro, Function drivers/media/usb/em28xx/em28xx-video.c:get_next_buf (copy pasted below for reference) does not take the list spinlock, yet it modifies the list. Is that correct? That looks wrong to me. You really need spinlocks here. OK, second question then. Is there any way to guarantee the URBs irq handler is *not* running, when vb2_ops are called (e.g. stop_streaming)? Otherwise, given stop_streaming will return the current buffer to vb2 (dev-usb_ctl.vid_buf), I believe that will race against the irq handler, which is processing it. It seems that's currently racy as well. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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: em38xx locking question
On 03/10/2015 02:29 PM, Ezequiel Garcia wrote: On 03/10/2015 10:26 AM, Hans Verkuil wrote: On 03/10/2015 02:18 PM, Ezequiel Garcia wrote: Mauro, Function drivers/media/usb/em28xx/em28xx-video.c:get_next_buf (copy pasted below for reference) does not take the list spinlock, yet it modifies the list. Is that correct? That looks wrong to me. You really need spinlocks here. OK, second question then. Is there any way to guarantee the URBs irq handler is *not* running, when vb2_ops are called (e.g. stop_streaming)? That depends on the op. But stop_streaming is the op that is supposed to turn off the streaming (and thus the irq), so it depends on the order of how things are done in that function. Otherwise, given stop_streaming will return the current buffer to vb2 (dev-usb_ctl.vid_buf), I believe that will race against the irq handler, which is processing it. It seems that's currently racy as well. Hmm, the stop_streaming code looks fine at first sight, but I think there is a race if you start streaming both video and vbi, and then stop streaming one of the two. I think the code might keep calling get_next_buf() in that case, even if for that stream the streaming was stopped. This is a problem anyway: get_next_buf() should do this check at the beginning: if (!vb2_start_streaming_called(vb2_queue)) return NULL; to prevent it from using buffer before start_streaming was actually called. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em38xx locking question
Mauro,
Function drivers/media/usb/em28xx/em28xx-video.c:get_next_buf
(copy pasted below for reference) does not take the list spinlock,
yet it modifies the list. Is that correct?
static inline struct em28xx_buffer *get_next_buf(struct em28xx *dev,
struct em28xx_dmaqueue *dma_q)
{
struct em28xx_buffer *buf;
if (list_empty(dma_q-active)) {
em28xx_isocdbg(No active queue to serve\n);
return NULL;
}
/* Get the next buffer */
buf = list_entry(dma_q-active.next, struct em28xx_buffer, list);
/* Cleans up buffer - Useful for testing for frame/URB loss */
list_del(buf-list);
buf-pos = 0;
buf-vb_buf = buf-mem;
return buf;
}
Thanks!
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
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 2/7] media: rc: Add cec protocol handling
On 03/10/2015 01:02 PM, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Let me add to this as the original designer of this framework: first of all the CEC protocol is a protocol from hell, very ad-hoc designed. The problem with that is that it very much depends on the product or device driver what - if anything - of the CEC protocol should be exposed to the end-user. You can decide to keep all the CEC handling in the driver, or do almost everything in userspace or anything in between. The hardware itself can be an HDMI receiver, transmitter or repeater, or it can be a USB dongle that controls the CEC bus between two HDMI devices. So even the subsystem involved in the device can be all over the place (usb, drm, v4l). So this CEC framework keeps the core protocol handling inside the kernel, and allows drivers to expose the CEC protocol to varying degrees to userspace. The pure CEC core commands should be handled in the kernel so no userspace components should be needed to get a valid working setup. A USB dongle might be an exception to that rule, I haven't looked at that in detail. On the userspace side of the CEC framework we might need a simple library. I'm not so sure about a daemon: that should definitely be optional. A standard cec-ctl utility to help test and control the CEC bus would be useful. I am also thinking that a cec-compliance test utility would be extremely useful to verify that drivers (and userspace) implement the CEC commands correctly. Since CEC is a bit of a disaster, such a tool would help a lot. Time permitting this is something I might work on myself. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em38xx locking question
On 03/10/2015 03:06 PM, Ezequiel Garcia wrote: On 03/10/2015 10:46 AM, Hans Verkuil wrote: On 03/10/2015 02:29 PM, Ezequiel Garcia wrote: On 03/10/2015 10:26 AM, Hans Verkuil wrote: On 03/10/2015 02:18 PM, Ezequiel Garcia wrote: Mauro, Function drivers/media/usb/em28xx/em28xx-video.c:get_next_buf (copy pasted below for reference) does not take the list spinlock, yet it modifies the list. Is that correct? That looks wrong to me. You really need spinlocks here. OK, second question then. Is there any way to guarantee the URBs irq handler is *not* running, when vb2_ops are called (e.g. stop_streaming)? That depends on the op. But stop_streaming is the op that is supposed to turn off the streaming (and thus the irq), so it depends on the order of how things are done in that function. Ah, right. As long as you kill the urbs before you try to access the current buffer, everything is OK. Otherwise, given stop_streaming will return the current buffer to vb2 (dev-usb_ctl.vid_buf), I believe that will race against the irq handler, which is processing it. It seems that's currently racy as well. Hmm, the stop_streaming code looks fine at first sight, but I think there is a race if you start streaming both video and vbi, and then stop streaming one of the two. I think the code might keep calling get_next_buf() in that case, even if for that stream the streaming was stopped. This is a problem anyway: get_next_buf() should do this check at the beginning: if (!vb2_start_streaming_called(vb2_queue)) return NULL; to prevent it from using buffer before start_streaming was actually called. I'd say get_next_buf() is called only in the URB complete handler path, and hence only after start_streaming. Well, no. If you are streaming just video and then start streaming vbi in addition to the video, then I think get_next_buf() can be called for the VBI stream before start_streaming is called for that VBI stream. Hans However, maybe there's a subtle issue here: URB complete handler can be called _while_ start_streaming is still running. -- 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 2/7] media: rc: Add cec protocol handling
On Tue, 2015-03-10 at 13:02 +0100, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) I have 2 machines that this could work on, a Intel Baytrail tablet, and a laptop with Intel Haswell. Is that part going to be covered by your library, or will there be a drm API for that? - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) That's done through the CEC API as well? - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly That's easier to deal with :) Something like LIRC can be used in the short-term. How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Great. Do drop me a mail when you have something that I could test. Cheers -- 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 00/18] marvell-ccic + ov7670 fixes
On Mon, 9 Mar 2015 22:22:05 +0100 Hans Verkuil hverk...@xs4all.nl wrote: This patch series makes loads of fixes and improvements to the marvell-ccic and ov7670 drivers. This has been tested on an OLPC XO-1 laptop. So I'm traveling and even shorter on time than usual. I've had a quick look over these patches, and they generally seem OK. Just don't ding me for not using a bunch of infrastructure that wasn't there when I wrote this thing! :) Ideally it would be nice to see patch 9 split - locking changes separate from use of helpers - but that's a quibble. Out of curiosity, is there a use driving this work, or are you just making things cleaner? Regardless, it clearly improves the drivers; thanks for doing this. Acked-by: Jonathan Corbet cor...@lwn.net I do need to check the last patch with Libin Yang since his patch from mid-2013 broke the driver for the OLPC laptop. Nobody noticed since the latest released kernel from the OLPC project for that laptop is 3.3, which didn't have his patch. Libin seems to have vanished, and I think that whatever interest Marvell had in supporting this driver has vanished with him, unfortunately. I'm still tempted to revert much of that work, since I'm not sure it has ever worked on a real system... 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
[PATCH] media: davinci: vpfe_capture: embed video_device
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Embed the video_device struct to simplify the error handling and in
order to (eventually) get rid of video_device_alloc/release.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpfe_capture.c | 26 +++---
include/media/davinci/vpfe_capture.h | 2 +-
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index b41bf7e..ccfcf3f 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -1871,16 +1871,9 @@ static int vpfe_probe(struct platform_device *pdev)
goto probe_free_ccdc_cfg_mem;
}
- /* Allocate memory for video device */
- vfd = video_device_alloc();
- if (NULL == vfd) {
- ret = -ENOMEM;
- v4l2_err(pdev-dev.driver, Unable to alloc video device\n);
- goto probe_out_release_irq;
- }
-
+ vfd = vpfe_dev-video_dev;
/* Initialize field of video device */
- vfd-release= video_device_release;
+ vfd-release= video_device_release_empty;
vfd-fops = vpfe_fops;
vfd-ioctl_ops = vpfe_ioctl_ops;
vfd-tvnorms= 0;
@@ -1891,14 +1884,12 @@ static int vpfe_probe(struct platform_device *pdev)
(VPFE_CAPTURE_VERSION_CODE 16) 0xff,
(VPFE_CAPTURE_VERSION_CODE 8) 0xff,
(VPFE_CAPTURE_VERSION_CODE) 0xff);
- /* Set video_dev to the video device */
- vpfe_dev-video_dev = vfd;
ret = v4l2_device_register(pdev-dev, vpfe_dev-v4l2_dev);
if (ret) {
v4l2_err(pdev-dev.driver,
Unable to register v4l2 device.\n);
- goto probe_out_video_release;
+ goto probe_out_release_irq;
}
v4l2_info(vpfe_dev-v4l2_dev, v4l2 device registered\n);
spin_lock_init(vpfe_dev-irqlock);
@@ -1914,7 +1905,7 @@ static int vpfe_probe(struct platform_device *pdev)
v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
video_dev=%p\n, vpfe_dev-video_dev);
vpfe_dev-fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- ret = video_register_device(vpfe_dev-video_dev,
+ ret = video_register_device(vpfe_dev-video_dev,
VFL_TYPE_GRABBER, -1);
if (ret) {
@@ -1927,7 +1918,7 @@ static int vpfe_probe(struct platform_device *pdev)
/* set the driver data in platform device */
platform_set_drvdata(pdev, vpfe_dev);
/* set driver private data */
- video_set_drvdata(vpfe_dev-video_dev, vpfe_dev);
+ video_set_drvdata(vpfe_dev-video_dev, vpfe_dev);
i2c_adap = i2c_get_adapter(vpfe_cfg-i2c_adapter_id);
num_subdevs = vpfe_cfg-num_subdevs;
vpfe_dev-sd = kmalloc(sizeof(struct v4l2_subdev *) * num_subdevs,
@@ -1979,12 +1970,9 @@ static int vpfe_probe(struct platform_device *pdev)
probe_sd_out:
kfree(vpfe_dev-sd);
probe_out_video_unregister:
- video_unregister_device(vpfe_dev-video_dev);
+ video_unregister_device(vpfe_dev-video_dev);
probe_out_v4l2_unregister:
v4l2_device_unregister(vpfe_dev-v4l2_dev);
-probe_out_video_release:
- if (!video_is_registered(vpfe_dev-video_dev))
- video_device_release(vpfe_dev-video_dev);
probe_out_release_irq:
free_irq(vpfe_dev-ccdc_irq0, vpfe_dev);
probe_free_ccdc_cfg_mem:
@@ -2007,7 +1995,7 @@ static int vpfe_remove(struct platform_device *pdev)
free_irq(vpfe_dev-ccdc_irq0, vpfe_dev);
kfree(vpfe_dev-sd);
v4l2_device_unregister(vpfe_dev-v4l2_dev);
- video_unregister_device(vpfe_dev-video_dev);
+ video_unregister_device(vpfe_dev-video_dev);
kfree(vpfe_dev);
kfree(ccdc_cfg);
return 0;
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 288772e..28bcd71 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -102,7 +102,7 @@ struct vpfe_config {
struct vpfe_device {
/* V4l2 specific parameters */
/* Identifies video device for this channel */
- struct video_device *video_dev;
+ struct video_device video_dev;
/* sub devices */
struct v4l2_subdev **sd;
/* vpfe cfg */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Mar 11 04:00:16 CET 2015 git branch: test git hash: 3d945be05ac1e806af075e9315bc1b3409adae2b gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] marvell-ccic + ov7670 fixes
On 03/10/2015 03:30 PM, Jonathan Corbet wrote: On Mon, 9 Mar 2015 22:22:05 +0100 Hans Verkuil hverk...@xs4all.nl wrote: This patch series makes loads of fixes and improvements to the marvell-ccic and ov7670 drivers. This has been tested on an OLPC XO-1 laptop. So I'm traveling and even shorter on time than usual. I've had a quick look over these patches, and they generally seem OK. Just don't ding me for not using a bunch of infrastructure that wasn't there when I wrote this thing! :) Ideally it would be nice to see patch 9 split - locking changes separate from use of helpers - but that's a quibble. Out of curiosity, is there a use driving this work, or are you just making things cleaner? I needed to test my earlier subdev patch series, and since I finally had the OLPC in a testable state again I thought that was a good opportunity to run the v4l2-compliance test suite over it. That always generates a lot of failures when it is run for the first time on a driver. I'm biased since I wrote that tool, but v4l2-compliance is awesome :-) As an added bonus this driver is now also converted to the new frameworks. Eventually all drivers will be converted and we can drop legacy support in the v4l2 core. And as a second bonus this was a good reason for me to add support for the 4:2:0 planar formats to the vivid driver, which helped me test the marvell driver. I've tested all the supported formats and I can confirm that they all work after this patch series is applied. Regardless, it clearly improves the drivers; thanks for doing this. Acked-by: Jonathan Corbet cor...@lwn.net I do need to check the last patch with Libin Yang since his patch from mid-2013 broke the driver for the OLPC laptop. Nobody noticed since the latest released kernel from the OLPC project for that laptop is 3.3, which didn't have his patch. Libin seems to have vanished, and I think that whatever interest Marvell had in supporting this driver has vanished with him, unfortunately. I'm still tempted to revert much of that work, since I'm not sure it has ever worked on a real system... OK, good to know. I'll try to contact him and if I haven't heard from him by Monday (or if the email is no longer valid), then I'll make a pull request for this series to get it in 4.1. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 2/7] media: rc: Add cec protocol handling
From: Bastien Nocera [mailto:had...@hadess.net] Sent: Tuesday, March 10, 2015 3:15 PM On Tue, 2015-03-10 at 13:02 +0100, Kamil Debski wrote: Hi Bastien, From: Bastien Nocera [mailto:had...@hadess.net] Sent: Monday, March 09, 2015 5:44 PM On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote: Hi Mauro, From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com] Sent: Sunday, March 08, 2015 3:21 PM Em Thu, 22 Jan 2015 17:04:34 +0100 Kamil Debski k.deb...@samsung.com escreveu: (c/c linux-input ML) Add cec protocol handling the RC framework. I added some comments, that reflects my understanding from what's there at the keymap definitions found at: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf Thank you very much for the review, Mauro. Your comments are very much appreciated. How does one use this new support? If I plug in my laptop to my TV, will using the TV's remote automatically send those key events to the laptop? It depends on the hardware that is used in your laptop to handle HDMI. If there is hardware support for CEC then this framework can be used to create a driver for the laptop's HDMI hardware. Then the laptop will be able to communicate with the TV over CEC - this includes receiving key events from the TV. Currently there are some CEC devices (and drivers) that enable Linux to use CEC, but there is no generic framework for CEC in the Linux kernel. My goal is to introduce such a framework, such that userspace application could work with different hardware using the same interface. Getting back to your question - using this framework. There should be some initialization done by a user space application: - enabling CEC (if needed by the hardware/driver) I have 2 machines that this could work on, a Intel Baytrail tablet, and a laptop with Intel Haswell. Is that part going to be covered by your library, or will there be a drm API for that? Enabling CEC is done by the CEC framework. The idea is to have it independent of other frameworks (such as drm, or v4l2). - configuring the connection (e.g. what kind of device should the laptop appear as, request the TV to pass remote control keys, etc.) That's done through the CEC API as well? Yes. - the TV will also send other CEC messages to the laptop, hence the application should listen for such messages and act accordingly That's easier to deal with :) Something like LIRC can be used in the short-term. How this should be done userspace? Definitely, it would be a good idea to use a library. Maybe a deamon that does the steps mentioned above would be a good idea? I am working on a simple library implementation that would wrap the kernel ioctls and provide a more user friendly API. Great. Do drop me a mail when you have something that I could test. Will do. Cheers Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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] MAINTAINERS: Update the maintainer mail address for stk1160
I'd rather use my work mail address to get patches, so let's update it. Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index c721042..1202c18 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4236,7 +4236,7 @@ S:Maintained F: block/partitions/efi.* STK1160 USB VIDEO CAPTURE DRIVER -M: Ezequiel Garcia elezegar...@gmail.com +M: Ezequiel Garcia ezequ...@vanguardiasur.com.ar L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git S: Maintained -- 2.3.0 -- 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: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id
Hi Grant, Rob, Am Dienstag, den 03.03.2015, 08:59 +0100 schrieb Philipp Zabel: Hi Grant, Rob, this series has been around for quite some time now, basically unchanged except for adding fixes for new users of the API that keep appearing over time in different subsystems. It would be really helpful to get this merged for v4.0. Could you still make this happen? Alternatively, could I please get your ack to allow this tag to be merged into the other subsystem trees for v4.1 so that patches that depend on it don't have to wait for yet another merge window? The question still stands. It would be great to hear from you and maybe get this change in at least in time for v4.1. best regards Philipp -- 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 18/18] marvell-ccic: fix Y'CbCr ordering
On 03/09/2015 10:22 PM, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Various formats had their byte ordering implemented incorrectly, and the V4L2_PIX_FMT_UYVY is actually impossible to create, instead you get V4L2_PIX_FMT_YVYU. This was working before commit ad6ac452227b7cb93ac79beec092850d178740b1 (add new formats support for marvell-ccic driver). That commit broke the original format support and the OLPC XO-1 laptop showed wrong colors ever since (if you are crazy enough to attempt to run the latest kernel on it, like I did). I tried to contact the original authors of that commit but I couldn't reach them. So I've added the following to the commit log of this patch: The email addresses of the authors of that patch are no longer valid, so without a way to reach them and ask them about their test setup I am going with what I can test on the OLPC laptop. If this breaks something for someone on their non-OLPC setup, then contact the linux-media mailinglist. My suspicion however is that that commit went in untested. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.1] fixes, blackfin cleanups
Hi Mauro, This patch series has various fixes all over and the blackfin cleanups (this time with new and improved commit messages!). Regards, Hans The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: [media] mn88473: simplify bandwidth registers setting code (2015-03-03 13:09:12 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.1h for you to fetch changes up to 80c9cab2241928ed348a5539478f9a5feb35873d: media: davinci: vpif_display: embed video_device struct in channel_obj (2015-03-10 16:12:55 +0100) Hans Verkuil (7): vb2: check if vb2_fop_write/read is allowed v4l2-framework.txt: debug - dev_debug v4l2-ioctl: tidy up debug messages DocBook media: fix xv601/709 formulas DocBook media: BT.2020 RGB uses limited quantization range videodev2.h: fix comment vivid: BT.2020 R'G'B' is limited range Lad, Prabhakar (22): media: am437x-vpfe: match the OF node/i2c addr instead of name media: am437x-vpfe: return error in case memory allocation failure media: am437x-vpfe: embed video_device struct in vpfe_device media: blackfin: bfin_capture: drop buf_init() callback media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails media: blackfin: bfin_capture: set min_buffers_needed media: blackfin: bfin_capture: set vb2 buffer field media: blackfin: bfin_capture: improve queue_setup() callback media: blackfin: bfin_capture: use vb2_fop_mmap/poll media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release media: blackfin: bfin_capture: use vb2_ioctl_* helpers media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback media: blackfin: bfin_capture: return -ENODATA for *std calls media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls media: blackfin: bfin_capture: add support for vidioc_create_bufs media: blackfin: bfin_capture: add support for VB2_DMABUF media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF media: blackfin: bfin_capture: set v4l2 buffer sequence media: blackfin: bfin_capture: drop bcap_get_unmapped_area() media: blackfin: bfin_capture: embed video_device struct in bcap_device media: davinci: vpif_capture: embed video_device struct in channel_obj media: davinci: vpif_display: embed video_device struct in channel_obj Laurent Pinchart (1): media: am437x: Don't release OF node reference twice Masatake YAMATO (1): am437x: include linux/videodev2.h for expanding BASE_VIDIOC_PRIVATE Tapasweni Pathak (1): drivers: media: platform: vivid: Fix possible null derefrence Documentation/DocBook/media/v4l/pixfmt.xml | 23 +++--- Documentation/video4linux/v4l2-framework.txt | 6 +- drivers/media/platform/am437x/am437x-vpfe.c| 57 ++--- drivers/media/platform/am437x/am437x-vpfe.h| 3 +- drivers/media/platform/blackfin/bfin_capture.c | 348 +++-- drivers/media/platform/davinci/vpif_capture.c | 52 +++- drivers/media/platform/davinci/vpif_capture.h | 2 +- drivers/media/platform/davinci/vpif_display.c | 49 ++- drivers/media/platform/davinci/vpif_display.h | 2 +- drivers/media/platform/vivid/vivid-tpg.c | 4 + drivers/media/platform/vivid/vivid-vid-out.c | 4 +- drivers/media/v4l2-core/v4l2-ioctl.c | 4 +- drivers/media/v4l2-core/videobuf2-core.c | 4 + include/uapi/linux/am437x-vpfe.h | 2 + include/uapi/linux/videodev2.h | 7 +- 15 files changed, 184 insertions(+), 383 deletions(-) -- 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: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id
On Tue, Mar 10, 2015 at 04:24:47PM +0100, Philipp Zabel wrote: Hi Grant, Rob, Am Dienstag, den 03.03.2015, 08:59 +0100 schrieb Philipp Zabel: Hi Grant, Rob, this series has been around for quite some time now, basically unchanged except for adding fixes for new users of the API that keep appearing over time in different subsystems. It would be really helpful to get this merged for v4.0. Could you still make this happen? Alternatively, could I please get your ack to allow this tag to be merged into the other subsystem trees for v4.1 so that patches that depend on it don't have to wait for yet another merge window? The question still stands. It would be great to hear from you and maybe get this change in at least in time for v4.1. Let's look at the history. 10-03-2015: This reminder 03-03-2015: Pull request (ignored from what can be seen) 01-03-2015: Request from Laurent about what's happening 27-02-2015: Reminder 23-02-2015: Re-base (and version 8) due to conflicts 11-02-2015: Reminder 22-01-2015: Pull request 23-12-2014: Version 7 During that time, there's not been one peep from Rob or Grant on this. At what point has there been enough pestering that it's sufficient to bypass an apparently uninterested maintainer, who can't be bothered to say yes or no to a set of patches? For such a key subsystem in the kernel, this is bad. If Grant isn't interested in performing a maintainer role, I'd be willing to pick up that function (which'll be ironic, because that's the kind of thing that Linaro's been doing to me over the last few years... picking stuff off my plate without any discussion or agreement with me first, leaving me with almost nothing to do. No, I'm not pissed at that... not much.) I guess if you were to submit patches to Andrew, Andrew may take them in this circumstance and eventually send them on to Linus. Andrew? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 1/1] Fix DVBsky rc-keymap
Signed-off-by: Dirk Nehring dnehr...@gmx.net
---
drivers/media/rc/keymaps/rc-dvbsky.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-dvbsky.c
b/drivers/media/rc/keymaps/rc-dvbsky.c
index c5115a1..48bf307 100644
--- a/drivers/media/rc/keymaps/rc-dvbsky.c
+++ b/drivers/media/rc/keymaps/rc-dvbsky.c
@@ -33,16 +33,16 @@ static struct rc_map_table rc5_dvbsky[] = {
{ 0x000b, KEY_STOP },
{ 0x000c, KEY_EXIT },
{ 0x000e, KEY_CAMERA }, /*Snap shot*/
- { 0x000f, KEY_SUBTITLE }, /*PIP*/
- { 0x0010, KEY_VOLUMEUP },
- { 0x0011, KEY_VOLUMEDOWN },
+ { 0x000f, KEY_NEW }, /*PIP*/
+ { 0x0010, KEY_RIGHT },
+ { 0x0011, KEY_LEFT },
{ 0x0012, KEY_FAVORITES },
- { 0x0013, KEY_LIST }, /*Info*/
+ { 0x0013, KEY_INFO },
{ 0x0016, KEY_PAUSE },
{ 0x0017, KEY_PLAY },
{ 0x001f, KEY_RECORD },
- { 0x0020, KEY_CHANNELDOWN },
- { 0x0021, KEY_CHANNELUP },
+ { 0x0020, KEY_UP },
+ { 0x0021, KEY_DOWN },
{ 0x0025, KEY_POWER2 },
{ 0x0026, KEY_REWIND },
{ 0x0027, KEY_FASTFORWARD },
--
2.1.0
--
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] v4l: mt9p031: Convert to the gpiod API
Hi Laurent,
Thanks for the patch.
On Sun, Mar 8, 2015 at 1:40 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
This simplifies platform data and DT integration.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/mt9p031.c | 31 +++
include/media/mt9p031.h | 2 --
2 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 89ae2b4..1757ef6 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -15,12 +15,11 @@
#include linux/clk.h
#include linux/delay.h
#include linux/device.h
-#include linux/gpio.h
+#include linux/gpio/consumer.h
#include linux/i2c.h
#include linux/log2.h
#include linux/module.h
#include linux/of.h
-#include linux/of_gpio.h
#include linux/of_graph.h
#include linux/pm.h
#include linux/regulator/consumer.h
@@ -136,7 +135,7 @@ struct mt9p031 {
struct aptina_pll pll;
unsigned int clk_div;
bool use_pll;
- int reset;
+ struct gpio_desc *reset;
struct v4l2_ctrl_handler ctrls;
struct v4l2_ctrl *blc_auto;
@@ -309,9 +308,9 @@ static int mt9p031_power_on(struct mt9p031 *mt9p031)
{
int ret;
- /* Ensure RESET_BAR is low */
- if (gpio_is_valid(mt9p031-reset)) {
- gpio_set_value(mt9p031-reset, 0);
+ /* Ensure RESET_BAR is active */
+ if (mt9p031-reset) {
+ gpiod_set_value(mt9p031-reset, 1);
usleep_range(1000, 2000);
}
@@ -332,8 +331,8 @@ static int mt9p031_power_on(struct mt9p031 *mt9p031)
}
/* Now RESET_BAR must be high */
- if (gpio_is_valid(mt9p031-reset)) {
- gpio_set_value(mt9p031-reset, 1);
+ if (mt9p031-reset) {
+ gpiod_set_value(mt9p031-reset, 0);
usleep_range(1000, 2000);
}
As per the data sheet reset needs to be low initially and then high,
you just reversed it.
Thanks,
--Prabhakar Lad
--
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: [GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id
On Tue, Mar 10, 2015 at 10:42 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Mar 10, 2015 at 04:24:47PM +0100, Philipp Zabel wrote: Hi Grant, Rob, Am Dienstag, den 03.03.2015, 08:59 +0100 schrieb Philipp Zabel: Hi Grant, Rob, this series has been around for quite some time now, basically unchanged except for adding fixes for new users of the API that keep appearing over time in different subsystems. It would be really helpful to get this merged for v4.0. Could you still make this happen? Alternatively, could I please get your ack to allow this tag to be merged into the other subsystem trees for v4.1 so that patches that depend on it don't have to wait for yet another merge window? The question still stands. It would be great to hear from you and maybe get this change in at least in time for v4.1. Let's look at the history. 10-03-2015: This reminder 03-03-2015: Pull request (ignored from what can be seen) 01-03-2015: Request from Laurent about what's happening 27-02-2015: Reminder 23-02-2015: Re-base (and version 8) due to conflicts 11-02-2015: Reminder 22-01-2015: Pull request 23-12-2014: Version 7 During that time, there's not been one peep from Rob or Grant on this. I've only been copied on this latest pull request and a version from March of last year which Grant nak'ed. This series did not go to devicetree list either. I'll take a look at the series. If there is an explanation of how Grant's nak was addressed that would speed up my review. I'm not applying for v4.0 though. Rob At what point has there been enough pestering that it's sufficient to bypass an apparently uninterested maintainer, who can't be bothered to say yes or no to a set of patches? For such a key subsystem in the kernel, this is bad. If Grant isn't interested in performing a maintainer role, I'd be willing to pick up that function (which'll be ironic, because that's the kind of thing that Linaro's been doing to me over the last few years... picking stuff off my plate without any discussion or agreement with me first, leaving me with almost nothing to do. No, I'm not pissed at that... not much.) I guess if you were to submit patches to Andrew, Andrew may take them in this circumstance and eventually send them on to Linus. Andrew? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 3/3] omap3isp: Add a delayed buffers for frame mode
When using an external decoder such as a NTSC decoder chip,
the decoder is sending frame data most of the time making
it very time sensitive to latch onto the CCDC not busy bit
from one frame to the next. This is different than most
parallel cameras that may be attached to the system as
these send frames in more of a bursty way.
This exhibits itself as a problem in the VD0 interrupt, at
least when attached to a ADV7180 using BT.656. In this case
the ISR sometimes misses the small amount of time that the
CCDC is not busy. The ISR attempts to busywait for up to
1ms inside the ISR waiting for the CCDC to stop being busy
and if it misses it it will kill the stream. In testing,
I set this delay up to 10ms with the ADV7180 and often saw
delays of ~6-7ms with this hardware configuration.
To avoid having to adjust this delay, the CCDC hardware
actually does latch the buffer address at each vertical sync
so the driver could modify the buffer address at any point
during a frame to take effect during the next frame. In
this patch, the buffering subsystem has been modified for
BT.656 only so that the timing looks more like this near
the end of each frame:
1. Frame N-2 is released back to userspace
2. Frame N-1 is being filled by the hardware
3. Frame N is loaded into buffer address
This introduces additional latency into the video pipeline and
it requires more buffers to be used in the pipeline, but it
removes the busy waiting in the ISR when it's attempting to
find the time the CCDC is not busy.
Rather than moving the buffers out of the dmaqueue, this patch
leaves the buffers in the dmaqueue so that the rest of the
cleanup code for the system isn't affected. Peeking forward
from the front of the list doesn't take very many cycles to
complete and simplifies this patch's integration with the
rest of the system. Additionally, this patch is set to only
occur when BT.656 is enabled in the system.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
drivers/media/platform/omap3isp/ispccdc.c | 22 +++-
drivers/media/platform/omap3isp/ispvideo.c | 163 -
drivers/media/platform/omap3isp/ispvideo.h | 3 +
3 files changed, 157 insertions(+), 31 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispccdc.c
b/drivers/media/platform/omap3isp/ispccdc.c
index d5de843..882ebde 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1147,6 +1147,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
pdata = ((struct isp_v4l2_subdevs_group *)sensor-host_priv)
-bus.parallel;
+ if (ccdc-bt656)
+ ccdc-video_out.pipe.do_delayed_frames = true;
}
/* CCDC_PAD_SINK */
@@ -1321,9 +1323,23 @@ static void __ccdc_enable(struct isp_ccdc_device *ccdc,
int enable)
* interrupts high enough that they won't be generated.
*/
if (enable) {
- vd0 = format-height - 2;
- vd1 = format-height * 2 / 3;
+ if (ccdc-bt656) {
+ /* Generate VD0 around the first line of the image
+ * and VD1 high enough to not be encountered for BT.656.
+ */
+ vd0 = 1;
+ vd1 = 0x;
+ } else {
+ /* Generate VD0 on the last line of the image and VD1
+ * on the 2/3 height line.
+ */
+ vd0 = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ }
} else {
+ /* Set VD0 and VD1 interrupts high enough that they won't
+ * be generated.
+ */
vd0 = 0x;
vd1 = 0x;
}
@@ -1617,7 +1633,7 @@ static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
}
/* Wait for the CCDC to become idle. */
- if (ccdc_sbl_wait_idle(ccdc, 1000)) {
+ if (!pipe-do_delayed_frames ccdc_sbl_wait_idle(ccdc, 1000)) {
dev_info(isp-dev, CCDC won't become idle!\n);
isp-crashed |= 1U ccdc-subdev.entity.id;
omap3isp_pipeline_cancel_stream(pipe);
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 3fe9047..2764463 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -370,6 +370,34 @@ static int isp_video_buffer_prepare(struct vb2_buffer *buf)
}
/*
+ * isp_video_buffer_queue_ready - Returns true if dmaqueue is in a state that
+ * warrants starting the stream.
+ * @video: Video stream
+ *
+ * This function checks to see if isp_video_buffer_queue should start streaming
+ * of the queue or not. If we're not doing delayed frames, we should kickstart
+ * on the basis of 0 frames currently in the queue. If we are doing delayed
[PATCH 0/3] *** Updates against OMAP3ISP and BT.656
I've been doing some testing for a client's system that has a ADV7180 attached to the omap3isp and integrating it with kernel v3.19 on a DM3730 platform. I had some stability problems with the driver (it would crash sometimes upon stream startup or shutdown) as well as the ISR causing the system to lockup. Additionally, for the system I've described everything with device tree (except for the omap3isp of course since those bindings aren't available yet), and I discovered that the omap3isp was starting before I2C in this case and it needed to support the deferral of probing the I2C client. I also encountered the ISP getting in a state where the interrupts were enabled and firing, but it wasn't actually processing it since the pipeline state wasn't correct yet. I added mitigation to this by modifying when the VD0 and VD1 interrupt trigger levels are setup, and causing these trigger levels to be high enough not to occur when the pipeline is disabled. The other issues I encountered I believe are due to the interaction of the ISP on the OMAP3 and BT.656 in part. It appears that the timing is critical for the ISR when entering since the current design busywaits in the ISR waiting for the ISP to no longer be busy, and it appears that it can end up missing its opportunity. Thus I added some code to have a delayed buffering mode for BT.656 that causes it to hold onto buffers a bit longer than it otherwise would have and rely on the VSYNC latching for the buffers in the CCDC. Tim Nordell (3): omap3isp: Defer probing when subdev isn't available omap3isp: Disable CCDC's VD0 and VD1 interrupts when stream is not enabled omap3isp: Add a delayed buffers for frame mode drivers/media/platform/omap3isp/isp.c | 6 +- drivers/media/platform/omap3isp/ispccdc.c | 43 ++-- drivers/media/platform/omap3isp/ispvideo.c | 163 - drivers/media/platform/omap3isp/ispvideo.h | 3 + 4 files changed, 178 insertions(+), 37 deletions(-) -- 2.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] omap3isp: Defer probing when subdev isn't available
If the subdev isn't available just yet, defer probing of
the system. This is useful if the omap3isp comes up before
the I2C subsystem does.
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
drivers/media/platform/omap3isp/isp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 51c2129..a361c40 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1811,7 +1811,7 @@ isp_register_subdev_group(struct isp_device *isp,
device %s\n, __func__,
board_info-i2c_adapter_id,
board_info-board_info-type);
- continue;
+ return ERR_PTR(-EPROBE_DEFER);
}
subdev = v4l2_i2c_new_subdev_board(isp-v4l2_dev, adapter,
@@ -1898,6 +1898,10 @@ static int isp_register_entities(struct isp_device *isp)
unsigned int i;
sensor = isp_register_subdev_group(isp, subdevs-subdevs);
+ if (IS_ERR(sensor)) {
+ ret = PTR_ERR(sensor);
+ goto done;
+ }
if (sensor == NULL)
continue;
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap3isp: Disable CCDC's VD0 and VD1 interrupts when stream is not enabled
During testing there appeared to be a race condition where the IRQs
for VD0 and VD1 could be triggered while enabling the CCDC module
before the pipeline status was updated. Simply modify the trigger
conditions for VD0 and VD1 so they won't occur when the CCDC module
is not enabled.
(When this occurred during testing, the VD0 interrupt was occurring
over and over again starving the rest of the system.)
Signed-off-by: Tim Nordell tim.nord...@logicpd.com
---
drivers/media/platform/omap3isp/ispccdc.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispccdc.c
b/drivers/media/platform/omap3isp/ispccdc.c
index 587489a..d5de843 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -1218,13 +1218,6 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
}
ccdc_config_imgattr(ccdc, ccdc_pattern);
- /* Generate VD0 on the last line of the image and VD1 on the
-* 2/3 height line.
-*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
- OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
-
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
crop = ccdc-crop;
@@ -1316,11 +1309,29 @@ unlock:
static void __ccdc_enable(struct isp_ccdc_device *ccdc, int enable)
{
+ struct v4l2_mbus_framefmt *format = ccdc-formats[CCDC_PAD_SINK];
struct isp_device *isp = to_isp_device(ccdc);
+ int vd0, vd1;
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_PCR,
ISPCCDC_PCR_EN, enable ? ISPCCDC_PCR_EN : 0);
+ /* Generate VD0 on the last line of the image and VD1 on the
+ * 2/3 height line when enabled. Otherwise, set VD0 and VD1
+ * interrupts high enough that they won't be generated.
+ */
+ if (enable) {
+ vd0 = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ } else {
+ vd0 = 0x;
+ vd1 = 0x;
+ }
+
+ isp_reg_writel(isp, (vd0 ISPCCDC_VDINT_0_SHIFT) |
+ (vd1 ISPCCDC_VDINT_1_SHIFT),
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
+
ccdc-running = enable;
}
--
2.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/8] v4l: xilinx: Add Xilinx Video IP core
On 03/09/2015 09:09 PM, Laurent Pinchart wrote: Hi Hans, Thank you for the review. On Wednesday 04 March 2015 16:11:43 Hans Verkuil wrote: Hi Laurent, Almost OK :-) Great :-) Two small issues remain, see below. On 03/04/15 15:51, Laurent Pinchart wrote: Xilinx platforms have no hardwired video capture or video processing interface. Users create capture and memory to memory processing pipelines in the FPGA fabric to suit their particular needs, by instantiating video IP cores from a large library. The Xilinx Video IP core is a framework that models a video pipeline described in the device tree and expose the pipeline to userspace through the media controller and V4L2 APIs. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Hyun Kwon hyun.k...@xilinx.com Signed-off-by: Radhey Shyam Pandey radh...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- Cc: devicet...@vger.kernel.org Changes since v5: - Report frame field as V4L2_FIELD_NONE - Update to the mainline pad-level subdev API changes - Add VIDIOC_CREATE_BUFS support - Add a comment to explain the lack of VB2_READ and VB2_WRITE Changes since v4: - Use a DT format description closer to the hardware - Document the xvip_device clk field Changes since v3: - Rename V4L2_MBUS_FMT_* to MEDIA_BUS_FMT_* - Cleanup unused vdma configuration. - Add resource init and cleanup helpers - Return buffers to vb2 when media pipeline start fails Changes since v2: - Remove explicit trailing \0 after snprintf - Don't hardcode colorspace Changes since v1: - Remove unnecessary fields from struct xvip_dma_buffer - Fix querycap capabilities and bus_info reporting - Refuse to set format when the queue is busy - Return buffers to vb2 when start_streaming fails - Use vb2 fops and ioctl ops v1 was made of the following individual patches. media: xilinx: vip: Add yuv444 and bayer formats media: xilinx: vip: Remove _TIMING_ from register definition media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback media: xilinx: dma: Fix alignments of xvip_dma_fops definition media: xilinx: dma: Workaround for bytesperline media: xilinx: vip: Add default min/max height/width definitions media: xilinx: vip: Add common sink/source pad IDs media: xilinx: vip: Add xvip_set_format_size() media: xilinx: vip: Add xvip_enum_mbus_code() media: xilinx: vip: Add xvip_enum_frame_size() media: xilinx: vip: Add register clear and set functions media: xilinx: vip: Add xvip_start() media: xilinx: vip: Add xvip_stop() media: xilinx: vip: Add xvip_set_frame_size() media: xilinx: vip: Add enable/disable reg update functions media: xilinx: vip: Add xvip_print_version() media: xilinx: vip: Add xvip_reset() media: xilinx: vip: Add xvip_get_frame_size() media: xilinx: vip: Add suspend/resume helper functions media: xilinx: vip: Change the return value of xvip_get_format_by_code() media: xilinx: vip: Change the return value of xvip_of_get_format() media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc() media: xilinx: vipp: Remove of_match_ptr() media: xilinx: vipp: Add control to inherit subdevice controls media: xilinx: Make disconnected video nodes return -EPIPE at stream on media: xilinx: Make links configurable media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity media: xilinx: Rename xvip_pipeline to xvip_composite_device media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_* media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_* media: xilinx: Rename xvipp_* functions to xvip_composite_* media: xilinx: Move pipeline management code to xilinx-dma.c media: xilinx: Add missing mutex_destroy call media: xilinx: Create xvip_pipeline structure media: xilinx: Support more than two VDMAs in DT media: xilinx: dma: Change vdma configuration to cyclic-mode Revert media: xilinx: dma: Workaround for bytesperline media: xilinx: Added DMA error handling media: xilinx: Fix error handling media: xilinx: Reordered mutexes initialization media: xilinx: vipp: Add devicetree bindings documentation media: xilinx: Reordered mutexes initialization media: xilinx: Set format description in enum_fmt media: xilinx: Remove global control handler media: xilinx: dma: Use the interleaved dmaengine API xilinx: Remove .owner field for drivers v4l: xilinx: video: Rename compatible string to xlnx,video v4l: xilinx: Remove axi- prefix from DT properties v4l: xilinx: dma: Give back queued buffers at streamoff time --- .../devicetree/bindings/media/xilinx/video.txt | 35 + .../bindings/media/xilinx/xlnx,video.txt | 55 ++ MAINTAINERS| 9 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/xilinx/Kconfig | 10 + drivers/media/platform/xilinx/Makefile |
Re: [PATCH 1/1] Fix DVBsky rc-keymap
On 03/10/2015 12:02 AM, Dirk Nehring wrote:
Signed-off-by: Dirk Nehring dnehr...@gmx.net
---
drivers/media/rc/keymaps/rc-dvbsky.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-dvbsky.c
b/drivers/media/rc/keymaps/rc-dvbsky.c
index c5115a1..b942b16 100644
--- a/drivers/media/rc/keymaps/rc-dvbsky.c
+++ b/drivers/media/rc/keymaps/rc-dvbsky.c
@@ -33,16 +33,16 @@ static struct rc_map_table rc5_dvbsky[] = {
{ 0x000b, KEY_STOP },
{ 0x000c, KEY_EXIT },
{ 0x000e, KEY_CAMERA }, /*Snap shot*/
- { 0x000f, KEY_SUBTITLE }, /*PIP*/
- { 0x0010, KEY_VOLUMEUP },
- { 0x0011, KEY_VOLUMEDOWN },
+ { 0x000f, KEY_TV2 }, /*PIP*/
I don't know what kind of layout there really is, but according to
comment that button is PIP which should be KEY_NEW. I wonder if you
mapped those UP/DOWN buttons also badly...
http://linuxtv.org/wiki/index.php/Remote_Controllers
+ { 0x0010, KEY_RIGHT },
+ { 0x0011, KEY_LEFT },
{ 0x0012, KEY_FAVORITES },
- { 0x0013, KEY_LIST }, /*Info*/
+ { 0x0013, KEY_INFO },
{ 0x0016, KEY_PAUSE },
{ 0x0017, KEY_PLAY },
{ 0x001f, KEY_RECORD },
- { 0x0020, KEY_CHANNELDOWN },
- { 0x0021, KEY_CHANNELUP },
+ { 0x0020, KEY_UP },
+ { 0x0021, KEY_DOWN },
{ 0x0025, KEY_POWER2 },
{ 0x0026, KEY_REWIND },
{ 0x0027, KEY_FASTFORWARD },
--
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] uvcvideo: Don't call vb2 mmap and get_unmapped_area with queue lock held
Hi Bjørn, (it took me half an hour to figure out how to write ø on my keyboard :-)) On Monday 09 March 2015 12:06:36 Bjørn Mork wrote: Bjørn Mork bj...@mork.no writes: Laurent Pinchart laurent.pinch...@ideasonboard.com writes: Bjørn, does this fix the circular locking dependency you have reported in [v3.19-rc7] possible circular locking dependency in uvc_queue_streamoff ? The report mentions involves locks, so I'm not 100% this patch will fix the issue. Sorry, I forgot all about that report after firing it off... Should have followed it up with some more details. Grepping my logs now I cannot find this warning at all after the one I reported. I see it once before (while running 3.19-rc6). So it is definitely not easily reproducible. And I have a bad feeling the trigger might involve completely unrelated USB issues... In any case, thanks for the patch. I will test it for a while and let you know if the same warning shows ut with it. But based on the rare occurence, I don't think I ever will be able to positively confirm that the warning is gone. FWIW, I have not seen the warning after applying this patch, so it appears to fix the problem. Thanks. You're welcome. If I'm wrong, then I'm sure Murphy will tell us as soon as I send this email :-) I'd be happy to prove Murphy wrong for once. -- 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 v6 6/8] v4l: xilinx: Add Xilinx Video IP core
Hi Hans, Thank you for the review. On Wednesday 04 March 2015 16:11:43 Hans Verkuil wrote: Hi Laurent, Almost OK :-) Great :-) Two small issues remain, see below. On 03/04/15 15:51, Laurent Pinchart wrote: Xilinx platforms have no hardwired video capture or video processing interface. Users create capture and memory to memory processing pipelines in the FPGA fabric to suit their particular needs, by instantiating video IP cores from a large library. The Xilinx Video IP core is a framework that models a video pipeline described in the device tree and expose the pipeline to userspace through the media controller and V4L2 APIs. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Hyun Kwon hyun.k...@xilinx.com Signed-off-by: Radhey Shyam Pandey radh...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- Cc: devicet...@vger.kernel.org Changes since v5: - Report frame field as V4L2_FIELD_NONE - Update to the mainline pad-level subdev API changes - Add VIDIOC_CREATE_BUFS support - Add a comment to explain the lack of VB2_READ and VB2_WRITE Changes since v4: - Use a DT format description closer to the hardware - Document the xvip_device clk field Changes since v3: - Rename V4L2_MBUS_FMT_* to MEDIA_BUS_FMT_* - Cleanup unused vdma configuration. - Add resource init and cleanup helpers - Return buffers to vb2 when media pipeline start fails Changes since v2: - Remove explicit trailing \0 after snprintf - Don't hardcode colorspace Changes since v1: - Remove unnecessary fields from struct xvip_dma_buffer - Fix querycap capabilities and bus_info reporting - Refuse to set format when the queue is busy - Return buffers to vb2 when start_streaming fails - Use vb2 fops and ioctl ops v1 was made of the following individual patches. media: xilinx: vip: Add yuv444 and bayer formats media: xilinx: vip: Remove _TIMING_ from register definition media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback media: xilinx: dma: Fix alignments of xvip_dma_fops definition media: xilinx: dma: Workaround for bytesperline media: xilinx: vip: Add default min/max height/width definitions media: xilinx: vip: Add common sink/source pad IDs media: xilinx: vip: Add xvip_set_format_size() media: xilinx: vip: Add xvip_enum_mbus_code() media: xilinx: vip: Add xvip_enum_frame_size() media: xilinx: vip: Add register clear and set functions media: xilinx: vip: Add xvip_start() media: xilinx: vip: Add xvip_stop() media: xilinx: vip: Add xvip_set_frame_size() media: xilinx: vip: Add enable/disable reg update functions media: xilinx: vip: Add xvip_print_version() media: xilinx: vip: Add xvip_reset() media: xilinx: vip: Add xvip_get_frame_size() media: xilinx: vip: Add suspend/resume helper functions media: xilinx: vip: Change the return value of xvip_get_format_by_code() media: xilinx: vip: Change the return value of xvip_of_get_format() media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc() media: xilinx: vipp: Remove of_match_ptr() media: xilinx: vipp: Add control to inherit subdevice controls media: xilinx: Make disconnected video nodes return -EPIPE at stream on media: xilinx: Make links configurable media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity media: xilinx: Rename xvip_pipeline to xvip_composite_device media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_* media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_* media: xilinx: Rename xvipp_* functions to xvip_composite_* media: xilinx: Move pipeline management code to xilinx-dma.c media: xilinx: Add missing mutex_destroy call media: xilinx: Create xvip_pipeline structure media: xilinx: Support more than two VDMAs in DT media: xilinx: dma: Change vdma configuration to cyclic-mode Revert media: xilinx: dma: Workaround for bytesperline media: xilinx: Added DMA error handling media: xilinx: Fix error handling media: xilinx: Reordered mutexes initialization media: xilinx: vipp: Add devicetree bindings documentation media: xilinx: Reordered mutexes initialization media: xilinx: Set format description in enum_fmt media: xilinx: Remove global control handler media: xilinx: dma: Use the interleaved dmaengine API xilinx: Remove .owner field for drivers v4l: xilinx: video: Rename compatible string to xlnx,video v4l: xilinx: Remove axi- prefix from DT properties v4l: xilinx: dma: Give back queued buffers at streamoff time --- .../devicetree/bindings/media/xilinx/video.txt | 35 + .../bindings/media/xilinx/xlnx,video.txt | 55 ++ MAINTAINERS| 9 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/xilinx/Kconfig
[GIT FIXES FOR v4.0] Two fixes
Hi Mauro, Two bug fixes for 4.0. The sh_veu patch was actually posted in December, but the git pull request I made had no subject and that was likely the reason it was never picked up by patchwork. I only discovered that today when I was cleaning up old branches in my git development tree. Well, better late than never. Regards, Hans The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: [media] mn88473: simplify bandwidth registers setting code (2015-03-03 13:09:12 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.0a for you to fetch changes up to 0031b9ce6fde58cfcd9dccb472a4d5affb2bf513: cx23885: fix querycap (2015-03-10 09:06:28 +0100) Hans Verkuil (2): sh_veu: v4l2_dev wasn't set cx23885: fix querycap drivers/media/pci/cx23885/cx23885-417.c | 13 ++--- drivers/media/platform/sh_veu.c | 1 + 2 files changed, 7 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix DVBsky rc-keymap
On Tue, Mar 10, 2015 at 09:53:04AM +0200, Antti Palosaari wrote:
On 03/10/2015 12:02 AM, Dirk Nehring wrote:
Signed-off-by: Dirk Nehring dnehr...@gmx.net
---
drivers/media/rc/keymaps/rc-dvbsky.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-dvbsky.c
b/drivers/media/rc/keymaps/rc-dvbsky.c
index c5115a1..b942b16 100644
--- a/drivers/media/rc/keymaps/rc-dvbsky.c
+++ b/drivers/media/rc/keymaps/rc-dvbsky.c
@@ -33,16 +33,16 @@ static struct rc_map_table rc5_dvbsky[] = {
{ 0x000b, KEY_STOP },
{ 0x000c, KEY_EXIT },
{ 0x000e, KEY_CAMERA }, /*Snap shot*/
-{ 0x000f, KEY_SUBTITLE }, /*PIP*/
-{ 0x0010, KEY_VOLUMEUP },
-{ 0x0011, KEY_VOLUMEDOWN },
+{ 0x000f, KEY_TV2 }, /*PIP*/
I don't know what kind of layout there really is, but according to
comment that button is PIP which should be KEY_NEW. I wonder if you
mapped those UP/DOWN buttons also badly...
http://linuxtv.org/wiki/index.php/Remote_Controllers
OK, KEY_NEW should be better (I just orientated on other rc
keymaps). The UP/DOWN buttons are correct, the DVBsky rc has no channel
up/down buttons.
Best regards,
Dirk
+{ 0x0010, KEY_RIGHT },
+{ 0x0011, KEY_LEFT },
{ 0x0012, KEY_FAVORITES },
-{ 0x0013, KEY_LIST }, /*Info*/
+{ 0x0013, KEY_INFO },
{ 0x0016, KEY_PAUSE },
{ 0x0017, KEY_PLAY },
{ 0x001f, KEY_RECORD },
-{ 0x0020, KEY_CHANNELDOWN },
-{ 0x0021, KEY_CHANNELUP },
+{ 0x0020, KEY_UP },
+{ 0x0021, KEY_DOWN },
{ 0x0025, KEY_POWER2 },
{ 0x0026, KEY_REWIND },
{ 0x0027, KEY_FASTFORWARD },
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fix DVBsky rc-keymap
On Tue, Mar 10, 2015 at 09:48:33AM +0800, Nibble Max wrote:
Hello,
Mapping VOLUME and CHANNEL keys to the general ones will break some tv
softwares remote control functions.
The remote control has no volume and channel control, I would leave it
to the general mapping. Tested successfully with vdr 2.2.0.
Best regards,
Dirk
Best Regards,
Max
On 2015-03-10 06:05:02, Dirk Nehring dnehr...@gmx.net wrote:
Signed-off-by: Dirk Nehring dnehr...@gmx.net
---
drivers/media/rc/keymaps/rc-dvbsky.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-dvbsky.c
b/drivers/media/rc/keymaps/rc-dvbsky.c
index c5115a1..b942b16 100644
--- a/drivers/media/rc/keymaps/rc-dvbsky.c
+++ b/drivers/media/rc/keymaps/rc-dvbsky.c
@@ -33,16 +33,16 @@ static struct rc_map_table rc5_dvbsky[] = {
{ 0x000b, KEY_STOP },
{ 0x000c, KEY_EXIT },
{ 0x000e, KEY_CAMERA }, /*Snap shot*/
-{ 0x000f, KEY_SUBTITLE }, /*PIP*/
-{ 0x0010, KEY_VOLUMEUP },
-{ 0x0011, KEY_VOLUMEDOWN },
+{ 0x000f, KEY_TV2 }, /*PIP*/
+{ 0x0010, KEY_RIGHT },
+{ 0x0011, KEY_LEFT },
{ 0x0012, KEY_FAVORITES },
-{ 0x0013, KEY_LIST }, /*Info*/
+{ 0x0013, KEY_INFO },
{ 0x0016, KEY_PAUSE },
{ 0x0017, KEY_PLAY },
{ 0x001f, KEY_RECORD },
-{ 0x0020, KEY_CHANNELDOWN },
-{ 0x0021, KEY_CHANNELUP },
+{ 0x0020, KEY_UP },
+{ 0x0021, KEY_DOWN },
{ 0x0025, KEY_POWER2 },
{ 0x0026, KEY_REWIND },
{ 0x0027, KEY_FASTFORWARD },
--
2.1.0
--
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
hyvää päivää
hyvää päivää Hanki laina tänään Loan Engine, jonka korko on 3%. Täytä muodostavat alle jos kiinnostaa: Sukupuoli: maa: Määrä tarvitaan: Kesto: Mission: On monia syitä, miksi lainan voi auttaa tervehdys Ana Paula -- 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
