RE: [RFD] frame-size switching: preview / single-shot use-case
Hi, On Tue, 15 Feb 2011, Qing Xu wrote: Please, don't top-post and use a proper quoting. > Hi, > > I have a question that why we must check "icf->vb_vidq.bufs[0]" in > s_fmt_vid_cap()? The application mainly calling sequence at switching > fmt could be like this: > streamoff > s_fmt_vid_cap > request_buf > qbuf...qbuf > streamon > qbuf/dqbuf > ... > The application should also aware that they are switching the fmt, > so they should release their buffer(per in usrptr method), and re-call > request-buf/qbuf, so based on this assumption, how about we check "bufs[0]" > in request_buf or qbuf according to the new fmt, if we find the buffer > size is not correct, then indicate error in request_buf or qbuf. > However,in s_fmt_vid_cap, > we only need to check whether streaming is on/off, if it is still on, > that means HW resource is not available or IO/buffer is in progress, then > we reject s_fmt. What do you think? Yes, that restriction is in a way more conservative, than it needs to be. I did that to (a) simplify the design and implementation: that way you don't have to worry about S_FMT calls in your drivers during a running capture, and to (b) verify whether that can be a problem for anyone and to hear from them;) > For the idea 3, (what is the difference between idea 1 and 3?) (1) proposes to add multiple inputs to the video device, selectable per VIDIOC_S_INPUT, (3) doesn't touch inputs and only proposes to add multiple videobuf queues to devices, adding a special ioctl(). > in our real usage cases of camera(our product is a phone), > we will set many formats, such as: > preview@VGA, photos@5M/3M/QVGA/QCIF..., video@1080p/720p/VGA/QVGA, if we > maintain each queue for each fmt, it seems that there are too many queues, > and, in this way, the application need to be changed, it should quite > aware of VIDIOC_BUFQ_SELECT queue-id for each fmt, then it could > allocate/release > the required buffer queue by new ioctl. Is my understanding correct? Of course, with case (3) from my original post, if you want to use those multiple queues, you _have_ to modify your application. Same holds for (1) and (2) too. As for too many queues - well, you can decide then. Maybe you don't need a separate queue for each format, maybe you could use one queue for several still-shot queues with similar buffer sizes and buffer numbers. Or you don't need them all simultaneously, depending on your use-case. If you have an interface, where the user only switches between preview and still images, the still image format is usually fixed. To select a different format the user has to go to some kind of a configuration menu and select a different image format, right? Which would be a good time to release the previous still image queue and allocate a new one. Thanks Guennadi > > Thanks! > -Qing > > -Original Message- > From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] > Sent: 2011Äê2ÔÂ16ÈÕ 1:34 > To: Linux Media Mailing List > Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert; > Karicheri, Muralidharan; Eino-Ville Talvala > Subject: [RFD] frame-size switching: preview / single-shot use-case > > Hi > > This topic has been slightly discussed several times [1] before, but there > has been no conclusion, nor I'm aware of any implementation, suitably > resolving this problem. I've added to CC all involved in earlier > discussions, that I managed to find. > > What seems a typical use-case to me is a system with a vewfinder or a > display, providing a live preview of the video data from a source, like a > camera, with a relatively low resolution, and a possibility to take > high-resolution still photos with a very short delay. > > Currently this is pretty difficult to realise, e.g., with soc-camera > drivers you have to free the videobuf(2) queue, by either closing and > re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS, > count=0) if your driver is already using videobuf2 and if this is really > working;), configure with a different resolution and re-allocate > videobuffers (or use different buffers, allocated per USERPTR). Another > possibility would be to allocate and use buffers large enough for still > photos, also for the preview, which would be wasteful, because one can > well need many more preview than still-shot buffers. > > So, it seems to me, we could live with a better solution. > > 1. We could use separate inputs for different capture modes and support > per-input videobuf queues. Advantage: no API changes required. > Disadvantages: confusing, especially, if a driver already exports multiple > inputs. The driver does not know, whether this mode is required or not, > always exporting 2 inputs for this purpose doesn't seem like a good idea. > Eventually, the user might want not 2, but 3 or more of such videobuf > queues. > > 2. Use different IO methods, e.g., mmap() for preview and read() for still > shots. I'm just mentioning this possibility her
Re: [PATCH v2 1/1] [media] ov9740: Initial submission of OV9740 driver
Hi Andrew, On Tuesday, February 15, 2011 23:28:38 ac...@nvidia.com wrote: > From: Andrew Chew > > This driver is for Omnivision's OV9740 sensor. This initial submission > provides support for YUV422 output at 1280x720 (the sensor's native > resolution), and 640x480 (cropping and scaling performed by the sensor's ISP). > > This driver is heavily based off of the existing OV9640 driver. > > Change-Id: I4a75d097143a189a5ec0ae0a7be8d8f3531ea155 > Signed-off-by: Andrew Chew > --- > Applied comments by Hans Verkuil, to wit: use new control framework to > support the two controls (VFLIP, HFLIP). Based this work on > drivers/media/video/noon010pc30.c. > > Note that I did not test these new changes. I'm not in a position to build > a kernel that will come up far enough on my platform to test this, with the > linux-next tree. I have to apologize: I overlooked that you are using the soc-camera framework. Unfortunately, the soc-camera framework does not yet support the control framework so you can't use that yet. In other words, the first version of your patch is the right version. You didn't do this conversion for nothing, though, as I hope that soc-camera will be converted to the control framework in 2.6.40. I have patches ready for that, but I need to do some additional work first and my time is very limited at the moment :-( I have CC-ed the soc-camera maintainer as well. Guennadi, when you do your review, please look at the first version of this patch and ignore this one :-) Regards, Hans > > drivers/media/video/Kconfig |6 + > drivers/media/video/Makefile|1 + > drivers/media/video/ov9740.c| 993 > +++ > include/media/v4l2-chip-ident.h |1 + > 4 files changed, 1001 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/ov9740.c > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index d40a8fc..52b6271 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -837,6 +837,12 @@ config SOC_CAMERA_OV9640 > help > This is a ov9640 camera driver > > +config SOC_CAMERA_OV9740 > + tristate "ov9740 camera support" > + depends on SOC_CAMERA && I2C > + help > + This is a ov9740 camera driver > + > config MX1_VIDEO > bool > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 251b7ca..ac54652 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -79,6 +79,7 @@ obj-$(CONFIG_SOC_CAMERA_OV2640) += ov2640.o > obj-$(CONFIG_SOC_CAMERA_OV6650) += ov6650.o > obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o > obj-$(CONFIG_SOC_CAMERA_OV9640) += ov9640.o > +obj-$(CONFIG_SOC_CAMERA_OV9740) += ov9740.o > obj-$(CONFIG_SOC_CAMERA_RJ54N1) += rj54n1cb0c.o > obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o > > diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c > new file mode 100644 > index 000..309a5f1 > --- /dev/null > +++ b/drivers/media/video/ov9740.c > @@ -0,0 +1,993 @@ > +/* > + * OmniVision OV9740 Camera Driver > + * > + * Copyright (C) 2011 NVIDIA Corporation > + * > + * Based on ov9640 camera driver. > + * > + * 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 > + > +#define to_ov9740_sensor(sd) container_of(sd, struct ov9740_priv, subdev) > +#define to_sd(ctrl) (&container_of(ctrl->handler, \ > + struct ov9740_priv, \ > + ctrl_handler)->subdev) > + > +/* General Status Registers */ > +#define OV9740_MODEL_ID_HI 0x > +#define OV9740_MODEL_ID_LO 0x0001 > +#define OV9740_REVISION_NUMBER 0x0002 > +#define OV9740_MANUFACTURER_ID 0x0003 > +#define OV9740_SMIA_VERSION 0x0004 > + > +/* General Setup Registers */ > +#define OV9740_MODE_SELECT 0x0100 > +#define OV9740_IMAGE_ORT 0x0101 > +#define OV9740_SOFTWARE_RESET0x0103 > +#define OV9740_GRP_PARAM_HOLD0x0104 > +#define OV9740_MSK_CORRUP_FM 0x0105 > + > +/* Timing Setting */ > +#define OV9740_FRM_LENGTH_LN_HI 0x0340 /*VTS*/ > +#define OV9740_FRM_LENGTH_LN_LO 0x0341 /*VTS*/ > +#define OV9740_LN_LENGTH_PCK_HI 0x0342 /*HTS*/ > +#define OV9740_LN_LENGTH_PCK_LO 0x0343 /*HTS*/ > +#define OV9740_X_ADDR_START_HI 0x0344 > +#define OV9740_X_ADDR_START_LO 0x0345 > +#define OV9740_Y_ADDR_START_HI 0x0346 > +#define OV9740_Y_ADDR_START_LO 0x0347 > +#define OV9740_X_ADDR_END_HI 0x034
Re: soc-camera: Benefits of soc-camera interface over specific char drivers that use Gstreamer lib
Hi Bhupesh
On Wed, 16 Feb 2011, Bhupesh SHARMA wrote:
> Hi Guennadi,
>
> As I mentioned in one of my previous mails , we are developing a Camera Host
> and
> Sensor driver for our ST specific SoC and considering using the soc-camera
> framework
> for the same. One of our open-source customers has raised a interesting case
> though:
>
> It seems they have an existing solution (for another SoC) in which they do
> not use V4L2
> framework and instead use the Gstreamer with framebuffer.
Don't see how gstreamer ("with framebuffer") can replace V4L2 source, I
only know a fbdev _sink_ plugin for gstreamer, and no framebuffer source
plugin. So, either this is a propriatory extension to gstreamer, or you
mean something different here.
> They specifically wish us to
> implement a solution which is compatible with ANDROID applications.
AFAIU, android only specifies higher level Java application APIs, and it
doesn't specify what you use at the device-node level. I know, that first
(msm) android implementations didn't use V4L and used a custom character
device for video data, which is totally incompatible with the mainline
Linux.
> Could you please help us in deciding which approach is preferable in terms of
> performance, maintenance and ease-of-design.
Sorry, no, I have no idea about performance and ease of design, but it
might be related to maintenance: your choice is basically between a custom
character device, which only the specific android implementations know how
to use, and a standard V4L2 (not necessarily soc-camera) implementation,
which will immediately work for any Linux-based solution on your system. I
believe, there have already been android ports, using V4L2 for video
source, it is true, that some (mostly optional) android API calls don't
have direct analogs in V4L2, and, therefore, have so far to be emulated,
but I also think, there are a few users, that would be interested in
extending V4L2 to better support those android API calls.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] rc: do not enable remote controller adapters by default.
Having the RC_CORE config default to INPUT is almost equivalent to saying "yes". Default to "no" instead. Signed-off-by: Stephen Wilson --- drivers/media/rc/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 3785162..8842843 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -1,7 +1,7 @@ menuconfig RC_CORE tristate "Remote Controller adapters" depends on INPUT - default INPUT + default n ---help--- Enable support for Remote Controllers on Linux. This is needed in order to support several video capture adapters. -- 1.7.3.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
soc-camera: Benefits of soc-camera interface over specific char drivers that use Gstreamer lib
Hi Guennadi, As I mentioned in one of my previous mails , we are developing a Camera Host and Sensor driver for our ST specific SoC and considering using the soc-camera framework for the same. One of our open-source customers has raised a interesting case though: It seems they have an existing solution (for another SoC) in which they do not use V4L2 framework and instead use the Gstreamer with framebuffer. They specifically wish us to implement a solution which is compatible with ANDROID applications. Could you please help us in deciding which approach is preferable in terms of performance, maintenance and ease-of-design. Thanks for your help. Regards, Bhupesh ST Microelectronics -- 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
Afatech AF9015 & dual tuner - dual_mode B.R.O.K.E.N.
To num_adapters = 2, or num_adapters = 1: that is the question! rgds, poma -- 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: [RFD] frame-size switching: preview / single-shot use-case
Add Kassey and Angela in the loop. Thanks!
-Qing
-Original Message-
From: Qing Xu
Sent: 2011年2月16日 10:51
To: 'Guennadi Liakhovetski'; Linux Media Mailing List
Cc: Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert; Karicheri,
Muralidharan; Eino-Ville Talvala
Subject: RE: [RFD] frame-size switching: preview / single-shot use-case
Hi,
I have a question that why we must check "icf->vb_vidq.bufs[0]" in
s_fmt_vid_cap()? The application mainly calling sequence at switching
fmt could be like this:
streamoff
s_fmt_vid_cap
request_buf
qbuf...qbuf
streamon
qbuf/dqbuf
...
The application should also aware that they are switching the fmt,
so they should release their buffer(per in usrptr method), and re-call
request-buf/qbuf, so based on this assumption, how about we check "bufs[0]"
in request_buf or qbuf according to the new fmt, if we find the buffer
size is not correct, then indicate error in request_buf or qbuf.
However,in s_fmt_vid_cap,
we only need to check whether streaming is on/off, if it is still on,
that means HW resource is not available or IO/buffer is in progress, then
we reject s_fmt. What do you think?
For the idea 3, (what is the difference between idea 1 and 3?)
in our real usage cases of camera(our product is a phone),
we will set many formats, such as:
preview@VGA, photos@5M/3M/QVGA/QCIF..., video@1080p/720p/VGA/QVGA, if we
maintain each queue for each fmt, it seems that there are too many queues,
and, in this way, the application need to be changed, it should quite aware of
VIDIOC_BUFQ_SELECT queue-id for each fmt, then it could allocate/release
the required buffer queue by new ioctl. Is my understanding correct?
Thanks!
-Qing
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: 2011年2月16日 1:34
To: Linux Media Mailing List
Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert;
Karicheri, Muralidharan; Eino-Ville Talvala
Subject: [RFD] frame-size switching: preview / single-shot use-case
Hi
This topic has been slightly discussed several times [1] before, but there
has been no conclusion, nor I'm aware of any implementation, suitably
resolving this problem. I've added to CC all involved in earlier
discussions, that I managed to find.
What seems a typical use-case to me is a system with a vewfinder or a
display, providing a live preview of the video data from a source, like a
camera, with a relatively low resolution, and a possibility to take
high-resolution still photos with a very short delay.
Currently this is pretty difficult to realise, e.g., with soc-camera
drivers you have to free the videobuf(2) queue, by either closing and
re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS,
count=0) if your driver is already using videobuf2 and if this is really
working;), configure with a different resolution and re-allocate
videobuffers (or use different buffers, allocated per USERPTR). Another
possibility would be to allocate and use buffers large enough for still
photos, also for the preview, which would be wasteful, because one can
well need many more preview than still-shot buffers.
So, it seems to me, we could live with a better solution.
1. We could use separate inputs for different capture modes and support
per-input videobuf queues. Advantage: no API changes required.
Disadvantages: confusing, especially, if a driver already exports multiple
inputs. The driver does not know, whether this mode is required or not,
always exporting 2 inputs for this purpose doesn't seem like a good idea.
Eventually, the user might want not 2, but 3 or more of such videobuf
queues.
2. Use different IO methods, e.g., mmap() for preview and read() for still
shots. I'm just mentioning this possibility here, because it occurred in
one of previous threads, but I don't really like it either. What if you
want to use the same IO method for all? Etc.
3. Not liking either of the above, it seems we need yet a new API for
this... How about extending VIDIOC_REQBUFS with a videobuf queue index,
thus using up one of the remaining two 32-bit reserved fields? Then we
need one more ioctl() like VIDIOC_BUFQ_SELECT to switch from one queue to
another, after which setting frame format and queuing and dequeuing
buffers will affect this currently selected queue. We could also keep
REQBUFS as is and require BUFQ_SELECT to be called before it for any queue
except the default 0.
Yes, I know, that some video sensors have a double register set for this
dual-format operation, so, for them it is natural to support two queues,
and drivers are certainly most welcome to use this feature for, say, the
first two queues. On other sensors and for any further queues switching
will have to be done in software.
Ideas? Comments?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{���bj)��骅w* jg�报 �茛j/�赇z罐���2���ㄨ��&�)摺�a囤�� �G���h��j:+v���w��佶
RE: [RFD] frame-size switching: preview / single-shot use-case
Hi, I have a question that why we must check "icf->vb_vidq.bufs[0]" in s_fmt_vid_cap()? The application mainly calling sequence at switching fmt could be like this: streamoff s_fmt_vid_cap request_buf qbuf...qbuf streamon qbuf/dqbuf ... The application should also aware that they are switching the fmt, so they should release their buffer(per in usrptr method), and re-call request-buf/qbuf, so based on this assumption, how about we check "bufs[0]" in request_buf or qbuf according to the new fmt, if we find the buffer size is not correct, then indicate error in request_buf or qbuf. However,in s_fmt_vid_cap, we only need to check whether streaming is on/off, if it is still on, that means HW resource is not available or IO/buffer is in progress, then we reject s_fmt. What do you think? For the idea 3, (what is the difference between idea 1 and 3?) in our real usage cases of camera(our product is a phone), we will set many formats, such as: preview@VGA, photos@5M/3M/QVGA/QCIF..., video@1080p/720p/VGA/QVGA, if we maintain each queue for each fmt, it seems that there are too many queues, and, in this way, the application need to be changed, it should quite aware of VIDIOC_BUFQ_SELECT queue-id for each fmt, then it could allocate/release the required buffer queue by new ioctl. Is my understanding correct? Thanks! -Qing -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: 2011年2月16日 1:34 To: Linux Media Mailing List Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert; Karicheri, Muralidharan; Eino-Ville Talvala Subject: [RFD] frame-size switching: preview / single-shot use-case Hi This topic has been slightly discussed several times [1] before, but there has been no conclusion, nor I'm aware of any implementation, suitably resolving this problem. I've added to CC all involved in earlier discussions, that I managed to find. What seems a typical use-case to me is a system with a vewfinder or a display, providing a live preview of the video data from a source, like a camera, with a relatively low resolution, and a possibility to take high-resolution still photos with a very short delay. Currently this is pretty difficult to realise, e.g., with soc-camera drivers you have to free the videobuf(2) queue, by either closing and re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS, count=0) if your driver is already using videobuf2 and if this is really working;), configure with a different resolution and re-allocate videobuffers (or use different buffers, allocated per USERPTR). Another possibility would be to allocate and use buffers large enough for still photos, also for the preview, which would be wasteful, because one can well need many more preview than still-shot buffers. So, it seems to me, we could live with a better solution. 1. We could use separate inputs for different capture modes and support per-input videobuf queues. Advantage: no API changes required. Disadvantages: confusing, especially, if a driver already exports multiple inputs. The driver does not know, whether this mode is required or not, always exporting 2 inputs for this purpose doesn't seem like a good idea. Eventually, the user might want not 2, but 3 or more of such videobuf queues. 2. Use different IO methods, e.g., mmap() for preview and read() for still shots. I'm just mentioning this possibility here, because it occurred in one of previous threads, but I don't really like it either. What if you want to use the same IO method for all? Etc. 3. Not liking either of the above, it seems we need yet a new API for this... How about extending VIDIOC_REQBUFS with a videobuf queue index, thus using up one of the remaining two 32-bit reserved fields? Then we need one more ioctl() like VIDIOC_BUFQ_SELECT to switch from one queue to another, after which setting frame format and queuing and dequeuing buffers will affect this currently selected queue. We could also keep REQBUFS as is and require BUFQ_SELECT to be called before it for any queue except the default 0. Yes, I know, that some video sensors have a double register set for this dual-format operation, so, for them it is natural to support two queues, and drivers are certainly most welcome to use this feature for, say, the first two queues. On other sensors and for any further queues switching will have to be done in software. Ideas? Comments? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
Re: [PATCH v19 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.
On Tue, Feb 15, 2011 at 10:13:46AM +0200, Matti J. Aaltonen wrote:
> if (core->i2s_mode != mode) {
> - r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET, mode);
> + r = core->write(core, WL1273_I2S_MODE_CONFIG_SET, mode);
I'm having a hard time loving the replacement of the function with the
direct dereference from the struct but overall this is a good win so:
Acked-by: Mark Brown
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] [media] ov9740: Initial submission of OV9740 driver
From: Andrew Chew This driver is for Omnivision's OV9740 sensor. This initial submission provides support for YUV422 output at 1280x720 (the sensor's native resolution), and 640x480 (cropping and scaling performed by the sensor's ISP). This driver is heavily based off of the existing OV9640 driver. Change-Id: I4a75d097143a189a5ec0ae0a7be8d8f3531ea155 Signed-off-by: Andrew Chew --- Applied comments by Hans Verkuil, to wit: use new control framework to support the two controls (VFLIP, HFLIP). Based this work on drivers/media/video/noon010pc30.c. Note that I did not test these new changes. I'm not in a position to build a kernel that will come up far enough on my platform to test this, with the linux-next tree. drivers/media/video/Kconfig |6 + drivers/media/video/Makefile|1 + drivers/media/video/ov9740.c| 993 +++ include/media/v4l2-chip-ident.h |1 + 4 files changed, 1001 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ov9740.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index d40a8fc..52b6271 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -837,6 +837,12 @@ config SOC_CAMERA_OV9640 help This is a ov9640 camera driver +config SOC_CAMERA_OV9740 + tristate "ov9740 camera support" + depends on SOC_CAMERA && I2C + help + This is a ov9740 camera driver + config MX1_VIDEO bool diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 251b7ca..ac54652 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -79,6 +79,7 @@ obj-$(CONFIG_SOC_CAMERA_OV2640) += ov2640.o obj-$(CONFIG_SOC_CAMERA_OV6650)+= ov6650.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_OV9640)+= ov9640.o +obj-$(CONFIG_SOC_CAMERA_OV9740)+= ov9740.o obj-$(CONFIG_SOC_CAMERA_RJ54N1)+= rj54n1cb0c.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c new file mode 100644 index 000..309a5f1 --- /dev/null +++ b/drivers/media/video/ov9740.c @@ -0,0 +1,993 @@ +/* + * OmniVision OV9740 Camera Driver + * + * Copyright (C) 2011 NVIDIA Corporation + * + * Based on ov9640 camera driver. + * + * 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 + +#define to_ov9740_sensor(sd) container_of(sd, struct ov9740_priv, subdev) +#define to_sd(ctrl)(&container_of(ctrl->handler, \ + struct ov9740_priv, \ + ctrl_handler)->subdev) + +/* General Status Registers */ +#define OV9740_MODEL_ID_HI 0x +#define OV9740_MODEL_ID_LO 0x0001 +#define OV9740_REVISION_NUMBER 0x0002 +#define OV9740_MANUFACTURER_ID 0x0003 +#define OV9740_SMIA_VERSION0x0004 + +/* General Setup Registers */ +#define OV9740_MODE_SELECT 0x0100 +#define OV9740_IMAGE_ORT 0x0101 +#define OV9740_SOFTWARE_RESET 0x0103 +#define OV9740_GRP_PARAM_HOLD 0x0104 +#define OV9740_MSK_CORRUP_FM 0x0105 + +/* Timing Setting */ +#define OV9740_FRM_LENGTH_LN_HI0x0340 /*VTS*/ +#define OV9740_FRM_LENGTH_LN_LO0x0341 /*VTS*/ +#define OV9740_LN_LENGTH_PCK_HI0x0342 /*HTS*/ +#define OV9740_LN_LENGTH_PCK_LO0x0343 /*HTS*/ +#define OV9740_X_ADDR_START_HI 0x0344 +#define OV9740_X_ADDR_START_LO 0x0345 +#define OV9740_Y_ADDR_START_HI 0x0346 +#define OV9740_Y_ADDR_START_LO 0x0347 +#define OV9740_X_ADDR_END_HI 0x0348 +#define OV9740_X_ADDR_END_LO 0x0349 +#define OV9740_Y_ADDR_END_HI 0x034A +#define OV9740_Y_ADDR_END_LO 0x034B +#define OV9740_X_OUTPUT_SIZE_HI0x034C +#define OV9740_X_OUTPUT_SIZE_LO0x034D +#define OV9740_Y_OUTPUT_SIZE_HI0x034E +#define OV9740_Y_OUTPUT_SIZE_LO0x034F + +/* IO Control Registers */ +#define OV9740_IO_CREL00 0x3002 +#define OV9740_IO_CREL01 0x3004 +#define OV9740_IO_CREL02 0x3005 +#define OV9740_IO_OUTPUT_SEL01 0x3026 +#define OV9740_IO_OUTPUT_SEL02 0x3027 + +/* AWB Registers */ +#define OV9740_AWB_MANUAL_CTRL 0x3406 + +/* Analog Control Registers */ +#define OV9740_ANALOG_CTRL01 0x3601 +#define OV9740_ANALOG_CTRL02 0x3602 +#define OV9740_ANALOG_CTRL03 0x3603 +#define OV9740_ANALOG_CTRL04 0x3604 +#define OV9740_ANALOG_CTRL10 0x3610 +#define OV9740
Re: Non-portable code in em28XX driver
Em 15-02-2011 17:16, Vitaly Makarov escreveu:
> Dear Mauro,
> In your patch 12406 to v4l-dvb dev tree there is a small problem:
> --
>
> diff -r 13a35e80e987 -r 8f9eee4fd803
> linux/drivers/media/video/em28xx/em28xx-core.c
> --- a/linux/drivers/media/video/em28xx/em28xx-core.cFri Aug 07 18:43:00
> 2009 -0300
> +++ b/linux/drivers/media/video/em28xx/em28xx-core.cSat Aug 08 03:14:55
> 2009 -0300
> @@ -720,7 +720,10 @@
> {
> int width, height;
> width = norm_maxw(dev);
> - height = norm_maxh(dev) >> 1;
> + height = norm_maxh(dev);
> +
> + if (!dev->progressive)
> + height >>= norm_maxh(dev);
>
> em28xx_set_outfmt(dev);
>
> --
> In the line "height >>= norm_maxh(dev)" undefined behavior has been
> introduced. There is an attempt to shift the number to a big number of
> bits which is not defined by C standard and leads to unpredictable
> results. For example it will work on Intel because there it will
> translate to no shift at all which seems to be unexpected as well. But
> if you enable global optimization or compile this code for ARM the
> result will be 0.
> It seems like this line should look like "height = norm_maxh(dev) >> 1"
Yes, I suspect so. Could you please make us a patch for 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] cx23885: restore flushes of cx23885_dev work items
Em 15-02-2011 07:20, Tejun Heo escreveu:
> Commit 8c71778c (media/video: don't use flush_scheduled_work())
> dropped flush_scheduled_work() from cx23885_input_ir_stop()
> incorrectly assuming that it didn't use any work item; however,
> cx23885_dev makes use of three work items - cx25840_work and
> ir_{r|t}x_work.
>
> Make cx23885_input_ir_stop() sync flush all three work items before
> returning.
>
> Signed-off-by: Tejun Heo
> Reported-by: Andy Walls
> Reviewed-by: Andy Walls
> Cc: Dmitry Torokhov
> Cc: Mauro Carvalho Chehab
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/media/video/cx23885/cx23885-input.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/video/cx23885/cx23885-input.c
> b/drivers/media/video/cx23885/cx23885-input.c
> index 199b996..e27cedb 100644
> --- a/drivers/media/video/cx23885/cx23885-input.c
> +++ b/drivers/media/video/cx23885/cx23885-input.c
> @@ -229,6 +229,9 @@ static void cx23885_input_ir_stop(struct cx23885_dev *dev)
> v4l2_subdev_call(dev->sd_ir, ir, rx_s_parameters, ¶ms);
> v4l2_subdev_call(dev->sd_ir, ir, rx_g_parameters, ¶ms);
> }
> + flush_work_sync(&dev->cx25840_work);
> + flush_work_sync(&dev->ir_rx_work);
> + flush_work_sync(&dev->ir_tx_work);
> }
>
> static void cx23885_input_ir_close(struct rc_dev *rc)
--
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 v19 0/3] TI Wl1273 FM radio driver.
Em 15-02-2011 06:13, Matti J. Aaltonen escreveu: > Hello. > > Now I've refactored the code so that the I2C I/O functions are in the > MFD core. Also now the codec can be compiled without compiling the V4L2 > driver. > > I haven't implemented the audio routing (yet), but I've added a TODO > comment about it in the codec file. Matti, It looks ok on my eyes. As most of the changes is at the V4L part, it is probably better to merge this patch via my tree. Cheers, 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 1/4] [media] tuner-core: remove usage of DIGITAL_TV
Em 15-02-2011 15:25, Andy Walls escreveu:
> Mauro Carvalho Chehab wrote:
>
>> tuner-core has no business to do with digital TV. So, don't use
>> T_DIGITAL_TV on it, as it has no code to distinguish between
>> them, and nobody fills T_DIGITAL_TV right.
>>
>> Signed-off-by: Mauro Carvalho Chehab
>>
>> diff --git a/drivers/media/video/au0828/au0828-cards.c
>> b/drivers/media/video/au0828/au0828-cards.c
>> index 01be89f..39fc923 100644
>> --- a/drivers/media/video/au0828/au0828-cards.c
>> +++ b/drivers/media/video/au0828/au0828-cards.c
>> @@ -185,8 +185,7 @@ void au0828_card_setup(struct au0828_dev *dev)
>> static u8 eeprom[256];
>> struct tuner_setup tun_setup;
>> struct v4l2_subdev *sd;
>> -unsigned int mode_mask = T_ANALOG_TV |
>> - T_DIGITAL_TV;
>> +unsigned int mode_mask = T_ANALOG_TV;
>>
>> dprintk(1, "%s()\n", __func__);
>>
>> diff --git a/drivers/media/video/bt8xx/bttv-cards.c
>> b/drivers/media/video/bt8xx/bttv-cards.c
>> index 7f58756..242f0d5 100644
>> --- a/drivers/media/video/bt8xx/bttv-cards.c
>> +++ b/drivers/media/video/bt8xx/bttv-cards.c
>> @@ -3616,7 +3616,7 @@ void __devinit bttv_init_tuner(struct bttv *btv)
>> &btv->c.i2c_adap, "tuner",
>> 0, v4l2_i2c_tuner_addrs(ADDRS_TV_WITH_DEMOD));
>>
>> -tun_setup.mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
>> +tun_setup.mode_mask = T_ANALOG_TV;
>> tun_setup.type = btv->tuner_type;
>> tun_setup.addr = addr;
>>
>> diff --git a/drivers/media/video/cx88/cx88-cards.c
>> b/drivers/media/video/cx88/cx88-cards.c
>> index 4e6ee55..8128b93 100644
>> --- a/drivers/media/video/cx88/cx88-cards.c
>> +++ b/drivers/media/video/cx88/cx88-cards.c
>> @@ -3165,9 +3165,7 @@ static void cx88_card_setup(struct cx88_core
>> *core)
>> {
>> static u8 eeprom[256];
>> struct tuner_setup tun_setup;
>> -unsigned int mode_mask = T_RADIO |
>> - T_ANALOG_TV |
>> - T_DIGITAL_TV;
>> +unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
>>
>> memset(&tun_setup, 0, sizeof(tun_setup));
>>
>> diff --git a/drivers/media/video/saa7134/saa7134-cards.c
>> b/drivers/media/video/saa7134/saa7134-cards.c
>> index 74467c1..61c6007 100644
>> --- a/drivers/media/video/saa7134/saa7134-cards.c
>> +++ b/drivers/media/video/saa7134/saa7134-cards.c
>> @@ -7333,9 +7333,7 @@ int saa7134_board_init1(struct saa7134_dev *dev)
>> static void saa7134_tuner_setup(struct saa7134_dev *dev)
>> {
>> struct tuner_setup tun_setup;
>> -unsigned int mode_mask = T_RADIO |
>> - T_ANALOG_TV |
>> - T_DIGITAL_TV;
>> +unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
>>
>> memset(&tun_setup, 0, sizeof(tun_setup));
>> tun_setup.tuner_callback = saa7134_tuner_callback;
>> diff --git a/drivers/media/video/tuner-core.c
>> b/drivers/media/video/tuner-core.c
>> index dcf03fa..5e1437c 100644
>> --- a/drivers/media/video/tuner-core.c
>> +++ b/drivers/media/video/tuner-core.c
>> @@ -497,7 +497,7 @@ static void tuner_lookup(struct i2c_adapter *adap,
>> device. If other devices appear then we need to
>> make this test more general. */
>> else if (*tv == NULL && pos->type != TUNER_TDA9887 &&
>> - (pos->mode_mask & (T_ANALOG_TV | T_DIGITAL_TV)))
>> + (pos->mode_mask & T_ANALOG_TV))
>> *tv = pos;
>> }
>> }
>> @@ -565,8 +565,7 @@ static int tuner_probe(struct i2c_client *client,
>> } else {
>> /* Default is being tda9887 */
>> t->type = TUNER_TDA9887;
>> -t->mode_mask = T_RADIO | T_ANALOG_TV |
>> - T_DIGITAL_TV;
>> +t->mode_mask = T_RADIO | T_ANALOG_TV;
>> goto register_client;
>> }
>> break;
>> @@ -596,7 +595,7 @@ static int tuner_probe(struct i2c_client *client,
>> first found TV tuner. */
>> tuner_lookup(t->i2c->adapter, &radio, &tv);
>> if (tv == NULL) {
>> -t->mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
>> +t->mode_mask = T_ANALOG_TV;
>> if (radio == NULL)
>> t->mode_mask |= T_RADIO;
>> tuner_dbg("Setting mode_mask to 0x%02x\n", t->mode_mask);
>> @@ -607,18 +606,15 @@ register_client:
>> /* Sets a default mode */
>> if (t->mode_mask & T_ANALOG_TV)
>> t->mode = V4L2_TUNER_ANALOG_TV;
>> -else if (t->mode_mask & T_RADIO)
>> -t->mode = V4L2_TUNER_RADIO;
>> else
>> -t->mode = V4L2_TUNER_DIGITAL_TV;
>> +t->mode = V4L2_TUNER_RADIO;
>> set_type(client, t->type, t->mode_mask, t->config, t->fe.callback);
>> list_add_ta
[cron job] v4l-dvb daily build: WARNINGS
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:Tue Feb 15 19:00:28 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: 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: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: OK 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.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: OK linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l-utils: Add the JPEG Lite decoding function
Hi,
On 02/15/2011 10:26 AM, Jean-Francois Moine wrote:
Hi Hans,
I got the permission to relicense the JPEG Lite decoding to the LGPL.
Ah, good, patch applied and pushed to git.
If you want to test the nw80x driver, get the gspca tarball from my web
page (2.12.12). I added your webcam which should directly work (p35u -
chip nw801).
I've tested it and it works :) I also tested the JPGL -> YUV path.
I did find 2 bugs, the "if (gspca_dev->curr_mode)" test in sd_start,
needs to be inverted. In general it is a good idea to do a test
on gspca_dev->width, rather then curr_mode IMHO, it is more
readable and less error prone.
Talking about readability, I also found the
if (sd->bridge == BRIDGE_NW800) {
...
} else {
...
if (sd->bridge == BRIDGE_NW802) {
...
} else {
...
}
}
part in sd_init a bit hard to grok, can this be changed
to a switch case on sd->bridge ?
The other bug was a divide by zero -> kernel panic, in
do_autogain when sd->ae_res == 0, note this was when I was
messing around with the driver a bit (before I found the
issue with the inverted curr_mode check), but I think this
could happen in real life to depending on register values
and we should protect against this.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Non-portable code in em28XX driver
Dear Mauro,
In your patch 12406 to v4l-dvb dev tree there is a small problem:
--
diff -r 13a35e80e987 -r 8f9eee4fd803
linux/drivers/media/video/em28xx/em28xx-core.c
--- a/linux/drivers/media/video/em28xx/em28xx-core.cFri Aug 07 18:43:00
2009 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-core.cSat Aug 08 03:14:55
2009 -0300
@@ -720,7 +720,10 @@
{
int width, height;
width = norm_maxw(dev);
- height = norm_maxh(dev) >> 1;
+ height = norm_maxh(dev);
+
+ if (!dev->progressive)
+ height >>= norm_maxh(dev);
em28xx_set_outfmt(dev);
--
In the line "height >>= norm_maxh(dev)" undefined behavior has been
introduced. There is an attempt to shift the number to a big number of
bits which is not defined by C standard and leads to unpredictable
results. For example it will work on Intel because there it will
translate to no shift at all which seems to be unexpected as well. But
if you enable global optimization or compile this code for ARM the
result will be 0.
It seems like this line should look like "height = norm_maxh(dev) >> 1"
--
With best regards,
Vitaly Makarov
--
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: [RFD] frame-size switching: preview / single-shot use-case
Adding Manjunath Hadli to the list... Murail -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Tuesday, February 15, 2011 12:34 PM To: Linux Media Mailing List Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert; Karicheri, Muralidharan; Eino-Ville Talvala Subject: [RFD] frame-size switching: preview / single-shot use-case Hi This topic has been slightly discussed several times [1] before, but there has been no conclusion, nor I'm aware of any implementation, suitably resolving this problem. I've added to CC all involved in earlier discussions, that I managed to find. What seems a typical use-case to me is a system with a vewfinder or a display, providing a live preview of the video data from a source, like a camera, with a relatively low resolution, and a possibility to take high-resolution still photos with a very short delay. Currently this is pretty difficult to realise, e.g., with soc-camera drivers you have to free the videobuf(2) queue, by either closing and re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS, count=0) if your driver is already using videobuf2 and if this is really working;), configure with a different resolution and re-allocate videobuffers (or use different buffers, allocated per USERPTR). Another possibility would be to allocate and use buffers large enough for still photos, also for the preview, which would be wasteful, because one can well need many more preview than still-shot buffers. So, it seems to me, we could live with a better solution. 1. We could use separate inputs for different capture modes and support per-input videobuf queues. Advantage: no API changes required. Disadvantages: confusing, especially, if a driver already exports multiple inputs. The driver does not know, whether this mode is required or not, always exporting 2 inputs for this purpose doesn't seem like a good idea. Eventually, the user might want not 2, but 3 or more of such videobuf queues. 2. Use different IO methods, e.g., mmap() for preview and read() for still shots. I'm just mentioning this possibility here, because it occurred in one of previous threads, but I don't really like it either. What if you want to use the same IO method for all? Etc. 3. Not liking either of the above, it seems we need yet a new API for this... How about extending VIDIOC_REQBUFS with a videobuf queue index, thus using up one of the remaining two 32-bit reserved fields? Then we need one more ioctl() like VIDIOC_BUFQ_SELECT to switch from one queue to another, after which setting frame format and queuing and dequeuing buffers will affect this currently selected queue. We could also keep REQBUFS as is and require BUFQ_SELECT to be called before it for any queue except the default 0. Yes, I know, that some video sensors have a double register set for this dual-format operation, so, for them it is natural to support two queues, and drivers are certainly most welcome to use this feature for, say, the first two queues. On other sensors and for any further queues switching will have to be done in software. Ideas? Comments? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
[RFD] frame-size switching: preview / single-shot use-case
Hi This topic has been slightly discussed several times [1] before, but there has been no conclusion, nor I'm aware of any implementation, suitably resolving this problem. I've added to CC all involved in earlier discussions, that I managed to find. What seems a typical use-case to me is a system with a vewfinder or a display, providing a live preview of the video data from a source, like a camera, with a relatively low resolution, and a possibility to take high-resolution still photos with a very short delay. Currently this is pretty difficult to realise, e.g., with soc-camera drivers you have to free the videobuf(2) queue, by either closing and re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS, count=0) if your driver is already using videobuf2 and if this is really working;), configure with a different resolution and re-allocate videobuffers (or use different buffers, allocated per USERPTR). Another possibility would be to allocate and use buffers large enough for still photos, also for the preview, which would be wasteful, because one can well need many more preview than still-shot buffers. So, it seems to me, we could live with a better solution. 1. We could use separate inputs for different capture modes and support per-input videobuf queues. Advantage: no API changes required. Disadvantages: confusing, especially, if a driver already exports multiple inputs. The driver does not know, whether this mode is required or not, always exporting 2 inputs for this purpose doesn't seem like a good idea. Eventually, the user might want not 2, but 3 or more of such videobuf queues. 2. Use different IO methods, e.g., mmap() for preview and read() for still shots. I'm just mentioning this possibility here, because it occurred in one of previous threads, but I don't really like it either. What if you want to use the same IO method for all? Etc. 3. Not liking either of the above, it seems we need yet a new API for this... How about extending VIDIOC_REQBUFS with a videobuf queue index, thus using up one of the remaining two 32-bit reserved fields? Then we need one more ioctl() like VIDIOC_BUFQ_SELECT to switch from one queue to another, after which setting frame format and queuing and dequeuing buffers will affect this currently selected queue. We could also keep REQBUFS as is and require BUFQ_SELECT to be called before it for any queue except the default 0. Yes, I know, that some video sensors have a double register set for this dual-format operation, so, for them it is natural to support two queues, and drivers are certainly most welcome to use this feature for, say, the first two queues. On other sensors and for any further queues switching will have to be done in software. Ideas? Comments? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/4] [media] tuner-core: remove usage of DIGITAL_TV
Mauro Carvalho Chehab wrote:
>tuner-core has no business to do with digital TV. So, don't use
>T_DIGITAL_TV on it, as it has no code to distinguish between
>them, and nobody fills T_DIGITAL_TV right.
>
>Signed-off-by: Mauro Carvalho Chehab
>
>diff --git a/drivers/media/video/au0828/au0828-cards.c
>b/drivers/media/video/au0828/au0828-cards.c
>index 01be89f..39fc923 100644
>--- a/drivers/media/video/au0828/au0828-cards.c
>+++ b/drivers/media/video/au0828/au0828-cards.c
>@@ -185,8 +185,7 @@ void au0828_card_setup(struct au0828_dev *dev)
> static u8 eeprom[256];
> struct tuner_setup tun_setup;
> struct v4l2_subdev *sd;
>- unsigned int mode_mask = T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ unsigned int mode_mask = T_ANALOG_TV;
>
> dprintk(1, "%s()\n", __func__);
>
>diff --git a/drivers/media/video/bt8xx/bttv-cards.c
>b/drivers/media/video/bt8xx/bttv-cards.c
>index 7f58756..242f0d5 100644
>--- a/drivers/media/video/bt8xx/bttv-cards.c
>+++ b/drivers/media/video/bt8xx/bttv-cards.c
>@@ -3616,7 +3616,7 @@ void __devinit bttv_init_tuner(struct bttv *btv)
> &btv->c.i2c_adap, "tuner",
> 0, v4l2_i2c_tuner_addrs(ADDRS_TV_WITH_DEMOD));
>
>- tun_setup.mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
>+ tun_setup.mode_mask = T_ANALOG_TV;
> tun_setup.type = btv->tuner_type;
> tun_setup.addr = addr;
>
>diff --git a/drivers/media/video/cx88/cx88-cards.c
>b/drivers/media/video/cx88/cx88-cards.c
>index 4e6ee55..8128b93 100644
>--- a/drivers/media/video/cx88/cx88-cards.c
>+++ b/drivers/media/video/cx88/cx88-cards.c
>@@ -3165,9 +3165,7 @@ static void cx88_card_setup(struct cx88_core
>*core)
> {
> static u8 eeprom[256];
> struct tuner_setup tun_setup;
>- unsigned int mode_mask = T_RADIO |
>- T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
>
> memset(&tun_setup, 0, sizeof(tun_setup));
>
>diff --git a/drivers/media/video/saa7134/saa7134-cards.c
>b/drivers/media/video/saa7134/saa7134-cards.c
>index 74467c1..61c6007 100644
>--- a/drivers/media/video/saa7134/saa7134-cards.c
>+++ b/drivers/media/video/saa7134/saa7134-cards.c
>@@ -7333,9 +7333,7 @@ int saa7134_board_init1(struct saa7134_dev *dev)
> static void saa7134_tuner_setup(struct saa7134_dev *dev)
> {
> struct tuner_setup tun_setup;
>- unsigned int mode_mask = T_RADIO |
>- T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
>
> memset(&tun_setup, 0, sizeof(tun_setup));
> tun_setup.tuner_callback = saa7134_tuner_callback;
>diff --git a/drivers/media/video/tuner-core.c
>b/drivers/media/video/tuner-core.c
>index dcf03fa..5e1437c 100644
>--- a/drivers/media/video/tuner-core.c
>+++ b/drivers/media/video/tuner-core.c
>@@ -497,7 +497,7 @@ static void tuner_lookup(struct i2c_adapter *adap,
> device. If other devices appear then we need to
> make this test more general. */
> else if (*tv == NULL && pos->type != TUNER_TDA9887 &&
>- (pos->mode_mask & (T_ANALOG_TV | T_DIGITAL_TV)))
>+ (pos->mode_mask & T_ANALOG_TV))
> *tv = pos;
> }
> }
>@@ -565,8 +565,7 @@ static int tuner_probe(struct i2c_client *client,
> } else {
> /* Default is being tda9887 */
> t->type = TUNER_TDA9887;
>- t->mode_mask = T_RADIO | T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ t->mode_mask = T_RADIO | T_ANALOG_TV;
> goto register_client;
> }
> break;
>@@ -596,7 +595,7 @@ static int tuner_probe(struct i2c_client *client,
> first found TV tuner. */
> tuner_lookup(t->i2c->adapter, &radio, &tv);
> if (tv == NULL) {
>- t->mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
>+ t->mode_mask = T_ANALOG_TV;
> if (radio == NULL)
> t->mode_mask |= T_RADIO;
> tuner_dbg("Setting mode_mask to 0x%02x\n", t->mode_mask);
>@@ -607,18 +606,15 @@ register_client:
> /* Sets a default mode */
> if (t->mode_mask & T_ANALOG_TV)
> t->mode = V4L2_TUNER_ANALOG_TV;
>- else if (t->mode_mask & T_RADIO)
>- t->mode = V4L2_TUNER_RADIO;
> else
>- t->mode = V4L2_TUNER_DIGITAL_TV;
>+ t->mode = V4L2_TUNER_RADIO;
> set_type(client, t->type, t->mode_mask, t->config, t->fe.callback);
> list_add_tail(&t->list, &tuner_list);
>
>- tuner_info("Tuner %d found with type(s)%s%s%s.\n",
>+ tuner_info("Tuner %d found with
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
Hello Andy, I've tried some of your suggestions, but no luck so far. On Tue, Feb 15, 2011 at 4:09 AM, Andy Walls wrote: > On Mon, 2011-02-14 at 13:35 +0200, Dennis Kurten wrote: >> Hello, >> >> This card (technisat cablestar hd 2 dvb-c) works fine when plugged >> into a native PCI slot. >> When I try it with a PCI-adapter I intend to use in mITX-builds there >> doesn't seem >> to be any data coming in through the tuner. The adapter is a >> transparent bridge (with a >> PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a >> 4-pin molex. >> >> My guess is some kind of dma mapping incompatibility with the mantis >> driver (s2-liplianin). >> The card seems to initialize correctly, but doesn't work when the >> tuner is put into action >> (scandvb timeouts, dvbtraffic yields nothing). For the record, I've >> tested the bridge with a >> firewire card and that works fine. >> >> Kernel is 2.6.32 (+the compiled drivers) >> >> lspci for the bridge and the card: >> -- >> 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI >> Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> SERR- > Latency: 0, Cache Line Size: 32 bytes > ^^ > I can't remember the exact meaning of setting the latency to 0. IIRC it > is not actually 0, but allows at least to one data phase (but that may > not be enough for correct operation): > > http://www.sierrasales.com/pdfs/PCI-PCI_Bridges_When_Designing.pdf > > I would recommend you use setpci to bump this number up to 32, 64, or > 128 for troubleshooting/testing to ensure the bridge gets a decent > number of PCI bus clocks on the bus. The worst thing that could happen > is the PLX bridge hogs a PCI bus segment while you are testing - no big > deal. > I don't get to change that latency with setpci. Also, since the bridge is basically a PCIE card in itself I wonder if it is this or other "sec-latency=32" that is the relevant figure. I remember reading somewhere that the latency for a PCIE card cannot be set with setpci for some MBs. The second latency can be tweaked, but does not yield anything for 32, 64 or 128. I've also upped the tv card's latency. I'll investigate fine tuning of the bridge still (registered at PLX and received an SDK and some diagnostic apps) > >> Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 >> I/O behind bridge: e000-efff >> Memory behind bridge: fdd0-fddf >> Prefetchable memory behind bridge: fdc0-fdcf >> Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >> >TAbort- > BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- >> PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- >> Capabilities: >> Kernel modules: shpchp >> >> 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV >> PCI Bridge Controller [Ver 1.0] (rev 01) >> Subsystem: Device 1ae4:0002 >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >> >TAbort- SERR- > Well the Twinhan/Mantis device terminated at least one PCI transaction > it was mastering with a "target abort". Maybe that is related to the > bridge latency being set to 0. > Unfortunately that flag is also up when the card is working correctly in a native PCI slot. > >> Latency: 32 (2000ns min, 63750ns max) >> Interrupt: pin A routed to IRQ 16 >> Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] > > > Heh, I always find it curious when I/O peripherials claim their register > space is prefetchable (the CX23416 does this as well). If the chip is > designed right, it is valid though AFAICT. > > You may want to run a separate test with the cache-line size on the > bridge set to something smaller than 32 using setpci. I believe powers > of 2 and the value 0 are allowed. Transfers will become more > inefficient with smaller cache-line size, but it may eliminate any > problems related to conditions required for prefetching. Worth a try. > Tried as far down as zero, no luck I'm afraid. > > > You may also want to look for some BIOS/EFI settings related to > interrupt routing and emulation. > I don't recall much more options than "P'n'P or not" (which I've done both ways), but I'll have a look in the manual. The interrupt watch you mentioned in your other post was interesting since apparently that one is shared. from /cat/interrupts: --- 16: 9751 0 IO-APIC-fasteoi ahci, nvidia, Mantis Without doing an
[PATCH 3/4] [media] tuner-core: Rearrange some functions to better document
Group a few functions together and add/fix comments for each
block of the driver.
This is just a cleanup patch meant to improve driver readability.
No functional changes in this patch.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 2c7fe18..a91a299 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -251,7 +251,7 @@ static struct analog_demod_ops tuner_analog_ops = {
};
/*
- * Functions to select between radio and TV and tuner probe functions
+ * Functions to select between radio and TV and tuner probe/remove functions
*/
/**
@@ -698,6 +698,75 @@ static int tuner_remove(struct i2c_client *client)
}
/*
+ * Functions to switch between Radio and TV
+ *
+ * A few cards have a separate I2C tuner for radio. Those routines
+ * take care of switching between TV/Radio mode, filtering only the
+ * commands that apply to the Radio or TV tuner.
+ */
+
+/**
+ * check_mode - Verify if tuner supports the requested mode
+ * @t: a pointer to the module's internal struct_tuner
+ *
+ * This function checks if the tuner is capable of tuning analog TV,
+ * digital TV or radio, depending on what the caller wants. If the
+ * tuner can't support that mode, it returns -EINVAL. Otherwise, it
+ * returns 0.
+ * This function is needed for boards that have a separate tuner for
+ * radio (like devices with tea5767).
+ */
+static inline int check_mode(struct tuner *t, enum v4l2_tuner_type mode)
+{
+ if ((1 << mode & t->mode_mask) == 0)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * set_mode_freq - Switch tuner to other mode.
+ * @client:struct i2c_client pointer
+ * @t: a pointer to the module's internal struct_tuner
+ * @mode: enum v4l2_type (radio or TV)
+ * @freq: frequency to set (0 means to use the previous one)
+ *
+ * If tuner doesn't support the needed mode (radio or TV), prints a
+ * debug message and returns -EINVAL, changing its state to standby.
+ * Otherwise, changes the state and sets frequency to the last value, if
+ * the tuner can sleep or if it supports both Radio and TV.
+ */
+static int set_mode_freq(struct i2c_client *client, struct tuner *t,
+enum v4l2_tuner_type mode, unsigned int freq)
+{
+ struct analog_demod_ops *analog_ops = &t->fe.ops.analog_ops;
+
+ if (mode != t->mode) {
+ if (check_mode(t, mode) == -EINVAL) {
+ tuner_dbg("Tuner doesn't support mode %d. "
+ "Putting tuner to sleep\n", mode);
+ t->standby = true;
+ if (analog_ops->standby)
+ analog_ops->standby(&t->fe);
+ return -EINVAL;
+ }
+ t->mode = mode;
+ tuner_dbg("Changing to mode %d\n", mode);
+ }
+ if (t->mode == V4L2_TUNER_RADIO) {
+ if (freq)
+ t->radio_freq = freq;
+ set_radio_freq(client, t->radio_freq);
+ } else {
+ if (freq)
+ t->tv_freq = freq;
+ set_tv_freq(client, t->tv_freq);
+ }
+
+ return 0;
+}
+
+/*
* Functions that are specific for TV mode
*/
@@ -925,66 +994,9 @@ static void set_radio_freq(struct i2c_client *c, unsigned
int freq)
analog_ops->set_params(&t->fe, ¶ms);
}
-/**
- * check_mode - Verify if tuner supports the requested mode
- * @t: a pointer to the module's internal struct_tuner
- *
- * This function checks if the tuner is capable of tuning analog TV,
- * digital TV or radio, depending on what the caller wants. If the
- * tuner can't support that mode, it returns -EINVAL. Otherwise, it
- * returns 0.
- * This function is needed for boards that have a separate tuner for
- * radio (like devices with tea5767).
+/*
+ * Debug function for reporting tuner status to userspace
*/
-static inline int check_mode(struct tuner *t, enum v4l2_tuner_type mode)
-{
- if ((1 << mode & t->mode_mask) == 0)
- return -EINVAL;
-
- return 0;
-}
-
-/**
- * set_mode_freq - Switch tuner to other mode.
- * @client:struct i2c_client pointer
- * @t: a pointer to the module's internal struct_tuner
- * @mode: enum v4l2_type (radio or TV)
- * @freq: frequency to set (0 means to use the previous one)
- *
- * If tuner doesn't support the needed mode (radio or TV), prints a
- * debug message and returns -EINVAL, changing internal state to T_STANDBY.
- * Otherwise, changes the state and sets frequency to the last value, if
- * the tuner can sleep or if it supports both Radio and TV.
- */
-static int set_mode_freq(struct i2c_client *client, struct tuner *t,
-enum v4l2_tuner_type mode, unsigned int freq)
-{
- struct analog_demod_ops *analog_ops = &t->fe.ops.analog_ops;
-
- if (mode != t->mode) {
- if (check_mo
[PATCH 2/4] [media] tuner-core: Improve function documentation
This driver is complex, and used by everyone. Better to have it
properly documented.
No functional changes are done in this patch.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 5e1437c..2c7fe18 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1,7 +1,17 @@
/*
- *
* i2c tv tuner chip device driver
* core core, i.e. kernel interfaces, registering and so on
+ *
+ * Copyright(c) by Ralph Metzler, Gerd Knorr, Gunther Mayer
+ *
+ * Copyright(c) 2005-2011 by Mauro Carvalho Chehab
+ * - Added support for a separate Radio tuner
+ * - Major rework and cleanups at the code
+ *
+ * This driver supports many devices and the idea is to let the driver
+ * detect which device is present. So rather than listing all supported
+ * devices here, we pretend to support a single, fake device type that will
+ * handle both radio and analog TV tuning.
*/
#include
@@ -67,6 +77,7 @@ module_param_string(ntsc, ntsc, sizeof(ntsc), 0644);
*/
static LIST_HEAD(tuner_list);
+static const struct v4l2_subdev_ops tuner_ops;
/*
* Debug macros
@@ -125,6 +136,13 @@ struct tuner {
};
/*
+ * Function prototypes
+ */
+
+static void set_tv_freq(struct i2c_client *c, unsigned int freq);
+static void set_radio_freq(struct i2c_client *c, unsigned int freq);
+
+/*
* tuner attach/detach logic
*/
@@ -233,13 +251,24 @@ static struct analog_demod_ops tuner_analog_ops = {
};
/*
- * Functions that are common to both TV and radio
+ * Functions to select between radio and TV and tuner probe functions
*/
-static void set_tv_freq(struct i2c_client *c, unsigned int freq);
-static void set_radio_freq(struct i2c_client *c, unsigned int freq);
-static const struct v4l2_subdev_ops tuner_ops;
-
+/**
+ * set_type - Sets the tuner type for a given device
+ *
+ * @c: i2c_client descriptoy
+ * @type: type of the tuner (e. g. tuner number)
+ * @new_mode_mask: Indicates if tuner supports TV and/or Radio
+ * @new_config:an optional parameter ranging from 0-255 used by
+ a few tuners to adjust an internal parameter,
+ like LNA mode
+ * @tuner_callback:an optional function to be called when switching
+ * to analog mode
+ *
+ * This function applys the tuner config to tuner specified
+ * by tun_setup structure. It contains several per-tuner initialization "magic"
+ */
static void set_type(struct i2c_client *c, unsigned int type,
unsigned int new_mode_mask, unsigned int new_config,
int (*tuner_callback) (void *dev, int component, int cmd,
int arg))
@@ -452,6 +481,15 @@ static int tuner_s_type_addr(struct v4l2_subdev *sd,
return 0;
}
+/**
+ * tuner_s_config - Sets tuner configuration
+ *
+ * @sd:subdev descriptor
+ * @cfg: tuner configuration
+ *
+ * Calls tuner set_config() private function to set some tuner-internal
+ * parameters
+ */
static int tuner_s_config(struct v4l2_subdev *sd,
const struct v4l2_priv_tun_config *cfg)
{
@@ -470,10 +508,20 @@ static int tuner_s_config(struct v4l2_subdev *sd,
return 0;
}
-/* Search for existing radio and/or TV tuners on the given I2C adapter.
- Note that when this function is called from tuner_probe you can be
- certain no other devices will be added/deleted at the same time, I2C
- core protects against that. */
+/**
+ * tuner_lookup - Seek for tuner adapters
+ *
+ * @adap: i2c_adapter struct
+ * @radio: pointer to be filled if the adapter is radio
+ * @tv:pointer to be filled if the adapter is TV
+ *
+ * Search for existing radio and/or TV tuners on the given I2C adapter,
+ * discarding demod-only adapters (tda9887).
+ *
+ * Note that when this function is called from tuner_probe you can be
+ * certain no other devices will be added/deleted at the same time, I2C
+ * core protects against that.
+ */
static void tuner_lookup(struct i2c_adapter *adap,
struct tuner **radio, struct tuner **tv)
{
@@ -502,8 +550,20 @@ static void tuner_lookup(struct i2c_adapter *adap,
}
}
-/* During client attach, set_type is called by adapter's attach_inform
callback.
- set_type must then be completed by tuner_probe.
+/**
+ *tuner_probe - Probes the existing tuners on an I2C bus
+ *
+ * @client:i2c_client descriptor
+ * @id:not used
+ *
+ * This routine probes for tuners at the expected I2C addresses. On most
+ * cases, if a device answers to a given I2C address, it assumes that the
+ * device is a tuner. On a few cases, however, an additional logic is needed
+ * to double check if the device is really a tuner, or to identify the tuner
+ * type, like on tea5767/5761 devices.
+ *
+ * During client attach, set_type is called by adapter's attach_inform
callback.
+ * set_type must then be co
[PATCH 1/4] [media] tuner-core: remove usage of DIGITAL_TV
tuner-core has no business to do with digital TV. So, don't use
T_DIGITAL_TV on it, as it has no code to distinguish between
them, and nobody fills T_DIGITAL_TV right.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/au0828/au0828-cards.c
b/drivers/media/video/au0828/au0828-cards.c
index 01be89f..39fc923 100644
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -185,8 +185,7 @@ void au0828_card_setup(struct au0828_dev *dev)
static u8 eeprom[256];
struct tuner_setup tun_setup;
struct v4l2_subdev *sd;
- unsigned int mode_mask = T_ANALOG_TV |
-T_DIGITAL_TV;
+ unsigned int mode_mask = T_ANALOG_TV;
dprintk(1, "%s()\n", __func__);
diff --git a/drivers/media/video/bt8xx/bttv-cards.c
b/drivers/media/video/bt8xx/bttv-cards.c
index 7f58756..242f0d5 100644
--- a/drivers/media/video/bt8xx/bttv-cards.c
+++ b/drivers/media/video/bt8xx/bttv-cards.c
@@ -3616,7 +3616,7 @@ void __devinit bttv_init_tuner(struct bttv *btv)
&btv->c.i2c_adap, "tuner",
0, v4l2_i2c_tuner_addrs(ADDRS_TV_WITH_DEMOD));
- tun_setup.mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
+ tun_setup.mode_mask = T_ANALOG_TV;
tun_setup.type = btv->tuner_type;
tun_setup.addr = addr;
diff --git a/drivers/media/video/cx88/cx88-cards.c
b/drivers/media/video/cx88/cx88-cards.c
index 4e6ee55..8128b93 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -3165,9 +3165,7 @@ static void cx88_card_setup(struct cx88_core *core)
{
static u8 eeprom[256];
struct tuner_setup tun_setup;
- unsigned int mode_mask = T_RADIO |
-T_ANALOG_TV |
-T_DIGITAL_TV;
+ unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
memset(&tun_setup, 0, sizeof(tun_setup));
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 74467c1..61c6007 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -7333,9 +7333,7 @@ int saa7134_board_init1(struct saa7134_dev *dev)
static void saa7134_tuner_setup(struct saa7134_dev *dev)
{
struct tuner_setup tun_setup;
- unsigned int mode_mask = T_RADIO |
-T_ANALOG_TV |
-T_DIGITAL_TV;
+ unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
memset(&tun_setup, 0, sizeof(tun_setup));
tun_setup.tuner_callback = saa7134_tuner_callback;
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index dcf03fa..5e1437c 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -497,7 +497,7 @@ static void tuner_lookup(struct i2c_adapter *adap,
device. If other devices appear then we need to
make this test more general. */
else if (*tv == NULL && pos->type != TUNER_TDA9887 &&
-(pos->mode_mask & (T_ANALOG_TV | T_DIGITAL_TV)))
+(pos->mode_mask & T_ANALOG_TV))
*tv = pos;
}
}
@@ -565,8 +565,7 @@ static int tuner_probe(struct i2c_client *client,
} else {
/* Default is being tda9887 */
t->type = TUNER_TDA9887;
- t->mode_mask = T_RADIO | T_ANALOG_TV |
- T_DIGITAL_TV;
+ t->mode_mask = T_RADIO | T_ANALOG_TV;
goto register_client;
}
break;
@@ -596,7 +595,7 @@ static int tuner_probe(struct i2c_client *client,
first found TV tuner. */
tuner_lookup(t->i2c->adapter, &radio, &tv);
if (tv == NULL) {
- t->mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
+ t->mode_mask = T_ANALOG_TV;
if (radio == NULL)
t->mode_mask |= T_RADIO;
tuner_dbg("Setting mode_mask to 0x%02x\n", t->mode_mask);
@@ -607,18 +606,15 @@ register_client:
/* Sets a default mode */
if (t->mode_mask & T_ANALOG_TV)
t->mode = V4L2_TUNER_ANALOG_TV;
- else if (t->mode_mask & T_RADIO)
- t->mode = V4L2_TUNER_RADIO;
else
- t->mode = V4L2_TUNER_DIGITAL_TV;
+ t->mode = V4L2_TUNER_RADIO;
set_type(client, t->type, t->mode_mask, t->config, t->fe.callback);
list_add_tail(&t->list, &tuner_list);
- tuner_info("Tuner %d found with type(s)%s%s%s.\n",
+ tuner_info("Tuner %d found with type(s)%s%s.\n",
t->type,
- t->mode_mask &
[PATCH 0/4] Additional cleanups to tuner-core
Hans Verkuils gave me some feedback about the last series at the ML, and, due to that, I've added a few more cleanup patches at the series. Basically, he poined me two issues: - DIGITAL_TV is not used at tuner core; - tuner_lookup shouldn't touch at t->standby. This series cleans the code to address the above issues, and also do a few other cleanups to better document the code, without changing any functionality. I also extended my tests with some other devices. The tuner-core was tested with: - cx88: Pixelview Ultra Pro: A TNF analog tuner + tea5767; - em28xx: WinTV USB2: an analog tuner with tda9887; - em28xx: HVR950: xc2028 based tuner; - cx231xx: Pixelview SBTVD Hybrid: tda18271 tuner. On all the tests, tuner-core behave well. So, I'm committing the entire tuner-core series of patches, for people to test them with other devices, but, based on my tests, I don't think that the changes would cause any regressions. Mauro Carvalho Chehab (4): [media] tuner-core: remove usage of DIGITAL_TV [media] tuner-core: Improve function documentation [media] tuner-core: Rearrange some functions to better document [media] tuner-core: Don't touch at standby during tuner_lookup drivers/media/video/au0828/au0828-cards.c |3 +- drivers/media/video/bt8xx/bttv-cards.c |2 +- drivers/media/video/cx88/cx88-cards.c |4 +- drivers/media/video/saa7134/saa7134-cards.c |4 +- drivers/media/video/tuner-core.c| 310 ++- 5 files changed, 209 insertions(+), 114 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] [media] tuner-core: Don't touch at standby during tuner_lookup
It makes no sense that tuner_lookup would touch at the standby state. Remove it. Thanks-to: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index a91a299..9363ed9 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -538,7 +538,6 @@ static void tuner_lookup(struct i2c_adapter *adap, continue; mode_mask = pos->mode_mask; - pos->standby = 1; if (*radio == NULL && mode_mask == T_RADIO) *radio = pos; /* Note: currently TDA9887 is the only demod-only -- 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: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
Dennis Kurten wrote: >The power issue did cross my mind after some more research. Maybe >that would explain why the card is registering correctly but not >returning >any tuned data. I haven't found any detailed requirement specs for the >tv card but I assume that the tuner/demodulator could consume a fair >amount of power. However, my adapter should be supplying 12V >500mA with the molex. I'll try to measure if I can get the equipment >of >a friend (just in case, since the connectors seem a bit sloppy). > >Andy's insightful tips from the other reply also made a lot of sense >since >there does not seem to be anything at all coming back from the card, >not >even jitter or noise. That could indicate lost interrupts / bus >mastering >problems. I'll see tonight after some tweaking. > >As far as using native PCIe cards there's only one experimental (and >very expensive) DVB-C model I know of. Combine this with the shortage >of PCI slots on SFF motherboards and you have a problem with media >centers. > >Regard, >Dennis > > > >On Tue, Feb 15, 2011 at 10:20 AM, Konstantin Dimitrov > wrote: >> oh, i have just noticed your DVB card is for Cable and not for >> Satellite, but still it may use 12V PCI interface pins for something >> else and not exactly for LNB power as i thought assuming it's >DVB-S/S2 >> DVB card. >> >> On Tue, Feb 15, 2011 at 10:18 AM, Konstantin Dimitrov >> wrote: >>> hi, does your DVB card can get signal lock when it's inserted into >the >>> PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE >>> adapters based on PEX 8111/8112 don't provide power to 12V pins of >the >>> PCI interface, which probably all PCI DVB card use for LNB power. >so, >>> what i would check if i'm at your position is the LNB power of the >>> card as well as if there is no some extensive amount of noise in the >>> LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE >>> adapter. also, i can give you example from my own experience with an >>> "Audiotrak Prodigy HD2" PCI audio card and PEX 8111/8112 based >>> PCI-to-PCIE adapters - with one such adapter that don't provide >power >>> to 12V pins of the PCI interface there is no sound coming out, >because >>> the amplifier on the card uses power from 12V pins of the PCI >>> interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems >>> to provide power to 12V pins there is extensive noise in the sound >>> that is coming out, because PCI-to-PCIE adapter doesn't provide good >>> power on 12V pins of the PCI interface and thus the noise in the >>> audio. also, on some motherboards (with nVidia chipset on my tests) >>> there was some problem with how the memory was mapped preventing the >>> work of the PCI card when it's inserted into PEX 8111/8112 based >>> PCI-to-PCIE adapter. so, it's also helpful to test motherboards with >>> different chipset. in any case it's always better to find and use >>> native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter >>> and PCI card. anyway, maybe, someone with more hardware engineering >>> knowledge then i have, especially if the problem is 12V can find >some >>> way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are >>> floating around, because i'm sure they just sacrifice 12V power to >>> lower the BOM cost of the adapter. BTW, i'm sure your firewire card >is >>> working, because it doesn't use 12V PCI interface pins - it's the >same >>> with many PCI cards, but all that needs 12V are no-go based on my >>> experience. >>> >>> --konstantin >>> >>> On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten > wrote: Hello, This card (technisat cablestar hd 2 dvb-c) works fine when plugged into a native PCI slot. When I try it with a PCI-adapter I intend to use in mITX-builds >there doesn't seem to be any data coming in through the tuner. The adapter is a transparent bridge (with a PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through >a 4-pin molex. My guess is some kind of dma mapping incompatibility with the >mantis driver (s2-liplianin). The card seems to initialize correctly, but doesn't work when the tuner is put into action (scandvb timeouts, dvbtraffic yields nothing). For the record, I've tested the bridge with a firewire card and that works fine. Kernel is 2.6.32 (+the compiled drivers) lspci for the bridge and the card: -- 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >>TAbort- SERR- >>> Latency: 0, Cache Line Size: 32 bytes Bus: primary=03, secondary=04, subordinate=04, >sec-latency=32 I/O behind bridge: e000-efff >>>
Re: [PATCH resend] video: omap24xxcam: Fix compilation
Felipe Balbi wrote: > Hi, > > On Tue, Feb 15, 2011 at 12:50:12PM +0100, Thomas Weber wrote: >> Hello Felipe, >> >> in include/linux/wait.h >> >> #define wake_up(x)__wake_up(x, TASK_NORMAL, 1, NULL) > > aha, now I get it, so shouldn't the real fix be including > on , I mean, it's who uses a symbol > defined in , right ? Surprisingly many other files still don't seem to be affected. But this is actually a better solution (to include sched.h in wait.h). -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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 resend] video: omap24xxcam: Fix compilation
Hi, On Tue, Feb 15, 2011 at 12:50:12PM +0100, Thomas Weber wrote: > Hello Felipe, > > in include/linux/wait.h > > #define wake_up(x)__wake_up(x, TASK_NORMAL, 1, NULL) aha, now I get it, so shouldn't the real fix be including on , I mean, it's who uses a symbol defined in , right ? -- balbi -- 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 resend] video: omap24xxcam: Fix compilation
Felipe Balbi wrote: > hi, > > On Tue, Feb 15, 2011 at 12:44:42PM +0100, Sylwester Nawrocki wrote: >>> Are we using the same tree ? I don't see anything related to TASK_* on >> >> Please have a look at definition of macro wake_up. This where those >> TASK_* flags are used. > > $ git grep -e TASK_ drivers/media/video/omap*.[ch] > $ > > ??? > It's wake_up() on line 414. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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 resend] video: omap24xxcam: Fix compilation
Am 15.02.2011 12:44, schrieb Sylwester Nawrocki:
> Hi Felipe,
>
> On 02/15/2011 12:37 PM, Felipe Balbi wrote:
>> On Tue, Feb 15, 2011 at 01:28:19PM +0200, Sakari Ailus wrote:
>>> Thomas Weber wrote:
Add linux/sched.h because of missing declaration of TASK_NORMAL.
This patch fixes the following error:
drivers/media/video/omap24xxcam.c: In function
'omap24xxcam_vbq_complete':
drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
(first use in this function)
drivers/media/video/omap24xxcam.c:415: error: (Each undeclared
identifier is reported only once
drivers/media/video/omap24xxcam.c:415: error: for each function it
appears in.)
Signed-off-by: Thomas Weber
>>> Thanks, Thomas!
>> Are we using the same tree ? I don't see anything related to TASK_* on
> Please have a look at definition of macro wake_up. This where those
> TASK_* flags are used.
>
>> that function on today's mainline, here's a copy of the function:
>>
>> 387 static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
>> 388 u32 csr, void *arg)
>> 389 {
>> 390 struct omap24xxcam_device *cam =
>> 391 container_of(sgdma, struct omap24xxcam_device, sgdma);
>> 392 struct omap24xxcam_fh *fh = cam->streaming->private_data;
>> 393 struct videobuf_buffer *vb = (struct videobuf_buffer *)arg;
>> 394 const u32 csr_error = CAMDMA_CSR_MISALIGNED_ERR
>> 395 | CAMDMA_CSR_SUPERVISOR_ERR | CAMDMA_CSR_SECURE_ERR
>> 396 | CAMDMA_CSR_TRANS_ERR | CAMDMA_CSR_DROP;
>> 397 unsigned long flags;
>> 398
>> 399 spin_lock_irqsave(&cam->core_enable_disable_lock, flags);
>> 400 if (--cam->sgdma_in_queue == 0)
>> 401 omap24xxcam_core_disable(cam);
>> 402 spin_unlock_irqrestore(&cam->core_enable_disable_lock, flags);
>> 403
>> 404 do_gettimeofday(&vb->ts);
>> 405 vb->field_count = atomic_add_return(2, &fh->field_count);
>> 406 if (csr & csr_error) {
>> 407 vb->state = VIDEOBUF_ERROR;
>> 408 if (!atomic_read(&fh->cam->in_reset)) {
>> 409 dev_dbg(cam->dev, "resetting camera, csr
>> 0x%x\n", csr);
>> 410 omap24xxcam_reset(cam);
>> 411 }
>> 412 } else
>> 413 vb->state = VIDEOBUF_DONE;
>> 414 wake_up(&vb->done);
>> 415 }
>>
>> see that line 415 is where the function ends. My head is
>> 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
>>
> Cheers,
> Sylwester Nawrocki
> --
Hello Felipe,
in include/linux/wait.h
#define wake_up(x)__wake_up(x, TASK_NORMAL, 1, NULL)
Regards,
Thomas
--
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 resend] video: omap24xxcam: Fix compilation
hi, On Tue, Feb 15, 2011 at 12:44:42PM +0100, Sylwester Nawrocki wrote: > > Are we using the same tree ? I don't see anything related to TASK_* on > > Please have a look at definition of macro wake_up. This where those > TASK_* flags are used. $ git grep -e TASK_ drivers/media/video/omap*.[ch] $ ??? -- balbi -- 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 resend] video: omap24xxcam: Fix compilation
Hi Felipe,
On 02/15/2011 12:37 PM, Felipe Balbi wrote:
> On Tue, Feb 15, 2011 at 01:28:19PM +0200, Sakari Ailus wrote:
>> Thomas Weber wrote:
>>> Add linux/sched.h because of missing declaration of TASK_NORMAL.
>>>
>>> This patch fixes the following error:
>>>
>>> drivers/media/video/omap24xxcam.c: In function
>>> 'omap24xxcam_vbq_complete':
>>> drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
>>> (first use in this function)
>>> drivers/media/video/omap24xxcam.c:415: error: (Each undeclared
>>> identifier is reported only once
>>> drivers/media/video/omap24xxcam.c:415: error: for each function it
>>> appears in.)
>>>
>>> Signed-off-by: Thomas Weber
>>
>> Thanks, Thomas!
>
> Are we using the same tree ? I don't see anything related to TASK_* on
Please have a look at definition of macro wake_up. This where those
TASK_* flags are used.
> that function on today's mainline, here's a copy of the function:
>
> 387 static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
> 388 u32 csr, void *arg)
> 389 {
> 390 struct omap24xxcam_device *cam =
> 391 container_of(sgdma, struct omap24xxcam_device, sgdma);
> 392 struct omap24xxcam_fh *fh = cam->streaming->private_data;
> 393 struct videobuf_buffer *vb = (struct videobuf_buffer *)arg;
> 394 const u32 csr_error = CAMDMA_CSR_MISALIGNED_ERR
> 395 | CAMDMA_CSR_SUPERVISOR_ERR | CAMDMA_CSR_SECURE_ERR
> 396 | CAMDMA_CSR_TRANS_ERR | CAMDMA_CSR_DROP;
> 397 unsigned long flags;
> 398
> 399 spin_lock_irqsave(&cam->core_enable_disable_lock, flags);
> 400 if (--cam->sgdma_in_queue == 0)
> 401 omap24xxcam_core_disable(cam);
> 402 spin_unlock_irqrestore(&cam->core_enable_disable_lock, flags);
> 403
> 404 do_gettimeofday(&vb->ts);
> 405 vb->field_count = atomic_add_return(2, &fh->field_count);
> 406 if (csr & csr_error) {
> 407 vb->state = VIDEOBUF_ERROR;
> 408 if (!atomic_read(&fh->cam->in_reset)) {
> 409 dev_dbg(cam->dev, "resetting camera, csr
> 0x%x\n", csr);
> 410 omap24xxcam_reset(cam);
> 411 }
> 412 } else
> 413 vb->state = VIDEOBUF_DONE;
> 414 wake_up(&vb->done);
> 415 }
>
> see that line 415 is where the function ends. My head is
> 795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
>
Cheers,
Sylwester Nawrocki
--
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 resend] video: omap24xxcam: Fix compilation
On Tue, Feb 15, 2011 at 01:28:19PM +0200, Sakari Ailus wrote:
> Thomas Weber wrote:
> > Add linux/sched.h because of missing declaration of TASK_NORMAL.
> >
> > This patch fixes the following error:
> >
> > drivers/media/video/omap24xxcam.c: In function
> > 'omap24xxcam_vbq_complete':
> > drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared
> > (first use in this function)
> > drivers/media/video/omap24xxcam.c:415: error: (Each undeclared
> > identifier is reported only once
> > drivers/media/video/omap24xxcam.c:415: error: for each function it
> > appears in.)
> >
> > Signed-off-by: Thomas Weber
>
> Thanks, Thomas!
Are we using the same tree ? I don't see anything related to TASK_* on
that function on today's mainline, here's a copy of the function:
387 static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
388 u32 csr, void *arg)
389 {
390 struct omap24xxcam_device *cam =
391 container_of(sgdma, struct omap24xxcam_device, sgdma);
392 struct omap24xxcam_fh *fh = cam->streaming->private_data;
393 struct videobuf_buffer *vb = (struct videobuf_buffer *)arg;
394 const u32 csr_error = CAMDMA_CSR_MISALIGNED_ERR
395 | CAMDMA_CSR_SUPERVISOR_ERR | CAMDMA_CSR_SECURE_ERR
396 | CAMDMA_CSR_TRANS_ERR | CAMDMA_CSR_DROP;
397 unsigned long flags;
398
399 spin_lock_irqsave(&cam->core_enable_disable_lock, flags);
400 if (--cam->sgdma_in_queue == 0)
401 omap24xxcam_core_disable(cam);
402 spin_unlock_irqrestore(&cam->core_enable_disable_lock, flags);
403
404 do_gettimeofday(&vb->ts);
405 vb->field_count = atomic_add_return(2, &fh->field_count);
406 if (csr & csr_error) {
407 vb->state = VIDEOBUF_ERROR;
408 if (!atomic_read(&fh->cam->in_reset)) {
409 dev_dbg(cam->dev, "resetting camera, csr 0x%x\n",
csr);
410 omap24xxcam_reset(cam);
411 }
412 } else
413 vb->state = VIDEOBUF_DONE;
414 wake_up(&vb->done);
415 }
see that line 415 is where the function ends. My head is
795abaf1e4e188c4171e3cd3dbb11a9fcacaf505
--
balbi
--
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 resend] video: omap24xxcam: Fix compilation
Thomas Weber wrote: > Add linux/sched.h because of missing declaration of TASK_NORMAL. > > This patch fixes the following error: > > drivers/media/video/omap24xxcam.c: In function > 'omap24xxcam_vbq_complete': > drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared > (first use in this function) > drivers/media/video/omap24xxcam.c:415: error: (Each undeclared > identifier is reported only once > drivers/media/video/omap24xxcam.c:415: error: for each function it > appears in.) > > Signed-off-by: Thomas Weber Thanks, Thomas! Acked-by: Sakari Ailus > --- > drivers/media/video/omap24xxcam.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/omap24xxcam.c > b/drivers/media/video/omap24xxcam.c > index 0175527..f6626e8 100644 > --- a/drivers/media/video/omap24xxcam.c > +++ b/drivers/media/video/omap24xxcam.c > @@ -36,6 +36,7 @@ > #include > #include > #include > +#include > > #include > #include -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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: Sony CXD2099AR decryption failing
Hi Oliver, Thx for your reply. This will be a bit hard. But I will give it a try. I will try to boot from a USB key with Windows on it. Any preferences for Windows ? XP, Vista or 7 ? -- Issa -- Original Message -- Received: 04:04 AM CET, 02/15/2011 From: Oliver Endriss To: "Issa Gorissen" Cc: linux-media@vger.kernel.org Subject: Re: Sony CXD2099AR decryption failing > Hello, > > On Monday 14 February 2011 17:42:55 Issa Gorissen wrote: > > Hi, > > > > I am having some trouble with the Sony CXD2099AR CI chip. > > > > With a SMIT Viaccess CAM, I am not able to decrypt channels from the french > > package Bis.TV on Hotbird 13E. > > > > The CAM decrypts fine when inserted in a set top box. > > > > The drivers running are those from the branch of Oliver. > > System's running OpenSuse 11.3. > > > > May someone with the knowledge of this chip get in touch with me ? > > Could you please test, whether it works with the windows driver? > > 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: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
The power issue did cross my mind after some more research. Maybe that would explain why the card is registering correctly but not returning any tuned data. I haven't found any detailed requirement specs for the tv card but I assume that the tuner/demodulator could consume a fair amount of power. However, my adapter should be supplying 12V 500mA with the molex. I'll try to measure if I can get the equipment of a friend (just in case, since the connectors seem a bit sloppy). Andy's insightful tips from the other reply also made a lot of sense since there does not seem to be anything at all coming back from the card, not even jitter or noise. That could indicate lost interrupts / bus mastering problems. I'll see tonight after some tweaking. As far as using native PCIe cards there's only one experimental (and very expensive) DVB-C model I know of. Combine this with the shortage of PCI slots on SFF motherboards and you have a problem with media centers. Regard, Dennis On Tue, Feb 15, 2011 at 10:20 AM, Konstantin Dimitrov wrote: > oh, i have just noticed your DVB card is for Cable and not for > Satellite, but still it may use 12V PCI interface pins for something > else and not exactly for LNB power as i thought assuming it's DVB-S/S2 > DVB card. > > On Tue, Feb 15, 2011 at 10:18 AM, Konstantin Dimitrov > wrote: >> hi, does your DVB card can get signal lock when it's inserted into the >> PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE >> adapters based on PEX 8111/8112 don't provide power to 12V pins of the >> PCI interface, which probably all PCI DVB card use for LNB power. so, >> what i would check if i'm at your position is the LNB power of the >> card as well as if there is no some extensive amount of noise in the >> LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE >> adapter. also, i can give you example from my own experience with an >> "Audiotrak Prodigy HD2" PCI audio card and PEX 8111/8112 based >> PCI-to-PCIE adapters - with one such adapter that don't provide power >> to 12V pins of the PCI interface there is no sound coming out, because >> the amplifier on the card uses power from 12V pins of the PCI >> interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems >> to provide power to 12V pins there is extensive noise in the sound >> that is coming out, because PCI-to-PCIE adapter doesn't provide good >> power on 12V pins of the PCI interface and thus the noise in the >> audio. also, on some motherboards (with nVidia chipset on my tests) >> there was some problem with how the memory was mapped preventing the >> work of the PCI card when it's inserted into PEX 8111/8112 based >> PCI-to-PCIE adapter. so, it's also helpful to test motherboards with >> different chipset. in any case it's always better to find and use >> native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter >> and PCI card. anyway, maybe, someone with more hardware engineering >> knowledge then i have, especially if the problem is 12V can find some >> way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are >> floating around, because i'm sure they just sacrifice 12V power to >> lower the BOM cost of the adapter. BTW, i'm sure your firewire card is >> working, because it doesn't use 12V PCI interface pins - it's the same >> with many PCI cards, but all that needs 12V are no-go based on my >> experience. >> >> --konstantin >> >> On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten >> wrote: >>> Hello, >>> >>> This card (technisat cablestar hd 2 dvb-c) works fine when plugged >>> into a native PCI slot. >>> When I try it with a PCI-adapter I intend to use in mITX-builds there >>> doesn't seem >>> to be any data coming in through the tuner. The adapter is a >>> transparent bridge (with a >>> PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a >>> 4-pin molex. >>> >>> My guess is some kind of dma mapping incompatibility with the mantis >>> driver (s2-liplianin). >>> The card seems to initialize correctly, but doesn't work when the >>> tuner is put into action >>> (scandvb timeouts, dvbtraffic yields nothing). For the record, I've >>> tested the bridge with a >>> firewire card and that works fine. >>> >>> Kernel is 2.6.32 (+the compiled drivers) >>> >>> lspci for the bridge and the card: >>> -- >>> 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI >>> Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>> ParErr- Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >>> SERR- >> Latency: 0, Cache Line Size: 32 bytes >>> Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 >>> I/O behind bridge: e000-efff >>> Memory behind bridge: fdd0-fddf >>> Prefetchable memory behind bridge: fdc0-fdcf >>> Secondary stat
[patch v2] [media] stv090x: handle allocation failures
kmalloc() can fail so check whether state->internal is NULL.
append_internal() can return NULL on allocation failures so check that.
Also if we hit the error condition later in the function then there is
a memory leak and we need to call remove_dev() to fix it.
Also Oliver Endriss pointed out an additional leak that I missed in the
first version of this patch.
Signed-off-by: Dan Carpenter
---
v2: Fix the leak Oliver noticed.
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index d3362d0..41d0f0a 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -4783,7 +4783,13 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
} else {
state->internal = kmalloc(sizeof(struct stv090x_internal),
GFP_KERNEL);
+ if (!state->internal)
+ goto error;
temp_int = append_internal(state->internal);
+ if (!temp_int) {
+ kfree(state->internal);
+ goto error;
+ }
state->internal->num_used = 1;
state->internal->mclk = 0;
state->internal->dev_ver = 0;
@@ -4796,7 +4802,7 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
if (stv090x_setup(&state->frontend) < 0) {
dprintk(FE_ERROR, 1, "Error setting up device");
- goto error;
+ goto err_remove;
}
}
@@ -4811,6 +4817,9 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
return &state->frontend;
+err_remove:
+ remove_dev(state->internal);
+ kfree(state->internal);
error:
kfree(state);
return NULL;
--
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] v4l-utils: Add the JPEG Lite decoding function
Hi Hans, I got the permission to relicense the JPEG Lite decoding to the LGPL. If you want to test the nw80x driver, get the gspca tarball from my web page (2.12.12). I added your webcam which should directly work (p35u - chip nw801). Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ jpgl.pat Description: Binary data
[PATCH] cx23885: restore flushes of cx23885_dev work items
Commit 8c71778c (media/video: don't use flush_scheduled_work())
dropped flush_scheduled_work() from cx23885_input_ir_stop()
incorrectly assuming that it didn't use any work item; however,
cx23885_dev makes use of three work items - cx25840_work and
ir_{r|t}x_work.
Make cx23885_input_ir_stop() sync flush all three work items before
returning.
Signed-off-by: Tejun Heo
Reported-by: Andy Walls
Reviewed-by: Andy Walls
Cc: Dmitry Torokhov
Cc: Mauro Carvalho Chehab
---
drivers/media/video/cx23885/cx23885-input.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/cx23885/cx23885-input.c
b/drivers/media/video/cx23885/cx23885-input.c
index 199b996..e27cedb 100644
--- a/drivers/media/video/cx23885/cx23885-input.c
+++ b/drivers/media/video/cx23885/cx23885-input.c
@@ -229,6 +229,9 @@ static void cx23885_input_ir_stop(struct cx23885_dev *dev)
v4l2_subdev_call(dev->sd_ir, ir, rx_s_parameters, ¶ms);
v4l2_subdev_call(dev->sd_ir, ir, rx_g_parameters, ¶ms);
}
+ flush_work_sync(&dev->cx25840_work);
+ flush_work_sync(&dev->ir_rx_work);
+ flush_work_sync(&dev->ir_tx_work);
}
static void cx23885_input_ir_close(struct rc_dev *rc)
--
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: cx23885-input.c does in fact use a workqueue....
Hello, On Mon, Feb 14, 2011 at 07:54:36PM -0500, Andy Walls wrote: > > 1. Just flush the work items explicitly using flush_work_sync(). > > That will do for now. > > > 2. Create a dedicated workqueue to serve as flushing domain. > > I have gotten reports of the IR Rx FIFO overflows for the CX23885 IR Rx > unit (the I2C connected one). I eventually should either set the Rx > FIFO service interrupt watermark down from 4 measurments to 1 > measurment, or use a kthread_worker with some higher priority to respond > to the IR Rx FIFO service interrupt. Hmmm... please consider playing with WQ_HIGHPRI before going forward with dedicated thread. > > The first would look like the following. Does this look correct? > > Yes, your patch below looks sane to me. > > Reviewed-by: Andy Walls Thanks. Will send patch with proper description soon. -- tejun -- 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: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
last, but not least, that i totally forgot - on my tests with audio card PEX 8111/8112 adapter is stuttering to transfer 8 channel, 192 kHz, 24-bit audio, which is very small data rate comparing to DVB data - i'm not sure though, it's because of increased latency or PEX 8111/8112 adapter can't handle huge data rate for some other reason. On Tue, Feb 15, 2011 at 10:20 AM, Konstantin Dimitrov wrote: > oh, i have just noticed your DVB card is for Cable and not for > Satellite, but still it may use 12V PCI interface pins for something > else and not exactly for LNB power as i thought assuming it's DVB-S/S2 > DVB card. > > On Tue, Feb 15, 2011 at 10:18 AM, Konstantin Dimitrov > wrote: >> hi, does your DVB card can get signal lock when it's inserted into the >> PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE >> adapters based on PEX 8111/8112 don't provide power to 12V pins of the >> PCI interface, which probably all PCI DVB card use for LNB power. so, >> what i would check if i'm at your position is the LNB power of the >> card as well as if there is no some extensive amount of noise in the >> LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE >> adapter. also, i can give you example from my own experience with an >> "Audiotrak Prodigy HD2" PCI audio card and PEX 8111/8112 based >> PCI-to-PCIE adapters - with one such adapter that don't provide power >> to 12V pins of the PCI interface there is no sound coming out, because >> the amplifier on the card uses power from 12V pins of the PCI >> interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems >> to provide power to 12V pins there is extensive noise in the sound >> that is coming out, because PCI-to-PCIE adapter doesn't provide good >> power on 12V pins of the PCI interface and thus the noise in the >> audio. also, on some motherboards (with nVidia chipset on my tests) >> there was some problem with how the memory was mapped preventing the >> work of the PCI card when it's inserted into PEX 8111/8112 based >> PCI-to-PCIE adapter. so, it's also helpful to test motherboards with >> different chipset. in any case it's always better to find and use >> native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter >> and PCI card. anyway, maybe, someone with more hardware engineering >> knowledge then i have, especially if the problem is 12V can find some >> way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are >> floating around, because i'm sure they just sacrifice 12V power to >> lower the BOM cost of the adapter. BTW, i'm sure your firewire card is >> working, because it doesn't use 12V PCI interface pins - it's the same >> with many PCI cards, but all that needs 12V are no-go based on my >> experience. >> >> --konstantin >> >> On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten >> wrote: >>> Hello, >>> >>> This card (technisat cablestar hd 2 dvb-c) works fine when plugged >>> into a native PCI slot. >>> When I try it with a PCI-adapter I intend to use in mITX-builds there >>> doesn't seem >>> to be any data coming in through the tuner. The adapter is a >>> transparent bridge (with a >>> PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a >>> 4-pin molex. >>> >>> My guess is some kind of dma mapping incompatibility with the mantis >>> driver (s2-liplianin). >>> The card seems to initialize correctly, but doesn't work when the >>> tuner is put into action >>> (scandvb timeouts, dvbtraffic yields nothing). For the record, I've >>> tested the bridge with a >>> firewire card and that works fine. >>> >>> Kernel is 2.6.32 (+the compiled drivers) >>> >>> lspci for the bridge and the card: >>> -- >>> 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI >>> Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>> ParErr- Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >>> SERR- >> Latency: 0, Cache Line Size: 32 bytes >>> Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 >>> I/O behind bridge: e000-efff >>> Memory behind bridge: fdd0-fddf >>> Prefetchable memory behind bridge: fdc0-fdcf >>> Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- >>> PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- >>> Capabilities: >>> Kernel modules: shpchp >>> >>> 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV >>> PCI Bridge Controller [Ver 1.0] (rev 01) >>> Subsystem: Device 1ae4:0002 >>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>> ParErr- Stepping- SERR- FastB2B- DisINTx- >>> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- SERR- >> Latency: 32 (20
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
oh, i have just noticed your DVB card is for Cable and not for Satellite, but still it may use 12V PCI interface pins for something else and not exactly for LNB power as i thought assuming it's DVB-S/S2 DVB card. On Tue, Feb 15, 2011 at 10:18 AM, Konstantin Dimitrov wrote: > hi, does your DVB card can get signal lock when it's inserted into the > PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE > adapters based on PEX 8111/8112 don't provide power to 12V pins of the > PCI interface, which probably all PCI DVB card use for LNB power. so, > what i would check if i'm at your position is the LNB power of the > card as well as if there is no some extensive amount of noise in the > LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE > adapter. also, i can give you example from my own experience with an > "Audiotrak Prodigy HD2" PCI audio card and PEX 8111/8112 based > PCI-to-PCIE adapters - with one such adapter that don't provide power > to 12V pins of the PCI interface there is no sound coming out, because > the amplifier on the card uses power from 12V pins of the PCI > interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems > to provide power to 12V pins there is extensive noise in the sound > that is coming out, because PCI-to-PCIE adapter doesn't provide good > power on 12V pins of the PCI interface and thus the noise in the > audio. also, on some motherboards (with nVidia chipset on my tests) > there was some problem with how the memory was mapped preventing the > work of the PCI card when it's inserted into PEX 8111/8112 based > PCI-to-PCIE adapter. so, it's also helpful to test motherboards with > different chipset. in any case it's always better to find and use > native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter > and PCI card. anyway, maybe, someone with more hardware engineering > knowledge then i have, especially if the problem is 12V can find some > way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are > floating around, because i'm sure they just sacrifice 12V power to > lower the BOM cost of the adapter. BTW, i'm sure your firewire card is > working, because it doesn't use 12V PCI interface pins - it's the same > with many PCI cards, but all that needs 12V are no-go based on my > experience. > > --konstantin > > On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten > wrote: >> Hello, >> >> This card (technisat cablestar hd 2 dvb-c) works fine when plugged >> into a native PCI slot. >> When I try it with a PCI-adapter I intend to use in mITX-builds there >> doesn't seem >> to be any data coming in through the tuner. The adapter is a >> transparent bridge (with a >> PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a >> 4-pin molex. >> >> My guess is some kind of dma mapping incompatibility with the mantis >> driver (s2-liplianin). >> The card seems to initialize correctly, but doesn't work when the >> tuner is put into action >> (scandvb timeouts, dvbtraffic yields nothing). For the record, I've >> tested the bridge with a >> firewire card and that works fine. >> >> Kernel is 2.6.32 (+the compiled drivers) >> >> lspci for the bridge and the card: >> -- >> 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI >> Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> SERR- > Latency: 0, Cache Line Size: 32 bytes >> Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 >> I/O behind bridge: e000-efff >> Memory behind bridge: fdd0-fddf >> Prefetchable memory behind bridge: fdc0-fdcf >> Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >>>TAbort- > BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- >> PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- >> Capabilities: >> Kernel modules: shpchp >> >> 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV >> PCI Bridge Controller [Ver 1.0] (rev 01) >> Subsystem: Device 1ae4:0002 >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >>>TAbort- SERR- > Latency: 32 (2000ns min, 63750ns max) >> Interrupt: pin A routed to IRQ 16 >> Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] >> Kernel driver in use: Mantis >> Kernel modules: mantis >> >> dmesg output with modules loaded: >> - >> Mantis :04:00.0: PCI INT A -> Link[APC7] -> GSI 16 (level, low) -> IRQ 16 >> irq: 16, latency: 32 >> memory: 0xfdcff000, mmio: 0xc900031a >> found a VP-2040 PCI DVB-C device on (04:00.0),
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
hi, does your DVB card can get signal lock when it's inserted into the PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE adapters based on PEX 8111/8112 don't provide power to 12V pins of the PCI interface, which probably all PCI DVB card use for LNB power. so, what i would check if i'm at your position is the LNB power of the card as well as if there is no some extensive amount of noise in the LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE adapter. also, i can give you example from my own experience with an "Audiotrak Prodigy HD2" PCI audio card and PEX 8111/8112 based PCI-to-PCIE adapters - with one such adapter that don't provide power to 12V pins of the PCI interface there is no sound coming out, because the amplifier on the card uses power from 12V pins of the PCI interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems to provide power to 12V pins there is extensive noise in the sound that is coming out, because PCI-to-PCIE adapter doesn't provide good power on 12V pins of the PCI interface and thus the noise in the audio. also, on some motherboards (with nVidia chipset on my tests) there was some problem with how the memory was mapped preventing the work of the PCI card when it's inserted into PEX 8111/8112 based PCI-to-PCIE adapter. so, it's also helpful to test motherboards with different chipset. in any case it's always better to find and use native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter and PCI card. anyway, maybe, someone with more hardware engineering knowledge then i have, especially if the problem is 12V can find some way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are floating around, because i'm sure they just sacrifice 12V power to lower the BOM cost of the adapter. BTW, i'm sure your firewire card is working, because it doesn't use 12V PCI interface pins - it's the same with many PCI cards, but all that needs 12V are no-go based on my experience. --konstantin On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten wrote: > Hello, > > This card (technisat cablestar hd 2 dvb-c) works fine when plugged > into a native PCI slot. > When I try it with a PCI-adapter I intend to use in mITX-builds there > doesn't seem > to be any data coming in through the tuner. The adapter is a > transparent bridge (with a > PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a > 4-pin molex. > > My guess is some kind of dma mapping incompatibility with the mantis > driver (s2-liplianin). > The card seems to initialize correctly, but doesn't work when the > tuner is put into action > (scandvb timeouts, dvbtraffic yields nothing). For the record, I've > tested the bridge with a > firewire card and that works fine. > > Kernel is 2.6.32 (+the compiled drivers) > > lspci for the bridge and the card: > -- > 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI > Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 32 bytes > Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 > I/O behind bridge: e000-efff > Memory behind bridge: fdd0-fddf > Prefetchable memory behind bridge: fdc0-fdcf > Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >>TAbort- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- > PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- > Capabilities: > Kernel modules: shpchp > > 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV > PCI Bridge Controller [Ver 1.0] (rev 01) > Subsystem: Device 1ae4:0002 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >>TAbort- SERR- Latency: 32 (2000ns min, 63750ns max) > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] > Kernel driver in use: Mantis > Kernel modules: mantis > > dmesg output with modules loaded: > - > Mantis :04:00.0: PCI INT A -> Link[APC7] -> GSI 16 (level, low) -> IRQ 16 > irq: 16, latency: 32 > memory: 0xfdcff000, mmio: 0xc900031a > found a VP-2040 PCI DVB-C device on (04:00.0), > Mantis Rev 1 [1ae4:0002], irq: 16, latency: 32 > memory: 0xfdcff000, mmio: 0xc900031a > MAC Address=[00:08:c9:d0:46:b4] > mantis_alloc_buffers (0): DMA=0x1bb9 cpu=0x88001bb9 size=65536 > mantis_alloc_buffers (0): RISC=0x1bbec000 cpu=0x88001bbec000 size=1000 > DVB: registering new adapter (Mantis dvb adapter) > mantis_frontend_init (0): Probing for CU1216 (DVB-C) > TDA
[PATCH v19 2/3] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver
This module implements V4L2 controls for the Texas Instruments
WL1273 FM Radio and handles the communication with the chip.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/radio/Kconfig| 16 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 2183
3 files changed, 2200 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..3c5a473 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,20 @@ config RADIO_TIMBERDALE
found behind the Timberdale FPGA on the Russellville board.
Enabling this driver will automatically select the DSP and tuner.
+config RADIO_WL1273
+ tristate "Texas Instruments WL1273 I2C FM Radio"
+ depends on I2C && VIDEO_V4L2
+ select MFD_WL1273_CORE
+ select FW_LOADER
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to "v4l2" programs may be found at
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..37a7cc7
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,2183 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Author: Matti J. Aaltonen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "Wl1273 FM Radio"
+
+#define WL1273_POWER_SET_OFF 0
+#define WL1273_POWER_SET_FMBIT(0)
+#define WL1273_POWER_SET_RDS BIT(1)
+#define WL1273_POWER_SET_RETENTION BIT(4)
+
+#define WL1273_PUPD_SET_OFF0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION 0x10
+
+#define WL1273_FREQ(x) (x * 1 / 625)
+#define WL1273_INV_FREQ(x) (x * 625 / 1)
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, "The number of the radio device. Default = 0");
+
+struct wl1273_device {
+ char *bus_type;
+
+ u8 forbidden;
+ unsigned int preemphasis;
+ unsigned int spacing;
+ unsigned int tx_power;
+ unsigned int rx_frequency;
+ unsigned int tx_frequency;
+ unsigned int rangelow;
+ unsigned int rangehigh;
+ unsigned int band;
+ bool stereo;
+
+ /* RDS */
+ unsigned int rds_on;
+ struct delayed_work work;
+
+ wait_queue_head_t read_queue;
+ struct mutex lock; /* for serializing fm radio operations */
+ struct completion busy;
+
+ unsigned char *buffer;
+ unsigned int buf_size;
+ unsigned int rd_index;
+ unsigned int wr_index;
+
+ /* Selected interrupts */
+ u16 irq_flags;
+ u16 irq_received;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ struct file *owner;
+ char *write_buf;
+ unsigned int rds_users;
+};
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT | \
+ WL1273_POW_ENB_EVENT)
+
+/*
+ * static unsigned int rds_buf - the number of RDS buffer blocks used.
+ *
+ * The default number is 100.
+ */
+static unsigned int rds_b
[PATCH v19 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.
This is the core of the WL1273 FM radio driver, it connects
the two child modules. The two child drivers are
drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.
The radio-wl1273 driver implements the V4L2 interface and communicates
with the device. The ALSA codec offers digital audio, without it only
analog audio is available.
Signed-off-by: Matti J. Aaltonen
---
drivers/mfd/Kconfig | 10 ++
drivers/mfd/Makefile|1 +
drivers/mfd/wl1273-core.c | 295 +++
include/linux/mfd/wl1273-core.h | 291 ++
4 files changed, 597 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a1493b..7c2e6c3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -606,6 +606,16 @@ config MFD_VX855
VIA VX855/VX875 south bridge. You will need to enable the vx855_spi
and/or vx855_gpio drivers for this to do anything useful.
+config MFD_WL1273_CORE
+ tristate "Support for TI WL1273 FM radio."
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+ This is the core driver for the TI WL1273 FM radio. This MFD
+ driver connects the radio-wl1273 V4L2 module and the wl1273
+ audio codec.
+
endif # MFD_SUPPORT
menu "Multimedia Capabilities Port drivers"
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f54b365..ae2f915 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -81,3 +81,4 @@ obj-$(CONFIG_MFD_JANZ_CMODIO) += janz-cmodio.o
obj-$(CONFIG_MFD_JZ4740_ADC) += jz4740-adc.o
obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855)+= vx855.o
+obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..66e0ac9
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,295 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Author: Matti Aaltonen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+
+#define DRIVER_DESC "WL1273 FM Radio Core"
+
+static struct i2c_device_id wl1273_driver_id_table[] = {
+ { WL1273_FM_DRIVER_NAME, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, wl1273_driver_id_table);
+
+
+static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+ struct i2c_client *client = core->client;
+ u8 b[2];
+ int r;
+
+ r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
+ if (r != 2) {
+ dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+ return -EREMOTEIO;
+ }
+
+ *value = (u16)b[0] << 8 | b[1];
+
+ return 0;
+}
+
+static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+ struct i2c_client *client = core->client;
+ u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+ int r;
+
+ r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
+ if (r) {
+ dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+ return r;
+ }
+
+ return 0;
+}
+
+static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+ struct i2c_client *client = core->client;
+ struct i2c_msg msg;
+ int r;
+
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.buf = data;
+ msg.len = len;
+
+ r = i2c_transfer(client->adapter, &msg, 1);
+ if (r != 1) {
+ dev_err(&client->dev, "%s: write error.\n", __func__);
+ return -EREMOTEIO;
+ }
+
+ return 0;
+}
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core: A pointer to the device struct.
+ * @new_mode: The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+ int r = 0;
+
+ if (core->mode == WL1273_MODE_OFF ||
+ core->mode == WL1273_MODE_SUSPENDED)
+ return -EPERM;
+
+ if (core->mode ==
[PATCH v19 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.
These changes are needed to keep up with the changes in the
MFD core and V4L2 parts of the wl1273 FM radio driver.
Use function pointers instead of exported functions for I2C IO.
Also move all preprocessor constants from the wl1273.h to
include/linux/mfd/wl1273-core.h.
Signed-off-by: Matti J. Aaltonen
---
sound/soc/codecs/Kconfig |2 +-
sound/soc/codecs/wl1273.c | 38
sound/soc/codecs/wl1273.h | 71 -
3 files changed, 20 insertions(+), 91 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 3b5690d..4e77f67 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -43,7 +43,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL6040 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
- select SND_SOC_WL1273 if WL1273_CORE
+ select SND_SOC_WL1273 if MFD_WL1273_CORE
select SND_SOC_WM2000 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
index 0c47c78..62a30a3 100644
--- a/sound/soc/codecs/wl1273.c
+++ b/sound/soc/codecs/wl1273.c
@@ -43,7 +43,7 @@ struct wl1273_priv {
static int snd_wl1273_fm_set_i2s_mode(struct wl1273_core *core,
int rate, int width)
{
- struct device *dev = &core->i2c_dev->dev;
+ struct device *dev = &core->client->dev;
int r = 0;
u16 mode;
@@ -124,13 +124,13 @@ static int snd_wl1273_fm_set_i2s_mode(struct wl1273_core
*core,
dev_dbg(dev, "mode: 0x%04x\n", mode);
if (core->i2s_mode != mode) {
- r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET, mode);
+ r = core->write(core, WL1273_I2S_MODE_CONFIG_SET, mode);
if (r)
goto out;
core->i2s_mode = mode;
- r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
- WL1273_AUDIO_ENABLE_I2S);
+ r = core->write(core, WL1273_AUDIO_ENABLE,
+ WL1273_AUDIO_ENABLE_I2S);
if (r)
goto out;
}
@@ -143,8 +143,7 @@ out:
static int snd_wl1273_fm_set_channel_number(struct wl1273_core *core,
int channel_number)
{
- struct i2c_client *client = core->i2c_dev;
- struct device *dev = &client->dev;
+ struct device *dev = &core->client->dev;
int r = 0;
dev_dbg(dev, "%s\n", __func__);
@@ -155,17 +154,13 @@ static int snd_wl1273_fm_set_channel_number(struct
wl1273_core *core,
goto out;
if (channel_number == 1 && core->mode == WL1273_MODE_RX)
- r = wl1273_fm_write_cmd(core, WL1273_MOST_MODE_SET,
- WL1273_RX_MONO);
+ r = core->write(core, WL1273_MOST_MODE_SET, WL1273_RX_MONO);
else if (channel_number == 1 && core->mode == WL1273_MODE_TX)
- r = wl1273_fm_write_cmd(core, WL1273_MONO_SET,
- WL1273_TX_MONO);
+ r = core->write(core, WL1273_MONO_SET, WL1273_TX_MONO);
else if (channel_number == 2 && core->mode == WL1273_MODE_RX)
- r = wl1273_fm_write_cmd(core, WL1273_MOST_MODE_SET,
- WL1273_RX_STEREO);
+ r = core->write(core, WL1273_MOST_MODE_SET, WL1273_RX_STEREO);
else if (channel_number == 2 && core->mode == WL1273_MODE_TX)
- r = wl1273_fm_write_cmd(core, WL1273_MONO_SET,
- WL1273_TX_STEREO);
+ r = core->write(core, WL1273_MONO_SET, WL1273_TX_STEREO);
else
r = -EINVAL;
out:
@@ -185,7 +180,12 @@ static int snd_wl1273_get_audio_route(struct snd_kcontrol
*kcontrol,
return 0;
}
-static const char *wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" };
+/*
+ * TODO: Implement the audio routing in the driver. Now this control
+ * only indicates the setting that has been done elsewhere (in the user
+ * space).
+ */
+static const char * const wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" };
static int snd_wl1273_set_audio_route(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
@@ -238,14 +238,14 @@ static int snd_wl1273_fm_audio_put(struct snd_kcontrol
*kcontrol,
if (wl1273->core->audio_mode == val)
return 0;
- r = wl1273_fm_set_audio(wl1273->core, val);
+ r = wl1273->core->set_audio(wl1273->core, val);
if (r < 0)
return r;
return 1;
}
-static const char *wl1273_audio_strings[] = { "Digital", "Analog" };
+static const char * const wl1273_audio_strings[] = { "Digital", "Analog" };
static const struct soc_enum wl1273_audio_enum =
[PATCH v19 0/3] TI Wl1273 FM radio driver.
Hello. Now I've refactored the code so that the I2C I/O functions are in the MFD core. Also now the codec can be compiled without compiling the V4L2 driver. I haven't implemented the audio routing (yet), but I've added a TODO comment about it in the codec file. Cheers, Matti Matti J. Aaltonen (3): MFD: WL1273 FM Radio: MFD driver for the FM radio. V4L2: WL1273 FM Radio: TI WL1273 FM radio driver ASoC: WL1273 FM radio: Access I2C IO functions through pointers. drivers/media/radio/Kconfig| 16 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 2183 drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile |1 + drivers/mfd/wl1273-core.c | 295 + include/linux/mfd/wl1273-core.h| 291 + sound/soc/codecs/Kconfig |2 +- sound/soc/codecs/wl1273.c | 38 +- sound/soc/codecs/wl1273.h | 71 -- 10 files changed, 2817 insertions(+), 91 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c create mode 100644 drivers/mfd/wl1273-core.c create mode 100644 include/linux/mfd/wl1273-core.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
