Re: [PATCH] media: initial driver for ov5642 CMOS sensor
Hi Angela On Tue, 5 Jul 2011, Angela Wan wrote: > Hi, Guennadi > The solution you said is right. We could use parameters to > distinguish different power managerment, gain, etc. > So ov5642_default_regs_init and ov5642_default_regs_finalise in the > patch could be removed in the final version, right? > Since it's not common for all boards. What I think about is that > ov5642.c is a common driver, which could use on almost > all platforms. But the setting could be different from different > boards from my experience on three boards. And the setting > contains lots of registers. OV5642 document should be learnt a lot > before merging the patch. Sorry, this all doesn't tell me much. I have to see your code, your patches for your boards. When we see them, then we can think how to abstract those differences. Until then I don't think, that just claiming, that the driver is not generic enough in its present, is a reason enough to not merge it. Thanks Guennadi > Thank you > Angela > > > On Mon, Jul 4, 2011 at 3:35 AM, Guennadi Liakhovetski > wrote: > > Hi Angela > > > > On Sun, 3 Jul 2011, angela wan wrote: > > > >> Hi, Bastian, > >> > >> Could the setting in ov5642.c like ov5642_default_regs_init and > >> ov5642_default_regs_finalise adapt to different board? From my experience, > >> ov5642 may have difference settings for differnt boards. So could we put > >> the > >> setting in another file instead of in the common driver? > > > > No, that's not the solution, that we want. What we want is find the > > differences, understand them and learn to calculate them. So, for example, > > if you need different power management procedures, or if you feed the > > sensor with a different frequency clock, or if you use different lenses > > and your WB or gain or any other parameters differ then, we might have to > > use or add some platform parameters and verify them in the driver. > > > > Thanks > > Guennadi > > > >> Best Regards, > >> Angela Wan > >> > >> Application Processor Systems Engineering, > >> Marvell Technology Group Ltd. > >> > >> > >> On Tue, Jun 28, 2011 at 5:48 AM, Bastian Hecht > >> wrote: > >> > >> > 2011/6/27 Laurent Pinchart : > >> > > Hi Bastian, > >> > > > >> > > Thanks for the patch. > >> > > > >> > > On Friday 24 June 2011 12:57:36 Bastian Hecht wrote: > >> > >> This is an initial driver release for the Omnivision 5642 CMOS sensor. > >> > >> > >> > >> Signed-off-by: Bastian Hecht > >> > >> --- > >> > >> > >> > >> diff --git a/drivers/media/video/ov5642.c > >> > >> b/drivers/media/video/ov5642.c > >> > >> new file mode 100644 > >> > >> index 000..3cdae97 > >> > >> --- /dev/null > >> > >> +++ b/drivers/media/video/ov5642.c > >> > >> @@ -0,0 +1,1011 @@ > >> > >> +/* > >> > >> + * Driver for OV5642 CMOS Image Sensor from Omnivision > >> > >> + * > >> > >> + * Copyright (C) 2011, Bastian Hecht > >> > >> + * > >> > >> + * Based on Sony IMX074 Camera Driver > >> > >> + * Copyright (C) 2010, Guennadi Liakhovetski > >> > >> + * > >> > >> + * Based on Omnivision OV7670 Camera Driver > >> > >> + * Copyright (C) 2006-7 Jonathan Corbet > >> > >> + * > >> > >> + * This program is free software; you can redistribute it and/or > >> > >> modify > >> > >> + * it under the terms of the GNU General Public License version 2 as > >> > >> + * published by the Free Software Foundation. > >> > >> + */ > >> > >> + > >> > >> +#include > >> > >> +#include > >> > >> +#include > >> > >> +#include > >> > >> + > >> > >> +#include > >> > >> +#include > >> > >> +#include > >> > >> +#include > >> > >> + > >> > >> +/* OV5642 registers */ > >> > >> +#define REG_CHIP_ID_HIGH 0x300a > >> > >> +#define REG_CHIP_ID_LOW 0x300b > >> > >> + > >> > >> +#define REG_WINDOW_START_X_HIGH 0x3800 > >> > >> +#define REG_WINDOW_START_X_LOW 0x3801 > >> > >> +#define REG_WINDOW_START_Y_HIGH 0x3802 > >> > >> +#define REG_WINDOW_START_Y_LOW 0x3803 > >> > >> +#define REG_WINDOW_WIDTH_HIGH 0x3804 > >> > >> +#define REG_WINDOW_WIDTH_LOW 0x3805 > >> > >> +#define REG_WINDOW_HEIGHT_HIGH 0x3806 > >> > >> +#define REG_WINDOW_HEIGHT_LOW 0x3807 > >> > >> +#define REG_OUT_WIDTH_HIGH 0x3808 > >> > >> +#define REG_OUT_WIDTH_LOW 0x3809 > >> > >> +#define REG_OUT_HEIGHT_HIGH 0x380a > >> > >> +#define REG_OUT_HEIGHT_LOW 0x380b > >> > >> +#define REG_OUT_TOTAL_WIDTH_HIGH 0x380c > >> > >> +#define REG_OUT_TOTAL_WIDTH_LOW 0x380d > >> > >> +#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e > >> > >> +#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f > >> > >> + > >> > >> +/* > >> > >> + * define standard resolution. > >> > >> + * Works currently only for up to 720 lines > >> > >> + * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720 > >> > >> + */ > >> > >> + > >> > >> +#define OV5642_WIDTH 1280 > >> > >> +#define OV5642_HEIGHT 720 >
DVB-T USB Devices to be added
Hi there and sorry for the email, it seems I am too dumb to edit the wiki and I am at work right now and there is few time to figure it out. Device to be added: Terratec T Stick Dual RC USB DVB-T Device Product Page: http://www.terratec.net/de/produkte/Cinergy_T_Stick_Dual_RC_102260.html This one os similar to the TerraTec Cinergy T USB RC (mk II), but has a different USB ID and a different Tuner: Terratec T Stick Dual RC 0ccd:0099 USB2.0 Afatech AF9015A + mxl5007t (Tuner) Firmware: dvb-usb-af9015.fw On Ubuntu 11.04 64bit, Kernel 2.6.38 working out of the box. dmesg: [ 380.391622] usb 1-1.6: new high speed USB device using ehci_hcd and address 7 [ 380.879599] dvb-usb: found a 'TerraTec Cinergy T Stick Dual RC' in cold state, will try to load a firmware [ 380.881645] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [ 380.936424] dvb-usb: found a 'TerraTec Cinergy T Stick Dual RC' in warm state. [ 380.936470] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 380.936844] DVB: registering new adapter (TerraTec Cinergy T Stick Dual RC) [ 380.943911] af9013: firmware version:4.65.0.0 [ 380.946910] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [ 380.949569] mxl5007t 8-00c0: creating new instance [ 380.951657] mxl5007t_get_chip_id: unknown rev (3f) [ 380.951660] mxl5007t_get_chip_id: MxL5007T detected @ 8-00c0 [ 380.952278] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 380.952675] DVB: registering new adapter (TerraTec Cinergy T Stick Dual RC) [ 381.611221] af9013: found a 'Afatech AF9013 DVB-T' in warm state. [ 381.614687] af9013: firmware version:4.65.0.0 [ 381.626018] DVB: registering adapter 1 frontend 0 (Afatech AF9013 DVB-T)... [ 381.626177] mxl5007t 9-00c0: creating new instance [ 381.628663] mxl5007t_get_chip_id: unknown rev (3f) [ 381.628667] mxl5007t_get_chip_id: MxL5007T detected @ 9-00c0 [ 381.660243] Registered IR keymap rc-terratec-slim [ 381.660339] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/rc/rc0/input13 [ 381.660402] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/rc/rc0 [ 381.660405] dvb-usb: schedule remote query interval to 500 msecs. [ 381.660409] dvb-usb: TerraTec Cinergy T Stick Dual RC successfully initialized and connected. [ 381.672566] input: Afatech DVB-T 2 as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.1/input/input14 [ 381.672686] generic-usb 0003:0CCD:0099.000A: input,hidraw8: USB HID v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:1a.0-1.6/input1 Nice Feature: It has 2 Tuners Best Regards Bernhard Günther -- -- Bernhard Guenther GnuPG-Key-ID: 1024D/1CD92189 Jabber(im): ti...@jabber.fsinf.de Tel: +493065075259 , Cell: +491704931668, Fax: +493065076049 -- signature.asc Description: Digital signature
[PATCH] v4l: remove single to multiplane conversion
This patch removes an implicit conversion between multi and single plane
formats from V4L2 framework. The conversion is to be performed by libv4l2.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ioctl.c | 250 ++
1 files changed, 12 insertions(+), 238 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 213ba7d..07f2abd 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -476,63 +476,6 @@ static int check_fmt(const struct v4l2_ioctl_ops *ops,
enum v4l2_buf_type type)
return -EINVAL;
}
-/**
- * fmt_sp_to_mp() - Convert a single-plane format to its multi-planar 1-plane
- * equivalent
- */
-static int fmt_sp_to_mp(const struct v4l2_format *f_sp,
- struct v4l2_format *f_mp)
-{
- struct v4l2_pix_format_mplane *pix_mp = &f_mp->fmt.pix_mp;
- const struct v4l2_pix_format *pix = &f_sp->fmt.pix;
-
- if (f_sp->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
- f_mp->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
- else if (f_sp->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
- f_mp->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
- else
- return -EINVAL;
-
- pix_mp->width = pix->width;
- pix_mp->height = pix->height;
- pix_mp->pixelformat = pix->pixelformat;
- pix_mp->field = pix->field;
- pix_mp->colorspace = pix->colorspace;
- pix_mp->num_planes = 1;
- pix_mp->plane_fmt[0].sizeimage = pix->sizeimage;
- pix_mp->plane_fmt[0].bytesperline = pix->bytesperline;
-
- return 0;
-}
-
-/**
- * fmt_mp_to_sp() - Convert a multi-planar 1-plane format to its single-planar
- * equivalent
- */
-static int fmt_mp_to_sp(const struct v4l2_format *f_mp,
- struct v4l2_format *f_sp)
-{
- const struct v4l2_pix_format_mplane *pix_mp = &f_mp->fmt.pix_mp;
- struct v4l2_pix_format *pix = &f_sp->fmt.pix;
-
- if (f_mp->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
- f_sp->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
- else if (f_mp->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
- f_sp->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
- else
- return -EINVAL;
-
- pix->width = pix_mp->width;
- pix->height = pix_mp->height;
- pix->pixelformat = pix_mp->pixelformat;
- pix->field = pix_mp->field;
- pix->colorspace = pix_mp->colorspace;
- pix->sizeimage = pix_mp->plane_fmt[0].sizeimage;
- pix->bytesperline = pix_mp->plane_fmt[0].bytesperline;
-
- return 0;
-}
-
static long __video_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
@@ -540,7 +483,6 @@ static long __video_do_ioctl(struct file *file,
const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
void *fh = file->private_data;
struct v4l2_fh *vfh = NULL;
- struct v4l2_format f_copy;
int use_fh_prio = 0;
long ret = -EINVAL;
@@ -702,42 +644,15 @@ static long __video_do_ioctl(struct file *file,
switch (f->type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
- if (ops->vidioc_g_fmt_vid_cap) {
+ if (ops->vidioc_g_fmt_vid_cap)
ret = ops->vidioc_g_fmt_vid_cap(file, fh, f);
- } else if (ops->vidioc_g_fmt_vid_cap_mplane) {
- if (fmt_sp_to_mp(f, &f_copy))
- break;
- ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh,
- &f_copy);
- if (ret)
- break;
-
- /* Driver is currently in multi-planar format,
-* we can't return it in single-planar API*/
- if (f_copy.fmt.pix_mp.num_planes > 1) {
- ret = -EBUSY;
- break;
- }
-
- ret = fmt_mp_to_sp(&f_copy, f);
- }
if (!ret)
v4l_print_pix_fmt(vfd, &f->fmt.pix);
break;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
- if (ops->vidioc_g_fmt_vid_cap_mplane) {
+ if (ops->vidioc_g_fmt_vid_cap_mplane)
ret = ops->vidioc_g_fmt_vid_cap_mplane(file,
fh, f);
- } else if (ops->vidioc_g_fmt_vid_cap) {
- if (fmt_mp_to_sp(f, &f_copy))
- break;
- ret = ops->vidioc_g_fmt
[PATCH 1/2] libv4l2: add implicit conversion from single- to multi-plane api
This patch add implicit conversion of single plane variant of ioctl to
multiplane variant. The conversion is performed only in case if a driver
implements only mplane api. The conversion is done by substituting SYS_IOCTL
with a wrapper that converts single plane call to their mplane analogs.
Function v4l2_fd_open was revised to work correctly with the wrapper.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
lib/libv4l2/libv4l2.c | 227
lib/libv4lconvert/libv4lsyscall-priv.h |5 +-
2 files changed, 205 insertions(+), 27 deletions(-)
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index 4de382e..6af9f8c 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -57,6 +57,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -79,6 +80,7 @@
#define V4L2_STREAM_TOUCHED0x2000
#define V4L2_USE_READ_FOR_READ 0x4000
#define V4L2_SUPPORTS_TIMEPERFRAME 0x8000
+#define V4L2_CONVERT2MPLANE0x0001
#define V4L2_MMAP_OFFSET_MAGIC 0xABCDEF00u
@@ -93,6 +95,165 @@ static struct v4l2_dev_info devices[V4L2_MAX_DEVICES] = {
};
static int devices_used;
+static int v4l2_get_index(int fd);
+
+#define SYS_DO_IOCTL(fd, cmd, arg) \
+ syscall(SYS_ioctl, (int)(fd), (unsigned long)(cmd), (void *)(arg))
+
+int v4l2_ioctl_mp(int fd, unsigned long cmd, void *arg)
+{
+ int ret;
+ int index = v4l2_get_index(fd);
+
+ /* skipping if no mplane convertion is needed */
+ if (index == -1 || !(devices[index].flags & V4L2_CONVERT2MPLANE))
+ return SYS_DO_IOCTL(fd, cmd, arg);
+
+ switch (cmd) {
+ case VIDIOC_QUERYCAP: {
+ struct v4l2_capability *cap = arg;
+ ret = SYS_DO_IOCTL(fd, cmd, cap);
+ if (ret)
+ return ret;
+ if (cap->capabilities & V4L2_CAP_VIDEO_CAPTURE_MPLANE)
+ cap->capabilities |= V4L2_CAP_VIDEO_CAPTURE;
+ return 0;
+ }
+ case VIDIOC_TRY_FMT:
+ case VIDIOC_S_FMT: {
+ /* convert single planar structs to mplane structs */
+ struct v4l2_format fmt = {0};
+ struct v4l2_format *old = arg;
+
+ fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+ fmt.fmt.pix_mp.width = old->fmt.pix.width;
+ fmt.fmt.pix_mp.height = old->fmt.pix.height;
+ fmt.fmt.pix_mp.pixelformat = old->fmt.pix.pixelformat;
+ fmt.fmt.pix_mp.field = old->fmt.pix.field;
+ fmt.fmt.pix_mp.colorspace = old->fmt.pix.colorspace;
+ fmt.fmt.pix_mp.num_planes = 1;
+ fmt.fmt.pix_mp.plane_fmt[0].bytesperline =
old->fmt.pix.bytesperline;
+ fmt.fmt.pix_mp.plane_fmt[0].sizeimage = old->fmt.pix.sizeimage;
+
+ ret = SYS_DO_IOCTL(fd, cmd, &fmt);
+ if (ret)
+ return ret;
+
+ old->fmt.pix.width = fmt.fmt.pix_mp.width;
+ old->fmt.pix.height = fmt.fmt.pix_mp.height;
+ old->fmt.pix.pixelformat = fmt.fmt.pix_mp.pixelformat;
+ old->fmt.pix.field = fmt.fmt.pix_mp.field;
+ old->fmt.pix.colorspace = fmt.fmt.pix_mp.colorspace;
+ old->fmt.pix.bytesperline =
fmt.fmt.pix_mp.plane_fmt[0].bytesperline;
+ old->fmt.pix.sizeimage = fmt.fmt.pix_mp.plane_fmt[0].sizeimage;
+
+ return 0;
+ }
+ case VIDIOC_G_FMT: {
+ struct v4l2_format fmt = { 0 };
+ struct v4l2_format *old = arg;
+
+ fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+ ret = SYS_DO_IOCTL(fd, cmd, &fmt);
+ if (ret)
+ return ret;
+ /* cannot return multiplane format to singleplane app */
+ if (fmt.fmt.pix_mp.num_planes > 1) {
+ errno = -EBUSY;
+ return -1;
+ }
+ old->fmt.pix.width = fmt.fmt.pix_mp.width;
+ old->fmt.pix.height = fmt.fmt.pix_mp.height;
+ old->fmt.pix.pixelformat = fmt.fmt.pix_mp.pixelformat;
+ old->fmt.pix.field = fmt.fmt.pix_mp.field;
+ old->fmt.pix.colorspace = fmt.fmt.pix_mp.colorspace;
+ old->fmt.pix.bytesperline =
fmt.fmt.pix_mp.plane_fmt[0].bytesperline;
+ old->fmt.pix.sizeimage = fmt.fmt.pix_mp.plane_fmt[0].sizeimage;
+
+ return 0;
+ }
+ case VIDIOC_ENUM_FMT: {
+ struct v4l2_fmtdesc *fmtdesc = arg;
+
+ fmtdesc->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+ ret = SYS_DO_IOCTL(fd, cmd, fmtdesc);
+ fmtdesc->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+
+ return ret;
+ }
+ case VIDIOC_S_PARM:
+ case VIDIOC_G_PARM: {
+ struct v4l2_streamparm *parm = arg;
+
+
[PATCH 2/2] v4l2-ctl: fix wrapped open/close
When running in libv4l2 warp mode, the application did not use
v4l2_open and v4l2_close in some cases. This patch fixes this
issue substituting open/close calls with test_open/test_close
which are libv4l2-aware.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
utils/v4l2-ctl/v4l2-ctl.cpp |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp
index 227ce1a..02f97e4 100644
--- a/utils/v4l2-ctl/v4l2-ctl.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl.cpp
@@ -1604,13 +1604,13 @@ static void list_devices()
for (dev_vec::iterator iter = files.begin();
iter != files.end(); ++iter) {
- int fd = open(iter->c_str(), O_RDWR);
+ int fd = test_open(iter->c_str(), O_RDWR);
std::string bus_info;
if (fd < 0)
continue;
doioctl(fd, VIDIOC_QUERYCAP, &vcap);
- close(fd);
+ test_close(fd);
bus_info = (const char *)vcap.bus_info;
if (cards[bus_info].empty())
cards[bus_info] += std::string((char *)vcap.card) + "
(" + bus_info + "):\n";
@@ -2535,7 +2535,7 @@ int main(int argc, char **argv)
return 1;
}
- if ((fd = open(device, O_RDWR)) < 0) {
+ if ((fd = test_open(device, O_RDWR)) < 0) {
fprintf(stderr, "Failed to open %s: %s\n", device,
strerror(errno));
exit(1);
@@ -3693,6 +3693,6 @@ int main(int argc, char **argv)
perror("VIDIOC_QUERYCAP");
}
- close(fd);
+ test_close(fd);
exit(app_result);
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] v4l2-ctl: fix wrapped open/close
> When running in libv4l2 warp mode, the application did not use
> v4l2_open and v4l2_close in some cases. This patch fixes this
> issue substituting open/close calls with test_open/test_close
> which are libv4l2-aware.
This is already fixed in the latest version. I found the same
bug recently.
Regards,
Hans
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> utils/v4l2-ctl/v4l2-ctl.cpp |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp
> index 227ce1a..02f97e4 100644
> --- a/utils/v4l2-ctl/v4l2-ctl.cpp
> +++ b/utils/v4l2-ctl/v4l2-ctl.cpp
> @@ -1604,13 +1604,13 @@ static void list_devices()
>
> for (dev_vec::iterator iter = files.begin();
> iter != files.end(); ++iter) {
> - int fd = open(iter->c_str(), O_RDWR);
> + int fd = test_open(iter->c_str(), O_RDWR);
> std::string bus_info;
>
> if (fd < 0)
> continue;
> doioctl(fd, VIDIOC_QUERYCAP, &vcap);
> - close(fd);
> + test_close(fd);
> bus_info = (const char *)vcap.bus_info;
> if (cards[bus_info].empty())
> cards[bus_info] += std::string((char *)vcap.card) + "
> (" + bus_info +
> "):\n";
> @@ -2535,7 +2535,7 @@ int main(int argc, char **argv)
> return 1;
> }
>
> - if ((fd = open(device, O_RDWR)) < 0) {
> + if ((fd = test_open(device, O_RDWR)) < 0) {
> fprintf(stderr, "Failed to open %s: %s\n", device,
> strerror(errno));
> exit(1);
> @@ -3693,6 +3693,6 @@ int main(int argc, char **argv)
> perror("VIDIOC_QUERYCAP");
> }
>
> - close(fd);
> + test_close(fd);
> exit(app_result);
> }
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] davinci: dm646x: move vpif related code to driver core header from platform
Hi Mauro, On Wed, Jun 22, 2011 at 09:35:58, Nori, Sekhar wrote: > On Thu, Jun 02, 2011 at 22:51:58, Nori, Sekhar wrote: > > Hi Mauro, > > > > On Fri, May 20, 2011 at 19:28:49, Hadli, Manjunath wrote: > > > move vpif related code for capture and display drivers > > > from dm646x platform header file to vpif.h as these definitions > > > are related to driver code more than the platform or board. > > > > > > Signed-off-by: Manjunath Hadli > > > > Will you be taking this patch through your tree? > > > > If not, with your ack, I can queue it for inclusion > > through the ARM tree. > > > > Ping :) Can you please provide your ack so that I can queue this for v3.1? Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 05-07-2011 10:20, Hans Verkuil escreveu:
>> I failed to see what information is provided by the "presets" name. If this
>> were removed
>> from the ioctl, and fps would be added instead, the API would be clearer.
>> The only
>> adjustment would be to use "index" as the preset selection key. Anyway, it
>> is too late
>> for such change. We need to live with that.
>
> Adding the fps solves nothing. Because that still does not give you specific
> timings.
> You can have 1920x1080P60 that has quite different timings from the CEA-861
> standard
> and that may not be supported by a TV.
>
> If you are working with HDMI, then you may want to filter all supported
> presets to
> those of the CEA standard.
>
> That's one thing that is missing at the moment: that presets belonging to a
> certain
> standard get their own range. Since we only do CEA861 right now it hasn't
> been an
> issue, but it will.
I prepared a long email about that, but then I realized that we're investing
our time into
something broken, at the light of all DV timing standards. So, I've dropped it
and
started from scratch.
>From what I've got, there are some hardware that can only do a limited set of
>DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where hardware only
support
a limited set of frequencies, that may or may not be inside the CEA standard.
Let's assume we never added the current API, and discuss how it would properly
fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE1<<31
#define DV_PRESET_SPEC(flag)(flag && 0xff)
#define DV_PRESET_IS_CEA861 1
#define DV_PRESET_IS_DMT2
#define DV_PRESET_IS_CVF3
#define DV_PRESET_IS_GTF4
#define DV_PRESET_IS_VENDOR_SPECIFIC5
__u32 flags; /* Interlaced/progressive, DV specs, etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[4];
};
#define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct v4l2_dv_enum_preset2)
#define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV timing
information to select the desired format, and don't need to have a switch for
a preset macro to try to guess what the format actually means. Also, there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the above
definitions
are different than the old ones, _IO macros will provide a different magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one as
deprecated.
Thanks,
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
RFC: Changes to preset handling
There has been some discussion recently regarding the preset API:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg33774.html
The current presets are:
#define V4L2_DV_INVALID 0
#define V4L2_DV_480P59_94 1 /* BT.1362 */
#define V4L2_DV_576P50 2 /* BT.1362 */
#define V4L2_DV_720P24 3 /* SMPTE 296M */
#define V4L2_DV_720P25 4 /* SMPTE 296M */
#define V4L2_DV_720P30 5 /* SMPTE 296M */
#define V4L2_DV_720P50 6 /* SMPTE 296M */
#define V4L2_DV_720P59_94 7 /* SMPTE 274M */
#define V4L2_DV_720P60 8 /* SMPTE 274M/296M */
#define V4L2_DV_1080I29_97 9 /* BT.1120/ SMPTE 274M */
#define V4L2_DV_1080I30 10 /* BT.1120/ SMPTE 274M */
#define V4L2_DV_1080I25 11 /* BT.1120 */
#define V4L2_DV_1080I50 12 /* SMPTE 296M */
#define V4L2_DV_1080I60 13 /* SMPTE 296M */
#define V4L2_DV_1080P24 14 /* SMPTE 296M */
#define V4L2_DV_1080P25 15 /* SMPTE 296M */
#define V4L2_DV_1080P30 16 /* SMPTE 296M */
#define V4L2_DV_1080P50 17 /* BT.1120 */
#define V4L2_DV_1080P60 18 /* BT.1120 */
One thing that needs to change is that the comments should refer to the
CEA-861 standard since all these presets are from that document. The other
thing is that the macros should contain the name of the standard and the
exact resolution. This allows for adding presets from other standards
such as the VESA DMT standard.
The proposed list of presets would look like this:
#define V4L2_DV_INVALID0
#define V4L2_DV_CEA861_720X480P59_94 1 /* CEA-861, VIC 2, 3 */
#define V4L2_DV_480P59_94 V4L2_DV_CEA861_720X480P59_94
#define V4L2_DV_CEA861_720X576P50 2 /* CEA-861, VIC 17, 18 */
#define V4L2_DV_576P50 V4L2_DV_CEA861_720X576P50
#define V4L2_DV_CEA861_1280X720P24 3 /* CEA-861, VIC 60 */
#define V4L2_DV_720P24 V4L2_DV_CEA861_1280X720P24
...
#define V4L2_DV_CEA861_1280X720P59_94 7 /* CEA-861, VIC 4 */
#define V4L2_DV_720P59_94 V4L2_DV_CEA861_1280X720P59_94
#define V4L2_DV_CEA861_1280X720P60 8 /* CEA-861, VIC 4 */
#define V4L2_DV_720P60 V4L2_DV_CEA861_1280X720P60
...
The old names become aliases to the new ones.
I would also like to reserve the range 1-65535 for the CEA presets, so a comment
is needed for this.
The other part that needs to be extended is struct v4l2_dv_enum_presets.
Currently
this returns a human readable description of the format and the width and
height.
What is missing is the fps or frame period and a flags field that can tell
whether
this is an interlaced or progressive format.
So I propose to extend the struct as follows:
struct v4l2_dv_enum_preset {
__u32 index;
__u32 preset;
__u8name[32]; /* Name of the preset timing */
__u32 width;
__u32 height;
struct v4l2_fract fps;
__u32 flags;
__u32 reserved[1];
};
#define V4L2_DV_ENUM_FL_INTERLACED (1 << 0)
What is better: that the v4l2_fract represents frames-per-second or that it
represents
time-per-frame? G/S_PARM uses the latter, but I find the first more logical.
Another thing that is missing in VIDIOC_ENUM_DV_PRESETS is that you cannot put
in a
specific preset and get back this information. Instead it is index based. This
is fine
when you want to enumerate all available presets, but it is annoying when you
want to
find the specifics one particular preset.
I propose that we define a specific index value (e.g. 0x8000) that will let
the
driver return the information about the preset instead (or -EINVAL if the
preset is
not supported by the driver). So:
#define V4L2_DV_ENUM_USE_PRESET 0x8000
A separate issue is how to handle calculated modes based on the VESA GTF and CVT
standards. For a video transmitter the VIDIOC_S_DV_TIMINGS can be used, although
the application has to do the calculations. For video receiving things are much
more complex. This needs more research. There are several possibilities, but it
isn't clear which works best. Some experimentation is needed, but due to
vacations
this will have to be postponed.
Comment?
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>
>>> I failed to see what information is provided by the "presets" name. If
>>> this were removed
>>> from the ioctl, and fps would be added instead, the API would be
>>> clearer. The only
>>> adjustment would be to use "index" as the preset selection key. Anyway,
>>> it is too late
>>> for such change. We need to live with that.
>>
>> Adding the fps solves nothing. Because that still does not give you
>> specific timings.
>> You can have 1920x1080P60 that has quite different timings from the
>> CEA-861 standard
>> and that may not be supported by a TV.
>>
>> If you are working with HDMI, then you may want to filter all supported
>> presets to
>> those of the CEA standard.
>>
>> That's one thing that is missing at the moment: that presets belonging
>> to a certain
>> standard get their own range. Since we only do CEA861 right now it
>> hasn't been an
>> issue, but it will.
>
> I prepared a long email about that, but then I realized that we're
> investing our time into
> something broken, at the light of all DV timing standards. So, I've
> dropped it and
> started from scratch.
>
> From what I've got, there are some hardware that can only do a limited set
> of DV timings.
> If this were not the case, we could simply just use the
> VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
> and put the CEA 861 and VESA timings into some userspace library.
>
> In other words, the PRESET API is meant to solve the case where hardware
> only support
> a limited set of frequencies, that may or may not be inside the CEA
> standard.
>
> Let's assume we never added the current API, and discuss how it would
> properly fulfill
> the user needs. An API that would likely work is:
>
> struct v4l2_dv_enum_preset2 {
> __u32 index;
> __u8 name[32]; /* Name of the preset timing */
>
> struct v4l2_fract fps;
>
> #define DV_PRESET_IS_PROGRESSIVE 1<<31
> #define DV_PRESET_SPEC(flag) (flag && 0xff)
> #define DV_PRESET_IS_CEA861 1
> #define DV_PRESET_IS_DMT 2
> #define DV_PRESET_IS_CVF 3
> #define DV_PRESET_IS_GTF 4
> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
>
> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>
> __u32 width; /* width in pixels */
> __u32 height; /* height in lines */
> __u32 polarities; /* Positive or negative polarity */
> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
> __u32 hfrontporch;/* Horizpontal front porch in pixels */
> __u32 hsync; /* Horizontal Sync length in pixels */
> __u32 hbackporch; /* Horizontal back porch in pixels */
> __u32 vfrontporch;/* Vertical front porch in pixels */
> __u32 vsync; /* Vertical Sync length in lines */
> __u32 vbackporch; /* Vertical back porch in lines */
> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>* interlaced field formats
>*/
> __u32 il_vsync; /* Vertical sync length for bottom field of
>* interlaced field formats
>*/
> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>* interlaced field formats
>*/
> __u32 reserved[4];
> };
>
> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
> v4l2_dv_enum_preset2)
> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>
> Such preset API seems to work for all cases. Userspace can use any DV
> timing
> information to select the desired format, and don't need to have a switch
> for
> a preset macro to try to guess what the format actually means. Also,
> there's no
> need to touch at the API spec every time a new DV timeline is needed.
>
> Also, it should be noticed that, since the size of the data on the above
> definitions
> are different than the old ones, _IO macros will provide a different magic
> number,
> so, adding these won't break the existing API.
>
> So, I think we should work on this proposal, and mark the existing one as
> deprecated.
This proposal makes it very hard for applications to directly select a
format like 720p50 because the indices can change at any time. I think
this is a very desirable feature, particularly for apps running on
embedded systems where the hardware is known. This was one of the design
considerations at the time this API was made.
But looking at this I wonder if we shouldn't just make a
VIDIOC_G_PRESET_TIMINGS function? You give it the preset ID and you get
all the timing information back. No need to deprecate anything. I'm not
even sure if with this change we need to modify struct v4l2_dv_enum_preset
as I proposed in my RFC, although I thi
RE: [DVB] TT S-1500b tuning issue
> -Original Message- > From: Oliver Endriss [mailto:o.endr...@gmx.de] > Sent: lundi 4 juillet 2011 00:43 > To: Linux Media Mailing List > Cc: Sébastien RAILLARD (COEXSI); Malcolm Priestley > Subject: Re: [DVB] TT S-1500b tuning issue > > On Wednesday 29 June 2011 15:16:10 Sébastien RAILLARD wrote: > > Dear all, > > > > We have found what seems to be a tuning issue in the driver for the > > ALPS BSBE1-D01A used in the new TT-S-1500b card from Technotrend. > > On some transponders, like ASTRA 19.2E 11817-V-27500, the card can > > work very well (no lock issues) for hours. > > > > On some other transponders, like ASTRA 19.2E 11567-V-22000, the card > > nearly never manage to get the lock: it's looking like the signal > > isn't good enough. > > Afaics the problem is caused by the tuning loop > for (tm = -6; tm < 7;) > in stv0288_set_frontend(). > > I doubt that this code works reliably. > Apparently it never obtains a lock within the given delay (30us). > > Could you please try the attached patch? > It disables the loop and tries to tune to the center frequency. > Ok, I've tested this patch with ASTRA 19.2 #24 transponder that wasn't always working: it seems to work. I think it would be great to test it for few days more to be sure. > CU > Oliver > > -- > > VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ > 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ > Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ > -- 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: [DVB] Possible regression in stb6100 module for DVBS2 transponders
> -Original Message- > From: Issa Gorissen [mailto:flo...@usa.net] > Sent: lundi 4 juillet 2011 14:25 > To: "Sébastien RAILLARD (COEXSI)" > Cc: Linux Media Mailing List; abraham.m...@gmail.com > Subject: Re: [DVB] Possible regression in stb6100 module for DVBS2 > transponders > > On 01/07/2011 10:44, Sébastien RAILLARD (COEXSI) wrote: > > Dear Manu, > > > > I think there is a regression in your patch from December 2010 > > regarding the > > stb6100 module. > > With the latest version of stb6100 published in media_build git > > branch, we can't tune the TT-S2-3200 on some DVBS2 transponders like > > Hotbird 13E > > 11681-H-27500 or Hotbird 13E 12692-H-27500. > > After reverting to the previous stb6100_set_frequency function, it's > > working fine. > > So, there is maybe in issue in the last December code refactoring. > > > > Reference of the patch: "[media] stb6100: Improve tuner performance" > > http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/dvb/fr > > ontend s/stb6100.c;h=bc1a8af4f6e105181670ee33ebe111f98425e0ff;hb=HEAD > > > > See below for the code removed from the stb6100.c file (the > > stb6100_set_frequency function) and the code added (the previous > > stb6100_set_frequency function and the stb6100_write_regs function). > > > > Best regards, > > Sebastien. > > Reported back in may > [http://www.mail-archive.com/linux-media@vger.kernel.org/msg31334.html] I can confirm what was reported by Issa, my problem was solved after applying these two patches: 1- https://patchwork.kernel.org/patch/244201/ Why this patch is noted as "refused"? It seems to solve the last issues encountered with the TT-S2-3200. 2- https://patchwork.kernel.org/patch/753392/ This patch is still in "RFC" And removing this one that seem to introduce a regression, as noted before: http://git.linuxtv.org/media_tree.git?a=commit;h=f14bfe94e459cb070a489e1786f 26d54e9e7b5de Sebastien. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 06-07-2011 08:31, Hans Verkuil escreveu:
>> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>>
I failed to see what information is provided by the "presets" name. If
this were removed
from the ioctl, and fps would be added instead, the API would be
clearer. The only
adjustment would be to use "index" as the preset selection key. Anyway,
it is too late
for such change. We need to live with that.
>>>
>>> Adding the fps solves nothing. Because that still does not give you
>>> specific timings.
>>> You can have 1920x1080P60 that has quite different timings from the
>>> CEA-861 standard
>>> and that may not be supported by a TV.
>>>
>>> If you are working with HDMI, then you may want to filter all supported
>>> presets to
>>> those of the CEA standard.
>>>
>>> That's one thing that is missing at the moment: that presets belonging
>>> to a certain
>>> standard get their own range. Since we only do CEA861 right now it
>>> hasn't been an
>>> issue, but it will.
>>
>> I prepared a long email about that, but then I realized that we're
>> investing our time into
>> something broken, at the light of all DV timing standards. So, I've
>> dropped it and
>> started from scratch.
>>
>> From what I've got, there are some hardware that can only do a limited set
>> of DV timings.
>> If this were not the case, we could simply just use the
>> VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
>> and put the CEA 861 and VESA timings into some userspace library.
>>
>> In other words, the PRESET API is meant to solve the case where hardware
>> only support
>> a limited set of frequencies, that may or may not be inside the CEA
>> standard.
>>
>> Let's assume we never added the current API, and discuss how it would
>> properly fulfill
>> the user needs. An API that would likely work is:
>>
>> struct v4l2_dv_enum_preset2 {
>> __u32 index;
>> __u8 name[32]; /* Name of the preset timing */
>>
>> struct v4l2_fract fps;
>>
>> #define DV_PRESET_IS_PROGRESSIVE 1<<31
>> #define DV_PRESET_SPEC(flag) (flag && 0xff)
>> #define DV_PRESET_IS_CEA861 1
>> #define DV_PRESET_IS_DMT 2
>> #define DV_PRESET_IS_CVF 3
>> #define DV_PRESET_IS_GTF 4
>> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
>>
>> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>>
>> __u32 width; /* width in pixels */
>> __u32 height; /* height in lines */
>> __u32 polarities; /* Positive or negative polarity */
>> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
>> __u32 hfrontporch;/* Horizpontal front porch in pixels */
>> __u32 hsync; /* Horizontal Sync length in pixels */
>> __u32 hbackporch; /* Horizontal back porch in pixels */
>> __u32 vfrontporch;/* Vertical front porch in pixels */
>> __u32 vsync; /* Vertical Sync length in lines */
>> __u32 vbackporch; /* Vertical back porch in lines */
>> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>> * interlaced field formats
>> */
>> __u32 il_vsync; /* Vertical sync length for bottom field of
>> * interlaced field formats
>> */
>> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>> * interlaced field formats
>> */
>> __u32 reserved[4];
>> };
>>
>> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
>> v4l2_dv_enum_preset2)
>> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
>> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>>
>> Such preset API seems to work for all cases. Userspace can use any DV
>> timing
>> information to select the desired format, and don't need to have a switch
>> for
>> a preset macro to try to guess what the format actually means. Also,
>> there's no
>> need to touch at the API spec every time a new DV timeline is needed.
>>
>> Also, it should be noticed that, since the size of the data on the above
>> definitions
>> are different than the old ones, _IO macros will provide a different magic
>> number,
>> so, adding these won't break the existing API.
>>
>> So, I think we should work on this proposal, and mark the existing one as
>> deprecated.
>
> This proposal makes it very hard for applications to directly select a
> format like 720p50 because the indices can change at any time.
Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
check what line it wants, and do a S_DV_PRESET2, just like any other place
where V4L2 defines an ENUM function.
The enum won't change during application runtime, so, they can be stored
if the application would need to switch to other formats latter.
> I think
> this is a very desirable feature, particularly for
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Wednesday 06 July 2011 13:48:35 Mauro Carvalho Chehab wrote:
> Em 06-07-2011 08:31, Hans Verkuil escreveu:
> >> Em 05-07-2011 10:20, Hans Verkuil escreveu:
> I failed to see what information is provided by the "presets" name. If
> this were removed from the ioctl, and fps would be added instead, the
> API would be clearer. The only adjustment would be to use "index" as
> the preset selection key. Anyway, it is too late for such change. We
> need to live with that.
> >>>
> >>> Adding the fps solves nothing. Because that still does not give you
> >>> specific timings. You can have 1920x1080P60 that has quite different
> >>> timings from the CEA-861 standard and that may not be supported by a TV.
> >>>
> >>> If you are working with HDMI, then you may want to filter all supported
> >>> presets to those of the CEA standard.
> >>>
> >>> That's one thing that is missing at the moment: that presets belonging
> >>> to a certain standard get their own range. Since we only do CEA861 right
> >>> now it hasn't been an issue, but it will.
> >>
> >> I prepared a long email about that, but then I realized that we're
> >> investing our time intosomething broken, at the light of all DV timing
> >> standards. So, I've dropped it and started from scratch.
> >>
> >> From what I've got, there are some hardware that can only do a limited
> >> set of DV timings. If this were not the case, we could simply just use
> >> the VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS, and put the CEA 861 and VESA
> >> timings into some userspace library.
> >>
> >> In other words, the PRESET API is meant to solve the case where hardware
> >> only support a limited set of frequencies, that may or may not be inside
> >> the CEA standard.
> >>
> >> Let's assume we never added the current API, and discuss how it would
> >> properly fulfill the user needs. An API that would likely work is:
> >>
> >> struct v4l2_dv_enum_preset2 {
> >>
> >>__u32 index;
> >>__u8 name[32]; /* Name of the preset timing */
> >>
> >>struct v4l2_fract fps;
> >>
> >> #define DV_PRESET_IS_PROGRESSIVE 1<<31
> >> #define DV_PRESET_SPEC(flag) (flag && 0xff)
> >> #define DV_PRESET_IS_CEA8611
> >> #define DV_PRESET_IS_DMT 2
> >> #define DV_PRESET_IS_CVF 3
> >> #define DV_PRESET_IS_GTF 4
> >> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
> >>
> >>__u32 flags; /* Interlaced/progressive, DV specs, etc */
> >>
> >>__u32 width; /* width in pixels */
> >>__u32 height; /* height in lines */
> >>__u32 polarities; /* Positive or negative polarity */
> >>__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
> >>__u32 hfrontporch;/* Horizpontal front porch in pixels */
> >>__u32 hsync; /* Horizontal Sync length in pixels */
> >>__u32 hbackporch; /* Horizontal back porch in pixels */
> >>__u32 vfrontporch;/* Vertical front porch in pixels */
> >>__u32 vsync; /* Vertical Sync length in lines */
> >>__u32 vbackporch; /* Vertical back porch in lines */
> >>__u32 il_vfrontporch; /* Vertical front porch for bottom field of
> >>
> >> * interlaced field formats
> >> */
> >>
> >>__u32 il_vsync; /* Vertical sync length for bottom field of
> >>
> >> * interlaced field formats
> >> */
> >>
> >>__u32 il_vbackporch; /* Vertical back porch for bottom field of
> >>
> >> * interlaced field formats
> >> */
> >>
> >>__u32 reserved[4];
> >>
> >> };
> >>
> >> #defineVIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
> >> v4l2_dv_enum_preset2)
> >> #defineVIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
> >> #defineVIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
> >>
> >> Such preset API seems to work for all cases. Userspace can use any DV
> >> timing information to select the desired format, and don't need to have a
> >> switch for a preset macro to try to guess what the format actually means.
> >> Also, there's no need to touch at the API spec every time a new DV
> >> timeline is needed.
> >>
> >> Also, it should be noticed that, since the size of the data on the above
> >> definitions are different than the old ones, _IO macros will provide a
> >> different magic number, so, adding these won't break the existing API.
> >>
> >> So, I think we should work on this proposal, and mark the existing one
> >> as deprecated.
> >
> > This proposal makes it very hard for applications to directly select a
> > format like 720p50 because the indices can change at any time.
>
> Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
> check what line it wants, and do a S_DV_PRESET2, just like any other place
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 06-07-2011 09:03, Laurent Pinchart escreveu:
> On Wednesday 06 July 2011 13:48:35 Mauro Carvalho Chehab wrote:
>> Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
>> I failed to see what information is provided by the "presets" name. If
>> this were removed from the ioctl, and fps would be added instead, the
>> API would be clearer. The only adjustment would be to use "index" as
>> the preset selection key. Anyway, it is too late for such change. We
>> need to live with that.
>
> Adding the fps solves nothing. Because that still does not give you
> specific timings. You can have 1920x1080P60 that has quite different
> timings from the CEA-861 standard and that may not be supported by a TV.
>
> If you are working with HDMI, then you may want to filter all supported
> presets to those of the CEA standard.
>
> That's one thing that is missing at the moment: that presets belonging
> to a certain standard get their own range. Since we only do CEA861 right
> now it hasn't been an issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time intosomething broken, at the light of all DV timing
standards. So, I've dropped it and started from scratch.
From what I've got, there are some hardware that can only do a limited
set of DV timings. If this were not the case, we could simply just use
the VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS, and put the CEA 861 and VESA
timings into some userspace library.
In other words, the PRESET API is meant to solve the case where hardware
only support a limited set of frequencies, that may or may not be inside
the CEA standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 1<<31
#define DV_PRESET_SPEC(flag) (flag && 0xff)
#define DV_PRESET_IS_CEA8611
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs, etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[4];
};
#defineVIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#defineVIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#defineVIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing information to select the desired format, and don't need to have a
switch for a preset macro to try to guess what the format actually means.
Also, there's no need to touch at the API spec every time a new DV
timeline is needed.
Also, it should be noticed that, since the size of the data on the above
definitions are different than the old ones, _IO macros will provide a
different magic number, so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as deprecated.
>>>
>>> This proposal makes it very hard for applications to directly select a
>>> format like 720p50 because the indices can change at any time.
>>
>> Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
>> check what line it wants, and do a S_DV
[PATCH] Upside-down webcam on Asus K52JT
Greetings from yet another owner of an Asus laptop. Hopefully this is the right place... patch included. - device: 04f2:b1e5 - manufacturer: "ASUSTeK Computer Inc." - product: "K52JT" -- Mantas -- 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] libv4l: add Asus K52JT to upside down device table
---
lib/libv4lconvert/control/libv4lcontrol.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/libv4lconvert/control/libv4lcontrol.c
b/lib/libv4lconvert/control/libv4lcontrol.c
index 2fddf43..c8a636b 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -288,6 +288,8 @@ static const struct v4lcontrol_flags_info
v4lcontrol_flags[] = {
V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED },
{ 0x04f2, 0xb1e5, 0, "ASUSTeK Computer Inc.", "K52Jc",
V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED },
+ { 0x04f2, 0xb1e5, 0, "ASUSTeK Computer Inc.", "K52JT",
+ V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED },
{ 0x04f2, 0xb1e5, 0, "ASUSTeK Computer Inc.", "K52N",
V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED },
{ 0x04f2, 0xb1e5, 0, "ASUSTeK Computer Inc.", "P52F",
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Wednesday 06 July 2011 14:09:38 Mauro Carvalho Chehab wrote:
> Em 06-07-2011 09:03, Laurent Pinchart escreveu:
> > On Wednesday 06 July 2011 13:48:35 Mauro Carvalho Chehab wrote:
> >> Em 06-07-2011 08:31, Hans Verkuil escreveu:
> Em 05-07-2011 10:20, Hans Verkuil escreveu:
> >> I failed to see what information is provided by the "presets" name.
> >> If this were removed from the ioctl, and fps would be added
> >> instead, the API would be clearer. The only adjustment would be to
> >> use "index" as the preset selection key. Anyway, it is too late for
> >> such change. We need to live with that.
> >
> > Adding the fps solves nothing. Because that still does not give you
> > specific timings. You can have 1920x1080P60 that has quite different
> > timings from the CEA-861 standard and that may not be supported by a
> > TV.
> >
> > If you are working with HDMI, then you may want to filter all
> > supported presets to those of the CEA standard.
> >
> > That's one thing that is missing at the moment: that presets
> > belonging to a certain standard get their own range. Since we only
> > do CEA861 right now it hasn't been an issue, but it will.
>
> I prepared a long email about that, but then I realized that we're
> investing our time intosomething broken, at the light of all DV timing
> standards. So, I've dropped it and started from scratch.
>
> From what I've got, there are some hardware that can only do a limited
> set of DV timings. If this were not the case, we could simply just use
> the VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS, and put the CEA 861 and
> VESA timings into some userspace library.
>
> In other words, the PRESET API is meant to solve the case where
> hardware only support a limited set of frequencies, that may or may
> not be inside the CEA standard.
>
> Let's assume we never added the current API, and discuss how it would
> properly fulfill the user needs. An API that would likely work is:
>
> struct v4l2_dv_enum_preset2 {
>
> __u32 index;
> __u8 name[32]; /* Name of the preset timing */
>
> struct v4l2_fract fps;
>
> #define DV_PRESET_IS_PROGRESSIVE 1<<31
> #define DV_PRESET_SPEC(flag) (flag && 0xff)
> #define DV_PRESET_IS_CEA861 1
> #define DV_PRESET_IS_DMT 2
> #define DV_PRESET_IS_CVF 3
> #define DV_PRESET_IS_GTF 4
> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
>
> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>
> __u32 width; /* width in pixels */
> __u32 height; /* height in lines */
> __u32 polarities; /* Positive or negative polarity */
> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
> __u32 hfrontporch;/* Horizpontal front porch in pixels */
> __u32 hsync; /* Horizontal Sync length in pixels */
> __u32 hbackporch; /* Horizontal back porch in pixels */
> __u32 vfrontporch;/* Vertical front porch in pixels */
> __u32 vsync; /* Vertical Sync length in lines */
> __u32 vbackporch; /* Vertical back porch in lines */
> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>
> * interlaced field formats
> */
>
> __u32 il_vsync; /* Vertical sync length for bottom field of
>
> * interlaced field formats
> */
>
> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>
> * interlaced field formats
> */
>
> __u32 reserved[4];
>
> };
>
> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
> v4l2_dv_enum_preset2)
> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>
> Such preset API seems to work for all cases. Userspace can use any DV
> timing information to select the desired format, and don't need to
> have a switch for a preset macro to try to guess what the format
> actually means. Also, there's no need to touch at the API spec every
> time a new DV timeline is needed.
>
> Also, it should be noticed that, since the size of the data on the
> above definitions are different than the old ones, _IO macros will
> provide a different magic number, so, adding these won't break the
> existing API.
>
> So, I think we should work on this proposal, and mark the existing one
> as deprecated.
> >>>
> >>> This proposal makes it very hard for applic
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
> Em 06-07-2011 08:31, Hans Verkuil escreveu:
>>> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>>>
> I failed to see what information is provided by the "presets" name.
> If
> this were removed
> from the ioctl, and fps would be added instead, the API would be
> clearer. The only
> adjustment would be to use "index" as the preset selection key.
> Anyway,
> it is too late
> for such change. We need to live with that.
Adding the fps solves nothing. Because that still does not give you
specific timings.
You can have 1920x1080P60 that has quite different timings from the
CEA-861 standard
and that may not be supported by a TV.
If you are working with HDMI, then you may want to filter all
supported
presets to
those of the CEA standard.
That's one thing that is missing at the moment: that presets belonging
to a certain
standard get their own range. Since we only do CEA861 right now it
hasn't been an
issue, but it will.
>>>
>>> I prepared a long email about that, but then I realized that we're
>>> investing our time into
>>> something broken, at the light of all DV timing standards. So, I've
>>> dropped it and
>>> started from scratch.
>>>
>>> From what I've got, there are some hardware that can only do a limited
>>> set
>>> of DV timings.
>>> If this were not the case, we could simply just use the
>>> VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
>>> and put the CEA 861 and VESA timings into some userspace library.
>>>
>>> In other words, the PRESET API is meant to solve the case where
>>> hardware
>>> only support
>>> a limited set of frequencies, that may or may not be inside the CEA
>>> standard.
>>>
>>> Let's assume we never added the current API, and discuss how it would
>>> properly fulfill
>>> the user needs. An API that would likely work is:
>>>
>>> struct v4l2_dv_enum_preset2 {
>>> __u32 index;
>>> __u8 name[32]; /* Name of the preset timing */
>>>
>>> struct v4l2_fract fps;
>>>
>>> #define DV_PRESET_IS_PROGRESSIVE1<<31
>>> #define DV_PRESET_SPEC(flag)(flag && 0xff)
>>> #define DV_PRESET_IS_CEA861 1
>>> #define DV_PRESET_IS_DMT2
>>> #define DV_PRESET_IS_CVF3
>>> #define DV_PRESET_IS_GTF4
>>> #define DV_PRESET_IS_VENDOR_SPECIFIC5
>>>
>>> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>>>
>>> __u32 width; /* width in pixels */
>>> __u32 height; /* height in lines */
>>> __u32 polarities; /* Positive or negative polarity */
>>> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
>>> __u32 hfrontporch;/* Horizpontal front porch in pixels */
>>> __u32 hsync; /* Horizontal Sync length in pixels */
>>> __u32 hbackporch; /* Horizontal back porch in pixels */
>>> __u32 vfrontporch;/* Vertical front porch in pixels */
>>> __u32 vsync; /* Vertical Sync length in lines */
>>> __u32 vbackporch; /* Vertical back porch in lines */
>>> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>>> * interlaced field formats
>>> */
>>> __u32 il_vsync; /* Vertical sync length for bottom field of
>>> * interlaced field formats
>>> */
>>> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>>> * interlaced field formats
>>> */
>>> __u32 reserved[4];
>>> };
>>>
>>> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
>>> v4l2_dv_enum_preset2)
>>> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
>>> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>>>
>>> Such preset API seems to work for all cases. Userspace can use any DV
>>> timing
>>> information to select the desired format, and don't need to have a
>>> switch
>>> for
>>> a preset macro to try to guess what the format actually means. Also,
>>> there's no
>>> need to touch at the API spec every time a new DV timeline is needed.
>>>
>>> Also, it should be noticed that, since the size of the data on the
>>> above
>>> definitions
>>> are different than the old ones, _IO macros will provide a different
>>> magic
>>> number,
>>> so, adding these won't break the existing API.
>>>
>>> So, I think we should work on this proposal, and mark the existing one
>>> as
>>> deprecated.
>>
>> This proposal makes it very hard for applications to directly select a
>> format like 720p50 because the indices can change at any time.
>
> Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
> check what line it wants,
It's not so easy as you think to find the right timings: you have to check
many parameters to be certain you have the right one and not some subtle
v
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 06-07-2011 09:13, Laurent Pinchart escreveu:
> On Wednesday 06 July 2011 14:09:38 Mauro Carvalho Chehab wrote:
>> Em 06-07-2011 09:03, Laurent Pinchart escreveu:
>>> On Wednesday 06 July 2011 13:48:35 Mauro Carvalho Chehab wrote:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
>> Em 05-07-2011 10:20, Hans Verkuil escreveu:
I failed to see what information is provided by the "presets" name.
If this were removed from the ioctl, and fps would be added
instead, the API would be clearer. The only adjustment would be to
use "index" as the preset selection key. Anyway, it is too late for
such change. We need to live with that.
>>>
>>> Adding the fps solves nothing. Because that still does not give you
>>> specific timings. You can have 1920x1080P60 that has quite different
>>> timings from the CEA-861 standard and that may not be supported by a
>>> TV.
>>>
>>> If you are working with HDMI, then you may want to filter all
>>> supported presets to those of the CEA standard.
>>>
>>> That's one thing that is missing at the moment: that presets
>>> belonging to a certain standard get their own range. Since we only
>>> do CEA861 right now it hasn't been an issue, but it will.
>>
>> I prepared a long email about that, but then I realized that we're
>> investing our time intosomething broken, at the light of all DV timing
>> standards. So, I've dropped it and started from scratch.
>>
>> From what I've got, there are some hardware that can only do a limited
>> set of DV timings. If this were not the case, we could simply just use
>> the VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS, and put the CEA 861 and
>> VESA timings into some userspace library.
>>
>> In other words, the PRESET API is meant to solve the case where
>> hardware only support a limited set of frequencies, that may or may
>> not be inside the CEA standard.
>>
>> Let's assume we never added the current API, and discuss how it would
>> properly fulfill the user needs. An API that would likely work is:
>>
>> struct v4l2_dv_enum_preset2 {
>>
>> __u32 index;
>> __u8 name[32]; /* Name of the preset timing */
>>
>> struct v4l2_fract fps;
>>
>> #define DV_PRESET_IS_PROGRESSIVE 1<<31
>> #define DV_PRESET_SPEC(flag) (flag && 0xff)
>> #define DV_PRESET_IS_CEA861 1
>> #define DV_PRESET_IS_DMT 2
>> #define DV_PRESET_IS_CVF 3
>> #define DV_PRESET_IS_GTF 4
>> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
>>
>> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>>
>> __u32 width; /* width in pixels */
>> __u32 height; /* height in lines */
>> __u32 polarities; /* Positive or negative polarity */
>> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
>> __u32 hfrontporch;/* Horizpontal front porch in pixels */
>> __u32 hsync; /* Horizontal Sync length in pixels */
>> __u32 hbackporch; /* Horizontal back porch in pixels */
>> __u32 vfrontporch;/* Vertical front porch in pixels */
>> __u32 vsync; /* Vertical Sync length in lines */
>> __u32 vbackporch; /* Vertical back porch in lines */
>> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>>
>> * interlaced field formats
>> */
>>
>> __u32 il_vsync; /* Vertical sync length for bottom field of
>>
>> * interlaced field formats
>> */
>>
>> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>>
>> * interlaced field formats
>> */
>>
>> __u32 reserved[4];
>>
>> };
>>
>> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
>> v4l2_dv_enum_preset2)
>> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
>> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>>
>> Such preset API seems to work for all cases. Userspace can use any DV
>> timing information to select the desired format, and don't need to
>> have a switch for a preset macro to try to guess what the format
>> actually means. Also, there's no need to touch at the API spec every
>> time a new DV timeline is needed.
>>
>> Also, it should be noticed that, since the size of the data on the
>> above definitions are different than the old ones, _IO macros will
>> provide a different magic number, so, adding these won't break the
>> existing API.
>>
>> So, I think we should work on this proposal, and mark the existing one
>> as deprecated.
>
> This prop
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 06-07-2011 09:14, Hans Verkuil escreveu:
>> Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
>> I failed to see what information is provided by the "presets" name.
>> If
>> this were removed
>> from the ioctl, and fps would be added instead, the API would be
>> clearer. The only
>> adjustment would be to use "index" as the preset selection key.
>> Anyway,
>> it is too late
>> for such change. We need to live with that.
>
> Adding the fps solves nothing. Because that still does not give you
> specific timings.
> You can have 1920x1080P60 that has quite different timings from the
> CEA-861 standard
> and that may not be supported by a TV.
>
> If you are working with HDMI, then you may want to filter all
> supported
> presets to
> those of the CEA standard.
>
> That's one thing that is missing at the moment: that presets belonging
> to a certain
> standard get their own range. Since we only do CEA861 right now it
> hasn't been an
> issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time into
something broken, at the light of all DV timing standards. So, I've
dropped it and
started from scratch.
From what I've got, there are some hardware that can only do a limited
set
of DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where
hardware
only support
a limited set of frequencies, that may or may not be inside the CEA
standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 1<<31
#define DV_PRESET_SPEC(flag) (flag && 0xff)
#define DV_PRESET_IS_CEA8611
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs, etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[4];
};
#defineVIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#defineVIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#defineVIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing
information to select the desired format, and don't need to have a
switch
for
a preset macro to try to guess what the format actually means. Also,
there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the
above
definitions
are different than the old ones, _IO macros will provide a different
magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as
deprecated.
>>>
>>> This proposal makes it very hard for applications to directly select a
>>> format like 720p50 because the indices can change at any time.
>>
>> Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
>> check what line it wants,
>
> It's
[GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. Laurent noticed an issue with the previous pull request and I've fixed that. Changes since the second pull request: - Properly call validate_new_int() from validate_new() for bitmask controls. Changes since the first pull request to the second one: - Added a patch to document the V4L2 control endianness. It's on the top. - Rebased the patches. I haven't tested vivi, though. - The adp1653 uses dev_pm_ops instead of i2c ops for suspend/resume. Changes since the last patchset since the first pull request: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1-flash-4 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. Sakari Ailus (4): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller v4l: Document V4L2 control endianness as machine endianness. Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 291 Documentation/DocBook/media/v4l/v4l2.xml |6 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 491 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 63 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1068 insertions(+), 7 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- Sakari Ailus sakari.ai...@iki.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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
> Em 06-07-2011 09:14, Hans Verkuil escreveu:
>>> Em 06-07-2011 08:31, Hans Verkuil escreveu:
> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>
>>> I failed to see what information is provided by the "presets" name.
>>> If
>>> this were removed
>>> from the ioctl, and fps would be added instead, the API would be
>>> clearer. The only
>>> adjustment would be to use "index" as the preset selection key.
>>> Anyway,
>>> it is too late
>>> for such change. We need to live with that.
>>
>> Adding the fps solves nothing. Because that still does not give you
>> specific timings.
>> You can have 1920x1080P60 that has quite different timings from the
>> CEA-861 standard
>> and that may not be supported by a TV.
>>
>> If you are working with HDMI, then you may want to filter all
>> supported
>> presets to
>> those of the CEA standard.
>>
>> That's one thing that is missing at the moment: that presets
>> belonging
>> to a certain
>> standard get their own range. Since we only do CEA861 right now it
>> hasn't been an
>> issue, but it will.
>
> I prepared a long email about that, but then I realized that we're
> investing our time into
> something broken, at the light of all DV timing standards. So, I've
> dropped it and
> started from scratch.
>
> From what I've got, there are some hardware that can only do a
> limited
> set
> of DV timings.
> If this were not the case, we could simply just use the
> VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
> and put the CEA 861 and VESA timings into some userspace library.
>
> In other words, the PRESET API is meant to solve the case where
> hardware
> only support
> a limited set of frequencies, that may or may not be inside the CEA
> standard.
>
> Let's assume we never added the current API, and discuss how it would
> properly fulfill
> the user needs. An API that would likely work is:
>
> struct v4l2_dv_enum_preset2 {
> __u32 index;
> __u8 name[32]; /* Name of the preset timing */
>
> struct v4l2_fract fps;
>
> #define DV_PRESET_IS_PROGRESSIVE 1<<31
> #define DV_PRESET_SPEC(flag) (flag && 0xff)
> #define DV_PRESET_IS_CEA861 1
> #define DV_PRESET_IS_DMT 2
> #define DV_PRESET_IS_CVF 3
> #define DV_PRESET_IS_GTF 4
> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
>
> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>
> __u32 width; /* width in pixels */
> __u32 height; /* height in lines */
> __u32 polarities; /* Positive or negative polarity */
> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
> __u32 hfrontporch;/* Horizpontal front porch in pixels */
> __u32 hsync; /* Horizontal Sync length in pixels */
> __u32 hbackporch; /* Horizontal back porch in pixels */
> __u32 vfrontporch;/* Vertical front porch in pixels */
> __u32 vsync; /* Vertical Sync length in lines */
> __u32 vbackporch; /* Vertical back porch in lines */
> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>* interlaced field formats
>*/
> __u32 il_vsync; /* Vertical sync length for bottom field of
>* interlaced field formats
>*/
> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>* interlaced field formats
>*/
> __u32 reserved[4];
> };
>
> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
> v4l2_dv_enum_preset2)
> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>
> Such preset API seems to work for all cases. Userspace can use any DV
> timing
> information to select the desired format, and don't need to have a
> switch
> for
> a preset macro to try to guess what the format actually means. Also,
> there's no
> need to touch at the API spec every time a new DV timeline is needed.
>
> Also, it should be noticed that, since the size of the data on the
> above
> definitions
> are different than the old ones, _IO macros will provide a different
> magic
> number,
> so, adding these won't break the existing API.
>
> So, I think we should work on this proposal, and mark the existing
> one
> as
> deprecated.
This proposal makes it very hard for applications to directly select a
format like 720p50 because the indices can change at any time.
>>>
>>> Why?
RE: [PATCH 6/8] drivers: add Contiguous Memory Allocator
Hello, On Tuesday, July 05, 2011 1:34 PM Russell King - ARM Linux wrote: > On Tue, Jul 05, 2011 at 09:41:48AM +0200, Marek Szyprowski wrote: > > The Contiguous Memory Allocator is a set of helper functions for DMA > > mapping framework that improves allocations of contiguous memory chunks. > > > > CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and > > gives back to the system. Kernel is allowed to allocate movable pages > > within CMA's managed memory so that it can be used for example for page > > cache when DMA mapping do not use it. On dma_alloc_from_contiguous() > > request such pages are migrated out of CMA area to free required > > contiguous block and fulfill the request. This allows to allocate large > > contiguous chunks of memory at any time assuming that there is enough > > free memory available in the system. > > > > This code is heavily based on earlier works by Michal Nazarewicz. > > And how are you addressing the technical concerns about aliasing of > cache attributes which I keep bringing up with this and you keep > ignoring and telling me that I'm standing in your way. I'm perfectly aware of the issues with aliasing of cache attributes. My idea is to change low memory linear mapping for all CMA areas on boot time to use 2 level page tables (4KiB mappings instead of super-section mappings). This way the page properties for a single page in CMA area can be changed/updated at any time to match required coherent/writecombine attributes. Linear mapping can be even removed completely if we want to create the it elsewhere in the address space. The only problem that might need to be resolved is GFP_ATOMIC allocation (updating page properties probably requires some locking), but it can be served from a special area which is created on boot without low-memory mapping at all. None sane driver will call dma_alloc_coherent(GFP_ATOMIC) for large buffers anyway. CMA limits the memory area from which coherent pages are being taken quite well, so the change in the linear mapping method should have no significant impact on the system performance. I didn't implement such solution yet, because it is really hard to handle all issues at the same time and creating the allocator was just a first step. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC] media: vb2: change queue initialization order
Hello, On Friday, July 01, 2011 12:18 AM Jonathan Corbet wrote: > On Wed, 29 Jun 2011 16:10:45 +0200 > Marek Szyprowski wrote: > > > > I do still wonder why this is an issue - why not pass the buffers > through > > > to the driver at VIDIOC_QBUF time? I assume there must be a reason for > > > doing things this way, I'd like to understand what it is. > > > > I want to delay giving the ownership of the buffers to the driver until > it > > is certain that start_streaming method will be called. This way I achieve > > a well defined states of the queued buffers: > > > > 1. successful start_streaming() -> the driver is processing the queue > buffers > > 2. unsuccessful start_streaming() -> the driver is responsible to discard > all > >queued buffers > > 3. stop_streaming() called -> the driver has finished or discarded all > queued > >buffers > > So it's a buffer ownership thing. I wonder if there would be value in > adding a buf_give_them_all_back_now() callback? You have an implicit > change of buffer ownership now that seems easy for drivers to mess up. It > might be better to send an explicit signal at such times and, perhaps, > even require the driver to explicitly hand each buffer back to vb2? That > would make the rules clear and give some flexibility - stopping and > starting streaming without needing to start over with buffers, for example. You are right that this will make the rules more clear, but wonder if we really need it now in videbuf2. The current V4L2 API states that all buffers are automatically discarded after calling STREAM_OFF, so it is not really possible to implement true pause-like functionality. Maybe we should schedule this for V4L3? ;) Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wednesday 06 July 2011, Marek Szyprowski wrote: > The only problem that might need to be resolved is GFP_ATOMIC allocation > (updating page properties probably requires some locking), but it can be > served from a special area which is created on boot without low-memory > mapping at all. None sane driver will call dma_alloc_coherent(GFP_ATOMIC) > for large buffers anyway. Would it be easier to start with a version that only allocated from memory without a low-memory mapping at first? This would be similar to the approach that Russell's fix for the regular dma_alloc_coherent has taken, except that you need to also allow the memory to be used as highmem user pages. Maybe you can simply adapt the default location of the contiguous memory are like this: - make CONFIG_CMA depend on CONFIG_HIGHMEM on ARM, at compile time - if ZONE_HIGHMEM exist during boot, put the CMA area in there - otherwise, put the CMA area at the top end of lowmem, and change the zone sizes so ZONE_HIGHMEM stretches over all of the CMA memory. 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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 06-07-2011 09:56, Hans Verkuil escreveu:
>> Em 06-07-2011 09:14, Hans Verkuil escreveu:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
>> Em 05-07-2011 10:20, Hans Verkuil escreveu:
>>
I failed to see what information is provided by the "presets" name.
If
this were removed
from the ioctl, and fps would be added instead, the API would be
clearer. The only
adjustment would be to use "index" as the preset selection key.
Anyway,
it is too late
for such change. We need to live with that.
>>>
>>> Adding the fps solves nothing. Because that still does not give you
>>> specific timings.
>>> You can have 1920x1080P60 that has quite different timings from the
>>> CEA-861 standard
>>> and that may not be supported by a TV.
>>>
>>> If you are working with HDMI, then you may want to filter all
>>> supported
>>> presets to
>>> those of the CEA standard.
>>>
>>> That's one thing that is missing at the moment: that presets
>>> belonging
>>> to a certain
>>> standard get their own range. Since we only do CEA861 right now it
>>> hasn't been an
>>> issue, but it will.
>>
>> I prepared a long email about that, but then I realized that we're
>> investing our time into
>> something broken, at the light of all DV timing standards. So, I've
>> dropped it and
>> started from scratch.
>>
>> From what I've got, there are some hardware that can only do a
>> limited
>> set
>> of DV timings.
>> If this were not the case, we could simply just use the
>> VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
>> and put the CEA 861 and VESA timings into some userspace library.
>>
>> In other words, the PRESET API is meant to solve the case where
>> hardware
>> only support
>> a limited set of frequencies, that may or may not be inside the CEA
>> standard.
>>
>> Let's assume we never added the current API, and discuss how it would
>> properly fulfill
>> the user needs. An API that would likely work is:
>>
>> struct v4l2_dv_enum_preset2 {
>> __u32 index;
>> __u8 name[32]; /* Name of the preset timing */
>>
>> struct v4l2_fract fps;
>>
>> #define DV_PRESET_IS_PROGRESSIVE 1<<31
>> #define DV_PRESET_SPEC(flag) (flag && 0xff)
>> #define DV_PRESET_IS_CEA861 1
>> #define DV_PRESET_IS_DMT 2
>> #define DV_PRESET_IS_CVF 3
>> #define DV_PRESET_IS_GTF 4
>> #define DV_PRESET_IS_VENDOR_SPECIFIC 5
>>
>> __u32 flags; /* Interlaced/progressive, DV specs, etc */
>>
>> __u32 width; /* width in pixels */
>> __u32 height; /* height in lines */
>> __u32 polarities; /* Positive or negative polarity */
>> __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
>> __u32 hfrontporch;/* Horizpontal front porch in pixels */
>> __u32 hsync; /* Horizontal Sync length in pixels */
>> __u32 hbackporch; /* Horizontal back porch in pixels */
>> __u32 vfrontporch;/* Vertical front porch in pixels */
>> __u32 vsync; /* Vertical Sync length in lines */
>> __u32 vbackporch; /* Vertical back porch in lines */
>> __u32 il_vfrontporch; /* Vertical front porch for bottom field of
>> * interlaced field formats
>> */
>> __u32 il_vsync; /* Vertical sync length for bottom field of
>> * interlaced field formats
>> */
>> __u32 il_vbackporch; /* Vertical back porch for bottom field of
>> * interlaced field formats
>> */
>> __u32 reserved[4];
>> };
>>
>> #define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
>> v4l2_dv_enum_preset2)
>> #define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
>> #define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
>>
>> Such preset API seems to work for all cases. Userspace can use any DV
>> timing
>> information to select the desired format, and don't need to have a
>> switch
>> for
>> a preset macro to try to guess what the format actually means. Also,
>> there's no
>> need to touch at the API spec every time a new DV timeline is needed.
>>
>> Also, it should be noticed that, since the size of the data on the
>> above
>> definitions
>> are different than the old ones, _IO macros will provide a different
>> magic
>> number,
>> so, adding these won't break the existing API.
>>
>> So, I think we should work on this proposal, and mark the existing
>> one
>> as
>> deprecated.
>
> This proposal makes
Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, Jul 06, 2011 at 04:09:29PM +0200, Arnd Bergmann wrote: > Maybe you can simply adapt the default location of the contiguous memory > are like this: > - make CONFIG_CMA depend on CONFIG_HIGHMEM on ARM, at compile time > - if ZONE_HIGHMEM exist during boot, put the CMA area in there > - otherwise, put the CMA area at the top end of lowmem, and change > the zone sizes so ZONE_HIGHMEM stretches over all of the CMA memory. One of the requirements of the allocator is that the returned memory should be zero'd (because it can be exposed to userspace via ALSA and frame buffers.) Zeroing the memory from all the contexts which dma_alloc_coherent is called from is a trivial matter if its in lowmem, but highmem is harder. Another issue is that when a platform has restricted DMA regions, they typically don't fall into the highmem zone. As the dmabounce code allocates from the DMA coherent allocator to provide it with guaranteed DMA-able memory, that would be rather inconvenient. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: > Another issue is that when a platform has restricted DMA regions, > they typically don't fall into the highmem zone. As the dmabounce > code allocates from the DMA coherent allocator to provide it with > guaranteed DMA-able memory, that would be rather inconvenient. Do we encounter this in practice i.e. do those platforms requiring large contiguous allocations motivating this work have such DMA restrictions? Nicolas -- 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 6/8] drivers: add Contiguous Memory Allocator
On Wednesday 06 July 2011, Russell King - ARM Linux wrote: > On Wed, Jul 06, 2011 at 04:09:29PM +0200, Arnd Bergmann wrote: > > Maybe you can simply adapt the default location of the contiguous memory > > are like this: > > - make CONFIG_CMA depend on CONFIG_HIGHMEM on ARM, at compile time > > - if ZONE_HIGHMEM exist during boot, put the CMA area in there > > - otherwise, put the CMA area at the top end of lowmem, and change > > the zone sizes so ZONE_HIGHMEM stretches over all of the CMA memory. > > One of the requirements of the allocator is that the returned memory > should be zero'd (because it can be exposed to userspace via ALSA > and frame buffers.) > > Zeroing the memory from all the contexts which dma_alloc_coherent > is called from is a trivial matter if its in lowmem, but highmem is > harder. I don't see how. The pages get allocated from an unmapped area or memory, mapped into the kernel address space as uncached or wc and then cleared. This should be the same for lowmem or highmem pages. What am I missing? > Another issue is that when a platform has restricted DMA regions, > they typically don't fall into the highmem zone. As the dmabounce > code allocates from the DMA coherent allocator to provide it with > guaranteed DMA-able memory, that would be rather inconvenient. True. The dmabounce code would consequently have to allocate the memory through an internal function that avoids the contiguous allocation area and goes straight to ZONE_DMA memory as it does today. 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.1-rc7] media fixes
Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For a series of bug fixes: - mx1-camera were using an uninitialized variable; - pwc issues at USB disconnect; - several mceusb and lirc fixes; - some OOPSes fixes at uvc driver; - some videobuf2 fixes; - some omap1 camera fixes; - m5mols/s5p-fimc fixes (this is a driver added at 3.0 merge window); Thanks! Mauro The following changes since commit d364ee4fdb33a329b16cdf9342e9770b4d4ddc83: [media] soc_camera: preserve const attribute (2011-06-01 15:03:56 -0300) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Andre Bartke (1): [media] V4L: mx1-camera: fix uninitialized variable Hans de Goede (1): [media] pwc: better usb disconnect handling HeungJun, Kim (4): [media] m5mols: Fix capture image size register definition [media] m5mols: add m5mols_read_u8/u16/u32() according to I2C byte width [media] m5mols: remove union in the m5mols_get_version(), and VERSION_SIZE [media] m5mols: Use proper email address format Jarod Wilson (20): [media] mceusb: add and use mce_dbg printk macro [media] mceusb: support I-O Data GV-MC7/RCKIT [media] mceusb: mce_sync_in is brain-dead [media] [staging] lirc_imon: fix unused-but-set warnings [media] [staging] lirc_sir: fix unused-but-set warnings [media] lirc_dev: store cdev in irctl, up maxdevs [media] fintek-cir: make suspend with active IR more reliable [media] nuvoton-cir: in_use isn't actually in use, remove it [media] mceusb: plug memory leak on data transmit [media] imon: support for 0x46 0xffdc imon vfd [media] imon: fix initial panel key repeat suppression [media] ite-cir: 8709 needs to use pnp resource 2 [media] keymaps: fix table for pinnacle pctv hd devices [media] lirc_zilog: fix spinning rx thread [media] [staging] lirc_serial: allocate irq at init time [media] rc: fix ghost keypresses with certain hw [media] saa7134: fix raw IR timeout value [media] imon: auto-config ffdc 7e device [media] imon: allow either proto on unknown 0xffdc [media] rc: call input_sync after scancode reports Laurent Pinchart (2): [media] v4l: Don't access media entity after is has been destroyed [media] uvcvideo: Ignore entities for terminals with no supported format Marek Szyprowski (5): [media] MAINTAINERS: Add videobuf2 maintainers [media] media: vb2: add __GFP_NOWARN to dma-sg allocator [media] Revert "[media] v4l2: vb2: one more fix for REQBUFS()" [media] media: vb2: reset queued_count value during queue reinitialization [media] media: vb2: fix allocation failure check Ohad Ben-Cohen (1): [media] media: omap3isp: fix a potential NULL deref Sjoerd Simons (2): [media] uvcvideo: Remove buffers from the queues when freeing [media] uvcvideo: Disable the queue when failing to start Sylwester Nawrocki (7): [media] s5p-fimc: Fix possible memory leak during capture devnode registration [media] s5p-fimc: Fix V4L2_PIX_FMT_RGB565X description [media] s5p-fimc: Fix data structures documentation and cleanup debug trace [media] s5p-fimc: Fix wrong buffer size in queue_setup [media] s5p-fimc: Remove empty buf_init operation [media] s5p-fimc: Use pix_mp for the color format lookup [media] s5p-fimc: Update copyright notices Vaibhav Hiremath (2): [media] OMAP_VOUT: Change hardcoded device node number to -1 [media] omap_vout: Added check in reqbuf & mmap for buf_size allocation Vladimir Pantelic (1): [media] OMAP_VOUTLIB: Fix wrong resizer calculation MAINTAINERS|9 ++ drivers/media/rc/fintek-cir.c |5 + drivers/media/rc/imon.c| 19 +++- drivers/media/rc/ir-raw.c |4 +- drivers/media/rc/ite-cir.c | 12 ++- drivers/media/rc/ite-cir.h |3 + drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c | 58 - drivers/media/rc/lirc_dev.c| 37 -- drivers/media/rc/mceusb.c | 80 ++--- drivers/media/rc/nuvoton-cir.c |2 - drivers/media/rc/nuvoton-cir.h |1 - drivers/media/rc/rc-main.c | 48 drivers/media/video/m5mols/m5mols.h| 57 +- drivers/media/video/m5mols/m5mols_capture.c| 22 ++-- drivers/media/video/m5mols/m5mols_controls.c |6 +- drivers/media/video/m5mols/m5mols_core.c | 144 ++ drivers/media/video/m5mols/m5mols_reg.h| 21 +++- drivers/media/video/mx1_camera.c | 10 +- drivers/media/video/omap/omap_vout.c
RE: [PATCH 6/8] drivers: add Contiguous Memory Allocator
Hello, On Wednesday, July 06, 2011 4:09 PM Arnd Bergmann wrote: > On Wednesday 06 July 2011, Marek Szyprowski wrote: > > The only problem that might need to be resolved is GFP_ATOMIC allocation > > (updating page properties probably requires some locking), but it can be > > served from a special area which is created on boot without low-memory > > mapping at all. None sane driver will call dma_alloc_coherent(GFP_ATOMIC) > > for large buffers anyway. > > Would it be easier to start with a version that only allocated from memory > without a low-memory mapping at first? > > This would be similar to the approach that Russell's fix for the regular > dma_alloc_coherent has taken, except that you need to also allow the memory > to be used as highmem user pages. > > Maybe you can simply adapt the default location of the contiguous memory > are like this: > - make CONFIG_CMA depend on CONFIG_HIGHMEM on ARM, at compile time > - if ZONE_HIGHMEM exist during boot, put the CMA area in there > - otherwise, put the CMA area at the top end of lowmem, and change > the zone sizes so ZONE_HIGHMEM stretches over all of the CMA memory. This will not solve our problems. We need CMA also to create at least one device private area that for sure will be in low memory (video codec). I will rewrite ARM dma-mapping & CMA integration patch basing on the latest ARM for-next patches and add proof-of-concept of the solution presented in my previous mail (2-level page tables and unmapping pages from low-mem). Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wednesday 06 July 2011, Nicolas Pitre wrote: > On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: > > > Another issue is that when a platform has restricted DMA regions, > > they typically don't fall into the highmem zone. As the dmabounce > > code allocates from the DMA coherent allocator to provide it with > > guaranteed DMA-able memory, that would be rather inconvenient. > > Do we encounter this in practice i.e. do those platforms requiring large > contiguous allocations motivating this work have such DMA restrictions? You can probably find one or two of those, but we don't have to optimize for that case. I would at least expect the maximum size of the allocation to be smaller than the DMA limit for these, and consequently mandate that they define a sufficiently large CONSISTENT_DMA_SIZE for the crazy devices, or possibly add a hack to unmap some low memory and call dma_declare_coherent_memory() for the device. 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 3.1] TV driver for Samsung S5P platform
Hello Mauro, The following changes since commit 66ef90675ad5e45717ff84e4a106c0d22e690803: [media] DocBook/v4l: Document the new system-wide version behavior (2011-06-29 17:45:31 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p-tv-for-mauro-no59_94 Tomasz Stanislawski (7): v4l: add g_tvnorms_output callback to V4L2 subdev v4l: add g_dv_preset callback to V4L2 subdev v4l: add g_std_output callback to V4L2 subdev v4l: fix v4l_fill_dv_preset_info function v4l: s5p-tv: add drivers for HDMI on Samsung S5P platform v4l: s5p-tv: add SDO driver for Samsung S5P platform v4l: s5p-tv: add TV Mixer driver for Samsung S5P platform drivers/media/video/Kconfig |2 + drivers/media/video/Makefile |1 + drivers/media/video/s5p-tv/Kconfig | 76 ++ drivers/media/video/s5p-tv/Makefile | 17 + drivers/media/video/s5p-tv/hdmi_drv.c| 1042 ++ drivers/media/video/s5p-tv/hdmiphy_drv.c | 188 + drivers/media/video/s5p-tv/mixer.h | 354 + drivers/media/video/s5p-tv/mixer_drv.c | 487 drivers/media/video/s5p-tv/mixer_grp_layer.c | 185 + drivers/media/video/s5p-tv/mixer_reg.c | 541 + drivers/media/video/s5p-tv/mixer_video.c | 1006 + drivers/media/video/s5p-tv/mixer_vp_layer.c | 211 ++ drivers/media/video/s5p-tv/regs-hdmi.h | 141 drivers/media/video/s5p-tv/regs-mixer.h | 121 +++ drivers/media/video/s5p-tv/regs-sdo.h| 63 ++ drivers/media/video/s5p-tv/regs-vp.h | 88 +++ drivers/media/video/s5p-tv/sdo_drv.c | 479 drivers/media/video/v4l2-common.c|2 + include/media/v4l2-subdev.h | 12 + 19 files changed, 5016 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5p-tv/Kconfig create mode 100644 drivers/media/video/s5p-tv/Makefile create mode 100644 drivers/media/video/s5p-tv/hdmi_drv.c create mode 100644 drivers/media/video/s5p-tv/hdmiphy_drv.c create mode 100644 drivers/media/video/s5p-tv/mixer.h create mode 100644 drivers/media/video/s5p-tv/mixer_drv.c create mode 100644 drivers/media/video/s5p-tv/mixer_grp_layer.c create mode 100644 drivers/media/video/s5p-tv/mixer_reg.c create mode 100644 drivers/media/video/s5p-tv/mixer_video.c create mode 100644 drivers/media/video/s5p-tv/mixer_vp_layer.c create mode 100644 drivers/media/video/s5p-tv/regs-hdmi.h create mode 100644 drivers/media/video/s5p-tv/regs-mixer.h create mode 100644 drivers/media/video/s5p-tv/regs-sdo.h create mode 100644 drivers/media/video/s5p-tv/regs-vp.h create mode 100644 drivers/media/video/s5p-tv/sdo_drv.c -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.1] MFC Driver and necessary v4l2 framework changes
Hi Mauro, Recently I have send the MFC 5.1 driver v10 with necessary v4l2 patches. The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung mfc-for-Mauro Kamil Debski (4): v4l: add fourcc definitions for compressed formats. v4l: add control definitions for codec devices. v4l2-ctrl: add codec controls support to the control framework MFC: Add MFC 5.1 V4L2 driver Documentation/DocBook/media/v4l/controls.xml | 976 ++- Documentation/DocBook/media/v4l/pixfmt.xml | 47 +- drivers/media/video/Kconfig |8 + drivers/media/video/Makefile |1 + drivers/media/video/s5p-mfc/Makefile |5 + drivers/media/video/s5p-mfc/regs-mfc.h | 413 ++ drivers/media/video/s5p-mfc/s5p_mfc.c| 1274 ++ drivers/media/video/s5p-mfc/s5p_mfc_cmd.c| 120 ++ drivers/media/video/s5p-mfc/s5p_mfc_cmd.h| 30 + drivers/media/video/s5p-mfc/s5p_mfc_common.h | 572 drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 343 + drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h | 29 + drivers/media/video/s5p-mfc/s5p_mfc_debug.h | 48 + drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 1036 +++ drivers/media/video/s5p-mfc/s5p_mfc_dec.h| 23 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 1829 ++ drivers/media/video/s5p-mfc/s5p_mfc_enc.h| 23 + drivers/media/video/s5p-mfc/s5p_mfc_intr.c | 92 ++ drivers/media/video/s5p-mfc/s5p_mfc_intr.h | 26 + drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 1397 drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 91 ++ drivers/media/video/s5p-mfc/s5p_mfc_pm.c | 117 ++ drivers/media/video/s5p-mfc/s5p_mfc_pm.h | 24 + drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 47 + drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 91 ++ drivers/media/video/v4l2-ctrls.c | 197 +++- include/linux/videodev2.h| 186 +++- 27 files changed, 9032 insertions(+), 13 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/Makefile create mode 100644 drivers/media/video/s5p-mfc/regs-mfc.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_common.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_debug.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_dec.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_dec.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_enc.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_enc.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_pm.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_pm.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.h Thanks, Kamil Debski -- 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 for v3.1-rc7] media fixes
Em 06-07-2011 11:55, Mauro Carvalho Chehab escreveu: > Hi Linus, > > Please pull from: > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git > v4l_for_linus > > For a series of bug fixes: > - mx1-camera were using an uninitialized variable; > - pwc issues at USB disconnect; > - several mceusb and lirc fixes; > - some OOPSes fixes at uvc driver; > - some videobuf2 fixes; > - some omap1 camera fixes; > - m5mols/s5p-fimc fixes (this is a driver added at 3.0 merge window); > > Thanks! > Mauro > Linus, In time: There will be a small conflict when applying over 3.0-rc6: $ git diff diff --cc MAINTAINERS index ae563fa,63be58b..000 --- a/MAINTAINERS +++ b/MAINTAINERS @@@ -6733,6 -6723,7 +6733,10 @@@ F: fs/fat VIDEOBUF2 FRAMEWORK M:Pawel Osciak M:Marek Szyprowski ++<<< HEAD ++=== + M:Kyungmin Park ++>>> 98c32bcded0e249fd48726930ae9f393e0e318b4 L:linux-media@vger.kernel.org S:Maintained F:drivers/media/video/videobuf2-* The right conflict resolution is to add Kyugmin's name as one of the VB2 maintainers. Thanks, 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: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, Jul 06, 2011 at 04:56:23PM +0200, Marek Szyprowski wrote: > This will not solve our problems. We need CMA also to create at least one > device private area that for sure will be in low memory (video codec). You make these statements but you don't say why. Can you please explain why the video codec needs low memory - does it have a restricted number of memory address bits which it can manipulate? -- 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 6/8] drivers: add Contiguous Memory Allocator
Hello, On Wednesday, July 06, 2011 5:37 PM Russell King - ARM Linux wrote: > On Wed, Jul 06, 2011 at 04:56:23PM +0200, Marek Szyprowski wrote: > > This will not solve our problems. We need CMA also to create at least one > > device private area that for sure will be in low memory (video codec). > > You make these statements but you don't say why. Can you please > explain why the video codec needs low memory - does it have a > restricted number of memory address bits which it can manipulate? Nope, it only needs to put some type of memory buffers in first bank (effectively in 3000-34ff area) and the others in the second bank (4000-57ff area). The values are given for Samsung GONI board. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, Jul 06, 2011 at 04:51:49PM +0200, Arnd Bergmann wrote: > On Wednesday 06 July 2011, Russell King - ARM Linux wrote: > > On Wed, Jul 06, 2011 at 04:09:29PM +0200, Arnd Bergmann wrote: > > > Maybe you can simply adapt the default location of the contiguous memory > > > are like this: > > > - make CONFIG_CMA depend on CONFIG_HIGHMEM on ARM, at compile time > > > - if ZONE_HIGHMEM exist during boot, put the CMA area in there > > > - otherwise, put the CMA area at the top end of lowmem, and change > > > the zone sizes so ZONE_HIGHMEM stretches over all of the CMA memory. > > > > One of the requirements of the allocator is that the returned memory > > should be zero'd (because it can be exposed to userspace via ALSA > > and frame buffers.) > > > > Zeroing the memory from all the contexts which dma_alloc_coherent > > is called from is a trivial matter if its in lowmem, but highmem is > > harder. > > I don't see how. The pages get allocated from an unmapped area > or memory, mapped into the kernel address space as uncached or wc > and then cleared. This should be the same for lowmem or highmem > pages. You don't want to clear them via their uncached or WC mapping, but via their cached mapping _before_ they get their alternative mapping, and flush any cached out of that mapping - both L1 and L2 caches. For lowmem pages, that's easy. For highmem pages, they need to be individually kmap'd to zero them etc. (alloc_pages() warns on GFP_HIGHMEM + GFP_ZERO from atomic contexts - and dma_alloc_coherent must be callable from such contexts.) That may be easier now that we don't have the explicit indicies for kmap_atomics, but at that time it wasn't easily possible. > > Another issue is that when a platform has restricted DMA regions, > > they typically don't fall into the highmem zone. As the dmabounce > > code allocates from the DMA coherent allocator to provide it with > > guaranteed DMA-able memory, that would be rather inconvenient. > > True. The dmabounce code would consequently have to allocate > the memory through an internal function that avoids the > contiguous allocation area and goes straight to ZONE_DMA memory > as it does today. CMA's whole purpose for existing is to provide _dma-able_ contiguous memory for things like cameras and such like found on crippled non- scatter-gather hardware. If that memory is not DMA-able what's the point? -- 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
-EFAULT error code at firedtv driver
Hi Stefan, I'm validating if all drivers are behaving equally with respect to the error codes returned to userspace, and double-checking with the API. On almost all places, -EFAULT code is used only to indicate when copy_from_user/copy_to_user fails. However, firedtv uses a lot of -EFAULT, where it seems to me that other error codes should be used instead (like -EIO for bus transfer errors and -EINVAL/-ERANGE for invalid/out of range parameters). I'll be posting soon a series of patches fixing the error codes on the other places, but, as I don't know how do you use -EFAULT inside the firewire core, I prefer to not touch at firedtv. Could you please take a look on it? Thanks! 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: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, 06 Jul 2011 18:05:00 +0200, Christoph Lameter wrote: ZONE_DMA is a zone for memory of legacy (crippled) devices that cannot DMA into all of memory (and so is ZONE_DMA32). Memory from ZONE_NORMAL can be used for DMA as well and a fully capable device would be expected to handle any memory in the system for DMA transfers. "guaranteed" dmaable memory? DMA abilities are device specific. Well maybe you can call ZONE_DMA memory to be guaranteed if you guarantee that any device must at mininum be able to perform DMA into ZONE_DMA memory. But there may not be much of that memory around so you would want to limit the use of that scarce resource. As pointed in Marek's other mail, this reasoning is not helping in any way. In case of video codec on various Samsung devices (and from some other threads this is not limited to Samsung), the codec needs separate buffers in separate memory banks. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: > > > they typically don't fall into the highmem zone. As the dmabounce > > > code allocates from the DMA coherent allocator to provide it with > > > guaranteed DMA-able memory, that would be rather inconvenient. > > > > True. The dmabounce code would consequently have to allocate > > the memory through an internal function that avoids the > > contiguous allocation area and goes straight to ZONE_DMA memory > > as it does today. > > CMA's whole purpose for existing is to provide _dma-able_ contiguous > memory for things like cameras and such like found on crippled non- > scatter-gather hardware. If that memory is not DMA-able what's the > point? ZONE_DMA is a zone for memory of legacy (crippled) devices that cannot DMA into all of memory (and so is ZONE_DMA32). Memory from ZONE_NORMAL can be used for DMA as well and a fully capable device would be expected to handle any memory in the system for DMA transfers. "guaranteed" dmaable memory? DMA abilities are device specific. Well maybe you can call ZONE_DMA memory to be guaranteed if you guarantee that any device must at mininum be able to perform DMA into ZONE_DMA memory. But there may not be much of that memory around so you would want to limit the use of that scarce resource. -- 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 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011, Michal Nazarewicz wrote: > On Wed, 06 Jul 2011 18:05:00 +0200, Christoph Lameter wrote: > > ZONE_DMA is a zone for memory of legacy (crippled) devices that cannot DMA > > into all of memory (and so is ZONE_DMA32). Memory from ZONE_NORMAL > > can be used for DMA as well and a fully capable device would be expected > > to handle any memory in the system for DMA transfers. > > > > "guaranteed" dmaable memory? DMA abilities are device specific. Well maybe > > you can call ZONE_DMA memory to be guaranteed if you guarantee > > that any device must at mininum be able to perform DMA into ZONE_DMA > > memory. But there may not be much of that memory around so you would > > want to limit the use of that scarce resource. > > As pointed in Marek's other mail, this reasoning is not helping in any > way. In case of video codec on various Samsung devices (and from some > other threads this is not limited to Samsung), the codec needs separate > buffers in separate memory banks. What I described is the basic memory architecture of Linux. I am not that familiar with ARM and the issue discussed here. Only got involved because ZONE_DMA was mentioned. The nature of ZONE_DMA is often misunderstood. The allocation of the memory banks for the Samsung devices has to fit somehow into one of these zones. Its probably best to put the memory banks into ZONE_NORMAL and not have any dependency on ZONE_DMA at all. -- 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: omap3isp: known causes of "CCDC won't become idle!
On 07/05/11 17:35, Jonathan Cameron wrote: > On 07/05/11 16:22, Jonathan Cameron wrote: >> On 07/05/11 16:02, Laurent Pinchart wrote: >>> On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: > On 07/05/11 13:19, Sakari Ailus wrote: >> On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: >>> Hi Laurent, >>> >>> I'm just trying to get an mt9v034 sensor working on a beagle xm. >>> Everything more or less works, except that after a random number >>> of frames of capture, I tend to get won't become idle messages >>> and the vd0 and vd1 interrupts tend to turn up at same time. >>> >>> I was just wondering if there are any known issues with the ccdc >>> driver / silicon that might explain this? >>> >>> I also note that it appears to be impossible to disable >>> HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling >>> support >>> >>> despite the datasheet claiming this can be done. Is this a known >>> issue? >> >> The same interrupt may be used to produce an interrupt per horizontal >> sync but the driver doesn't use that. I remember of a case where the >> two sync signals had enough crosstalk to cause vertical sync interrupt >> per every horizontal sync. (It's been discussed on this list.) This >> might not be the case here, though: you should be flooded with HS_VS >> interrupts. > > As far as I can tell, the driver doesn't use either interrupt (except to > pass it up as an event). Hence I was trying to mask it purely to cut > down on the interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. >>> >>> We actually use the VD0 and VD1 interrupts for that, not the HS_VS >>> interrupt. > On that note, the interrupt was being disabled, just not it's value in the > register. What I was actually seeing was it combined with one of the others. > >>> >> The VD* counters are counting and interrupts are produced (AFAIR) even >> if the CCDC is disabled. > > Oh goody... > >> Once the CCDC starts receiving a frame, it becomes busy, and becomes >> idle only when it has received the full frame. For this reason it's >> important that the full frame is actually received by the CCDC, >> otherwise this is due to happen when the CCDC is being stopped at the >> end of the stream. > > Fair enough. Is there any software reason why it might think it hasn't > received the whole frame? Obviously it could in theory be a hardware > issue, but it's a bit odd that it can reliably do a certain number of > frames before falling over. Others than those which Laurent already pointed out, one which crosses my mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does mention it. It _may_ have the effect that one line of input is missed by the VD* counters. Thus the VD* counters might never reach the expected value --- the last line of the frame. >>> >>> I would first try to increase vertical blanking to see if it helps. >> Have done. No luck as yet. This sensor mt9v034 annoyingly starts live. >> Right now this means I get two frames with very short vblank (10% ratio, at >> 60fps, >> so sub 2 microseonds.) Whilst the failure seems to be at a later time, I'd >> obviously like to get rid of these. > Hmm. Via a bit of reordering of writes and a temporary disable, it now does > one frame, > then about a 100ms pause, then continues with 50ms blanking periods, vs, > about 18ms of > data transfer. Still running into what looks like the same issue with the > ccdc getting > wedged... > > Having introduced some debugging into the isr I get: > > 55.123840] power on called > [ 55.135528] interrupt 2147483648 > [ 55.139038] interrupt 2147483648 > [ 55.142578] interrupt 2147483648 > [ 55.145965] interrupt 2147483648 > [ 55.149383] interrupt 2147483648 > [ 55.152770] interrupt 2147483648 > [ 55.156188] interrupt 2147483648 > [ 55.159576] interrupt 2147483648 > [ 55.162994] interrupt 2147483648 > [ 55.181854] end of set power > [ 55.241821] get format called > [ 55.245025] get pad format > [ 55.248138] in > [ 55.249877] get format called > [ 55.252990] get pad format > [ 55.256195] on > [ 55.257904] s_stream called > [ 55.260833] set params called > [ 55.267944] stream enable attempted > [ 55.282257] interrupt 2147483648 > [ 55.302429] interrupt 512 > [ 55.312408] interrupt 256 > [ 55.385864] interrupt 2147483648 > [ 55.406005] interrupt 512 > [ 55.415985] interrupt 256 > [ 55.492401] interrupt 2147483648 > [ 55.512603] interrupt 512 > [ 55.522583] interrupt 256 > [ 55.599029] interrupt 2147483648 > [ 55.619201] interrupt 512 > [ 55.629180] interrupt 256 > [ 55.705627] interrupt 2147483648 > [ 55.725738] interrupt 512
Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wednesday 06 July 2011, Russell King - ARM Linux wrote: > On Wed, Jul 06, 2011 at 04:51:49PM +0200, Arnd Bergmann wrote: > > On Wednesday 06 July 2011, Russell King - ARM Linux wrote: > > > > I don't see how. The pages get allocated from an unmapped area > > or memory, mapped into the kernel address space as uncached or wc > > and then cleared. This should be the same for lowmem or highmem > > pages. > > You don't want to clear them via their uncached or WC mapping, but via > their cached mapping _before_ they get their alternative mapping, and > flush any cached out of that mapping - both L1 and L2 caches. But there can't be any other mapping, which is the whole point of the exercise to use highmem. Quoting from the new dma_alloc_area() function: c = arm_vmregion_alloc(&area->vm, align, size, gfp & ~(__GFP_DMA | __GFP_HIGHMEM)); if (!c) return NULL; memset((void *)c->vm_start, 0, size); area->vm here points to an uncached location, which means that we already zero the data through the uncached mapping. I don't see how it's getting worse than it is already. > > > Another issue is that when a platform has restricted DMA regions, > > > they typically don't fall into the highmem zone. As the dmabounce > > > code allocates from the DMA coherent allocator to provide it with > > > guaranteed DMA-able memory, that would be rather inconvenient. > > > > True. The dmabounce code would consequently have to allocate > > the memory through an internal function that avoids the > > contiguous allocation area and goes straight to ZONE_DMA memory > > as it does today. > > CMA's whole purpose for existing is to provide _dma-able_ contiguous > memory for things like cameras and such like found on crippled non- > scatter-gather hardware. If that memory is not DMA-able what's the > point? I mean not any ZONE_DMA memory, but the memory backing coherent_areas[], which is by definition DMA-able from any device and is what is currently being used for the purpose. 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: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, Jul 06, 2011 at 11:05:00AM -0500, Christoph Lameter wrote: > On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: > > > > > they typically don't fall into the highmem zone. As the dmabounce > > > > code allocates from the DMA coherent allocator to provide it with > > > > guaranteed DMA-able memory, that would be rather inconvenient. > > > > > > True. The dmabounce code would consequently have to allocate > > > the memory through an internal function that avoids the > > > contiguous allocation area and goes straight to ZONE_DMA memory > > > as it does today. > > > > CMA's whole purpose for existing is to provide _dma-able_ contiguous > > memory for things like cameras and such like found on crippled non- > > scatter-gather hardware. If that memory is not DMA-able what's the > > point? > > ZONE_DMA is a zone for memory of legacy (crippled) devices that cannot DMA > into all of memory (and so is ZONE_DMA32). Memory from ZONE_NORMAL can be > used for DMA as well and a fully capable device would be expected to > handle any memory in the system for DMA transfers. > > "guaranteed" dmaable memory? DMA abilities are device specific. Well maybe > you can call ZONE_DMA memory to be guaranteed if you guarantee that any > device must at mininum be able to perform DMA into ZONE_DMA memory. But > there may not be much of that memory around so you would want to limit > the use of that scarce resource. Precisely, which is what ZONE_DMA is all about. I *have* been a Linux kernel hacker for the last 18 years and do know these things, especially as ARM has had various issues with DMA memory limitations over those years - and have successfully had platforms working reliably given that and ZONE_DMA. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] s5p-csis: Enable v4l subdev device node
Set v4l2_subdev flags for a host driver to create a sub-device node for the driver so the subdev can be directly configured by applications. Signed-off-by: Kyungmin Park Signed-off-by: Sylwester Nawrocki --- drivers/media/video/s5p-fimc/mipi-csis.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c b/drivers/media/video/s5p-fimc/mipi-csis.c index 5b38be7..180abd6 100644 --- a/drivers/media/video/s5p-fimc/mipi-csis.c +++ b/drivers/media/video/s5p-fimc/mipi-csis.c @@ -546,6 +546,7 @@ static int __devinit s5pcsis_probe(struct platform_device *pdev) v4l2_subdev_init(&state->sd, &s5pcsis_subdev_ops); state->sd.owner = THIS_MODULE; strlcpy(state->sd.name, dev_name(&pdev->dev), sizeof(state->sd.name)); + state->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; state->csis_fmt = &s5pcsis_formats[0]; state->pads[CSIS_PAD_SINK].flags = MEDIA_PAD_FL_SINK; -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] s5p-csis: Rework of the system suspend/resume helpers
Do not resume the device during system resume if it was idle
before system suspend, as this causes resume from suspend
to RAM failures on exynos4. For this purpose runtime PM and
system sleep helpers are separated.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/mipi-csis.c | 45 --
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c
b/drivers/media/video/s5p-fimc/mipi-csis.c
index 4a529b4..5b38be7 100644
--- a/drivers/media/video/s5p-fimc/mipi-csis.c
+++ b/drivers/media/video/s5p-fimc/mipi-csis.c
@@ -561,7 +561,6 @@ static int __devinit s5pcsis_probe(struct platform_device
*pdev)
/* .. and a pointer to the subdev. */
platform_set_drvdata(pdev, &state->sd);
- state->flags = ST_SUSPENDED;
pm_runtime_enable(&pdev->dev);
return 0;
@@ -582,7 +581,7 @@ e_free:
return ret;
}
-static int s5pcsis_suspend(struct device *dev)
+static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
{
struct s5p_platform_mipi_csis *pdata = dev->platform_data;
struct platform_device *pdev = to_platform_device(dev);
@@ -607,14 +606,15 @@ static int s5pcsis_suspend(struct device *dev)
}
clk_disable(state->clock[CSIS_CLK_GATE]);
state->flags &= ~ST_POWERED;
+ if (!runtime)
+ state->flags |= ST_SUSPENDED;
}
- state->flags |= ST_SUSPENDED;
unlock:
mutex_unlock(&state->lock);
return ret ? -EAGAIN : 0;
}
-static int s5pcsis_resume(struct device *dev)
+static int s5pcsis_pm_resume(struct device *dev, bool runtime)
{
struct s5p_platform_mipi_csis *pdata = dev->platform_data;
struct platform_device *pdev = to_platform_device(dev);
@@ -626,7 +626,7 @@ static int s5pcsis_resume(struct device *dev)
__func__, state->flags);
mutex_lock(&state->lock);
- if (!(state->flags & ST_SUSPENDED))
+ if (!runtime && !(state->flags & ST_SUSPENDED))
goto unlock;
if (!(state->flags & ST_POWERED)) {
@@ -647,32 +647,34 @@ static int s5pcsis_resume(struct device *dev)
}
if (state->flags & ST_STREAMING)
s5pcsis_start_stream(state);
-
- state->flags &= ~ST_SUSPENDED;
+ if (!runtime)
+ state->flags &= ~ST_SUSPENDED;
unlock:
mutex_unlock(&state->lock);
return ret ? -EAGAIN : 0;
}
#ifdef CONFIG_PM_SLEEP
-static int s5pcsis_pm_suspend(struct device *dev)
+static int s5pcsis_suspend(struct device *dev)
{
- return s5pcsis_suspend(dev);
+ return s5pcsis_pm_suspend(dev, false);
}
-static int s5pcsis_pm_resume(struct device *dev)
+static int s5pcsis_resume(struct device *dev)
{
- int ret;
-
- ret = s5pcsis_resume(dev);
+ return s5pcsis_pm_resume(dev, false);
+}
+#endif
- if (!ret) {
- pm_runtime_disable(dev);
- ret = pm_runtime_set_active(dev);
- pm_runtime_enable(dev);
- }
+#ifdef CONFIG_PM_RUNTIME
+static int s5pcsis_runtime_suspend(struct device *dev)
+{
+ return s5pcsis_pm_suspend(dev, true);
+}
- return ret;
+static int s5pcsis_runtime_resume(struct device *dev)
+{
+ return s5pcsis_pm_resume(dev, true);
}
#endif
@@ -700,8 +702,9 @@ static int __devexit s5pcsis_remove(struct platform_device
*pdev)
}
static const struct dev_pm_ops s5pcsis_pm_ops = {
- SET_RUNTIME_PM_OPS(s5pcsis_suspend, s5pcsis_resume, NULL)
- SET_SYSTEM_SLEEP_PM_OPS(s5pcsis_pm_suspend, s5pcsis_pm_resume)
+ SET_RUNTIME_PM_OPS(s5pcsis_runtime_suspend, s5pcsis_runtime_resume,
+ NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(s5pcsis_suspend, s5pcsis_resume)
};
static struct platform_driver s5pcsis_driver = {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] s5p-csis driver updates for 3.1
The following are a few updates for s5p-csis MIPI-CSI receiver driver. I have originally missed the fact there are multiple voltages to be supplied externally for the MIPI-CSI receiver and PHY and the driver have to make sure they are all enabled at PMIC. The patch 1/3 fixes it by adding a relevant regulator supply. Patch 2/3 fixes issues with resume from suspend to memory. Finally patch 3/3 enables a device node for s5p-mipi-csis subdev as it is more flexible to control the subdev from library/application rather than doing this in the kernel. Sylwester Nawrocki (3): s5p-csis: Handle all available power supplies s5p-csis: Rework of the system suspend/resume helpers s5p-csis: Enable v4l subdev device node drivers/media/video/s5p-fimc/mipi-csis.c | 88 +- 1 files changed, 50 insertions(+), 38 deletions(-) Regards, - Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] s5p-csis: Handle all available power supplies
On the SoCs this driver is intended to support the are three
separate pins to supply the MIPI-CSIS subsystem: 1.1V or 1.2V,
1.8V and power supply for an internal PLL.
This patch adds support for two separate voltage supplies
to cover properly board configurations where PMIC requires
to configure independently each external supply of the MIPI-CSI
device. The 1.8V and PLL supply are assigned a single "vdd18"
regulator supply as it seems more reasonable than creating
separate regulator supplies for them.
Reported-by: HeungJun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/mipi-csis.c | 42 +
1 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c
b/drivers/media/video/s5p-fimc/mipi-csis.c
index ef056d6..4a529b4 100644
--- a/drivers/media/video/s5p-fimc/mipi-csis.c
+++ b/drivers/media/video/s5p-fimc/mipi-csis.c
@@ -81,6 +81,12 @@ static char *csi_clock_name[] = {
};
#define NUM_CSIS_CLOCKSARRAY_SIZE(csi_clock_name)
+static const char * const csis_supply_name[] = {
+ "vdd11", /* 1.1V or 1.2V (s5pc100) MIPI CSI suppply */
+ "vdd18", /* VDD 1.8V and MIPI CSI PLL supply */
+};
+#define CSIS_NUM_SUPPLIES ARRAY_SIZE(csis_supply_name)
+
enum {
ST_POWERED = 1,
ST_STREAMING= 2,
@@ -109,9 +115,9 @@ struct csis_state {
struct platform_device *pdev;
struct resource *regs_res;
void __iomem *regs;
+ struct regulator_bulk_data supply[CSIS_NUM_SUPPLIES];
struct clk *clock[NUM_CSIS_CLOCKS];
int irq;
- struct regulator *supply;
u32 flags;
const struct csis_pix_format *csis_fmt;
struct v4l2_mbus_framefmt format;
@@ -460,6 +466,7 @@ static int __devinit s5pcsis_probe(struct platform_device
*pdev)
struct resource *regs_res;
struct csis_state *state;
int ret = -ENOMEM;
+ int i;
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
@@ -519,13 +526,14 @@ static int __devinit s5pcsis_probe(struct platform_device
*pdev)
goto e_clkput;
}
+ for (i = 0; i < CSIS_NUM_SUPPLIES; i++)
+ state->supply[i].supply = csis_supply_name[i];
+
if (!pdata->fixed_phy_vdd) {
- state->supply = regulator_get(&pdev->dev, "vdd");
- if (IS_ERR(state->supply)) {
- ret = PTR_ERR(state->supply);
- state->supply = NULL;
+ ret = regulator_bulk_get(&pdev->dev, CSIS_NUM_SUPPLIES,
+state->supply);
+ if (ret)
goto e_clkput;
- }
}
ret = request_irq(state->irq, s5pcsis_irq_handler, 0,
@@ -561,8 +569,7 @@ static int __devinit s5pcsis_probe(struct platform_device
*pdev)
e_irqfree:
free_irq(state->irq, state);
e_regput:
- if (state->supply)
- regulator_put(state->supply);
+ regulator_bulk_free(CSIS_NUM_SUPPLIES, state->supply);
e_clkput:
clk_disable(state->clock[CSIS_CLK_MUX]);
s5pcsis_clk_put(state);
@@ -592,8 +599,9 @@ static int s5pcsis_suspend(struct device *dev)
ret = pdata->phy_enable(state->pdev, false);
if (ret)
goto unlock;
- if (state->supply) {
- ret = regulator_disable(state->supply);
+ if (!pdata->fixed_phy_vdd) {
+ ret = regulator_bulk_disable(CSIS_NUM_SUPPLIES,
+state->supply);
if (ret)
goto unlock;
}
@@ -622,16 +630,17 @@ static int s5pcsis_resume(struct device *dev)
goto unlock;
if (!(state->flags & ST_POWERED)) {
- if (state->supply)
- ret = regulator_enable(state->supply);
+ if (!pdata->fixed_phy_vdd)
+ ret = regulator_bulk_enable(CSIS_NUM_SUPPLIES,
+ state->supply);
if (ret)
goto unlock;
-
ret = pdata->phy_enable(state->pdev, true);
if (!ret) {
state->flags |= ST_POWERED;
- } else if (state->supply) {
- regulator_disable(state->supply);
+ } else if (!pdata->fixed_phy_vdd) {
+ regulator_bulk_disable(CSIS_NUM_SUPPLIES,
+ state->supply);
goto unlock;
}
clk_enable(state->clock[CSIS_CLK_GATE]);
@@ -679,8 +688,7 @@ static int __devexit s5pcsis_remove(struct platform_device
*pdev)
pm_runtime_set_suspended(&pdev->dev);
s5pcsis_clk_put(state);
- if (state->supply)
-
Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, Jul 06, 2011 at 11:19:00AM -0500, Christoph Lameter wrote: > What I described is the basic memory architecture of Linux. I am not that > familiar with ARM and the issue discussed here. Only got involved because > ZONE_DMA was mentioned. The nature of ZONE_DMA is often misunderstood. > > The allocation of the memory banks for the Samsung devices has to fit > somehow into one of these zones. Its probably best to put the memory banks > into ZONE_NORMAL and not have any dependency on ZONE_DMA at all. Let me teach you about the ARM memory management on Linux. Firstly, lets go over the structure of zones in Linux. There are three zones - ZONE_DMA, ZONE_NORMAL and ZONE_HIGHMEM. These zones are filled in that order. So, ZONE_DMA starts at zero. Following on from ZONE_DMA is ZONE_NORMAL memory, and lastly ZONE_HIGHMEM. At boot, we pass all memory over to the kernel as follows: 1. If there is no DMA zone, then we pass all low memory over as ZONE_NORMAL. 2. If there is a DMA zone, by default we pass all low memory as ZONE_DMA. This is required so drivers which use GFP_DMA can work. Platforms with restricted DMA requirements can modify that layout to move memory from ZONE_DMA into ZONE_NORMAL, thereby restricting the upper address which the kernel allocators will give for GFP_DMA allocations. 3. In either case, any high memory as ZONE_HIGHMEM if configured (or memory is truncated if not.) So, when we have (eg) a platform where only the _even_ MBs of memory are DMA-able, we have a 1MB DMA zone at the beginning of system memory, and everything else in ZONE_NORMAL. This means GFP_DMA will return either memory from the first 1MB or fail if it can't. This is the behaviour we desire. Normal allocations will come from ZONE_NORMAL _first_ and then try ZONE_DMA if there's no other alternative. This is the same desired behaviour as x86. So, ARM is no different from x86, with the exception that the 16MB DMA zone due to ISA ends up being different sizes on ARM depending on our restrictions. -- 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] firedtv: change some -EFAULT returns to more fitting error codes
Mauro Carvalho Chehab wrote:
> I'm validating if all drivers are behaving equally with respect to the
> error codes returned to userspace, and double-checking with the API.
>
> On almost all places, -EFAULT code is used only to indicate when
> copy_from_user/copy_to_user fails. However, firedtv uses a lot of
> -EFAULT, where it seems to me that other error codes should be used
> instead (like -EIO for bus transfer errors and -EINVAL/-ERANGE for
> invalid/out of range parameters).
This concerns only the CI (CAM) related code of firedtv of which I know
little. Let's just pass through the error returns of lower level I/O
code where applicable, and -EACCES (permission denied) when a seemingly
valid but negative FCP response or an unknown-to-firedtv CA message is
received.
Signed-off-by: Stefan Richter
Cc: Henrik Kurelid
---
Only tested on FireDTV-{C,T}/CI without CAM.
drivers/media/dvb/firewire/firedtv-avc.c |2
drivers/media/dvb/firewire/firedtv-ci.c | 34 +++
2 files changed, 17 insertions(+), 19 deletions(-)
Index: b/drivers/media/dvb/firewire/firedtv-avc.c
===
--- a/drivers/media/dvb/firewire/firedtv-avc.c
+++ b/drivers/media/dvb/firewire/firedtv-avc.c
@@ -1208,7 +1208,7 @@ int avc_ca_pmt(struct firedtv *fdtv, cha
if (r->response != AVC_RESPONSE_ACCEPTED) {
dev_err(fdtv->device,
"CA PMT failed with response 0x%x\n",
r->response);
- ret = -EFAULT;
+ ret = -EACCES;
}
out:
mutex_unlock(&fdtv->avc_mutex);
Index: b/drivers/media/dvb/firewire/firedtv-ci.c
===
--- a/drivers/media/dvb/firewire/firedtv-ci.c
+++ b/drivers/media/dvb/firewire/firedtv-ci.c
@@ -45,11 +45,6 @@ static int fdtv_get_ca_flags(struct fire
return flags;
}
-static int fdtv_ca_reset(struct firedtv *fdtv)
-{
- return avc_ca_reset(fdtv) ? -EFAULT : 0;
-}
-
static int fdtv_ca_get_caps(void *arg)
{
struct ca_caps *cap = arg;
@@ -65,12 +60,14 @@ static int fdtv_ca_get_slot_info(struct
{
struct firedtv_tuner_status stat;
struct ca_slot_info *slot = arg;
+ int err;
- if (avc_tuner_status(fdtv, &stat))
- return -EFAULT;
+ err = avc_tuner_status(fdtv, &stat);
+ if (err)
+ return err;
if (slot->num != 0)
- return -EFAULT;
+ return -EACCES;
slot->type = CA_CI;
slot->flags = fdtv_get_ca_flags(&stat);
@@ -81,21 +78,21 @@ static int fdtv_ca_app_info(struct fired
{
struct ca_msg *reply = arg;
- return avc_ca_app_info(fdtv, reply->msg, &reply->length) ?
-EFAULT : 0;
+ return avc_ca_app_info(fdtv, reply->msg, &reply->length);
}
static int fdtv_ca_info(struct firedtv *fdtv, void *arg)
{
struct ca_msg *reply = arg;
- return avc_ca_info(fdtv, reply->msg, &reply->length) ? -EFAULT :
0;
+ return avc_ca_info(fdtv, reply->msg, &reply->length);
}
static int fdtv_ca_get_mmi(struct firedtv *fdtv, void *arg)
{
struct ca_msg *reply = arg;
- return avc_ca_get_mmi(fdtv, reply->msg, &reply->length) ?
-EFAULT : 0;
+ return avc_ca_get_mmi(fdtv, reply->msg, &reply->length);
}
static int fdtv_ca_get_msg(struct firedtv *fdtv, void *arg)
@@ -111,14 +108,15 @@ static int fdtv_ca_get_msg(struct firedt
err = fdtv_ca_info(fdtv, arg);
break;
default:
- if (avc_tuner_status(fdtv, &stat))
- err = -EFAULT;
- else if (stat.ca_mmi == 1)
+ err = avc_tuner_status(fdtv, &stat);
+ if (err)
+ break;
+ if (stat.ca_mmi == 1)
err = fdtv_ca_get_mmi(fdtv, arg);
else {
dev_info(fdtv->device, "unhandled CA message
0x%08x\n", fdtv->ca_last_command);
- err = -EFAULT;
+ err = -EACCES;
}
}
fdtv->ca_last_command = 0;
@@ -141,7 +139,7 @@ static int fdtv_ca_pmt(struct firedtv *f
data_length = msg->msg[3];
}
- return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length) ?
-EFAULT : 0;
+ return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length);
}
static int fdtv_ca_send_msg(struct firedtv *fdtv, void *arg)
@@ -170,7 +168,7 @@ static int fdtv_ca_send_msg(struct fired
default:
dev_err(fdtv->device, "unhandled CA message 0x%08x\n",
fdtv->ca_last_command);
- err = -EFAULT;
+ err = -EACCES;
}
return err;
}
@@ -184,7 +182,7 @@ static int fdtv_ca_ioctl(struct file *fi
switch (cmd) {
case CA_RESET:
- err = fdtv_ca_reset(fdtv);
+ err = avc_ca_reset(fdtv);
br
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
Hi. I think that you could reuse lots of code with smart suspend / resume. What do you think about this DVB power saving case (about the concept, don't look at details, please): - One device has responsibility to do the power off when it can be done (mantis_core.ko) - In my case there is only one frontend tda10021.ko to take care of. - dvb_frontend.c would call fe->sleep(fe). The callback goes into mantis_core.ko. - mantis_core.ko will traverse all devices on it's responsibility, all (tda10021.ko) are idle. => suspend tda10021.ko by calling tda10021->sleep() and do additional power off things. - When dvb_frontend.c wants tuner to be woken up, mantis_core.ko does hardware resets and power on first and then resumes tda10021->init(fe). I implemented something that worked a few years ago with suspend / resume. In mantis_dvb.c's driver probe function I modified tuner_ops to enable these runtime powersaving features: + mantis->fe->ops.tuner_ops.sleep = mantis_dvb_tuner_sleep; + mantis->fe->ops.tuner_ops.init = mantis_dvb_tuner_init; That way mantis_core.ko had all needed details to do any advanced power savings I wanted. Suspend / resume worked well: During resume there was only a glitch at the picture and sound and the TV channel watching continued. tda10021 (was cu1216 at that time) restored the original TV channel. It took DVB FE_LOCK during resume. Suspended DMA transfer was recovered before returning into userspace. So I think that you need a single device (mantis_core.ko) that can see the whole picture, in what states the subdevices are: can you touch the power button?. With DVB this is easy because dvb_frontend.c tells when a frontend is idle and when it is not. The similar idea of some kind of watchdog that is able to track when a single device (frontend) is used and when it is not used, would be sufficient. The topmost driver (mantis_core.ko in my case) would then be responsible to track multiple frontends (subdevices), if they all are idle or not, with suitable mutex protection. Then this driver could easilly suspend/resume these subdevices and press power switch when necessary. So the clash between DVB and V4L devices would be solved: Both DVB and V4L calls a (different) sleep() function on mantis_core.ko mantis_core.ko will turn power off when both "frontends" are sleeping. If only one sleeps, the one can be put to sleep or suspended, but power button can't be touched. What do you think? I did this easy case mantis_core.ko solution in about Summer 2007. It needs a rewrite and testing, if I take it from the dust. Regards, Marko Ristola 16.06.2011 15:51, Devin Heitmueller wrote: > On Thu, Jun 16, 2011 at 7:14 AM, Mauro Carvalho Chehab > wrote: >> One possible logic that would solve the scripting would be to use a watchdog >> to monitor ioctl activities. If not used for a while, it could send a s_power >> to put the device to sleep, but this may not solve all our problems. >> >> So, I agree with Devin: we need to add an option to explicitly control the >> power management logic of the device, having 3 modes of operation: >>POWER_AUTO - use the watchdogs to poweroff >>POWER_ON - explicitly powers on whatever subdevices are needed in >> order to make the V4L ready to stream; >>POWER_OFF - Put all subdevices to power-off if they support it. >> >> After implementing such logic, and keeping the default as POWER_ON, we may >> announce that the default will change to POWER_AUTO, and give some time for >> userspace apps/scripts that need to use a different mode to change their >> behaviour. That means that, for example, "radio -qf" will need to change to >> POWER_ON mode, and "radio -m" should call POWER_OFF. > > I've considered this idea before, and it's not bad in theory. The one > thing you will definitely have to watch out for is causing a race > between DVB and V4L for hybrid tuners. In other words, you can have a > user switching from analog to digital and you don't want the tuner to > get powered down a few seconds after they started streaming video from > DVB. > > Any such solution would have to take the above into account. We've > got a history of race conditions like this and I definitely don't want > to see a new one introduced. > > Devin > -- 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 RFCv3 15/17] [media] DocBook/dvb: Use generic descriptions for the video API
While here, removes the bogus EINTERNAL error codes. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/dvb/video.xml b/Documentation/DocBook/media/dvb/video.xml index 0b1b662..25fb823 100644 --- a/Documentation/DocBook/media/dvb/video.xml +++ b/Documentation/DocBook/media/dvb/video.xml @@ -593,22 +593,6 @@ role="subsection">VIDEO_STOP &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - VIDEO_PLAY @@ -645,22 +629,6 @@ role="subsection">VIDEO_PLAY &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - VIDEO_FREEZE @@ -701,22 +669,6 @@ role="subsection">VIDEO_FREEZE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - VIDEO_CONTINUE @@ -753,22 +705,6 @@ role="subsection">VIDEO_CONTINUE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - VIDEO_SELECT_SOURCE @@ -815,22 +751,6 @@ role="subsection">VIDEO_SELECT_SOURCE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - VIDEO_SET_BLANK @@ -880,29 +800,6 @@ role="subsection">VIDEO_SET_BLANK &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - -EINVAL - -Illegal input parameter - - VIDEO_GET_STATUS @@ -947,29 +844,6 @@ role="subsection">VIDEO_GET_STATUS &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error, possibly in the communication with the - DVB subsystem. - - -EFAULT - -status points to invalid address - - VIDEO_GET_EVENT @@ -1025,20 +899,6 @@ role="subsection">VIDEO_GET_EVENT &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - -EFAULT - -ev points to invalid address - - EWOULDBLOCK @@ -1050,11 +910,6 @@ role="subsection">VIDEO_GET_EVENT EOVERFLOW - - - Overflow in event queue - one or more events were lost. @@ -1105,28 +960,6 @@ role="subsection">VIDEO_SET_DISPLAY_FORMAT &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error. - - -EINVAL - -Illegal parameter format. - - VIDEO_STILLPICTURE @@ -1174,28 +1007,6 @@ role="subsection">VIDEO_STILLPICTURE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error. - - -EFAULT - -sp points to an invalid iframe. - - VIDEO_FAST_FORWARD @@ -1242,32 +1053,11 @@ role="subsection">VIDEO_FAST_FORWARD &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error. - - EPERM Mode VIDEO_SOURCE_MEMORY not selected. - -EINVAL - -Illegal parameter format. - VIDEO_SLOWMOTION &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error. - - EPERM Mode VIDEO_SOURCE_MEMORY not selected. - -EINVAL - -Illegal parameter format. - VIDEO_GET_CAPABILITIES &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EFAULT - -cap points to an invalid iframe. - - VIDEO_SET_ID @@ -1449,20 +1203,6 @@ role="subsection">VIDEO_SET_ID &return-value-dvb; -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - EINVAL @@ -1504,14 +1244,6 @@ role="subsection">VIDEO_CLEAR_BUFFER &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - VIDEO_SET_STREAMTYPE @@ -1557,21 +1289,6 @@ role="subsection">VIDEO_SET_STREAMTYPE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINVAL - -type is not a valid or supported stream type. - - VIDEO_SET_FORMAT @@ -1619,13 +1336,6 @@ role="subsection">VIDEO_SET_FORMAT &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1680,13 +1390,6 @@ role="subsection">VIDEO_SET_SYSTEM &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1737,21 +1440,6 @@ role="subsection">VIDEO_SET_HIGHLIGHT &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINVAL - -input is not a valid highlight setting. - - VIDEO_SET_SPU @@ -1799,13 +1487,6 @@ role="subsection">VIDEO_SET_SPU &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1859,13 +1540,6 @@ role="subsection">VIDEO_SET_SPU_PALETTE &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1920,13 +1594,6 @@ role="subse
[PATCH RFCv3 14/17] [media] DocBook/dvb: Use generic descriptions for the frontend API
Move generic stuff into gen-errors.xml, and remove them from
DVB API. While here, removes two bogus error codes that aren't
supported or used on Linux: EINTERNAL and ENOSIGNAL.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 33274bc..207e1a5 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -82,15 +82,6 @@ struct dtv_properties {
&return-value-dvb;
- EINVAL
- Invalid parameter(s) received or number of
parameters out of the range.
-
- ENOMEM
- Out of memory.
-
- EFAULT
- Failure while copying data from/to
userspace.
-
EOPNOTSUPP
Property type not supported.
@@ -139,15 +130,6 @@ struct dtv_properties {
&return-value-dvb;
- EINVAL
- Invalid parameter(s) received or number of
parameters out of the range.
-
- ENOMEM
- Out of memory.
-
- EFAULT
- Failure while copying data from/to
userspace.
-
EOPNOTSUPP
Property type not supported.
diff --git a/Documentation/DocBook/media/dvb/frontend.xml
b/Documentation/DocBook/media/dvb/frontend.xml
index c5a5cb4..61407ea 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -575,7 +575,7 @@ typedef enum fe_hierarchy {
File descriptor returned by a previous call to open().
-&return-value-dvb;
+RETURN VALUE
EBADF
@@ -692,37 +692,8 @@ typedef enum fe_hierarchy {
The bit error rate is stored into *ber.
+
&return-value-dvb;
-
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-ber points to invalid address.
-
-
-ENOSIGNAL
-
-There is no signal, thus no meaningful bit error rate. Also
- returned if the front-end is not turned on.
-
-
-ENOSYS
-
-Function not available for this device.
-
-
@@ -770,36 +741,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-snr points to invalid address.
-
-
-ENOSIGNAL
-
-There is no signal, thus no meaningful signal strength
- value. Also returned if front-end is not turned on.
-
-
-ENOSYS
-
-Function not available for this device.
-
-
@@ -846,37 +787,8 @@ typedef enum fe_hierarchy {
The signal strength value is stored into *strength.
+
&return-value-dvb;
-
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-status points to invalid address.
-
-
-ENOSIGNAL
-
-There is no signal, thus no meaningful signal strength
- value. Also returned if front-end is not turned on.
-
-
-ENOSYS
-
-Function not available for this device.
-
-
@@ -930,29 +842,8 @@ typedef enum fe_hierarchy {
so far.
+
&return-value-dvb;
-
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-ublocks points to invalid address.
-
-
-ENOSYS
-
-Function not available for this device.
-
-
@@ -1005,23 +896,10 @@ typedef enum fe_hierarchy {
Points to parameters for tuning operation.
+
&return-value-dvb;
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-p points to invalid address.
-
-
EINVAL
@@ -1078,23 +956,8 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-p points to invalid address.
-
-
EINVAL
@@ -1181,20 +1044,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-ev points to invalid address.
-
-
EWOULDBLOCK
@@ -1206,11 +1055,6 @@ typedef enum fe_hierarchy {
EOVERFLOW
-
-
-
Overflow in event queue - one or more events were lost.
@@ -1264,21 +1108,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid open file descriptor.
-
-
-EFAULT
-
-info points to invalid address.
-
-
@@ -1322,28 +1151,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EPERM
-
-Permission denied (needs read/write access).
-
-
-EINTERNAL
-
-Internal error in the device driver.
-
-
@@ -1394,43 +1201,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EFAULT
-
-Seq points to an invalid address.
-
-
-EINVAL
-
-The data structure referred to by seq is invalid in some
- way.
-
-
-EPERM
-
-Permission denied (needs read/write access).
-
-
-EINTERNAL
-
-Internal error in the device driver.
-
-
@@ -1481,43 +1251,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EFAULT
-
-Seq points to an invalid address.
-
-
-EINVAL
-
-The data structure referred to by seq is invalid in some
- way.
-
-
-EPERM
-
-Permission denied (needs read/write access).
-
-
-EINTERNAL
-
-Internal error in the device driver.
-
-
@@ -1566,43 +1299,6 @@ typedef enum fe_hierarchy {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EFAULT
-
-Seq p
[PATCH RFCv3 02/17] [media] DocBook: Use the generic ioctl error codes for all V4L ioctl's
Be sure that all VIDIOC_* ioctl are using the return error macro, and aren't specifying generic error codes internally. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 1efc688..6ef476a 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -10,7 +10,24 @@ The ioctl can't be handled because the device is busy. This is typically return while device is streaming, and an ioctl tried to change something that would affect the stream, or would require the - usage of a hardware resource that was already allocated. + usage of a hardware resource that was already allocated. The ioctl + must not be retried without performing another action to fix the + problem first (typically: stop the stream before retrying). + + + EINVAL + The ioctl is not supported by the driver, actually meaning that + the required functionality is not available. + + + ENOMEM + There's not enough memory to handle the desired operation. + + + ENOSPC + On USB devices, the stream ioctl's can return this error meaning + that this request would overcommit the usb bandwidth reserved + for periodic transfers (up to 80% of the USB bandwidth). diff --git a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml index 816e90e..b4f2f25 100644 --- a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml @@ -156,19 +156,10 @@ on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" --> EINVAL The &v4l2-cropcap; type is -invalid or the ioctl is not supported. This is not permitted for -video capture, output and overlay devices, which must support -VIDIOC_CROPCAP. +invalid. This is not permitted for video capture, output and overlay devices, +which must support VIDIOC_CROPCAP. - - diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml index 4a09e20..4ecd966 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml @@ -258,18 +258,9 @@ could not identify it. EINVAL - The driver does not support this ioctl, or the -match_type is invalid. + The match_type is invalid. - - diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml index 980c7f3..a44aebc 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml @@ -247,15 +247,6 @@ register. - EINVAL - - The driver does not support this ioctl, or the kernel -was not compiled with the CONFIG_VIDEO_ADV_DEBUG -option, or the match_type is invalid, or the -selected chip or register does not exist. - - - EPERM Insufficient permissions. Root privileges are required @@ -265,11 +256,3 @@ to execute these ioctls. - - diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index b8c4f76..7769642 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -136,11 +136,7 @@ + +&return-value; + - diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index b0dde94..af7f3f2 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -180,8 +180,7 @@ Pictures, rather than immediately. EINVAL - The driver does not support this ioctl, or the -cmd field is invalid. + The cmd field is invalid. @@ -194,11 +193,3 @@ the encoder was not running. - - diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml b/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml index 3c216e1..5fd72c4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml @@ -254,17 +254,6 @@ enumerated. &return-value; - -See the description section above for a list of return -values that errno can have. - - diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml b/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml index 6afa454..f7
[PATCH RFCv3 04/17] [media] DocBook/media-ioc-setup-link.xml: Remove EBUSY
The EBUSY is already described as a generic error condition, with a similar text. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml index cec97af..fc2e522 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml @@ -72,15 +72,6 @@ - EBUSY - - The link properties can't be changed because the link is - currently busy. This can be caused, for instance, by an active media - stream (audio or video) on the link. The ioctl shouldn't be retried if - no other action is performed before to fix the problem. - - - EINVAL The &media-link-desc; references a non-existing link, or the -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 06/17] [media] DocBook: Add an error code session for LIRC interface
Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml b/Documentation/DocBook/media/v4l/lirc_device_interface.xml index 0e0453f..a060f3f 100644 --- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml @@ -248,4 +248,8 @@ on working with the default settings initially. + + +&return-value; + -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 05/17] [media] DocBook: Remove V4L generic error description for ioctl()
V4L ioctl function descripton also has a generic error chapter. Remove it, as it is now obsoleted by a general, multi-API generic error descriptions. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/v4l/func-ioctl.xml b/Documentation/DocBook/media/v4l/func-ioctl.xml index b60fd37..2de64be 100644 --- a/Documentation/DocBook/media/v4l/func-ioctl.xml +++ b/Documentation/DocBook/media/v4l/func-ioctl.xml @@ -64,75 +64,9 @@ their respective function and parameters are specified in -Return Value - -On success the ioctl() function returns -0 and does not reset the -errno variable. On failure --1 is returned, when the ioctl takes an -output or read/write parameter it remains unmodified, and the -errno variable is set appropriately. See below for -possible error codes. Generic errors like EBADF -or EFAULT are not listed in the sections -discussing individual ioctl requests. -Note ioctls may return undefined error codes. Since errors -may have side effects such as a driver reset applications should -abort on unexpected errors. - - - - EBADF - - fd is not a valid open file -descriptor. - - - - EBUSY - - The property cannot be changed right now. Typically -this error code is returned when I/O is in progress or the driver -supports multiple opens and another process locked the property. - - - - EFAULT - - argp references an inaccessible -memory area. - - - - ENOTTY - - fd is not associated with a -character special device. - - - - EINVAL - - The request or the data pointed -to by argp is not valid. This is a very common -error code, see the individual ioctl requests listed in for actual causes. - - - - ENOMEM - - Not enough physical or virtual memory was available to -complete the request. - - - - ERANGE - - The application attempted to set a control with the -&VIDIOC-S-CTRL; ioctl to a value which is out of bounds. - - - +&return-value; +When an ioctl that takes an output or read/write parameter fails, +the parameter remains unmodified. diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index a7f73c9..2b50b63 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -31,7 +31,8 @@ EINVAL or ENOTTY The ioctl is not supported by the driver, actually meaning that - the required functionality is not available. + the required functionality is not available, or the file + descriptor is not for a media device. ENOMEM @@ -46,3 +47,10 @@ + +Note 1: ioctls may return other error codes. Since errors may have side +effects such as a driver reset, applications should abort on unexpected errors. + + +Note 2: Request-specific error codes are listed in the individual +requests descriptions. diff --git a/Documentation/DocBook/media/v4l/media-func-ioctl.xml b/Documentation/DocBook/media/v4l/media-func-ioctl.xml index e0ee285..39478d0 100644 --- a/Documentation/DocBook/media/v4l/media-func-ioctl.xml +++ b/Documentation/DocBook/media/v4l/media-func-ioctl.xml @@ -64,6 +64,7 @@ &return-value; + Request-specific error codes are listed in the individual requests descriptions. When an ioctl that takes an output or read/write parameter fails, -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 03/17] [media] DocBook: Use the generic error code page also for MC API
Instead of having their own generic error codes at the MC API, move its section to the generic one and be sure that all media ioctl's will point to it. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 6ef476a..a7f73c9 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -5,6 +5,11 @@ &cs-str; + + + EBADF + fd is not a valid open file descriptor. + EBUSY The ioctl can't be handled because the device is busy. This is @@ -15,7 +20,16 @@ problem first (typically: stop the stream before retrying). + EFAULT + fd is not a valid open file descriptor. + + EINVAL + One or more of the ioctl parameters are invalid. This is a widely + error code. see the individual ioctl requests for actual causes. + + + EINVAL or ENOTTY The ioctl is not supported by the driver, actually meaning that the required functionality is not available. @@ -25,7 +39,7 @@ ENOSPC - On USB devices, the stream ioctl's can return this error meaning + On USB devices, the stream ioctl's can return this error, meaning that this request would overcommit the usb bandwidth reserved for periodic transfers (up to 80% of the USB bandwidth). diff --git a/Documentation/DocBook/media/v4l/media-func-ioctl.xml b/Documentation/DocBook/media/v4l/media-func-ioctl.xml index bda8604..e0ee285 100644 --- a/Documentation/DocBook/media/v4l/media-func-ioctl.xml +++ b/Documentation/DocBook/media/v4l/media-func-ioctl.xml @@ -63,54 +63,10 @@ -Return Value - -ioctl() returns 0 on -success. On failure, -1 is returned, and the -errno variable is set appropriately. Generic error codes -are listed below, and request-specific error codes are listed in the +&return-value; +Request-specific error codes are listed in the individual requests descriptions. When an ioctl that takes an output or read/write parameter fails, the parameter remains unmodified. - - - - EBADF - - fd is not a valid open file descriptor. - - - - - EFAULT - - argp references an inaccessible memory - area. - - - - EINVAL - - The request or the data pointed to by - argp is not valid. This is a very common error - code, see the individual ioctl requests listed in - for actual causes. - - - - ENOMEM - - Insufficient kernel memory was available to complete the - request. - - - - ENOTTY - - fd is not associated with a character - special device. - - - diff --git a/Documentation/DocBook/media/v4l/media-ioc-device-info.xml b/Documentation/DocBook/media/v4l/media-ioc-device-info.xml index 1f32373..2ce5214 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-device-info.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-device-info.xml @@ -127,7 +127,6 @@ -Return value -This function doesn't return specific error codes. +&return-value; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 07/17] [media] DocBook: Add return error codes to LIRC ioctl session
Add a reference for the generic error code chapter to LIRC ioctl description. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml b/Documentation/DocBook/media/v4l/lirc_device_interface.xml index a060f3f..8d7eb6b 100644 --- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml @@ -246,10 +246,8 @@ on working with the default settings initially. - - - -&return-value; + &return-value; + -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 10/17] [media] DVB: Point to the generic error chapter
Just like the V4L, MC and LIRC API's, point to the generic error
chapter for ioctl's. This will allow moving generic error codes
to just one place inside all media API's.
A latter patch will remove the generic errors from each specific
ioctl.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/DocBook/media/dvb/audio.xml
b/Documentation/DocBook/media/dvb/audio.xml
index c27fe73..90e9b7f 100644
--- a/Documentation/DocBook/media/dvb/audio.xml
+++ b/Documentation/DocBook/media/dvb/audio.xml
@@ -220,8 +220,7 @@ and right.
(blocking mode is the default)
-ERRORS
-
+RETURN VALUE
ENODEV
@@ -279,8 +278,7 @@ and right.
File descriptor returned by a previous call to open().
-ERRORS
-
+RETURN VALUE
EBADF
@@ -335,8 +333,7 @@ and right.
Size of buf.
-ERRORS
-
+RETURN VALUE
EPERM
@@ -394,8 +391,7 @@ role="subsection">AUDIO_STOP
Equals AUDIO_STOP for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -446,8 +442,7 @@ role="subsection">AUDIO_PLAY
Equals AUDIO_PLAY for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -506,8 +501,7 @@ role="subsection">AUDIO_PAUSE
Equals AUDIO_PAUSE for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -563,8 +557,7 @@ with AUDIO_PAUSE command.
Equals AUDIO_CONTINUE for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -627,8 +620,7 @@ role="subsection">AUDIO_SELECT_SOURCE
stream.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -706,8 +698,7 @@ role="subsection">AUDIO_SET_MUTE
FALSE Audio Un-mute
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -785,8 +776,7 @@ role="subsection">AUDIO_SET_AV_SYNC
FALSE AV-sync OFF
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -868,8 +858,7 @@ role="subsection">AUDIO_SET_BYPASS_MODE
FALSE Bypass is enabled
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -937,8 +926,7 @@ role="subsection">AUDIO_CHANNEL_SELECT
stereo).
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1005,8 +993,7 @@ role="subsection">AUDIO_GET_STATUS
Returns the current state of Audio Device.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1073,8 +1060,7 @@ role="subsection">AUDIO_GET_CAPABILITIES
Returns a bit array of supported sound formats.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1132,8 +1118,7 @@ role="subsection">AUDIO_CLEAR_BUFFER
Equals AUDIO_CLEAR_BUFFER for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1196,8 +1181,7 @@ role="subsection">AUDIO_SET_ID
audio sub-stream id
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1262,8 +1246,7 @@ role="subsection">AUDIO_SET_MIXER
mixer settings.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1330,8 +1313,7 @@ role="subsection">AUDIO_SET_STREAMTYPE
stream type
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1390,8 +1372,7 @@ role="subsection">AUDIO_SET_EXT_ID
audio sub_stream_id
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1451,8 +1432,7 @@ role="subsection">AUDIO_SET_ATTRIBUTES
audio attributes according to section ??
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -1512,8 +1492,7 @@ role="subsection">AUDIO_SET_KARAOKE
karaoke settings according to section ??.
-ERRORS
-
+&return-value-dvb;
EBADF
diff --git a/Documentation/DocBook/media/dvb/ca.xml
b/Documentation/DocBook/media/dvb/ca.xml
index a6cb952..5c4adb4 100644
--- a/Documentation/DocBook/media/dvb/ca.xml
+++ b/Documentation/DocBook/media/dvb/ca.xml
@@ -158,8 +158,7 @@ typedef struct ca_pid {
(blocking mode is the default)
-ERRORS
-
+RETURN VALUE
ENODEV
@@ -217,8 +216,7 @@ typedef struct ca_pid {
File descriptor returned by a previous call to open().
-ERRORS
-
+RETURN VALUE
EBADF
diff --git a/Documentation/DocBook/media/dvb/demux.xml
b/Documentation/DocBook/media/dvb/demux.xml
index 6758739..e5058d7 100644
--- a/Documentation/DocBook/media/dvb/demux.xml
+++ b/Documentation/DocBook/media/dvb/demux.xml
@@ -239,8 +239,7 @@ typedef enum {
(blocking mode is the default)
-ERRORS
-
+RETURN VALUE
ENODEV
@@ -299,8 +298,7 @@ typedef enum {
File descriptor returned by a previous call to open().
-ERRORS
-
+RETURN VALUE
EBADF
@@ -381,8 +379,7 @@ typedef enum {
Size of buf.
-ERRORS
-
+RETURN VALUE
EWOULDBLOCK
@@ -485,8 +482,7 @@ typedef enum {
Size of buf.
-ERRORS
-
+RETURN VALUE
EWOULDBLOCK
@@ -553,8 +549,7 @@ typedef enum {
Equals DMX_START for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -619,8 +614,7 @@ typedef enum {
Equals DMX_STOP for this command.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -682,8 +676,7 @@ typedef enum {
Pointer to structure containing filter parameters.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -755,8 +748,7 @@ typedef enum {
Pointer to structure containing filter parameters.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -827,8 +819,7 @@ typedef enum {
Size of circular buffer.
-ERRORS
-
+&return-value-dvb;
EBADF
@@ -900,8 +891,7 @@ typedef enum {
Pointer to the location where the event is to be stored.
-ERRORS
-
+&return-value-dvb;
EBADF
@@
[PATCH RFCv3 12/17] [media] DocBook/demux.xml: Remove generic errors
Remove generic errors from ioctl() descriptions. For other ioctl's,
there's no generic section. So, just keep whatever is there.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/DocBook/media/dvb/demux.xml
b/Documentation/DocBook/media/dvb/demux.xml
index e5058d7..37c1790 100644
--- a/Documentation/DocBook/media/dvb/demux.xml
+++ b/Documentation/DocBook/media/dvb/demux.xml
@@ -552,13 +552,6 @@ typedef enum {
&return-value-dvb;
-EBADF
-
-fd is not a valid file descriptor.
-
-
EINVAL
@@ -615,14 +608,6 @@ typedef enum {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
@@ -677,21 +662,6 @@ typedef enum {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EINVAL
-
-Invalid argument.
-
-
@@ -751,20 +721,6 @@ typedef enum {
&return-value-dvb;
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EINVAL
-
-Invalid argument.
-
-
EBUSY
@@ -820,22 +776,6 @@ typedef enum {
&return-value-dvb;
-
-EBADF
-
-fd is not a valid file descriptor.
-
-
-ENOMEM
-
-The driver was not able to allocate a buffer of the
- requested size.
-
-
@@ -894,20 +834,6 @@ typedef enum {
&return-value-dvb;
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EFAULT
-
-ev points to an invalid address.
-
-
EWOULDBLOCK
@@ -967,20 +893,6 @@ typedef enum {
&return-value-dvb;
-EBADF
-
-fd is not a valid file descriptor.
-
-
-EFAULT
-
-stc points to an invalid address.
-
-
EINVAL
diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml
b/Documentation/DocBook/media/v4l/gen-errors.xml
index 9a9575f..3e6ddd9 100644
--- a/Documentation/DocBook/media/v4l/gen-errors.xml
+++ b/Documentation/DocBook/media/v4l/gen-errors.xml
@@ -48,6 +48,11 @@
that this request would overcommit the usb bandwidth reserved
for periodic transfers (up to 80% of the USB bandwidth).
+
+ EWOULDBLOCK
+ Operation would block. Used when the ioctl would need to wait
+ for an event, but the device was opened in non-blocking
mode.
+
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 09/17] [media] nxt6000: i2c bus error should return -EIO
-EFAULT is used to indicate that there were a problem when copying
data from/to userspace. Don't mix it with I2C bus error (-EIO).
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/frontends/nxt6000.c
b/drivers/media/dvb/frontends/nxt6000.c
index a763ec7..6599b8f 100644
--- a/drivers/media/dvb/frontends/nxt6000.c
+++ b/drivers/media/dvb/frontends/nxt6000.c
@@ -50,7 +50,7 @@ static int nxt6000_writereg(struct nxt6000_state* state, u8
reg, u8 data)
if ((ret = i2c_transfer(state->i2c, &msg, 1)) != 1)
dprintk("nxt6000: nxt6000_write error (reg: 0x%02X, data:
0x%02X, ret: %d)\n", reg, data, ret);
- return (ret != 1) ? -EFAULT : 0;
+ return (ret != 1) ? -EIO : 0;
}
static u8 nxt6000_readreg(struct nxt6000_state* state, u8 reg)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 08/17] [media] siano: bad parameter is -EINVAL and not -EFAULT
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/siano/smscoreapi.c
b/drivers/media/dvb/siano/smscoreapi.c
index 78765ed..7331e84 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -1147,7 +1147,7 @@ static int smscore_validate_client(struct
smscore_device_t *coredev,
if (!client) {
sms_err("bad parameter.");
- return -EFAULT;
+ return -EINVAL;
}
registered_client = smscore_find_client(coredev, data_type, id);
if (registered_client == client)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 16/17] [media] v4l2 core: return -ENOTTY if an ioctl doesn't exist
Currently, -EINVAL is used to return either when an IOCTL is not
implemented, or if the ioctl was not implemented.
Note: Drivers that don't use video_ioctl2, will need extra patches.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml
b/Documentation/DocBook/media/v4l/gen-errors.xml
index dedcc90..8117c60 100644
--- a/Documentation/DocBook/media/v4l/gen-errors.xml
+++ b/Documentation/DocBook/media/v4l/gen-errors.xml
@@ -30,13 +30,6 @@
ioctl requests for specific causes.
- EINVAL or ENOTTY
- The ioctl is not supported by the driver, actually meaning that
- the required functionality is not available, or the file
- descriptor is not for a media device. The usage of EINVAL is
- deprecated and will be fixed on a latter patch.
-
-
ENODEV
Device not found or was removed.
@@ -45,6 +38,12 @@
There's not enough memory to handle the desired
operation.
+ ENOTTY
+ The ioctl is not supported by the driver, actually meaning that
+ the required functionality is not available, or the file
+ descriptor is not for a media device.
+
+
ENOSPC
On USB devices, the stream ioctl's can return this error, meaning
that this request would overcommit the usb bandwidth reserved
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml
b/Documentation/DocBook/media/v4l/v4l2.xml
index c5ee398..43386a6 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -132,7 +132,9 @@ applications. -->
2011-06-27
mcc, po
Documented that VIDIOC_QUERYCAP now returns a per-subsystem
version instead of a per-driver one.
+ Standardize an error code for invalid ioctl.
+
2.6.39
2011-03-01
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index f9aebac..4253276 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -543,12 +543,12 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_fh *vfh = NULL;
struct v4l2_format f_copy;
int use_fh_prio = 0;
- long ret = -EINVAL;
+ long ret = -ENOTTY;
if (ops == NULL) {
printk(KERN_WARNING "videodev: \"%s\" has no ioctl_ops.\n",
vfd->name);
- return -EINVAL;
+ return ret;
}
if ((vfd->debug & V4L2_DEBUG_IOCTL) &&
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 13/17] [media] dvb-bt8xx: Don't return -EFAULT when a device is not found
When a device (or their PCI structs) are not found, the error should
be -ENODEV. -EFAULT is reserved for errors while copying arguments
from/to userspace.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 1e1106d..521d691 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -892,7 +892,7 @@ static int __devinit dvb_bt8xx_probe(struct bttv_sub_device
*sub)
if (!(bttv_pci_dev = bttv_get_pcidev(card->bttv_nr))) {
printk("dvb_bt8xx: no pci device for card %d\n", card->bttv_nr);
kfree(card);
- return -EFAULT;
+ return -ENODEV;
}
if (!(card->bt = dvb_bt8xx_878_match(card->bttv_nr, bttv_pci_dev))) {
@@ -902,7 +902,7 @@ static int __devinit dvb_bt8xx_probe(struct bttv_sub_device
*sub)
"installed, try removing it.\n");
kfree(card);
- return -EFAULT;
+ return -ENODEV;
}
mutex_init(&card->bt->gpio_lock);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 01/17] [media] DocBook: Add a chapter to describe media errors
There are several errors reported by V4L that aren't described. They can occur on almost all ioctl's. Instead of adding them into each ioctl, create a new chapter. For V4L, the new chapter will automatically be listed on all places, as there's a macro used everywhere there. Signed-off-by: Mauro Carvalho Chehab create mode 100644 Documentation/DocBook/media/v4l/gen-errors.xml diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore index 25214a5..720f245 100644 --- a/Documentation/DocBook/.gitignore +++ b/Documentation/DocBook/.gitignore @@ -8,5 +8,7 @@ *.dvi *.log *.out +*.png +*.gif media-indices.tmpl media-entities.tmpl diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 8cb27f3..6628b4b 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -100,23 +100,59 @@ STRUCTS = \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h) ERRORS = \ + E2BIG \ EACCES \ EAGAIN \ EBADF \ + EBADFD \ + EBADR \ + EBADRQC \ EBUSY \ + ECHILD \ + ECONNRESET \ + EDEADLK \ + EDOM \ + EEXIST \ EFAULT \ - EIO \ + EFBIG \ + EILSEQ \ + EINIT \ + EINPROGRESS \ EINTR \ EINVAL \ + EIO \ + EMFILE \ ENFILE \ + ENOBUFS \ + ENODATA \ + ENODEV \ + ENOENT \ + ENOIOCTLCMD \ ENOMEM \ ENOSPC \ + ENOSR \ + ENOSYS \ + ENOTSUP \ + ENOTSUPP \ ENOTTY \ ENXIO \ - EMFILE \ + EOPNOTSUPP \ + EOVERFLOW \ EPERM \ - ERANGE \ EPIPE \ + EPROTO \ + ERANGE \ + EREMOTE \ + EREMOTEIO \ + ERESTART \ + ERESTARTSYS \ + ESHUTDOWN \ + ESPIPE \ + ETIME \ + ETIMEDOUT \ + EUSERS \ + EWOULDBLOCK \ + EXDEV \ ESCAPE = \ -e "s/&/\\&/g" \ diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml new file mode 100644 index 000..1efc688 --- /dev/null +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -0,0 +1,17 @@ +Generic Error Codes + + + Generic error codes + +&cs-str; + + + EBUSY + The ioctl can't be handled because the device is busy. This is + typically return while device is streaming, and an ioctl tried to + change something that would affect the stream, or would require the + usage of a hardware resource that was already allocated. + + + + diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 88f2cc6..bdb06bc 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -8,7 +8,7 @@ open()."> 2C"> -Return ValueOn success 0 is returned, on error -1 and the errno variable is set appropriately:"> +Return ValueOn success 0 is returned, on error -1 and the errno variable is set appropriately. The generic error codes are described at the Generic Error Codes chapter."> 2"> @@ -110,6 +109,11 @@ Foundation. A copy of the license is included in the chapter entitled &sub-media-controller; + +&sub-gen-errors; + + + &sub-fdl-appendix; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 00/17] Error code fixes and return -ENOTTY for no-ioctl
This patch series contain some fixes on how error codes are handled at the media API's. It consists on two parts. The first part have the DocBook changes: - Create a generic errno xml file, used by all media API's (V4L, MC, LIRC and DVB); - Move the generic errorcodes to the new file; - Removes code duplication/inconsistency along the several API files; - Removes two bogus undefined errorcodes: EINTERNAL/ENOSIGNAL from the ioctl's. The second part have the code changes: - Some fixes on a few drivers that use EFAULT on a wrong way, and not compliant with the DVB API; - The usage of ENOTTY meaning that no ioctl is implemented. TODO: - Some DVB open/close API description are mentioning the non-existent EINTERNAL error code; - firedtv driver needs to be fixed with respect to the usage of -EFAULT (Stefan c/c). - The DVB driver uses a couple different error codes to mean that an ioctl is not implemented: ENOSYS and EOPNOTSUPP. The last one is used on most places. It would be great to standardize this error code as well, but further study is required. - There are still several error codes not present at gen-errors.xml. A match between what's currently used at the drivers and the API is needed. Probably, both code and DocBook needs to be changed, as, on several cases, different drivers return different error codes for the same error. Mauro Carvalho Chehab (17): [media] DocBook: Add a chapter to describe media errors [media] DocBook: Use the generic ioctl error codes for all V4L ioctl's [media] DocBook: Use the generic error code page also for MC API [media] DocBook/media-ioc-setup-link.xml: Remove EBUSY [media] DocBook: Remove V4L generic error description for ioctl() [media] DocBook: Add an error code session for LIRC interface [media] DocBook: Add return error codes to LIRC ioctl session [media] siano: bad parameter is -EINVAL and not -EFAULT [media] nxt6000: i2c bus error should return -EIO [media] DVB: Point to the generic error chapter [media] DocBook/audio.xml: Remove generic errors [media] DocBook/demux.xml: Remove generic errors [media] dvb-bt8xx: Don't return -EFAULT when a device is not found [media] DocBook/dvb: Use generic descriptions for the frontend API [media] DocBook/dvb: Use generic descriptions for the video API [media] v4l2 core: return -ENOTTY if an ioctl doesn't exist [media] return -ENOTTY for unsupported ioctl's at legacy drivers Documentation/DocBook/.gitignore |2 + Documentation/DocBook/media/Makefile | 42 ++- Documentation/DocBook/media/dvb/audio.xml | 372 +-- Documentation/DocBook/media/dvb/ca.xml |6 +- Documentation/DocBook/media/dvb/demux.xml | 121 +- Documentation/DocBook/media/dvb/dvbproperty.xml| 23 +- Documentation/DocBook/media/dvb/frontend.xml | 487 +--- Documentation/DocBook/media/dvb/video.xml | 418 + Documentation/DocBook/media/v4l/func-ioctl.xml | 72 +--- Documentation/DocBook/media/v4l/gen-errors.xml | 77 +++ .../DocBook/media/v4l/lirc_device_interface.xml|4 +- .../DocBook/media/v4l/media-func-ioctl.xml | 47 +-- .../DocBook/media/v4l/media-ioc-device-info.xml|3 +- .../DocBook/media/v4l/media-ioc-setup-link.xml |9 - Documentation/DocBook/media/v4l/v4l2.xml |2 + Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 13 +- .../DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml | 11 +- .../DocBook/media/v4l/vidioc-dbg-g-register.xml| 17 - Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 10 +- .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 11 +- .../media/v4l/vidioc-enum-frameintervals.xml | 11 - .../DocBook/media/v4l/vidioc-enum-framesizes.xml | 11 - .../DocBook/media/v4l/vidioc-enumaudio.xml | 12 +- .../DocBook/media/v4l/vidioc-enumaudioout.xml | 12 +- Documentation/DocBook/media/v4l/vidioc-g-audio.xml | 18 +- .../DocBook/media/v4l/vidioc-g-audioout.xml| 18 +- Documentation/DocBook/media/v4l/vidioc-g-crop.xml | 17 - .../DocBook/media/v4l/vidioc-g-dv-preset.xml | 12 +- .../DocBook/media/v4l/vidioc-g-dv-timings.xml | 11 +- .../DocBook/media/v4l/vidioc-g-enc-index.xml | 17 - Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml | 19 +- Documentation/DocBook/media/v4l/vidioc-g-fmt.xml | 20 +- Documentation/DocBook/media/v4l/vidioc-g-input.xml | 19 +- .../DocBook/media/v4l/vidioc-g-jpegcomp.xml| 17 - .../DocBook/media/v4l/vidioc-g-output.xml | 18 +- Documentation/DocBook/media/v4l/vidioc-g-parm.xml | 17 - .../DocBook/media/v4l/vidioc-g-priority.xml|3 +- .../DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml | 11 +- Documentation/DocBook/media/v4l/vidioc-g-std.xml |9 +- .../DocBook/media/v4l/vidioc-log-status.xml| 17 - Documentation/Do
[PATCH RFCv3 11/17] [media] DocBook/audio.xml: Remove generic errors
Remove generic errors from ioctl() descriptions. For other ioctl's, there's no generic section. So, just keep whatever is there. Also remove the EINTERNAL error code, as no DVB driver returns it, and this error code is not defined on POSIX or on Linux. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/DocBook/media/dvb/audio.xml b/Documentation/DocBook/media/dvb/audio.xml index 90e9b7f..d643862 100644 --- a/Documentation/DocBook/media/dvb/audio.xml +++ b/Documentation/DocBook/media/dvb/audio.xml @@ -230,13 +230,6 @@ and right. -EINTERNAL - -Internal error. - - EBUSY @@ -392,21 +385,6 @@ role="subsection">AUDIO_STOP &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error. - - AUDIO_PLAY @@ -443,21 +421,6 @@ role="subsection">AUDIO_PLAY &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor - - -EINTERNAL - -Internal error. - - AUDIO_PAUSE @@ -502,22 +465,6 @@ role="subsection">AUDIO_PAUSE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - - AUDIO_CONTINUE @@ -558,21 +505,6 @@ with AUDIO_PAUSE command. &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - AUDIO_SELECT_SOURCE @@ -621,28 +553,6 @@ role="subsection">AUDIO_SELECT_SOURCE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EINVAL - -Illegal input parameter. - - AUDIO_SET_MUTE @@ -699,28 +609,6 @@ role="subsection">AUDIO_SET_MUTE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EINVAL - -Illegal input parameter. - - AUDIO_SET_AV_SYNC @@ -777,28 +665,6 @@ role="subsection">AUDIO_SET_AV_SYNC &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EINVAL - -Illegal input parameter. - - AUDIO_SET_BYPASS_MODE @@ -859,28 +725,6 @@ role="subsection">AUDIO_SET_BYPASS_MODE &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EINVAL - -Illegal input parameter. - - AUDIO_CHANNEL_SELECT @@ -927,28 +771,6 @@ role="subsection">AUDIO_CHANNEL_SELECT &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EINVAL - -Illegal input parameter ch. - - AUDIO_GET_STATUS @@ -994,28 +816,6 @@ role="subsection">AUDIO_GET_STATUS &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EFAULT - -status points to invalid address. - - AUDIO_GET_CAPABILITIES @@ -1061,28 +861,6 @@ role="subsection">AUDIO_GET_CAPABILITIES &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EFAULT - -cap points to an invalid address. - - AUDIO_CLEAR_BUFFER @@ -1119,21 +897,6 @@ role="subsection">AUDIO_CLEAR_BUFFER &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - AUDIO_SET_ID @@ -1182,28 +945,6 @@ role="subsection">AUDIO_SET_ID &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EINVAL - -Invalid sub-stream id. - - AUDIO_SET_MIXER @@ -1247,28 +988,6 @@ role="subsection">AUDIO_SET_MIXER &return-value-dvb; - -EBADF - -fd is not a valid open file descriptor. - - -EINTERNAL - -Internal error. - - -EFAULT - -mix points to an invalid address. - - AUDIO_SET_STREAMTYPE @@ -1316,13 +1035,6 @@ role="subsection">AUDIO_SET_STREAMTYPE &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1375,13 +1087,6 @@ role="subsection">AUDIO_SET_EXT_ID &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1435,13 +1140,6 @@ role="subsection">AUDIO_SET_ATTRIBUTES &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL @@ -1495,13 +1193,6 @@ role="subsection">AUDIO_SET_KARAOKE &return-value-dvb; -EBADF - -fd is not a valid open file descriptor - - EINVAL diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 2b50b63..9a9575f 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -35,6 +35,10 @@ descriptor is not for a media device. +ENODEV + Device not found or was removed. + + ENOMEM There's not enough memory to handle the desired operation. -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 17/17] [media] return -ENOTTY for unsupported ioctl's at legacy drivers
Those drivers are not relying at the V4L2 core to handle the ioctl's.
So, we need to manually patch them every time a change goes to the
core.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/et61x251/et61x251_core.c
b/drivers/media/video/et61x251/et61x251_core.c
index d7efb33..9a1e80a 100644
--- a/drivers/media/video/et61x251/et61x251_core.c
+++ b/drivers/media/video/et61x251/et61x251_core.c
@@ -2480,16 +2480,8 @@ static long et61x251_ioctl_v4l2(struct file *filp,
case VIDIOC_S_PARM:
return et61x251_vidioc_s_parm(cam, arg);
- case VIDIOC_G_STD:
- case VIDIOC_S_STD:
- case VIDIOC_QUERYSTD:
- case VIDIOC_ENUMSTD:
- case VIDIOC_QUERYMENU:
- case VIDIOC_ENUM_FRAMEINTERVALS:
- return -EINVAL;
-
default:
- return -EINVAL;
+ return -ENOTTY;
}
}
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 573749a..e27f8ab 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -369,11 +369,6 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
break;
}
- case VIDIOC_S_AUDIO:
- {
- ret = -EINVAL;
- break;
- }
case VIDIOC_G_TUNER:
{
struct v4l2_tuner *vt = (struct v4l2_tuner *)arg;
@@ -850,7 +845,7 @@ static long pvr2_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
#endif
default :
- ret = -EINVAL;
+ ret = -ENOTTY;
break;
}
diff --git a/drivers/media/video/sn9c102/sn9c102_core.c
b/drivers/media/video/sn9c102/sn9c102_core.c
index d8eece8..16cb07c 100644
--- a/drivers/media/video/sn9c102/sn9c102_core.c
+++ b/drivers/media/video/sn9c102/sn9c102_core.c
@@ -3187,16 +3187,8 @@ static long sn9c102_ioctl_v4l2(struct file *filp,
case VIDIOC_S_AUDIO:
return sn9c102_vidioc_s_audio(cam, arg);
- case VIDIOC_G_STD:
- case VIDIOC_S_STD:
- case VIDIOC_QUERYSTD:
- case VIDIOC_ENUMSTD:
- case VIDIOC_QUERYMENU:
- case VIDIOC_ENUM_FRAMEINTERVALS:
- return -EINVAL;
-
default:
- return -EINVAL;
+ return -ENOTTY;
}
}
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index cdd967b..7afb97b 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -83,7 +83,7 @@ static int uvc_ioctl_ctrl_map(struct uvc_video_chain *chain,
default:
uvc_trace(UVC_TRACE_CONTROL, "Unsupported V4L2 control type "
"%u.\n", xmap->v4l2_type);
- ret = -EINVAL;
+ ret = -ENOTTY;
goto done;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola wrote: > > Hi. > > I think that you could reuse lots of code with smart suspend / resume. > > What do you think about this DVB power saving case (about the concept, don't > look at details, please): > > - One device has responsibility to do the power off when it can be done > (mantis_core.ko) > - In my case there is only one frontend tda10021.ko to take care of. > > - dvb_frontend.c would call fe->sleep(fe). The callback goes into > mantis_core.ko. > - mantis_core.ko will traverse all devices on it's responsibility, all > (tda10021.ko) are idle. > => suspend tda10021.ko by calling tda10021->sleep() and do additional power > off things. > > - When dvb_frontend.c wants tuner to be woken up, > mantis_core.ko does hardware resets and power on first and then resumes > tda10021->init(fe). > > I implemented something that worked a few years ago with suspend / resume. > In mantis_dvb.c's driver probe function I modified tuner_ops to enable these > runtime powersaving features: > + mantis->fe->ops.tuner_ops.sleep = > mantis_dvb_tuner_sleep; > + mantis->fe->ops.tuner_ops.init = > mantis_dvb_tuner_init; > > That way mantis_core.ko had all needed details to do any advanced power > savings I wanted. > > Suspend / resume worked well: During resume there was only a glitch at the > picture and sound > and the TV channel watching continued. tda10021 (was cu1216 at that time) > restored the original TV channel. It took DVB FE_LOCK during resume. > Suspended DMA transfer was recovered before returning into userspace. > > So I think that you need a single device (mantis_core.ko) that can see the > whole picture, > in what states the subdevices are: can you touch the power button?. > With DVB this is easy because dvb_frontend.c tells when a frontend is idle > and when it is not. > > The similar idea of some kind of watchdog that is able to track when a single > device (frontend) is used and when it is not used, would be sufficient. > > The topmost driver (mantis_core.ko in my case) would then be responsible to > track multiple frontends > (subdevices), if they all are idle or not, with suitable mutex protection. > Then this driver could easilly suspend/resume these subdevices and press > power switch when necessary. > > > So the clash between DVB and V4L devices would be solved: > Both DVB and V4L calls a (different) sleep() function on mantis_core.ko > mantis_core.ko will turn power off when both "frontends" are sleeping. > If only one sleeps, the one can be put to sleep or suspended, but power > button can't be touched. > > What do you think? > > I did this easy case mantis_core.ko solution in about Summer 2007. > It needs a rewrite and testing, if I take it from the dust. > > Regards, > Marko Ristola Hi Marko, This is one of those ideas that sounds good in theory but in practice getting it to work with all the different types of boards is really a challenge. It would need to take into account devices with multiple frontends, shared tuners between V4L and DVB, shared tuners between different DVB frontends, etc. For example, the DVB frontend call to sleep the demod is actually deferred. This exposes all sorts of fun races with applications such as MythTV which switch between DVB and V4L modes in fast succession. For example, on the HVR-950Q I debugged an issue last year where switching from DVB to V4L would close the DVB frontend device, immediately open the V4L device, start tuning the V4L device, and then a couple hundred milliseconds later the sleep call would arrive from the DVB frontend thread which would screw up the tuner state. In other words, the locking is not trivial and you need to take into account the various threads that can be running. Taking the above example, if you had deferred freeing up the device until the sleep call arrived, then the DVB close would have returned immediately, and the V4L open would have failed because the device was "still in use". Also, you need to take into consideration that bringing some devices out of sleep can be a *very* time consuming operation. This is mostly due to loading of firmware, which on some devices can take upwards of ten seconds due to large blobs and slow i2c busses. Hence if you have too granular a power management strategy you end up with a situation where you are continuously calling a resume routine which takes ten seconds. This adds up quickly if for example you call v4l2-ctl half a dozen times before starting streaming. All that said, I believe that you are correct in that the business logic needs to ultimately be decided by the bridge driver, rather than having the dvb/tuner core blindly calling the sleep routines against the tuner and demod drivers without a full understanding of what impact it has on the board as a whole. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send
Re: [PATCH] [media] firedtv: change some -EFAULT returns to more fitting error codes
Hi Stefan,
Em 06-07-2011 14:33, Stefan Richter escreveu:
> Mauro Carvalho Chehab wrote:
>> I'm validating if all drivers are behaving equally with respect to the
>> error codes returned to userspace, and double-checking with the API.
>>
>> On almost all places, -EFAULT code is used only to indicate when
>> copy_from_user/copy_to_user fails. However, firedtv uses a lot of
>> -EFAULT, where it seems to me that other error codes should be used
>> instead (like -EIO for bus transfer errors and -EINVAL/-ERANGE for
>> invalid/out of range parameters).
Thanks for the patch! Unfortunately, it didn't arrived fine here (it was
whitespace mangled). Could you please re-send it with the proper whitespacing
(or
attached)?
>
> This concerns only the CI (CAM) related code of firedtv of which I know
> little. Let's just pass through the error returns of lower level I/O
> code where applicable, and -EACCES (permission denied) when a seemingly
> valid but negative FCP response or an unknown-to-firedtv CA message is
> received.
Works for me.
>
> Signed-off-by: Stefan Richter
> Cc: Henrik Kurelid
> ---
> Only tested on FireDTV-{C,T}/CI without CAM.
>
> drivers/media/dvb/firewire/firedtv-avc.c |2
> drivers/media/dvb/firewire/firedtv-ci.c | 34 +++
> 2 files changed, 17 insertions(+), 19 deletions(-)
>
> Index: b/drivers/media/dvb/firewire/firedtv-avc.c
> ===
> --- a/drivers/media/dvb/firewire/firedtv-avc.c
> +++ b/drivers/media/dvb/firewire/firedtv-avc.c
> @@ -1208,7 +1208,7 @@ int avc_ca_pmt(struct firedtv *fdtv, cha
> if (r->response != AVC_RESPONSE_ACCEPTED) {
> dev_err(fdtv->device,
> "CA PMT failed with response 0x%x\n",
> r->response);
> - ret = -EFAULT;
> + ret = -EACCES;
> }
> out:
> mutex_unlock(&fdtv->avc_mutex);
> Index: b/drivers/media/dvb/firewire/firedtv-ci.c
> ===
> --- a/drivers/media/dvb/firewire/firedtv-ci.c
> +++ b/drivers/media/dvb/firewire/firedtv-ci.c
> @@ -45,11 +45,6 @@ static int fdtv_get_ca_flags(struct fire
> return flags;
> }
>
> -static int fdtv_ca_reset(struct firedtv *fdtv)
> -{
> - return avc_ca_reset(fdtv) ? -EFAULT : 0;
> -}
> -
> static int fdtv_ca_get_caps(void *arg)
> {
> struct ca_caps *cap = arg;
> @@ -65,12 +60,14 @@ static int fdtv_ca_get_slot_info(struct
> {
> struct firedtv_tuner_status stat;
> struct ca_slot_info *slot = arg;
> + int err;
>
> - if (avc_tuner_status(fdtv, &stat))
> - return -EFAULT;
> + err = avc_tuner_status(fdtv, &stat);
> + if (err)
> + return err;
>
> if (slot->num != 0)
> - return -EFAULT;
> + return -EACCES;
>
> slot->type = CA_CI;
> slot->flags = fdtv_get_ca_flags(&stat);
> @@ -81,21 +78,21 @@ static int fdtv_ca_app_info(struct fired
> {
> struct ca_msg *reply = arg;
>
> - return avc_ca_app_info(fdtv, reply->msg, &reply->length) ?
> -EFAULT : 0;
> + return avc_ca_app_info(fdtv, reply->msg, &reply->length);
> }
>
> static int fdtv_ca_info(struct firedtv *fdtv, void *arg)
> {
> struct ca_msg *reply = arg;
>
> - return avc_ca_info(fdtv, reply->msg, &reply->length) ? -EFAULT :
> 0;
> + return avc_ca_info(fdtv, reply->msg, &reply->length);
> }
>
> static int fdtv_ca_get_mmi(struct firedtv *fdtv, void *arg)
> {
> struct ca_msg *reply = arg;
>
> - return avc_ca_get_mmi(fdtv, reply->msg, &reply->length) ?
> -EFAULT : 0;
> + return avc_ca_get_mmi(fdtv, reply->msg, &reply->length);
> }
>
> static int fdtv_ca_get_msg(struct firedtv *fdtv, void *arg)
> @@ -111,14 +108,15 @@ static int fdtv_ca_get_msg(struct firedt
> err = fdtv_ca_info(fdtv, arg);
> break;
> default:
> - if (avc_tuner_status(fdtv, &stat))
> - err = -EFAULT;
> - else if (stat.ca_mmi == 1)
> + err = avc_tuner_status(fdtv, &stat);
> + if (err)
> + break;
> + if (stat.ca_mmi == 1)
> err = fdtv_ca_get_mmi(fdtv, arg);
> else {
> dev_info(fdtv->device, "unhandled CA message
> 0x%08x\n", fdtv->ca_last_command);
> - err = -EFAULT;
> + err = -EACCES;
> }
> }
> fdtv->ca_last_command = 0;
> @@ -141,7 +139,7 @@ static int fdtv_ca_pmt(struct firedtv *f
> data_length = msg->msg[3];
> }
>
> - return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length) ?
> -EFAULT : 0;
> + return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length);
> }
>
> static int fdtv_ca_send_msg(struct firedtv *fdtv, void *arg)
> @@ -170,7 +168,7 @@ static int fdtv_ca_send_msg(struct fired
> default:
> dev_err(fdtv->device,
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jul 6 19:00:35 CEST 2011 git hash:df6aabbeb2b8799d97f3886fc994c318bc6a6843 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS 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 V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend] [media] firedtv: change some -EFAULT returns to more fitting error codes
Mauro Carvalho Chehab wrote:
> I'm validating if all drivers are behaving equally with respect to the
> error codes returned to userspace, and double-checking with the API.
>
> On almost all places, -EFAULT code is used only to indicate when
> copy_from_user/copy_to_user fails. However, firedtv uses a lot of
> -EFAULT, where it seems to me that other error codes should be used
> instead (like -EIO for bus transfer errors and -EINVAL/-ERANGE for
> invalid/out of range parameters).
This concerns only the CI (CAM) related code of firedtv of which I know
little. Let's just pass through the error returns of lower level I/O
code where applicable, and -EACCES (permission denied) when a seemingly
valid but negative FCP response or an unknown-to-firedtv CA message is
received.
Signed-off-by: Stefan Richter
Cc: Henrik Kurelid
---
Resent, hopefully without linewrap breakage this time.
drivers/media/dvb/firewire/firedtv-avc.c |2
drivers/media/dvb/firewire/firedtv-ci.c | 34 +++
2 files changed, 17 insertions(+), 19 deletions(-)
Index: b/drivers/media/dvb/firewire/firedtv-avc.c
===
--- a/drivers/media/dvb/firewire/firedtv-avc.c
+++ b/drivers/media/dvb/firewire/firedtv-avc.c
@@ -1208,7 +1208,7 @@ int avc_ca_pmt(struct firedtv *fdtv, cha
if (r->response != AVC_RESPONSE_ACCEPTED) {
dev_err(fdtv->device,
"CA PMT failed with response 0x%x\n", r->response);
- ret = -EFAULT;
+ ret = -EACCES;
}
out:
mutex_unlock(&fdtv->avc_mutex);
Index: b/drivers/media/dvb/firewire/firedtv-ci.c
===
--- a/drivers/media/dvb/firewire/firedtv-ci.c
+++ b/drivers/media/dvb/firewire/firedtv-ci.c
@@ -45,11 +45,6 @@ static int fdtv_get_ca_flags(struct fire
return flags;
}
-static int fdtv_ca_reset(struct firedtv *fdtv)
-{
- return avc_ca_reset(fdtv) ? -EFAULT : 0;
-}
-
static int fdtv_ca_get_caps(void *arg)
{
struct ca_caps *cap = arg;
@@ -65,12 +60,14 @@ static int fdtv_ca_get_slot_info(struct
{
struct firedtv_tuner_status stat;
struct ca_slot_info *slot = arg;
+ int err;
- if (avc_tuner_status(fdtv, &stat))
- return -EFAULT;
+ err = avc_tuner_status(fdtv, &stat);
+ if (err)
+ return err;
if (slot->num != 0)
- return -EFAULT;
+ return -EACCES;
slot->type = CA_CI;
slot->flags = fdtv_get_ca_flags(&stat);
@@ -81,21 +78,21 @@ static int fdtv_ca_app_info(struct fired
{
struct ca_msg *reply = arg;
- return avc_ca_app_info(fdtv, reply->msg, &reply->length) ? -EFAULT : 0;
+ return avc_ca_app_info(fdtv, reply->msg, &reply->length);
}
static int fdtv_ca_info(struct firedtv *fdtv, void *arg)
{
struct ca_msg *reply = arg;
- return avc_ca_info(fdtv, reply->msg, &reply->length) ? -EFAULT : 0;
+ return avc_ca_info(fdtv, reply->msg, &reply->length);
}
static int fdtv_ca_get_mmi(struct firedtv *fdtv, void *arg)
{
struct ca_msg *reply = arg;
- return avc_ca_get_mmi(fdtv, reply->msg, &reply->length) ? -EFAULT : 0;
+ return avc_ca_get_mmi(fdtv, reply->msg, &reply->length);
}
static int fdtv_ca_get_msg(struct firedtv *fdtv, void *arg)
@@ -111,14 +108,15 @@ static int fdtv_ca_get_msg(struct firedt
err = fdtv_ca_info(fdtv, arg);
break;
default:
- if (avc_tuner_status(fdtv, &stat))
- err = -EFAULT;
- else if (stat.ca_mmi == 1)
+ err = avc_tuner_status(fdtv, &stat);
+ if (err)
+ break;
+ if (stat.ca_mmi == 1)
err = fdtv_ca_get_mmi(fdtv, arg);
else {
dev_info(fdtv->device, "unhandled CA message 0x%08x\n",
fdtv->ca_last_command);
- err = -EFAULT;
+ err = -EACCES;
}
}
fdtv->ca_last_command = 0;
@@ -141,7 +139,7 @@ static int fdtv_ca_pmt(struct firedtv *f
data_length = msg->msg[3];
}
- return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length) ? -EFAULT : 0;
+ return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length);
}
static int fdtv_ca_send_msg(struct firedtv *fdtv, void *arg)
@@ -170,7 +168,7 @@ static int fdtv_ca_send_msg(struct fired
default:
dev_err(fdtv->device, "unhandled CA message 0x%08x\n",
fdtv->ca_last_command);
- err = -EFAULT;
+ err = -EACCES;
}
return err;
}
@@ -184,7 +182,7 @@ static int fdtv_ca_ioctl(struct file *fi
switch (cmd) {
case CA_RESET:
- err = fdtv_ca_reset(fdtv);
+ e
Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011, Russell King - ARM Linux wrote: > So, ARM is no different from x86, with the exception that the 16MB DMA > zone due to ISA ends up being different sizes on ARM depending on our > restrictions. Sounds good. Thank you. -- 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 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011, Arnd Bergmann wrote: > On Wednesday 06 July 2011, Russell King - ARM Linux wrote: > > On Wed, Jul 06, 2011 at 04:51:49PM +0200, Arnd Bergmann wrote: > > > On Wednesday 06 July 2011, Russell King - ARM Linux wrote: > > > > > > I don't see how. The pages get allocated from an unmapped area > > > or memory, mapped into the kernel address space as uncached or wc > > > and then cleared. This should be the same for lowmem or highmem > > > pages. > > > > You don't want to clear them via their uncached or WC mapping, but via > > their cached mapping _before_ they get their alternative mapping, and > > flush any cached out of that mapping - both L1 and L2 caches. > > But there can't be any other mapping, which is the whole point of > the exercise to use highmem. > Quoting from the new dma_alloc_area() function: > > c = arm_vmregion_alloc(&area->vm, align, size, > gfp & ~(__GFP_DMA | __GFP_HIGHMEM)); > if (!c) > return NULL; > memset((void *)c->vm_start, 0, size); > > area->vm here points to an uncached location, which means that > we already zero the data through the uncached mapping. I don't > see how it's getting worse than it is already. If you get a highmem page, because the cache is VIPT, that page might still be cached even if it wasn't mapped. With a VIVT cache we must flush the cache whenever a highmem page is unmapped. There is no such restriction with VIPT i.e. ARMv6 and above. Therefore to make sure the highmem page you get doesn't have cache lines associated to it, you must first map it cacheable, then perform cache invalidation on it, and eventually remap it as non-cacheable. This is necessary because there is no way to perform cache maintenance on L1 cache using physical addresses unfortunately. See commit 7e5a69e83b for an example of what this entails (fortunately commit 3e4d3af501 made things much easier and therefore commit 39af22a79 greatly simplified things). Nicolas -- 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
Slovakia dvb-t iupdates
Hi all, attached are the updates for dvb-t scan files valid for Slovakia. Kind regards Peter Butkovic diff -r 148ede2a6809 util/scan/dvb-t/sk-BanskaBystrica --- a/util/scan/dvb-t/sk-BanskaBystrica Tue Jun 28 07:50:24 2011 +0200 +++ b/util/scan/dvb-t/sk-BanskaBystrica Wed Jul 06 21:25:01 2011 +0200 @@ -1,9 +1,7 @@ # DVB-T Banska Bystrica (Banska Bystrica, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -# 1.st multiplex - on channel 65 -T 82600 8MHz 2/3 NONE QAM64 8k 1/4 NONE - # 2.st multiplex (commercial) - on channel 51 T 71400 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-BanskaStiavnica --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/sk-BanskaStiavnica Wed Jul 06 21:25:01 2011 +0200 @@ -0,0 +1,9 @@ +# DVB-T Banska Stiavnica (Banska Stiavnica, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy + +# 2.st multiplex (commercial) - on channel 21 +T 30600 8MHz 2/3 NONE QAM64 8k 1/4 NONE + +# 3.st multiplex (public) - on channel 48 +T 69000 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-Bardejov --- a/util/scan/dvb-t/sk-Bardejov Tue Jun 28 07:50:24 2011 +0200 +++ b/util/scan/dvb-t/sk-Bardejov Wed Jul 06 21:25:01 2011 +0200 @@ -1,9 +1,7 @@ # DVB-T Bardejov (Bardejov, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -# 1.st multiplex - on channel 62 -T 80200 8MHz 2/3 NONE QAM64 8k 1/4 NONE - # 2.st multiplex (commercial) - on channel 40 T 62600 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-Bratislava --- a/util/scan/dvb-t/sk-Bratislava Tue Jun 28 07:50:24 2011 +0200 +++ b/util/scan/dvb-t/sk-Bratislava Wed Jul 06 21:25:01 2011 +0200 @@ -1,9 +1,7 @@ # DVB-T Bratislava (Bratislava, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -# 1.st multiplex - on channel 66 -T 83400 8MHz 2/3 NONE QAM64 8k 1/4 NONE - # 2.st multiplex (commercial) - on channel 56 T 75400 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-Cadca --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/sk-Cadca Wed Jul 06 21:25:01 2011 +0200 @@ -0,0 +1,9 @@ +# DVB-T Cadca (Cadca, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy + +# 2.st multiplex (commercial) - on channel 52 +T 72200 8MHz 2/3 NONE QAM64 8k 1/4 NONE + +# 3.st multiplex (public) - on channel 32 +T 56200 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-Detva --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/sk-Detva Wed Jul 06 21:25:01 2011 +0200 @@ -0,0 +1,9 @@ +# DVB-T Detva (Detva, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy + +# 2.st multiplex (commercial) - on channel 60 +T 78600 8MHz 2/3 NONE QAM64 8k 1/4 NONE + +# 3.st multiplex (public) - on channel 33 +T 57000 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-Hnusta --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/sk-Hnusta Wed Jul 06 21:25:01 2011 +0200 @@ -0,0 +1,9 @@ +# DVB-T Hnusta (Hnusta, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy + +# 2.st multiplex (commercial) - on channel 27 +T 52200 8MHz 2/3 NONE QAM64 8k 1/4 NONE + +# 3.st multiplex (public) - on channel 54 +T 73800 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-Kosice --- a/util/scan/dvb-t/sk-Kosice Tue Jun 28 07:50:24 2011 +0200 +++ b/util/scan/dvb-t/sk-Kosice Wed Jul 06 21:25:01 2011 +0200 @@ -1,9 +1,7 @@ # DVB-T Kosice (Kosice, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -# 1.st multiplex - on channel 64 -T 81800 8MHz 2/3 NONE QAM64 8k 1/4 NONE - # 2.st multiplex (commercial) - on channel 59 T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE diff -r 148ede2a6809 util/scan/dvb-t/sk-KralovskyChlmec --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/sk-KralovskyChlmec Wed Jul 06 21:25:01 2011 +0200 @@ -0,0 +1,9 @@ +# DVB-T Kralovsky Chlmec (Kralovsky Chlmec, Slovak Republic) +# Created from http://www.dvbt.towercom.sk/odbornici.php +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy + +# 2.st multiplex (commercial) - on channel 59 +T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE + +# 3.st multiplex (public) - on chann
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 06-07-2011 09:14, Hans Verkuil escreveu:
>> Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
>> I failed to see what information is provided by the "presets" name.
>> If
>> this were removed
>> from the ioctl, and fps would be added instead, the API would be
>> clearer. The only
>> adjustment would be to use "index" as the preset selection key.
>> Anyway,
>> it is too late
>> for such change. We need to live with that.
>
> Adding the fps solves nothing. Because that still does not give you
> specific timings.
> You can have 1920x1080P60 that has quite different timings from the
> CEA-861 standard
> and that may not be supported by a TV.
>
> If you are working with HDMI, then you may want to filter all
> supported
> presets to
> those of the CEA standard.
>
> That's one thing that is missing at the moment: that presets belonging
> to a certain
> standard get their own range. Since we only do CEA861 right now it
> hasn't been an
> issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time into
something broken, at the light of all DV timing standards. So, I've
dropped it and
started from scratch.
From what I've got, there are some hardware that can only do a limited
set
of DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where
hardware
only support
a limited set of frequencies, that may or may not be inside the CEA
standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 1<<31
#define DV_PRESET_SPEC(flag) (flag && 0xff)
#define DV_PRESET_IS_CEA8611
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs, etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[4];
};
#defineVIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#defineVIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#defineVIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing
information to select the desired format, and don't need to have a
switch
for
a preset macro to try to guess what the format actually means. Also,
there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the
above
definitions
are different than the old ones, _IO macros will provide a different
magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as
deprecated.
>>>
>>> This proposal makes it very hard for applications to directly select a
>>> format like 720p50 because the indices can change at any time.
>>
>> Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
>> check what line it wants,
>
> It's
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
06.07.2011 21:17, Devin Heitmueller kirjoitti: > On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola > wrote: >> > > All that said, I believe that you are correct in that the business > logic needs to ultimately be decided by the bridge driver, rather than > having the dvb/tuner core blindly calling the sleep routines against > the tuner and demod drivers without a full understanding of what > impact it has on the board as a whole. You wrote it nicely and compactly. What do you think about tracking coarse last busy time rather than figuring out accurate idle time? dvb_frontend.c and V4L side would just poll the device: "bridge->wake()". wake() will just store current "busy" timestamp to the bridge device with coarse accuracy, if subdevices are already at active state. If subdevices are powered off, it will first power them on and resume them, and then store "busy" timestamp. Bridge device would have a "delayed task": "Check after 3 minutes: If I haven't been busy for three minutes, I'll go to sleep. I'll suspend the subdevices and power them off." The "delayed task" would refresh itself: check again after last awake time + 3 minutes. "Delayed task" could be further developed to support multiple suspend states. > > Cheers, > > Devin > Marko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wednesday 06 July 2011 21:10:07 Nicolas Pitre wrote: > If you get a highmem page, because the cache is VIPT, that page might > still be cached even if it wasn't mapped. With a VIVT cache we must > flush the cache whenever a highmem page is unmapped. There is no such > restriction with VIPT i.e. ARMv6 and above. Therefore to make sure the > highmem page you get doesn't have cache lines associated to it, you must > first map it cacheable, then perform cache invalidation on it, and > eventually remap it as non-cacheable. This is necessary because there > is no way to perform cache maintenance on L1 cache using physical > addresses unfortunately. See commit 7e5a69e83b for an example of what > this entails (fortunately commit 3e4d3af501 made things much easier and > therefore commit 39af22a79 greatly simplified things). Ok, thanks for the explanation. This definitely makes the highmem approach much harder to get right, and slower. Let's hope then that Marek's approach of using small pages for the contiguous memory region and changing their attributes on the fly works out better than this. 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: [DVB] TT S-1500b tuning issue
On Wed, 2011-07-06 at 13:34 +0200, Sébastien RAILLARD (COEXSI) wrote: > > > -Original Message- > > From: Oliver Endriss [mailto:o.endr...@gmx.de] > > Sent: lundi 4 juillet 2011 00:43 > > To: Linux Media Mailing List > > Cc: Sébastien RAILLARD (COEXSI); Malcolm Priestley > > Subject: Re: [DVB] TT S-1500b tuning issue > > > > On Wednesday 29 June 2011 15:16:10 Sébastien RAILLARD wrote: > > > Dear all, > > > > > > We have found what seems to be a tuning issue in the driver for the > > > ALPS BSBE1-D01A used in the new TT-S-1500b card from Technotrend. > > > On some transponders, like ASTRA 19.2E 11817-V-27500, the card can > > > work very well (no lock issues) for hours. > > > > > > On some other transponders, like ASTRA 19.2E 11567-V-22000, the card > > > nearly never manage to get the lock: it's looking like the signal > > > isn't good enough. > > > > Afaics the problem is caused by the tuning loop > > for (tm = -6; tm < 7;) > > in stv0288_set_frontend(). > > > > I doubt that this code works reliably. > > Apparently it never obtains a lock within the given delay (30us). It's actually quite slow caused by any delay in the I2C bus. I doubt given the age many controllers run at the 400kHz spec, if barely 100kHz. > > > > Could you please try the attached patch? > > It disables the loop and tries to tune to the center frequency. > > > > Ok, I've tested this patch with ASTRA 19.2 #24 transponder that wasn't > always working: it seems to work. > I think it would be great to test it for few days more to be sure. Unfortunately, this patch does not work well at all. All that is happening is that the carrier offset is getting forced to 0, after it has been updated by the lock control register losing a 'good' lock. The value is typically around ~f800+. Perhaps the loop should be knocked down slightly to -9. The loop was probably intended for 22000 symbol rate. tvboxspy -- 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 for v3.0] OMAP_VOUT bug fixes and code cleanup
On Tue, 5 Jul 2011, JAIN, AMBER wrote:
> > > diff --git a/drivers/media/video/omap24xxcam.c
> > b/drivers/media/video/omap24xxcam.c
> > > index f6626e8..d92d4c6 100644
> > > --- a/drivers/media/video/omap24xxcam.c
> > > +++ b/drivers/media/video/omap24xxcam.c
> > > @@ -309,11 +309,11 @@ static int
> > omap24xxcam_vbq_alloc_mmap_buffer(struct videobuf_buffer *vb)
> > > order--;
> > >
> > > /* try to allocate as many contiguous pages as possible */
> > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
> > > + page = alloc_pages(GFP_KERNEL, order);
> > > /* if allocation fails, try to allocate smaller amount */
> > > while (page == NULL) {
> > > order--;
> > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
> > > + page = alloc_pages(GFP_KERNEL, order);
> > > if (page == NULL && !order) {
> > > err = -ENOMEM;
> > > goto out;
> >
> > Hmm... the proper fix wouldn't be to define ZONE_DMA at OMAP?
>
> I don't think so, my understanding for ZOME_DMA is that it is defined
> for architectures that have restrictions on memory addresses that can be
> used for DMA. OMAP doesn't have any such restriction and hence we should
> not define ZONE_DMA.
>
s/should not define/do not need to define/
Right, if omap does not have DMA restrictions then the GFP_DMA usage that
is removed with this patch was incorrect.
--
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
[REVIEW] adv7175 mbus support
Hi all,
I have hacked together a patch, which adds support for mediabus in
adv7175 driver. I am not sending
this out as a patch series instead I show you one (big) patch with
questions about my code. Also
I want to note that I am not quite sure if I introduced the correct
formats and the documentation could
also be better, but I am not a format specialist.
The data sheet can be found here:
http://dxr3.sourceforge.net/download/hardware/ADV7175A_6A.pdf
In later patches I need to implement this functionality:
HSYNC to Pixel Data Adjust (TR17–TR16)
This enables the HSYNC to be adjusted with respect to the
pixel data. This allows the Cr and Cb components to be
swapped. This adjustment is available in both master and slave
timing modes.
See data sheet page 25. But at the moment I am not sure how to do this.
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532e..18e30b0 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -2565,5 +2565,43 @@
+
+
+ YCrCb Formats
+
+ YCbCr represents colors as a combination of three values:
+
+ Y - the luminosity (roughly the
brightness)
+ Cb - the chrominance of the blue
primary
+ Cr - the chrominance of the red
primary
+
+
+
+ The following table lists existing YCrCb compressed formats.
+
+
+ YCrCb Formats
+
+
+
+
+
+ Identifier
+ Code
+
+
+
+
+ V4L2_MBUS_FMT_YCRCB_1X8
+ 0x5001
+
+
+ V4L2_MBUS_FMT_YCRCB_1X16
+ 0x5002
+
+
+
+
+
What do you think about the doc?
diff --git a/drivers/media/video/adv7175.c b/drivers/media/video/adv7175.c
index d2327db..79ab5a3 100644
--- a/drivers/media/video/adv7175.c
+++ b/drivers/media/video/adv7175.c
@@ -51,6 +51,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-1)");
struct adv7175 {
struct v4l2_subdev sd;
v4l2_std_id norm;
+ enum v4l2_mbus_pixelcode pixelcode;
int input;
};
@@ -61,6 +62,11 @@ static inline struct adv7175 *to_adv7175(struct
v4l2_subdev *sd)
static char *inputs[] = { "pass_through", "play_back", "color_bar" };
+static enum v4l2_mbus_pixelcode adv7175_codes[] = {
+ V4L2_MBUS_FMT_YCRCB_1X8,
+ V4L2_MBUS_FMT_YCRCB_1X16,
+};
+
/* --- */
static inline int adv7175_write(struct v4l2_subdev *sd, u8 reg, u8 value)
@@ -296,6 +302,60 @@ static int adv7175_s_routing(struct v4l2_subdev *sd,
return 0;
}
+static int adv7175_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index >= ARRAY_SIZE(adv7175_codes))
+ return -EINVAL;
+
+ *code = adv7175_codes[index];
+ return 0;
+}
+
+static int adv7175_g_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ struct adv7175 *encoder = to_adv7175(sd);
+
+ mf->code= encoder->pixelcode;
+ mf->colorspace = V4L2_COLORSPACE_SMPTE170M;
+ mf->width = 0;
+ mf->height = 0;
Do I need to set width and height? Cause the bridge driver knows these
values.
+ mf->field = V4L2_FIELD_NONE;
+
+ return 0;
+}
+
+static int adv7175_s_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
+{
+ struct adv7175 *encoder = to_adv7175(sd);
+ u8 val = adv7175_read(sd, 0x7);
+ int ret;
+
+ switch (mf->code) {
+ case V4L2_MBUS_FMT_YCRCB_1X8:
+ val &= ~0x40;
+ break;
+
+ case V4L2_MBUS_FMT_YCRCB_1X16:
+ val |= 0x40;
+ break;
+
+ default:
+ v4l2_dbg(1, debug, sd,
+ "illegal v4l2_mbus_framefmt code: %d\n", mf->code);
+ return -EINVAL;
+ }
+
+ ret = adv7175_write(sd, 0x7, val);
+
+ if (ret == 0)
+ encoder->pixelcode = mf->code;
+
+ return ret;
+}
+
static int adv7175_g_chip_ident(struct v4l2_subdev *sd, struct
v4l2_dbg_chip_ident *chip)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -324,6 +384,9 @@ static const struct v4l2_subdev_core_ops
adv7175_core_ops = {
static const struct v4l2_subdev_video_ops adv7175_video_ops = {
.s_std_output = adv7175_s_std_output,
.s_routing = adv7175_s_routing,
+ .s_mbus_fmt = adv7175_s_fmt,
+ .g_mbus_fmt = adv7175_g_fmt,
+ .enum_mbus_fmt = adv7175_enum_fmt,
};
static const struct v4l2_subdev_ops adv7175_ops = {
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..11b916d 100644
--- a/include/li
Re: [PATCH 1/3] s5p-csis: Handle all available power supplies
Hi Sylwester,
On Wednesday 06 July 2011 19:13:39 Sylwester Nawrocki wrote:
> On the SoCs this driver is intended to support the are three
> separate pins to supply the MIPI-CSIS subsystem: 1.1V or 1.2V,
> 1.8V and power supply for an internal PLL.
> This patch adds support for two separate voltage supplies
> to cover properly board configurations where PMIC requires
> to configure independently each external supply of the MIPI-CSI
> device. The 1.8V and PLL supply are assigned a single "vdd18"
> regulator supply as it seems more reasonable than creating
> separate regulator supplies for them.
>
> Reported-by: HeungJun Kim
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/s5p-fimc/mipi-csis.c | 42
> + 1 files changed, 25 insertions(+), 17
> deletions(-)
>
> diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c
> b/drivers/media/video/s5p-fimc/mipi-csis.c index ef056d6..4a529b4 100644
> --- a/drivers/media/video/s5p-fimc/mipi-csis.c
> +++ b/drivers/media/video/s5p-fimc/mipi-csis.c
> @@ -81,6 +81,12 @@ static char *csi_clock_name[] = {
> };
> #define NUM_CSIS_CLOCKS ARRAY_SIZE(csi_clock_name)
>
> +static const char * const csis_supply_name[] = {
> + "vdd11", /* 1.1V or 1.2V (s5pc100) MIPI CSI suppply */
> + "vdd18", /* VDD 1.8V and MIPI CSI PLL supply */
> +};
> +#define CSIS_NUM_SUPPLIES ARRAY_SIZE(csis_supply_name)
> +
> enum {
> ST_POWERED = 1,
> ST_STREAMING= 2,
> @@ -109,9 +115,9 @@ struct csis_state {
> struct platform_device *pdev;
> struct resource *regs_res;
> void __iomem *regs;
> + struct regulator_bulk_data supply[CSIS_NUM_SUPPLIES];
I would have called this supplies, but that's nitpicking. Otherwise the patch
looks good to me.
> struct clk *clock[NUM_CSIS_CLOCKS];
> int irq;
> - struct regulator *supply;
> u32 flags;
> const struct csis_pix_format *csis_fmt;
> struct v4l2_mbus_framefmt format;
> @@ -460,6 +466,7 @@ static int __devinit s5pcsis_probe(struct
> platform_device *pdev) struct resource *regs_res;
> struct csis_state *state;
> int ret = -ENOMEM;
> + int i;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (!state)
> @@ -519,13 +526,14 @@ static int __devinit s5pcsis_probe(struct
> platform_device *pdev) goto e_clkput;
> }
>
> + for (i = 0; i < CSIS_NUM_SUPPLIES; i++)
> + state->supply[i].supply = csis_supply_name[i];
> +
> if (!pdata->fixed_phy_vdd) {
> - state->supply = regulator_get(&pdev->dev, "vdd");
> - if (IS_ERR(state->supply)) {
> - ret = PTR_ERR(state->supply);
> - state->supply = NULL;
> + ret = regulator_bulk_get(&pdev->dev, CSIS_NUM_SUPPLIES,
> + state->supply);
> + if (ret)
> goto e_clkput;
> - }
> }
>
> ret = request_irq(state->irq, s5pcsis_irq_handler, 0,
> @@ -561,8 +569,7 @@ static int __devinit s5pcsis_probe(struct
> platform_device *pdev) e_irqfree:
> free_irq(state->irq, state);
> e_regput:
> - if (state->supply)
> - regulator_put(state->supply);
> + regulator_bulk_free(CSIS_NUM_SUPPLIES, state->supply);
> e_clkput:
> clk_disable(state->clock[CSIS_CLK_MUX]);
> s5pcsis_clk_put(state);
> @@ -592,8 +599,9 @@ static int s5pcsis_suspend(struct device *dev)
> ret = pdata->phy_enable(state->pdev, false);
> if (ret)
> goto unlock;
> - if (state->supply) {
> - ret = regulator_disable(state->supply);
> + if (!pdata->fixed_phy_vdd) {
> + ret = regulator_bulk_disable(CSIS_NUM_SUPPLIES,
> + state->supply);
> if (ret)
> goto unlock;
> }
> @@ -622,16 +630,17 @@ static int s5pcsis_resume(struct device *dev)
> goto unlock;
>
> if (!(state->flags & ST_POWERED)) {
> - if (state->supply)
> - ret = regulator_enable(state->supply);
> + if (!pdata->fixed_phy_vdd)
> + ret = regulator_bulk_enable(CSIS_NUM_SUPPLIES,
> + state->supply);
> if (ret)
> goto unlock;
> -
> ret = pdata->phy_enable(state->pdev, true);
> if (!ret) {
> state->flags |= ST_POWERED;
> - } else if (state->supply) {
> - regulator_disable(state->supply);
> + } else if (!pdata->fixed_phy_vdd) {
> + regulator_bulk_disable(CSIS_NUM_SUPPLIES,
> +state->supply);
> goto unlock;
> }
> clk_enab
Re: [PATCHv11 0/8] Contiguous Memory Allocator
On Tue, 5 Jul 2011 14:07:17 +0200 Arnd Bergmann wrote: > On Tuesday 05 July 2011, Marek Szyprowski wrote: > > This is yet another round of Contiguous Memory Allocator patches. I hope > > that I've managed to resolve all the items discussed during the Memory > > Management summit at Linaro Meeting in Budapest and pointed later on > > mailing lists. The goal is to integrate it as tight as possible with > > other kernel subsystems (like memory management and dma-mapping) and > > finally merge to mainline. > > You have certainly addressed all of my concerns, this looks really good now! > > Andrew, can you add this to your -mm tree? What's your opinion on the > current state, do you think this is ready for merging in 3.1 or would > you want to have more reviews from core memory management people? > > My reviews were mostly on the driver and platform API side, and I think > we're fine there now, but I don't really understand the impacts this has > in mm. I could review it and put it in there on a preliminary basis for some runtime testing. But the question in my mind is how different will the code be after the problems which rmk has identified have been fixed? If "not very different" then that effort and testing will have been worthwhile. If "very different" or "unworkable" then it was all for naught. So. Do we have a feeling for the magnitude of the changes which will be needed to fix these things up? -- 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] add support for the dvb-t part of CT-3650 v2
This patch add suport for the dvb-t part of CT-3650.
Jose Alberto
Signed-off-by: Jose Alberto Reguero
diff -ur linux/drivers/media/common/tuners/tda827x.c linux.new/drivers/media/common/tuners/tda827x.c
--- linux/drivers/media/common/tuners/tda827x.c 2010-07-03 23:22:08.0 +0200
+++ linux.new/drivers/media/common/tuners/tda827x.c 2011-07-04 12:00:29.931561053 +0200
@@ -135,14 +135,29 @@
static int tuner_transfer(struct dvb_frontend *fe,
struct i2c_msg *msg,
- const int size)
+ int size)
{
int rc;
struct tda827x_priv *priv = fe->tuner_priv;
+ struct i2c_msg msgr[2];
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- rc = i2c_transfer(priv->i2c_adap, msg, size);
+ if (priv->cfg->i2cr && (msg->flags == I2C_M_RD)) {
+ msgr[0].addr = msg->addr;
+ msgr[0].flags = 0;
+ msgr[0].len = msg->len - 1;
+ msgr[0].buf = msg->buf;
+ msgr[1].addr = msg->addr;
+ msgr[1].flags = I2C_M_RD;
+ msgr[1].len = 1;
+ msgr[1].buf = msg->buf;
+ size = 2;
+ rc = i2c_transfer(priv->i2c_adap, msgr, size);
+ msg->buf[msg->len - 1] = msgr[1].buf[0];
+ } else {
+ rc = i2c_transfer(priv->i2c_adap, msg, size);
+ }
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
@@ -540,7 +555,7 @@
if_freq = 500;
break;
}
- tuner_freq = params->frequency + if_freq;
+ tuner_freq = params->frequency;
if (fe->ops.info.type == FE_QAM) {
dprintk("%s select tda827xa_dvbc\n", __func__);
@@ -554,6 +569,8 @@
i++;
}
+ tuner_freq += if_freq;
+
N = ((tuner_freq + 31250) / 62500) << frequency_map[i].spd;
buf[0] = 0;// subaddress
buf[1] = N >> 8;
diff -ur linux/drivers/media/common/tuners/tda827x.h linux.new/drivers/media/common/tuners/tda827x.h
--- linux/drivers/media/common/tuners/tda827x.h 2010-07-03 23:22:08.0 +0200
+++ linux.new/drivers/media/common/tuners/tda827x.h 2011-05-21 22:48:31.484340005 +0200
@@ -38,6 +38,8 @@
int switch_addr;
void (*agcf)(struct dvb_frontend *fe);
+
+ u8 i2cr;
};
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c 2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c 2011-07-05 12:35:51.842182196 +0200
@@ -30,6 +30,7 @@
#include "tda826x.h"
#include "tda10086.h"
#include "tda1002x.h"
+#include "tda10048.h"
#include "tda827x.h"
#include "lnbp21.h"
@@ -44,6 +45,7 @@
struct ttusb2_state {
u8 id;
u16 last_rc_key;
+ struct dvb_frontend *fe;
};
static int ttusb2_msg(struct dvb_usb_device *d, u8 cmd,
@@ -190,6 +190,22 @@
.deltaf = 0xa511,
};
+static struct tda10048_config tda10048_config = {
+ .demod_address= 0x10 >> 1,
+ .output_mode = TDA10048_PARALLEL_OUTPUT,
+ .inversion= TDA10048_INVERSION_ON,
+ .dtv6_if_freq_khz = TDA10048_IF_4000,
+ .dtv7_if_freq_khz = TDA10048_IF_4500,
+ .dtv8_if_freq_khz = TDA10048_IF_5000,
+ .clk_freq_khz = TDA10048_CLK_16000,
+ .no_firmware = 1,
+};
+
+static struct tda827x_config tda827x_config = {
+ .i2cr = 1,
+ .config = 0,
+};
+
static int ttusb2_frontend_tda10086_attach(struct dvb_usb_adapter *adap)
{
if (usb_set_interface(adap->dev->udev,0,3) < 0)
@@ -205,18 +221,32 @@
static int ttusb2_frontend_tda10023_attach(struct dvb_usb_adapter *adap)
{
+
+ struct ttusb2_state *state;
if (usb_set_interface(adap->dev->udev, 0, 3) < 0)
err("set interface to alts=3 failed");
+ state = (struct ttusb2_state *)adap->dev->priv;
if ((adap->fe = dvb_attach(tda10023_attach, &tda10023_config, &adap->dev->i2c_adap, 0x48)) == NULL) {
deb_info("TDA10023 attach failed\n");
return -ENODEV;
}
+ adap->fe->id = 1;
+ tda10048_config.fe = adap->fe;
+ if ((state->fe = dvb_attach(tda10048_attach, &tda10048_config, &adap->dev->i2c_adap)) == NULL) {
+ deb_info("TDA10048 attach failed\n");
+ return -ENODEV;
+ }
+ dvb_register_frontend(&adap->dvb_adap, state->fe);
+ if (dvb_attach(tda827x_attach, state->fe, 0x61, &adap->dev->i2c_adap, &tda827x_config) == NULL) {
+ printk(KERN_ERR "%s: No tda827x found!\n", __func__);
+ return -ENODEV;
+ }
return 0;
}
static int ttusb2_tuner_tda827x_attach(struct dvb_usb_adapter *adap)
{
- if (dvb_attach(tda827x_attach, adap->fe, 0x61, &adap->dev->i2c_adap, NULL) == NULL) {
+ if (dvb_attach(tda827x_attach, adap->fe, 0x61, &adap->dev->i2c_adap, &tda827x_config) == NULL) {
printk(KERN_ERR "%s: No tda827x found!\n", __func__);
return -ENODEV;
}
@@ -242,6 +272,19 @@
static struct dvb_usb_device_properties ttusb2_properties_s2400;
static struct dvb_usb_device_properties ttusb2_properties_ct3650;
+static void ttusb2_usb_disconnect (struct usb_interface *intf)
+{
+ struct dvb_usb_device *d = usb_get_intfdata (intf);
+ struct ttusb2_state * state;
+
+ state = (struct ttusb2_state *)d->priv;
+ if (state->fe) {
+ dvb_unregister_frontend(state->fe);
+ dvb_frontend_detach(state->fe);
+ }
+ dvb_usb_device_exit (intf);
+}
+
static int ttusb2_probe(struct usb_interface *intf,
cons
Re: [PATCH v8 1/2] Add driver for Aptina Micron mt9p031 sensor.
Hi Javier, On Monday 04 July 2011 13:25:10 javier Martin wrote: > Hi, Laurent. > How is it going? > > Is there any chance these changes to be included for next release? > We are afraid that changes in the framework may turn the patches useless. I've applied the patch to my tree and I'm working on a couple of fixes. I'll try to finish that ASAP, but I'm quite busy at the moment :-S -- 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: SV: omap3isp - H3A auto white balance
Hi Daniel, On Wednesday 01 June 2011 10:49:43 Daniel Lundborg wrote: > > On Tuesday 31 May 2011 12:07:08 Daniel Lundborg wrote: > > > > [snip] > > > > > > Any chance you will submit the driver for inclusion in the kernel? > > > Yes if there is an interest in it. I can create a patch from your > > > omap3isp-next-sensors tree if you want. > > > > That would be nice, thank you. > > Here's the patch: [snip] The patch is corrupted as your mailer wraps lines. Could you please fix that, or send it as an attachement ? Please also include a commit message with your SoB line. -- 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: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator
On Wed, 6 Jul 2011, Arnd Bergmann wrote: > On Wednesday 06 July 2011 21:10:07 Nicolas Pitre wrote: > > If you get a highmem page, because the cache is VIPT, that page might > > still be cached even if it wasn't mapped. With a VIVT cache we must > > flush the cache whenever a highmem page is unmapped. There is no such > > restriction with VIPT i.e. ARMv6 and above. Therefore to make sure the > > highmem page you get doesn't have cache lines associated to it, you must > > first map it cacheable, then perform cache invalidation on it, and > > eventually remap it as non-cacheable. This is necessary because there > > is no way to perform cache maintenance on L1 cache using physical > > addresses unfortunately. See commit 7e5a69e83b for an example of what > > this entails (fortunately commit 3e4d3af501 made things much easier and > > therefore commit 39af22a79 greatly simplified things). > > Ok, thanks for the explanation. This definitely makes the highmem approach > much harder to get right, and slower. Let's hope then that Marek's approach > of using small pages for the contiguous memory region and changing their > attributes on the fly works out better than this. I would say that both approaches have fairly equivalent complexity. Nicolas -- 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 for v3.0] OMAP_VOUT bug fixes and code cleanup
> -Original Message-
> From: David Rientjes [mailto:rient...@google.com]
> Sent: Thursday, July 07, 2011 2:14 AM
> To: JAIN, AMBER
> Cc: Mauro Carvalho Chehab; Hiremath, Vaibhav; linux-media@vger.kernel.org;
> Andrew Morton
> Subject: RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
>
> On Tue, 5 Jul 2011, JAIN, AMBER wrote:
>
> > > > diff --git a/drivers/media/video/omap24xxcam.c
> > > b/drivers/media/video/omap24xxcam.c
> > > > index f6626e8..d92d4c6 100644
> > > > --- a/drivers/media/video/omap24xxcam.c
> > > > +++ b/drivers/media/video/omap24xxcam.c
> > > > @@ -309,11 +309,11 @@ static int
> > > omap24xxcam_vbq_alloc_mmap_buffer(struct videobuf_buffer *vb)
> > > > order--;
> > > >
> > > > /* try to allocate as many contiguous pages as possible
> */
> > > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
> > > > + page = alloc_pages(GFP_KERNEL, order);
> > > > /* if allocation fails, try to allocate smaller amount
> */
> > > > while (page == NULL) {
> > > > order--;
> > > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
> > > > + page = alloc_pages(GFP_KERNEL, order);
> > > > if (page == NULL && !order) {
> > > > err = -ENOMEM;
> > > > goto out;
> > >
> > > Hmm... the proper fix wouldn't be to define ZONE_DMA at OMAP?
> >
> > I don't think so, my understanding for ZOME_DMA is that it is defined
> > for architectures that have restrictions on memory addresses that can be
> > used for DMA. OMAP doesn't have any such restriction and hence we should
> > not define ZONE_DMA.
> >
>
> s/should not define/do not need to define/
>
> Right, if omap does not have DMA restrictions then the GFP_DMA usage that
> is removed with this patch was incorrect.
[Hiremath, Vaibhav] I did not understand your comment; can you please help me
to understand here?
Thanks,
Vaibhav
--
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 for v3.0] OMAP_VOUT bug fixes and code cleanup
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Thursday, July 07, 2011 11:25 AM
> To: David Rientjes; JAIN, AMBER
> Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; Andrew Morton
> Subject: RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
>
> > -Original Message-
> > From: David Rientjes [mailto:rient...@google.com]
> > Sent: Thursday, July 07, 2011 2:14 AM
> > To: JAIN, AMBER
> > Cc: Mauro Carvalho Chehab; Hiremath, Vaibhav; linux-
> me...@vger.kernel.org;
> > Andrew Morton
> > Subject: RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
> >
> > On Tue, 5 Jul 2011, JAIN, AMBER wrote:
> >
> > > > > diff --git a/drivers/media/video/omap24xxcam.c
> > > > b/drivers/media/video/omap24xxcam.c
> > > > > index f6626e8..d92d4c6 100644
> > > > > --- a/drivers/media/video/omap24xxcam.c
> > > > > +++ b/drivers/media/video/omap24xxcam.c
> > > > > @@ -309,11 +309,11 @@ static int
> > > > omap24xxcam_vbq_alloc_mmap_buffer(struct videobuf_buffer *vb)
> > > > > order--;
> > > > >
> > > > > /* try to allocate as many contiguous pages as possible
> > */
> > > > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
> > > > > + page = alloc_pages(GFP_KERNEL, order);
> > > > > /* if allocation fails, try to allocate smaller amount
> > */
> > > > > while (page == NULL) {
> > > > > order--;
> > > > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
> > > > > + page = alloc_pages(GFP_KERNEL, order);
> > > > > if (page == NULL && !order) {
> > > > > err = -ENOMEM;
> > > > > goto out;
> > > >
> > > > Hmm... the proper fix wouldn't be to define ZONE_DMA at OMAP?
> > >
> > > I don't think so, my understanding for ZOME_DMA is that it is defined
> > > for architectures that have restrictions on memory addresses that can
> be
> > > used for DMA. OMAP doesn't have any such restriction and hence we
> should
> > > not define ZONE_DMA.
> > >
> >
> > s/should not define/do not need to define/
> >
> > Right, if omap does not have DMA restrictions then the GFP_DMA usage
> that
> > is removed with this patch was incorrect.
> [Hiremath, Vaibhav] I did not understand your comment; can you please help
> me to understand here?
I think what David wants to say is that if we do not have DMA restrictions on
OMAP we should have not used GFP_DMA flag for page allocation at first place.
Is my understanding correct David?
~Amber
>
> Thanks,
> Vaibhav
--
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
