Re: identifying camera sensor
On Wednesday 04 March 2009 16:52:20 ext Hans Verkuil wrote: Alternatively, VIDIOC_QUERYCAP could be used to identify the sensor. Would it make more sense if it would return something like capability.card: `omap3/smia-sensor-12-1234-5678//' where 12 would be manufacturer_id, 1234 model_id, and 5678 revision_number? Yuck :-) Agreed :) Also, if there are many slaves, the length of the capability.card field is not sufficient. From: Trent Piepho xy...@speakeasy.org You could always try to decode the manufacturer name and maybe even the model name. After all, pretty much every other driver does this. That would be possible, but the driver would then need a device name table which would need to be modified whenever a new chip comes up :( On Wednesday 04 March 2009 16:52:20 ext Hans Verkuil wrote: G_CHIP_IDENT is probably the way to go, provided you are aware of the limitations of this ioctl. Should this be a problem, then we need to think of a better solution. Could you tell me what limitations? I thought about that ioctl initially, but then read that it is going to be removed, that's why abandoned it. The limitation is that it's API might change from one kernel version to another. It's not going to be removed. http://n2.nabble.com/-REVIEW--v4l2-debugging:-match-drivers-by-name-instead-of-the-deprecated-ID-td1681635.html That's the API change :-) This change is already in 2.6.29. But if you say it's a good way, then I'll go that way. The intention is to get the SMIA driver included into official kernel, so I'd prefer a method which allows that :-) Using DBG_G_CHIP_IDENT is the quick way of doing things, but it is by definition an API that might change in the future (although I hope that doesn't happen anytime soon). If you want something stable, then we need to come up with an alternative. ENUMINPUT is probably a better solution: you can say something like Camera 1 (sensor1), Camera 2 (sensor2). It remains a bit of a hack, though. The problem is that DBG_G_CHIP_IDENT is really the only ioctl that can do what you want, but it is meant for internal use only. Perhaps this calls for an ENUM_CHIPS ioctl that calls G_CHIP_IDENT internally. 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: identifying camera sensor
On Thu, 5 Mar 2009, Tuukka.O Toivonen wrote: On Wednesday 04 March 2009 16:52:20 ext Hans Verkuil wrote: Alternatively, VIDIOC_QUERYCAP could be used to identify the sensor. Would it make more sense if it would return something like capability.card: `omap3/smia-sensor-12-1234-5678//' where 12 would be manufacturer_id, 1234 model_id, and 5678 revision_number? Yuck :-) Agreed :) Also, if there are many slaves, the length of the capability.card field is not sufficient. From: Trent Piepho xy...@speakeasy.org You could always try to decode the manufacturer name and maybe even the model name. After all, pretty much every other driver does this. That would be possible, but the driver would then need a device name table which would need to be modified whenever a new chip comes up :( Pretty much every single driver does this, so it's apparently not that hard. Another thing to consider, is that if the sensor has certain properties that you want to know in user space, maybe the driver could provide those properties drectly, instead of providing the sensor id and letting user space app figure the properties from the id. -- 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: identifying camera sensor
On Thu, 5 Mar 2009, Hans Verkuil wrote: ENUMINPUT is probably a better solution: you can say something like Camera 1 (sensor1), Camera 2 (sensor2). It remains a bit of a hack, though. Maybe use some of the reserved bits in v4l2_input to show not only the sensor orientation, but also manufacturer, model, and revision? I wonder if there are enough bits for that? How does this discussion go? I point out that using reserved bits is not sustainable, does not allow enumeration of supplied properties, and provides no meta-data for the self-documentation of those properties. The control interface provides all these things. Then you point out that these aren't controls and say end of discussion. Though if one had considered allowing the control api to be used to provide sensor properties, then the solution to this problem would now be quite simple and obvious. -- 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] cx88: Prevent general protection fault on rmmod
On Thu, 5 Mar 2009, Jean Delvare wrote: +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20) struct work_struct work; struct timer_list timer; +#else + struct delayed_work work; +#endif You don't need this compat stuff. compat.h will take are of it for you. Just code it like you would for the latest kernel. The only thing you need to worry about is the way the third argument of the work function went away, but the ifdef that's already there takes care of it. -- 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
[PULL] http://linuxtv.org/hg/~tap/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~tap/v4l-dvb for the following 2 changesets: 01/02: compat: Add INIT_DELAYED_WORK http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=f6382daee1df 02/02: zoran: Change first argument to zoran_v4l2_buffer_status http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=784ecbdb42a5 linux/drivers/media/video/zoran/zoran_driver.c |9 - v4l/compat.h |1 + 2 files changed, 5 insertions(+), 5 deletions(-) Thanks, Trent -- 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: [linux-dvb] ERROR: Module dvb_usb_aaa_dvbusb_demo is in use
Hi,
On Thu, 5 Mar 2009, wdy9927 wrote:
I had make install a module for a dvb usb box which writen by my self. But this
one didn't have real frontend ops and tuner ops.These functions did
nothing but return 0.
Like this
static int demo_fe_init(struct dvb_frontend *fe)
{
return 0;
}
After the usb box removed from linux, the DVB system called demo_fe_release and
demo_tu_release, sofar that seems very good? But, I can't rmmod this
module normally. It showed ERROR: Module dvb_usb_dvbusb_demo is in use.This error
is diffrent with ERROR: Module dvb_usb is in use by
dvb_usb_dvbusb_demo
How can i rmmod this module with out reboot Linux.
This is a known problem with every dvb-device-driver (especially the ones
using dvb-usb) which are implementing the frontend-part not as an
independent kernel module. When the frontend-driver is released the
dvb-core is doing something like use-count-decrement on the module. As the
use-count was never incremented (dvb_attach cannot be used on function
which are not exported with EXPORT_SYMBOL) the count is now -1, which is
same as 0x.
rmmod is refusing to unload a module which has a use_count != 0. This is
the problem you're facing.
You could still try to use rmmod -f to force to unload. Or you make your
frontend-driver a seperate kernel module.
Patrick.
Re: [PATCH 1/9] omap3isp: Add ISP main driver and register definitions
Thanks for the comments, Alexey!
Alexey Klimov wrote:
+static int isp_probe(struct platform_device *pdev)
+{
+ struct isp_device *isp;
+ int ret_err = 0;
+ int i;
+
+ isp = kzalloc(sizeof(*isp), GFP_KERNEL);
+ if (!isp) {
+ dev_err(pdev-dev, could not allocate memory\n);
+ return -ENODEV;
return -ENOMEM; ?
Done.
+ }
+
+ platform_set_drvdata(pdev, isp);
+
+ isp-dev = pdev-dev;
+
+ for (i = 0; i = OMAP3_ISP_IOMEM_CSI2PHY; i++) {
+ struct resource *mem;
+ /* request the mem region for the camera registers */
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!mem) {
+ dev_err(isp-dev, no mem resource?\n);
+ return -ENODEV;
Maybe ENODEV is not apropriate here too..
What else it could be? ENOENT comes to mind but I'm not sure it's
significantly better.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and RDS
Hi Hans I build fresh video4linux with your patch and my config for our cards. In a dmesg i see : found RDS decoder. cat /dev/radio0 give me some slow junk data. Is this RDS data?? Have you any tools for testing RDS? I try build rdsd from Hans J. Koch, but build crashed with: rdshandler.cpp: In member function ‘void std::RDShandler::delete_client(std::RDSclient*)’: rdshandler.cpp:363: error: no matching function for call to ‘find(__gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , __gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , std::RDSclient*)’ P.S. Debian Lenny. With my best regards, Dmitry. On Wednesday 04 March 2009 13:02:46 Dmitri Belimov wrote: Dmitri, I have a patch pending to fix this for the saa7134 driver. The i2c problems are resolved, so this shouldn't be a problem anymore. Good news! The one thing that is holding this back is that I first want to finalize the RFC regarding the RDS support. I posted an RFC a few weeks ago, but I need to make a second version and for that I need to do a bit of research into the US version of RDS. And I haven't found the time to do that yet. Yes, I found your discussion in linux-media mailing list. If you need any information from chip vendor I'll try find. I can get it under NDA and help you. I'll see if I can get the patch merged anyway. I've attached my patch for the saa7134. I want to wait with the final pull request until I've finished the RDS RFC, but this gives you something to play with. 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: saa7134 and RDS
Hi Hans I build fresh video4linux with your patch and my config for our cards. In a dmesg i see : found RDS decoder. cat /dev/radio0 give me some slow junk data. Is this RDS data?? Have you any tools for testing RDS? I try build rdsd from Hans J. Koch, but build crashed with: rdshandler.cpp: In member function âvoid std::RDShandler::delete_client(std::RDSclient*)â: rdshandler.cpp:363: error: no matching function for call to âfind(__gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , __gnu_cxx::__normal_iteratorstd::RDSclient**, std::vectorstd::RDSclient*, std::allocatorstd::RDSclient* , std::RDSclient*)â Ah yes, that's right. I had to hack the C++ source to make this compile. I'll see if I can post a patch for this tonight. Hans P.S. Debian Lenny. With my best regards, Dmitry. On Wednesday 04 March 2009 13:02:46 Dmitri Belimov wrote: Dmitri, I have a patch pending to fix this for the saa7134 driver. The i2c problems are resolved, so this shouldn't be a problem anymore. Good news! The one thing that is holding this back is that I first want to finalize the RFC regarding the RDS support. I posted an RFC a few weeks ago, but I need to make a second version and for that I need to do a bit of research into the US version of RDS. And I haven't found the time to do that yet. Yes, I found your discussion in linux-media mailing list. If you need any information from chip vendor I'll try find. I can get it under NDA and help you. I'll see if I can get the patch merged anyway. I've attached my patch for the saa7134. I want to wait with the final pull request until I've finished the RDS RFC, but this gives you something to play with. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: RFC on proposed patches to mr97310a.c for gspca and v4l
Hello Theodore kilg...@banach.math.auburn.edu wrote: On Wed, 4 Mar 2009, Thomas Kaiser wrote: As to the actual contents of the header, as you describe things, 0. Do you have any idea how to account for the discrepancy between From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 and In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 (I am referring to the 00 00 as opposed to F0 00)? Or could this have happened somehow just because these were not two identical sessions? Doesn't remember what the differences was. The first is from Windoz (usbsnoop) and the second is from Linux. 1. xx: don't know but value is changing between 0x00 to 0x07 as I said, this signifies the image format, qua compression algorithm in use, or if 00 then no compression. On the PAC207, the compression can be controlled with a register called Compression Balance size. So, I guess, depending on the value set in the register this value in the header will show what compression level is set. 2. xx: this is the actual pixel clock So there is a control setting for this? Yes, in the PAC207, register 2. (12 MHz divided by the value set). 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Does anyone have any idea of how actually to use this information/ for example, since a lot of cameras are reporting some kind of similar looking information, does anyone know if there are any kinds of standard scales for these entries? Just what are they supposed to signify, and how exactly is one supposed to use such values, if they have been presented? When I say a lot of cameras, understand, I mean still cameras as well as webcams, and cameras with a lot of different chipsets in them, too. So this is a question whether there is any standard system for the presentation of such data, and how it might constructively be used in image processing. I have had questions about this kind of thing for a long time, and I do not know where to look for the answers. For the brightness, I guess, 0 means dark and 0xff completely bright (sensor is in saturation)? Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx88: Prevent general protection fault on rmmod
On Thu, 5 Mar 2009 01:43:55 -0800 (PST), Trent Piepho wrote: On Thu, 5 Mar 2009, Jean Delvare wrote: +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20) struct work_struct work; struct timer_list timer; +#else + struct delayed_work work; +#endif You don't need this compat stuff. compat.h will take are of it for you. Just code it like you would for the latest kernel. The only thing you need to worry about is the way the third argument of the work function went away, but the ifdef that's already there takes care of it. OK, thanks. I'll resend updated patches soon. -- Jean Delvare -- 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 9/9] omap34xxcam: Add camera driver
Alexey Klimov wrote:
+static int vidioc_g_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ f-fmt.pix = vdev-pix;
+ mutex_unlock(vdev-mutex);
H, you are using mutex_lock to lock reading from vdev structure..
Well, i don't if this is right approach. I am used to that mutex_lock is
used to prevent _changing_ of members in structure..
The vdev-mutex is acquired since we want to prevent concurrent access
to vdev-pix. Otherwise it might change while we are reading it, right?
+static int vidioc_s_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+ struct v4l2_pix_format pix_tmp;
+ struct v4l2_fract timeperframe;
+ int rval;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ if (vdev-streaming) {
+ rval = -EBUSY;
+ goto out;
+ }
Well, why don't remove goto, place return -EBUSY, and move mutex after
if (vdev-streaming) check ?
The streaming state may change in the meantime. See vidioc_streamon.
It's not very likely but possible as far as I understand.
+static int vidioc_reqbufs(struct file *file, void *fh,
+ struct v4l2_requestbuffers *b)
+{
+ struct omap34xxcam_fh *ofh = fh;
+ struct omap34xxcam_videodev *vdev = ofh-vdev;
+ int rval;
+
+ if (vdev-vdev_sensor == v4l2_int_device_dummy())
+ return -EINVAL;
+
+ mutex_lock(vdev-mutex);
+ if (vdev-streaming) {
+ mutex_unlock(vdev-mutex);
+ return -EBUSY;
+ }
If i'm doing this i prefer to place mutex_lock after this
if(vdev-streaming) check.
Same here.
+static int omap34xxcam_device_register(struct v4l2_int_device *s)
+{
+ struct omap34xxcam_videodev *vdev = s-u.slave-master-priv;
+ struct omap34xxcam_hw_config hwc;
+ int rval;
+
+ /* We need to check rval just once. The place is here. */
I didn't understand this comment. You doing nothin in next few lines
with int variable rval(which introduced in this function). Is comment
talking about struct v4l2_int_device *s ?
Yes. If the g_priv() succeeds now it will succeed in future, too. This
comes from the platform data through the slave device.
+ /* Are we the first slave? */
+ if (vdev-slaves == 1) {
+ /* initialize the video_device struct */
+ vdev-vfd = video_device_alloc();
+ if (!vdev-vfd) {
+ dev_err(vdev-vfd-dev,
+ could not allocate video device struct\n);
Do i understand you code in right way ?
You call video_device_alloc() to get vdev-vfd. Then if vdev-vfd is
null(empty) you make message dev_err which based on vdev-vfd-dev but
dev-vfd allocating is failed.. If i'm not wrong you message will
provide kernel oops.
One more point here is that you use dev_err(vdev-vfd-dev before call
to video_device_alloc() in this function.
Indeed. Others hit this already. Thanks.
+static int __init omap34xxcam_init(void)
+{
+ struct omap34xxcam_device *cam;
+ int i;
+
+ cam = kzalloc(sizeof(*cam), GFP_KERNEL);
+ if (!cam) {
+ printk(KERN_ERR %s: could not allocate memory\n, __func__);
+ goto err;
If kzalloc failed you return -ENODEV; but this is ENOMEM error.
Yes. Will fix.
Thanks again for the comments.
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Embedded Linux Conference
Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. 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
Symbol rate limit for TT 3200
Hi all, I have been struggling for quite a while to lock on a DVB-S2 transponder. And recently I got some information that they changed the symbol rate to 45MS/s which looks borderline to me. Can someone confirm that the TT 3200 can do that? I also attach a log that I obtained when trying to lock on this transponder with the following parameters: QPSK, FEC= 5/6, 45MS/s The driver I used was Igor's (very recent) one with szap-s2. The status oscillates between 00 and 0b, it can take long to attain 0b which suggests long and unreliable lock (never got VITERBI, just demod lock +sync). Thx for any help Bye Emmanuel -- 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
Symbol rate limit for TT 3200
I know I know I forgot to attach the log ;-) Here you go... Bye Emmanuel TP-45000-SR-FEC-56-Lock-SYNC-but-No-VITERBI.txt.bz2 Description: application/bzip
[PATCH] firedtv: fix printk format mismatch
Eliminate
drivers/media/dvb/firewire/firedtv-avc.c: In function 'debug_fcp':
drivers/media/dvb/firewire/firedtv-avc.c:156: warning: format '%d' expects type
'int', but argument 5 has type 'size_t'
Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de
---
Mauro, if you don't mind I queue it up in linux1394-2.6.git for after
2.6.29, before 2.6.30-rc1. There may be firewire subsystem related
changes of firedtv coming together until then.
drivers/media/dvb/firewire/firedtv-avc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/media/dvb/firewire/firedtv-avc.c
===
--- linux.orig/drivers/media/dvb/firewire/firedtv-avc.c
+++ linux/drivers/media/dvb/firewire/firedtv-avc.c
@@ -115,7 +115,7 @@ static const char *debug_fcp_ctype(unsig
}
static const char *debug_fcp_opcode(unsigned int opcode,
- const u8 *data, size_t length)
+ const u8 *data, int length)
{
switch (opcode) {
case AVC_OPCODE_VENDOR: break;
@@ -141,7 +141,7 @@ static const char *debug_fcp_opcode(unsi
return Vendor;
}
-static void debug_fcp(const u8 *data, size_t length)
+static void debug_fcp(const u8 *data, int length)
{
unsigned int subunit_type, subunit_id, op;
const char *prefix = data[0] 7 ? FCP - : FCP - ;
--
Stefan Richter
-=-==--= --== --=-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thu, 5 Mar 2009, Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: On Wed, 4 Mar 2009, Thomas Kaiser wrote: As to the actual contents of the header, as you describe things, 0. Do you have any idea how to account for the discrepancy between From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 and In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 (I am referring to the 00 00 as opposed to F0 00)? Or could this have happened somehow just because these were not two identical sessions? Doesn't remember what the differences was. The first is from Windoz (usbsnoop) and the second is from Linux. 1. xx: don't know but value is changing between 0x00 to 0x07 as I said, this signifies the image format, qua compression algorithm in use, or if 00 then no compression. On the PAC207, the compression can be controlled with a register called Compression Balance size. So, I guess, depending on the value set in the register this value in the header will show what compression level is set. 2. xx: this is the actual pixel clock So there is a control setting for this? Yes, in the PAC207, register 2. (12 MHz divided by the value set). 3. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (center) 4. xx: this is changing according light conditions from 0x03 (dark) to 0xfc (bright) (edge) 5. xx: set value Digital Gain of Red 6. xx: set value Digital Gain of Green 7. xx: set value Digital Gain of Blue Does anyone have any idea of how actually to use this information/ for example, since a lot of cameras are reporting some kind of similar looking information, does anyone know if there are any kinds of standard scales for these entries? Just what are they supposed to signify, and how exactly is one supposed to use such values, if they have been presented? When I say a lot of cameras, understand, I mean still cameras as well as webcams, and cameras with a lot of different chipsets in them, too. So this is a question whether there is any standard system for the presentation of such data, and how it might constructively be used in image processing. I have had questions about this kind of thing for a long time, and I do not know where to look for the answers. For the brightness, I guess, 0 means dark and 0xff completely bright (sensor is in saturation)? That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or it could be that only the digits 0 through 9 are actually used, and the basis is then 100, or too many other variations to count. Also what is considered a normal or an average value? The trouble with your suggestion of a scale from 0 to 0xff is that it makes sense, and in a situation like this one obviously can not assume that. What I am suspecting is that these things have some kind of standard definitions, which are not necessarily done by logic but by convention, and there is a document out there somewhere which lays it all down. The document could have been produced by Microsoft, for example, which doubtless has its own problems reducing chaos to order in the industry, or by some kind of consortium of camera manufacturers, or something like that. I really do strongly suspect that the interpretation of all of this is written down somewhere. But I don't know where to look. 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
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote: Beside the fact that we don't need to strip support for legacy kernels, the advantage of using this method is that we can evolute to a new development model. As several developers already required, we should really use the standard -git tree as everybody's else. This will simplify a lot the way we work, and give us more agility to send patches upstream. With this backport script, plus the current v4l-dvb building systems, and after having all backport rules properly mapped, we can generate a test tree based on -git drivers/media, for the users to test the drivers against their kernels, and still use a clean tree for development. Sorry, switching to git is great, but just to make sure I understood you right: by -git drivers/media you don't mean it is going to be a git tree of only drivers/media, but it is going to be a normal complete Linux kernel tree, right? 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
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Thu Mar 5 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10833:ef0aaa237fa4 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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-rc7-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-armv5-omap2: OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS 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-rc7-i686: WARNINGS 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-rc7-m32r: OK linux-2.6.16.61-mips: ERRORS linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc7-powerpc64: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc7-x86_64: WARNINGS fw/apps: WARNINGS spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] pxa_camera: Redesign DMA handling
This patchset, formerly known as pxa_camera: Redesign DMA handling, attempts so simplify the code for all DMA related parts of pxa_camera host driver. As asked for by Guennadi and Mike, the original patch was split up into 4 patches : - one to address the YUV planar format hole (page alignment) - one to redesign the DMA - one for code style change - one for lately discovered overrun issue A decision about enforcing a size for pxa_camera_set_fmt() to be a multiple of 8 was not done yet. Meanwhile, the patchset doesn't make any hypothesis about the image size, and even a weird size like 223 x 111 will work. If such a decision was to be taken, patch 1 would have to amended. Powermanagment with suspend to RAM, then resume in the middle of a capture does work. As Mike noticed, YUV planar format overlay was not tested after these changes. Robert Jarzmik (4): pxa_camera: remove YUV planar formats hole pxa_camera: Redesign DMA handling pxa_camera: Coding style sweeping pxa_camera: Fix overrun condition on last buffer drivers/media/video/pxa_camera.c | 474 ++ 1 files changed, 277 insertions(+), 197 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] pxa_camera: Remove YUV planar formats hole
All planes were PAGE aligned (ie. 4096 bytes aligned). This
is not consistent with YUV422 format, which requires Y, U
and V planes glued together. The new implementation forces
the alignement on 8 bytes (DMA requirement), which is almost
always the case (granted by width x height being a multiple
of 8).
The test cases include tests in both YUV422 and RGB565 :
- a picture of size 111 x 111 (cross RAM pages example)
- a picture of size 1023 x 4 in (under 1 RAM page)
- a picture of size 1024 x 4 in (exactly 1 RAM page)
- a picture of size 1025 x 4 in (over 1 RAM page)
- a picture of size 1280 x 1024 (many RAM pages)
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/media/video/pxa_camera.c | 165 ++
1 files changed, 114 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index e3e6b29..54df071 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -242,14 +242,13 @@ static int pxa_videobuf_setup(struct videobuf_queue *vq,
unsigned int *count,
dev_dbg(icd-dev, count=%d, size=%d\n, *count, *size);
/* planar capture requires Y, U and V buffers to be page aligned */
- if (pcdev-channels == 3) {
- *size = PAGE_ALIGN(icd-width * icd-height); /* Y pages */
- *size += PAGE_ALIGN(icd-width * icd-height / 2); /* U pages */
- *size += PAGE_ALIGN(icd-width * icd-height / 2); /* V pages */
- } else {
- *size = icd-width * icd-height *
- ((icd-current_fmt-depth + 7) 3);
- }
+ if (pcdev-channels == 3)
+ *size = roundup(icd-width * icd-height, 8) /* Y pages */
+ + roundup(icd-width * icd-height / 2, 8) /* U pages */
+ + roundup(icd-width * icd-height / 2, 8); /* V pages
*/
+ else
+ *size = roundup(icd-width * icd-height *
+ ((icd-current_fmt-depth + 7) 3), 8);
if (0 == *count)
*count = 32;
@@ -289,19 +288,63 @@ static void free_buffer(struct videobuf_queue *vq, struct
pxa_buffer *buf)
buf-vb.state = VIDEOBUF_NEEDS_INIT;
}
+static int calculate_dma_sglen(struct scatterlist *sglist, int sglen,
+ int sg_first_ofs, int size)
+{
+ int i, offset, dma_len, xfer_len;
+ struct scatterlist *sg;
+
+ offset = sg_first_ofs;
+ for_each_sg(sglist, sg, sglen, i) {
+ dma_len = sg_dma_len(sg);
+
+ /* PXA27x Developer's Manual 27.4.4.1: round up to 8 bytes */
+ xfer_len = roundup(min(dma_len - offset, size), 8);
+
+ size = max(0, size - xfer_len);
+ offset = 0;
+ if (size == 0)
+ break;
+ }
+
+ BUG_ON(size != 0);
+ return i + 1;
+}
+
+/**
+ * pxa_init_dma_channel - init dma descriptors
+ * @pcdev: pxa camera device
+ * @buf: pxa buffer to find pxa dma channel
+ * @dma: dma video buffer
+ * @channel: dma channel (0 = 'Y', 1 = 'U', 2 = 'V')
+ * @cibr: camera read fifo
+ * @size: bytes to transfer
+ * @sg_first: index of first element of sg_list
+ * @sg_first_ofs: offset in first element of sg_list
+ *
+ * Prepares the pxa dma descriptors to transfer one camera channel.
+ * Beware sg_first and sg_first_ofs are both input and output parameters.
+ *
+ * Returns 0
+ */
static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
struct pxa_buffer *buf,
struct videobuf_dmabuf *dma, int channel,
- int sglen, int sg_start, int cibr,
- unsigned int size)
+ int cibr, int size,
+ struct scatterlist **sg_first, int
*sg_first_ofs)
{
struct pxa_cam_dma *pxa_dma = buf-dmas[channel];
- int i;
+ struct scatterlist *sg;
+ int i, offset, sglen;
+ int dma_len = 0, xfer_len = 0;
if (pxa_dma-sg_cpu)
dma_free_coherent(pcdev-dev, pxa_dma-sg_size,
pxa_dma-sg_cpu, pxa_dma-sg_dma);
+ sglen = calculate_dma_sglen(*sg_first, dma-sglen,
+ *sg_first_ofs, size);
+
pxa_dma-sg_size = (sglen + 1) * sizeof(struct pxa_dma_desc);
pxa_dma-sg_cpu = dma_alloc_coherent(pcdev-dev, pxa_dma-sg_size,
pxa_dma-sg_dma, GFP_KERNEL);
@@ -309,27 +352,51 @@ static int pxa_init_dma_channel(struct pxa_camera_dev
*pcdev,
return -ENOMEM;
pxa_dma-sglen = sglen;
+ offset = *sg_first_ofs;
- for (i = 0; i sglen; i++) {
- int sg_i = sg_start + i;
- struct scatterlist *sg = dma-sglist;
- unsigned int dma_len = sg_dma_len(sg[sg_i]), xfer_len;
+
[PATCH 2/4] pxa_camera: Redesign DMA handling
The DMA transfers in pxa_camera showed some weaknesses in
multiple queued buffers context :
- poll/select problem
The order between list pcdev-capture and DMA chain was
not the same. This creates a discrepancy between video
buffers marked as done by the IRQ handler, and the
really finished video buffer.
The bug shows up with capture_example tool from v4l2 hg
tree. The process just stalls on a select timeout.
The key problem is in pxa_videobuf_queue(), where the
queued buffer is chained before the active buffer, while
it should have been the active buffer first, and queued
buffer tailed after.
- multiple buffers DMA starting
When multiple buffers were queued, the DMA channels were
always started right away. This is not optimal, as a
special case appears when the first EOF was not yet
reached, and the DMA channels were prematurely started.
- Maintainability
DMA code was a bit obfuscated. Rationalize the code to be
easily maintainable by anyone.
This patch attemps to address these issues.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/media/video/pxa_camera.c | 264 --
1 files changed, 139 insertions(+), 125 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 54df071..2d79ded 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -325,7 +325,7 @@ static int calculate_dma_sglen(struct scatterlist *sglist,
int sglen,
* Prepares the pxa dma descriptors to transfer one camera channel.
* Beware sg_first and sg_first_ofs are both input and output parameters.
*
- * Returns 0
+ * Returns 0 or -ENOMEM si no coherent memory is available
*/
static int pxa_init_dma_channel(struct pxa_camera_dev *pcdev,
struct pxa_buffer *buf,
@@ -369,7 +369,8 @@ static int pxa_init_dma_channel(struct pxa_camera_dev
*pcdev,
pxa_dma-sg_cpu[i].dsadr = pcdev-res-start + cibr;
pxa_dma-sg_cpu[i].dtadr = sg_dma_address(sg) + offset;
pxa_dma-sg_cpu[i].dcmd =
- DCMD_FLOWSRC | DCMD_BURST8 | DCMD_INCTRGADDR | xfer_len;
+ DCMD_FLOWSRC | DCMD_BURST8 | DCMD_INCTRGADDR | xfer_len
+ | ((i == 0) ? DCMD_STARTIRQEN : 0);
pxa_dma-sg_cpu[i].ddadr =
pxa_dma-sg_dma + (i + 1) * sizeof(struct pxa_dma_desc);
@@ -516,6 +517,97 @@ out:
return ret;
}
+/**
+ * pxa_dma_start_channels - start DMA channel for active buffer
+ * @pcdev: pxa camera device
+ *
+ * Initialize DMA channels to the beginning of the active video buffer, and
+ * start these channels.
+ */
+static void pxa_dma_start_channels(struct pxa_camera_dev *pcdev)
+{
+ int i;
+ struct pxa_buffer *active;
+
+ active = pcdev-active;
+
+ for (i = 0; i pcdev-channels; i++) {
+ dev_dbg(pcdev-dev, %s (channel=%d) ddadr=%08x\n, __func__,
+ i, active-dmas[i].sg_dma);
+ DDADR(pcdev-dma_chans[i]) = active-dmas[i].sg_dma;
+ DCSR(pcdev-dma_chans[i]) = DCSR_RUN;
+ }
+}
+
+static void pxa_dma_stop_channels(struct pxa_camera_dev *pcdev)
+{
+ int i;
+
+ for (i = 0; i pcdev-channels; i++) {
+ dev_dbg(pcdev-dev, %s (channel=%d)\n, __func__, i);
+ DCSR(pcdev-dma_chans[i]) = 0;
+ }
+}
+
+static void pxa_dma_update_sg_tail(struct pxa_camera_dev *pcdev,
+ struct pxa_buffer *buf)
+{
+ int i;
+
+ for (i = 0; i pcdev-channels; i++) {
+ pcdev-sg_tail[i] = buf-dmas[i].sg_cpu + buf-dmas[i].sglen;
+ pcdev-sg_tail[i]-ddadr = DDADR_STOP;
+ }
+}
+
+static void pxa_dma_add_tail_buf(struct pxa_camera_dev *pcdev,
+struct pxa_buffer *buf)
+{
+ int i;
+
+ for (i = 0; i pcdev-channels; i++) {
+ if (!pcdev-sg_tail[i])
+ continue;
+ pcdev-sg_tail[i]-ddadr = buf-dmas[i].sg_dma;
+ }
+
+ pxa_dma_update_sg_tail(pcdev, buf);
+}
+
+/**
+ * pxa_camera_start_capture - start video capturing
+ * @pcdev: camera device
+ *
+ * Launch capturing. DMA channels should not be active yet. They should get
+ * activated at the end of frame interrupt, to capture only whole frames, and
+ * never begin the capture of a partial frame.
+ */
+static void pxa_camera_start_capture(struct pxa_camera_dev *pcdev)
+{
+ unsigned long cicr0, cifr;
+
+ dev_dbg(pcdev-dev, %s\n, __func__);
+ cifr = __raw_readl(pcdev-base + CIFR) | CIFR_RESET_F;
+ __raw_writel(cifr, pcdev-base + CIFR);
+
+ cicr0 = __raw_readl(pcdev-base + CICR0) | CICR0_ENB | CISR_IFO_0
+ | CISR_IFO_1 | CISR_IFO_2;
+ cicr0 = ~CICR0_EOFM;
+ __raw_writel(cicr0, pcdev-base + CICR0);
+}
+
+static void pxa_camera_stop_capture(struct
[PATCH 3/4] pxa_camera: Coding style sweeping
Transform sequences of form:
foo = val1 | val2 |
val3 | val4;
into :
foo = val1 | val2
| val3 | val4;
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/media/video/pxa_camera.c | 43 ++---
1 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 2d79ded..16bf0a3 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -158,9 +158,9 @@
#define CICR3_VSW_VAL(x) (((x) 11) CICR3_VSW) /* Vertical sync pulse
width */
#define CICR3_LPF_VAL(x) (((x) 0) CICR3_LPF) /* Lines per frame */
-#define CICR0_IRQ_MASK (CICR0_TOM | CICR0_RDAVM | CICR0_FEM | CICR0_EOLM | \
- CICR0_PERRM | CICR0_QDM | CICR0_CDM | CICR0_SOFM | \
- CICR0_EOFM | CICR0_FOM)
+#define CICR0_IRQ_MASK (CICR0_TOM | CICR0_RDAVM | CICR0_FEM | CICR0_EOLM \
+ | CICR0_PERRM | CICR0_QDM | CICR0_CDM | CICR0_SOFM \
+ | CICR0_EOFM | CICR0_FOM)
/*
* Structures
@@ -429,10 +429,10 @@ static int pxa_videobuf_prepare(struct videobuf_queue *vq,
* the actual buffer is yours */
buf-inwork = 1;
- if (buf-fmt!= icd-current_fmt ||
- vb-width != icd-width ||
- vb-height != icd-height ||
- vb-field != field) {
+ if (buf-fmt!= icd-current_fmt
+ || vb-width!= icd-width
+ || vb-height != icd-height
+ || vb-field!= field) {
buf-fmt= icd-current_fmt;
vb-width = icd-width;
vb-height = icd-height;
@@ -960,13 +960,13 @@ static int test_platform_param(struct pxa_camera_dev
*pcdev,
* quick capture interface supports both.
*/
*flags = (pcdev-platform_flags PXA_CAMERA_MASTER ?
- SOCAM_MASTER : SOCAM_SLAVE) |
- SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_PCLK_SAMPLE_FALLING;
+ SOCAM_MASTER : SOCAM_SLAVE)
+ | SOCAM_HSYNC_ACTIVE_HIGH
+ | SOCAM_HSYNC_ACTIVE_LOW
+ | SOCAM_VSYNC_ACTIVE_HIGH
+ | SOCAM_VSYNC_ACTIVE_LOW
+ | SOCAM_PCLK_SAMPLE_RISING
+ | SOCAM_PCLK_SAMPLE_FALLING;
/* If requested data width is supported by the platform, use it */
switch (buswidth) {
@@ -1094,8 +1094,8 @@ static int pxa_camera_set_bus_param(struct
soc_camera_device *icd, __u32 pixfmt)
cicr1 |= CICR1_COLOR_SP_VAL(2);
break;
case V4L2_PIX_FMT_RGB555:
- cicr1 |= CICR1_RGB_BPP_VAL(1) | CICR1_RGBT_CONV_VAL(2) |
- CICR1_TBIT | CICR1_COLOR_SP_VAL(1);
+ cicr1 |= CICR1_RGB_BPP_VAL(1) | CICR1_RGBT_CONV_VAL(2)
+ | CICR1_TBIT | CICR1_COLOR_SP_VAL(1);
break;
case V4L2_PIX_FMT_RGB565:
cicr1 |= CICR1_COLOR_SP_VAL(1) | CICR1_RGB_BPP_VAL(2);
@@ -1103,8 +1103,8 @@ static int pxa_camera_set_bus_param(struct
soc_camera_device *icd, __u32 pixfmt)
}
cicr2 = 0;
- cicr3 = CICR3_LPF_VAL(icd-height - 1) |
- CICR3_BFW_VAL(min((unsigned short)255, icd-y_skip_top));
+ cicr3 = CICR3_LPF_VAL(icd-height - 1)
+ | CICR3_BFW_VAL(min((unsigned short)255, icd-y_skip_top));
cicr4 |= pcdev-mclk_divisor;
__raw_writel(cicr1, pcdev-base + CICR1);
@@ -1372,8 +1372,7 @@ static unsigned int pxa_camera_poll(struct file *file,
poll_table *pt)
poll_wait(file, buf-vb.done, pt);
- if (buf-vb.state == VIDEOBUF_DONE ||
- buf-vb.state == VIDEOBUF_ERROR)
+ if (buf-vb.state == VIDEOBUF_DONE || buf-vb.state == VIDEOBUF_ERROR)
return POLLIN|POLLRDNORM;
return 0;
@@ -1489,8 +1488,8 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev-pdata = pdev-dev.platform_data;
pcdev-platform_flags = pcdev-pdata-flags;
- if (!(pcdev-platform_flags (PXA_CAMERA_DATAWIDTH_8 |
- PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
+ if (!(pcdev-platform_flags (PXA_CAMERA_DATAWIDTH_8
+ | PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
/* Platform hasn't set available data widths. This is bad.
* Warn and use a default. */
dev_warn(pdev-dev, WARNING! Platform hasn't set available
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] pxa_camera: Fix overrun condition on last buffer
The last buffer queued will often overrun, as the DMA chain
is finished, and the time the dma irq handler is activated,
the QIF fifos are filled by the sensor.
The fix is to ignore the overrun condition on the last
queued buffer, and restart the capture only on intermediate
buffers of the chain.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/media/video/pxa_camera.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 16bf0a3..dd56c35 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -734,14 +734,18 @@ static void pxa_camera_dma_irq(int channel, struct
pxa_camera_dev *pcdev,
status DCSR_ENDINTR ? EOF : , vb, DDADR(channel));
if (status DCSR_ENDINTR) {
- if (camera_status overrun) {
+ /*
+* It's normal if the last frame creates an overrun, as there
+* are no more DMA descriptors to fetch from QIF fifos
+*/
+ if (camera_status overrun
+!list_is_last(pcdev-capture.next, pcdev-capture)) {
dev_dbg(pcdev-dev, FIFO overrun! CISR: %x\n,
camera_status);
pxa_camera_stop_capture(pcdev);
pxa_camera_start_capture(pcdev);
goto out;
}
-
buf-active_dma = ~act_dma;
if (!buf-active_dma)
pxa_camera_wakeup(pcdev, vb, buf);
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge NOVA-T 500 falls over after warm reboot
Have you tried rmmoding the module (dvb_usb_dib0700) and reloading it? I think that it was in such a case where it then wrongly detected the card as 'cold', attempting to reload it, which failed. No as if I do a cold boot there isn't an issue. I just thought I would report this so that the developers were aware. Many thanks for the suggestion though. -- 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 PATCH 11/14] OMAP34XXCAM: Add driver
Hans Verkuil wrote: Situation 1 - Instance1: Select sensor 1, and Do queue/dequeue of buffers. - Instance2: If sensor 1 is currently selected, Begin loop requesting internally collected OMAP3ISP statistics (with V4L2 private based IOCTLs) for performing user-side Auto-exposure, Auto White Balance, Auto Focus algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a result. Question: if you have multiple sensors, and sensor 1 is selected, can you still get statistics from sensor 2? Or is all this still limited to the selected sensor? Just want to make sure I understand it all. The ISP does have submodules and there are some ways of configuring the data path inside the ISP, but in general just one sensor can be used at a time in meaningful way. Sergio, please correct me if I'm wrong: the only case I know that you can do is to use the ISP normally (data flowing through pretty much all the ISP modules) with one sensor and write the output of another sensor directly to memory in one of the parallel/CCP2/CSI2 receivers. I guess there's no use case for this, however. So just one user at a time for the OMAP 3 ISP. Another thing comes to my mind, though. Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. That is probably what the driver should do, yes. The V4L2 spec leaves it up to the driver whether you can switch inputs while a capture is in progress. In this case I think it is perfectly reasonably for the driver to return -EBUSY. Ok. I'm not clear if this single-node idea is really helping the user to have a simpler usage in Situation 1, which I feel will become pretty common on this driver... The spec is pretty clear about this, and existing v4l2 applications also expect this behavior. Also, suppose you have two video nodes, what happens when you want to use the inactive node? How can you tell it is inactive? open() succeeds. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
Hi list, I get errors on my DVB-C card, Mar 5 21:23:47 media kernel: [ 1489.968022] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer Ubuntu 8.10, TT-1501-C with CI module. There is a PVR-150 in the adjacent PCI slot, if that matters I can try an switch them or remove the pvr board. any ideas /Henrik -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu
wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu
wrote:
contents of file mr97310a.patch follow, for gspca/mr97310a.c
--- mr97310a.c.old2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new2009-03-03 17:19:06.0 -0600
@@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
data, n);
sd-header_read = 0;
gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
-len -= sof - data;
-data = sof;
-}
-if (sd-header_read 7) {
-int needed;
-
-/* skip the rest of the header */
-needed = 7 - sd-header_read;
-if (len = needed) {
-sd-header_read += len;
-return;
-}
-data += needed;
-len -= needed;
-sd-header_read = 7;
+/* keep the header, including sof marker, for coming
frame */
+len -= n;
+data = sof - sizeof pac_sof_marker;;
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
A few notes:
1. There is an extra semicolon on that last added line.
Oops. My bifocals.
2. sd-header_read no longer seems necessary.
This is very likely true.
3. If the SOF marker is split over two transfers then everything
falls
apart.
Are you sure about that?
Simple example: One transfer ends with FF FF 00 and the next
begins with FF 96 64. pac_find_sof() returns a pointer to 64, n is
set to 0, len stays the same, data now points at 3 bytes _before_
the transfer buffer, and we will most likely get undefined behavior
when trying to copy the data out of the transfer buffer. Not only
that, but the FF FF 00 portion of the SOF won't get copied to the
frame buffer.
Good point, since we will always pass frames to userspace which
start with the
sof, maybe we should just only pass the variable part of the header
to userspace?
That sure feels like the easiest solution to me.
Regards,
Hans
Hans, that would not solve the problem. In fact, it appears to me
that this problem was already inherent in the driver code before I
proposed any patches at all.
Erm, if I understood correctly (haven't looked yet) the driver is working
with the sof detection from pac_common, which does work with a SOF split
over multiple frames.
That is not my impression of what the code in pac_common is doing. That
code, as I understand, is totally neutral about such things. What is
does is to parse some data and search for an SOF marker, and if it finds
such a thing then it declares the next byte after to be what it calls
sof. Specifically, there is the function
static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
unsigned char *m, int len)
and what it does is that it searches through unsigned char *m up to the
extent declared in int len, looking for an SOF marker. If it finds one,
then it returns the location of the next byte after the SOF marker has
been successfully read.
Check that function again, more carefully, if it fails, but finds a part of
the sof at the end of m it remembers how much of the sof it has already seen
and continues where it left of the next time it is called.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thu, 5 Mar 2009, Thomas Kaiser wrote: kilg...@banach.math.auburn.edu wrote: That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or it could be that only the digits 0 through 9 are actually used, and the basis is then 100, or too many other variations to count. Also what is considered a normal or an average value? The trouble with your suggestion of a scale from 0 to 0xff is that it makes sense, and in a situation like this one obviously can not assume that. I don't really understand what you try to tell with this sentence: and in a situation like this one obviously can not assume that. I mean, your interpretation of 0 to 0xff is a natural and sensible interpretation (for us). But what one can not assume is, it made sense to those who constructed the system. Perhaps those guys were setting it all up differently. You are right, we don't know what the developer were thinking, unfortunately, You have to turn yourself in a webcam developer and think how you would do it. When you find, by observing/testing the cam, that it looks similar as you thought about how to do it, the observation should be true! True enough. In this respect, there is not much difference between still cameras and webcams. I will do this again in the next couple of weeks (lens removed). I believe that this documents are exists, but not available for public:-( Just company confidential. That may be true. If so, then such documentation is indeed not available. But sometimes a document is published and available, and one just is not aware of the fact. I will add to this that a lot of documentation for a lot of things really is available to the public. Anyway most of the Linux webcam drivers were done by re-engineering the Windoz driver (usbsnoop). That said, all information about the cams is a guess. Very true. Also true about the still cameras that I supported in libgphoto2. There are no secrets kept on the USB bus. But what is done inside the computer does not appear on the USB bus and there is no log of it. I will brag a little bit. Give me any cheap still camera that I don't know anything about, and a copy of the Windows driver. Provided only that the camera does not use an unknown, proprietary compression algorithm, I will promise you a working libgphoto2 driver for it within a week. Compression algorithms are the big obstacle there, and the only one. For the brightness thing, I just was working with a light and studied what is changing in the header of the frame. At this time I did this, I was not aware that I could remove the lens of the webcam to be more sensible to light change and get more precise results. During the work I did for the PAC7311 Pixart chip I found out that removing the lens and put light directly to the sensor does help a lot to figure out how the cam is working. And with this idea in mind, we could even get further to guess the compression algo from a cam. Assuming that the sensor has a Bayer pattern. - remove lens. - put white light on the sensor - use color filter an put each spectrum (RGB) on the sensor - check the stream and find out what is changing in the stream according to the different light conditions. I would very much like to see this in action. Looks like I get off topic, now ;-) But it is very interesting nevertheless. I think so, I didn't try with the color filter :-( Something else comes in my mind. Would it good to document all this what we are talking bout somewhere on a webpage? Thomas Perhaps so. Also a good idea to try to collect some people who have similar interests and are trying to work on similar problems. I have been trying to do that for a while, but with mixed and limited success. May be, some people read this and have the same felling. Let's see what happens. felling-feeling We are not chopping down trees. :) 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
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu
wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu
wrote:
contents of file mr97310a.patch follow, for gspca/mr97310a.c
--- mr97310a.c.old2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new2009-03-03 17:19:06.0 -0600
@@ -302,21 +302,9 @@ static void sd_pkt_scan(struct gspca_dev
data, n);
sd-header_read = 0;
gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
-len -= sof - data;
-data = sof;
-}
-if (sd-header_read 7) {
-int needed;
-
-/* skip the rest of the header */
-needed = 7 - sd-header_read;
-if (len = needed) {
-sd-header_read += len;
-return;
-}
-data += needed;
-len -= needed;
-sd-header_read = 7;
+/* keep the header, including sof marker, for coming frame
*/
+len -= n;
+data = sof - sizeof pac_sof_marker;;
}
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
A few notes:
1. There is an extra semicolon on that last added line.
Oops. My bifocals.
2. sd-header_read no longer seems necessary.
This is very likely true.
3. If the SOF marker is split over two transfers then everything
falls
apart.
Are you sure about that?
Simple example: One transfer ends with FF FF 00 and the next begins
with FF 96 64. pac_find_sof() returns a pointer to 64, n is set to 0,
len stays the same, data now points at 3 bytes _before_ the transfer
buffer, and we will most likely get undefined behavior when trying to
copy the data out of the transfer buffer. Not only that, but the FF FF
00 portion of the SOF won't get copied to the frame buffer.
Good point, since we will always pass frames to userspace which start
with the
sof, maybe we should just only pass the variable part of the header to
userspace?
That sure feels like the easiest solution to me.
Regards,
Hans
Hans, that would not solve the problem. In fact, it appears to me that
this problem was already inherent in the driver code before I proposed
any patches at all.
Erm, if I understood correctly (haven't looked yet) the driver is working
with the sof detection from pac_common, which does work with a SOF split
over multiple frames.
That is not my impression of what the code in pac_common is doing. That
code, as I understand, is totally neutral about such things. What is does
is to parse some data and search for an SOF marker, and if it finds such a
thing then it declares the next byte after to be what it calls sof.
Specifically, there is the function
static unsigned char *pac_find_sof(struct gspca_dev *gspca_dev,
unsigned char *m, int len)
and what it does is that it searches through unsigned char *m up to the
extent declared in int len, looking for an SOF marker. If it finds one,
then it returns the location of the next byte after the SOF marker has been
successfully read.
Check that function again, more carefully, if it fails, but finds a part of
the sof at the end of m it remembers how much of the sof it has already seen
and continues where it left of the next time it is called.
Well, here is the code in the function. I don't see. So can you explain?
Perhaps I am dense.
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i len; i++) {
if (m[i] == pac_sof_marker[sd-sof_read]) {
sd-sof_read++;
if (sd-sof_read == sizeof(pac_sof_marker)) {
PDEBUG(D_FRAM,
SOF found, bytes to analyze: %u.
Frame starts at byte #%u,
len, i + 1);
sd-sof_read = 0;
return m + i + 1;
}
} else {
sd-sof_read = 0;
}
}
return NULL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix race in infrared polling on rmmod
Hi Devin, On Thu, 5 Mar 2009 13:03:00 -0500, Devin Heitmueller wrote: On Thu, Mar 5, 2009 at 4:39 AM, Jean Delvare kh...@linux-fr.org wrote: I would suggest that this patch be broken into three separate patches, and then they can go in as the individual maintainers have the opportunity to test them out. This will ensure that no totally untested code goes into the codebase. OK, will do. This is how I had it originally, BTW... and then I merged all 3 patches because they are really fixing the same bug. But I'll split them again, no problem. I'll volunteer to do the em28xx patch. Thanks! -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
kilg...@banach.math.auburn.edu wrote: felling-feeling spelling/writing error (I meant feeling) Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pxa_camera: Remove YUV planar formats hole
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: This is not a review yet - just an explanation why I was suggesting to adjust height and width - you say yourself, that YUV422P (I think, this is wat you meant, not just YUV422) requires planes to immediately follow one another. But you have to align them on 8 byte boundary for DMA, so, you violate the standard, right? If so, I would rather suggest to adjust width and height for planar formats to comply to the standard. Or have I misunderstood you? No, you understand perfectly. And now, what do we do : - adjust height ? - adjust height ? - adjust both ? I couldn't decide which one, any hint ? -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pxa_camera: Remove YUV planar formats hole
On Thu, 5 Mar 2009, Robert Jarzmik wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: This is not a review yet - just an explanation why I was suggesting to adjust height and width - you say yourself, that YUV422P (I think, this is wat you meant, not just YUV422) requires planes to immediately follow one another. But you have to align them on 8 byte boundary for DMA, so, you violate the standard, right? If so, I would rather suggest to adjust width and height for planar formats to comply to the standard. Or have I misunderstood you? No, you understand perfectly. And now, what do we do : - adjust height ? - adjust height ? - adjust both ? I couldn't decide which one, any hint ? Shame the planes have to be contiguous. Software like ffmpeg doesn't require this and could handle planes with gaps between them without trouble. Plans aligned on 8 bytes boundaries would probably be faster in fact. Be better if v4l2_buffer gave us offsets for each plane. If you must adjust, probably better to adjust both. -- 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 PATCH 11/14] OMAP34XXCAM: Add driver
On Thursday 05 March 2009 21:11:02 Sakari Ailus wrote: Hans Verkuil wrote: Situation 1 - Instance1: Select sensor 1, and Do queue/dequeue of buffers. - Instance2: If sensor 1 is currently selected, Begin loop requesting internally collected OMAP3ISP statistics (with V4L2 private based IOCTLs) for performing user-side Auto-exposure, Auto White Balance, Auto Focus algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a result. Question: if you have multiple sensors, and sensor 1 is selected, can you still get statistics from sensor 2? Or is all this still limited to the selected sensor? Just want to make sure I understand it all. The ISP does have submodules and there are some ways of configuring the data path inside the ISP, but in general just one sensor can be used at a time in meaningful way. Sergio, please correct me if I'm wrong: the only case I know that you can do is to use the ISP normally (data flowing through pretty much all the ISP modules) with one sensor and write the output of another sensor directly to memory in one of the parallel/CCP2/CSI2 receivers. I guess there's no use case for this, however. So just one user at a time for the OMAP 3 ISP. Another thing comes to my mind, though. Sergio has posted earlier a patchset containing a driver for using the ISP to process images from memory to memory. The ISP driver is used roughly the same way as with the omap34xxcam and real sensors. The interface towards the userspace offered by the driver, however, is different, you probably saw it (preview and resizer wrappers). My opinion has been that the memory-to-memory operation of the ISP should also offer V4L2 interface. V4L2, however, doesn't support such devices at the moment. The only differences that I can see is that 1. the input is a video buffer instead of sensor and 2. the source format needs to be specified somehow since the ISP can also do format conversion. So it's output and input at the same time. But if we had one video device per ISP, then memory-to-memory operation would be just one... input or output or what? :) Earlier we were thinking of creating one device node for it. This sounds like a codec interface as 'described' here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html#CODEC It would be a first for V4L2 to have a driver that can do this, but I agree that that would be a single device that has both 'output' and 'capture'. That is probably what the driver should do, yes. The V4L2 spec leaves it up to the driver whether you can switch inputs while a capture is in progress. In this case I think it is perfectly reasonably for the driver to return -EBUSY. Ok. I'm not clear if this single-node idea is really helping the user to have a simpler usage in Situation 1, which I feel will become pretty common on this driver... The spec is pretty clear about this, and existing v4l2 applications also expect this behavior. Also, suppose you have two video nodes, what happens when you want to use the inactive node? How can you tell it is inactive? open() succeeds. Currently you can have just one device node using the ISP open. omap34xxcam_open() calls isp_get() which fails if the ISP use count was non-zero (means one). Or did I misunderstood something? Oh dear. Please don't use 'use counts'. It is perfectly acceptable and desirable to have multiple opens on the same video node. Only one file handle can do reading/writing/streaming, but others should be able to querying controls, set brightness, or whatever at the same time. Use counts are really bad and totally unnecessary. Only if another file handle is in streaming mode (and when using VIDIOC_S_PRIORITY) does it make sense to return -EBUSY for certain ioctls or read/write operations. Otherwise you shouldn't limit the user from opening the same device node as many times as he wants and use that to query the video device. There are unfortunately a whole bunch of existing v4l2 drivers that have this same limitation. These drivers are wrong. It is sadly not very easy to fix them, but I can try to prevent the same bug from appearing in new drivers. BTW, I looked at omap24xxcam_open(): data like fh-pix does *not* belong to the filehandle struct, it should be part of the top-level data structure. You want to be able to do simple things like querying a video node for the currently selected format. You can't do that if the format is stored in the filehandle! E.g.: you are streaming and you want to run v4l2-ctl --get-fmt-video to check what video format is being used. Things like this must be supported by a well-written v4l2 driver. Again, sadly quite a few v4l2 drivers do this wrong as well :-( I also see that cam-users is not decreased by one if omap24xxcam_sensor_enable() fails. Note that I'm looking at the code in the v4l-dvb repository, the linux-omap git tree might have fixed that already. Regards, Hans
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Thursday 05 March 2009 21:57:16 Trent Piepho wrote: On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Thu, 5 Mar 2009, Trent Piepho wrote: On Thu, 5 Mar 2009, Guennadi Liakhovetski wrote: On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote: Beside the fact that we don't need to strip support for legacy kernels, the advantage of using this method is that we can evolute to a new development model. As several developers already required, we should really use the standard -git tree as everybody's else. This will simplify a lot the way we work, and give us more agility to send patches upstream. With this backport script, plus the current v4l-dvb building systems, and after having all backport rules properly mapped, we can generate a test tree based on -git drivers/media, for the users to test the drivers against their kernels, and still use a clean tree for development. Sorry, switching to git is great, but just to make sure I understood you right: by -git drivers/media you don't mean it is going to be a git tree of only drivers/media, but it is going to be a normal complete Linux kernel tree, right? So there will be no way we can test a driver without switching to a new kernel hourly? And there is no way we can test someone else's tree without compiling an entirely new kernel and rebooting? And every tree we want to work on requires a complete copy of the entire kernel source? AFAIR, Mauro wanted to provide snapshots for those who absolutely prefer to work with partial trees. Although, to be honest, I don't understand what makes video drivers so special. Think about audio drivers, or network, including WLAN. I never heard about those subsystems working with or providing subtree snapshots. If only before specific drivers or subsystems are included in the mainline, but not long after that. ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Lots of subsystems are more tightly connected to the kernel and compiling the subsystem out of tree against any kernel just wouldn't work. Some subsystems (like say gpio or led) mostly provide a framework to the rest of the kernel so working on them without the rest of the tree doesn't make sense either. Or they don't get many patches and don't have many active maintainers so they don't really have any development SCM at all. Just some patches through email that get applied by one maintainer. Our model of just the subsystem is fine when all you are dealing with are PCI and USB devices, but especially with embedded devices you get a lot of links to the platform code. For that you need to have a full kernel. I expect that the embedded drivers will be a very active area for the next several years so we have to make sure we can handle that. 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: Results of the 'dropping support for kernels 2.6.22' poll
On Thu, 5 Mar 2009, Trent Piepho wrote: ALSA used a partial tree, but their system was much worse than v4l-dvb's. I think the reason more systems don't do it is that setting up the build system we have with v4l-dvb was a lot of work. They don't have that. Right, it was a lot of work, it is still quite a bit of work (well, I'm not doing that work directly, but it affetcs me too, when I have to adjust patches, that I generated from a complete kernel tree to fit compatibility-emhanced versions), and it is not going to be less work. Lots of subsystems are more tightly connected to the kernel and compiling the subsystem out of tree against any kernel just wouldn't work. Some subsystems (like say gpio or led) mostly provide a framework to the rest of the kernel so working on them without the rest of the tree doesn't make sense either. Or they don't get many patches and don't have many active maintainers so they don't really have any development SCM at all. Just some patches through email that get applied by one maintainer. That's why I didn't give LED or GPIO or SPI or I2C or SCSI or ATA or MMC or MTD or ... as examples, but audio and network, which are also largely consumer interfaces and are actively developed. 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
Re: [linux-dvb] (no subject) - in fact Amiga OS4 and v4l-dvb
Hello, Am Donnerstag, den 05.03.2009, 19:04 +0100 schrieb lars ouff: Hello, I am looking into the possibility of porting or writing a simple driver for the DVB-T part of the SAA7135 chip. I am merely doing some research for an eventual long-term hobby programming project. I have a little programming experience but have friends that are more experienced that will help. The driver will be for the AmigaOS4 platform (PowerPC). hmm, I know quite nothing about the recent Amiga OS4, but the GNU/Linux saa7134 driver supports saa7130/34/33/35 and saa7131e PCI brigdes currently. For DVB-T and DVB-S we rely on the dvb subsystem. For almost all current silicon tuners and demodulators you will need NDAs for register programming details too. (some Freescale support with open specs was just added) Given that the PCI interface seems to vanish soon on recent PCs, depending on how long-term your efforts might be, you might end up without any such devices on the markets anymore. The work on Linux support started in 2002. The reason I'm mailing this list is to maybe get some help with where to start and what is needed. I read in the PDF for the chip that there is an SDK available for 3rd parties, is this freely available online? As far I know there is still nothing freely available for the programming details. (I've mailed Gigabyte about it but don't expect swift response). I also read something about an alternative API for non Win systems. Amiga devs told me that writing a new driver will be the thing to do and not try to port a linux driver, comments? I'm asuming there is a ppc-linux driver? I've read some threads about the support for this chip in the linux world and it seems good. For decoding in AmigaOS4 we have ffmpeg and libfaad. __ Why reinvent the wheel when others already did the work and it is Open Source? With the hidden auto detected devices the driver currently supports about two hundred different PCI cards. We also support almost all tuners currently on the markets also vbi/cc, external analog inputs and radio and soon RDS. Also some cards with mpeg encoders. This was only possible with our active community and people willing to help to add support for new stuff and it is an still ongoing process. You can use Linux PPC, maybe just CD/DVD live media or boot it from some Flash media to have a try, if you already have some supported hardware. I suggest to use xine/kaffeine for a painless try with GUI, but you must take care to have the codecs distributions can't provide, but are legal for individual use. The Amiga devs probably have good reasons to suggest to write a new driver, but I don't know about any details. Unfortunately linux-dvb is not easy portable for Open Source m$ projects too, but our code is there ;) Maybe some at home in both worlds can give better pointers or you must raise more detailed questions. For me CP/M was still good enough during all that ... Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thursday 05 March 2009 14:58:54 kilg...@banach.math.auburn.edu wrote:
Well, here is the code in the function. I don't see. So can you explain?
Perhaps I am dense.
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i len; i++) {
if (m[i] == pac_sof_marker[sd-sof_read]) {
sd-sof_read++;
if (sd-sof_read == sizeof(pac_sof_marker)) {
PDEBUG(D_FRAM,
SOF found, bytes to analyze: %u.
Frame starts at byte #%u,
len, i + 1);
sd-sof_read = 0;
return m + i + 1;
}
} else {
sd-sof_read = 0;
}
}
return NULL;
}
We send a chunk of data to this function, as pointed to by m. It could be the
entire transfer buffer or only a part of it, but that doesn't matter. If the
chunk of data ends with FF FF 00 then sd-sof_read will be set to 3 when the
function exits. On the next call it picks up where it left off and looks for
byte 4 of the SOF.
Way back when, I said to copy sd-sof_read bytes from pac_sof_marker if you
want the portion of the SOF that was in the previous transfer. There's no
need to buffer 4 bytes from the previous transfer because the SOF is
_constant_.
So, if it's constant, why do we need to copy it to userspace at all? If we
do, then every frame buffer begins with a constant, useless FF FF 00 FF 96.
The reassurance doesn't matter because the frame _must_ have started with
FF FF 00 FF 96 to get there in the first place. I agree with Hans that it
isn't necessary, and by not sending it to userspace we simplify the kernel
driver.
But what if it's not constant? Maybe the SOF is 4 bytes and the 5th byte is
some useful data that, 99.9% of the time, is set to 96? This is the only
reason I see for keeping the SOF.
-Kyle
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Thu, 5 Mar 2009, Kyle Guinn wrote:
On Thursday 05 March 2009 14:58:54 kilg...@banach.math.auburn.edu wrote:
Well, here is the code in the function. I don't see. So can you explain?
Perhaps I am dense.
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i len; i++) {
if (m[i] == pac_sof_marker[sd-sof_read]) {
sd-sof_read++;
if (sd-sof_read == sizeof(pac_sof_marker)) {
PDEBUG(D_FRAM,
SOF found, bytes to analyze: %u.
Frame starts at byte #%u,
len, i + 1);
sd-sof_read = 0;
return m + i + 1;
}
} else {
sd-sof_read = 0;
}
}
return NULL;
}
We send a chunk of data to this function, as pointed to by m. It could be the
entire transfer buffer or only a part of it, but that doesn't matter. If the
chunk of data ends with FF FF 00 then sd-sof_read will be set to 3 when the
function exits. On the next call it picks up where it left off and looks for
byte 4 of the SOF.
It took me a while to see this, but, yes. So I agree that something needed
to be fixed. It is fixed, now. There is a revised patch.
Way back when, I said to copy sd-sof_read bytes from pac_sof_marker if you
want the portion of the SOF that was in the previous transfer. There's no
need to buffer 4 bytes from the previous transfer because the SOF is
_constant_.
True. So this is the solution which is just now adopted.
So, if it's constant, why do we need to copy it to userspace at all? If we
do, then every frame buffer begins with a constant, useless FF FF 00 FF 96.
The reassurance doesn't matter because the frame _must_ have started with
FF FF 00 FF 96 to get there in the first place.
Unless it was a frame from some other camera. But it could have been a
frame dumped from some other camera, and then potentially useful
information for evaluating what it is, would have been lost.
I agree with Hans that it
isn't necessary, and by not sending it to userspace we simplify the kernel
driver.
My experience indicates otherwise. One of the reasons for doing this is,
if one has _all_ of this information it is easier to recognize where it
came from. What kind of camera. What kind of compression. That kind of
thing. It then becomes possible to do things such as to look
at a raw file in total isolation from the streaming app, six months later,
and to be able to know immediately what kind of camera it came from, and
all other information relevant for processing it on the spot with a
program which converts raw data into finished frames or images. If only it
were possible to embed the width and height, somehow, into the header,
then my happiness would be total.
But what if it's not constant? Maybe the SOF is 4 bytes and the 5th byte is
some useful data that, 99.9% of the time, is set to 96? This is the only
reason I see for keeping the SOF.
Very good point. It could happen, couldn't it? It already occurred to me,
actually. We do not know that it will not happen. For, in such a situation
we are at the mercy of some other guys who make cameras. So why paint
oneself into a corner and be sorry later on?
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
Fw: oops in pwc_reset_buffers
Begin forwarded message: Date: Thu, 05 Mar 2009 14:53:17 +0100 From: strawks stra...@yahoo.fr To: linux-ker...@vger.kernel.org Subject: oops in pwc_reset_buffers Hi all, On 2.6.29-rc6, when resuming from suspend to RAM I got the following oops when motion tried to open /dev/video0. Just ask me if you need some additionnal info (full log attached). regards, strawks Mar 5 08:26:38 evangeline kernel: [109985.797284] BUG: unable to handle kernel NULL pointer dereference at 0008 Mar 5 08:26:38 evangeline kernel: [109985.797290] IP: [a01d1439] pwc_reset_buffers+0x4a/0xdd [pwc] Mar 5 08:26:38 evangeline kernel: [109985.797299] PGD 51dad067 PUD 18485067 PMD 0 Mar 5 08:26:38 evangeline kernel: [109985.797302] Oops: 0002 [#1] SMP Mar 5 08:26:38 evangeline kernel: [109985.797305] last sysfs file: /sys/class/video4linux/video0/index Mar 5 08:26:38 evangeline kernel: [109985.797307] CPU 0 Mar 5 08:26:38 evangeline kernel: [109985.797308] Modules linked in: i915 drm i2c_algo_bit acpi_cpufreq cpufreq_conservative cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_ondemand freq_table ipv6 fuse coretemp it87 hwmon_vid sbp2 loop snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_usb_audio snd_hda_intel snd_usb_lib snd_hda_codec snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm snd_hwdep snd_seq snd_timer snd_seq_device pwc i2c_i801 psmouse snd videodev v4l1_compat i2c_core serio_raw iTCO_wdt snd_page_alloc soundcore pcspkr v4l2_compat_ioctl32 joydev intel_agp button evdev ext3 jbd mbcache ide_gd_mod ata_piix ata_generic libata scsi_mod hid_logitech ff_memless usbhid hid ohci1394 ieee1394 ide_pci_generic it8213 ide_core ehci_hcd r8169 mii uhci_hcd thermal processor fan thermal_sys Mar 5 08:26:38 evangeline kernel: [109985.797356] Pid: 26749, comm: motion Not tainted 2.6.29-rc6 #1 EG45M-DS2H Mar 5 08:26:38 evangeline kernel: [109985.797359] RIP: 0010:[a01d1439] [a01d1439] pwc_reset_buffers+0x4a/0xdd [pwc] Mar 5 08:26:38 evangeline kernel: [109985.797366] RSP: 0018:880018519cb8 EFLAGS: 00010046 Mar 5 08:26:38 evangeline kernel: [109985.797368] RAX: RBX: 880037968c00 RCX: Mar 5 08:26:38 evangeline kernel: [109985.797370] RDX: 805852b8 RSI: 0296 RDI: Mar 5 08:26:38 evangeline kernel: [109985.797372] RBP: 880037968e70 R08: 0003 R09: Mar 5 08:26:38 evangeline kernel: [109985.797375] R10: R11: 804697f2 R12: 0001 Mar 5 08:26:38 evangeline kernel: [109985.797377] R13: 000a R14: 00f0 R15: 0140 Mar 5 08:26:38 evangeline kernel: [109985.797379] FS: 7faba7078950() GS:80671000() knlGS: Mar 5 08:26:38 evangeline kernel: [109985.797382] CS: 0010 DS: ES: CR0: 8005003b Mar 5 08:26:38 evangeline kernel: [109985.797384] CR2: 0008 CR3: 533a7000 CR4: 000406e0 Mar 5 08:26:38 evangeline kernel: [109985.797386] DR0: DR1: DR2: Mar 5 08:26:38 evangeline kernel: [109985.797388] DR3: DR6: 0ff0 DR7: 0400 Mar 5 08:26:38 evangeline kernel: [109985.797391] Process motion (pid: 26749, threadinfo 880018518000, task 88007b3b0050) Mar 5 08:26:38 evangeline kernel: [109985.797393] Stack: Mar 5 08:26:38 evangeline kernel: [109985.797394] 0001 880037968c00 a01d270d Mar 5 08:26:38 evangeline kernel: [109985.797397] c0d05605 88007b8ac080 880037968c00 Mar 5 08:26:38 evangeline kernel: [109985.797401] 88007a8c5400 a01d616c Mar 5 08:26:38 evangeline kernel: [109985.797405] Call Trace: Mar 5 08:26:38 evangeline kernel: [109985.797408] [a01d270d] ? pwc_try_video_mode+0x2d/0xa5 [pwc] Mar 5 08:26:38 evangeline kernel: [109985.797414] [a01d616c] ? pwc_video_do_ioctl+0xe8b/0x127b [pwc] Mar 5 08:26:38 evangeline kernel: [109985.797421] [802379d7] ? default_wake_function+0x0/0x9 Mar 5 08:26:38 evangeline kernel: [109985.797426] [a01a1a46] ? video_usercopy+0x17a/0x217 [videodev] Mar 5 08:26:38 evangeline kernel: [109985.797433] [a01d52e1] ? pwc_video_do_ioctl+0x0/0x127b [pwc] Mar 5 08:26:38 evangeline kernel: [109985.797439] [a01d164c] ? pwc_video_ioctl+0x65/0x7f [pwc] Mar 5 08:26:38 evangeline kernel: [109985.797446] [a01a110b] ? v4l2_ioctl+0x38/0x3a [videodev] Mar 5 08:26:38 evangeline kernel: [109985.797451] [802c2aa3] ? vfs_ioctl+0x56/0x6c Mar 5 08:26:38 evangeline kernel: [109985.797455] [802c2ef2] ? do_vfs_ioctl+0x439/0x472 Mar 5 08:26:38 evangeline kernel: [109985.797458] [802b74c3] ? vfs_write+0x121/0x156 Mar 5 08:26:38 evangeline kernel: [109985.797462]
Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hi Alexey, On Fri, Mar 6, 2009 at 7:05 AM, Alexey Klimov klimov.li...@gmail.com wrote: Hello, all On Thu, Mar 5, 2009 at 7:42 PM, Curran, Dominic dcur...@ti.com wrote: Hi Kim -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim Sent: Wednesday, March 04, 2009 8:58 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 Hi Sergio, On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: + /* turn on analog power */ + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); + + /* out of standby */ + gpio_set_value(MT9P012_STANDBY_GPIO, 0); + udelay(1000); It seems better using msleep rather than udelay for 1000us much. Just to be safe :) How about you? Why is msleep safer than udelay ? I have small guess that he is wondering why you are using big delays with help of udelay(). (It's may be obvious but as we know udelay uses cpu loops to make delay and msleep calls to scheduler) So, msleep is more flexible and softer but if you need precise time or you can't sleep in code you need udelay. Sometimes using udelay is reasonably required. I totally agree with you. But besides the udelay and mdelay accuracy issue, Sergio's power up timing for MT9P012 seems to delay too much. (not for lens controller.) I also have experience using MT9P012 sensor with other ISP, but in case of mine it took 600 to 800 ms for whole power up sequence. But if that delay depends on SDP board and Sergio had no options without making delay for that much, then it explains everything. So I'm saying if there was no other option than making long delay to bring up MT9P012 sensor properly, if I were Sergio I should rather use mdelay than udelay. But if that delay is necessary to bring up MT9P012 with SDP board, I have no idea what to say. In that case, Sergio should be right. Cheers, Nate -- Best regards, Klimov Alexey -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] for the file gspca/mr97310a.c
First time ever that I mouse-copied an address and it gained a typo.
Amazing. So trying again. The patch works better than the mouse, though.
Guaranteed.
-- Forwarded message --
Date: Thu, 5 Mar 2009 20:09:52 -0600 (CST)
From: kilg...@banach.math.auburn.edu
To: Hans de Goede hdego...@redhat.com
Cc: Kyle Guinn ely...@gmail.com, Jean-Francois Moine moin...@free.fr,
linux-mme...@vger.kernel.org
Subject: [PATCH] for the file gspca/mr97310a.c
I just realized that the message below only went in one direction and did not
have the proper title. So I fix that, now. The purpose of the patch has been
extensively discussed in the thread seen in the title of the forwarded message.
The patch below improves on the previous patch submitted for discussion, by
fixing a bug in that one. The purpose of the patch is to save the header for
the raw frames from the MR97310a cameras, which previously was not done. The
patch achieves this result, and, when tested with two cameras, gives nice
results.
A parallel patch for libv4lconvert/mr97310a.c was also presented in the RFC.
Needless to say, it is needed simultaneously, before the output from the camera
can be properly decompressed.
Theodore Kilgore
-- Forwarded message --
Date: Thu, 5 Mar 2009 19:27:57 -0600 (CST)
From: kilg...@banach.math.auburn.edu
To: Hans de Goede hdego...@redhat.com
Subject: Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Fri, 6 Mar 2009, Hans de Goede wrote:
Well 2.6.29 is getting closer, so we need to be reasonable quick with the
kernel side changes. As we do not want to change this after a kernel
has been released with the current behaviour.
For libv4l we can take our time. But having a kernel patch ready soon
would be good.
Well, it did not take as long as I thought. And, as far as the libv4lconvert
change, you _do_ have a patch, right?
So, here is a patch for one file, namely for gspca/mr97310a.c. I hope that it
will meet all objections.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
--
--- mr97310a.c.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c 2009-03-05 19:14:13.0 -0600
@@ -29,9 +29,7 @@ MODULE_LICENSE(GPL);
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
-
u8 sof_read;
- u8 header_read;
};
/* V4L2 controls supported by the driver */
@@ -100,12 +98,9 @@ static int sd_init(struct gspca_dev *gsp
static int sd_start(struct gspca_dev *gspca_dev)
{
- struct sd *sd = (struct sd *) gspca_dev;
__u8 *data = gspca_dev-usb_buf;
int err_code;
- sd-sof_read = 0;
-
/* Note: register descriptions guessed from MR97113A driver */
data[0] = 0x01;
@@ -285,40 +280,29 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data, /* isoc packet */
int len) /* iso packet length */
{
- struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;
sof = pac_find_sof(gspca_dev, data, len);
if (sof) {
int n;
-
+ int marker_len = sizeof pac_sof_marker;
/* finish decoding current frame */
n = sof - data;
- if (n sizeof pac_sof_marker)
- n -= sizeof pac_sof_marker;
+ if (n marker_len)
+ n -= marker_len;
else
n = 0;
frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame,
data, n);
- sd-header_read = 0;
- gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
- len -= sof - data;
+ /* Start next frame. */
+ gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+ pac_sof_marker, marker_len);
+ len -= n;
+ len -= marker_len;
+ if (len 0)
+ len = 0;
data = sof;
}
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
- }
-
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
}
@@ -337,6 +321,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x08ca, 0x0111)},
+ {USB_DEVICE(0x093a, 0x010f)},
{}
};
MODULE_DEVICE_TABLE(usb, device_table);
--
To unsubscribe from this list: send the
About the radio-si470x driver for I2C interface
Hi all, I have worked with Silicon Labs Si4709 chip using the I2C interface. There is the radio-si470x driver in linux-kernel, but it uses usb interface. First, i made a new file based on radio-si470x.c in driver/media/radio/ for si4709 i2c driver and modified it to use i2c interface instead of usb interface and could listen to FM radio station. I think it can be to join two things together to one file because there isn't the difference between the two except for the interface. I am considering how to integrate them. Please send your opinion. -- - Joonyoung Shim -- 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] cx88: Add IR support to pcHDTV HD3000 HD5500
Thanks for your comments, Trent. My responses below: Trent Piepho wrote: On Sat, 28 Feb 2009, Erik S. Beiser wrote: cx88: Add IR support to pcHDTV HD3000 HD5500 Signed-off-by: Erik S. Beiser er...@bu.edu --- Idea originally from http://www.pchdtv.com/forum/viewtopic.php?t=1529 I made it into this small patch and added the HD3000 support also, which I have I've actually been using this for over a year, updating for new kernel versions. I'm tired of doing so, and would like to try and have it merged upstream -- I hope I got all the patch-mechanics correct. I just updated and tested it today on 2.6.28.7 vanilla. Thanks. You forgot a patch description. Ok, I had looked around and saw many patches that had the one-liner descriptions, which I thought would be sufficient for a four line patch. At your request, I can add a couple lines description when I fix it (see below). Since neither the HD-3000 or HD-5500 came with a remote, and at least my HD-3000 didn't even come with an IR receiver. So I have to ask why configuring the driver to work a remote you happened to have is any more correct than configuring it to work a remote someone else happens to have? True, the vendor doesn't seem to sell a remote or IR receiver with these cards. I was actually surprised when I got mine to see the jack for an IR receiver, which can be made to work if one has those parts from another source. I don't think that because these cards were sold without a remote and receiver should mean that we don't expose the receiver functionality. I didn't see that happening elsewhere, so I adopted this 'worksforme' solution. You have a valid point about the key mapping, which I did not fully consider. I don't have a good justification. OTOH how does someone with one of those cards use a remote different from what came with their card? Is that possible? All I'm really trying to accomplish is to somehow get inputs from a remote exposed through some device, with which I could parse stuff with lirc. This method exposed it via a /dev/input/eventN node. I admit I hadn't paid too much attention to the keymapping before. (Just trying to get the thing to work.) But you prompted me to dig deeper, and I see that in drivers/media/common/ir-keymaps.c there is a ir_codes_empty mapping. I tried it tonight with that mapping instead, and a /dev/input/eventN device was created, but I don't seem to get anything from it. Which I guess isn't too surprising, but if so, then how can I go about generically exposing signals from the IR port to userspace? This patch also causes these cards to generate 101 interrupts per second per card, even when not in use. That seems pretty costly for a card that doesn't even come with an ir sensor. Whoa, I didn't realize that. Can you point me to how I can verify that? Is that simply an effect of the ir-sampling type? Might a different type be preferred? I could do some experimenting. Is there a better way of doing this? I'm willing to do a little legwork to see if I can make this a better, more generic solution. --Erik p.s. I don't mean to appear rude, so FYI I will be w/o net access this weekend and thus unable to respond to anyone until at least Monday. -- 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: [PULL] http://linuxtv.org/hg/~awalls/cx18
On Tue, 2009-03-03 at 21:50 -0300, Mauro Carvalho Chehab wrote:
On Sun, 01 Mar 2009 22:04:55 -0500
Andy Walls awa...@radix.net wrote:
Mauro,
Please pull from
http://linuxtv.org/hg/~awalls/cx18
for the following
cx18: Add interlock so sliced VBI insertion only happens for an MPEG PS
cx18: Fix VPS service register code and ensure VBI consistentcy with ivtv
Argh! This is really ugly!
+
+#include linux/ivtv.h /* For IVTV_SLICED_TYPE_* */
+
Yes. It is.
Why do you need to include a header for a device that has nothing to do with
cx18?
I don't.
My rationale was that the cx18 driver supports a VBI data format type
enumerated in the V4L2 spec and in linux/include/linux/videodev2.h,
namely:
enum v4l2_mpeg_stream_vbi_fmt {
[...]
V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1, /* VBI in private packets, IVTV
format */
};
And some values used in that data format are in no other internal nor
exported header than linux/include/linux/ivtv.h. The data format itself
isn't delared at all in any kernel header AFAIK, but only in
linux/Documentation/video4linux/README.vbi in prose instead of C
declarations.
This doesn't belong here...
OK.
If those VBI parameters should be global to all devices, then it should be,
instead, at some subsystem header, and your patch should also touch on the
other drivers.
Yes, they should be exported to userspace as well, so apps like MythTV
don't have to keep their own copies as well. I'm going to work on a
V4L2 spec change to add structures and defines for the packets indicated
by V4L2_MPEG_STREAM_VBI_FMT_IVTV, and then add it to some API header.
Maybe in linux/include/linux/videodev2.h with all the other VBI data
formats.
Unless someone really disagrees.
In the mean time I will issue a new PULL request omitting the portion of
the change you don't like.
Regards,
Andy
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
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please disregard my previous pull request and instead please pull from: http://linuxtv.org/hg/~awalls/v4l-dvb for: cx18: Add interlock so sliced VBI insertion only happens for an MPEG PS cx18: Fix VPS service register codes cx18: Correct comments about vertical and horizontal blanking timings cx18: Fix s-parse warnings and a logic error about extracting the VBI PTS cx18: Include cx18-audio.h in cx18-audio.c to eliminate s-parse warning cx18: Fix a video scaling check problem introduced by sliced VBI changes cx18: Use strlcpy() instead of strncpy() for temp eeprom i2c_client setup This collections of changesets do not have the #include linux/ivtv.h that was in my previous pull request. Regards, Andy diffstat: cx18-audio.c|1 + cx18-av-core.c | 42 +++--- cx18-av-core.h | 19 --- cx18-av-vbi.c |6 +++--- cx18-controls.c | 40 +++- cx18-driver.c |3 +-- cx18-streams.c |5 ++--- cx18-vbi.c |9 + 8 files changed, 86 insertions(+), 39 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Conference
Hello, I'm attending as a speaker for one session which title is Digital camera framework in Linux I'm also looking forward to see many v4l2 engineers and discuss about latest issues. BTW, see you there Hans :) Nate On Fri, Mar 6, 2009 at 1:49 AM, Hans Verkuil hverk...@xs4all.nl wrote: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] for the file gspca/mr97310a.c
On Thursday 05 March 2009 20:34:27 kilg...@banach.math.auburn.edu wrote:
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
--
--- mr97310a.c.old2009-02-23 23:59:07.0 -0600
+++ mr97310a.c2009-03-05 19:14:13.0 -0600
@@ -29,9 +29,7 @@ MODULE_LICENSE(GPL);
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
-
u8 sof_read;
- u8 header_read;
};
/* V4L2 controls supported by the driver */
@@ -100,12 +98,9 @@ static int sd_init(struct gspca_dev *gsp
static int sd_start(struct gspca_dev *gspca_dev)
{
- struct sd *sd = (struct sd *) gspca_dev;
__u8 *data = gspca_dev-usb_buf;
int err_code;
- sd-sof_read = 0;
-
Good catch, I didn't realize this was kzalloc'd.
/* Note: register descriptions guessed from MR97113A driver */
data[0] = 0x01;
@@ -285,40 +280,29 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data, /* isoc packet */
int len) /* iso packet length */
{
- struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;
sof = pac_find_sof(gspca_dev, data, len);
if (sof) {
int n;
-
+ int marker_len = sizeof pac_sof_marker;
The value doesn't change; there's no need to use a variable for this.
/* finish decoding current frame */
n = sof - data;
- if (n sizeof pac_sof_marker)
- n -= sizeof pac_sof_marker;
+ if (n marker_len)
+ n -= marker_len;
else
n = 0;
frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame,
data, n);
- sd-header_read = 0;
- gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
- len -= sof - data;
+ /* Start next frame. */
+ gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+ pac_sof_marker, marker_len);
+ len -= n;
+ len -= marker_len;
+ if (len 0)
+ len = 0;
len -= sof - data; is a shorter way to find the remaining length.
data = sof;
}
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
- }
-
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
}
@@ -337,6 +321,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x08ca, 0x0111)},
+ {USB_DEVICE(0x093a, 0x010f)},
This change is unrelated; maybe it should be in a different patch? Don't
forget to update Documentation/video4linux/gspca.txt with the new camera.
-Kyle
--
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: Embedded Linux Conference
That is great! I will let you know our plans soon. -Manju -Original Message- From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com] Sent: Friday, March 06, 2009 9:33 AM To: Hans Verkuil Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Hadli, Manjunath; Aguirre Rodriguez, Sergio Alberto; Hiremath, Vaibhav Subject: Re: Embedded Linux Conference Hello, I'm attending as a speaker for one session which title is Digital camera framework in Linux I'm also looking forward to see many v4l2 engineers and discuss about latest issues. BTW, see you there Hans :) Nate On Fri, Mar 6, 2009 at 1:49 AM, Hans Verkuil hverk...@xs4all.nl wrote: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] for the file gspca/mr97310a.c
On Thu, 5 Mar 2009, Kyle Guinn wrote:
On Thursday 05 March 2009 20:34:27 kilg...@banach.math.auburn.edu wrote:
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
--
--- mr97310a.c.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c 2009-03-05 19:14:13.0 -0600
@@ -29,9 +29,7 @@ MODULE_LICENSE(GPL);
/* specific webcam descriptor */
struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
-
u8 sof_read;
- u8 header_read;
};
/* V4L2 controls supported by the driver */
@@ -100,12 +98,9 @@ static int sd_init(struct gspca_dev *gsp
static int sd_start(struct gspca_dev *gspca_dev)
{
- struct sd *sd = (struct sd *) gspca_dev;
__u8 *data = gspca_dev-usb_buf;
int err_code;
- sd-sof_read = 0;
-
Good catch, I didn't realize this was kzalloc'd.
Hmmm. Perhaps I cut too much and _that_ should go back in. What if one
stops the streaming and then restarts it? OTOH, one only risks losing one
frame. OTTH, one might really want that frame. I will put it back.
/* Note: register descriptions guessed from MR97113A driver */
data[0] = 0x01;
@@ -285,40 +280,29 @@ static void sd_pkt_scan(struct gspca_dev
__u8 *data, /* isoc packet */
int len) /* iso packet length */
{
- struct sd *sd = (struct sd *) gspca_dev;
unsigned char *sof;
sof = pac_find_sof(gspca_dev, data, len);
if (sof) {
int n;
-
+ int marker_len = sizeof pac_sof_marker;
The value doesn't change; there's no need to use a variable for this.
True. I was just working for legibility, and trying to substitute a
shorter symbol for something which is long and cumbersome and screws up
80-character lines. If it is bad to do that, then I can take it right back
out, of course.
/* finish decoding current frame */
n = sof - data;
- if (n sizeof pac_sof_marker)
- n -= sizeof pac_sof_marker;
+ if (n marker_len)
+ n -= marker_len;
else
n = 0;
frame = gspca_frame_add(gspca_dev, LAST_PACKET, frame,
data, n);
- sd-header_read = 0;
- gspca_frame_add(gspca_dev, FIRST_PACKET, frame, NULL, 0);
- len -= sof - data;
+ /* Start next frame. */
+ gspca_frame_add(gspca_dev, FIRST_PACKET, frame,
+ pac_sof_marker, marker_len);
+ len -= n;
+ len -= marker_len;
+ if (len 0)
+ len = 0;
len -= sof - data; is a shorter way to find the remaining length.
Now, why did I try that and it did not work, but now it does? Weird. OK,
you are right.
data = sof;
}
- if (sd-header_read 7) {
- int needed;
-
- /* skip the rest of the header */
- needed = 7 - sd-header_read;
- if (len = needed) {
- sd-header_read += len;
- return;
- }
- data += needed;
- len -= needed;
- sd-header_read = 7;
- }
-
gspca_frame_add(gspca_dev, INTER_PACKET, frame, data, len);
}
@@ -337,6 +321,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x08ca, 0x0111)},
+ {USB_DEVICE(0x093a, 0x010f)},
This change is unrelated; maybe it should be in a different patch?
Suspecting that the main business of this patch is more urgent, I will
just take the other camera out, in that case. Then that is the next patch.
Don't
forget to update Documentation/video4linux/gspca.txt with the new camera.
Interesting. Sometimes previous experience is not a good guide. What I
learned is that one does not mess with someone else's stuff,
without consulting with the person who is (at least informally) in charge
of it, usually the person who wrote it. Example: In libgphoto2 I can add
a camera driver any time I want, and I could in theory go and mess with
any code anywhere in the tree, because I have commit privileges. But if
someone else is specializing in X (for example X = project documentation)
I will make suggestions to him, not just go and mess around in his work.
By analogy, I would not have even dreamed of going over into
linux/Documentation and started to mess with the contents of gspca.txt. I
am over here working on the code. So, gspca is a new project for me and
I see that things are done differently.
So, what you are also reminding me, is that it is my duty to do that for
the SQ905C cameras, too,
