[PATCH] uvcvideo: add zero fill for VIDIOC_ENUM_FMT
From: Márton Németh
When enumerating formats with VIDIOC_ENUM_FMT the uvcvideo driver does not
fill the reserved fields of the struct v4l2_fmtdesc with zeros as required by
V4L2 API revision 0.24 [1]. Add the missing initializations.
The patch was tested with v4l-test 0.10 [2] with CNF7129 webcam found on EeePC
901.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r8367.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh
---
--- linux-2.6.29/drivers/media/video/uvc/uvc_v4l2.c.orig2009-03-24
00:12:14.0 +0100
+++ linux-2.6.29/drivers/media/video/uvc/uvc_v4l2.c 2009-03-25
07:24:42.0 +0100
@@ -673,11 +673,19 @@ static long uvc_v4l2_do_ioctl(struct fil
{
struct v4l2_fmtdesc *fmt = arg;
struct uvc_format *format;
+ __u32 index;
+ enum v4l2_buf_type type;
if (fmt->type != video->streaming->type ||
fmt->index >= video->streaming->nformats)
return -EINVAL;
+ index = fmt->index;
+ type = fmt->type;
+ memset(fmt, 0, sizeof(*fmt));
+ fmt->index = index;
+ fmt->type = type;
+
format = &video->streaming->format[fmt->index];
fmt->flags = 0;
if (format->flags & UVC_FMT_FLAG_COMPRESSED)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ov772x: add edge contrl support
Dear Guennadi
Thank you for checking patch
> Whatever this "edge" does, isn't it so, that "threshold," "upper," and
> "lower" parameters configure it and "strength" actually enforces the
> changes? Say, if strength == 0, edge control is off, and as soon as you
> switch it to != 0, it is on with all the configured parameters? If my
> guess is right, wouldn't it make sense to first configure parameters and
> then set strength? If you agree, I'll just swap them when committing, so,
> you don't have to resend. Just please either confirm that you agree, or
> explain why I am wrong.
I don't know detail of these register's order.
Because my datasheet doesn't have detail explain.
For example, does "strength" actually enforce
all of configured parameters change ?
So, I tried to test whether these register setting
order were important.
It seems to be independent apparently respectively.
For example, I can change only "upper" register and
the setting was effective.
So, I will ask to maker about these register's behavior.
Because it seems to relate to other register.
So, please ignore this patch until I get answer. sorry.
> +#define OV772X_EDGECTRL(s, t, u, l) \
> +{\
> + .strength = (s & 0x1F), \
> + .threshold = (t & 0x0F), \
> + .upper = (u & 0xFF), \
> + .lower = (l & 0xFF), \
> +}
I will fix this in next =)
Best regards
--
Kuninori Morimoto
--
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
zc3xx: Add .driver_info to DLink DSB - C320
Hello Jean, Attached patch for the following: zc3xx: Add .driver_info to DLink DSB - C320 Added .driver_info = SENSOR_PAS106 to 0x0ac8, 0x0302 (D-Link DSB - C320) Thanks to Bruna Griebeler for reporting and test. Reported-by: Bruna Griebeler Tested-by: Bruna Griebeler Signed-off-by: Douglas Schilling Landgraf Thanks, Douglas zc3xx-add-driver-info.diff Description: Binary data
[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for a large collection of pvrusb2 changesets (see below). Way back around November 2005, I had written a large chunk of code in the driver to provide uniform control of the associated i2c modules. With the advent of the v4l2-subdev framework within V4L, that old i2c layer in the pvrusb2 driver has become obsolete. The vast majority of these changes transform the pvrusb2 driver such that it now uses the v4l2-subdev framework, replacing the old i2c module control layer. In the end, the pvrusb2 driver is somewhat simpler now. I recommend that this whole things find its way into the 2.6.30 kernel merge window. Note: This will not be checkpatch.pl "clean". Though I have taken great care to abide by the questionable space-after-comma silliness (and boy did that suck - it's not AT ALL easy to change a 21 year habit), other warnings will still be present. The high-runner will be things related to single-line or compound if-statements. We've had that discussion before and I anticipate not to have to repeat it again. I don't remember any other warnings of any real consequence. Oh one thing, part of this series involved an early changeset that moves a large chunk of old code to a new file. That changeset will be rife with checkpatch.pl complaints, but it's code that is otherwise unchanged and I'm not about to sanitize it all purely for the sake of that script. (Besides, most if not all of that old code goes away in a later changeset anyway.) -Mike - pvrusb2: Split i2c module handling from i2c adapter - pvrusb2: Set up v4l2_device instance - pvrusb2: Changes to further isolate old i2c layer - pvrusb2: whitespace trivial tweaks - pvrusb2: New device attribute mechanism to specify sub-devices - pvrusb2: Providing means to stop tracking an old i2c module - pvrusb2: whitespace tweaks - pvrusb2: Set i2c autoprobing to be off by default - pvrusb2: Tie up loose ends with v4l2-subdev setup - pvrusb2: Lay foundation for triggering sub-device updates - pvrusb2: Tie-in sub-device log requests - pvrusb2: Tie in debug register access to sub-devices - pvrusb2: Implement status fetching from sub-devices - pvrusb2: Tie in various v4l2 operations into the sub-device mechanism - pvrusb2: Define value for a null sub-device ID - pvrusb2: Note who our video decoder sub-device is, and set it up - pvrusb2: Clean-up / placeholders inserted for additional development - pvrusb2: Tie in sub-device decoder start/stop - pvrusb2: Cause overall initialization to fail if sub-driver(s) fail - pvrusb2: Fix backwards function header comments - pvrusb2: Implement reporting of connected sub-devices - pvrusb2: Implement sub-device specific update framework - pvrusb2: Tie in wm8775 sub-device handling - pvrusb2: Tie in saa7115 sub-device handling - pvrusb2: Make audio sample rate update into a sub-device broadcast - pvrusb2: make sub-device specific update function names uniform - pvrusb2: Tie in msp3400 sub-device support - pvrusb2: Fix silly 80 column issue - pvrusb2: Tie in cx25840 sub-device support - pvrusb2: Implement more sub-device loading trace and improve error handling - pvrusb2: Define default i2c address for wm8775 sub-device - pvrusb2: Fix uninitialized counter - pvrusb2: Fix bugs involved in listing of sub-devices - pvrusb2: Allow sub-devices to insert correctly - pvrusb2: Sub-device update must happen BEFORE state dirty bits are cleared - pvrusb2: Deal with space-after-comma coding style idiocy - pvrusb2: Broadcast tuner type change to sub-devices - pvrusb2: Define default I2C address for cx25840 sub-device - pvrusb2: Implement trace print for stream on / off action - pvrusb2: Correct some trace print inaccuracies - pvrusb2: Implement mechanism to force a full sub-device update - pvrusb2: Issue required core init broadcast to all sub-devices - pvrusb2: Define default I2C addresses for msp3400 and saa7115 sub-devices - pvrusb2: Fix incorrectly named sub-device ID - pvrusb2: Define default I2C address for CS53L32A sub-device - pvrusb2: Convert all device definitions to use new sub-device declarations - pvrusb2: Make a bunch of dvb config structures const (trivial) - pvrusb2: Fix space-after-comma idiocy - pvrusb2: Fix slightly mis-leading header in debug interface output - pvrusb2: Implement better reporting on attached sub-devices - pvrusb2: Remove old i2c layer; we use v4l2-subdev now - pvrusb2: Remove ancient IVTV specific ioctl functions - pvrusb2: Add sub-device for demod - pvrusb2: Add composite and s-video input support for OnAir devices - pvrusb2: Use v4l2_device_disconnect() a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-chips-v4l2.c | 119 - a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.c | 339 a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.h | 53 a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-track.c | 504 -- a/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-track.h | 102 - a/linux/drivers/medi
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Tue, 2009-03-24 at 18:08 -0400, Steven Toth wrote: > >> Let me ask this rhetorical question: if we did nothing more than just > >> normalize the SNR to provide a consistent value in dB, and did nothing > >> more than normalize the existing strength field to be 0-100%, leaving > >> it up to the driver author to decide the actual heuristic, what > >> percentage of user's needs would be fulfilled? > > We don't need a new API and more complexity and/or code confusion, just > standardize on the unit values for the existing APIs. > > 1) SNR in either units of db or units of .1 db (I don't care which, although > I > prefer the later). Devin, ETSI TR 101 290 v1.2.1 can provide some guidance and information on conversion of measurement quantities. For example, as part of a conversion from Es/No to S/N, Annex G, G.2 and G.3 tells you the right factor to use to convert from No to N. Here's where to go to download the document: http://pda.etsi.org/pda/queryform.asp (Free registration required. Downloads of DVB docs are free.) The list of DVB standards is here: http://www.dvb.org/technology/standards/index.xml Regards, Andy > 2) Strength as a percentage. > > The approach Devin outlined above has my support. > > - Steve > -- 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: [question] atsc and api v5
On Tue, 2009-03-24 at 13:13 -0400, Devin Heitmueller wrote:
> On Tue, Mar 24, 2009 at 12:35 PM, wk wrote:
> > While trying to update an application to API v5 some question arised.
> >
> > Which type of "delivery_system" should be set for ATSC?
> > says...
> >
> > SYS_DVBC_ANNEX_AC, <- european DVB-C
> > SYS_DVBC_ANNEX_B, <- american ATSC QAM
> > ..
> > SYS_ATSC, <- oops, here we have ATSC again, cable and terrestrial not
> > named? Is this VSB *only*?
> >
> >
> >
> > Which one should i choose, "SYS_ATSC" for both (VSB and QAM),
> > or should i choose SYS_DVBC_ANNEX_B for ATSC cable and SYS_ATSC for VSB?
> >
> > thanks,
> > Winfried
>
> I'm pretty sure it's SYS_ATSC for both VSB and QAM.
>
> Devin
Hmmm...
The compatability code between the API v5 property cache and the API v3
frontend parameters use...
a. This code for translating v3 parameters into the v5 cache:
static void dtv_property_cache_sync(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
c->frequency = p->frequency;
c->inversion = p->inversion;
switch (fe->ops.info.type) {
...
case FE_ATSC:
c->modulation = p->u.vsb.modulation;
if ((c->modulation == VSB_8) || (c->modulation == VSB_16))
c->delivery_system = SYS_ATSC;
else
c->delivery_system = SYS_DVBC_ANNEX_B;
break;
}
}
b. This code for translating v5 cache into the v3 parameters:
static void dtv_property_legacy_params_sync(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dvb_frontend_parameters *p = &fepriv->parameters;
p->frequency = c->frequency;
p->inversion = c->inversion;
switch (fe->ops.info.type) {
...
case FE_ATSC:
dprintk("%s() Preparing VSB req\n", __func__);
p->u.vsb.modulation = c->modulation;
if ((c->modulation == VSB_8) || (c->modulation == VSB_16))
c->delivery_system = SYS_ATSC;
else
c->delivery_system = SYS_DVBC_ANNEX_B;
break;
}
}
So it would seem the code to fill out v3 parameter structures uses
SYS_DVBC_ANNEX_B as the "delivery system" for ATSC FE's that aren't
using VSB modulation.
Not that SYS_ATSC nor SYS_DVBC_ANNEX_B are used/checked as a delivery
system by any driver (yet.)
I've checked DVB-C (ETSI EN 300 429 v1.2.1) Annex B and it really
doesn't mention or reference ATSC QAM explicitly, but it does have a
table of QAM modulations useful in 8 MHz BWs down to a 2 MHz BW.
I've also looked at A/53 Part 2 which only talks about VSB modulations.
I couldn't find any free NCTA documents on QAM for American cable
systems.
I did find that ITU-T J.83 Annex B describes the framing structure,
channel coding, and modulation schemes for digital cable service in
North America. And that J.83 Annex A and J.83 Annex C defines the cable
modulation schemes for Japanese and European regions, respectively.
I'm trying to dig up a free copy if I can.
I suspect SYS_DVBC_ANNEX_B and SYS_DVB_ANNEX_AC in the Linux enumeration
don't refer to the DVB C standard Annexes, but refer to ITU-T J.83
Annexes.
So I'm assumming SYS_DVBC_ANNEX_B *is* the Linux delivery system
enumaeration value you want for North American Cable QAM modulations
with FE_ATSC.
Anyone got the ITU-T J.83 document to confirm or refute?
BTW, I plan on starting to documenting the API v5 changes in the Linux
DVB spec within the next week or so.
Regards,
Andy
--
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 17/61] v4l: struct device - replace bus_id with dev_name(), dev_set_name()
From: Kay Sievers Cc: mche...@infradead.org Cc: linux-media@vger.kernel.org Acked-by: Greg Kroah-Hartman Signed-off-by: Kay Sievers --- drivers/media/radio/radio-tea5764.c |3 ++- drivers/media/video/v4l2-device.c |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/radio/radio-tea5764.c b/drivers/media/radio/radio-tea5764.c index 4d35308..3936238 100644 --- a/drivers/media/radio/radio-tea5764.c +++ b/drivers/media/radio/radio-tea5764.c @@ -298,7 +298,8 @@ static int vidioc_querycap(struct file *file, void *priv, strlcpy(v->driver, dev->dev.driver->name, sizeof(v->driver)); strlcpy(v->card, dev->name, sizeof(v->card)); - snprintf(v->bus_info, sizeof(v->bus_info), "I2C:%s", dev->dev.bus_id); + snprintf(v->bus_info, sizeof(v->bus_info), +"I2C:%s", dev_name(&dev->dev)); v->version = RADIO_VERSION; v->capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO; return 0; diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index cf9d4c7..8a4b74f 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -34,7 +34,7 @@ int v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev) spin_lock_init(&v4l2_dev->lock); v4l2_dev->dev = dev; snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "%s %s", - dev->driver->name, dev->bus_id); + dev->driver->name, dev_name(dev)); dev_set_drvdata(dev, v4l2_dev); return 0; } -- 1.6.2 -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Tue, Mar 24, 2009 at 4:46 PM, Manu Abraham wrote: >>> From the end user point of view it is not very usefull if he has 2 >> different cards and application can not show any usefull signal goodness >> info in a way that would be easy to compare. So I think the attempt to >> standardize to db is good. > > The first part: For comparison having a standardized value is good. > > True. > > But the problem that surrounds it: > > To do this, a driver should support statistics in dB. For a device > which doesn't show statistics in dB, for reasons > (a) device uses a different format > > (b) enough information is not available to do a conversion > (too less information, or a reverse engineered driver) > > (c) the conversion to be done makes things too complex in kernel land. > > So you have very less devices to do a comparison between. Those are strong points you're making and more then enough reason to maintain the values in their native form and deal with it elsewhere. > The other way to do this: > > Suppose, the driver that doesn't support a dB format (relative > doesn't mean unknown) provides the information in a relative format. > And the driver that provides the information in dB format, but that > information you get, can be converted in to a relative floor - > ceiling format (conversion handled by application, or by a library) > > This is a quick way. > > Now, which all devices do provide a scale in dB, which is really > comparable ? There are many different parameters, quickly hacked > together to be called SNR. In the terms you mention, you will be > comparing things like > > SNR to CNR etc based on the device type. > > So eventually your comparison is wrong. Another good point. And a quick comment that I like the idea of a library. This takes the burden off the app while leaving options available instead of just forcing everything to dB whether it's compatible or not. >> Maybe there could then in addition be some other optional method for >> also getting data in some hw specific format in a way that Manu suggested. >> But there should anyway be mandatory to have this one "standard goodness >> value" in a way that does not require apps to make any complicate >> comparisons... (I bet half of those apps would be broken for years) > > In the way i mentioned, it leaves to the application to choose from > different styles such as > > (1) display parameters from the drivers, in their own native format > (This is a completely human readable format, in which you can see > the real scales) > > (2) convert parameters to a specific format. > (The very important part here is that the application is free to > convert from format A with driver X and format B with driver Y, to > get it into a unified format. if you really need the feature what > you mentioned, you need this feature, rather than have all drivers > being modified to provide one standard format) > > To make things look simple, i have a sample application which does > (1) to make things look simple. > > If you choose to do (2) It will be just doing the conversion one > time in a library or application, once rather than doing it multiple > times in unknown ways and formats. Makes sense. One of my concerns was that this would just be slapped together and rushed like some other things were and finding out how bad of an idea that was after the fact. This doesn't need to take forever to reach a majority opinion, but it should have enough thought behind it to not cut people off at the knees. It sounds to me that preserving the native format is certainly a good idea for the numerous reasons that have been pointed out, and providing converting via library is the most sane approach. Trying to force a square into a circle never seems to work out very well. Best regards, Derek -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Mika Laitio wrote: > But there should anyway be mandatory to have this one "standard goodness > value" in a way that does not require apps to make any complicate > comparisons... (I bet half of those apps would be broken for years) That said, the conversion functions can be added into libdvb, how we have added support for EN50221 CAM support. Apps that use the library can simply use the builtin functions and forget about all those conversions. That might help some of the applciations which are not conversant in conversions. Regards, Manu -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Mika Laitio wrote: That said, the solution takes the approach of "revolutionary" as opposed to "evolutionary", which always worries me. While providing a much more powerful interface, it also means all of the applications will have to properly support all of the various possible representations of the data, increasing the responsibility in userland considerably. >> >> Not necessarily, the application can simply chose to support what >> the driver provides as is, thereby doing no translations at all. > >> From the end user point of view it is not very usefull if he has 2 > different cards and application can not show any usefull signal goodness > info in a way that would be easy to compare. So I think the attempt to > standardize to db is good. The first part: For comparison having a standardized value is good. True. But the problem that surrounds it: To do this, a driver should support statistics in dB. For a device which doesn't show statistics in dB, for reasons (a) device uses a different format (b) enough information is not available to do a conversion (too less information, or a reverse engineered driver) (c) the conversion to be done makes things too complex in kernel land. So you have very less devices to do a comparison between. The other way to do this: Suppose, the driver that doesn't support a dB format (relative doesn't mean unknown) provides the information in a relative format. And the driver that provides the information in dB format, but that information you get, can be converted in to a relative floor - ceiling format (conversion handled by application, or by a library) This is a quick way. Now, which all devices do provide a scale in dB, which is really comparable ? There are many different parameters, quickly hacked together to be called SNR. In the terms you mention, you will be comparing things like SNR to CNR etc based on the device type. So eventually your comparison is wrong. > Maybe there could then in addition be some other optional method for > also getting data in some hw specific format in a way that Manu suggested. > But there should anyway be mandatory to have this one "standard goodness > value" in a way that does not require apps to make any complicate > comparisons... (I bet half of those apps would be broken for years) In the way i mentioned, it leaves to the application to choose from different styles such as (1) display parameters from the drivers, in their own native format (This is a completely human readable format, in which you can see the real scales) (2) convert parameters to a specific format. (The very important part here is that the application is free to convert from format A with driver X and format B with driver Y, to get it into a unified format. if you really need the feature what you mentioned, you need this feature, rather than have all drivers being modified to provide one standard format) To make things look simple, i have a sample application which does (1) to make things look simple. If you choose to do (2) It will be just doing the conversion one time in a library or application, once rather than doing it multiple times in unknown ways and formats. Regards, Manu -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
That said, the solution takes the approach of "revolutionary" as opposed to "evolutionary", which always worries me. While providing a much more powerful interface, it also means all of the applications will have to properly support all of the various possible representations of the data, increasing the responsibility in userland considerably. Not necessarily, the application can simply chose to support what the driver provides as is, thereby doing no translations at all. From the end user point of view it is not very usefull if he has 2 different cards and application can not show any usefull signal goodness info in a way that would be easy to compare. So I think the attempt to standardize to db is good. Maybe there could then in addition be some other optional method for also getting data in some hw specific format in a way that Manu suggested. But there should anyway be mandatory to have this one "standard goodness value" in a way that does not require apps to make any complicate comparisons... (I bet half of those apps would be broken for years) Mika -- 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: [REVIEW] v4l2 loopback
On Wed, Mar 25, 2009 at 1:07 AM, Alexey Klimov wrote:
> Hello, Vasily
>
> On Tue, 2009-03-24 at 21:27 +0200, vas...@gmail.com wrote:
>> Hello, please review new version of v4l2 loopback driver.
>> driver works fine but there are things which I am not shure in.
>> Is it ok not to count mmaped buffers and just free memory when no open
>> file descriptors left?
>>
>> Here is patch against current v4l-dvb tree
>> -
>> This patch introduces v4l2 loopback module
>>
>> From: Vasily Levin
>>
>> This is v4l2 loopback driver which can be used to make available any
>> userspace
>> video as v4l2 device. Initialy it was written to make videoeffects available
>> to Skype, but in fact it have many more uses.
>>
>> Priority: normal
>>
>> Signed-off-by: Vasily Levin
>>
>> diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig
>> v4l-dvb.my/linux/drivers/media/video/Kconfig
>> --- v4l-dvb.orig/linux/drivers/media/video/Kconfig 2009-03-21
>> 07:08:06.0 +0200
>> +++ v4l-dvb.my/linux/drivers/media/video/Kconfig 2009-03-24
>> 12:58:38.0 +0200
>> @@ -465,6 +465,13 @@ config VIDEO_VIVI
>> Say Y here if you want to test video apps or debug V4L devices.
>> In doubt, say N.
>>
>> +config VIDEO_V4L2_LOOPBACK
>> + tristate "v4l2 loopback driver"
>> + depends on VIDEO_V4L2 && VIDEO_DEV
>> + help
>> + Say Y if you want to use v4l2 loopback driver.
>> + This driver can be compiled as a module, called v4l2loopback.
>> +
>> source "drivers/media/video/bt8xx/Kconfig"
>>
>> config VIDEO_SAA6588
>> @@ -899,7 +906,7 @@ config USB_S2255
>> depends on VIDEO_V4L2
>> select VIDEOBUF_VMALLOC
>> default n
>> - help
>> + ---help---
>
> As i understand this change in not part of the patch..
>
>> Say Y here if you want support for the Sensoray 2255 USB device.
>> This driver can be compiled as a module, called s2255drv.
>>
>> diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile
>> v4l-dvb.my/linux/drivers/media/video/Makefile
>> --- v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-03-21
>> 07:08:06.0 +0200
>> +++ v4l-dvb.my/linux/drivers/media/video/Makefile 2009-03-24
>> 12:54:59.0 +0200
>> @@ -132,6 +132,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
>> obj-$(CONFIG_VIDEO_CX18) += cx18/
>>
>> obj-$(CONFIG_VIDEO_VIVI) += vivi.o
>> +obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o
>> obj-$(CONFIG_VIDEO_CX23885) += cx23885/
>>
>> obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
>> diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c
>> v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c
>> --- v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01
>> 03:00:00.0 +0300
>> +++ v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-03-24
>> 18:51:41.0 +0200
>> @@ -0,0 +1,726 @@
>> +/*
>> + * v4l2loopback.c -- video 4 linux loopback driver
>> + *
>> + * Copyright (C) 2005-2009
>> + * Vasily Levin (vas...@gmail.com)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "v4l2loopback.h"
>> +
>> +#define DEBUG
>> +#define DEBUG_RW
>> +#define YAVLD_STREAMING
>> +#define KERNEL_PREFIX "YAVLD device: " /* Prefix of each kernel
>> message */
>> +/* global module data */
>> +struct v4l2_loopback_device *dev;
>> +/* forward declarations */
>> +static void init_buffers(int buffer_size);
>> +static const struct v4l2_file_operations v4l2_loopback_fops;
>> +static const struct v4l2_ioctl_ops v4l2_loopback_ioctl_ops;
>> +/
>> + my queue helpers ***
>> +/
>> +/* next functions sets buffer flags and adjusts counters accordingly */
>> +void set_done(struct v4l2_buffer *buffer)
>> +{
>> + buffer->flags |= V4L2_BUF_FLAG_DONE;
>> + buffer->flags &= ~V4L2_BUF_FLAG_QUEUED;
>> +}
>> +
>> +void set_queued(struct v4l2_buffer *buffer)
>> +{
>> + buffer->flags |= V4L2_BUF_FLAG_QUEUED;
>> + buffer->flags &= ~V4L2_BUF_FLAG_DONE;
>> +}
>> +
>> +void unset_all(struct v4l2_buffer *buffer)
>> +{
>> + buffer->flags &= ~V4L2_BUF_FLAG_QUEUED;
>> + buffer->flags &= ~V4L2_BUF_FLAG_DONE;
>> +}
>
> Can this functions be static and inlined ?
>
>> +/
>> + V4L2 ioctl caps and params calls ***
>> +/
>> +/**
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote:
> On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller
> wrote:
>> Wow, well this literally kept me up all night pondering the various options.
>>
>> Manu's idea has alot of merit - providing a completely new API that
>> provides the "raw data without translation" as well as a way to query
>> for what that format is for the raw data, provides a great deal more
>> flexibility for applications that want to perform advanced analysis
>> and interpretation of the data.
>>
>> That said, the solution takes the approach of "revolutionary" as
>> opposed to "evolutionary", which always worries me. While providing a
>> much more powerful interface, it also means all of the applications
>> will have to properly support all of the various possible
>> representations of the data, increasing the responsibility in userland
>> considerably.
Not necessarily, the application can simply chose to support what
the driver provides as is, thereby doing no translations at all.
The change to the application is rather quite small, as you can see
from the quick patch and a modified femon.
>From what you see, it should be that simple.
>> Let me ask this rhetorical question: if we did nothing more than just
>> normalize the SNR to provide a consistent value in dB, and did nothing
>> more than normalize the existing strength field to be 0-100%, leaving
>> it up to the driver author to decide the actual heuristic, what
>> percentage of user's needs would be fulfilled?
>>
>> I bet the answer would be something like 99%.
You can really scale values to dB only if it is in some dB scale.
Looking at the drivers there are hardly a few drivers that do in dB.
If it were to be standardized in to "one standard format" i would
rather prefer to have the format what the API currently suggests:
That is to have a floor - ceiling value, without any units, rather
than one which forces all drivers to dB (in this case the drivers
which do not will be considered broken), the reason being this
hardly helps a few drivers, while the reverse holds true for all.
Regards,
Manu
diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Mar 25 01:22:31 2009 +0400
-1607,6 +1607,13 @@
break;
}
+ case FE_STATISTICS_CAPS: {
+ struct fecap_statistics *stats_cap = parg;
+ memcpy(stats_cap, &fe->ops.statistics_caps, sizeof (struct fecap_statistics));
+ err = 0;
+ break;
+ }
+
case FE_READ_STATUS: {
fe_status_t* status = parg;
-1622,6 +1629,17 @@
err = fe->ops.read_status(fe, status);
break;
}
+
+ case FE_SIGNAL_LEVEL:
+ if (fe->ops.read_level)
+ err = fe->ops.read_level(fe, (__u32 *) parg);
+ break;
+
+ case FE_SIGNAL_STATS:
+ if (fe->ops.read_stats)
+ err = fe->ops.read_stats(fe, (struct fesignal_stat *) parg);
+ break;
+
case FE_READ_BER:
if (fe->ops.read_ber)
err = fe->ops.read_ber(fe, (__u32*) parg);
diff -r 421de709288e linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Mar 25 01:22:31 2009 +0400
-252,6 +252,7 @@
struct dvb_frontend_ops {
struct dvb_frontend_info info;
+ struct fecap_statistics statistics_caps;
void (*release)(struct dvb_frontend* fe);
void (*release_sec)(struct dvb_frontend* fe);
-298,6 +299,9 @@
*/
enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
int (*track)(struct dvb_frontend *fe, struct dvb_frontend_parameters *p);
+
+ int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */
+ int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat);
struct dvb_tuner_ops tuner_ops;
struct analog_demod_ops analog_ops;
diff -r 421de709288e linux/drivers/media/dvb/frontends/stb0899_drv.c
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Mar 18 23:42:34 2009 +0400
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Mar 25 01:22:31 2009 +0400
-1226,6 +1226,29 @@
return 0;
}
+static int stb0899_read_level(struct dvb_frontend *fe, u32 *signal)
+{
+ /* TODO! */
+ return 0;
+}
+
+static int stb0899_read_stats(struct dvb_frontend *fe, struct fesignal_stat *stats)
+{
+ u16 snr, strength;
+ u32 ber;
+
+ stb0899_read_snr(fe, &snr);
+ stb0899_read_signal_strength(fe, &strength);
+ stb0899_read_ber(fe, &ber);
+
+ stats->quality = snr;
+ stats->strength = strength;
+ stats->error = ber;
+ stats->unc = 0;
+
+ return 0;
+}
+
static int stb0899_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
{
struct stb0899_state *state = fe->demodulator_priv;
-1917,6 +1940,27 @@
FE_CAN_QPSK
},
+ .statistics_caps = {
+ .quality = {
+ .params = FE_QUALITY_CNR,
+ .scale = FE_SCALE_dB,
+ .exponent = -4,
+ },
+
+ .strength = {
+ .params = FE_SCALE_dB,
+ .exponent = -4,
+ },
+
Re: [cron job] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: OK
On Tue, 2009-03-24 at 10:04 +0100, Hans Verkuil wrote: > Hmm, everything is OK. > > Let's enjoy this moment of perfection! It probably won't last long :-) > > Regards, > >Hans > > > 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 Mar 24 08:33:25 CET 2009 > > path:http://www.linuxtv.org/hg/v4l-dvb > > changeset: 11153:56cf0f1772f7 > > gcc version: gcc (GCC) 4.3.1 > > hardware:x86_64 > > host os: 2.6.26 > > > > linux-2.6.22.19-armv5: OK > > linux-2.6.23.12-armv5: OK > > linux-2.6.24.7-armv5: OK > > linux-2.6.25.11-armv5: OK > > linux-2.6.26-armv5: OK > > linux-2.6.27-armv5: OK > > linux-2.6.28-armv5: OK > > linux-2.6.29-armv5: OK > > linux-2.6.27-armv5-ixp: OK Sorry to rain on the parade, but: linux-2.6.27-armv5-ixp: WARNINGS CC [M] /marune/build/v4l-dvb-master/v4l/sp887x.o /tmp/ccqyC3HA.s: CC [M] /marune/build/v4l-dvb-master/v4l/nxt6000.o the logs and the summary log appear to disagree. Or maybe the assembler was having a bad day. So close :) Regards, Andy > > linux-2.6.28-armv5-ixp: OK > > linux-2.6.29-armv5-ixp: OK > > linux-2.6.28-armv5-omap2: OK > > linux-2.6.29-armv5-omap2: OK > > linux-2.6.22.19-i686: OK > > linux-2.6.23.12-i686: OK > > linux-2.6.24.7-i686: OK > > linux-2.6.25.11-i686: OK > > linux-2.6.26-i686: OK > > linux-2.6.27-i686: OK > > linux-2.6.28-i686: OK > > linux-2.6.29-i686: OK > > linux-2.6.23.12-m32r: OK > > linux-2.6.24.7-m32r: OK > > linux-2.6.25.11-m32r: OK > > linux-2.6.26-m32r: OK > > linux-2.6.27-m32r: OK > > linux-2.6.28-m32r: OK > > linux-2.6.29-m32r: OK > > linux-2.6.22.19-mips: OK > > linux-2.6.26-mips: OK > > linux-2.6.27-mips: OK > > linux-2.6.28-mips: OK > > linux-2.6.29-mips: OK > > linux-2.6.27-powerpc64: OK > > linux-2.6.28-powerpc64: OK > > linux-2.6.29-powerpc64: OK > > linux-2.6.22.19-x86_64: OK > > linux-2.6.23.12-x86_64: OK > > linux-2.6.24.7-x86_64: OK > > linux-2.6.25.11-x86_64: OK > > linux-2.6.26-x86_64: OK > > linux-2.6.27-x86_64: OK > > linux-2.6.28-x86_64: OK > > linux-2.6.29-x86_64: OK > > fw/apps: OK > > sparse (linux-2.6.29): ERRORS > > linux-2.6.16.61-i686: OK > > linux-2.6.17.14-i686: OK > > linux-2.6.18.8-i686: OK > > linux-2.6.19.5-i686: OK > > linux-2.6.20.21-i686: OK > > linux-2.6.21.7-i686: OK > > linux-2.6.16.61-x86_64: OK > > linux-2.6.17.14-x86_64: OK > > linux-2.6.18.8-x86_64: OK > > linux-2.6.19.5-x86_64: OK > > linux-2.6.20.21-x86_64: OK > > linux-2.6.21.7-x86_64: OK > > > > 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 V4L2 specification from this daily build is here: > > > > http://www.xs4all.nl/~hverkuil/spec/v4l2.html > > > > The DVB API specification from this daily build is here: > > > > http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 12/13][Resubmit][drivers/media] changed ioctls to unlocked
> > {
> > + lock_kernel();
> > +
>
> Why moving to unlocked_ioctl if you're acquiring the Big Kernel Lock
> anyways?
Ok, forget it, just saw Alexey mail chain...
Understood.
Regards,
Sergio
--
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
saa7134 streaming broken?
Hello - I have a RTD Technologies VFG7350 (saa7134 based, two channel, no tuner). I'd like to stream the compressed data. I/O read works: v4l2-apps/test/capture-example --device /dev/video2 --read but streaming does not: $ v4l2-apps/test/capture-example --device /dev/video2 --mmap /dev/video2 does not support memory mapping: Invalid argument This is error EINVAL from ioctl( VIDIOC_REQBUFS ). Streaming is listed as a capability of the device: $ v4l2-dbg --device /dev/video2 --info Driver info: Driver name : saa7134 Card type : RTD Embedded Technologies VFG73 Bus info : PCI::02:08.0 Driver version: 526 Capabilities : 0x0501 Video Capture Read/Write Streaming Is there hope that streaming can work? Thank you, Gordon
RE: [PATCH 12/13][Resubmit][drivers/media] changed ioctls to unlocked
Hi Stoyan,
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of stoyboy...@gmail.com
> Sent: Tuesday, March 24, 2009 3:39 PM
> To: linux-ker...@vger.kernel.org
> Cc: Stoyan Gaydarov; linux-media@vger.kernel.org
> Subject: [PATCH 12/13][Resubmit][drivers/media] changed ioctls to unlocked
>
> From: Stoyan Gaydarov
>
> Signed-off-by: Stoyan Gaydarov
> ---
> drivers/media/dvb/bt8xx/dst_ca.c |7 +--
> drivers/media/video/dabusb.c | 11 ---
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/dvb/bt8xx/dst_ca.c
> b/drivers/media/dvb/bt8xx/dst_ca.c
> index 0258451..d3487c5 100644
> --- a/drivers/media/dvb/bt8xx/dst_ca.c
> +++ b/drivers/media/dvb/bt8xx/dst_ca.c
> @@ -552,8 +552,10 @@ free_mem_and_exit:
> return result;
> }
>
> -static int dst_ca_ioctl(struct inode *inode, struct file *file, unsigned
> int cmd, unsigned long ioctl_arg)
> +static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned
> long ioctl_arg)
> {
> + lock_kernel();
> +
Why moving to unlocked_ioctl if you're acquiring the Big Kernel Lock anyways?
--
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: [REVIEW] v4l2 loopback
Hello, Vasily
On Tue, 2009-03-24 at 21:27 +0200, vas...@gmail.com wrote:
> Hello, please review new version of v4l2 loopback driver.
> driver works fine but there are things which I am not shure in.
> Is it ok not to count mmaped buffers and just free memory when no open
> file descriptors left?
>
> Here is patch against current v4l-dvb tree
> -
> This patch introduces v4l2 loopback module
>
> From: Vasily Levin
>
> This is v4l2 loopback driver which can be used to make available any userspace
> video as v4l2 device. Initialy it was written to make videoeffects available
> to Skype, but in fact it have many more uses.
>
> Priority: normal
>
> Signed-off-by: Vasily Levin
>
> diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig
> v4l-dvb.my/linux/drivers/media/video/Kconfig
> --- v4l-dvb.orig/linux/drivers/media/video/Kconfig2009-03-21
> 07:08:06.0 +0200
> +++ v4l-dvb.my/linux/drivers/media/video/Kconfig 2009-03-24
> 12:58:38.0 +0200
> @@ -465,6 +465,13 @@ config VIDEO_VIVI
> Say Y here if you want to test video apps or debug V4L devices.
> In doubt, say N.
>
> +config VIDEO_V4L2_LOOPBACK
> + tristate "v4l2 loopback driver"
> + depends on VIDEO_V4L2 && VIDEO_DEV
> + help
> + Say Y if you want to use v4l2 loopback driver.
> + This driver can be compiled as a module, called v4l2loopback.
> +
> source "drivers/media/video/bt8xx/Kconfig"
>
> config VIDEO_SAA6588
> @@ -899,7 +906,7 @@ config USB_S2255
> depends on VIDEO_V4L2
> select VIDEOBUF_VMALLOC
> default n
> - help
> + ---help---
As i understand this change in not part of the patch..
> Say Y here if you want support for the Sensoray 2255 USB device.
> This driver can be compiled as a module, called s2255drv.
>
> diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile
> v4l-dvb.my/linux/drivers/media/video/Makefile
> --- v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-03-21
> 07:08:06.0 +0200
> +++ v4l-dvb.my/linux/drivers/media/video/Makefile 2009-03-24
> 12:54:59.0 +0200
> @@ -132,6 +132,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
> obj-$(CONFIG_VIDEO_CX18) += cx18/
>
> obj-$(CONFIG_VIDEO_VIVI) += vivi.o
> +obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o
> obj-$(CONFIG_VIDEO_CX23885) += cx23885/
>
> obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
> diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c
> v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c
> --- v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01
> 03:00:00.0 +0300
> +++ v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-03-24
> 18:51:41.0 +0200
> @@ -0,0 +1,726 @@
> +/*
> + * v4l2loopback.c -- video 4 linux loopback driver
> + *
> + * Copyright (C) 2005-2009
> + * Vasily Levin (vas...@gmail.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "v4l2loopback.h"
> +
> +#define DEBUG
> +#define DEBUG_RW
> +#define YAVLD_STREAMING
> +#define KERNEL_PREFIX "YAVLD device: " /* Prefix of each kernel
> message */
> +/* global module data */
> +struct v4l2_loopback_device *dev;
> +/* forward declarations */
> +static void init_buffers(int buffer_size);
> +static const struct v4l2_file_operations v4l2_loopback_fops;
> +static const struct v4l2_ioctl_ops v4l2_loopback_ioctl_ops;
> +/
> + my queue helpers ***
> +/
> +/* next functions sets buffer flags and adjusts counters accordingly */
> +void set_done(struct v4l2_buffer *buffer)
> +{
> + buffer->flags |= V4L2_BUF_FLAG_DONE;
> + buffer->flags &= ~V4L2_BUF_FLAG_QUEUED;
> +}
> +
> +void set_queued(struct v4l2_buffer *buffer)
> +{
> + buffer->flags |= V4L2_BUF_FLAG_QUEUED;
> + buffer->flags &= ~V4L2_BUF_FLAG_DONE;
> +}
> +
> +void unset_all(struct v4l2_buffer *buffer)
> +{
> + buffer->flags &= ~V4L2_BUF_FLAG_QUEUED;
> + buffer->flags &= ~V4L2_BUF_FLAG_DONE;
> +}
Can this functions be static and inlined ?
> +/
> + V4L2 ioctl caps and params calls ***
> +/
> +/**/
> +/* returns device capabilities, called on VIDIOC_QUERYCAP ioctl*/
> +static int vidioc_querycap(struct file *file,
> +void *priv, struct v4l2_capabil
Re: [PATCH 12/13][Resubmit][drivers/media] changed ioctls to unlocked
On Tue, Mar 24, 2009 at 5:25 PM, Alexey Klimov wrote:
> Hello, Stoyan
>
> On Tue, 2009-03-24 at 16:38 -0500, stoyboy...@gmail.com wrote:
>> From: Stoyan Gaydarov
>>
>> Signed-off-by: Stoyan Gaydarov
>> ---
>> drivers/media/dvb/bt8xx/dst_ca.c | 7 +--
>> drivers/media/video/dabusb.c | 11 ---
>> 2 files changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/dvb/bt8xx/dst_ca.c
>> b/drivers/media/dvb/bt8xx/dst_ca.c
>> index 0258451..d3487c5 100644
>> --- a/drivers/media/dvb/bt8xx/dst_ca.c
>> +++ b/drivers/media/dvb/bt8xx/dst_ca.c
>> @@ -552,8 +552,10 @@ free_mem_and_exit:
>> return result;
>> }
>>
>> -static int dst_ca_ioctl(struct inode *inode, struct file *file, unsigned
>> int cmd, unsigned long ioctl_arg)
>> +static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned long
>> ioctl_arg)
>> {
>> + lock_kernel();
>> +
>> struct dvb_device* dvbdev = (struct dvb_device*) file->private_data;
>> struct dst_state* state = (struct dst_state*) dvbdev->priv;
>> struct ca_slot_info *p_ca_slot_info;
>> @@ -647,6 +649,7 @@ static int dst_ca_ioctl(struct inode *inode, struct file
>> *file, unsigned int cmd
>> kfree (p_ca_slot_info);
>> kfree (p_ca_caps);
>>
>> + unlock_kernel();
>> return result;
>> }
>>
>> @@ -684,7 +687,7 @@ static ssize_t dst_ca_write(struct file *file, const
>> char __user *buffer, size_t
>>
>> static struct file_operations dst_ca_fops = {
>> .owner = THIS_MODULE,
>> - .ioctl = dst_ca_ioctl,
>> + .unlocked_ioctl = dst_ca_ioctl,
>> .open = dst_ca_open,
>> .release = dst_ca_release,
>> .read = dst_ca_read,
>> diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
>> index 298810d..c31e76f 100644
>> --- a/drivers/media/video/dabusb.c
>> +++ b/drivers/media/video/dabusb.c
>> @@ -657,22 +657,26 @@ static int dabusb_release (struct inode *inode, struct
>> file *file)
>> return 0;
>> }
>>
>> -static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned
>> int cmd, unsigned long arg)
>> +static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned
>> long arg)
>> {
>> pdabusb_t s = (pdabusb_t) file->private_data;
>> pbulk_transfer_t pbulk;
>> int ret = 0;
>> int version = DABUSB_VERSION;
>>
>> + lock_kernel();
>> dbg("dabusb_ioctl");
>>
>> - if (s->remove_pending)
>> + if (s->remove_pending) {
>> + unlock_kernel();
>> return -EIO;
>> + }
>>
>> mutex_lock(&s->mutex);
>>
>> if (!s->usbdev) {
>> mutex_unlock(&s->mutex);
>> + unlock_kernel();
>> return -EIO;
>> }
>>
>> @@ -713,6 +717,7 @@ static int dabusb_ioctl (struct inode *inode, struct
>> file *file, unsigned int cm
>> break;
>> }
>> mutex_unlock(&s->mutex);
>> + unlock_kernel();
>
> May i ask why big kernel lock is used here?
> Where is an advantage of BKL here?
> Why not to use, for example, one more mutex lock?
The big kernel lock was already being used here, the call to ioctl is
surrounded by lock/unlock kernel, this patch just pushes it down so
that the __locked__ ioctl can be removed and also makes the
maintainers of the code aware that the lock was there. If the lock is
not needed then it can be removed and the function can remain under
the unlocked_ioctl.
>
> --
> Best regards, Klimov Alexey
>
>
--
-Stoyan
--
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 12/13][Resubmit][drivers/media] changed ioctls to unlocked
Hello, Stoyan
On Tue, 2009-03-24 at 16:38 -0500, stoyboy...@gmail.com wrote:
> From: Stoyan Gaydarov
>
> Signed-off-by: Stoyan Gaydarov
> ---
> drivers/media/dvb/bt8xx/dst_ca.c |7 +--
> drivers/media/video/dabusb.c | 11 ---
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/dvb/bt8xx/dst_ca.c
> b/drivers/media/dvb/bt8xx/dst_ca.c
> index 0258451..d3487c5 100644
> --- a/drivers/media/dvb/bt8xx/dst_ca.c
> +++ b/drivers/media/dvb/bt8xx/dst_ca.c
> @@ -552,8 +552,10 @@ free_mem_and_exit:
> return result;
> }
>
> -static int dst_ca_ioctl(struct inode *inode, struct file *file, unsigned int
> cmd, unsigned long ioctl_arg)
> +static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned long
> ioctl_arg)
> {
> + lock_kernel();
> +
> struct dvb_device* dvbdev = (struct dvb_device*) file->private_data;
> struct dst_state* state = (struct dst_state*) dvbdev->priv;
> struct ca_slot_info *p_ca_slot_info;
> @@ -647,6 +649,7 @@ static int dst_ca_ioctl(struct inode *inode, struct file
> *file, unsigned int cmd
> kfree (p_ca_slot_info);
> kfree (p_ca_caps);
>
> + unlock_kernel();
> return result;
> }
>
> @@ -684,7 +687,7 @@ static ssize_t dst_ca_write(struct file *file, const char
> __user *buffer, size_t
>
> static struct file_operations dst_ca_fops = {
> .owner = THIS_MODULE,
> - .ioctl = dst_ca_ioctl,
> + .unlocked_ioctl = dst_ca_ioctl,
> .open = dst_ca_open,
> .release = dst_ca_release,
> .read = dst_ca_read,
> diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
> index 298810d..c31e76f 100644
> --- a/drivers/media/video/dabusb.c
> +++ b/drivers/media/video/dabusb.c
> @@ -657,22 +657,26 @@ static int dabusb_release (struct inode *inode, struct
> file *file)
> return 0;
> }
>
> -static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned
> int cmd, unsigned long arg)
> +static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned long
> arg)
> {
> pdabusb_t s = (pdabusb_t) file->private_data;
> pbulk_transfer_t pbulk;
> int ret = 0;
> int version = DABUSB_VERSION;
>
> + lock_kernel();
> dbg("dabusb_ioctl");
>
> - if (s->remove_pending)
> + if (s->remove_pending) {
> + unlock_kernel();
> return -EIO;
> + }
>
> mutex_lock(&s->mutex);
>
> if (!s->usbdev) {
> mutex_unlock(&s->mutex);
> + unlock_kernel();
> return -EIO;
> }
>
> @@ -713,6 +717,7 @@ static int dabusb_ioctl (struct inode *inode, struct file
> *file, unsigned int cm
> break;
> }
> mutex_unlock(&s->mutex);
> + unlock_kernel();
May i ask why big kernel lock is used here?
Where is an advantage of BKL here?
Why not to use, for example, one more mutex lock?
--
Best regards, Klimov Alexey
--
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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Let me ask this rhetorical question: if we did nothing more than just normalize the SNR to provide a consistent value in dB, and did nothing more than normalize the existing strength field to be 0-100%, leaving it up to the driver author to decide the actual heuristic, what percentage of user's needs would be fulfilled? We don't need a new API and more complexity and/or code confusion, just standardize on the unit values for the existing APIs. 1) SNR in either units of db or units of .1 db (I don't care which, although I prefer the later). 2) Strength as a percentage. The approach Devin outlined above has my support. - Steve -- 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 12/13][Resubmit][drivers/media] changed ioctls to unlocked
From: Stoyan Gaydarov
Signed-off-by: Stoyan Gaydarov
---
drivers/media/dvb/bt8xx/dst_ca.c |7 +--
drivers/media/video/dabusb.c | 11 ---
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dst_ca.c b/drivers/media/dvb/bt8xx/dst_ca.c
index 0258451..d3487c5 100644
--- a/drivers/media/dvb/bt8xx/dst_ca.c
+++ b/drivers/media/dvb/bt8xx/dst_ca.c
@@ -552,8 +552,10 @@ free_mem_and_exit:
return result;
}
-static int dst_ca_ioctl(struct inode *inode, struct file *file, unsigned int
cmd, unsigned long ioctl_arg)
+static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned long
ioctl_arg)
{
+ lock_kernel();
+
struct dvb_device* dvbdev = (struct dvb_device*) file->private_data;
struct dst_state* state = (struct dst_state*) dvbdev->priv;
struct ca_slot_info *p_ca_slot_info;
@@ -647,6 +649,7 @@ static int dst_ca_ioctl(struct inode *inode, struct file
*file, unsigned int cmd
kfree (p_ca_slot_info);
kfree (p_ca_caps);
+ unlock_kernel();
return result;
}
@@ -684,7 +687,7 @@ static ssize_t dst_ca_write(struct file *file, const char
__user *buffer, size_t
static struct file_operations dst_ca_fops = {
.owner = THIS_MODULE,
- .ioctl = dst_ca_ioctl,
+ .unlocked_ioctl = dst_ca_ioctl,
.open = dst_ca_open,
.release = dst_ca_release,
.read = dst_ca_read,
diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
index 298810d..c31e76f 100644
--- a/drivers/media/video/dabusb.c
+++ b/drivers/media/video/dabusb.c
@@ -657,22 +657,26 @@ static int dabusb_release (struct inode *inode, struct
file *file)
return 0;
}
-static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned int
cmd, unsigned long arg)
+static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned long
arg)
{
pdabusb_t s = (pdabusb_t) file->private_data;
pbulk_transfer_t pbulk;
int ret = 0;
int version = DABUSB_VERSION;
+ lock_kernel();
dbg("dabusb_ioctl");
- if (s->remove_pending)
+ if (s->remove_pending) {
+ unlock_kernel();
return -EIO;
+ }
mutex_lock(&s->mutex);
if (!s->usbdev) {
mutex_unlock(&s->mutex);
+ unlock_kernel();
return -EIO;
}
@@ -713,6 +717,7 @@ static int dabusb_ioctl (struct inode *inode, struct file
*file, unsigned int cm
break;
}
mutex_unlock(&s->mutex);
+ unlock_kernel();
return ret;
}
@@ -721,7 +726,7 @@ static const struct file_operations dabusb_fops =
.owner =THIS_MODULE,
.llseek = no_llseek,
.read = dabusb_read,
- .ioctl =dabusb_ioctl,
+ .unlocked_ioctl = dabusb_ioctl,
.open = dabusb_open,
.release = dabusb_release,
};
--
1.6.2.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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Sun, Mar 22, 2009 at 9:00 PM, Devin Heitmueller wrote: > Wow, well this literally kept me up all night pondering the various options. > > Manu's idea has alot of merit - providing a completely new API that > provides the "raw data without translation" as well as a way to query > for what that format is for the raw data, provides a great deal more > flexibility for applications that want to perform advanced analysis > and interpretation of the data. > > That said, the solution takes the approach of "revolutionary" as > opposed to "evolutionary", which always worries me. While providing a > much more powerful interface, it also means all of the applications > will have to properly support all of the various possible > representations of the data, increasing the responsibility in userland > considerably. > > Let me ask this rhetorical question: if we did nothing more than just > normalize the SNR to provide a consistent value in dB, and did nothing > more than normalize the existing strength field to be 0-100%, leaving > it up to the driver author to decide the actual heuristic, what > percentage of user's needs would be fulfilled? > > I bet the answer would be something like 99%. > > I can see the value in an "advanced API" that could provide the > underlying raw data, but I feel like this could be provided in the > future at any point that someone cares enough to do the work. > > We can spend weeks debating and trying to design the "perfect > interface" (and possibly never come to an agreement as has gone on for > years), or we can just make a decision on how to represent the two > values that is "good enough", and we can have 99% of the population > satisfied virtually overnight (with the ability to provide an advanced > API to get the raw data in the future if there is ever sufficient > need). > > I'm willing to submit the patches for all the ATSC demods to conform > to the final API if the experts can just decide on what the format > should be. > > Devin Any other demod authors want to weigh in on this matter? Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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 12/13] [drivers/media] changed ioctls to unlocked
On Tue, Mar 24, 2009 at 04:31:54PM -0500, Stoyan Gaydarov wrote:
> On Tue, Mar 24, 2009 at 4:24 PM, Alan Cox wrote:
> >
> >> -static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned
> >> int cmd, unsigned long arg)
> >> +static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned
> >> long arg)
> >> {
> >> + lock_kernel();
> >> pdabusb_t s = (pdabusb_t) file->private_data;
> >
> > After the variables or you'll get lots of warnings from gcc
> >
> >
>
> Unfortunately I am not familiar with this driver and as such i was not
> sure if the variable required the lock to be accessed or not so as to
> play it safe i put it before the variable. But i can resubmit this
> patch if there are no problems.
Please do so.
It is considered better style to first decalre the variable and then later
assign it.
So this would allow you to move the assignment after the lock_kernel(),
Sam
--
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 12/13] [drivers/media] changed ioctls to unlocked
On Tue, Mar 24, 2009 at 4:24 PM, Alan Cox wrote:
>
>> -static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned
>> int cmd, unsigned long arg)
>> +static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned
>> long arg)
>> {
>> + lock_kernel();
>> pdabusb_t s = (pdabusb_t) file->private_data;
>
> After the variables or you'll get lots of warnings from gcc
>
>
Unfortunately I am not familiar with this driver and as such i was not
sure if the variable required the lock to be accessed or not so as to
play it safe i put it before the variable. But i can resubmit this
patch if there are no problems.
--
-Stoyan
--
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
scan vs dvbscan
Hello,
both in the Ubuntu package dvb-apps, and in the source from
http://linuxtv.org/hg/dvb-apps , there is both a program scan and dvbscan,
which are not the same. Which should be used when? I have a TechnoTrend
C-1501 DVB-C card, and only `scan` worked. `dvbscan
/usr/local/share/dvb/dvb-c/no-Oslo-CanalDigital` gave the output "Unable
to query frontend status".
Could the --help in the programs say something about which should work
when?
In util/dvbscan/dvbscan.c main():
if (dvbfe_get_info(fe, DVBFE_INFO_LOCKSTATUS, &feinfo,
DVBFE_INFO_QUERYTYPE_IMMEDIATE, 0) !=
DVBFE_INFO_QUERYTYPE_IMMEDIATE) {
fprintf(stderr, "Unable to query frontend status\n");
exit(1);
}
In lib/libdvbapi/dvbfe.c dvbfe_get_info():
switch(querytype) {
case DVBFE_INFO_QUERYTYPE_IMMEDIATE:
if (querymask & DVBFE_INFO_LOCKSTATUS) {
if (!ioctl(fehandle->fd, FE_READ_STATUS, &kevent.status)) {
returnval |= DVBFE_INFO_LOCKSTATUS;
}
}
...
return returnval;
I do not really understand this. If the call to ioctl *suceeds*,
DVBFE_INFO_LOCKSTATUS is returned, and exit(1) is called in main(). I do
not really understand this.
Klem fra Nils
--
http://www.idi.ntnu.no/~nilsgri/Why is this thus?
What is the reason of this thusness?
- Artemus Ward
--
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 12/13] [drivers/media] changed ioctls to unlocked
> -static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned
> int cmd, unsigned long arg)
> +static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned long
> arg)
> {
> + lock_kernel();
> pdabusb_t s = (pdabusb_t) file->private_data;
After the variables or you'll get lots of warnings from gcc
--
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 12/13] [drivers/media] changed ioctls to unlocked
From: Stoyan Gaydarov
Signed-off-by: Stoyan Gaydarov
---
drivers/media/dvb/bt8xx/dst_ca.c |7 +--
drivers/media/video/dabusb.c | 11 ---
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dst_ca.c b/drivers/media/dvb/bt8xx/dst_ca.c
index 0258451..d3487c5 100644
--- a/drivers/media/dvb/bt8xx/dst_ca.c
+++ b/drivers/media/dvb/bt8xx/dst_ca.c
@@ -552,8 +552,10 @@ free_mem_and_exit:
return result;
}
-static int dst_ca_ioctl(struct inode *inode, struct file *file, unsigned int
cmd, unsigned long ioctl_arg)
+static long dst_ca_ioctl(struct file *file, unsigned int cmd, unsigned long
ioctl_arg)
{
+ lock_kernel();
+
struct dvb_device* dvbdev = (struct dvb_device*) file->private_data;
struct dst_state* state = (struct dst_state*) dvbdev->priv;
struct ca_slot_info *p_ca_slot_info;
@@ -647,6 +649,7 @@ static int dst_ca_ioctl(struct inode *inode, struct file
*file, unsigned int cmd
kfree (p_ca_slot_info);
kfree (p_ca_caps);
+ unlock_kernel();
return result;
}
@@ -684,7 +687,7 @@ static ssize_t dst_ca_write(struct file *file, const char
__user *buffer, size_t
static struct file_operations dst_ca_fops = {
.owner = THIS_MODULE,
- .ioctl = dst_ca_ioctl,
+ .unlocked_ioctl = dst_ca_ioctl,
.open = dst_ca_open,
.release = dst_ca_release,
.read = dst_ca_read,
diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
index 298810d..ae4cd79 100644
--- a/drivers/media/video/dabusb.c
+++ b/drivers/media/video/dabusb.c
@@ -657,8 +657,9 @@ static int dabusb_release (struct inode *inode, struct file
*file)
return 0;
}
-static int dabusb_ioctl (struct inode *inode, struct file *file, unsigned int
cmd, unsigned long arg)
+static long dabusb_ioctl (struct file *file, unsigned int cmd, unsigned long
arg)
{
+ lock_kernel();
pdabusb_t s = (pdabusb_t) file->private_data;
pbulk_transfer_t pbulk;
int ret = 0;
@@ -666,13 +667,16 @@ static int dabusb_ioctl (struct inode *inode, struct file
*file, unsigned int cm
dbg("dabusb_ioctl");
- if (s->remove_pending)
+ if (s->remove_pending) {
+ unlock_kernel();
return -EIO;
+ }
mutex_lock(&s->mutex);
if (!s->usbdev) {
mutex_unlock(&s->mutex);
+ unlock_kernel();
return -EIO;
}
@@ -713,6 +717,7 @@ static int dabusb_ioctl (struct inode *inode, struct file
*file, unsigned int cm
break;
}
mutex_unlock(&s->mutex);
+ unlock_kernel();
return ret;
}
@@ -721,7 +726,7 @@ static const struct file_operations dabusb_fops =
.owner =THIS_MODULE,
.llseek = no_llseek,
.read = dabusb_read,
- .ioctl =dabusb_ioctl,
+ .unlocked_ioctl = dabusb_ioctl,
.open = dabusb_open,
.release = dabusb_release,
};
--
1.6.2
--
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: Failure to read saa7134/saa6752hs MPEG output
Am Dienstag, den 24.03.2009, 13:42 -0600 schrieb Gordon Smith:
> On Tue, Mar 24, 2009 at 1:15 PM, Hans Verkuil wrote:
> > On Tuesday 24 March 2009 19:47:13 hermann pitton wrote:
> >> Am Dienstag, den 24.03.2009, 03:03 +0100 schrieb hermann pitton:
> >> > Hi,
> >> >
> >> > Am Montag, den 23.03.2009, 11:33 -0600 schrieb Gordon Smith:
> >> > > On Fri, Mar 20, 2009 at 10:02 PM, hermann pitton
> >> > >
> >> > > wrote:
> >> > > > Hi,
> >> > > >
> >> > > > Am Freitag, den 20.03.2009, 14:24 -0600 schrieb Gordon Smith:
> >> > > > > Hello -
> >> > > > >
> >> > > > > I'm unable to read or stream compressed data from
> >> > > > > saa7134/saa6752hs.
> >> > > > >
> >> > > > > I have a RTD Technologies VFG7350 (saa7134 based, two channel,
> >> > > > > hardware encoder per channel, no tuner) running current v4l-dvb
> >> > > > > in debian 2.6.26-1.
> >> > > > >
> >> > > > > MPEG2-TS data is normally available on /dev/video2 and
> >> > > > > /dev/video3.
> >> > > > >
> >> > > > > Previously there were parameters for the saa6752hs module named
> >> > > > > "force" and "ignore" to modify i2c addresses. The current module
> >> > > > > appears to lack those parameters and may be using incorrect i2c
> >> > > > > addresses.
> >> > > > >
> >> > > > > Current dmesg:
> >> > > > >
> >> > > > > [ 13.388944] saa6752hs 3-0020: chip found @ 0x40 (saa7133[0])
> >> > > > > [ 13.588458] saa6752hs 4-0020: chip found @ 0x40 (saa7133[1])
> >> > > > >
> >> > > > > Prior dmesg (~2.6.25-gentoo-r7 + v4l-dvb ???):
> >> > > > >
> >> > > > > saa6752hs 1-0021: saa6752hs: chip found @ 0x42
> >> > > > > saa6752hs 1-0021: saa6752hs: chip found @ 0x42
> >> > > > >
> >> > > > > Prior modprobe.conf entry:
> >> > > > > options saa6752hs force=0x1,0x21,0x2,0x21
> >> > > > > ignore=0x0,0x20,0x1,0x20,0x2,0x20
> >>
> >> It was disabled by Hans when converting to v4l2_subdev here.
> >> http://linuxtv.org/hg/v4l-dvb/rev/c41af551e79f
> >>
> >> It is only valid for kernels < 2.6.22 now in saa6752hs.
> >>
> >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 22)
> >> /* Addresses to scan */
> >> static unsigned short normal_i2c[] = {0x20, I2C_CLIENT_END};
> >>
> >> I2C_CLIENT_INSMOD;
> >> +#endif
> >>
> >> And we only have that single 0x20 address in saa7134-core.c etc.
> >> That should be the problem.
> >>
> >> > > > > $ v4l2-dbg --device /dev/video2 --info
> >> > > > > Driver info:
> >> > > > > Driver name : saa7134
> >> > > > > Card type : RTD Embedded Technologies VFG73
> >> > > > > Bus info : PCI::02:08.0
> >> > > > > Driver version: 526
> >> > > > > Capabilities : 0x0501
> >> > > > > Video Capture
> >> > > > > Read/Write
> >> > > > > Streaming
> >> > > > >
> >> > > > > Streaming is a listed capability but the capture example at
> >> > > > > http://v4l2spec.bytesex.org/spec/capture-example.html fails
> >> > > > > during request for buffers.
> >> > > > >
> >> > > > > $ v4l2-capture --device /dev/video2 --mmap
> >> > > > > /dev/video2 does not support memory mapping
> >> > > > >
> >> > > > > v4l2-capture.c:
> >> > > > > req.count = 4;
> >> > > > > req.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
> >> > > > > req.memory = V4L2_MEMORY_MMAP;
> >> > > > >
> >> > > > > if (-1 == xioctl (fd, VIDIOC_REQBUFS, &req)) {
> >> > > > > if (EINVAL == errno) {
> >> > > > > fprintf (stderr, "%s does not support "
> >> > > > > "memory mapping\n", dev_name);
> >> > > > >
> >> > > > >
> >> > > > > A read() results in EIO error:
> >> > > > >
> >> > > > > $ v4l2-capture --device /dev/video0 --read
> >> > > > > read error 5, Input/output error
> >> > > > >
> >> > > > > v4l2-capture.c:
> >> > > > > if (-1 == read (fd, buffers[0].start,
> >> > > > > buffers[0].length)) { switch (errno) {
> >> > > > > ...
> >> > > > > default:
> >> > > > > errno_exit ("read");
> >> > > > >
> >> > > > >
> >> > > > > This behavior does not change if the saa6752hs module is not
> >> > > > > loaded.
> >> > > > >
> >> > > > > Is there still a way to modify the i2c address(es) for the
> >> > > > > saa6752hs module?
> >> > > > >
> >> > > > > Any pointers are appreciated.
> >> > > > >
> >> > > > > Gordon
> >> > > >
> >> > > > thanks for the report.
> >> > > >
> >> > > > It was probably forgotten that the prior insmod option had a
> >> > > > reason.
> >> > > >
> >> > > > Try to change it to 0x21 in saa7134-i2c.c
> >> > > >
> >> > > > static char *i2c_devs[128] = {
> >> > > >[ 0x20 ] = "mpeg encoder (saa6752hs)",
> >> > > >[ 0xa0 >> 1 ] = "eeprom",
> >> > > >[ 0xc0 >> 1 ] = "tuner (analog)",
> >> > > >[ 0x86 >> 1 ] = "tda9887",
> >> > > >[ 0x5a >> 1 ] = "remote control",
> >> > > > };
> >> > > >
> >> > > > and report if your cards a usable ag
Re: [PATCH 1/1 re-submit 1] sdio: add low level i/o functions for workarounds
On Sun, 22 Mar 2009 16:48:39 +0200 "Uri Shkolnik" wrote: > Hi Pierre, > > The USB separation patches are ready, and will be committed for review > shortly (SDIO stack workaround + Siano SDIO driver were the first to be > re-re-re-committed, SPI will be next, and after them the "core" which > includes the 'separation' code). You can view one (of many) older commit > operations @ > http://patchwork.kernel.org/project/linux-media/list/?submitter=Uri&stat > e=* > I see. Could you hold off on the SDIO patches and allow me to do a final cleanup once you have the separation patches done? Then I can send them directly to Mauro and we can have this merged quickly. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: Failure to read saa7134/saa6752hs MPEG output
On Tue, Mar 24, 2009 at 1:15 PM, Hans Verkuil wrote:
> On Tuesday 24 March 2009 19:47:13 hermann pitton wrote:
>> Am Dienstag, den 24.03.2009, 03:03 +0100 schrieb hermann pitton:
>> > Hi,
>> >
>> > Am Montag, den 23.03.2009, 11:33 -0600 schrieb Gordon Smith:
>> > > On Fri, Mar 20, 2009 at 10:02 PM, hermann pitton
>> > >
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > Am Freitag, den 20.03.2009, 14:24 -0600 schrieb Gordon Smith:
>> > > > > Hello -
>> > > > >
>> > > > > I'm unable to read or stream compressed data from
>> > > > > saa7134/saa6752hs.
>> > > > >
>> > > > > I have a RTD Technologies VFG7350 (saa7134 based, two channel,
>> > > > > hardware encoder per channel, no tuner) running current v4l-dvb
>> > > > > in debian 2.6.26-1.
>> > > > >
>> > > > > MPEG2-TS data is normally available on /dev/video2 and
>> > > > > /dev/video3.
>> > > > >
>> > > > > Previously there were parameters for the saa6752hs module named
>> > > > > "force" and "ignore" to modify i2c addresses. The current module
>> > > > > appears to lack those parameters and may be using incorrect i2c
>> > > > > addresses.
>> > > > >
>> > > > > Current dmesg:
>> > > > >
>> > > > > [ 13.388944] saa6752hs 3-0020: chip found @ 0x40 (saa7133[0])
>> > > > > [ 13.588458] saa6752hs 4-0020: chip found @ 0x40 (saa7133[1])
>> > > > >
>> > > > > Prior dmesg (~2.6.25-gentoo-r7 + v4l-dvb ???):
>> > > > >
>> > > > > saa6752hs 1-0021: saa6752hs: chip found @ 0x42
>> > > > > saa6752hs 1-0021: saa6752hs: chip found @ 0x42
>> > > > >
>> > > > > Prior modprobe.conf entry:
>> > > > > options saa6752hs force=0x1,0x21,0x2,0x21
>> > > > > ignore=0x0,0x20,0x1,0x20,0x2,0x20
>>
>> It was disabled by Hans when converting to v4l2_subdev here.
>> http://linuxtv.org/hg/v4l-dvb/rev/c41af551e79f
>>
>> It is only valid for kernels < 2.6.22 now in saa6752hs.
>>
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 22)
>> /* Addresses to scan */
>> static unsigned short normal_i2c[] = {0x20, I2C_CLIENT_END};
>>
>> I2C_CLIENT_INSMOD;
>> +#endif
>>
>> And we only have that single 0x20 address in saa7134-core.c etc.
>> That should be the problem.
>>
>> > > > > $ v4l2-dbg --device /dev/video2 --info
>> > > > > Driver info:
>> > > > > Driver name : saa7134
>> > > > > Card type : RTD Embedded Technologies VFG73
>> > > > > Bus info : PCI::02:08.0
>> > > > > Driver version: 526
>> > > > > Capabilities : 0x0501
>> > > > > Video Capture
>> > > > > Read/Write
>> > > > > Streaming
>> > > > >
>> > > > > Streaming is a listed capability but the capture example at
>> > > > > http://v4l2spec.bytesex.org/spec/capture-example.html fails
>> > > > > during request for buffers.
>> > > > >
>> > > > > $ v4l2-capture --device /dev/video2 --mmap
>> > > > > /dev/video2 does not support memory mapping
>> > > > >
>> > > > > v4l2-capture.c:
>> > > > > req.count = 4;
>> > > > > req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>> > > > > req.memory = V4L2_MEMORY_MMAP;
>> > > > >
>> > > > > if (-1 == xioctl (fd, VIDIOC_REQBUFS, &req)) {
>> > > > > if (EINVAL == errno) {
>> > > > > fprintf (stderr, "%s does not support "
>> > > > > "memory mapping\n", dev_name);
>> > > > >
>> > > > >
>> > > > > A read() results in EIO error:
>> > > > >
>> > > > > $ v4l2-capture --device /dev/video0 --read
>> > > > > read error 5, Input/output error
>> > > > >
>> > > > > v4l2-capture.c:
>> > > > > if (-1 == read (fd, buffers[0].start,
>> > > > > buffers[0].length)) { switch (errno) {
>> > > > > ...
>> > > > > default:
>> > > > > errno_exit ("read");
>> > > > >
>> > > > >
>> > > > > This behavior does not change if the saa6752hs module is not
>> > > > > loaded.
>> > > > >
>> > > > > Is there still a way to modify the i2c address(es) for the
>> > > > > saa6752hs module?
>> > > > >
>> > > > > Any pointers are appreciated.
>> > > > >
>> > > > > Gordon
>> > > >
>> > > > thanks for the report.
>> > > >
>> > > > It was probably forgotten that the prior insmod option had a
>> > > > reason.
>> > > >
>> > > > Try to change it to 0x21 in saa7134-i2c.c
>> > > >
>> > > > static char *i2c_devs[128] = {
>> > > > [ 0x20 ] = "mpeg encoder (saa6752hs)",
>> > > > [ 0xa0 >> 1 ] = "eeprom",
>> > > > [ 0xc0 >> 1 ] = "tuner (analog)",
>> > > > [ 0x86 >> 1 ] = "tda9887",
>> > > > [ 0x5a >> 1 ] = "remote control",
>> > > > };
>> > > >
>> > > > and report if your cards a usable again.
>> > > >
>> > > > Seems we need the chip address per card without that insmod option
>> > > > and reliable probing.
>> > > >
>> > > > Cheers,
>> > > > Hermann
>> > >
>> > > Hermann -
>> > >
>> > > I made the change to saa7134-i2c.c but the i2c address did not
>> > > change. I added my initials (gms) to dmesg,
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jean-Francois. Please pull this tree for 24 gspca-m5602 related changesets that I would like to see included in 2.6.30. I forgot to add the gspca prefix to the summary of the last three patches. If this is an issue, please let me know and I'll back out the changesets and reapply them with the proper header. Best regards, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknJNuQACgkQN7qBt+4UG0GEBwCfdnQ2g2oONIB+kgzF+jKFNcbi j2wAn2qf0cDywY1veywJWjdKEFFBIMqU =xQaC -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW] v4l2 loopback
Hello, please review new version of v4l2 loopback driver.
driver works fine but there are things which I am not shure in.
Is it ok not to count mmaped buffers and just free memory when no open
file descriptors left?
Here is patch against current v4l-dvb tree
-
This patch introduces v4l2 loopback module
From: Vasily Levin
This is v4l2 loopback driver which can be used to make available any userspace
video as v4l2 device. Initialy it was written to make videoeffects available
to Skype, but in fact it have many more uses.
Priority: normal
Signed-off-by: Vasily Levin
diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig
v4l-dvb.my/linux/drivers/media/video/Kconfig
--- v4l-dvb.orig/linux/drivers/media/video/Kconfig 2009-03-21
07:08:06.0 +0200
+++ v4l-dvb.my/linux/drivers/media/video/Kconfig2009-03-24
12:58:38.0 +0200
@@ -465,6 +465,13 @@ config VIDEO_VIVI
Say Y here if you want to test video apps or debug V4L devices.
In doubt, say N.
+config VIDEO_V4L2_LOOPBACK
+ tristate "v4l2 loopback driver"
+ depends on VIDEO_V4L2 && VIDEO_DEV
+ help
+ Say Y if you want to use v4l2 loopback driver.
+ This driver can be compiled as a module, called v4l2loopback.
+
source "drivers/media/video/bt8xx/Kconfig"
config VIDEO_SAA6588
@@ -899,7 +906,7 @@ config USB_S2255
depends on VIDEO_V4L2
select VIDEOBUF_VMALLOC
default n
- help
+ ---help---
Say Y here if you want support for the Sensoray 2255 USB device.
This driver can be compiled as a module, called s2255drv.
diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile
v4l-dvb.my/linux/drivers/media/video/Makefile
--- v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-03-21
07:08:06.0 +0200
+++ v4l-dvb.my/linux/drivers/media/video/Makefile 2009-03-24
12:54:59.0 +0200
@@ -132,6 +132,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
+obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c
v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c
--- v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01
03:00:00.0 +0300
+++ v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-03-24
18:51:41.0 +0200
@@ -0,0 +1,726 @@
+/*
+ * v4l2loopback.c -- video 4 linux loopback driver
+ *
+ * Copyright (C) 2005-2009
+ * Vasily Levin (vas...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include "v4l2loopback.h"
+
+#define DEBUG
+#define DEBUG_RW
+#define YAVLD_STREAMING
+#define KERNEL_PREFIX "YAVLD device: " /* Prefix of each kernel message */
+/* global module data */
+struct v4l2_loopback_device *dev;
+/* forward declarations */
+static void init_buffers(int buffer_size);
+static const struct v4l2_file_operations v4l2_loopback_fops;
+static const struct v4l2_ioctl_ops v4l2_loopback_ioctl_ops;
+/
+ my queue helpers ***
+/
+/* next functions sets buffer flags and adjusts counters accordingly */
+void set_done(struct v4l2_buffer *buffer)
+{
+ buffer->flags |= V4L2_BUF_FLAG_DONE;
+ buffer->flags &= ~V4L2_BUF_FLAG_QUEUED;
+}
+
+void set_queued(struct v4l2_buffer *buffer)
+{
+ buffer->flags |= V4L2_BUF_FLAG_QUEUED;
+ buffer->flags &= ~V4L2_BUF_FLAG_DONE;
+}
+
+void unset_all(struct v4l2_buffer *buffer)
+{
+ buffer->flags &= ~V4L2_BUF_FLAG_QUEUED;
+ buffer->flags &= ~V4L2_BUF_FLAG_DONE;
+}
+/
+ V4L2 ioctl caps and params calls ***
+/
+/**/
+/* returns device capabilities, called on VIDIOC_QUERYCAP ioctl*/
+static int vidioc_querycap(struct file *file,
+ void *priv, struct v4l2_capability *cap)
+{
+ strcpy(cap->driver, "v4l2 loopback");
+ strcpy(cap->card, "Dummy video device");
+ cap->version = 1;
+ cap->capabilities =
+ V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT |
+ V4L2_CAP_READWRITE
+#ifdef YAVLD_STREAMING
+ | V4L2_CAP_STREAMING
+#endif
+ ;
+ return 0;
+}
+
+/*
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: OK
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 Mar 24 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11153:56cf0f1772f7 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: [question] atsc and api v5
Devin Heitmueller wrote:
On Tue, Mar 24, 2009 at 12:35 PM, wk wrote:
While trying to update an application to API v5 some question arised.
Which type of "delivery_system" should be set for ATSC?
says...
SYS_DVBC_ANNEX_AC, <- european DVB-C
SYS_DVBC_ANNEX_B, <- american ATSC QAM
..
SYS_ATSC, <- oops, here we have ATSC again, cable and terrestrial not
named? Is this VSB *only*?
Which one should i choose, "SYS_ATSC" for both (VSB and QAM),
or should i choose SYS_DVBC_ANNEX_B for ATSC cable and SYS_ATSC for VSB?
thanks,
Winfried
I'm pretty sure it's SYS_ATSC for both VSB and QAM.
Devin
Meanwhile i think this is the answer..
dvb-core/dvb_frontend.c line 1076
/* Synchronise the legacy tuning parameters into the cache, so that
demodulator
* drivers can use a single set_frontend tuning function, regardless of
whether
* it's being used for the legacy or new API, reducing code and complexity.
*/
static void dtv_property_cache_sync(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
.
switch (fe->ops.info.type) {
..
case FE_ATSC:
c->modulation = p->u.vsb.modulation;
if ((c->modulation == VSB_8) || (c->modulation == VSB_16))
c->delivery_system = SYS_ATSC;
else
c->delivery_system = SYS_DVBC_ANNEX_B; <- QAM_64
and QAM_256 here
break;
That means the naming is completely misleading here.
I have to choose SYS_DVBC_ANNEX_B for ATSC QAM, but ATSC VSB needs SYS_ATSC.
Winfried
--
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: [question] atsc and api v5
On Tue, Mar 24, 2009 at 12:35 PM, wk wrote: > While trying to update an application to API v5 some question arised. > > Which type of "delivery_system" should be set for ATSC? > says... > > SYS_DVBC_ANNEX_AC, <- european DVB-C > SYS_DVBC_ANNEX_B, <- american ATSC QAM > .. > SYS_ATSC, <- oops, here we have ATSC again, cable and terrestrial not > named? Is this VSB *only*? > > > > Which one should i choose, "SYS_ATSC" for both (VSB and QAM), > or should i choose SYS_DVBC_ANNEX_B for ATSC cable and SYS_ATSC for VSB? > > thanks, > Winfried I'm pretty sure it's SYS_ATSC for both VSB and QAM. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: gspca in the LinuxTv wiki
On Tue, 24 Mar 2009, Thomas Kaiser wrote: Theodore Kilgore wrote: But OTOH this causes a problem, too, because the manufacturers of cameras (probably some of them are not exactly manufacturers but rather packagers) are switching the electronics inside the device any time they feel like it, or if they get a large quantity of chips at a good price, or whatever. I have seen it happen several times that a certain camera keeps the make and model, but it gets a new USB Vendor:Product number. And, worst of all, it may have previously been well supported but now it is not. Someone who goes and buys the camera based upon the make and model which are stencilled on the outside of the camera and printed on the packaging material can end up being stung. Ok, just a example. See http://www.kaiser-linux.li/index.php/Linux_and_Webcams#Typhoon_Easycam_USB_330K At the time I bought this cam it had a sn9c102 bridge and PAS202 and was working great with gspca. Some time later, somebody reported to me that he has the same cam but with a PAC7311. So I just updated my page with the new information. AS of coincident, I was working on the PAC7311 at the time I got this report! So, I see. You have had to face similar problems. Fun, isn't it? Anyway, with a good and nice looking page on the LinuxTV wiki, you can get more interest from some other people and they may sign up and correct the page or ad new information (like this cam has now this chipset). Yes, perhaps this will help. Somehow we all have to figure out a way to keep on top of these things, and the information is always shifting around. The idea of doing things in Wiki style, and letting people sign up and add information, is probably good, too. I mention a couple of other, similar efforts to keep track of various devices, hoping it is possible for some wise person to come up with a way to avoid the problems which are associated with those efforts: Related to the Gphoto project, we have a similar information web page, listing Linux compatibility for still cameras. Unfortunately, it seems that the web page is maintained by one individual, and he is snowed under. He has plenty of other work, too, of course, and he works hard. So it is in no way a criticism of him if I say that the page is always hopelessly out of date, not even managing to keep up with a complete list of the cameras which are already supported in libgphoto2. There is also the list of usb devices at qbik.ch and it is (again very naturally) always out of date, too. It does operate more in the Wiki style, in that everyone can start an account there, sign up and add devices. However, the model they use fails, to the extent that it is not possible to edit what someone else has entered, and it seems not possible to send a mail to someone in charge, who can repair a stale entry. I am thinking of such a thing as an entry which says that device soandso does not work. Then someone (me or you, for instance) succeeds in supporting the device. So, we can go and add the information that now it works, in a comment to the existing entry. But even before anyone looks at those comments, beside the entry is a big red X which indicates that it does not work. And the person who originally filed the report is the only one who can change that big red X, and that person has now disappeared. If by good luck you are the one who created that original entry, then you and only you can remove that big red X. But if it was not originally your entry, you can't even if you know better. So, as I said, I mention these parallel attempts at documentation with the hope that their problems can somehow be avoided. Perhaps it is good to try to do that. Good luck, Theodore Kilgore -- 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
[question] atsc and api v5
While trying to update an application to API v5 some question arised. Which type of "delivery_system" should be set for ATSC? says... SYS_DVBC_ANNEX_AC, <- european DVB-C SYS_DVBC_ANNEX_B, <- american ATSC QAM .. SYS_ATSC, <- oops, here we have ATSC again, cable and terrestrial not named? Is this VSB *only*? Which one should i choose, "SYS_ATSC" for both (VSB and QAM), or should i choose SYS_DVBC_ANNEX_B for ATSC cable and SYS_ATSC for VSB? thanks, Winfried -- 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: [REVIEWv2] bttv v4l2_subdev conversion
Hans,
I don't see any points to comment, other than the ones Trent did. So, I'll add
my comments here.
On Fri, 20 Mar 2009 22:56:18 -0700 (PDT)
Trent Piepho wrote:
> > static unsigned int tuner[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
> > static unsigned int svhs[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
> > static unsigned int remote[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
> > +static unsigned int msp3400[BTTV_MAX];
> > +static unsigned int tda7432[BTTV_MAX];
> > +static unsigned int tvaudio[BTTV_MAX];
> > +static unsigned int saa6588[BTTV_MAX];
>
> Are any of these audio chips mutually exclusive? Does the driver even
> support having more than one of them for the same card? It looks like it
> doesn't. In that case you could replace some/all of these options with a
> "audio chip type" option where 0 is none, 1 is tvaudio, 2 is msp3400, etc.
> I think that's nicer than adding lots of new options and if you can't have
> multiple audio chips, why allow one to specify that?
IMO, a mutually exclusive kind of parameter would be better. If the user wants
to force some audio chip (or even disable it, for some reason), it should
explicitly select one.
I like Trent's idea of using something like :
-1 = no audio
0 = autoprobe
1 = msp3400
2 = tda7432,
...
While I don't see much gain for no-audio, since we are adding such option, I
don't see why not allowing the user to disable the audio chip support.
> How about not adding this? It's unused and I just removed a bunch of
> unused fields from here. Add it when someone can actually make use of it.
>
> > unsigned int tuner_type; /* tuner chip type */
> > unsigned int tda9887_conf;
> > unsigned int svhs, dig;
> > + unsigned int has_saa6588:1;
>
> You're better off not using a bitfield here. Because of padding, it still
> takes 32 bits (or more, depending on the alignment of bttv_pll_info) in the
> struct but takes more code to use.
IMO, it is better to keep it as bitfield since later other bitfields could be
added. Also, as Hans pointed, this indicates that this is a on/off ("boolean")
type, but I'm ok if you decide to use another type.
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
[PATCH v2] v4l2-subdev: THS7303 video amplifier driver
TI THS7303 video amplifier driver code
This patch adds driver for TI THS7303 video amplifier. This driver is
implemented as a v4l2 sub device. Tested on TI DM646x EVM.
This patch applies on top of the ADV7343 driver patch submitted prior to
this. The dependency is due to the modification of the
'Kconfig', 'Makefiile', 'v4l2-chip-ident.h' files by both the patches.
This updated version of the patch has incorporated the review comments.
Signed-off-by: Chaithrika U S
---
drivers/media/video/Kconfig |9 +++
drivers/media/video/Makefile|1 +
drivers/media/video/ths7303.c | 151 +++
include/media/v4l2-chip-ident.h |3 +
4 files changed, 164 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ths7303.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 49ff639..9747e4d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -435,6 +435,15 @@ config VIDEO_ADV7343
To compile this driver as a module, choose M here: the
module will be called adv7343.
+config VIDEO_THS7303
+ tristate "THS7303 Video Amplifier"
+ depends on I2C
+ help
+ Support for TI THS7303 video amplifier
+
+ To compile this driver as a module, choose M here: the
+ module will be called ths7303.
+
comment "Video improvement chips"
config VIDEO_UPD64031A
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index eaa5a49..4dc10de 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_VIDEO_BT819) += bt819.o
obj-$(CONFIG_VIDEO_BT856) += bt856.o
obj-$(CONFIG_VIDEO_BT866) += bt866.o
obj-$(CONFIG_VIDEO_KS0127) += ks0127.o
+obj-$(CONFIG_VIDEO_THS7303) += ths7303.o
obj-$(CONFIG_VIDEO_ZORAN) += zoran/
diff --git a/drivers/media/video/ths7303.c b/drivers/media/video/ths7303.c
new file mode 100644
index 000..682831b
--- /dev/null
+++ b/drivers/media/video/ths7303.c
@@ -0,0 +1,151 @@
+/*
+ * ths7303- THS7303 Video Amplifier driver
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("TI THS7303 video amplifier driver");
+MODULE_AUTHOR("Chaithrika U S");
+MODULE_LICENSE("GPL");
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level 0-1");
+
+/* following function is used to set ths7303 */
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std & V4L2_STD_NTSC) || (std & V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, "setting value for SDTV format\n");
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, "disabling all channels\n");
+ }
+
+ err |= i2c_smbus_write_byte_data(client, 0x01, val);
+ err |= i2c_smbus_write_byte_data(client, 0x02, val);
+ err |= i2c_smbus_write_byte_data(client, 0x03, val);
+
+ if (err)
+ v4l2_err(sd, "write failed\n");
+
+ return err;
+}
+
+static int ths7303_s_std_output(struct v4l2_subdev *sd, v4l2_std_id norm)
+{
+ return ths7303_setvalue(sd, norm);
+}
+
+static int ths7303_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_THS7303, 0);
+}
+
+static const struct v4l2_subdev_video_ops ths7303_video_ops = {
+ .s_std_output = ths7303_s_std_output,
+};
+
+static const struct v4l2_subdev_core_ops ths7303_core_ops = {
+ .g_chip_ident = ths7303_g_chip_ident,
+};
+
+static const struct v4l2_subdev_ops ths7303_ops = {
+ .core = &ths7303_core_ops,
+ .video = &ths7303_video_ops,
+};
+
+static int ths7303_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct v4l2_subdev *sd;
+ v4l2_std_id std_id = V4L2_STD_NTSC;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -ENODEV;
+
+ v4l_info(client, "chip found @ 0x%x (%s)\n",
+ client->addr << 1, client->adapter->name);
+
+ s
[PATCH v2] v4l2-subdev: ADV7343 video encoder driver
Analog Devices ADV7343 video encoder driver
Add ADV7343 I2C based video encoder driver. This follows the v4l2-subdev
framework.This driver has been tested on TI DM646x EVM. It has been tested for
Composite and Component outputs.
Review comments have been incorporated in this patch. The most important
updates are
- removal of structures adv7343_config, adv7343_channel
- simplification of the adv7343_std_info structure
- removal of the ch_id state variable, it was not needed
- using the state variables output and stdid effectively instead of
adv7343_channel
Note: There is no mention of SECAM support in the encoder datasheet.
Signed-off-by: Chaithrika U S
---
drivers/media/video/Kconfig|9 +
drivers/media/video/Makefile |1 +
drivers/media/video/adv7343.c | 545
drivers/media/video/adv7343_regs.h | 188 +
include/media/adv7343.h| 23 ++
include/media/v4l2-chip-ident.h|3 +
6 files changed, 769 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/adv7343.c
create mode 100644 drivers/media/video/adv7343_regs.h
create mode 100644 include/media/adv7343.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 114bf04..49ff639 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -426,6 +426,15 @@ config VIDEO_ADV7175
To compile this driver as a module, choose M here: the
module will be called adv7175.
+config VIDEO_ADV7343
+tristate "ADV7343 video encoder"
+depends on I2C
+help
+ Support for Analog Devices I2C bus based ADV7343 encoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7343.
+
comment "Video improvement chips"
config VIDEO_UPD64031A
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 08765d8..eaa5a49 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
+obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
obj-$(CONFIG_VIDEO_BT856) += bt856.o
diff --git a/drivers/media/video/adv7343.c b/drivers/media/video/adv7343.c
new file mode 100644
index 000..f392328
--- /dev/null
+++ b/drivers/media/video/adv7343.c
@@ -0,0 +1,545 @@
+/*
+ * adv7343 - ADV7343 Video Encoder Driver
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "adv7343_regs.h"
+
+MODULE_DESCRIPTION("ADV7343 video encoder driver");
+MODULE_LICENSE("GPL");
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level 0-1");
+
+struct adv7343_state {
+ struct v4l2_subdev sd;
+ u8 reg00;
+ u8 reg01;
+ u8 reg02;
+ u8 reg35;
+ u8 reg80;
+ u8 reg82;
+ int bright;
+ int hue;
+ int gain;
+ u32 output;
+ v4l2_std_id std;
+};
+
+static inline struct adv7343_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7343_state, sd);
+}
+
+static inline int adv7343_write(struct v4l2_subdev *sd, u8 reg, u8 value)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+static const u8 adv7343_init_reg_val[] = {
+ ADV7343_SOFT_RESET, ADV7343_SOFT_RESET_DEFAULT,
+ ADV7343_POWER_MODE_REG, ADV7343_POWER_MODE_REG_DEFAULT,
+
+ ADV7343_HD_MODE_REG1, ADV7343_HD_MODE_REG1_DEFAULT,
+ ADV7343_HD_MODE_REG2, ADV7343_HD_MODE_REG2_DEFAULT,
+ ADV7343_HD_MODE_REG3, ADV7343_HD_MODE_REG3_DEFAULT,
+ ADV7343_HD_MODE_REG4, ADV7343_HD_MODE_REG4_DEFAULT,
+ ADV7343_HD_MODE_REG5, ADV7343_HD_MODE_REG5_DEFAULT,
+ ADV7343_HD_MODE_REG6, ADV7343_HD_MODE_REG6_DEFAULT,
+ ADV7343_HD_MODE_REG7, ADV7343_HD_MODE_REG7_DEFAULT,
+
+ ADV7343_SD_MODE_REG1, ADV7343_SD_MODE_REG1_DEFAULT,
+ ADV7343_SD_MODE_REG2, ADV7343_SD_MODE_REG2_DEFAULT,
+ ADV7343_SD_MODE_REG3, ADV7343_SD_MODE_REG3_DEFAULT,
+ ADV7343_SD_MODE_REG4, ADV7343_SD_MODE_REG4_DEFAULT,
+ ADV7343
Re: [REVIEWv2] bttv v4l2_subdev conversion
On Tue, 24 Mar 2009, Hans Verkuil wrote:
> On Tuesday 24 March 2009 01:38:04 Trent Piepho wrote:
> > On Sat, 21 Mar 2009, Hans Verkuil wrote:
> > > On Saturday 21 March 2009 06:56:18 Trent Piepho wrote:
> > > > It seems like one could still disable loading modules for that bttv
> > > > might think it needs. When you're testing modules that have not been
> > > > installed, any calls to request_module() will load the wrong version
> > > > and cause all sorts of breakage. It should still be possible to
> > > > disable any attempts by the driver to do that.
> > >
> > > The idea is to either let the driver use the card definition info and
> > > probing to detect the audio chip, or to tell it which one to load
> > > explicitly. That's sufficient in my opinion.
> >
> > I still think it should be possible to prevent the driver from calling
> > request_module(). If you're trying to test drivers then a call to
> > request_module can cause a kernel oops.
>
> You mean you want to be able to load the driver without loading any audio
> module? Or do you mean something else? It must be me, but I still don't
Without loading a module that has not already been loaded.
> understand what scenario you are trying to prevent. Note that just calling
> request_module() doesn't do anything but load the module in memory. Without
> autoprobing it will never attach to a i2c adapter.
It loads the module that is located in /lib/modules/`uname -r` into memory.
If you are testing modules are are NOT installed there, then it loads the
*wrong* module. It can cause an opps if say a v4l core struct has changed
sizes between the module installed in /lib and the modules that have been
loaded with insmod.
> > > No. If you add a new card definition and that card has a saa6588,
> > > then this bit should be available for you. Otherwise I just know
> > > that people will just skip that chip ('Hey! I can't set it! Oh,
> > > I'll skip it then...') instead of asking for adding saa6588 support.
> > >
> > > The only reason it's not used is that the one board that can have it
> > > has to test for it dynamically as it is an add-on.
> >
> > Do you really think anyone is going to add a new card defition to bttv
> > that has a saa6588? All these years and there is only one obscure card
> > that has a saa6588 as an add on. No one even makes bttv cards with
> > tuners anymore. The only bttv cards we've seen added in a long time
> > are multi-chip cards with no tuners.
>
> I wasn't thinking so much of new devices as existing devices that never
> recorded the presence of a saa6588. We use 17 bits of the 32 available
> in the bitfield. This will be the 18th. I see absolutely no problem
> with that.
You're not counting the two u8 values. They share the same bits as the
bitfield. I can shink the card database again if just two bits can be
removed. The 'onemore' field is entirely unused, probably added years ago
for some future use that never appeared, so that can be deleted. The audio
chip fields aren't taking into account that the same card can't have
multiple audio chips so it should be possible to save another bit there.
Adding unused fields just makes it harder to clean up this stuff later.
How hard is cleaning up this cruft? Well, my patches that cleaned up
bttv's card database were complex enough to use 1316 words to describe
them. Compare that to every single patch you've commited from Jan 1st to
Mar 12th of this year, which total 1351 words.
> > > > > unsigned int tuner_type; /* tuner chip type */ unsigned int
> > > > > tda9887_conf; unsigned int svhs, dig; + unsigned int
> > > > > has_saa6588:1;
> > > >
> > > > You're better off not using a bitfield here. Because of padding,
> > > > it still takes 32 bits (or more, depending on the alignment of
> > > > bttv_pll_info) in the struct but takes more code to use.
> > >
> > > Mauro wants a bitfield, he gets a bitfield. I'm not going
> > > back-and-forth on this. Personally I don't care one way or the
> > > other.
> >
> > So Mauro, why a bit field? It doesn't save any space here.
>
> Because this clearly shows that it is a on-off value and not an integer
> that can have other values as well.
"bool"
Though it's obvious from the name anyway..
--
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: Results of the 'dropping support for kernels <2.6.22' poll
> On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote: >> > When this thread was started, it was about dropping support for >> > kernels < 2.6.22. However, it has turned into a thread about moving >> > to git and dropping support for *all* kernels less than the bleeding >> > edge -rc candidate (only supporting them through a backport system for >> > testers). The two are very different things. > > Yes they are very different things. I do not like a poll about dropping > the current build system being disguised as a poll about dropping support > for very old kernels. How about a new poll, "should developers be > required > to have multiple systems and spend the majority of their time recompiling > new kernels and testing nvidia and wireless drivers?" The poll was just about dropping support for old kernels. Nothing more, nothing less. There were a few who commented that they wouldn't mind dropping all compatibility, but those were very much a minority. I for one want to keep the compatibility code in one way or another so we can support the last X kernels and make life easy for ourselves and for our users. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Bug in mxl5005s driver
El Martes, 24 de Marzo de 2009, Andy Walls escribió:
> On Sun, 2009-03-22 at 22:31 +0100, Jose Alberto Reguero wrote:
> > In line 3992:
> >
> > if (fe->ops.info.type == FE_ATSC) {
> > switch (params->u.vsb.modulation) {
> > case VSB_8:
> > req_mode = MXL_ATSC; break;
> > default:
> > case QAM_64:
> > case QAM_256:
> > case QAM_AUTO:
> > req_mode = MXL_QAM; break;
> > }
> > } else
> > req_mode = MXL_DVBT;
> >
> > req_mode is filled with MXL_ATSC, MXL_QAM, or MXL_DVBT
> >
> > and in line 4007 req_mode is used like params->u.vsb.modulation
> >
> > switch (req_mode) {
> > case VSB_8:
> > case QAM_64:
> > case QAM_256:
> > case QAM_AUTO:
> > req_bw = MXL5005S_BANDWIDTH_6MHZ;
> > break;
> > default:
> > /* Assume DVB-T */
> > switch (params->u.ofdm.bandwidth) {
> > case BANDWIDTH_6_MHZ:
> > req_bw = MXL5005S_BANDWIDTH_6MHZ;
> > break;
> > case BANDWIDTH_7_MHZ:
> > req_bw = MXL5005S_BANDWIDTH_7MHZ;
> > break;
> > case BANDWIDTH_AUTO:
> > case BANDWIDTH_8_MHZ:
> >
> >
> > Jose Alberto Reguero
>
> Easy enough. Please try the patch here:
>
> http://linuxtv.org/hg/~awalls/v4l-dvb
>
>
>
> Sorry I forgot to add a
>
> Reported-by: Jose Alberto Reguero
>
> in the commit. I can fix that if things work out.
>
>
> Regards,
> Andy
>
Work well with DVB-T.
Thanks.
Jose Alberto
--
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: Results of the 'dropping support for kernels <2.6.22' poll
On Sat, 21 Mar 2009, Mauro Carvalho Chehab wrote: > > When this thread was started, it was about dropping support for > > kernels < 2.6.22. However, it has turned into a thread about moving > > to git and dropping support for *all* kernels less than the bleeding > > edge -rc candidate (only supporting them through a backport system for > > testers). The two are very different things. Yes they are very different things. I do not like a poll about dropping the current build system being disguised as a poll about dropping support for very old kernels. How about a new poll, "should developers be required to have multiple systems and spend the majority of their time recompiling new kernels and testing nvidia and wireless drivers?" > It is important to discuss a new model, since the current one has some flaws, > like: These are problems caused by having a large project with multiple areas of maintainership and many developers working simulaniously. Switching to a full kernel tree and dropping cross kernel building support isn't going to a help. > - bug fixes are sometimes postponed, since they depend on the bleeding edge > patches; Full kernel source will just make this worse! Your v4l patch needs some very recent change to pci core? With a full tree, the v4l-dvb maintainer will have to wait until the pci maintainer accepts the patch and puts it into his tree. Then the v4l-dvb maintainer will have to pull the pci tree. That won't just give you the one patch you need, but 100 other patches in the tree. Then and only then can any v4l-dvb devlopers work on their patch that needs the pci fix. With the current system a v4l-dvb devloper can pick just the pci patch he needs and put it into his kernel or he can get the pci tree. Then he's free to develop a v4l-dvb patch that needs the pci patch. He can probably even do his v4l-dvb patch in a compatible manner, so that it can go in the v4l-dvb tree before the pci patch has even appeared in the pci tree. > - our model is different from the rest of Linux kernel community; Their model is worse. Why make things worse just to help people who choose not to learn new things? > - it is hard to merge patches that needs coordination with changes outside > drivers/media; It's hard to merge patches that touch multiple areas of maintainership even if everyone uses full trees. > - the need of conversion for each -hg patch into -git; It's done by an automated script. It allows fixing the large number of mistakes commited to the v4l-dvb tree. > - the need of backport upstream changes at the building system, and keeping > track of such changes. You will still have patches that touch drivers/media that don't go in via the v4l-dvb tree. Just look at any system with a full tree, you'll see commits that touch that system's files and went in as some system wide cleanup patch via another maintainer's tree. So you'll still have to merge these patches. > - the increased volume of patches on v4l/dvb made our development model > incredible complex for submitting work upstream, since it doesn't scale well, > and has caused some hard to solve merge conflicts. More patches means more merge conflicts. Why does have an out of tree build system have anything to do with it? > You can even use a spare git clone, where, for example, only drivers/media > will > be cloned on your local machine. Which is useless. You can't build or run drivers/media only kernel tree! -- 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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
> On Tuesday 24 March 2009 08:06:39 Hans Verkuil wrote:
>> On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
>> > Hello, all
>> >
>> > After last convertion of radio drivers to use v4l2_device we have such
>> > code in many radio drivers:
>> > (it's radio-terratec.c for example)
>> >
>> > ...
>> > static int terratec_open(struct file *file)
>> > {
>> > return 0;
>> > }
>> >
>> > static int terratec_release(struct file *file)
>> > {
>> > return 0;
>> > }
>> > ...
>> >
>> > and
>> >
>> > ...
>> > static int vidioc_g_input(struct file *filp, void *priv, unsigned int
>> > *i)
>> > {
>> > *i = 0;
>> > return 0;
>> > }
>> >
>> > static int vidioc_s_input(struct file *filp, void *priv, unsigned int
>> i)
>> > {
>> > return i ? -EINVAL : 0;
>> > }
>> > ...
>> >
>> > Such code used in many radio-drivers as i understand.
>> >
>> > Is it good to place this empty and almost empty functions in:
>> > (here i see two variants)
>> >
>> > 1) In header file that be in linux/drivers/media/radio/ directory.
>> > Later, we can move some generic/or repeating code in this header.
>> >
>> > 2) In any v4l header. What header may contain this ?
>> >
>> > ?
>> >
>> > For what ? Well, as i understand we can decrease amount of lines and
>> > provide this simple generic functions. It's like
>> > video_device_release_empty function behaviour. Maybe not only radio
>> > drivers can use such vidioc_g_input and vidioc_s_input.
>> >
>> > Is it worth ?
>>
>> I don't think it is worth doing this for g/s_input. I think it is useful
>> to
>> have them here: it makes it very clear that there is just a single input
>> and the overhead in both lines and actual bytes is minimal.
>
> What about making that the default NULL g_input/s_input callbacks handling
> in
> video_ioctl2 ? Devices with a single input wouldn't need to define
> g_input/s_input callbacks at all.
If you leave s/g_input NULL then you have a device without an input at
all. That's perfectly valid for output-only devices.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
On Tuesday 24 March 2009 08:06:39 Hans Verkuil wrote:
> On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
> > Hello, all
> >
> > After last convertion of radio drivers to use v4l2_device we have such
> > code in many radio drivers:
> > (it's radio-terratec.c for example)
> >
> > ...
> > static int terratec_open(struct file *file)
> > {
> > return 0;
> > }
> >
> > static int terratec_release(struct file *file)
> > {
> > return 0;
> > }
> > ...
> >
> > and
> >
> > ...
> > static int vidioc_g_input(struct file *filp, void *priv, unsigned int
> > *i)
> > {
> > *i = 0;
> > return 0;
> > }
> >
> > static int vidioc_s_input(struct file *filp, void *priv, unsigned int i)
> > {
> > return i ? -EINVAL : 0;
> > }
> > ...
> >
> > Such code used in many radio-drivers as i understand.
> >
> > Is it good to place this empty and almost empty functions in:
> > (here i see two variants)
> >
> > 1) In header file that be in linux/drivers/media/radio/ directory.
> > Later, we can move some generic/or repeating code in this header.
> >
> > 2) In any v4l header. What header may contain this ?
> >
> > ?
> >
> > For what ? Well, as i understand we can decrease amount of lines and
> > provide this simple generic functions. It's like
> > video_device_release_empty function behaviour. Maybe not only radio
> > drivers can use such vidioc_g_input and vidioc_s_input.
> >
> > Is it worth ?
>
> I don't think it is worth doing this for g/s_input. I think it is useful to
> have them here: it makes it very clear that there is just a single input
> and the overhead in both lines and actual bytes is minimal.
What about making that the default NULL g_input/s_input callbacks handling in
video_ioctl2 ? Devices with a single input wouldn't need to define
g_input/s_input callbacks at all.
> But for the empty open and release functions you could easily handle that
> in v4l2-dev.c: if you leave the open and release callbacks to NULL, then
> v4l2_open and v4l2_release can just return 0. That would be nice.
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ov772x: add edge contrl support
On Tue, 24 Mar 2009, Kuninori Morimoto wrote:
> Signed-off-by: Kuninori Morimoto
> ---
> v2 -> v3
> o use edgectrl.strength for judge
>
> Sorry for my miss-understanding.
> This patch use edgectrl.strength for judgement.
> And the explain in the comment has all.
> My datasheet doesn't have details more than this explain.
>
> drivers/media/video/ov772x.c | 25 +
> include/media/ov772x.h | 21 +
> 2 files changed, 46 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
> index 34c9819..3226c43 100644
> --- a/drivers/media/video/ov772x.c
> +++ b/drivers/media/video/ov772x.c
> @@ -816,6 +816,31 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> u32 width, u32 height,
> ov772x_reset(priv->client);
>
> /*
> + * set Edge Ctrl
> + */
> + if (priv->info->edgectrl.strength) {
> + ret = ov772x_mask_set(priv->client, EDGE0, 0x1F,
> + priv->info->edgectrl.strength);
> + if (ret < 0)
> + goto ov772x_set_fmt_error;
Whatever this "edge" does, isn't it so, that "threshold," "upper," and
"lower" parameters configure it and "strength" actually enforces the
changes? Say, if strength == 0, edge control is off, and as soon as you
switch it to != 0, it is on with all the configured parameters? If my
guess is right, wouldn't it make sense to first configure parameters and
then set strength? If you agree, I'll just swap them when committing, so,
you don't have to resend. Just please either confirm that you agree, or
explain why I am wrong.
> +
> + ret = ov772x_mask_set(priv->client, EDGE1, 0x0F,
> + priv->info->edgectrl.threshold);
> + if (ret < 0)
> + goto ov772x_set_fmt_error;
> +
> + ret = ov772x_mask_set(priv->client, EDGE2, 0xFF,
> + priv->info->edgectrl.upper);
> + if (ret < 0)
> + goto ov772x_set_fmt_error;
> +
> + ret = ov772x_mask_set(priv->client, EDGE3, 0xFF,
> + priv->info->edgectrl.lower);
> + if (ret < 0)
> + goto ov772x_set_fmt_error;
> + }
> +
> + /*
>* set size format
>*/
> ret = ov772x_write_array(priv->client, priv->win->regs);
> diff --git a/include/media/ov772x.h b/include/media/ov772x.h
> index 57db48d..cfdd80e 100644
> --- a/include/media/ov772x.h
> +++ b/include/media/ov772x.h
> @@ -17,10 +17,31 @@
> #define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
> #define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
>
> +/*
> + * for Edge ctrl
> + */
> +struct ov772x_edge_ctrl {
> + unsigned char strength; /* strength control */
> + unsigned char threshold; /* threshold detection */
> + unsigned char upper; /* strength upper limit */
> + unsigned char lower; /* strength lower limit */
> +};
> +
> +#define OV772X_EDGECTRL(s, t, u, l) \
> + {.strength = (s & 0x1F),\
> + .threshold = (t & 0x0F),\
> + .upper = (u & 0xFF),\
> + .lower = (l & 0xFF),\
> + }
If you don't mind, I'll reformat this slightly to
+#define OV772X_EDGECTRL(s, t, u, l)\
+{ \
+ .strength = (s & 0x1F), \
+ .threshold = (t & 0x0F), \
+ .upper = (u & 0xFF), \
+ .lower = (l & 0xFF), \
+}
when applying, ok?
> +
> +/*
> + * ov772x camera info
> + */
> struct ov772x_camera_info {
> unsigned long buswidth;
> unsigned long flags;
> struct soc_camera_link link;
> + struct ov772x_edge_ctrl edgectrl;
> };
>
> #endif /* __OV772X_H__ */
> --
> 1.5.6.3
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ov772x: add edge contrl support
Signed-off-by: Kuninori Morimoto
---
v2 -> v3
o use edgectrl.strength for judge
Sorry for my miss-understanding.
This patch use edgectrl.strength for judgement.
And the explain in the comment has all.
My datasheet doesn't have details more than this explain.
drivers/media/video/ov772x.c | 25 +
include/media/ov772x.h | 21 +
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 34c9819..3226c43 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -816,6 +816,31 @@ static int ov772x_set_params(struct ov772x_priv *priv, u32
width, u32 height,
ov772x_reset(priv->client);
/*
+* set Edge Ctrl
+*/
+ if (priv->info->edgectrl.strength) {
+ ret = ov772x_mask_set(priv->client, EDGE0, 0x1F,
+ priv->info->edgectrl.strength);
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv->client, EDGE1, 0x0F,
+ priv->info->edgectrl.threshold);
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv->client, EDGE2, 0xFF,
+ priv->info->edgectrl.upper);
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv->client, EDGE3, 0xFF,
+ priv->info->edgectrl.lower);
+ if (ret < 0)
+ goto ov772x_set_fmt_error;
+ }
+
+ /*
* set size format
*/
ret = ov772x_write_array(priv->client, priv->win->regs);
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 57db48d..cfdd80e 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -17,10 +17,31 @@
#define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
#define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
+/*
+ * for Edge ctrl
+ */
+struct ov772x_edge_ctrl {
+ unsigned char strength; /* strength control */
+ unsigned char threshold; /* threshold detection */
+ unsigned char upper; /* strength upper limit */
+ unsigned char lower; /* strength lower limit */
+};
+
+#define OV772X_EDGECTRL(s, t, u, l) \
+ {.strength = (s & 0x1F),\
+.threshold = (t & 0x0F),\
+.upper = (u & 0xFF),\
+.lower = (l & 0xFF),\
+ }
+
+/*
+ * ov772x camera info
+ */
struct ov772x_camera_info {
unsigned long buswidth;
unsigned long flags;
struct soc_camera_link link;
+ struct ov772x_edge_ctrl edgectrl;
};
#endif /* __OV772X_H__ */
--
1.5.6.3
--
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: [cron job] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: OK
Hmm, everything is OK. Let's enjoy this moment of perfection! It probably won't last long :-) Regards, Hans > 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 Mar 24 08:33:25 CET 2009 > path:http://www.linuxtv.org/hg/v4l-dvb > changeset: 11153:56cf0f1772f7 > gcc version: gcc (GCC) 4.3.1 > hardware:x86_64 > host os: 2.6.26 > > linux-2.6.22.19-armv5: OK > linux-2.6.23.12-armv5: OK > linux-2.6.24.7-armv5: OK > linux-2.6.25.11-armv5: OK > linux-2.6.26-armv5: OK > linux-2.6.27-armv5: OK > linux-2.6.28-armv5: OK > linux-2.6.29-armv5: OK > linux-2.6.27-armv5-ixp: OK > linux-2.6.28-armv5-ixp: OK > linux-2.6.29-armv5-ixp: OK > linux-2.6.28-armv5-omap2: OK > linux-2.6.29-armv5-omap2: OK > linux-2.6.22.19-i686: OK > linux-2.6.23.12-i686: OK > linux-2.6.24.7-i686: OK > linux-2.6.25.11-i686: OK > linux-2.6.26-i686: OK > linux-2.6.27-i686: OK > linux-2.6.28-i686: OK > linux-2.6.29-i686: OK > linux-2.6.23.12-m32r: OK > linux-2.6.24.7-m32r: OK > linux-2.6.25.11-m32r: OK > linux-2.6.26-m32r: OK > linux-2.6.27-m32r: OK > linux-2.6.28-m32r: OK > linux-2.6.29-m32r: OK > linux-2.6.22.19-mips: OK > linux-2.6.26-mips: OK > linux-2.6.27-mips: OK > linux-2.6.28-mips: OK > linux-2.6.29-mips: OK > linux-2.6.27-powerpc64: OK > linux-2.6.28-powerpc64: OK > linux-2.6.29-powerpc64: OK > linux-2.6.22.19-x86_64: OK > linux-2.6.23.12-x86_64: OK > linux-2.6.24.7-x86_64: OK > linux-2.6.25.11-x86_64: OK > linux-2.6.26-x86_64: OK > linux-2.6.27-x86_64: OK > linux-2.6.28-x86_64: OK > linux-2.6.29-x86_64: OK > fw/apps: OK > sparse (linux-2.6.29): ERRORS > linux-2.6.16.61-i686: OK > linux-2.6.17.14-i686: OK > linux-2.6.18.8-i686: OK > linux-2.6.19.5-i686: OK > linux-2.6.20.21-i686: OK > linux-2.6.21.7-i686: OK > linux-2.6.16.61-x86_64: OK > linux-2.6.17.14-x86_64: OK > linux-2.6.18.8-x86_64: OK > linux-2.6.19.5-x86_64: OK > linux-2.6.20.21-x86_64: OK > linux-2.6.21.7-x86_64: OK > > 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 V4L2 specification from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/v4l2.html > > The DVB API specification from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf > > -- > 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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: OK
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 Mar 24 08:33:25 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11153:56cf0f1772f7 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Another OV7670 Soc-camera driver
Hi All,
seems everybody has their own OV7670 driver... I have one written from scratch
too.
It is written using Omnivision user manual, application note, and register
reference settings.
Omnivision provides settings arrays for every resolution (VGA, QVGA, QQVGA,
CIF, QCIF).
This driver has lot of harcoded magic numbers. Of course OV7670 has lot of
undocumented mystery and strange bugs.
Maybe my work could be useful merging all available OV7670 drivers into single
one.
This driver is tested with MXLADS v2.0 board.
So there it is:
---
From: Darius Augulis
Soc camera driver for OV7670 sensor from OMNIVISION.
Signed-off-by: Darius Augulis
Index: linux-2.6.29-rc5/drivers/media/video/Kconfig
===
--- linux-2.6.29-rc5.orig/drivers/media/video/Kconfig
+++ linux-2.6.29-rc5/drivers/media/video/Kconfig
@@ -779,6 +779,13 @@ config SOC_CAMERA_OV772X
help
This is a ov772x camera driver
+config SOC_CAMERA_OV7670
+ tristate "ov7670 support"
+ depends on SOC_CAMERA && I2C
+ help
+ This is a driver for OmniVision OV7670 VGA camera.
+ It currently only works with SoC Camera interface.
+
config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && PXA27x && SOC_CAMERA
Index: linux-2.6.29-rc5/drivers/media/video/Makefile
===
--- linux-2.6.29-rc5.orig/drivers/media/video/Makefile
+++ linux-2.6.29-rc5/drivers/media/video/Makefile
@@ -104,7 +104,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
-obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
@@ -144,6 +144,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111)+= mt9m
obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o
obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o
obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
+obj-$(CONFIG_SOC_CAMERA_OV7670)+= ov7670_soc.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
Index: linux-2.6.29-rc5/drivers/media/video/ov7670_soc.c
===
--- /dev/null
+++ linux-2.6.29-rc5/drivers/media/video/ov7670_soc.c
@@ -0,0 +1,1411 @@
+/*
+ * Driver for OV7670 CMOS Image Sensor from OmniVision
+ *
+ * Copyright (C) 2008, Darius Augulis
+ *
+ * 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.
+ */
+
+/* Remove comment to compile in debug messages */
+//#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* OV7670 has slave I2C address 0x42 */
+#define OV7670_I2C_ADDR 0x42
+
+/* OV7670 registers */
+#defineOV7670_PID 0x0A/* 76 R
*/
+#defineOV7670_VER 0x0B/* 73 R
*/
+#defineOV7670_COM7 0x12/* 0 RW
*/
+#defineOV7670_COM100x15/* 0 RW
*/
+#defineOV7670_MIDH 0x1C/* 7F R
*/
+#defineOV7670_MIDL 0x1D/* A2 R
*/
+#defineOV7670_MVFP 0x1E/* 1 RW
*/
+#defineOV7670_BRIGHT 0x55/* 0 RW
*/
+#defineOV7670_CONTRAS 0x56/* 40 RW
*/
+
+static const struct soc_camera_data_format ov7670_formats[] = {
+ {
+ .name = "YUV 4:2:2",
+ .depth = 16,
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ }
+};
+
+struct ov7670 {
+ struct i2c_client *client;
+ struct soc_camera_device icd;
+ int model;
+};
+
+/* Camera sensor register access functions */
+static u8 reg_read(struct i2c_client *client, const u8 reg)
+{
+ u8 i2c_buf[2];
+ i2c_buf[0] = reg;
+ i2c_master_send(client, i2c_buf, 1);
+ i2c_master_recv(client, i2c_buf, 1);
+ return i2c_buf[0];
+}
+
+static u8 reg_write(struct i2c_client *client, const u8 reg, u8 data)
+{
+ u8 i2c_buf[2];
+ i2c_buf[0] = reg;
+ i2c_buf[1] = data;
+ return i2c_master_send(client, i2c_buf, 2);
+}
+
+/* YCbCr, VGA
* 15fps @ 24MHz input clock
+ */
+u8 init_array_vga[][2] = {
+ { 0x11, 0x03 },
+ { 0x3a, 0x04 },
+ { 0x12, 0x00 },
+ { 0x17, 0x13 },
+ { 0x18, 0x01 },
+ { 0x32, 0xb6 },
+ { 0x19, 0x02 },
+ { 0x1a, 0x7a },
+ { 0x03, 0x0a },
+
[RFC] Another OV7670 Soc-camera driver
Hi All,
seems everybody has their own OV7670 driver... I have one written from scratch
too.
It is written using Omnivision user manual, application note, and register
reference settings.
Omnivision provides settings arrays for every resolution (VGA, QVGA, QQVGA,
CIF, QCIF).
This driver has lot of harcoded magic numbers. Of course OV7670 has lot of
undocumented mystery and strange bugs.
Maybe my work could be useful merging all available OV7670 drivers into single
one.
This driver is tested with MXLADS v2.0 board.
So there it is:
---
From: Darius Augulis
Soc camera driver for OV7670 sensor from OMNIVISION.
Signed-off-by: Darius Augulis
Index: linux-2.6.29-rc5/drivers/media/video/Kconfig
===
--- linux-2.6.29-rc5.orig/drivers/media/video/Kconfig
+++ linux-2.6.29-rc5/drivers/media/video/Kconfig
@@ -779,6 +779,13 @@ config SOC_CAMERA_OV772X
help
This is a ov772x camera driver
+config SOC_CAMERA_OV7670
+ tristate "ov7670 support"
+ depends on SOC_CAMERA && I2C
+ help
+ This is a driver for OmniVision OV7670 VGA camera.
+ It currently only works with SoC Camera interface.
+
config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && PXA27x && SOC_CAMERA
Index: linux-2.6.29-rc5/drivers/media/video/Makefile
===
--- linux-2.6.29-rc5.orig/drivers/media/video/Makefile
+++ linux-2.6.29-rc5/drivers/media/video/Makefile
@@ -104,7 +104,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
-obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
@@ -144,6 +144,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M111)+= mt9m
obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o
obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o
obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
+obj-$(CONFIG_SOC_CAMERA_OV7670)+= ov7670_soc.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
Index: linux-2.6.29-rc5/drivers/media/video/ov7670_soc.c
===
--- /dev/null
+++ linux-2.6.29-rc5/drivers/media/video/ov7670_soc.c
@@ -0,0 +1,1411 @@
+/*
+ * Driver for OV7670 CMOS Image Sensor from OmniVision
+ *
+ * Copyright (C) 2008, Darius Augulis
+ *
+ * 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.
+ */
+
+/* Remove comment to compile in debug messages */
+//#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* OV7670 has slave I2C address 0x42 */
+#define OV7670_I2C_ADDR 0x42
+
+/* OV7670 registers */
+#defineOV7670_PID 0x0A/* 76 R
*/
+#defineOV7670_VER 0x0B/* 73 R
*/
+#defineOV7670_COM7 0x12/* 0 RW
*/
+#defineOV7670_COM100x15/* 0 RW
*/
+#defineOV7670_MIDH 0x1C/* 7F R
*/
+#defineOV7670_MIDL 0x1D/* A2 R
*/
+#defineOV7670_MVFP 0x1E/* 1 RW
*/
+#defineOV7670_BRIGHT 0x55/* 0 RW
*/
+#defineOV7670_CONTRAS 0x56/* 40 RW
*/
+
+static const struct soc_camera_data_format ov7670_formats[] = {
+ {
+ .name = "YUV 4:2:2",
+ .depth = 16,
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ }
+};
+
+struct ov7670 {
+ struct i2c_client *client;
+ struct soc_camera_device icd;
+ int model;
+};
+
+/* Camera sensor register access functions */
+static u8 reg_read(struct i2c_client *client, const u8 reg)
+{
+ u8 i2c_buf[2];
+ i2c_buf[0] = reg;
+ i2c_master_send(client, i2c_buf, 1);
+ i2c_master_recv(client, i2c_buf, 1);
+ return i2c_buf[0];
+}
+
+static u8 reg_write(struct i2c_client *client, const u8 reg, u8 data)
+{
+ u8 i2c_buf[2];
+ i2c_buf[0] = reg;
+ i2c_buf[1] = data;
+ return i2c_master_send(client, i2c_buf, 2);
+}
+
+/* YCbCr, VGA
* 15fps @ 24MHz input clock
+ */
+u8 init_array_vga[][2] = {
+ { 0x11, 0x03 },
+ { 0x3a, 0x04 },
+ { 0x12, 0x00 },
+ { 0x17, 0x13 },
+ { 0x18, 0x01 },
+ { 0x32, 0xb6 },
+ { 0x19, 0x02 },
+ { 0x1a, 0x7a },
+ { 0x03, 0x0a },
Re: [REVIEWv2] bttv v4l2_subdev conversion
On Tuesday 24 March 2009 01:38:04 Trent Piepho wrote:
> On Sat, 21 Mar 2009, Hans Verkuil wrote:
> > On Saturday 21 March 2009 06:56:18 Trent Piepho wrote:
> > > It seems like one could still disable loading modules for that bttv
> > > might think it needs. When you're testing modules that have not been
> > > installed, any calls to request_module() will load the wrong version
> > > and cause all sorts of breakage. It should still be possible to
> > > disable any attempts by the driver to do that.
> >
> > The idea is to either let the driver use the card definition info and
> > probing to detect the audio chip, or to tell it which one to load
> > explicitly. That's sufficient in my opinion.
>
> I still think it should be possible to prevent the driver from calling
> request_module(). If you're trying to test drivers then a call to
> request_module can cause a kernel oops.
You mean you want to be able to load the driver without loading any audio
module? Or do you mean something else? It must be me, but I still don't
understand what scenario you are trying to prevent. Note that just calling
request_module() doesn't do anything but load the module in memory. Without
autoprobing it will never attach to a i2c adapter.
> > I'll remove it. I'll probably put it back in a future patch when I'll
> > start working on RDS. Currently you can read from a radio device in
> > bttv and it will allow that even when there is no rds on board. I
> > intended to use this pointer later in the radio fops to test whether
> > reading is allowed.
>
> Don't you have a has_saa6588 field in the bttv core struct that would
> allow the same thing?
Yeah, that would work as well: if I can't attach the saa6588 module, then I
can set that field to 0 and check that field elsewhere.
> > > > --- a/linux/drivers/media/video/bt8xx/bttv.hThu Mar 19 20:53:32
> > > > 2009 +0100 +++ b/linux/drivers/media/video/bt8xx/bttv.h Thu Mar 19
> > > > 21:15:53 2009 +0100 @@ -242,6 +242,7 @@
> > > > unsigned int msp34xx_alt:1;
> > > >
> > > > unsigned int no_video:1; /* video pci function is unused */
> > > > + unsigned int has_saa6588:1;
> > >
> > > How about not adding this? It's unused and I just removed a bunch of
> > > unused fields from here. Add it when someone can actually make use
> > > of it.
> >
> > No. If you add a new card definition and that card has a saa6588, then
> > this bit should be available for you. Otherwise I just know that people
> > will just skip that chip ('Hey! I can't set it! Oh, I'll skip it
> > then...') instead of asking for adding saa6588 support.
> >
> > The only reason it's not used is that the one board that can have it
> > has to test for it dynamically as it is an add-on.
>
> Do you really think anyone is going to add a new card defition to bttv
> that has a saa6588? All these years and there is only one obscure card
> that has a saa6588 as an add on. No one even makes bttv cards with
> tuners anymore. The only bttv cards we've seen added in a long time are
> multi-chip cards with no tuners.
I wasn't thinking so much of new devices as existing devices that never
recorded the presence of a saa6588. We use 17 bits of the 32 available in
the bitfield. This will be the 18th. I see absolutely no problem with that.
> > Looking at it I should add a comment, though.
> >
> > > > unsigned int tuner_type; /* tuner chip type */
> > > > unsigned int tda9887_conf;
> > > > unsigned int svhs, dig;
> > > > + unsigned int has_saa6588:1;
> > >
> > > You're better off not using a bitfield here. Because of padding, it
> > > still takes 32 bits (or more, depending on the alignment of
> > > bttv_pll_info) in the struct but takes more code to use.
> >
> > Mauro wants a bitfield, he gets a bitfield. I'm not going
> > back-and-forth on this. Personally I don't care one way or the other.
>
> So Mauro, why a bit field? It doesn't save any space here.
Because this clearly shows that it is a on-off value and not an integer that
can have other values as well.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: gspca in the LinuxTv wiki
Theodore Kilgore wrote: But OTOH this causes a problem, too, because the manufacturers of cameras (probably some of them are not exactly manufacturers but rather packagers) are switching the electronics inside the device any time they feel like it, or if they get a large quantity of chips at a good price, or whatever. I have seen it happen several times that a certain camera keeps the make and model, but it gets a new USB Vendor:Product number. And, worst of all, it may have previously been well supported but now it is not. Someone who goes and buys the camera based upon the make and model which are stencilled on the outside of the camera and printed on the packaging material can end up being stung. Ok, just a example. See http://www.kaiser-linux.li/index.php/Linux_and_Webcams#Typhoon_Easycam_USB_330K At the time I bought this cam it had a sn9c102 bridge and PAS202 and was working great with gspca. Some time later, somebody reported to me that he has the same cam but with a PAC7311. So I just updated my page with the new information. AS of coincident, I was working on the PAC7311 at the time I got this report! Anyway, with a good and nice looking page on the LinuxTV wiki, you can get more interest from some other people and they may sign up and correct the page or ad new information (like this cam has now this chipset). 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: [question] about open/release and vidioc_g_input/vidioc_s_input functions
On Tuesday 24 March 2009 00:14:07 Alexey Klimov wrote:
> Hello, all
>
> After last convertion of radio drivers to use v4l2_device we have such
> code in many radio drivers:
> (it's radio-terratec.c for example)
>
> ...
> static int terratec_open(struct file *file)
> {
> return 0;
> }
>
> static int terratec_release(struct file *file)
> {
> return 0;
> }
> ...
>
> and
>
> ...
> static int vidioc_g_input(struct file *filp, void *priv, unsigned int
> *i)
> {
> *i = 0;
> return 0;
> }
>
> static int vidioc_s_input(struct file *filp, void *priv, unsigned int i)
> {
> return i ? -EINVAL : 0;
> }
> ...
>
> Such code used in many radio-drivers as i understand.
>
> Is it good to place this empty and almost empty functions in:
> (here i see two variants)
>
> 1) In header file that be in linux/drivers/media/radio/ directory.
> Later, we can move some generic/or repeating code in this header.
>
> 2) In any v4l header. What header may contain this ?
>
> ?
>
> For what ? Well, as i understand we can decrease amount of lines and
> provide this simple generic functions. It's like
> video_device_release_empty function behaviour. Maybe not only radio
> drivers can use such vidioc_g_input and vidioc_s_input.
>
> Is it worth ?
I don't think it is worth doing this for g/s_input. I think it is useful to
have them here: it makes it very clear that there is just a single input
and the overhead in both lines and actual bytes is minimal.
But for the empty open and release functions you could easily handle that in
v4l2-dev.c: if you leave the open and release callbacks to NULL, then
v4l2_open and v4l2_release can just return 0. That would be nice.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
