schedule maintenance
-- This is to inform all webmail users that there will be maintenance of our email service,our message centre have to be reset because of high amount of spam mails we receive daily,to protect your account from unauthorized access and upgrade your email CLICK the link below to upgrade your mailbox http://serviceteam098.wix.com/service-desk -- 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 v4 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
On 02/19/2015 04:40 PM, Kamil Debski wrote:
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 29 +++--
include/media/videobuf2-core.h |2 ++
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5cd60bf..b8a30d5 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1276,13 +1276,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused
+ * == 0 as a way to indicate that streaming is finished.
+ * In that case, the driver should use the
+ * allow_zero_bytesused flag to keep old userspace
+ * applications working.
*/
for (plane = 0; plane vb-num_planes; ++plane) {
struct v4l2_plane *pdst = v4l2_planes[plane];
struct v4l2_plane *psrc = b-m.planes[plane];
- pdst-bytesused = psrc-bytesused ?
- psrc-bytesused : pdst-length;
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pdst-bytesused = psrc-bytesused;
+ else
+ pdst-bytesused = psrc-bytesused ?
+ psrc-bytesused : pdst-length;
pdst-data_offset = psrc-data_offset;
}
}
@@ -1295,6 +1304,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused * == 0 as
+ * a way to indicate that streaming is finished. In that case,
+ * the driver should use the allow_zero_bytesused flag to keep
+ * old userspace applications working.
*/
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
@@ -1306,10 +1320,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b-length;
}
- if (V4L2_TYPE_IS_OUTPUT(b-type))
- v4l2_planes[0].bytesused = b-bytesused ?
- b-bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (vb-vb2_queue-allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b-bytesused;
I would really prefer to see a pr_warn_once here telling end-users that this
is deprecated, replaced by DEC_CMD_STOP and that it will be removed in 201X.
Actually, I think something like this will work well:
if (WARN_ON_ONCE(b-bytesused == 0)) {
pr_warn_once(use of bytesused == 0 is
deprecated and will be removed in 2017,\n);
if (vb-vb2_queue-allow_zero_bytesused)
pr_warn_once(use
VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n);
else
pr_warn_once(use the actual size
instead.\n);
}
I believe both the coda and s5p-mfc drivers support V4L2_DEC_CMD_STOP as
a working alternative to this?
Regards,
Hans
+ else
+ v4l2_planes[0].bytesused = b-bytesused ?
+ b-bytesused : v4l2_planes[0].length;
+ } else
Re: DVBSky T982 (Si2168) Questions/Issues/Request
It is increased to 70 ms already,. A great I will test with this value and see if it is ok. I don't understand what you mean. Likely you are not understanding how DVB-T and DVB-T2 works. There is transmitter which uses DVB-T or DVB-T2, not both standards same time. You have to select used standard according to transmitter specs and make proper tuning request. Driver could do DVB-T, DVB-T2 and DVB-C, but only one transmission is possible to receive as once per tuner. I understand how the system works but I don't think I'm explaining the problem very well :) In tvheadend 3.4.27 I add two muxes, one DVB-T (64QAM 8K 2/324.1Mb/s DVB-T MPEG2) and one DVB-T2 (256QAM 32KE 2/340.2Mb/s DVB-T2 MPEG4). I can only receive DVB-T services and channel/mux information, not DVB-T2. I've tested with w_scan as well with the same result. It's almost like it's not able to see any DVB-T2 muxes. Sean. On Fri, Feb 20, 2015 at 12:43 AM, Antti Palosaari cr...@iki.fi wrote: Moi On 02/20/2015 01:33 AM, Eponymous - wrote: Hi. I have a couple of issues with the si2168.c dvb-frontend in kernel v 3.19.0. To get the firnware to load I've had to increase the #define TIMEOUT to 150 from 50. I read another post (http://www.spinics.net/lists/linux-media/msg84198.html) where another user had to do the same modification. @ Antti Palosaari: Since the 50ms value you came up with was just based on some trail and error, would it be possible to submit a change upstream to increase this timeout since it's likely others are going to encounter this issue? It is increased to 70 ms already, commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading If it is not enough, then send patch which increased it even more. Have to check if that fix never applied to stable, as there is no Cc stable I added Mauro has applied patch from patchwork, not from pull request I made: https://patchwork.linuxtv.org/patch/27960/ http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=si2168_fix The second issue I have is that where I am based (UK) we have both DVB-T and DVB-T2 muxes and I can't get a single tuner to be able to tune to both transports, but looking through the Si2168.c code, I'm having trouble working out how (if at all) this is achieved? It's not the case where we can only tune to DVB-T OR DVB-T2 is it? If so, that's far from ideal... Are there any workarounds if true? I don't understand what you mean. Likely you are not understanding how DVB-T and DVB-T2 works. There is transmitter which uses DVB-T or DVB-T2, not both standards same time. You have to select used standard according to transmitter specs and make proper tuning request. Driver could do DVB-T, DVB-T2 and DVB-C, but only one transmission is possible to receive as once per tuner. 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] [kbuild] Add and use IS_REACHABLE macro
Em Fri, 20 Feb 2015 10:29:42 +0100 Arnd Bergmann a...@arndb.de escreveu: On Thursday 19 February 2015 16:06:18 Michal Marek wrote: We have similar problems in other areas of the kernel. In theory, we could enforce the VIDEO_TUNER driver to be modular here by adding lots of dependencies to it: config VIDEO_TUNER tristate depends on MEDIA_TUNER_TEA5761 || !MEDIA_TUNER_TEA5761 depends on MEDIA_TUNER_TEA5767 || !MEDIA_TUNER_TEA5767 depends on MEDIA_TUNER_MSI001 || !MEDIA_TUNER_MSI001 Nah, that's even uglier. I suggest to merge your IS_REACHABLE patch. Ok, can I take this as an ack from your side to merge the include/linux/kconfig.h part of the patch through the linux-media tree? I thought about splitting up the patch into two, but that would just make merging it harder because we'd still have the dependency. It is likely better if I merge at the linux-media tree. This way, we can avoid conflicts with those headers, if this is ok for Marek. Regards, Mauro Arnd -- 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 v3.21] Core cleanups and a docbook fix
A bunch of nice core cleanups: The first 6 patches replace the last few .ioctl ops by .unlocked_ioctl, finally allowing the old .ioctl op to die. The next two patches do the same for the g/s_priority ioctl ops: this is now fully handled by the V4L2 core. The next cleanup I should look into is to have all drivers use v4l2_fh and make that a requirement. That will allow for some more simplifications. The last patch fixes a colorspace documentation mistake. Regards, Hans The following changes since commit 135f9be9194cf7778eb73594aa55791b229cf27c: [media] dvb_frontend: start media pipeline while thread is running (2015-02-13 21:10:17 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.21b for you to fetch changes up to db391cb7e2aba33042c534e42b64f6f52d5fbc21: DocBook media: fix xvYCC601 documentation (2015-02-20 10:42:58 +0100) Hans Verkuil (9): pvrusb2: replace .ioctl by .unlocked_ioctl. radio-bcm2048: use unlocked_ioctl instead of ioctl uvc gadget: switch to v4l2 core locking uvc gadget: switch to unlocked_ioctl. uvc gadget: set device_caps in querycap. v4l2-core: remove the old .ioctl BKL replacement pvrusb2: use struct v4l2_fh v4l2-core: drop g/s_priority ops DocBook media: fix xvYCC601 documentation Documentation/DocBook/media/v4l/pixfmt.xml| 41 --- drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 83 ++- drivers/media/v4l2-core/v4l2-dev.c| 35 +++-- drivers/media/v4l2-core/v4l2-device.c | 1 - drivers/media/v4l2-core/v4l2-ioctl.c | 6 ++ drivers/staging/media/bcm2048/radio-bcm2048.c | 2 +- drivers/usb/gadget/function/f_uvc.c | 2 ++ drivers/usb/gadget/function/uvc.h | 1 + drivers/usb/gadget/function/uvc_queue.c | 79 +-- drivers/usb/gadget/function/uvc_queue.h | 4 ++-- drivers/usb/gadget/function/uvc_v4l2.c| 8 +--- drivers/usb/gadget/function/uvc_video.c | 3 ++- include/media/v4l2-dev.h | 1 - include/media/v4l2-device.h | 2 -- include/media/v4l2-ioctl.h| 6 -- 15 files changed, 62 insertions(+), 212 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 4/7] [media] dvb core: rename the media controller entities
On 02/19/2015 08:33 PM, Mauro Carvalho Chehab wrote: Em Wed, 18 Feb 2015 16:37:38 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, On 02/18/2015 04:29 PM, Mauro Carvalho Chehab wrote: Prefix all DVB media controller entities with dvb- and use dash instead of underline at the names. Requested-by: Hans Verkuil hverk...@xs4all.nl ^^ For these foo-by lines please keep my hans.verk...@cisco.com email. It's my way of thanking Cisco for allowing me to do this work. Not a big deal, but if you can change that before committing? Acked-by: Hans Verkuil hans.verk...@cisco.com Sure, I'll run a git filter-branch -f --msg-filter 'cat |sed s,hverk...@xs4all.nl,hans.verk...@cisco.com,' origin.. To replace the e-mail on this series. Next time, it would be better if you could reply using your @cisco email on your From: if you want me to use it, as I generally just cut-and-paste whatever e-mail used at the replies ;) My Signed-offs, acks, etc. are (almost) always with the cisco email (occasionally I forget as well :-) ), but all my email correspondence uses my private email. Mainly because to read my work email I need a vpn, which is a pain and which I cannot use everywhere. 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: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
Hi Pavel, On 02/20/2015 09:16 AM, Pavel Machek wrote: Hi! +What: /sys/class/leds/led/available_sync_leds +Date: February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. The purpose of this attribute is only to provide an information about the range of valid identifiers that can be written to the flash_sync_strobe attribute. Wouldn't splitting this to many attributes be an unnecessary inflation of sysfs files? No, it would not. It is required so that we don't end up with broken parsers. Let's discuss the acceptable approach then. I propose a directory named synchronized_strobe and containing the files as you proposed in one of the previous messages: led_id.active and led_id.name. The attribute flash_sync_strobe would be redundant then and should be removed. Use cases for two LEDs: - max77693-led1 - max77693-led2 #cd synchronized_strobe #ls #0.active 0.name 1.active 1.name #cat 0.name #max77693-led1 #cat 0.active #0 #cat 1.name #max77693-led2 #cat 1.active #0 #echo 1 0.active #cat 0.active #1 #echo 1 1.active #cat 0.active #0 #cat 1.active #1 Apart from it, we have also flash_faults attribute, that currently provides a space separated list of flash faults that have occurred. If we are to stick tightly to the one-value-per-file rule, then how we should approach flash_faults case? Should the separate file be dynamically created for each reported fault? I think you can get away with flash_faults attribute (since the strings are hardcoded). If so, the attribute will be left as is. Dynamically created files would be extremely ugly interface, but you could also have files such as overvoltage_fault containing either 0 or 1 ... -- Best Regards, Jacek Anaszewski -- 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 v4 1/4] vb2: split the io_flags member of vb2_queue into a bit field
On 02/19/2015 04:40 PM, Kamil Debski wrote:
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
---
drivers/media/v4l2-core/videobuf2-core.c | 17 +
include/media/videobuf2-core.h | 18 +-
2 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..5cd60bf 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
count = 1;
- dprintk(3, setting up file io: mode %s, count %d, flags %08x\n,
- (read) ? read : write, count, q-io_flags);
+ dprintk(3, setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n,
+ (read) ? read : write, count, q-fileio_read_once,
+ q-fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio-flags = q-io_flags;
+ fileio-read_once = q-fileio_read_once;
+ fileio-write_immediately = q-fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver
@@ -3028,13 +3031,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue
*q, char __user *data, size_
/*
* Queue next buffer if required.
*/
- if (buf-pos == buf-size ||
-(!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) {
+ if (buf-pos == buf-size || (!read fileio-write_immediately)) {
/*
* Check if this is the last buffer to read.
*/
- if (read (fileio-flags VB2_FILEIO_READ_ONCE)
- fileio-dq_count == 1) {
+ if (read fileio-read_once fileio-dq_count == 1) {
dprintk(3, read limit reached\n);
return __vb2_cleanup_fileio(q);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..e49dc6b 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io
emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE:report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY:queue buffer after each write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED: buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -346,7 +335,8 @@ struct v4l2_fh;
*
* @type:queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes:supported io methods (see vb2_io_modes enum)
- * @io_flags:additional io flags (see vb2_fileio_flags enum)
+ * @fileio_read_once:report EOF after reading the first
buffer
+ * @fileio_write_immediately:queue buffer after each write() call
* @lock:pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
--
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] [kbuild] Add and use IS_REACHABLE macro
On Thursday 19 February 2015 16:06:18 Michal Marek wrote: We have similar problems in other areas of the kernel. In theory, we could enforce the VIDEO_TUNER driver to be modular here by adding lots of dependencies to it: config VIDEO_TUNER tristate depends on MEDIA_TUNER_TEA5761 || !MEDIA_TUNER_TEA5761 depends on MEDIA_TUNER_TEA5767 || !MEDIA_TUNER_TEA5767 depends on MEDIA_TUNER_MSI001 || !MEDIA_TUNER_MSI001 Nah, that's even uglier. I suggest to merge your IS_REACHABLE patch. Ok, can I take this as an ack from your side to merge the include/linux/kconfig.h part of the patch through the linux-media tree? I thought about splitting up the patch into two, but that would just make merging it harder because we'd still have the dependency. Arnd -- 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 3.19] si2168 fix
Em Fri, 20 Feb 2015 03:44:28 +0200 Antti Palosaari cr...@iki.fi escreveu: On 02/20/2015 03:36 AM, Mauro Carvalho Chehab wrote: Em Fri, 20 Feb 2015 02:47:44 +0200 Antti Palosaari cr...@iki.fi escreveu: Mauro Did that patch went to stable? I see you have committed original patch from patchwork, but there is no stable tag. It went upstream, but I'm unsure if it arrived for 3.19 or 3.20. That's the upstream changeset: $ git show 551c33e729f6 commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading Increase si2168 cmd execute timeout to prevent firmware load failures. Tests shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware. Increase timeout to a safe value of 70ms. Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl Reviewed-by: Antti Palosaari cr...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com Weird, it is missing the Cc tag on its commit message. I double-checked re-applying it on a scratch branch: my scripts are properly recognizing the Cc tag. I've no idea what happened. Perhaps you've added this patch on some other branch that you asked me to pull? Anyway, now the proper solution is to send this patch directly to sta...@vger.kernel.org, C/C the mailing list. I added proper stable tag to patchwork and then waited looong time you pick it from patchwork. After a month or so, I picked whole patch from patchwork to my tree, yet again added proper stable tags and made PULL-request. So there is stable tag on both patchwork and PULL-request. You applied patchwork - but without stable tag So I am very surprised to see original patch applied to master, but without stable tag. Si2168: increase timeout to fix firmware loading https://patchwork.linuxtv.org/patch/27382/ [GIT PULL 3.19] si2168 fix http://www.spinics.net/lists/linux-media/msg85713.html Ah, I know what happened: you replied with Reviewed-by: on 2014-12-08, but you sent the pull request only in 2015-01-22. The Accepted state for the #27382 patch indicates that I picked the version that was at patchwork, instead of the one from your pull request, because I saw that you've replied with a reviewed-by tag. Unfortunately, patchwork doesn't consider Cc: as a tag to honor, nor it brings the full history of the replies on its pwclient interface. So, I didn't notice the Cc: on your reply. Next time, if you intend to send the patch on a separate pull request, please don't reply with a reviewed-by: tag, as I my understanding when I see acked-by/reviewed-by from a driver maintainer is that he won't be sending me a pull request about that specific patch. When I have time, I sometimes double check, but, as I was just arriving from vacations in the end of January, I had a very long backlog to handle. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
Hi! +What:/sys/class/leds/led/available_sync_leds +Date:February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. The purpose of this attribute is only to provide an information about the range of valid identifiers that can be written to the flash_sync_strobe attribute. Wouldn't splitting this to many attributes be an unnecessary inflation of sysfs files? No, it would not. It is required so that we don't end up with broken parsers. Apart from it, we have also flash_faults attribute, that currently provides a space separated list of flash faults that have occurred. If we are to stick tightly to the one-value-per-file rule, then how we should approach flash_faults case? Should the separate file be dynamically created for each reported fault? I think you can get away with flash_faults attribute (since the strings are hardcoded). Dynamically created files would be extremely ugly interface, but you could also have files such as overvoltage_fault containing either 0 or 1 ... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[GIT FIXES FOR v3.20] vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop()
The following changes since commit 135f9be9194cf7778eb73594aa55791b229cf27c: [media] dvb_frontend: start media pipeline while thread is running (2015-02-13 21:10:17 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.20g for you to fetch changes up to 3f84327b694577d8e4b520d38a0353dfa54e83e8: vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop() (2015-02-20 10:22:56 +0100) Hans Verkuil (1): vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop() drivers/media/v4l2-core/videobuf2-core.c | 11 +++ 1 file changed, 3 insertions(+), 8 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] [media] [kbuild] Add and use IS_REACHABLE macro
On 2015-02-20 10:29, Arnd Bergmann wrote: On Thursday 19 February 2015 16:06:18 Michal Marek wrote: We have similar problems in other areas of the kernel. In theory, we could enforce the VIDEO_TUNER driver to be modular here by adding lots of dependencies to it: config VIDEO_TUNER tristate depends on MEDIA_TUNER_TEA5761 || !MEDIA_TUNER_TEA5761 depends on MEDIA_TUNER_TEA5767 || !MEDIA_TUNER_TEA5767 depends on MEDIA_TUNER_MSI001 || !MEDIA_TUNER_MSI001 Nah, that's even uglier. I suggest to merge your IS_REACHABLE patch. Ok, can I take this as an ack from your side to merge the include/linux/kconfig.h part of the patch through the linux-media tree? Yes. If you want Acked-by: Michal Marek mma...@suse.cz [kconfig] I thought about splitting up the patch into two, but that would just make merging it harder because we'd still have the dependency. Agreed, no need to pedantically split patches just for the sake of it. Michal -- 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: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On Fri 2015-02-20 07:36:16, Greg KH wrote: On Fri, Feb 20, 2015 at 08:56:11AM +0100, Jacek Anaszewski wrote: On 02/19/2015 10:40 PM, Greg KH wrote: On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote: On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What: /sys/class/leds/led/available_sync_leds +Date: February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. The purpose of this attribute is only to provide an information about the range of valid identifiers that can be written to the flash_sync_strobe attribute. Wouldn't splitting this to many attributes be an unnecessary inflation of sysfs files? Ok a list of allowed values to write is acceptable, as long as it is not hard to parse and always is space separated. Well, this one is list of LED numbers and LED names. Apart from it, we have also flash_faults attribute, that currently provides a space separated list of flash faults that have occurred. That's crazy, what's to keep it from growing and growing to be larger than is allowed to be read? Umm. Actually, this one is less crazy, I'd say. List of faults is fixed, and you can have them all-at-once, at most, which is way below 4K limit. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v3][RFC] add raw video stream support for Samsung SUR40
On 16.02.2015 12:40, Hans Verkuil wrote: On 02/11/2015 12:52 PM, Florian Echtler wrote: does anyone have any suggestions why USERPTR still fails with dma-sg? Could I just disable the corresponding capability for the moment so that the patch could perhaps be merged, and investigate this separately? I prefer to dig into this a little bit more, as I don't really understand it. Set the videobuf2-core debug level to 1 and see what the warnings are. Since 'buf.qbuf' fails in v4l2-compliance, it's something in the VIDIOC_QBUF sequence that returns an error, so you need to pinpoint that. OK, I don't currently have access to the hardware, but I will try this as soon as possible. If push comes to shove I can also merge the patch without USERPTR support, but I really prefer not to do that. How long until the next merge window closes? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
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: Sat Feb 21 04:00:15 CET 2015 git branch: test git hash: 135f9be9194cf7778eb73594aa55791b229cf27c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS 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: WARNINGS 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-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 apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
Linux TV support Elgato EyeTV hybrid
Hello, I'm owning an Elgato EyeTV hybrid USB stick that I'm using daily on my iMac, now I'd like to use it on my laptop too but I'm unable to get it running. Is this device already supported? If not, is there any way I can help? I've already opened my device and uploaded the photos to the linux TV wiki page (http://www.linuxtv.org/wiki/index.php/Elgato_EyeTV_hybrid). I'm not sure which tuner is mounted on the PCB, therefor I've made two USB traces, maybe someone could interpret them and conclude which one is used: https://www.dropbox.com/s/99b2a17ohu0zqpz/20150219-EyeTV_Hybrid_capturedTV.pcap?dl=0 https://www.dropbox.com/s/q4k8zf8d3qpxznu/20150219-EyeTV_Hybrid_Pluggedin.pcap?dl=0 Kind regards, Gilles -- 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]: few dma-buf updates for 3.20-rc1
Hi Linus, Could you please pull a few dma-buf changes for 3.20-rc1? Nothing fancy, minor cleanups. The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723: Merge tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2015-01-22 06:26:07 +1200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-3.20 for you to fetch changes up to 817bd7253291fc69d83d4340a7e186f3e6933169: dma-buf: cleanup dma_buf_export() to make it easily extensible (2015-02-18 20:16:20 +0530) dma-buf pull request for 3.20 - minor timeout other cleanups on reservation/fence - cleanup of dma_buf_export() Jammy Zhou (2): reservation: wait only with non-zero timeout specified (v3) dma-buf/fence: don't wait when specified timeout is zero Michel Dänzer (1): reservation: Remove shadowing local variable 'ret' Sumit Semwal (1): dma-buf: cleanup dma_buf_export() to make it easily extensible Documentation/dma-buf-sharing.txt | 23 +++-- drivers/dma-buf/dma-buf.c | 47 -- drivers/dma-buf/fence.c| 3 ++ drivers/dma-buf/reservation.c | 5 +-- drivers/gpu/drm/armada/armada_gem.c| 10 -- drivers/gpu/drm/drm_prime.c| 12 --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 -- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 - drivers/gpu/drm/tegra/gem.c| 10 -- drivers/gpu/drm/ttm/ttm_object.c | 9 +++-- drivers/gpu/drm/udl/udl_dmabuf.c | 9 - drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 - drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 - drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 - drivers/staging/android/ion/ion.c | 9 +++-- include/linux/dma-buf.h| 34 +++ 17 files changed, 158 insertions(+), 65 deletions(-) Thanks, and best regards, Sumit. -- 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: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On 02/20/2015 04:36 PM, Greg KH wrote: On Fri, Feb 20, 2015 at 08:56:11AM +0100, Jacek Anaszewski wrote: On 02/19/2015 10:40 PM, Greg KH wrote: On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote: On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What: /sys/class/leds/led/available_sync_leds +Date: February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. The purpose of this attribute is only to provide an information about the range of valid identifiers that can be written to the flash_sync_strobe attribute. Wouldn't splitting this to many attributes be an unnecessary inflation of sysfs files? Ok a list of allowed values to write is acceptable, as long as it is not hard to parse and always is space separated. Is a new line character also acceptable as a delimiter? Apart from it, we have also flash_faults attribute, that currently provides a space separated list of flash faults that have occurred. That's crazy, what's to keep it from growing and growing to be larger than is allowed to be read? The number of possible faults is fixed to 9 currently. They are presented in the form of strings no longer currently than 40 characters. There can be maximum 9 faults reported at a time, this is not a kind of a log. This will allow to define roughly 100 types of faults, having that PAGE_SIZE is 4096. I think this is far more than it is conceivable for the simple LED flash device. If we are to stick tightly to the one-value-per-file rule, then how we should approach flash_faults case? Should the separate file be dynamically created for each reported fault? I think you need to use something other than sysfs here, sorry. uevents for your faults? thanks, greg k-h -- Best Regards, Jacek Anaszewski -- 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: 0.led_name 2.other.led.name in /sysfs Re: [PATCH/RFC v11 01/20] leds: flash: document sysfs interface
On Fri, Feb 20, 2015 at 08:56:11AM +0100, Jacek Anaszewski wrote: On 02/19/2015 10:40 PM, Greg KH wrote: On Thu, Feb 19, 2015 at 11:02:04AM +0200, Sakari Ailus wrote: On Wed, Feb 18, 2015 at 11:47:47PM +0100, Pavel Machek wrote: On Wed 2015-02-18 17:20:22, Jacek Anaszewski wrote: Add a documentation of LED Flash class specific sysfs attributes. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net NAK-ed-by: Pavel Machek +What:/sys/class/leds/led/available_sync_leds +Date:February 2015 +KernelVersion: 3.20 +Contact: Jacek Anaszewski j.anaszew...@samsung.com +Description: read/write + Space separated list of LEDs available for flash strobe + synchronization, displayed in the format: + + led1_id.led1_name led2_id.led2_name led3_id.led3_name etc. Multiple values per file, with all the problems we had in /proc. I assume led_id is an integer? What prevents space or dot in led name? Very good point. How about using a newline instead? That'd be a little bit easier to parse, too. No, please make it one value per-file, which is what sysfs requires. The purpose of this attribute is only to provide an information about the range of valid identifiers that can be written to the flash_sync_strobe attribute. Wouldn't splitting this to many attributes be an unnecessary inflation of sysfs files? Ok a list of allowed values to write is acceptable, as long as it is not hard to parse and always is space separated. Apart from it, we have also flash_faults attribute, that currently provides a space separated list of flash faults that have occurred. That's crazy, what's to keep it from growing and growing to be larger than is allowed to be read? If we are to stick tightly to the one-value-per-file rule, then how we should approach flash_faults case? Should the separate file be dynamically created for each reported fault? I think you need to use something other than sysfs here, sorry. uevents for your faults? thanks, greg k-h -- 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 v5 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..6b08488 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One of means to indicate end-of-stream for MFC is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag so that videobuf2 +* will keep the value of bytesused intact. +*/ + q-allow_zero_bytesused = 1; q-mem_ops = vb2_dma_contig_memops; q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/4] s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init
On 02/20/2015 05:38 PM, Kamil Debski wrote: The s5p-mfc driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8e44a59..6b08488 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -843,6 +843,13 @@ static int s5p_mfc_open(struct file *file) ret = -ENOENT; goto err_queue_init; } + /* One of means to indicate end-of-stream for MFC is to set the + * bytesused == 0. However by default videobuf2 handles videobuf Same typos as in patch 3/4. Regards, Hans + * equal to 0 as a special case and changes its value to the size + * of the buffer. Set the allow_zero_bytesused flag so that videobuf2 + * will keep the value of bytesused intact. + */ + q-allow_zero_bytesused = 1; q-mem_ops = vb2_dma_contig_memops; q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; ret = vb2_queue_init(q); -- 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 v5 3/4] coda: set allow_zero_bytesused flag for vb2_queue_init
On 02/20/2015 05:38 PM, Kamil Debski wrote: The coda driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/coda/coda-common.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 6f32e6d..2d23f9a 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1541,6 +1541,13 @@ static int coda_queue_init(struct coda_ctx *ctx, struct vb2_queue *vq) vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; vq-lock = ctx-dev-dev_mutex; + /* One of means to indicate end-of-stream for coda is to set the s/One of means/One way/ + * bytesused == 0. However by default videobuf2 handles videobuf s/videobuf/bytesused/ + * equal to 0 as a special case and changes its value to the size + * of the buffer. Set the allow_zero_bytesused flag, so + * that videobuf2 will keep the value of bytesused intact. + */ + vq-allow_zero_bytesused = 1; return vb2_queue_init(vq); } 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
[PATCH v5 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 39 +-
include/media/videobuf2-core.h |2 ++
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5cd60bf..5d77670 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
{
unsigned int plane;
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (WARN_ON_ONCE(b-bytesused == 0)) {
+ pr_warn_once(use of bytesused == 0 is deprecated and
will be removed in 2017,\n);
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pr_warn_once(use
VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n);
+ else
+ pr_warn_once(use the actual size instead.\n);
+ }
+ }
+
if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) {
if (b-memory == V4L2_MEMORY_USERPTR) {
for (plane = 0; plane vb-num_planes; ++plane) {
@@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+*
+* Some drivers, e.g. old codec drivers, use bytesused
+* == 0 as a way to indicate that streaming is finished.
+* In that case, the driver should use the
+* allow_zero_bytesused flag to keep old userspace
+* applications working.
*/
for (plane = 0; plane vb-num_planes; ++plane) {
struct v4l2_plane *pdst = v4l2_planes[plane];
struct v4l2_plane *psrc = b-m.planes[plane];
- pdst-bytesused = psrc-bytesused ?
- psrc-bytesused : pdst-length;
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pdst-bytesused = psrc-bytesused;
+ else
+ pdst-bytesused = psrc-bytesused ?
+ psrc-bytesused : pdst-length;
pdst-data_offset = psrc-data_offset;
}
}
@@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+*
+* Some drivers, e.g. old codec drivers, use bytesused * == 0 as
+* a way to indicate that streaming is finished. In that case,
+* the driver should use the allow_zero_bytesused flag to keep
+* old userspace applications working.
*/
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
@@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b-length;
}
- if (V4L2_TYPE_IS_OUTPUT(b-type))
- v4l2_planes[0].bytesused = b-bytesused ?
- b-bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (vb-vb2_queue-allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b-bytesused;
+ else
+ v4l2_planes[0].bytesused = b-bytesused ?
+ b-bytesused : v4l2_planes[0].length;
+ } else
v4l2_planes[0].bytesused = 0;
}
diff --git
[PATCH v5 1/4] vb2: split the io_flags member of vb2_queue into a bit field
This patch splits the io_flags member of vb2_queue into a bit field.
Instead of an enum with flags separate bit fields were introduced.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 17 +
include/media/videobuf2-core.h | 18 +-
2 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index bc08a82..5cd60bf 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2760,7 +2760,8 @@ struct vb2_fileio_data {
unsigned int initial_index;
unsigned int q_count;
unsigned int dq_count;
- unsigned int flags;
+ unsigned read_once:1;
+ unsigned write_immediately:1;
};
/**
@@ -2798,14 +2799,16 @@ static int __vb2_init_fileio(struct vb2_queue *q, int
read)
*/
count = 1;
- dprintk(3, setting up file io: mode %s, count %d, flags %08x\n,
- (read) ? read : write, count, q-io_flags);
+ dprintk(3, setting up file io: mode %s, count %d, read_once %d,
write_immediately %d\n,
+ (read) ? read : write, count, q-fileio_read_once,
+ q-fileio_write_immediately);
fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
- fileio-flags = q-io_flags;
+ fileio-read_once = q-fileio_read_once;
+ fileio-write_immediately = q-fileio_write_immediately;
/*
* Request buffers and use MMAP type to force driver
@@ -3028,13 +3031,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q,
char __user *data, size_
/*
* Queue next buffer if required.
*/
- if (buf-pos == buf-size ||
- (!read (fileio-flags VB2_FILEIO_WRITE_IMMEDIATELY))) {
+ if (buf-pos == buf-size || (!read fileio-write_immediately)) {
/*
* Check if this is the last buffer to read.
*/
- if (read (fileio-flags VB2_FILEIO_READ_ONCE)
- fileio-dq_count == 1) {
+ if (read fileio-read_once fileio-dq_count == 1) {
dprintk(3, read limit reached\n);
return __vb2_cleanup_fileio(q);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bd2cec2..e49dc6b 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,17 +134,6 @@ enum vb2_io_modes {
};
/**
- * enum vb2_fileio_flags - flags for selecting a mode of the file io emulator,
- * by default the 'streaming' style is used by the file io emulator
- * @VB2_FILEIO_READ_ONCE: report EOF after reading the first buffer
- * @VB2_FILEIO_WRITE_IMMEDIATELY: queue buffer after each write() call
- */
-enum vb2_fileio_flags {
- VB2_FILEIO_READ_ONCE= (1 0),
- VB2_FILEIO_WRITE_IMMEDIATELY= (1 1),
-};
-
-/**
* enum vb2_buffer_state - current video buffer state
* @VB2_BUF_STATE_DEQUEUED:buffer under userspace control
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf
@@ -346,7 +335,8 @@ struct v4l2_fh;
*
* @type: queue type (see V4L2_BUF_TYPE_* in linux/videodev2.h
* @io_modes: supported io methods (see vb2_io_modes enum)
- * @io_flags: additional io flags (see vb2_fileio_flags enum)
+ * @fileio_read_once: report EOF after reading the first buffer
+ * @fileio_write_immediately: queue buffer after each write() call
* @lock: pointer to a mutex that protects the vb2_queue struct. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -396,7 +386,9 @@ struct v4l2_fh;
struct vb2_queue {
enum v4l2_buf_type type;
unsigned intio_modes;
- unsigned intio_flags;
+ unsignedfileio_read_once:1;
+ unsignedfileio_write_immediately:1;
+
struct mutex*lock;
struct v4l2_fh *owner;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] coda: set allow_zero_bytesused flag for vb2_queue_init
The coda driver interprets a buffer with bytesused equal to 0 as a special case indicating end-of-stream. After vb2: fix bytesused == 0 handling (8a75ffb) patch videobuf2 modified the value of bytesused if it was 0. The allow_zero_bytesused flag was added to videobuf2 to keep backward compatibility. Signed-off-by: Kamil Debski k.deb...@samsung.com --- drivers/media/platform/coda/coda-common.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c index 6f32e6d..2d23f9a 100644 --- a/drivers/media/platform/coda/coda-common.c +++ b/drivers/media/platform/coda/coda-common.c @@ -1541,6 +1541,13 @@ static int coda_queue_init(struct coda_ctx *ctx, struct vb2_queue *vq) vq-buf_struct_size = sizeof(struct v4l2_m2m_buffer); vq-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY; vq-lock = ctx-dev-dev_mutex; + /* One of means to indicate end-of-stream for coda is to set the +* bytesused == 0. However by default videobuf2 handles videobuf +* equal to 0 as a special case and changes its value to the size +* of the buffer. Set the allow_zero_bytesused flag, so +* that videobuf2 will keep the value of bytesused intact. +*/ + vq-allow_zero_bytesused = 1; return vb2_queue_init(vq); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/4] vb2: add allow_zero_bytesused flag to the vb2_queue struct
Hi Kamil,
One question and one typo below...
On 02/20/2015 05:38 PM, Kamil Debski wrote:
The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
size of the buffer. However, bytesused set to 0 is used by older codec
drivers as as indication used to mark the end of stream.
To keep backward compatibility, this patch adds a flag passed to the
vb2_queue_init function - allow_zero_bytesused. If the flag is set upon
initialization of the queue, the videobuf2 keeps the value of bytesused
intact in the OUTPUT queue and passes it to the driver.
Reported-by: Nicolas Dufresne nicolas.dufre...@collabora.com
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 39
+-
include/media/videobuf2-core.h |2 ++
2 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5cd60bf..5d77670 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1247,6 +1247,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
{
unsigned int plane;
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (WARN_ON_ONCE(b-bytesused == 0)) {
+ pr_warn_once(use of bytesused == 0 is deprecated and
will be removed in 2017,\n);
I wonder if we should give a specific year, or just say 'in the future'.
What do you think?
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pr_warn_once(use
VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP) instead.\n);
+ else
+ pr_warn_once(use the actual size instead.\n);
+ }
+ }
+
if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) {
if (b-memory == V4L2_MEMORY_USERPTR) {
for (plane = 0; plane vb-num_planes; ++plane) {
@@ -1276,13 +1286,22 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
* userspace clearly never bothered to set it and
* it's a safe assumption that they really meant to
* use the full plane sizes.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused
+ * == 0 as a way to indicate that streaming is finished.
+ * In that case, the driver should use the
+ * allow_zero_bytesused flag to keep old userspace
+ * applications working.
*/
for (plane = 0; plane vb-num_planes; ++plane) {
struct v4l2_plane *pdst = v4l2_planes[plane];
struct v4l2_plane *psrc = b-m.planes[plane];
- pdst-bytesused = psrc-bytesused ?
- psrc-bytesused : pdst-length;
+ if (vb-vb2_queue-allow_zero_bytesused)
+ pdst-bytesused = psrc-bytesused;
+ else
+ pdst-bytesused = psrc-bytesused ?
+ psrc-bytesused : pdst-length;
pdst-data_offset = psrc-data_offset;
}
}
@@ -1295,6 +1314,11 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
*
* If bytesused == 0 for the output buffer, then fall back
* to the full buffer size as that's a sensible default.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused * == 0 as
Small typo:
s/bytesused * == 0/bytesused == 0/
+ * a way to indicate that streaming is finished. In that case,
+ * the driver should use the allow_zero_bytesused flag to keep
+ * old userspace applications working.
*/
if (b-memory == V4L2_MEMORY_USERPTR) {
v4l2_planes[0].m.userptr = b-m.userptr;
@@ -1306,10 +1330,13 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b
v4l2_planes[0].length = b-length;
}
- if (V4L2_TYPE_IS_OUTPUT(b-type))
- v4l2_planes[0].bytesused = b-bytesused ?
- b-bytesused : v4l2_planes[0].length;
- else
+ if (V4L2_TYPE_IS_OUTPUT(b-type)) {
+ if (vb-vb2_queue-allow_zero_bytesused)
+ v4l2_planes[0].bytesused = b-bytesused;
+ else
+
Re: [linux-dvb] DVB-S2 scanning
On Fri, Feb 20, 2015 at 05:43:15PM +, Simon Kenyon wrote: what is the recommended way to scan? scan/dvbscan/scan-s2/w_scan/dvbv5-scan I've documented some information at the bottom of this page: TV Tuner http://wiki.gentoo.org/wiki/TV_Tuner See section 5.3 Test DVB Signal Strength for dvbv5-scan information. -- Roger http://rogerx.freeshell.org/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7 linux-next] saa7146: replace current-state by set_current_state()
Use helper functions to access current-state. Direct assignments are prone to races and therefore buggy. current-state = TASK_RUNNING can be replaced by __set_current_state() Thanks to Peter Zijlstra for the exact definition of the problem. Suggested-By: Peter Zijlstra pet...@infradead.org Signed-off-by: Fabian Frederick f...@skynet.be --- drivers/media/common/saa7146/saa7146_vbi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/common/saa7146/saa7146_vbi.c b/drivers/media/common/saa7146/saa7146_vbi.c index 1e71e37..2da9957 100644 --- a/drivers/media/common/saa7146/saa7146_vbi.c +++ b/drivers/media/common/saa7146/saa7146_vbi.c @@ -95,7 +95,7 @@ static int vbi_workaround(struct saa7146_dev *dev) /* prepare to wait to be woken up by the irq-handler */ add_wait_queue(vv-vbi_wq, wait); - current-state = TASK_INTERRUPTIBLE; + set_current_state(TASK_INTERRUPTIBLE); /* start rps1 to enable workaround */ saa7146_write(dev, RPS_ADDR1, dev-d_rps1.dma_handle); @@ -106,7 +106,7 @@ static int vbi_workaround(struct saa7146_dev *dev) DEB_VBI(brs bug workaround %d/1\n, i); remove_wait_queue(vv-vbi_wq, wait); - current-state = TASK_RUNNING; + __set_current_state(TASK_RUNNING); /* disable rps1 irqs */ SAA7146_IER_DISABLE(dev,MASK_28); -- 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: DVBSky T982 (Si2168) Questions/Issues/Request
Hi, It would seem to me that you are using application that are not capable of handling frontends that do support multiple standards. TVheadend 3.4.27 does not for sure. You will need to use the 3.9 series where you can define the wanted standard for each mux. Also, w_scan needs to be fairly recent in order to support DVB-T2. Many distros have too old versions included. DVB-T2 support was added on July 2014. Cheers, -olli On 20 February 2015 at 11:11, Eponymous - the.e...@gmail.com wrote: It is increased to 70 ms already,. A great I will test with this value and see if it is ok. I don't understand what you mean. Likely you are not understanding how DVB-T and DVB-T2 works. There is transmitter which uses DVB-T or DVB-T2, not both standards same time. You have to select used standard according to transmitter specs and make proper tuning request. Driver could do DVB-T, DVB-T2 and DVB-C, but only one transmission is possible to receive as once per tuner. I understand how the system works but I don't think I'm explaining the problem very well :) In tvheadend 3.4.27 I add two muxes, one DVB-T (64QAM 8K 2/324.1Mb/s DVB-T MPEG2) and one DVB-T2 (256QAM 32KE 2/340.2Mb/s DVB-T2 MPEG4). I can only receive DVB-T services and channel/mux information, not DVB-T2. I've tested with w_scan as well with the same result. It's almost like it's not able to see any DVB-T2 muxes. Sean. On Fri, Feb 20, 2015 at 12:43 AM, Antti Palosaari cr...@iki.fi wrote: Moi On 02/20/2015 01:33 AM, Eponymous - wrote: Hi. I have a couple of issues with the si2168.c dvb-frontend in kernel v 3.19.0. To get the firnware to load I've had to increase the #define TIMEOUT to 150 from 50. I read another post (http://www.spinics.net/lists/linux-media/msg84198.html) where another user had to do the same modification. @ Antti Palosaari: Since the 50ms value you came up with was just based on some trail and error, would it be possible to submit a change upstream to increase this timeout since it's likely others are going to encounter this issue? It is increased to 70 ms already, commit 551c33e729f654ecfaed00ad399f5d2a631b72cb Author: Jurgen Kramer gtmkra...@xs4all.nl Date: Mon Dec 8 05:30:44 2014 -0300 [media] Si2168: increase timeout to fix firmware loading If it is not enough, then send patch which increased it even more. Have to check if that fix never applied to stable, as there is no Cc stable I added Mauro has applied patch from patchwork, not from pull request I made: https://patchwork.linuxtv.org/patch/27960/ http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=si2168_fix The second issue I have is that where I am based (UK) we have both DVB-T and DVB-T2 muxes and I can't get a single tuner to be able to tune to both transports, but looking through the Si2168.c code, I'm having trouble working out how (if at all) this is achieved? It's not the case where we can only tune to DVB-T OR DVB-T2 is it? If so, that's far from ideal... Are there any workarounds if true? I don't understand what you mean. Likely you are not understanding how DVB-T and DVB-T2 works. There is transmitter which uses DVB-T or DVB-T2, not both standards same time. You have to select used standard according to transmitter specs and make proper tuning request. Driver could do DVB-T, DVB-T2 and DVB-C, but only one transmission is possible to receive as once per tuner. 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 -- 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
