Re: Writing a HDMI-CEC device driver for the IT66121
On 04/01/2014 08:55 PM, Sriakhil Gogineni wrote: > Hi Hans, > > Thanks for the detailed response. As, much as I would love to have a > robust, fully functioning implementation for v1, I think it might be > a a bit of 'over-optimization' to write the complete spec into the > driver from the beginning. > > The question I ask myself is, "how can we get it mainlined quickly?" > I'm not sure of the answer but I would like implement and test basic > features of HDMI-CEC and then add in the more advanced fun stuff ;) To test CEC you typically need three ioctls: read, write and configure. It's what we do for our drivers that support CEC. But this can't be mainlined because the core CEC protocol really needs to be in the kernel. > So I'm trying to test out CEC on the hardware I have. Making clean > interfaces would allow for adaptable between 4l2 devices, drm/kms > devices and hardware. My question is how can I connect to / test on > the hardware I have?> This might help: http://www.spinics.net/lists/linux-media/msg29617.html It's basically what we implemented in our V4L drivers. I have an implementation of this for the adv7511 driver that I can mail you off-list if you are interested. But forget about mainlining this as it is not able to support the newer CEC features as I explained. Regards, Hans > Best, > Sri > > On Apr 1, 2014, at 2:29 AM, Hans Verkuil wrote: > >> Hi Sri, >> >> On 03/31/14 23:12, Sriakhil Gogineni wrote: >>> Hi, >>> >>> I'm trying to write a HDMI-CEC driver for the Radxa Rock >>> (Specification - Radxa). I am coming from a software background and >>> have found libcec and am looking at other implementation. >>> >>> I'm wondering how to connect the hardware and software pieces under >>> Linux / Android. >>> >>> I'm not sure if I need to find out what /dev/ its exposed under via >>> the device tree or determine which register is used from the data >>> sheet? >>> >>> Any advice / tips / pointers would be helpful. >> >> There is currently no kernel CEC support available. What makes cec >> complex is 1) the CEC specification is horrible :-) and 2) a proper cec >> implementation has to be able to take care of v4l2 devices, drm/kms devices >> and usb dongles. In addition, at least some of the CEC handling has to >> take place in the kernel in order to handle the audio return channel, >> suspend commands, hotplug-over-CEC and such advanced features. >> >> I have been working on this, but it is a background project and I never >> found the time to finish it. >> >> My latest code is available here: >> >> http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cec >> >> but it needs more work to make this ready for prime time. >> >> It works, but it needs cleanup and cec_claim_log_addrs() needs improvement. >> Particularly when called from a driver: this needs to be done in non- >> blocking mode which isn't yet working (in blocking mode the driver would >> block for an unacceptable amount of time). >> >> If you or someone else would be willing to take over, I would have no >> objections. I have no idea when I might have time to continue work on >> this. >> >> Regards, >> >> Hans > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] uvcvideo: Fix clock param realtime setting
Hi Laurent, On Tue, 2014-04-01 at 15:49 +0200, Laurent Pinchart wrote: > Hi Olivier, > > On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote: > > Hi Laurent, > > > > > > Yes. ffmpeg uses wall clock time to create timestamps for audio packets > > > > from ALSA device. > > > > > > OK. I suppose I shouldn't drop support for the realtime clock like I > > > wanted to then :-) > > > > > > > There is a bug in ffmpeg describing problems to synchronize audio and > > > > the video from a v4l2 webcam. > > > > > > > > https://trac.ffmpeg.org/ticket/692 > > > > > > > > To workaround this issue, ffmpeg devs added a switch to convert back > > > > > > > > monotonic to realtime. From ffmpeg/libavdevice/v4l2.c: > > > > -ts.D set type of timestamps for > > > > grabbed frames (from 0 to 2) > > > > (default 0) > > > > default .D use timestamps from the kernel > > > > abs .D use absolute timestamps (wall > > > > clock) > > > > mono2abs .D force conversion from monotonic > > > > to absolute timestamps > > > > > > > > If the v4l2 driver is able to send realtime ts, it is easier synchronize > > > > in userspace if all inputs use the same clock. > > > > > > That might be a stupid question, but shouldn't ALSA use the monotonic > > > clock instead ? > > > > I think that I have that answer why ffmpeg use realtime clock for ALSA data. > > In fact ffmpeg uses realtime clock for every data coming from capture > > devices and the purpose is to be able to seek into the recorded stream by > > using the date where the recording occured. Same principle than a camera > > recording dates when pictures are taken. > > > > now a tougher question is whether or not it is up to the driver to provide > > these realtime ts. > > It makes sense to associate a wall time with recorded streams for that > purpose, but synchronization should in my opinion be performed using the > monotonic clock, as the wall time can jump around. I believe drivers should > provide monotonic timestamps only. However, given that the uvcvideo driver > has > the option of providing wall clock timestamps, that option should work, so > your patch makes sense. I'd still like to remove support for the wall clock > though, but I don't want to break userspace. ffmpeg should be fixed, > especially given that most V4L devices provide monotonic timestamps only. > Please do not stop yourself to remove realtime ts support in your driver because that would not break ffmpeg, IMHO. It is just me that have tried to leverage options offered by your driver to remove the need to use ffmpeg workaround for a sync issue. I apparently have been the first ffmpeg user to try out! I am currently in the process to contribute the introduction of using CLOCK_MONOTONIC inside ffmpeg. CCing their list because I think your reply is relevant to the discussion we have on the topic there at the moment. thank you, Olivier -- 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: OK
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 Apr 2 04:00:27 CEST 2014 git branch: test git hash: a83b93a7480441a47856dc9104bea970e84cda87 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-7.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.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.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: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.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: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [yavta PATCH 7/9] Print timestamp type and source for dequeued buffers
Hi Sakari,
Thank you for the patch.
Given that the timestamp type and source are not supposed to change during
streaming, do we really need to print them for every frame ?
On Saturday 01 March 2014 18:18:08 Sakari Ailus wrote:
> Signed-off-by: Sakari Ailus
> ---
> yavta.c | 52 ++--
> 1 file changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/yavta.c b/yavta.c
> index 71c1477..224405d 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -445,6 +445,30 @@ static int video_set_framerate(struct device *dev,
> struct v4l2_fract *time_per_f return 0;
> }
>
> +static void get_ts_flags(uint32_t flags, const char **ts_type, const char
> **ts_source) +{
> + switch (flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) {
> + case V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN:
> + *ts_type = "unknown";
> + break;
> + case V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC:
> + *ts_type = "monotonic";
> + break;
> + default:
> + *ts_type = "invalid";
> + }
> + switch (flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK) {
> + case V4L2_BUF_FLAG_TSTAMP_SRC_EOF:
> + *ts_source = "EoF";
> + break;
> + case V4L2_BUF_FLAG_TSTAMP_SRC_SOE:
> + *ts_source = "SoE";
> + break;
> + default:
> + *ts_source = "invalid";
> + }
> +}
> +
> static int video_alloc_buffers(struct device *dev, int nbufs,
> unsigned int offset, unsigned int padding)
> {
> @@ -488,26 +512,7 @@ static int video_alloc_buffers(struct device *dev, int
> nbufs, strerror(errno), errno);
> return ret;
> }
> - switch (buf.flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) {
> - case V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN:
> - ts_type = "unknown";
> - break;
> - case V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC:
> - ts_type = "monotonic";
> - break;
> - default:
> - ts_type = "invalid";
> - }
> - switch (buf.flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK) {
> - case V4L2_BUF_FLAG_TSTAMP_SRC_EOF:
> - ts_source = "EoF";
> - break;
> - case V4L2_BUF_FLAG_TSTAMP_SRC_SOE:
> - ts_source = "SoE";
> - break;
> - default:
> - ts_source = "invalid";
> - }
> + get_ts_flags(buf.flags, &ts_type, &ts_source);
> printf("length: %u offset: %u timestamp type/source: %s/%s\n",
> buf.length, buf.m.offset, ts_type, ts_source);
>
> @@ -1131,6 +1136,7 @@ static int video_do_capture(struct device *dev,
> unsigned int nframes, last.tv_usec = start.tv_nsec / 1000;
>
> for (i = 0; i < nframes; ++i) {
> + const char *ts_type, *ts_source;
> /* Dequeue a buffer. */
> memset(&buf, 0, sizeof buf);
> buf.type = dev->type;
> @@ -1163,10 +1169,12 @@ static int video_do_capture(struct device *dev,
> unsigned int nframes, fps = fps ? 100.0 / fps : 0.0;
>
> clock_gettime(CLOCK_MONOTONIC, &ts);
> - printf("%u (%u) [%c] %u %u bytes %ld.%06ld %ld.%06ld %.3f
> fps\n", i,
> buf.index, + get_ts_flags(buf.flags, &ts_type, &ts_source);
> + printf("%u (%u) [%c] %u %u bytes %ld.%06ld %ld.%06ld %.3f fps
> tstamp
> type/src %s/%s\n", i, buf.index, (buf.flags & V4L2_BUF_FLAG_ERROR) ? 'E' :
> '-',
> buf.sequence, buf.bytesused, buf.timestamp.tv_sec,
> - buf.timestamp.tv_usec, ts.tv_sec, ts.tv_nsec/1000, fps);
> + buf.timestamp.tv_usec, ts.tv_sec, ts.tv_nsec/1000, fps,
> + ts_type, ts_source);
>
> last = buf.timestamp;
--
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: [yavta PATCH 0/9] Timestamp source and mem-to-mem device support
Hi Sakari, Thank you for the patches, and sorry for the late reply. I've pushed outstanding multiplane patches to the master branch of the yavta repository, and applied the first two patches of this series on top of that. After addressing the commends I've made on the individual patches, could you please rebase the rest of the series and resend it ? On Saturday 01 March 2014 18:18:01 Sakari Ailus wrote: > Hi, > > This patchset enables using yavta for mem-to-mem devices, including > mem2mem_testdev (or soon vim2m). The timestamp will be set for output > buffers when the timestamp type is copy. An option is added to set the > timestamp source flags (eof/soe). > > To use yavta for mem2mem devices, just open the device in the shell and pass > the file descriptor to yavta (--fd). -- 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: [yavta PATCH 6/9] Timestamp source for output buffers
Hi Sakari,
Thank you for the patch.
On Saturday 01 March 2014 18:18:07 Sakari Ailus wrote:
> Signed-off-by: Sakari Ailus
> ---
> yavta.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/yavta.c b/yavta.c
> index a9b192a..71c1477 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -73,6 +73,7 @@ struct device
> unsigned int height;
> unsigned int bytesperline;
> unsigned int imagesize;
> + uint32_t buffer_output_flags;
>
> void *pattern;
> unsigned int patternsize;
> @@ -611,6 +612,7 @@ static int video_queue_buffer(struct device *dev, int
> index, enum buffer_fill_mo buf.m.userptr = (unsigned
> long)dev->buffers[index].mem;
>
> if (dev->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + buf.flags = dev->buffer_output_flags;
> buf.bytesused = dev->patternsize;
> memcpy(dev->buffers[buf.index].mem, dev->pattern,
> dev->patternsize);
> } else {
> @@ -1255,6 +1257,7 @@ static void usage(const char *argv0)
> printf("--no-query Don't query capabilities on
> open\n");
> printf("--offsetUser pointer buffer offset from
> page
> start\n");
> printf("--requeue-last Requeue the last buffers before
> streamoff\n");
> + printf("--timestamp-source Set timestamp source on output
> buffers [eof, soe]\n");
> printf("--skip nSkip the first n frames\n");
> printf("--sleep-forever Sleep forever after configuring
> the
> device\n"); printf("--stride valueLine stride in
> bytes\n");
> @@ -1269,6 +1272,7 @@ static void usage(const char *argv0)
> #define OPT_REQUEUE_LAST 262
> #define OPT_STRIDE 263
> #define OPT_FD 264
> +#define OPT_TSTAMP_SRC 265
>
> static struct option opts[] = {
> {"capture", 2, 0, 'c'},
> @@ -1298,7 +1302,8 @@ static struct option opts[] = {
> {"sleep-forever", 0, 0, OPT_SLEEP_FOREVER},
> {"stride", 1, 0, OPT_STRIDE},
> {"time-per-frame", 1, 0, 't'},
> - {"userptr", 0, 0, 'u'},
> + {"timestamp-source", 1, 0, OPT_TSTAMP_SRC},
> + {"userptr", 1, 0, 'u'},
This seems to be an unrelated change.
> {0, 0, 0, 0}
> };
>
> @@ -1487,6 +1492,17 @@ int main(int argc, char *argv[])
> case OPT_STRIDE:
> stride = atoi(optarg);
> break;
> + case OPT_TSTAMP_SRC:
> + if (!strcmp(optarg, "eof")) {
> + dev.buffer_output_flags |=
> V4L2_BUF_FLAG_TSTAMP_SRC_EOF;
As the buffer_output_flags isn't used for anything else, would it make sense
to just name it timestamp_source ?
> + } else if (!strcmp(optarg, "soe")) {
> + dev.buffer_output_flags |=
> V4L2_BUF_FLAG_TSTAMP_SRC_SOE;
> + } else {
> + printf("Invalid timestamp source %s\n", optarg);
> + return 1;
> + }
> + printf("Using %s timestamp source\n", optarg);
Do we really need this printf ?
> + break;
> case OPT_USERPTR_OFFSET:
> userptr_offset = atoi(optarg);
> break;
--
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: [yavta PATCH 5/9] Allow passing file descriptors to yavta
Hi Sakari,
Thank you for the patch.
On Saturday 01 March 2014 18:18:06 Sakari Ailus wrote:
> Signed-off-by: Sakari Ailus
> ---
> yavta.c | 63
> 1 file changed, 43 insertions(+), 20 deletions(-)
>
> diff --git a/yavta.c b/yavta.c
> index 870682e..a9b192a 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -62,6 +62,7 @@ struct buffer
> struct device
> {
> int fd;
> + int opened;
>
> enum v4l2_buf_type type;
> enum v4l2_memory memtype;
> @@ -180,13 +181,8 @@ static unsigned int v4l2_format_code(const char *name)
> return 0;
> }
>
> -static int video_open(struct device *dev, const char *devname, int
> no_query)
> +static int video_open(struct device *dev, const char *devname)
> {
> - dev->fd = -1;
> - dev->memtype = V4L2_MEMORY_MMAP;
> - dev->buffers = NULL;
> - dev->type = (enum v4l2_buf_type)-1;
> -
> dev->fd = open(devname, O_RDWR);
> if (dev->fd < 0) {
> printf("Error opening device %s: %s (%d).\n", devname,
> @@ -196,6 +192,16 @@ static int video_open(struct device *dev, const char
> *devname, int no_query)
>
> printf("Device %s opened.\n", devname);
>
> + dev->opened = 1;
> +
> + return 0;
> +}
> +
> +static int video_querycap(struct device *dev, int no_query) {
> + struct v4l2_capability cap;
> + unsigned int capabilities;
> + int ret;
> +
video_querycap ends up setting the dev->type field, which isn't really the job
of a query function. Would there be a clean way to pass the fd to the
video_open() function instead ? Maybe video_open() could be split and/or
renamed to video_init() ?
> if (no_query) {
> /* Assume capture device. */
> dev->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> @@ -215,9 +221,7 @@ static int video_open(struct device *dev, const char
> *devname, int no_query) else if (capabilities & V4L2_CAP_VIDEO_OUTPUT)
> dev->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> else {
> - printf("Error opening device %s: neither video capture "
> - "nor video output supported.\n", devname);
> - close(dev->fd);
> + printf("Device supports neither capture nor output.\n");
> return -EINVAL;
> }
>
> @@ -231,7 +235,8 @@ static void video_close(struct device *dev)
> {
> free(dev->pattern);
> free(dev->buffers);
> - close(dev->fd);
> + if (dev->opened)
> + close(dev->fd);
> }
>
> static unsigned int get_control_type(struct device *dev, unsigned int id)
> @@ -1246,6 +1251,7 @@ static void usage(const char *argv0)
> printf("-w, --set-control 'ctrl value' Set control 'ctrl' to
'value'\n");
> printf("--enum-formats Enumerate formats\n");
> printf("--enum-inputs Enumerate inputs\n");
> + printf("--fdUse a numeric file descriptor
> insted of a device\n");
> printf("--no-query Don't query capabilities on
> open\n");
> printf("--offsetUser pointer buffer offset from
> page
> start\n");
> printf("--requeue-last Requeue the last buffers before
> streamoff\n");
> @@ -1262,6 +1268,7 @@ static void usage(const char *argv0)
> #define OPT_USERPTR_OFFSET 261
> #define OPT_REQUEUE_LAST 262
> #define OPT_STRIDE 263
> +#define OPT_FD 264
>
> static struct option opts[] = {
> {"capture", 2, 0, 'c'},
> @@ -1269,6 +1276,7 @@ static struct option opts[] = {
> {"delay", 1, 0, 'd'},
> {"enum-formats", 0, 0, OPT_ENUM_FORMATS},
> {"enum-inputs", 0, 0, OPT_ENUM_INPUTS},
> + {"fd", 1, 0, OPT_FD},
> {"file", 2, 0, 'F'},
> {"fill-frames", 0, 0, 'I'},
> {"format", 1, 0, 'f'},
> @@ -1297,7 +1305,11 @@ static struct option opts[] = {
> int main(int argc, char *argv[])
> {
> struct sched_param sched;
> - struct device dev = { 0 };
> + struct device dev = {
> + .fd = -1,
> + .memtype = V4L2_MEMORY_MMAP,
> + .type = (enum v4l2_buf_type)-1,
> + };
> int ret;
>
> /* Options parsings */
> @@ -1452,6 +1464,14 @@ int main(int argc, char *argv[])
> case OPT_ENUM_INPUTS:
> do_enum_inputs = 1;
> break;
> + case OPT_FD:
> + dev.fd = atoi(optarg);
> + if (dev.fd < 0) {
> + printf("Bad file descriptor %d\n", dev.fd);
> + return 1;
> + }
> + printf("Using file descriptor %d\n", dev.fd);
> + break;
> case OPT_NO_QUERY:
> no_query = 1;
> break;
> @@ -1482,18 +1502,21 @@ int main(int argc, char *argv[])
> return 1;
> }
>
> -
Re: [yavta PATCH 3/9] Allow supporting mem2mem devices by adding forced OUTPUT device type
Hi Sakari,
Thank you for the patch.
On Saturday 01 March 2014 18:18:04 Sakari Ailus wrote:
> The option is --output, or -o.
Wouldn't it make sense to have an option to force the device type to a user-
specified value instead of just an option for the output type ? "-o" is also
usually used to select an output file, I'd like to keep it for that.
> Signed-off-by: Sakari Ailus
> ---
> yavta.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/yavta.c b/yavta.c
> index 8e43ce5..e010252 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -1240,6 +1240,7 @@ static void usage(const char *argv0)
> printf("-I, --fill-frames Fill frames with check pattern
> before
queuing
> them\n"); printf("-l, --list-controls List available controls\n");
> printf("-n, --nbufs n Set the number of video
> buffers\n");
> + printf("-o, --outputUse video node as output\n");
> printf("-p, --pause Pause before starting the video
stream\n");
> printf("-q, --quality n MJPEG quality (0-100)\n");
> printf("-r, --get-control ctrl Get control 'ctrl'\n");
> @@ -1282,6 +1283,7 @@ static struct option opts[] = {
> {"nbufs", 1, 0, 'n'},
> {"no-query", 0, 0, OPT_NO_QUERY},
> {"offset", 1, 0, OPT_USERPTR_OFFSET},
> + {"output", 0, 0, 'o'},
> {"pause", 0, 0, 'p'},
> {"quality", 1, 0, 'q'},
> {"get-control", 1, 0, 'r'},
> @@ -1304,7 +1306,7 @@ int main(int argc, char *argv[])
> int ret;
>
> /* Options parsings */
> - int do_file = 0, do_capture = 0, do_pause = 0;
> + int do_file = 0, do_capture = 0, do_pause = 0, do_output = 0;
> int do_set_time_per_frame = 0;
> int do_enum_formats = 0, do_set_format = 0;
> int do_enum_inputs = 0, do_set_input = 0;
> @@ -1385,6 +1387,9 @@ int main(int argc, char *argv[])
> if (nbufs > V4L_BUFFERS_MAX)
> nbufs = V4L_BUFFERS_MAX;
> break;
> + case 'o':
> + do_output = 1;
> + break;
> case 'p':
> do_pause = 1;
> break;
> @@ -1500,6 +1505,9 @@ int main(int argc, char *argv[])
> if (dev.type == (enum v4l2_buf_type)-1)
> no_query = 1;
>
> + if (do_output)
> + dev.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> +
> dev.memtype = memtype;
>
> if (do_get_control) {
--
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: Writing a HDMI-CEC device driver for the IT66121
Hi Hans, Thanks for the detailed response. As, much as I would love to have a robust, fully functioning implementation for v1, I think it might be a a bit of 'over-optimization' to write the complete spec into the driver from the beginning. The question I ask myself is, "how can we get it mainlined quickly?" I'm not sure of the answer but I would like implement and test basic features of HDMI-CEC and then add in the more advanced fun stuff ;) So I'm trying to test out CEC on the hardware I have. Making clean interfaces would allow for adaptable between 4l2 devices, drm/kms devices and hardware. My question is how can I connect to / test on the hardware I have? Best, Sri On Apr 1, 2014, at 2:29 AM, Hans Verkuil wrote: > Hi Sri, > > On 03/31/14 23:12, Sriakhil Gogineni wrote: >> Hi, >> >> I'm trying to write a HDMI-CEC driver for the Radxa Rock >> (Specification - Radxa). I am coming from a software background and >> have found libcec and am looking at other implementation. >> >> I'm wondering how to connect the hardware and software pieces under >> Linux / Android. >> >> I'm not sure if I need to find out what /dev/ its exposed under via >> the device tree or determine which register is used from the data >> sheet? >> >> Any advice / tips / pointers would be helpful. > > There is currently no kernel CEC support available. What makes cec > complex is 1) the CEC specification is horrible :-) and 2) a proper cec > implementation has to be able to take care of v4l2 devices, drm/kms devices > and usb dongles. In addition, at least some of the CEC handling has to > take place in the kernel in order to handle the audio return channel, > suspend commands, hotplug-over-CEC and such advanced features. > > I have been working on this, but it is a background project and I never > found the time to finish it. > > My latest code is available here: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cec > > but it needs more work to make this ready for prime time. > > It works, but it needs cleanup and cec_claim_log_addrs() needs improvement. > Particularly when called from a driver: this needs to be done in non- > blocking mode which isn't yet working (in blocking mode the driver would > block for an unacceptable amount of time). > > If you or someone else would be willing to take over, I would have no > objections. I have no idea when I might have time to continue work on > this. > > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] uvcvideo: Fix marking buffer erroneous in case of FID toggling
Hi Anton,
On Saturday 29 March 2014 09:28:02 Anton Leontiev wrote:
> 28.03.2014 20:12, Laurent Pinchart пишет:
> + * Set error flag for incomplete buffer.
> + */
> +static void uvc_buffer_check_bytesused(const struct uvc_streaming
> *const stream,
> >
> > No need for the second const keyword here.
> >
> > I would have used "uvc_video_" as a prefix, to be in sync with the
> > surrounding functions. What would you think of
> > uvc_video_validate_buffer() ?
> >
> +struct uvc_buffer *const buf)
> >
> > And no need for const at all here.
> >
> +{
> +if (buf->length != buf->bytesused &&
> +!(stream->cur_format->flags &
> UVC_FMT_FLAG_COMPRESSED))
> >
> > The indentation is wrong here, the ! on the second line should be aligned
> > to the first 'buf' of the first line.
> >
> > If you agree with these changes I can perform them while applying, there's
> > no need to resubmit the patch.
>
> Thank you for reviewing my first patch to Linux kernel.
Thank you for submitting it :-)
> I completely agree with your changes.
>
> Just want to ask why there is no need for the second 'const' after pointer
> character '*'? I thought it marks pointer itself as constant for type-
> checking opposite to first 'const', which marks memory it points to as
> constant for type-checking.
Your understanding is correct (as far as I know).
> I understand that the function is simple enough to verify it by hand but
> it's better to add more information for automatic checking.
>
> Is there any guidelines on 'const' keyword usage in Linux kernel code?
Marking the memory pointed to by the pointer as const ensures that the
function won't modify memory that the caller thought wouldn't be modified. It
thus serves as a contract between the caller and the callee, enforced by the
compiler.
Marking the pointer as const, on the other hand, only affects the function
implementation, without influencing its call contract. Its only use in this
case would be to prevent the function from modifying a pointer that the
function itself thought it shouldn't modify. While not useless in all cases,
this compile-time checked if usually not performed in the kernel, especially
for simple functions. I'm not aware of any explicit rule regarding const usage
though.
--
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 RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector
Hi Jean-François, Sorry for the late reply. On Thursday 27 March 2014 12:34:49 Jean-Francois Moine wrote: > On Wed, 26 Mar 2014 18:33:09 +0100 Laurent Pinchart wrote: > > That could work in your case, but I don't really like that. > > > > We need to describe the hardware topology, that might be the only point we > > all agree on. There are various hardware topologies we need to support > > with different levels of complexity, and several ways to describe them, > > also with a wide range of complexities and features. > > > > The more complex the hardware topology, the more complex its description > > needs to be, and the more complex the code that will parse the > > description and handle the hardware will be. I don't think there's any > > doubt here. > > But also, the simpler is the topology and the simpler should be its > description. I wouldn't put it so strongly. I believe we can slightly relax our requirements regarding DT bindings complexity as long as drivers remain simple. There's of course no reason to use more complex bindings just for the sake of it. > In your approach, the connections between endpoints are described in the > components themselves, which makes hard for the DT maintainers to have a > global understanding of the video subsystem. > > Having the topology described in the master device is clearer, even if it is > complex. First of all, let's clarify what a "master device" is. In the "simple-video- card" example you've proposed the master device is a logical device (with a DT node that has no corresponding hardware device). The second approach I can think of is to make the IP core that implements the CRTC (which I usually call display controller) be the master device. Let's note that the second case makes both the link and "global description" DT binding styles possible. My concern with the "global description" bindings style is that the approach only applies to simple hardware and can't be generalized. Now, I'm not too concerned about using that approach for simple hardware and a link-based approach for more complex hardware. The "slave" components, however, need to use a single DT bindings style, regardless of the DT bindings used by the master device. That's why I believe we should try to standardize one DT bindings style for master devices, even if it results in a slightly more complex DT description than strictly needed in some cases. > > A given device can be integrated in a wide variety of hardware with > > different complexities. A driver can't thus always assume that the whole > > composite display device will match a given class of topologies. This is > > especially true for encoders and connectors, they can be hooked up > > directly at the output of a very simple display controller, or can be > > part of a very complex graph. Encoder and connector drivers can't assume > > much about how they will be integrated. I want to avoid a situation where > > using an HDMI encoder already supported in mainline with a different SoC > > will result in having to rewrite the HDMI encoder driver. > > The tda998x chips are simple enough for being used in many boards: one video > input and one serial digital output. I don't see in which circumstance the > driver should be rewritten. It shouldn't, that's the whole point ;-) I wasn't talking about the tda998x only, but about encoder drivers in general. I have a display controller in a Renesas SoC that has two LVDS encoders that output LVDS signals out of the SoC. One LVDS port is connected to an LVDS panel (a connector from a DRM point of view), the second one to an LVDS receiver that outputs parallel RGB data to an HDMI encoder. The LVDS encoder can't thus assume any particular downstream topology and its driver thus can't create DRM encoder and connector instances. The same could be true for an HDMI encoder in theory, although an HDMI encoder connected on the same board directly to an HDMI decoder that outputs RGB data to a panel is probably a case that will be rarely seen in practice. In the general case an encoder driver can't assume any specific upstream or downstream topology. As long as DRM can't expose the real hardware topology to userspace, someone needs to decide on how to map the hardware topology to the DRM topology exposed to userspace. Encoder drivers can't take that role and thus shouldn't create DRM encoder and connector instances themselves. > > The story is a bit different for display controllers. While the hardware > > topology outside (and sometimes inside as well) of the SoC can vary, a > > display controller often approximately implies a given level of > > complexity. A cheap SoC with a simple display controller will likely not > > be used to drive a 4k display requiring 4 encoders running in parallel > > for instance. While I also want to avoid having to make significant > > changes to a display controller driver when using the SoC on a different > > board, I believe the requireme
Re: em2750 usb camera log as mentioned in dmesg
Am 28.03.2014 21:21, schrieb aaron.mo...@alsatis.net: > Hi, > > I have endless problems since upgarding to ubuntu12.04 with my usb > microscope and it's a big problem cos i need it for work. Which device are you talking about ? Which sensor does it use ? What does "endless problems" mean ? Which kernel are you using and what's the last working kernel version ? > > As suggested in dmesg I have sent you the log.. Interestingly the > em2750 camera is Ok on my desk pc with Xubuntu 12.04... go figure.. > But the desk pC is kinda hard to carry to customer sites. > > I hope to find a solution soon > > thanks > > Aaron > > [12699.292580] em28xx: New device @ 480 Mbps (eb1a:2750, interface > 0, class 0) > [12699.292585] em28xx: Video interface 0 found: isoc > [12699.292636] em28xx: chip ID is em2750 > [12699.476200] em2750 #0: board has no eeprom > [12699.547792] em2750 #0: No sensor detected As you can see, no sensor is found. Does this also happen with the working kernel ? Regards, Frank Schäfer > [12699.583014] em2750 #0: found i2c device @ 0xba on bus 0 [webcam > sensor or tvp5150a] > [12699.595736] em2750 #0: Your board has no unique USB ID and thus > need a hint to be detected. > [12699.595742] em2750 #0: You may try to use card= insmod option to > workaround that. > [12699.595746] em2750 #0: Please send an email with this log to: > [12699.595749] em2750 #0: V4L Mailing List > > [12699.595752] em2750 #0: Board eeprom hash is 0x > [12699.595756] em2750 #0: Board i2c devicelist hash is 0x1bdd0080 > [12699.595759] em2750 #0: Here is a list of valid choices for the > card= insmod option: > [12699.595764] em2750 #0: card=0 -> Unknown EM2800 video grabber > [12699.595768] em2750 #0: card=1 -> Unknown EM2750/28xx video grabber > [12699.595772] em2750 #0: card=2 -> Terratec Cinergy 250 USB > [12699.595776] em2750 #0: card=3 -> Pinnacle PCTV USB 2 > [12699.595779] em2750 #0: card=4 -> Hauppauge WinTV USB 2 > [12699.595783] em2750 #0: card=5 -> MSI VOX USB 2.0 > [12699.595786] em2750 #0: card=6 -> Terratec Cinergy 200 USB > [12699.595790] em2750 #0: card=7 -> Leadtek Winfast USB II > [12699.595793] em2750 #0: card=8 -> Kworld USB2800 > [12699.595798] em2750 #0: card=9 -> Pinnacle Dazzle DVC > 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 / > Plextor ConvertX PX-AV100U > [12699.595802] em2750 #0: card=10 -> Hauppauge WinTV HVR 900 > [12699.595805] em2750 #0: card=11 -> Terratec Hybrid XS > [12699.595809] em2750 #0: card=12 -> Kworld PVR TV 2800 RF > [12699.595812] em2750 #0: card=13 -> Terratec Prodigy XS > [12699.595816] em2750 #0: card=14 -> SIIG AVTuner-PVR / Pixelview > Prolink PlayTV USB 2.0 > [12699.595819] em2750 #0: card=15 -> V-Gear PocketTV > [12699.595823] em2750 #0: card=16 -> Hauppauge WinTV HVR 950 > [12699.595827] em2750 #0: card=17 -> Pinnacle PCTV HD Pro Stick > [12699.595830] em2750 #0: card=18 -> Hauppauge WinTV HVR 900 (R2) > [12699.595834] em2750 #0: card=19 -> EM2860/SAA711X Reference Design > [12699.595838] em2750 #0: card=20 -> AMD ATI TV Wonder HD 600 > [12699.595841] em2750 #0: card=21 -> eMPIA Technology, Inc. > GrabBeeX+ Video Encoder > [12699.595845] em2750 #0: card=22 -> EM2710/EM2750/EM2751 webcam > grabber > [12699.595849] em2750 #0: card=23 -> Huaqi DLCW-130 > [12699.595852] em2750 #0: card=24 -> D-Link DUB-T210 TV Tuner > [12699.595856] em2750 #0: card=25 -> Gadmei UTV310 > [12699.595859] em2750 #0: card=26 -> Hercules Smart TV USB 2.0 > [12699.595863] em2750 #0: card=27 -> Pinnacle PCTV USB 2 (Philips > FM1216ME) > [12699.595867] em2750 #0: card=28 -> Leadtek Winfast USB II Deluxe > [12699.595870] em2750 #0: card=29 -> EM2860/TVP5150 Reference Design > [12699.595874] em2750 #0: card=30 -> Videology 20K14XUSB USB2.0 > [12699.595877] em2750 #0: card=31 -> Usbgear VD204v9 > [12699.595881] em2750 #0: card=32 -> Supercomp USB 2.0 TV > [12699.595884] em2750 #0: card=33 -> Elgato Video Capture > [12699.595888] em2750 #0: card=34 -> Terratec Cinergy A Hybrid XS > [12699.595891] em2750 #0: card=35 -> Typhoon DVD Maker > [12699.595895] em2750 #0: card=36 -> NetGMBH Cam > [12699.595898] em2750 #0: card=37 -> Gadmei UTV330 > [12699.595902] em2750 #0: card=38 -> Yakumo MovieMixer > [12699.595906] em2750 #0: card=39 -> KWorld PVRTV 300U > [12699.595909] em2750 #0: card=40 -> Plextor ConvertX PX-TV100U > [12699.595913] em2750 #0: card=41 -> Kworld 350 U DVB-T > [12699.595916] em2750 #0: card=42 -> Kworld 355 U DVB-T > [12699.595920] em2750 #0: card=43 -> Terratec Cinergy T XS > [12699.595924] em2750 #0: card=44 -> Terratec Cinergy T XS (MT2060) > [12699.595927] em2750 #0: card=45 -> Pinnacle PCTV DVB-T > [12699.595931] em2750 #0: card=46 -> Compro, VideoMate U3 > [12699.595934] em2750 #0: card=47 -> KWorld DVB-T 305U > [12699.595938] em2750 #0: card=48 -> KWorld DV
Re: sparse: ioctl defines and "error: bad integer constant expression"
On 04/01/2014 06:48 PM, Christopher Li wrote: > On Mon, Mar 31, 2014 at 10:22 AM, Linus Torvalds > wrote: >> On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil wrote: >> >> Chris, can you please add this to the test cases since Hans did the >> work to create a nice small test-case? > > Sure, I want to add them to the test case. > > Hans, May I get a signed-off for your test cases? For all my test cases: Signed-off-by: Hans Verkuil 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: sparse: ioctl defines and "error: bad integer constant expression"
On Mon, Mar 31, 2014 at 10:22 AM, Linus Torvalds wrote: > On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil wrote: > > Chris, can you please add this to the test cases since Hans did the > work to create a nice small test-case? Sure, I want to add them to the test case. Hans, May I get a signed-off for your test cases? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] s5p-fimc: Changed RGB32 to BGR32
Le mardi 01 avril 2014 à 16:34 +0200, Sylwester Nawrocki a écrit : > It should be "BGRA, 32 bpp", I can fix it when applying, if > you won't send next version of this patch until then. Good catch, I'll let you fix when applying. thanks, Nicolas signature.asc Description: This is a digitally signed message part
Re: [patch] [media] dvb-core: check ->msg_len for diseqc_send_master_cmd()
Oops. I send this to Mauro's old email address. Sorry about that.
regards,
dan carpenter
On Tue, Apr 01, 2014 at 05:38:07PM +0300, Dan Carpenter wrote:
> I'd like to send this patch except that it "breaks"
> cx24116_send_diseqc_msg(). The cx24116 driver accepts ->msg_len values
> up to 24 but it looks like it's just copying 16 bytes past the end of
> the ->msg[] array so it's already broken.
>
> cmd->msg_len is an unsigned char. The comment next to the struct
> declaration says that valid values are are 3-6. Some of the drivers
> check that this is true, but most don't and it could cause memory
> corruption.
>
> Some examples of functions which don't check are:
> ttusbdecfe_dvbs_diseqc_send_master_cmd()
> cx24123_send_diseqc_msg()
> ds3000_send_diseqc_msg()
> etc.
>
> Signed-off-by: Dan Carpenter
> Reviewed-by: Antti Palosaari
> ---
> This is a static checker fix and I haven't tested it but the security
> implications are quite bad so we should fix this.
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c
> b/drivers/media/dvb-core/dvb_frontend.c
> index 57601c0..3d1eee6 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -2267,7 +2267,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
>
> case FE_DISEQC_SEND_MASTER_CMD:
> if (fe->ops.diseqc_send_master_cmd) {
> - err = fe->ops.diseqc_send_master_cmd(fe, (struct
> dvb_diseqc_master_cmd*) parg);
> + struct dvb_diseqc_master_cmd *cmd = parg;
> +
> + if (cmd->msg_len >= 3 && cmd->msg_len <= 6)
> + err = fe->ops.diseqc_send_master_cmd(fe, cmd);
> + else
> + err = -EINVAL;
> +
> fepriv->state = FESTATE_DISEQC;
> fepriv->status = 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] v4l2-compliance: fix function pointer prototype
Hi Hans,
On Tue, Apr 1, 2014 at 8:12 PM, Hans Verkuil wrote:
> On 04/01/14 16:26, Hans Verkuil wrote:
>>
>>
>> On 04/01/14 16:06, Prabhakar Lad wrote:
>>> Hi Hans,
>>>
>>> On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil wrote:
Hi Prabhakar,
On 04/01/14 15:45, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> There was a conflict between the mmap function pointer prototype of
> struct v4l_fd and the actual function used. Make sure it is in sync
> with the prototype of v4l2_mmap.
The prototype of v4l2_mmap uses int64_t, so I don't understand this
patch.
>>> Actual prototype of mmap is,
>>>
>>> void *mmap(void *addr, size_t length, int prot, int flags, int fd,
>>> off_t offset);
>>>
>>> But where as the prototype in v4l_fd mmap the last parameter type is int64_t
>>> but that should have been off_t and same applies with test_mmap().
>>
>> The problem is that v4l2_mmap (in lib/include/libv4l2.h) uses int64_t.
>> So the function pointer uses int64_t as well as does test_mmap.
>>
>> I don't see how the current v4l-utils tree can cause a compile error.
>>
>> For the record, I know you can't assign mmap to fd->mmap, you would
>> have to make a wrapper. Unfortunately mmap and v4l2_mmap do not have
>> the same prototype and I had to pick one (I'm not sure why they don't
>> use the same prototype).
>>
>> Most applications would typically have to use v4l2_mmap, so I went with
>> that one.
>>
>
> I missed that mmap is assigned to v4l_fd_init(). Since mmap and v4l2_mmap
> have different prototypes the only solution is to make a wrapper.
>
> Does this work?
>
Yes it compiles now with the below patch.
Thanks,
--Prabhakar Lad
> diff --git a/utils/v4l2-compliance/v4l-helpers.h
> b/utils/v4l2-compliance/v4l-helpers.h
> index 48ea602..e718a24 100644
> --- a/utils/v4l2-compliance/v4l-helpers.h
> +++ b/utils/v4l2-compliance/v4l-helpers.h
> @@ -14,11 +14,21 @@ struct v4l_fd {
> int (*munmap)(void *addr, size_t length);
> };
>
> +/*
> + * mmap has a different prototype compared to v4l2_mmap. Because of
> + * this we have to make a wrapper for it.
> + */
> +static inline void *v4l_fd_mmap(void *addr, size_t length, int prot, int
> flags,
> + int fd, int64_t offset)
> +{
> + return mmap(addr, length, prot, flags, fd, offset);
> +}
> +
> static inline void v4l_fd_init(struct v4l_fd *f, int fd)
> {
> f->fd = fd;
> f->ioctl = ioctl;
> - f->mmap = mmap;
> + f->mmap = v4l_fd_mmap;
> f->munmap = munmap;
> }
>
>
> On a 64-bit system the types are the same, it's only on a 32-bit system that
> this will fail.
>
> Regards,
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2-compliance: fix function pointer prototype
On 04/01/14 16:26, Hans Verkuil wrote:
>
>
> On 04/01/14 16:06, Prabhakar Lad wrote:
>> Hi Hans,
>>
>> On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil wrote:
>>> Hi Prabhakar,
>>>
>>> On 04/01/14 15:45, Lad, Prabhakar wrote:
From: "Lad, Prabhakar"
There was a conflict between the mmap function pointer prototype of
struct v4l_fd and the actual function used. Make sure it is in sync
with the prototype of v4l2_mmap.
>>>
>>> The prototype of v4l2_mmap uses int64_t, so I don't understand this
>>> patch.
>>>
>> Actual prototype of mmap is,
>>
>> void *mmap(void *addr, size_t length, int prot, int flags, int fd,
>> off_t offset);
>>
>> But where as the prototype in v4l_fd mmap the last parameter type is int64_t
>> but that should have been off_t and same applies with test_mmap().
>
> The problem is that v4l2_mmap (in lib/include/libv4l2.h) uses int64_t.
> So the function pointer uses int64_t as well as does test_mmap.
>
> I don't see how the current v4l-utils tree can cause a compile error.
>
> For the record, I know you can't assign mmap to fd->mmap, you would
> have to make a wrapper. Unfortunately mmap and v4l2_mmap do not have
> the same prototype and I had to pick one (I'm not sure why they don't
> use the same prototype).
>
> Most applications would typically have to use v4l2_mmap, so I went with
> that one.
>
I missed that mmap is assigned to v4l_fd_init(). Since mmap and v4l2_mmap
have different prototypes the only solution is to make a wrapper.
Does this work?
diff --git a/utils/v4l2-compliance/v4l-helpers.h
b/utils/v4l2-compliance/v4l-helpers.h
index 48ea602..e718a24 100644
--- a/utils/v4l2-compliance/v4l-helpers.h
+++ b/utils/v4l2-compliance/v4l-helpers.h
@@ -14,11 +14,21 @@ struct v4l_fd {
int (*munmap)(void *addr, size_t length);
};
+/*
+ * mmap has a different prototype compared to v4l2_mmap. Because of
+ * this we have to make a wrapper for it.
+ */
+static inline void *v4l_fd_mmap(void *addr, size_t length, int prot, int flags,
+ int fd, int64_t offset)
+{
+ return mmap(addr, length, prot, flags, fd, offset);
+}
+
static inline void v4l_fd_init(struct v4l_fd *f, int fd)
{
f->fd = fd;
f->ioctl = ioctl;
- f->mmap = mmap;
+ f->mmap = v4l_fd_mmap;
f->munmap = munmap;
}
On a 64-bit system the types are the same, it's only on a 32-bit system that
this will fail.
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] [media] dvb-core: check ->msg_len for diseqc_send_master_cmd()
I'd like to send this patch except that it "breaks"
cx24116_send_diseqc_msg(). The cx24116 driver accepts ->msg_len values
up to 24 but it looks like it's just copying 16 bytes past the end of
the ->msg[] array so it's already broken.
cmd->msg_len is an unsigned char. The comment next to the struct
declaration says that valid values are are 3-6. Some of the drivers
check that this is true, but most don't and it could cause memory
corruption.
Some examples of functions which don't check are:
ttusbdecfe_dvbs_diseqc_send_master_cmd()
cx24123_send_diseqc_msg()
ds3000_send_diseqc_msg()
etc.
Signed-off-by: Dan Carpenter
Reviewed-by: Antti Palosaari
---
This is a static checker fix and I haven't tested it but the security
implications are quite bad so we should fix this.
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 57601c0..3d1eee6 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2267,7 +2267,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
case FE_DISEQC_SEND_MASTER_CMD:
if (fe->ops.diseqc_send_master_cmd) {
- err = fe->ops.diseqc_send_master_cmd(fe, (struct
dvb_diseqc_master_cmd*) parg);
+ struct dvb_diseqc_master_cmd *cmd = parg;
+
+ if (cmd->msg_len >= 3 && cmd->msg_len <= 6)
+ err = fe->ops.diseqc_send_master_cmd(fe, cmd);
+ else
+ err = -EINVAL;
+
fepriv->state = FESTATE_DISEQC;
fepriv->status = 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 1/5] s5p-fimc: Changed RGB32 to BGR32
On 25/03/14 21:55, Nicolas Dufresne wrote:
> Testing showed that HW produces BGR32 rather then RGB32 as exposed
> in the driver. The documentation seems to state the pixels are stored
> in little endian order.
>
> Signed-off-by: Nicolas Dufresne
> ---
> drivers/media/platform/exynos4-is/fimc-core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
> b/drivers/media/platform/exynos4-is/fimc-core.c
> index da2fc86..bfb80fb 100644
> --- a/drivers/media/platform/exynos4-is/fimc-core.c
> +++ b/drivers/media/platform/exynos4-is/fimc-core.c
> @@ -56,8 +56,8 @@ static struct fimc_fmt fimc_formats[] = {
> .colplanes = 1,
> .flags = FMT_FLAGS_M2M,
> }, {
> - .name = "ARGB, 32 bpp",
> - .fourcc = V4L2_PIX_FMT_RGB32,
> + .name = "BGRB888, 32 bpp",
It should be "BGRA, 32 bpp", I can fix it when applying, if
you won't send next version of this patch until then.
> + .fourcc = V4L2_PIX_FMT_BGR32,
> .depth = { 32 },
> .color = FIMC_FMT_RGB888,
> .memplanes = 1,
--
Thanks!
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2-compliance: fix function pointer prototype
On 04/01/14 16:06, Prabhakar Lad wrote: > Hi Hans, > > On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil wrote: >> Hi Prabhakar, >> >> On 04/01/14 15:45, Lad, Prabhakar wrote: >>> From: "Lad, Prabhakar" >>> >>> There was a conflict between the mmap function pointer prototype of >>> struct v4l_fd and the actual function used. Make sure it is in sync >>> with the prototype of v4l2_mmap. >> >> The prototype of v4l2_mmap uses int64_t, so I don't understand this >> patch. >> > Actual prototype of mmap is, > > void *mmap(void *addr, size_t length, int prot, int flags, int fd, > off_t offset); > > But where as the prototype in v4l_fd mmap the last parameter type is int64_t > but that should have been off_t and same applies with test_mmap(). The problem is that v4l2_mmap (in lib/include/libv4l2.h) uses int64_t. So the function pointer uses int64_t as well as does test_mmap. I don't see how the current v4l-utils tree can cause a compile error. For the record, I know you can't assign mmap to fd->mmap, you would have to make a wrapper. Unfortunately mmap and v4l2_mmap do not have the same prototype and I had to pick one (I'm not sure why they don't use the same prototype). Most applications would typically have to use v4l2_mmap, so I went with that one. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix _IOC_TYPECHECK sparse error
On Tue, Apr 01, 2014 at 09:04:12AM +0200, Hans Verkuil wrote: > When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these > errors: > > drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant > expression > drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant > expression > drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant > expression > drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant > expression > > etc. > > The root cause of that turns out to be in include/asm-generic/ioctl.h: > > #include > > /* provoke compile error for invalid uses of size argument */ > extern unsigned int __invalid_size_argument_for_IOC; > #define _IOC_TYPECHECK(t) \ > ((sizeof(t) == sizeof(t[1]) && \ > sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ > sizeof(t) : __invalid_size_argument_for_IOC) > > If it is defined as this (as is already done if __KERNEL__ is not defined): > > #define _IOC_TYPECHECK(t) (sizeof(t)) > > then all is well with the world. > > This patch allows sparse to work correctly. > > Signed-off-by: Hans Verkuil Reviewed-by: Josh Triplett > diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h > index d17295b..297fb0d 100644 > --- a/include/asm-generic/ioctl.h > +++ b/include/asm-generic/ioctl.h > @@ -3,10 +3,15 @@ > > #include > > +#ifdef __CHECKER__ > +#define _IOC_TYPECHECK(t) (sizeof(t)) > +#else > /* provoke compile error for invalid uses of size argument */ > extern unsigned int __invalid_size_argument_for_IOC; > #define _IOC_TYPECHECK(t) \ > ((sizeof(t) == sizeof(t[1]) && \ > sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ > sizeof(t) : __invalid_size_argument_for_IOC) > +#endif > + > #endif /* _ASM_GENERIC_IOCTL_H */ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sparse" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] s5p-fimc: Misc fixes
Hi Nicolas, On 01/04/14 16:13, Nicolas Dufresne wrote: > Any comment/input ? My apologies for the delay. The patches look good to me, I'm going to apply them to my tree for 3.16, as the media tree is already closed for 3.15. Thanks a lot for these fixes! > Le mardi 25 mars 2014 à 16:45 -0400, Nicolas Dufresne a écrit : >> This patch series fixes several bugs found in the s5p-fimc driver. These >> bugs relate to bad parameters in the formats definition and short size >> of image buffers. >> >> Nicolas Dufresne (5): >> s5p-fimc: Reuse calculated sizes >> s5p-fimc: Iterate for each memory plane >> s5p-fimc: Align imagesize to row size for tiled formats >> s5p-fimc: Fix YUV422P depth >> s5p-fimc: Changed RGB32 to BGR32 >> >> drivers/media/platform/exynos4-is/fimc-core.c | 21 +++-- >> drivers/media/platform/exynos4-is/fimc-m2m.c | 6 +++--- >> 2 files changed, 18 insertions(+), 9 deletions(-) Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] s5p-fimc: Misc fixes
Any comment/input ? Le mardi 25 mars 2014 à 16:45 -0400, Nicolas Dufresne a écrit : > This patch series fixes several bugs found in the s5p-fimc driver. These > bugs relate to bad parameters in the formats definition and short size > of image buffers. > > Nicolas Dufresne (5): > s5p-fimc: Reuse calculated sizes > s5p-fimc: Iterate for each memory plane > s5p-fimc: Align imagesize to row size for tiled formats > s5p-fimc: Fix YUV422P depth > s5p-fimc: Changed RGB32 to BGR32 > > drivers/media/platform/exynos4-is/fimc-core.c | 21 +++-- > drivers/media/platform/exynos4-is/fimc-m2m.c | 6 +++--- > 2 files changed, 18 insertions(+), 9 deletions(-) > signature.asc Description: This is a digitally signed message part
Re: [PATCH] v4l2-compliance: fix function pointer prototype
Hi Hans, On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil wrote: > Hi Prabhakar, > > On 04/01/14 15:45, Lad, Prabhakar wrote: >> From: "Lad, Prabhakar" >> >> There was a conflict between the mmap function pointer prototype of >> struct v4l_fd and the actual function used. Make sure it is in sync >> with the prototype of v4l2_mmap. > > The prototype of v4l2_mmap uses int64_t, so I don't understand this > patch. > Actual prototype of mmap is, void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset); But where as the prototype in v4l_fd mmap the last parameter type is int64_t but that should have been off_t and same applies with test_mmap(). 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: [PATCH] [media] uvcvideo: Fix clock param realtime setting
Hi Olivier, On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote: > Hi Laurent, > > > > Yes. ffmpeg uses wall clock time to create timestamps for audio packets > > > from ALSA device. > > > > OK. I suppose I shouldn't drop support for the realtime clock like I > > wanted to then :-) > > > > > There is a bug in ffmpeg describing problems to synchronize audio and > > > the video from a v4l2 webcam. > > > > > > https://trac.ffmpeg.org/ticket/692 > > > > > > To workaround this issue, ffmpeg devs added a switch to convert back > > > > > > monotonic to realtime. From ffmpeg/libavdevice/v4l2.c: > > > -ts.D set type of timestamps for > > > grabbed frames (from 0 to 2) > > > (default 0) > > > default .D use timestamps from the kernel > > > abs .D use absolute timestamps (wall > > > clock) > > > mono2abs .D force conversion from monotonic > > > to absolute timestamps > > > > > > If the v4l2 driver is able to send realtime ts, it is easier synchronize > > > in userspace if all inputs use the same clock. > > > > That might be a stupid question, but shouldn't ALSA use the monotonic > > clock instead ? > > I think that I have that answer why ffmpeg use realtime clock for ALSA data. > In fact ffmpeg uses realtime clock for every data coming from capture > devices and the purpose is to be able to seek into the recorded stream by > using the date where the recording occured. Same principle than a camera > recording dates when pictures are taken. > > now a tougher question is whether or not it is up to the driver to provide > these realtime ts. It makes sense to associate a wall time with recorded streams for that purpose, but synchronization should in my opinion be performed using the monotonic clock, as the wall time can jump around. I believe drivers should provide monotonic timestamps only. However, given that the uvcvideo driver has the option of providing wall clock timestamps, that option should work, so your patch makes sense. I'd still like to remove support for the wall clock though, but I don't want to break userspace. ffmpeg should be fixed, especially given that most V4L devices provide monotonic timestamps only. -- 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] v4l2-compliance: fix function pointer prototype
Hi Prabhakar,
On 04/01/14 15:45, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> There was a conflict between the mmap function pointer prototype of
> struct v4l_fd and the actual function used. Make sure it is in sync
> with the prototype of v4l2_mmap.
The prototype of v4l2_mmap uses int64_t, so I don't understand this
patch.
Regards,
Hans
>
> This patch fixes following build error,
>
> v4l2-compliance.cpp: In function 'void v4l_fd_test_init(v4l_fd*, int)':
> v4l2-compliance.cpp:132: error: invalid conversion from
> 'void* (*)(void*, size_t, int, int, int, int64_t)' to
> 'void* (*)(void*, size_t, int, int, int, off_t)'
>
> Cc: Hans Verkuil
> Signed-off-by: Lad, Prabhakar
> ---
> utils/v4l2-compliance/v4l-helpers.h |2 +-
> utils/v4l2-compliance/v4l2-compliance.h |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/utils/v4l2-compliance/v4l-helpers.h
> b/utils/v4l2-compliance/v4l-helpers.h
> index 48ea602..b2ce6c0 100644
> --- a/utils/v4l2-compliance/v4l-helpers.h
> +++ b/utils/v4l2-compliance/v4l-helpers.h
> @@ -10,7 +10,7 @@ struct v4l_fd {
> int fd;
> int (*ioctl)(int fd, unsigned long cmd, ...);
> void *(*mmap)(void *addr, size_t length, int prot, int flags,
> - int fd, int64_t offset);
> + int fd, off_t offset);
> int (*munmap)(void *addr, size_t length);
> };
>
> diff --git a/utils/v4l2-compliance/v4l2-compliance.h
> b/utils/v4l2-compliance/v4l2-compliance.h
> index f2f7072..b6d4dae 100644
> --- a/utils/v4l2-compliance/v4l2-compliance.h
> +++ b/utils/v4l2-compliance/v4l2-compliance.h
> @@ -137,7 +137,7 @@ static inline int test_ioctl(int fd, unsigned long cmd,
> ...)
> }
>
> static inline void *test_mmap(void *start, size_t length, int prot, int
> flags,
> - int fd, int64_t offset)
> + int fd, off_t offset)
> {
> return wrapper ? v4l2_mmap(start, length, prot, flags, fd, offset) :
> mmap(start, length, prot, flags, fd, offset);
>
--
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 v3] saa7134: add vidioc_querystd
Signed-off-by: Mikhail Domrachev
---
drivers/media/pci/saa7134/saa7134-empress.c | 1 +
drivers/media/pci/saa7134/saa7134-reg.h | 5
drivers/media/pci/saa7134/saa7134-video.c | 41 +++--
drivers/media/pci/saa7134/saa7134.h | 1 +
4 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-empress.c
b/drivers/media/pci/saa7134/saa7134-empress.c
index 0a9047e..a150deb 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -262,6 +262,7 @@ static const struct v4l2_ioctl_ops ts_ioctl_ops = {
.vidioc_s_input = saa7134_s_input,
.vidioc_s_std = saa7134_s_std,
.vidioc_g_std = saa7134_g_std,
+ .vidioc_querystd= saa7134_querystd,
.vidioc_log_status = v4l2_ctrl_log_status,
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
diff --git a/drivers/media/pci/saa7134/saa7134-reg.h
b/drivers/media/pci/saa7134/saa7134-reg.h
index e7e0af1..51737b1 100644
--- a/drivers/media/pci/saa7134/saa7134-reg.h
+++ b/drivers/media/pci/saa7134/saa7134-reg.h
@@ -167,17 +167,22 @@
#define SAA7134_HSYNC_START 0x106
#define SAA7134_HSYNC_STOP 0x107
#define SAA7134_SYNC_CTRL 0x108
+#define SAA7134_SYNC_CTRL_AUFD(1 << 7)
#define SAA7134_LUMA_CTRL 0x109
+#define SAA7134_LUMA_CTRL_LDEL(1 << 5)
#define SAA7134_DEC_LUMA_BRIGHT 0x10a
#define SAA7134_DEC_LUMA_CONTRAST 0x10b
#define SAA7134_DEC_CHROMA_SATURATION 0x10c
#define SAA7134_DEC_CHROMA_HUE 0x10d
#define SAA7134_CHROMA_CTRL10x10e
+#define SAA7134_CHROMA_CTRL1_AUTO0(1 << 1)
+#define SAA7134_CHROMA_CTRL1_FCTC (1 << 2)
#define SAA7134_CHROMA_GAIN 0x10f
#define SAA7134_CHROMA_CTRL20x110
#define SAA7134_MODE_DELAY_CTRL 0x111
#define SAA7134_ANALOG_ADC 0x114
+#define SAA7134_ANALOG_ADC_AUTO1 (1 << 2)
#define SAA7134_VGATE_START 0x115
#define SAA7134_VGATE_STOP 0x116
#define SAA7134_MISC_VGATE_MSB 0x117
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index eb472b5..5eb61ca 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -452,19 +452,26 @@ static void video_mux(struct saa7134_dev *dev, int input)
static void saa7134_set_decoder(struct saa7134_dev *dev)
{
- int luma_control, sync_control, mux;
+ int luma_control, sync_control, chroma_ctrl1, mux;
struct saa7134_tvnorm *norm = dev->tvnorm;
mux = card_in(dev, dev->ctl_input).vmux;
luma_control = norm->luma_control;
sync_control = norm->sync_control;
+ chroma_ctrl1 = norm->chroma_ctrl1;
if (mux > 5)
luma_control |= 0x80; /* svideo */
if (noninterlaced || dev->nosignal)
sync_control |= 0x20;
+ /* switch on auto standard detection */
+ sync_control |= SAA7134_SYNC_CTRL_AUFD;
+ chroma_ctrl1 |= SAA7134_CHROMA_CTRL1_AUTO0;
+ chroma_ctrl1 &= ~SAA7134_CHROMA_CTRL1_FCTC;
+ luma_control &= ~SAA7134_LUMA_CTRL_LDEL;
+
/* setup video decoder */
saa_writeb(SAA7134_INCR_DELAY,0x08);
saa_writeb(SAA7134_ANALOG_IN_CTRL1, 0xc0 | mux);
@@ -487,7 +494,7 @@ static void saa7134_set_decoder(struct saa7134_dev *dev)
dev->ctl_invert ? -dev->ctl_saturation : dev->ctl_saturation);
saa_writeb(SAA7134_DEC_CHROMA_HUE,dev->ctl_hue);
- saa_writeb(SAA7134_CHROMA_CTRL1, norm->chroma_ctrl1);
+ saa_writeb(SAA7134_CHROMA_CTRL1, chroma_ctrl1);
saa_writeb(SAA7134_CHROMA_GAIN, norm->chroma_gain);
saa_writeb(SAA7134_CHROMA_CTRL2, norm->chroma_ctrl2);
@@ -1686,6 +1693,35 @@ int saa7134_g_std(struct file *file, void *priv,
v4l2_std_id *id)
}
EXPORT_SYMBOL_GPL(saa7134_g_std);
+static v4l2_std_id saa7134_read_std(struct saa7134_dev *dev)
+{
+ static v4l2_std_id stds[] = {
+ V4L2_STD_UNKNOWN,
+ V4L2_STD_NTSC,
+ V4L2_STD_PAL,
+ V4L2_STD_SECAM };
+
+ v4l2_std_id result = 0;
+
+ u8 st1 = saa_readb(SAA7134_STATUS_VIDEO1);
+ u8 st2 = saa_readb(SAA7134_STATUS_VIDEO2);
+
+ if (!(st2 & 0x1)) /* RDCAP == 0 */
+ result = V4L2_STD_UNKNOWN;
+ else
+ result = stds[st1 & 0x03];
+
+ return result;
+}
+
+int saa7134_querystd(struct file *file, void *priv, v4l2_std_id *std)
+{
+
[PATCH] v4l2-compliance: fix function pointer prototype
From: "Lad, Prabhakar"
There was a conflict between the mmap function pointer prototype of
struct v4l_fd and the actual function used. Make sure it is in sync
with the prototype of v4l2_mmap.
This patch fixes following build error,
v4l2-compliance.cpp: In function 'void v4l_fd_test_init(v4l_fd*, int)':
v4l2-compliance.cpp:132: error: invalid conversion from
'void* (*)(void*, size_t, int, int, int, int64_t)' to
'void* (*)(void*, size_t, int, int, int, off_t)'
Cc: Hans Verkuil
Signed-off-by: Lad, Prabhakar
---
utils/v4l2-compliance/v4l-helpers.h |2 +-
utils/v4l2-compliance/v4l2-compliance.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/utils/v4l2-compliance/v4l-helpers.h
b/utils/v4l2-compliance/v4l-helpers.h
index 48ea602..b2ce6c0 100644
--- a/utils/v4l2-compliance/v4l-helpers.h
+++ b/utils/v4l2-compliance/v4l-helpers.h
@@ -10,7 +10,7 @@ struct v4l_fd {
int fd;
int (*ioctl)(int fd, unsigned long cmd, ...);
void *(*mmap)(void *addr, size_t length, int prot, int flags,
- int fd, int64_t offset);
+ int fd, off_t offset);
int (*munmap)(void *addr, size_t length);
};
diff --git a/utils/v4l2-compliance/v4l2-compliance.h
b/utils/v4l2-compliance/v4l2-compliance.h
index f2f7072..b6d4dae 100644
--- a/utils/v4l2-compliance/v4l2-compliance.h
+++ b/utils/v4l2-compliance/v4l2-compliance.h
@@ -137,7 +137,7 @@ static inline int test_ioctl(int fd, unsigned long cmd, ...)
}
static inline void *test_mmap(void *start, size_t length, int prot, int flags,
- int fd, int64_t offset)
+ int fd, off_t offset)
{
return wrapper ? v4l2_mmap(start, length, prot, flags, fd, offset) :
mmap(start, length, prot, flags, fd, offset);
--
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: [RFCv3,3/3] soc_camera: initial of code
On 01/04/14 07:39, Josh Wu wrote:
Hi, Ben
On 3/31/2014 6:10 PM, Ben Dooks wrote:
On 31/03/14 10:28, Josh Wu wrote:
Hi, Ben
Thanks for the patch, I just test atmel-isi with the your patch,
I find the "mclk" registered in soc-camera driver cannot be find
by the soc-camera sensors. See comment in below:
Ok, I guess that the driver I have does not need the
mclk clock.
... ...
+#ifdef CONFIG_OF
+static int soc_of_bind(struct soc_camera_host *ici,
+ struct device_node *ep,
+ struct device_node *remote)
+{
+struct soc_camera_device *icd;
+struct soc_camera_desc sdesc = {.host_desc.bus_id = ici->nr,};
+struct soc_camera_async_client *sasc;
+struct soc_camera_async_subdev *sasd;
+struct v4l2_async_subdev **asd_array;
+char clk_name[V4L2_SUBDEV_NAME_SIZE];
+int ret;
+
+/* alloacte a new subdev and add match info to it */
+sasd = devm_kzalloc(ici->v4l2_dev.dev, sizeof(*sasd), GFP_KERNEL);
+if (!sasd)
+return -ENOMEM;
+
+asd_array = devm_kzalloc(ici->v4l2_dev.dev,
+ sizeof(struct v4l2_async_subdev **),
+ GFP_KERNEL);
+if (!asd_array)
+return -ENOMEM;
+
+sasd->asd.match.of.node = remote;
+sasd->asd.match_type = V4L2_ASYNC_MATCH_OF;
+asd_array[0] = &sasd->asd;
+
+/* Or shall this be managed by the soc-camera device? */
+sasc = devm_kzalloc(ici->v4l2_dev.dev, sizeof(*sasc), GFP_KERNEL);
+if (!sasc)
+return -ENOMEM;
+
+/* HACK: just need a != NULL */
+sdesc.host_desc.board_info = ERR_PTR(-ENODATA);
+
+ret = soc_camera_dyn_pdev(&sdesc, sasc);
+if (ret < 0)
+return ret;
+
+sasc->sensor = &sasd->asd;
+
+icd = soc_camera_add_pdev(sasc);
+if (!icd) {
+platform_device_put(sasc->pdev);
+return -ENOMEM;
+}
+
+//sasc->notifier.subdevs = asd;
+sasc->notifier.subdevs = asd_array;
+sasc->notifier.num_subdevs = 1;
+sasc->notifier.bound = soc_camera_async_bound;
+sasc->notifier.unbind = soc_camera_async_unbind;
+sasc->notifier.complete = soc_camera_async_complete;
+
+icd->sasc = sasc;
+icd->parent = ici->v4l2_dev.dev;
+
+snprintf(clk_name, sizeof(clk_name), "of-%s",
+ of_node_full_name(remote));
The clk_name you register here is a OF string, but for the i2c
sensors, which
call the v4l2_clk_get by using dev_name(&client->dev). It is format
like:
"1-0030", combined i2c adaptor ID and addr.
So the i2c sensor can not find this registered mclk as the name is
not match.
Hmm, this sounds like something that really should go
away and be handled by the clk system instead.
Since the v4l2 clk (mclk) is just a temperory solution and it will be
removed if all use common clk framework.
(See the commit message of ff5430de70).
So IMHO we can live with this, just simply add the code in soc_of_bind():
+ struct i2c_client *client;
... ...
client = of_find_i2c_device_by_node(remote);
+ if (!client)
+ goto eclkreg;
-snprintf(clk_name, sizeof(clk_name), "of-%s",
- of_node_full_name(remote));
+ snprintf(clk_name, sizeof(clk_name), "%d-%04x",
+client->adapter->nr, client->addr);
icd->clk = v4l2_clk_register(&soc_camera_clk_ops, clk_name,
"mclk", icd);
[snip]
Thanks, I will look into this.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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] vb2: Check if there are buffers before streamon
Hi,
It seems the patch has been applied twice in linux-next/master:
$ git log --oneline -25 linux-next/master
drivers/media/v4l2-core/videobuf2-core.c
9cf3c31 [media] vb2: call buf_finish after the state check
3f1a9a3 [media] vb2: fix streamoff handling if streamon wasn't called
e4d2581 [media] vb2: replace BUG by WARN_ON
fb64dca [media] vb2: properly clean up PREPARED and QUEUED buffers
b3379c6 [media] vb2: only call start_streaming if sufficient buffers are
queued
a7afcac [media] vb2: don't init the list if there are still buffers
6ea3b98 [media] vb2: rename queued_count to owned_by_drv_count
256f316 [media] vb2: fix buf_init/buf_cleanup call sequences
9c0863b [media] vb2: call buf_finish from __queue_cancel
0647064 [media] vb2: change result code of buf_finish to void
b5b4541 [media] vb2: add debugging code to check for unbalanced ops
952c9ee [media] vb2: fix PREPARE_BUF regression
4e5a4d8 [media] vb2: fix read/write regression
> 249f5a5 [media] vb2: Check if there are buffers before streamon
c897df0 Merge tag 'v3.14-rc5' into patchwork
7ce6fd8 [media] v4l: Handle buffer timestamp flags correctly
872484c [media] v4l: Add timestamp source flags, mask and document them
c57ff79 [media] v4l: Timestamp flags will soon contain timestamp source,
not just type
ade4868 [media] v4l: Rename vb2_queue.timestamp_type as timestamp_flags
f134328 [media] vb2: fix timecode and flags handling for output buffers
> 548df78 [media] vb2: Check if there are buffers before streamon
Regards
Andrzej
On 01/08/2014 09:01 AM, Ricardo Ribalda Delgado wrote:
> This patch adds a test preventing streamon() if there is no buffer
> ready.
>
> Without this patch, a user could call streamon() before
> preparing any buffer. This leads to a situation where if he calls
> close() before calling streamoff() the device is kept streaming.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> v2: Comment by Marek Szyprowski:
> Reword error message
>
> v3: Comment by Marek Szyprowski:
> Actualy do the reword :)
>
> drivers/media/v4l2-core/videobuf2-core.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 098df28..6409e0a 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1776,6 +1776,11 @@ static int vb2_internal_streamon(struct vb2_queue *q,
> enum v4l2_buf_type type)
> return 0;
> }
>
> + if (!q->num_buffers) {
> + dprintk(1, "streamon: no buffers have been allocated\n");
> + return -EINVAL;
> + }
> +
> /*
>* If any buffers were queued before streamon,
>* we can now pass them to driver for processing.
>
--
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: Writing a HDMI-CEC device driver for the IT66121
Hi Sri, On 03/31/14 23:12, Sriakhil Gogineni wrote: > Hi, > > I'm trying to write a HDMI-CEC driver for the Radxa Rock > (Specification - Radxa). I am coming from a software background and > have found libcec and am looking at other implementation. > > I'm wondering how to connect the hardware and software pieces under > Linux / Android. > > I'm not sure if I need to find out what /dev/ its exposed under via > the device tree or determine which register is used from the data > sheet? > > Any advice / tips / pointers would be helpful. There is currently no kernel CEC support available. What makes cec complex is 1) the CEC specification is horrible :-) and 2) a proper cec implementation has to be able to take care of v4l2 devices, drm/kms devices and usb dongles. In addition, at least some of the CEC handling has to take place in the kernel in order to handle the audio return channel, suspend commands, hotplug-over-CEC and such advanced features. I have been working on this, but it is a background project and I never found the time to finish it. My latest code is available here: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cec but it needs more work to make this ready for prime time. It works, but it needs cleanup and cec_claim_log_addrs() needs improvement. Particularly when called from a driver: this needs to be done in non- blocking mode which isn't yet working (in blocking mode the driver would block for an unacceptable amount of time). If you or someone else would be willing to take over, I would have no objections. I have no idea when I might have time to continue work on this. 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] Fix _IOC_TYPECHECK sparse error
When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these errors: drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant expression drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant expression etc. The root cause of that turns out to be in include/asm-generic/ioctl.h: #include /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) If it is defined as this (as is already done if __KERNEL__ is not defined): #define _IOC_TYPECHECK(t) (sizeof(t)) then all is well with the world. This patch allows sparse to work correctly. Signed-off-by: Hans Verkuil diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h index d17295b..297fb0d 100644 --- a/include/asm-generic/ioctl.h +++ b/include/asm-generic/ioctl.h @@ -3,10 +3,15 @@ #include +#ifdef __CHECKER__ +#define _IOC_TYPECHECK(t) (sizeof(t)) +#else /* provoke compile error for invalid uses of size argument */ extern unsigned int __invalid_size_argument_for_IOC; #define _IOC_TYPECHECK(t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC) +#endif + #endif /* _ASM_GENERIC_IOCTL_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
