Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Wednesday 04 March 2009 09:39:48 ext Hans Verkuil wrote: BTW, do I understand correctly that e.g. lens drivers also get their own /dev/videoX node? Please tell me I'm mistaken! Since that would be so very wrong. You're mistaken :) With the v4l2-int-interface/omap34xxcam camera driver one device node consists of all slaves (sensor, lens, flash, ...) making up the complete camera device. Phew! That's a relief. I got scared there for a moment :-) Regards, Hans I hope that the conversion to v4l2_subdev will take place soon. You are basically stuck in a technological dead-end :-( Ok :( - Tuukka -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
kilg...@banach.math.auburn.edu wrote:
Hans, Jean-Francois, and Kyle,
The proposed patches are not very long, so I will give each of them,
with my comments after each, to explain why I believe that these changes
are a good idea.
First, the patch to libv4lconvert is short and sweet:
contents of file mr97310av4l.patch follow
--
--- mr97310a.c.old2009-03-01 15:37:38.0 -0600
+++ mr97310a.c.new2009-02-18 22:39:48.0 -0600
@@ -102,6 +102,9 @@ void v4lconvert_decode_mr97310a(const un
if (!decoder_initialized)
init_mr97310a_decoder();
+/* remove the header */
+inp += 12;
+
bitpos = 0;
/* main decoding loop */
- here ends the v4lconvert patch --
The reason I want to do this should be obvious. It is to preserve the
entire header of each frame over in the gspca driver, and to throw it
away over here. The SOF marker FF FF 00 FF 96 is also kept. The reason
why all of this should be kept is that it makes it possible to look at a
raw output and to know if it is exactly aligned or not. Furthermore, the
next byte after the 96 is a code for the compression algorithm used, and
the bytes after that in the header might be useful in the future for
better image processing. In other words, these headers contain
information which might be useful in the future and they should not be
jettisoned in the kernel module.
+1
Now, the kernel module ought to keep and send along the header and SOF
marker instead of throwing them away. This is the topic of the next
patch. It also has the virtue of simplifying and shortening the code in
the module at the same time, because one is not going through
contortions to skip over and throw away some data which ought to be kept
anyway.
+1
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);
@@ -337,6 +325,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);
end of mr97310a.patch -
You will also notice that I have added a USB ID. As I have mentioned, I
have four cameras with this ID. The story with them is that two of them
will not work at all. The module will not initialize the camera. As far
as the other two of them are concerned, the module and the accompanying
change in libv4lconvert work very well. I have mentioned this
previously, and I did not get any comment about what is good to do. So
now I decided to submit the ID number in the patch.
Adding the USB-ID sounds like the right thing to do.
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
Kyle Guinn wrote: On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: snip Just a random thought, but maybe the pac207 driver can benefit from such a change as well? It could, but it is to late for that, the pac207 driver and corresponding libv4l functionality has been out there for 2 kernel releases now, so we cannot change that. Which also makes me wonder about the same change for the mr97310a, is that cam already supported in a released kernel ? If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid we cannot make these changes. In that case if we ever need to header data we need to define a new PIXFMT for mr97310a with the header data, and deprecate the old one. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 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 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: lifeview NOT LV3H not working
ciencio ha scritto: Hello, I bought the TV card in the object, it is a PCI hybrid TV-card, both analogue and DVB-T. I bought it, because on the manufacturer site they said they develop a linux driver, unfortunately when I downloaded the driver (which claims to be for fedora) I found the whole V4L tree to be compiled. By the way, I tried to compiled it but it failed 'because it looked for the 2.6.19 kernel sources while I'm on Ubuntu Intrepid with a 2.6.27. While I was trying to make the card work, I found a peculiar note in the NotOnlyTV faq that says that the driver they provide only works on Fedora 6.0. Since Fedora 6.0 is an old distro (Fedora is now at the 10th revision) and since on ubuntu intrepid, the distro I'm using, the 2.6.19 kernel isn't available, I wondered if and how I could manage to apply the modifications they did to the main tree to make the driver work on more recent kernels and if those modifications could be imported in the main tree. I attach the link to the V4l tree NOT provide is someone more expert than me wants have a look. http://www.notonlytv.net/download/driver/lv3hlv3afedora.rar And this is their faq (not very usefull indeed) http://www.notonlytv.net/download/faq/faq_lv3h.pdf Last thing, how can I know if someone is working on that card or on the chipset that card uses? -- Vic -- 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://udev.netup.ru/hg/v4l-dvb-netup
Mauro, Well, again didn't see my post... Never mind. After cleanups and fixes. Please pull from http://udev.netup.ru/hg/v4l-dvb-netup for the following 10 changesets: 01/10: Add init code for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=a671cee39c95 02/10: Add EEPROM code for NetUP Dual DVB-S2 CI card. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=9aebc98deef7 03/10: Add CIMax(R) SP2 Common Interface code for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=009a5c8af780 04/10: Add support for ST STV6110 silicon tuner. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=ea3c0d6fa7d3 05/10: Add support for ST LNBH24 LNB power controller. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=ba740eb2348e 06/10: Add headers for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=b3f0151f8b6d 07/10: Add more headers for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=208740992e6c 08/10: Add core code for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=69bf69e14207 09/10: Add support for ST STV0900 dual demodulator. http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=74dfadeb1162 10/10: Add support for NetUP Dual DVB-S2 CI card http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=e8ebbf5835b8 b/linux/drivers/media/dvb/frontends/lnbh24.h | 55 b/linux/drivers/media/dvb/frontends/stv0900.h | 62 b/linux/drivers/media/dvb/frontends/stv0900_core.c | 1961 ++ b/linux/drivers/media/dvb/frontends/stv0900_init.h | 439 ++ b/linux/drivers/media/dvb/frontends/stv0900_priv.h | 430 ++ b/linux/drivers/media/dvb/frontends/stv0900_reg.h | 3787 + b/linux/drivers/media/dvb/frontends/stv0900_sw.c | 2847 +++ b/linux/drivers/media/dvb/frontends/stv6110.c | 457 ++ b/linux/drivers/media/dvb/frontends/stv6110.h | 62 b/linux/drivers/media/video/cx23885/cimax2.c | 484 ++ b/linux/drivers/media/video/cx23885/cimax2.h | 47 b/linux/drivers/media/video/cx23885/netup-eeprom.c | 117 b/linux/drivers/media/video/cx23885/netup-eeprom.h | 42 b/linux/drivers/media/video/cx23885/netup-init.c | 125 b/linux/drivers/media/video/cx23885/netup-init.h | 25 linux/Documentation/video4linux/CARDLIST.cx23885 |1 linux/drivers/media/dvb/frontends/Kconfig | 18 linux/drivers/media/dvb/frontends/Makefile |3 linux/drivers/media/dvb/frontends/lnbp21.c | 41 linux/drivers/media/dvb/frontends/lnbp21.h | 50 linux/drivers/media/video/cx23885/Kconfig |1 linux/drivers/media/video/cx23885/Makefile |4 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 20 linux/drivers/media/video/cx23885/cx23885-dvb.c| 106 linux/drivers/media/video/cx23885/cx23885-reg.h|2 linux/drivers/media/video/cx23885/cx23885.h|3 27 files changed, 11215 insertions(+), 27 deletions(-) Thanks, Igor -- 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
Thomas Kaiser wrote: Hello Theodore kilg...@banach.math.auburn.edu wrote: Also, after the byte indicator for the compression algorithm there are some more bytes, and these almost definitely contain information which could be valuable while doing image processing on the output. If they are already kept and passed out of the module over to libv4lconvert, then it would be very easy to do something with those bytes if it is ever figured out precisely what they mean. But if it is not done now it would have to be done then and would cause even more trouble. I sent it already in private mail to you. Here is the observation I made for the PAC207 SOF some years ago: From usb snoop. FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00 1. xx: looks like random value 2. xx: changed from 0x03 to 0x0b 3. xx: changed from 0x06 to 0x49 4. xx: changed from 0x07 to 0x55 5. xx: static 0x96 6. xx: static 0x80 7. xx: static 0xa0 And I did play in Linux and could identify some fields :-) . In Linux the header looks like this: FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx F0 00 1. xx: don't know but value is changing between 0x00 to 0x07 2. xx: this is the actual pixel clock 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 Thomas And I forgot to say that the center brightness sensor was used to do auto brightness control in the old gspca driver. Pixel clock was changed on the fly to get better brightness in dark light conditions. 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
TerraTec Cinergy HT PCI
Dear all, I've this tv card that works with philips chipset. There is the possibility to have the remote controller working? I've made lot of research on the internet without positive result. Thank you all, Pablo -- 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
On Wed, Mar 04, 2009 at 01:43:08AM +0100, hermann pitton wrote: Hi, Am Montag, den 02.03.2009, 13:33 +0900 schrieb Dmitri Belimov: Hi All. I want use RDS on our TV cards. But now saa7134 not work with saa6588. I found this old patch from Hans J. Koch. Why this patch is not in mercurial?? Yes I know that patch for v4l ver.1 and for old kernel. But why not?? v4l has other way for RDS on saa7134 boards? I think the patch got lost, because it was not clear who should pull it in. Likely Hartmut or Mauro would have picked it up in 2006 if pinged directly. The main reason was that at that time there was a conflict with the i2c ir keyboard driver. I couldn't fix it immediately and was occupied with different things afterwards. I don't know if saa7134 i2c got fixed in the meantime. Please try to work with Hans to get it in now. There was also a suggestion to add a has_rds capability flag and about how to deal with different RDS decoders later, IIRC. Right. We should have a flag you could set to something like .has_rds = RDS_SAA6588 so that the rds driver could be loaded automagically. But I'm afraid I cannot spend much time on this work ATM, sorry. Thanks, 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: saa7134 and RDS
On Wed, Mar 04, 2009 at 01:43:08AM +0100, hermann pitton wrote: Hi, Am Montag, den 02.03.2009, 13:33 +0900 schrieb Dmitri Belimov: Hi All. I want use RDS on our TV cards. But now saa7134 not work with saa6588. I found this old patch from Hans J. Koch. Why this patch is not in mercurial?? Yes I know that patch for v4l ver.1 and for old kernel. But why not?? v4l has other way for RDS on saa7134 boards? I think the patch got lost, because it was not clear who should pull it in. Likely Hartmut or Mauro would have picked it up in 2006 if pinged directly. The main reason was that at that time there was a conflict with the i2c ir keyboard driver. I couldn't fix it immediately and was occupied with different things afterwards. I don't know if saa7134 i2c got fixed in the meantime. Please try to work with Hans to get it in now. There was also a suggestion to add a has_rds capability flag and about how to deal with different RDS decoders later, IIRC. Right. We should have a flag you could set to something like .has_rds = RDS_SAA6588 so that the rds driver could be loaded automagically. But I'm afraid I cannot spend much time on this work ATM, sorry. Thanks, Hans 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. 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. I'll see if I can get the patch merged anyway. 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
[Resubmit] [PATCH] v4l/bttv Add support to the GeoVision GV-800(S)
Hello all, I have a GeoVision GV-800(S) card, it has 4 CONEXANT BT878A chips. It has 16 video inputs and 4 audio inputs, and it is almost identical to the GV-800, as seen on http://bttv-gallery.de . The only difference appears to be the analog mux, it has a CD22M3494 in place of the MT8816AP. The card has a blue PCB, as seen in this picture: http://www.gsbr.com.br/imagem/kits/GeoVision%20GV%20800.jpg . This card wasn't originally supported, and it was detected as UNKNOWN/GENERIC. The video inputs weren't working, so I tried forcing a few cards like the GeoVision GV-600, but there was still no video. So I made a patch to support this card, based on the Kodicom 4400r. The GV-800(S) is identified as follows: # lspci ... 02:00.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 02:04.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:04.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 02:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) 02:0c.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) 02:0c.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) # lspci -nv ... 02:00.0 0400: 109e:036e (rev 11) Subsystem: 800a:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdfff000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:00.1 0480: 109e:0878 (rev 11) Subsystem: 800a:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffe000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 02:04.0 0400: 109e:036e (rev 11) Subsystem: 800b:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffd000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:04.1 0480: 109e:0878 (rev 11) Subsystem: 800b:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffc000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 02:08.0 0400: 109e:036e (rev 11) Subsystem: 800c:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffb000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:08.1 0480: 109e:0878 (rev 11) Subsystem: 800c:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdffa000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 02:0c.0 0400: 109e:036e (rev 11) Subsystem: 800d:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdff9000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Kernel modules: bttv 02:0c.1 0480: 109e:0878 (rev 11) Subsystem: 800d:763d Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at cdff8000 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 As you can see, the GV-800(S) card is almost identical to the GV-800 on bttv-gallery, so this patch might also work for that card. If not, only a few changes should be required on the gv800s_write() function. After this patch, the video inputs work correctly on linux 2.6.24 and 2.6.27 using the software 'motion'. The input order may seem a little odd, but it's the order the original software/driver uses, and I decided to keep that order to get the most out of the card. I tried to get the audio working with the snd-bt87x module, but I only get noise from every audio input, even after selecting a different mux with alsamixer. Also, after trying to play sound from those sources, I randomly get a RISC error about an invalid RISC opcode, and then that output stops working. I also can't change the sampling rate when recording. Any pointers to adding audio support are welcome. This mail was sent using Evolution as described in email-clients.txt, I hope the tabs/spaces are now ok. Signed-off-by: Bruno Christo bchri...@inf.ufsm.br --- diff --git a/linux/Documentation/video4linux/CARDLIST.bttv b/linux/Documentation/video4linux/CARDLIST.bttv --- a/linux/Documentation/video4linux/CARDLIST.bttv
Cleanup of dvb frontend driver header files
Hi there! While having a look at lnbp21.h I have seen it includes linux/dvb/frontend.h without needing it. (There are only pointers referring to struct dvb_frontend). So I had a look at the whole directory. # cd linux/drivers/media/dvb/frontends # grep -l linux/dvb/frontend.h *.h|wc -l 47 So 47 header files include this header and seem not to need it. At least removing this line still allows me to compile the full set of v4l-dvb drivers. # sed -e '/linux\/dvb\/frontend/s-^-// -' -i *.h Some of these files use more headers the same way like dvb_frontend.h, firmware.h or i2c.h Is this kind of cleanup appreciated, or should the includes be kept even if they are not really needed for pointers to structs like dvb_frontend. Regards Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] MT9P012: Add driver
Hi,
not looking at v4l2 part since it's not my area...
On Tue, Mar 03, 2009 at 09:44:14PM +0100, ext Aguirre Rodriguez, Sergio Alberto
wrote:
+#define SENSOR_DETECTED1
+#define SENSOR_NOT_DETECTED0
these two should be unneeded...
+
+/**
+ * struct mt9p012_reg - mt9p012 register format
+ * @length: length of the register
+ * @reg: 16-bit offset to register
+ * @val: 8/16/32-bit register value
+ *
+ * Define a structure for MT9P012 register initialization values
+ */
+struct mt9p012_reg {
+ u16 length;
+ u16 reg;
+ u32 val;
+};
+
+enum image_size {
+ BIN4XSCALE,
+ BIN4X,
+ BIN2X,
+ THREE_MP,
+ FIVE_MP
you probably wanna prefix these with MT9P012_ to avoid namespace
conflicts.
+};
+
+enum pixel_format {
+ RAWBAYER10
+};
+
+#define NUM_IMAGE_SIZES5
+#define NUM_PIXEL_FORMATS 1
+#define NUM_FPS2 /* 2 ranges */
+#define FPS_LOW_RANGE 0
+#define FPS_HIGH_RANGE 1
+
+/**
+ * struct capture_size - image capture size information
+ * @width: image width in pixels
+ * @height: image height in pixels
+ */
+struct capture_size {
+ unsigned long width;
+ unsigned long height;
+};
+
+/**
+ * struct mt9p012_pll_settings - struct for storage of sensor pll values
+ * @vt_pix_clk_div: vertical pixel clock divider
+ * @vt_sys_clk_div: veritcal system clock divider
+ * @pre_pll_div: pre pll divider
+ * @fine_int_tm: fine resolution interval time
+ * @frame_lines: number of lines in frame
+ * @line_len: number of pixels in line
+ * @min_pll: minimum pll multiplier
+ * @max_pll: maximum pll multiplier
+ */
+struct mt9p012_pll_settings {
+ u16 vt_pix_clk_div;
+ u16 vt_sys_clk_div;
+ u16 pre_pll_div;
+
+ u16 fine_int_tm;
+ u16 frame_lines;
+ u16 line_len;
+
+ u16 min_pll;
+ u16 max_pll;
+};
+
+/*
+ * Array of image sizes supported by MT9P012. These must be ordered from
+ * smallest image size to largest.
+ */
+const static struct capture_size mt9p012_sizes[] = {
+ { 216, 162 }, /* 4X BINNING+SCALING */
+ { 648, 486 }, /* 4X BINNING */
+ { 1296, 972 }, /* 2X BINNING */
+ { 2048, 1536}, /* 3 MP */
+ { 2592, 1944}, /* 5 MP */
+};
+
+/* PLL settings for MT9P012 */
+enum mt9p012_pll_type {
+ PLL_5MP = 0,
+ PLL_3MP,
+ PLL_1296_15FPS,
+ PLL_1296_30FPS,
+ PLL_648_15FPS,
+ PLL_648_30FPS,
+ PLL_216_15FPS,
+ PLL_216_30FPS
+};
missing tabs, fix identation.
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-1));
if it's a bool it's not debug level, it's debug on/off switch :-p
+static struct mt9p012_sensor mt9p012;
+static struct i2c_driver mt9p012sensor_i2c_driver;
unneeded.
+static unsigned long xclk_current = MT9P012_XCLK_NOM_1;
why ??
+static int
+find_vctrl(int id)
I guess it fits in one line...
+static int
+mt9p012_read_reg(struct i2c_client *client, u16 data_length, u16 reg, u32
*val)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[4];
+
+ if (!client-adapter)
+ return -ENODEV;
+ if (data_length != MT9P012_8BIT data_length != MT9P012_16BIT
+data_length != MT9P012_32BIT)
+ return -EINVAL;
+
+ msg-addr = client-addr;
+ msg-flags = 0;
+ msg-len = 2;
+ msg-buf = data;
+
+ /* high byte goes out first */
+ data[0] = (u8) (reg 8);;
+ data[1] = (u8) (reg 0xff);
+ err = i2c_transfer(client-adapter, msg, 1);
+ if (err = 0) {
+ msg-len = data_length;
+ msg-flags = I2C_M_RD;
+ err = i2c_transfer(client-adapter, msg, 1);
+ }
+ if (err = 0) {
+ *val = 0;
+ /* high byte comes first */
+ if (data_length == MT9P012_8BIT)
+ *val = data[0];
+ else if (data_length == MT9P012_16BIT)
+ *val = data[1] + (data[0] 8);
+ else
+ *val = data[3] + (data[2] 8) +
+ (data[1] 16) + (data[0] 24);
+ return 0;
+ }
+ dev_err(client-dev, read from offset 0x%x error %d, reg, err);
doesn't this chip support smbus ?? It would be a lot simpler if it
does... :-s
+static int ioctl_s_power(struct v4l2_int_device *s, enum v4l2_power on)
+{
+ struct mt9p012_sensor *sensor = s-priv;
+ struct i2c_client *c = sensor-i2c_client;
+ int rval;
+
+ if ((on == V4L2_POWER_STANDBY) (sensor-state == SENSOR_DETECTED))
+ mt9p012_write_regs(c, stream_off_list);
+
+ if (on != V4L2_POWER_ON)
+
Re: saa7134 and RDS
Hi On Wed, Mar 04, 2009 at 01:43:08AM +0100, hermann pitton wrote: Hi, Am Montag, den 02.03.2009, 13:33 +0900 schrieb Dmitri Belimov: Hi All. I want use RDS on our TV cards. But now saa7134 not work with saa6588. I found this old patch from Hans J. Koch. Why this patch is not in mercurial?? Yes I know that patch for v4l ver.1 and for old kernel. But why not?? v4l has other way for RDS on saa7134 boards? I think the patch got lost, because it was not clear who should pull it in. Likely Hartmut or Mauro would have picked it up in 2006 if pinged directly. The main reason was that at that time there was a conflict with the i2c ir keyboard driver. I couldn't fix it immediately and was occupied with different things afterwards. I don't know if saa7134 i2c got fixed in the meantime. Please try to work with Hans to get it in now. There was also a suggestion to add a has_rds capability flag and about how to deal with different RDS decoders later, IIRC. Right. We should have a flag you could set to something like .has_rds = RDS_SAA6588 so that the rds driver could be loaded automagically. But I'm afraid I cannot spend much time on this work ATM, sorry. Thanks, Hans 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. Regards, Hans With my best regards, Dmitry. -- 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] Typo in lnbp21.c / changeset: 10800:ba740eb2348e
On 4 марта 2009, linux-media@vger.kernel.org wrote: Hi there! lnbp21 does show strange messages at depmod. WARNING: Loop detected: /lib/modules/2.6.28-tuxonice-r1/v4l/lnbp21.ko which needs lnbp21.ko again! WARNING: Module /lib/modules/2.6.28-tuxonice-r1/v4l/lnbp21.ko ignored, due to loop So I had a look at latest change and noticed there was a typo in the function name, it should be lnbh24_attach, and not lnbp24_attach I guess. The attached patch fixes this. Regards Matthias Hi Matthias Yes, You are right. What an unfortunate misprint and lack of attention from my side :( I confirm your patch. Mauro, please apply this patch. Best Regards Igor -- 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] Typo in lnbp21.c / changeset: 10800:ba740eb2348e
On Wed, 4 Mar 2009 14:40:33 +0200 Igor M. Liplianin liplia...@me.by wrote: On 4 марта 2009, linux-media@vger.kernel.org wrote: Hi there! lnbp21 does show strange messages at depmod. WARNING: Loop detected: /lib/modules/2.6.28-tuxonice-r1/v4l/lnbp21.ko which needs lnbp21.ko again! WARNING: Module /lib/modules/2.6.28-tuxonice-r1/v4l/lnbp21.ko ignored, due to loop So I had a look at latest change and noticed there was a typo in the function name, it should be lnbh24_attach, and not lnbp24_attach I guess. The attached patch fixes this. Regards Matthias Hi Matthias Yes, You are right. What an unfortunate misprint and lack of attention from my side :( I confirm your patch. Mauro, please apply this patch. You forgot to attach the patch. Best Regards Igor Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Typo in lnbp21.c / changeset: 10800:ba740eb2348e
В сообщении от 4 March 2009 15:02:44 Mauro Carvalho Chehab написал(а): On Wed, 4 Mar 2009 14:40:33 +0200 Igor M. Liplianin liplia...@me.by wrote: On 4 п╪п╟я─я┌п╟ 2009, linux-media@vger.kernel.org wrote: Hi there! lnbp21 does show strange messages at depmod. WARNING: Loop detected: /lib/modules/2.6.28-tuxonice-r1/v4l/lnbp21.ko which needs lnbp21.ko again! WARNING: Module /lib/modules/2.6.28-tuxonice-r1/v4l/lnbp21.ko ignored, due to loop So I had a look at latest change and noticed there was a typo in the function name, it should be lnbh24_attach, and not lnbp24_attach I guess. The attached patch fixes this. Regards Matthias Hi Matthias Yes, You are right. What an unfortunate misprint and lack of attention from my side :( I confirm your patch. Mauro, please apply this patch. You forgot to attach the patch. Best Regards Igor 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 Mauro, That was correct pull request to fix typo. Please pull from http://udev.netup.ru/hg/v4l-dvb-netup for the following changeset: 01/01: Fix typo in lnbp21.c http://udev.netup.ru/hg/v4l-dvb-netup?cmd=changeset;node=19f5b50ab3d6 lnbp21.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, Igor -- 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
TT S2-3200 and CAMs
Hi, I've been testing the TT S2-3200 card and while it performs well for FTA services I have been unable to get it working with encrypted services using the CI slot. With VLC I am able to tune to the transponder and pick up all the services but they are not decrypted, unencrypted services work fine. Using a DVB-S card with CI I am able to tune successfully, proving the CAMs are valid. This leads me to believe there may be a problem with the drivers for the S2-3200. Has anyone managed to get CAMs working with this card? Any advice gratefully recieved. Many thanks, Lou -- Lou Otway mailto:lot...@nildram.co.uk -- 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
identifying camera sensor
Hi, I am writing a generic driver for SMIA-compatible sensors. SMIA-sensors have registers containing: u16 model_id u16 revision_number u8 manufacturer_id which could be used to detect the sensor. However, since the driver is generic, it is not interested of these values. Nevertheless, in some cases user space applications want to know the exact chip. For example, to get the highest possible image quality, user space application might capture an image and postprocess it using sensor-specific filtering algorithms (which don't belong into kernel driver). I am planning to export the chip identification information to user space using VIDIOC_DBG_G_CHIP_IDENT. Here's a sketch: #define V4L2_IDENT_SMIA_BASE (0x53 24) then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler: struct v4l2_dbg_chip_ident id; id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id 16) | model_id; id.revision = revision_number; Do you think this is acceptable? 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? I'll start writing a patch as soon as you let me know which would be the best alternative. Thanks! - Tuukka -- 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] good card express for video
I've been attempting to use an HVR-1500q expresscard in linux. The development of the driver looks promising. The trouble is that I am currently living in a fairly remote valley where there is no TV reception, so I can't actually tell if the ATSC or NTSC tuners are working. I'll be spending next week near some larger cities so I will be able to test it further. All I can tell you now is that the card is detected correctly and the firmware appears to load properly. On Wed, Mar 4, 2009 at 02:12, djamil dja...@djamil.net wrote: Hi guys I v been waititng on analog support for HVR1400 with no luck can anyone tell me if there is a card similar working fully under linux, i mean , hybrid, hd, and analog inputs as an express card, the successor of pcmcia thnx in advance ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: [Camera] identifying camera sensor
Hi, Some sensor ID is definitely needed at least for Camera daemon and iCapture to load the appropriate tuning data. Ivan can comment which the preferable approach. Best regards, RADO -Original Message- From: camera-boun...@ok.research.nokia.com [mailto:camera-boun...@ok.research.nokia.com] On Behalf Of Tuukka.O Toivonen Sent: Wednesday, March 04, 2009 4:13 PM To: ext Hans Verkuil Cc: cam...@ok.research.nokia.com; linux-media@vger.kernel.org Subject: [Camera] identifying camera sensor Hi, I am writing a generic driver for SMIA-compatible sensors. SMIA-sensors have registers containing: u16 model_id u16 revision_number u8 manufacturer_id which could be used to detect the sensor. However, since the driver is generic, it is not interested of these values. Nevertheless, in some cases user space applications want to know the exact chip. For example, to get the highest possible image quality, user space application might capture an image and postprocess it using sensor-specific filtering algorithms (which don't belong into kernel driver). I am planning to export the chip identification information to user space using VIDIOC_DBG_G_CHIP_IDENT. Here's a sketch: #define V4L2_IDENT_SMIA_BASE (0x53 24) then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler: struct v4l2_dbg_chip_ident id; id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id 16) | model_id; id.revision = revision_number; Do you think this is acceptable? 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? I'll start writing a patch as soon as you let me know which would be the best alternative. Thanks! - Tuukka ___ Camera mailing list cam...@ok.research.nokia.com http://ok.research.nokia.com/cgi-bin/mailman/listinfo/camera -- 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
Hi Tuukka, Hi, I am writing a generic driver for SMIA-compatible sensors. SMIA-sensors have registers containing: u16 model_id u16 revision_number u8 manufacturer_id which could be used to detect the sensor. However, since the driver is generic, it is not interested of these values. Nevertheless, in some cases user space applications want to know the exact chip. For example, to get the highest possible image quality, user space application might capture an image and postprocess it using sensor-specific filtering algorithms (which don't belong into kernel driver). I am planning to export the chip identification information to user space using VIDIOC_DBG_G_CHIP_IDENT. Here's a sketch: #define V4L2_IDENT_SMIA_BASE(0x53 24) then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler: struct v4l2_dbg_chip_ident id; id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id 16) | model_id; id.revision = revision_number; Do you think this is acceptable? This ioctl is meant for debugging only. It's API can change without notice (hence the 'DBG' part in the name and the warnings in the v4l2 spec). In fact, it did change recently. The only application using it is v4l2-dbg, which is a tool that allows you to read and write registers on the fly. Very useful for debugging. It is also used internally in the kernel if the adapter driver needs to do different things depending on the actual chip used. So it is *not* acceptable to use this API in a generic application (i.e. an app that can be used for all sorts of different hardware). However, on an embedded system where you control the environment I have no objection if someone uses it in a custom application. They should be aware though that this API can change in a future kernel. But since they control the kernel version as well that shouldn't pose a problem. 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 :-) I'll start writing a patch as soon as you let me know which would be the best alternative. Thanks! 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. 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 : TT S2-3200 and CAMs
Le 04.03.2009 10:09:55, Lou Otway a écrit : Hi, I've been testing the TT S2-3200 card and while it performs well for FTA services I have been unable to get it working with encrypted services using the CI slot. With VLC I am able to tune to the transponder and pick up all the services but they are not decrypted, unencrypted services work fine. Using a DVB-S card with CI I am able to tune successfully, proving the CAMs are valid. This leads me to believe there may be a problem with the drivers for the S2-3200. Has anyone managed to get CAMs working with this card? Any advice gratefully recieved. Many thanks, Yes, you can look for a few threads for this in the archives. HTH Bye Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 0/9] OMAP3 ISP and camera drivers
Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sakari Ailus Sent: Tuesday, March 03, 2009 3:37 PM To: linux-media@vger.kernel.org; linux-o...@vger.kernel.org Cc: Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka Olli Artturi; Hiroshi DOYU; DongSoo Kim Subject: [RFC 0/9] OMAP3 ISP and camera drivers Hi, So here's the patchset for OMAP 3 ISP and camera drivers plus the associated V4L changes. Sergio Aguirre has been posting a related patchset earlier, containing also sensor and lens driver used on SDP. This patchset is agains the linux-omap tree: URL:http://www.muru.com/linux/omap/README_OMAP_GIT [Hiremath, Vaibhav] Sakari, Let me ask you basic question, have you tested/verified these patch-sets? The reason I am asking this question is, for me it was not working. I had to debug this and found that - - Changes missing in devices.c file, so isp_probe function will not be called at all, keeping omap3isp = NULL. You will end up into kernel crash in omap34xxcam_device_register. - The patches from Hiroshi DOYU doesn't build as is, you need to add one include line #include linux/hardirq.h in iovmmu.c (I am using the patches submitted on 16th Jan 2009) I have attached git diff output here with this mail for reference. Am I missing any patches here? I am not sure how Sergio is able to use these patches? If I am not missing anything, then I think you should mention all these issues clearly in the patch so that anybody who might want to use will not suffer. So I and Sergio have synchronised our versions of the ISP and camera drivers and this is the end result. There is still a lot of work to do, though. You can find some comments in individual patch descriptions. If the todo list for a patch is empty it doesn't mean there wouldn't be anything left to do. ;) There's at least one major change to Sergio Aguirre's earlier patches which is that the ISP driver now uses the IOMMU from Hiroshi Doyu. Hiroshi is away for some time now so there are just some hacks on top of Hiroshi's older iommu patches to use with current linux-omap. This patchset does not contain the resizer or preview wrappers from TI but they have been left intentionally out. A proper interface (V4L) should be used for those and the camera driver should be somehow involved --- the wrappers are just duplicating much of the camera driver's functionality. I don't have any sensor or lens drivers to publish at this time. This patchset should work with the SDP and OMAPZoom boards although you need the associated sensor drivers + the board code from Sergio Aguirre to use it. You'll also need the IOMMU patchset from Hiroshi Doyu. Everything except the sensor / board stuff is available here: URL:http://www.gitorious.org/projects/omap3camera In short, on linux-omap: $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \ iommu omap3camera base Hiroshi's original iommu tree is here (branch iommu): URL:http://git.gitorious.org/lk/mainline.git Some of the camera and ISP driver development history is available, too. See the first link. Any feedback is appreciated. Sincerely, -- 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 isp_patch_fix.patch Description: isp_patch_fix.patch
RE: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
From: stanley.miao [mailto:stanley.m...@windriver.com] Aguirre Rodriguez, Sergio Alberto wrote: This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. - OMAP3 ISP and camera drivers patch series, posted by Sakari Ailus on March 3rd. (Please follow his instructions to pull from gitorious.org server) This has been tested with: - SDP3430-VG5.0.1 with OMAP3430-ES3.1 daughter board upgrade. - Camkit V3.0.1 with MT9P012 and OV3640 sensors - LDP with OV3640 sensor Sergio Aguirre (5): MT9P012: Add driver DW9710: Add driver OV3640: Add driver Hi, Sergio, You forgot to send the 3rd patch, OV3640: Add driver. Hmm, weird... I'm sure I have sent the 5 patches to both linux-omap and linux-media MLs... But, according to http://patchwork.kernel.org/ linux- omap didn't receive that patch you're telling me... Anyways, resending that last patch to linux-omap only. Thanks for the interest. Stanley, I don't know why this patch is not making it... I resent it twice now, and it doesn't arrive to the list... Tony, Is this patch OV3640: Add driver being held on a mail filter somewhere? Regards, Sergio Stanley. OMAP3430SDP: Add support for Camera Kit v3 LDP: Add support for built-in camera -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] media/dm1105: uses ir_* functions, select VIDEO_IR
From: Randy Dunlap randy.dun...@oracle.com dm1105 uses the ir_*() functions, so it needs to select VIDEO_IR to avoid build errors: dm1105.c:(.text+0x26b7ac): undefined reference to `ir_input_keydown' dm1105.c:(.text+0x26b7bc): undefined reference to `ir_input_nokey' (.devinit.text+0x29982): undefined reference to `ir_codes_dm1105_nec' (.devinit.text+0x2998a): undefined reference to `ir_input_init' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/dvb/dm1105/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20090304.orig/drivers/media/dvb/dm1105/Kconfig +++ linux-next-20090304/drivers/media/dvb/dm1105/Kconfig @@ -8,6 +8,7 @@ config DVB_DM1105 select DVB_STB6000 if !DVB_FE_CUSTOMISE select DVB_CX24116 if !DVB_FE_CUSTOMISE select DVB_SI21XX if !DVB_FE_CUSTOMISE + select VIDEO_IR help Support for cards based on the SDMC DM1105 PCI chip like DvbWorld 2002 -- 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
Hans, On Mon, 2 Mar 2009 22:18:24 +0100 Hans Verkuil hverk...@xs4all.nl wrote: In the final analysis I'm the boss of my own time. And I've decided that once the conversion of all the i2c modules is finished I'll stop spending time on the compatibility code for kernels 2.6.22 as it is simply no longer an effective use of my time. If someone else wants to spend time on that, then that's great and I will of course answer questions or help in whatever way is needed. I know that Mauro thinks he can keep the backwards compat code in by doing nifty code transformations. It would be nice if he succeeds (and I have no doubt that it is possible given enough time and effort), but personally I think it is time better spent elsewhere. It required just a couple of hours today, in order to add the I2C conversion rules on the backport tree: http://linuxtv.org/hg/~mchehab/backport/ There, I used, as example, the tea6415c.c file that you sent me, meant to be an example of a driver converted to use just the new I2C API. I've removed from it all the other #ifdefs for 2.6.26, so, the module doesn't have any compat bits (except for compat.h that can also be handled by the script). I didn't compile the entire tree, since several drivers will break, as they aren't ported yet to the new I2C style. Maybe a few adjustments on the backport.pl may be needed, after having all drivers converted to 2.6.22, since the final version may need some other patching rules. That's said, the backport tree is still an experimental work. The scripts require more time to be tested, and the Makefiles need some cleanups. 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. Cheers, Mauro -- PS: the tea6415c.c fully ported to the new I2C API you sent in priv doesn't compile fine with 2.6.28. Since this file is just an example, I didn't care to fix 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
Re: TT S2-3200 and CAMs
Lou Otway wrote: Hi, I've been testing the TT S2-3200 card and while it performs well for FTA services I have been unable to get it working with encrypted services using the CI slot. With VLC I am able to tune to the transponder and pick up all the services but they are not decrypted, unencrypted services work fine. Using a DVB-S card with CI I am able to tune successfully, proving the CAMs are valid. This leads me to believe there may be a problem with the drivers for the S2-3200. Has anyone managed to get CAMs working with this card? yes, I manage to decrypt a entire dvb-s transponder using a powercam and mumudvb for streaming channels. I'm using the v4l-dvb driver from the hg repository. For mumudvb, I made a checkout of the git repository http://mumudvbgit.braice.net/mumudvb.git and compiled the source with LIBDVBEN50221=1 make (you need the dvb-apps to be installed) But using this card, I didn't manage to lock on my second lnd head, so I manage to lock on astra 19.2E but not on hotbird 13.0E. Pierre Any advice gratefully recieved. Many thanks, Lou -- Lou Otway mailto:lot...@nildram.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and RDS
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
diff -r 54ae11f1e777 linux/drivers/media/video/saa6588.c
--- a/linux/drivers/media/video/saa6588.c Wed Feb 11 23:28:30 2009 +0100
+++ b/linux/drivers/media/video/saa6588.c Fri Feb 13 09:07:20 2009 +0100
@@ -541,7 +541,6 @@
.command = saa6588_command,
.probe = saa6588_probe,
.remove = saa6588_remove,
- .legacy_class = I2C_CLASS_TV_ANALOG,
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 26)
.id_table = saa6588_id,
#endif
diff -r 54ae11f1e777 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Wed Feb 11 23:28:30 2009 +0100
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Feb 13 09:07:20 2009 +0100
@@ -1699,6 +1699,7 @@
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
+ .rds_addr = 0x10,
.tda9887_conf = TDA9887_PRESENT,
.inputs = {{
.name = name_tv,
diff -r 54ae11f1e777 linux/drivers/media/video/saa7134/saa7134-core.c
--- a/linux/drivers/media/video/saa7134/saa7134-core.c Wed Feb 11 23:28:30 2009 +0100
+++ b/linux/drivers/media/video/saa7134/saa7134-core.c Fri Feb 13 09:07:20 2009 +0100
@@ -1050,6 +1050,17 @@
sd-grp_id = GRP_EMPRESS;
}
+ if (saa7134_boards[dev-board].rds_addr) {
+ unsigned short addrs[2] = { 0, I2C_CLIENT_END };
+ struct v4l2_subdev *sd;
+
+ addrs[0] = saa7134_boards[dev-board].rds_addr;
+ sd = v4l2_i2c_new_probed_subdev(dev-i2c_adap, saa6588,
+ saa6588, addrs);
+ if (sd)
+ printk(KERN_INFO %s: found RDS decoder\n, dev-name);
+ }
+
request_submodules(dev);
v4l2_prio_init(dev-prio);
diff -r 54ae11f1e777 linux/drivers/media/video/saa7134/saa7134-video.c
--- a/linux/drivers/media/video/saa7134/saa7134-video.c Wed Feb 11 23:28:30 2009 +0100
+++ b/linux/drivers/media/video/saa7134/saa7134-video.c Fri Feb 13 09:07:20 2009 +0100
@@ -30,6 +30,7 @@
#include saa7134-reg.h
#include saa7134.h
#include media/v4l2-common.h
+#include media/rds.h
#ifdef CONFIG_VIDEO_V4L1_COMPAT
/* Include V4L1 specific functions. Should be removed soon */
@@ -1467,6 +1468,7 @@
{
struct saa7134_fh *fh = file-private_data;
struct saa7134_dev *dev = fh-dev;
+ struct rds_command cmd;
unsigned long flags;
/* turn off overlay */
@@ -1500,6 +1502,8 @@
saa_andorb(SAA7134_OFMT_DATA_B, 0x1f, 0);
saa_call_all(dev, core, s_standby, 0);
+ if (fh-radio)
+ saa_call_all(dev, core, ioctl, RDS_CMD_CLOSE, cmd);
/* free stuff */
videobuf_mmap_free(fh-cap);
@@ -1518,6 +1522,37 @@
struct saa7134_fh *fh = file-private_data;
return videobuf_mmap_mapper(saa7134_queue(fh), vma);
+}
+
+static ssize_t radio_read(struct file *file, char __user *data,
+ size_t count, loff_t *ppos)
+{
+ struct saa7134_fh *fh = file-private_data;
+ struct saa7134_dev *dev = fh-dev;
+ struct rds_command cmd;
+
+ cmd.block_count = count/3;
+ cmd.buffer = data;
+ cmd.instance = file;
+ cmd.result = -ENODEV;
+
+ saa_call_all(dev, core, ioctl, RDS_CMD_READ, cmd);
+
+ return cmd.result;
+}
+
+static unsigned int radio_poll(struct file *file, poll_table *wait)
+{
+ struct saa7134_fh *fh = file-private_data;
+ struct saa7134_dev *dev = fh-dev;
+ struct rds_command cmd;
+
+ cmd.instance = file;
+ cmd.event_list = wait;
+ cmd.result = -ENODEV;
+ saa_call_all(dev, core, ioctl, RDS_CMD_POLL, cmd);
+
+ return cmd.result;
}
/* -- */
@@ -2451,8 +2486,10 @@
static const struct v4l2_file_operations radio_fops = {
.owner = THIS_MODULE,
.open = video_open,
+ .read = radio_read,
.release = video_release,
.ioctl = video_ioctl2,
+ .poll = radio_poll,
};
static const struct v4l2_ioctl_ops radio_ioctl_ops = {
diff -r 54ae11f1e777 linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h Wed Feb 11 23:28:30 2009 +0100
+++ b/linux/drivers/media/video/saa7134/saa7134.h Fri Feb 13 09:07:20 2009 +0100
@@ -326,6 +326,7 @@
unsigned int radio_type;
unsigned char tuner_addr;
unsigned char radio_addr;
+
Re: [linux-dvb] good card express for video
oops i use pal-secam , not ntsc :) but thnx! Le mercredi 04 mars 2009 à 09:38 -0500, Matthew Gardeski a écrit : I've been attempting to use an HVR-1500q expresscard in linux. The development of the driver looks promising. The trouble is that I am currently living in a fairly remote valley where there is no TV reception, so I can't actually tell if the ATSC or NTSC tuners are working. I'll be spending next week near some larger cities so I will be able to test it further. All I can tell you now is that the card is detected correctly and the firmware appears to load properly. On Wed, Mar 4, 2009 at 02:12, djamil dja...@djamil.net wrote: Hi guys I v been waititng on analog support for HVR1400 with no luck can anyone tell me if there is a card similar working fully under linux, i mean , hybrid, hd, and analog inputs as an express card, the successor of pcmcia thnx in advance ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pxa_camera: Redesign DMA handling
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
(moved to the new v4l list)
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.
Could you please describe where and how the order could get wrong?
Sorry, I missed that point in the previous reply.
It's still the same bit of code :
- } else {
- buf_dma-sg_cpu[nents].ddadr =
- DDADR(pcdev-dma_chans[i]);
That chains the end of the queued buffer to the active buffer (probably the one
running in DMA chain [1]). So we'll get images in the following order:
queued_buffer, then active_buffer (head of pcdev-capture), then others.
The desired order is :
active_buffer (head of pcdev-capture), then others, then queued_buffer.
- multiple buffers DMA starting
When multiple buffers were queued, the DMA channels were
You mean multiple scatter-gather elements?
No, I mean multiple video buffers.
Multiple scatter-gather elements form one video buffer, and multiple video
buffers are queued to form a list of images (video stream).
Cheers.
--
Robert
[1] I mean _probably_, because the DMA chain can be already ahead of 1 buffer
(we're talking in terms of PXA cycles, which is very hard to watch), while
active pointer is not yet updated.
--
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: Cleanup of dvb frontend driver header files
On Wed, 4 Mar 2009 11:36:26 +0100 Matthias Schwarzott z...@gentoo.org wrote: Hi there! While having a look at lnbp21.h I have seen it includes linux/dvb/frontend.h without needing it. (There are only pointers referring to struct dvb_frontend). So I had a look at the whole directory. # cd linux/drivers/media/dvb/frontends # grep -l linux/dvb/frontend.h *.h|wc -l 47 So 47 header files include this header and seem not to need it. At least removing this line still allows me to compile the full set of v4l-dvb drivers. # sed -e '/linux\/dvb\/frontend/s-^-// -' -i *.h Some of these files use more headers the same way like dvb_frontend.h, firmware.h or i2c.h Is this kind of cleanup appreciated, or should the includes be kept even if they are not really needed for pointers to structs like dvb_frontend. This kind of cleanup is appreciated, since it reduces the compilation time of the kernel. Some care should be taken, however, since a few headers are required on other architectures, or may be needed, depending on the enabled CONFIG options. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wed, 4 Mar 2009, Hans de Goede wrote: Kyle Guinn wrote: On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote: snip Just a random thought, but maybe the pac207 driver can benefit from such a change as well? It could, but it is to late for that, the pac207 driver and corresponding libv4l functionality has been out there for 2 kernel releases now, so we cannot change that. Pretty much what I said. It would have been better so, but done is done. Which also makes me wonder about the same change for the mr97310a, is that cam already supported in a released kernel ? Someone else may know better than I do, but since it was only added quite recently, surely not? If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid we cannot make these changes. In that case if we ever need to header data we need to define a new PIXFMT for mr97310a with the header data, and deprecate the old one. I do not quite understand. Why not just do it right away. especially if this has not appeared yet in any kernel? 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: [PATCH] to gspca, to support SQ905C cameras.
On Tue, 3 Mar 2009 13:54:59 -0600 (CST) kilg...@banach.math.auburn.edu wrote: The SQ905C cameras (0x2770:0x905C) cameras, as well as two other closely related varieties (0x2770:0x9050 and 0x2770:0x913D) are supported in what follows. Please check your patch with checkpatch.pl. There are lots of troubles, maybe some introduced by your emailer, since you have tons of whitespace issues. These cameras are the successors in the marketplace of the SQ905 cameras. They are similar to the SQ905 cameras, in that they use bulk transport while streaming, and thus the driver functions similarly, using a workqueue to perform the streaming. However, there are also some serious differences. These differences include -- a different structure of the commands -- commands do not pass a data byte to the camera -- commands do not require a subsequent read operation -- while streaming, there are no commands sent during a frame download, nor is there an ack between frames. Thus, the only command sent during streaming is a command to quit streaming. -- frame header is of a different size -- the SQ905C cameras all stream compressed data, whereas the data for the older SQ905 cameras is not compressed -- since compressed frames are of variable size, the frame header is read first and contains the data size for the coming frame -- the supported resolution settings are different I should also mention that the introduction of support for these cameras requires an additional fourcc code to be introduced in linux/include/linux/videodev2.h, and the addition of the decompression algorithm in libv4lconvert. I have submitted the libv4lconvert patch a couple of days ago. The code in the new sq905c.c is based upon the structure of the code in gspca/sq905.c, and upon the code in libgphoto2/camlibs/digigr8, which supports the same set of cameras in stillcam mode. I am a co-author of gspca/sq905.c and I am the sole author of libgphoto2/camlibs/digigr8, which is licensed under the LGPL. I hereby give myself permission to use my own code from libgphoto2 in gspca/sq905c.c. Signed-off-by Theodore Kilgore kilg...@auburn.edu contents of the file sq905c.patch follow - diff -uprN linuxa/drivers/media/video/gspca/Kconfig linuxb/drivers/media/video/gspca/Kconfig --- linuxa/drivers/media/video/gspca/Kconfig 2009-02-23 23:59:07.0 -0600 +++ linuxb/drivers/media/video/gspca/Kconfig 2009-02-28 19:55:49.0 -0600 @@ -185,6 +185,15 @@ config USB_GSPCA_SQ905 To compile this driver as a module, choose M here: the module will be called gspca_sq905. +config USB_GSPCA_SQ905C + tristate SQ Technologies SQ905C based USB Camera Driver + depends on VIDEO_V4L2 USB_GSPCA + help + Say Y here if you want support for cameras based on the SQ905C chip. + + To compile this driver as a module, choose M here: the + module will be called gspca_sq905c. + config USB_GSPCA_STK014 tristate Syntek DV4000 (STK014) USB Camera Driver depends on VIDEO_V4L2 USB_GSPCA diff -uprN linuxa/drivers/media/video/gspca/Makefile linuxb/drivers/media/video/gspca/Makefile --- linuxa/drivers/media/video/gspca/Makefile 2009-02-23 23:59:07.0 -0600 +++ linuxb/drivers/media/video/gspca/Makefile 2009-02-28 19:54:54.0 -0600 @@ -17,6 +17,7 @@ obj-$(CONFIG_USB_GSPCA_SPCA506) += gspc obj-$(CONFIG_USB_GSPCA_SPCA508) += gspca_spca508.o obj-$(CONFIG_USB_GSPCA_SPCA561) += gspca_spca561.o obj-$(CONFIG_USB_GSPCA_SQ905)+= gspca_sq905.o +obj-$(CONFIG_USB_GSPCA_SQ905C)+= gspca_sq905c.o obj-$(CONFIG_USB_GSPCA_SUNPLUS) += gspca_sunplus.o obj-$(CONFIG_USB_GSPCA_STK014) += gspca_stk014.o obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o @@ -43,6 +44,7 @@ gspca_spca506-objs := spca506.o gspca_spca508-objs := spca508.o gspca_spca561-objs := spca561.o gspca_sq905-objs:= sq905.o +gspca_sq905c-objs:= sq905c.o gspca_stk014-objs := stk014.o gspca_sunplus-objs := sunplus.o gspca_t613-objs := t613.o diff -uprN linuxa/drivers/media/video/gspca/sq905c.c linuxb/drivers/media/video/gspca/sq905c.c --- linuxa/drivers/media/video/gspca/sq905c.c 1969-12-31 18:00:00.0 -0600 +++ linuxb/drivers/media/video/gspca/sq905c.c 2009-03-02 20:42:42.0 -0600 @@ -0,0 +1,330 @@ +/* + * SQ905C subdriver + * + * Copyright (C) 2009 Theodore Kilgore + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + *
[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:Wed Mar 4 19:00:07 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10821:4b288a26993d 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-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-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: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc5-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-rc5-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-rc5-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc5-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: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS 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-rc5-x86_64: WARNINGS fw/apps: WARNINGS spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The 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
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hans Verkuil wrote: On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. There might be situations where multiple device nodes would be beneficial even if they cannot be used simultaneously in all cases. Currently the omap34xxcam camera driver creates one device per camera. A camera in this case contains an isp (or camera controller), image sensor, lens and flash. The properties like maximum frame rate or resolution of a camera are usually (almost) completely defined by those of the sensor, lens and flash. This affects also cropping capabilities. Several programs can access video devices simultaneously. What happens if another program switches the input when the first one doesn't expect it? The original user won't notice the change, instead of getting -EBUSY when trying to open the other video device. In short, it's been just more clear to have one device per camera. There may be other reasons but these come to mind this time. BTW, do I understand correctly that e.g. lens drivers also get their own /dev/videoX node? Please tell me I'm mistaken! Since that would be so very wrong. Yes, you're mistaken this time. :) The contents of a video devices are defined in platform data. I hope that the conversion to v4l2_subdev will take place soon. You are basically stuck in a technological dead-end :-( Making things working properly in camera and ISP drivers has taken much more time than was anticipated and v4l2_subdev framework has developed a lot during that time. You're right --- we'll start thinking of how and when to move to v4l2_subdev. Thanks. -- 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: [hg:v4l-dvb] Add ids for Yuan PD378S DVB adapter
Le mercredi 04 mars 2009 à 19:20 +0100, Patch from Pascal Terjan a
écrit :
The patch number 10825 was added via Mauro Carvalho Chehab
mche...@redhat.com
to http://linuxtv.org/hg/v4l-dvb master development tree.
The merge seems wrong:
+/* 45 */{ USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_PD378S) },
+ { dib0700_usb_id_table[44], NULL },
Should be 45
--
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 Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: Hans Verkuil wrote: On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. There might be situations where multiple device nodes would be beneficial even if they cannot be used simultaneously in all cases. Currently the omap34xxcam camera driver creates one device per camera. A camera in this case contains an isp (or camera controller), image sensor, lens and flash. The properties like maximum frame rate or resolution of a camera are usually (almost) completely defined by those of the sensor, lens and flash. This affects also cropping capabilities. Several programs can access video devices simultaneously. What happens if another program switches the input when the first one doesn't expect it? The original user won't notice the change, instead of getting -EBUSY when trying to open the other video device. It is actually quite common to be able to switch inputs using one program (e.g. v4l2-ctl) while another program also has the video node open. This will typically be used for debugging or experimenting. Depending on the hardware, switching inputs while capturing is in progress may or may not be allowed (the driver might just return -EBUSY in that case). In addition the application can also call VIDIOC_S_PRIORITY to protect it against outside interference, provided the driver supports this ioctl. As an aside: many applications don't use VIDIOC_S_PRIORITY since whether a driver implements it is hit-and-miss. As part of the new v4l2 framework I have a struct v4l2_fh planned that will integrate support of this ioctl in the framework, thus making it generic for all drivers. But this won't be available any time soon. In short, it's been just more clear to have one device per camera. There may be other reasons but these come to mind this time. I very much disagree here. Having multiple devices ONLY makes sense if you can capture from them in parallel. This situation is really just a straightforward case of multiple inputs you have to choose from. BTW, do I understand correctly that e.g. lens drivers also get their own /dev/videoX node? Please tell me I'm mistaken! Since that would be so very wrong. Yes, you're mistaken this time. :) The contents of a video devices are defined in platform data. I hope that the conversion to v4l2_subdev will take place soon. You are basically stuck in a technological dead-end :-( Making things working properly in camera and ISP drivers has taken much more time than was anticipated and v4l2_subdev framework has developed a lot during that time. You're right --- we'll start thinking of how and when to move to v4l2_subdev. Just contact me if you have any questions, I'll be happy to help. If you think there are missing bits in the framework, or find that you need to workaround some limitation, please contact me first. It might well be that I need to add something to support these devices, or that you should take a different approach instead. The sooner such issues are resolved, the less time you loose. 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: [hg:v4l-dvb] Add ids for Yuan PD378S DVB adapter
On Wed, 04 Mar 2009 20:53:07 +0100
Pascal Terjan pter...@mandriva.com wrote:
Le mercredi 04 mars 2009 à 19:20 +0100, Patch from Pascal Terjan a
écrit :
The patch number 10825 was added via Mauro Carvalho Chehab
mche...@redhat.com
to http://linuxtv.org/hg/v4l-dvb master development tree.
The merge seems wrong:
+/* 45 */{ USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_PD378S) },
+ { dib0700_usb_id_table[44], NULL },
Should be 45
Fixed. Thanks!
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
On Tue, 3 Mar 2009, Mauro Carvalho Chehab wrote: On Mon, 2 Mar 2009 13:31:11 -0800 (PST) Trent Piepho xy...@speakeasy.org wrote: Hi Trent, Here's the latest patch for pluto2. It's a much simpler chip than cx18. I've used atomic operations to design a lockless system. Did you have any return about a tester with pluto2? It would be nice to apply this fix, since we've reverted the alternative patch. AFAIK, no one has tested the patch. The only one I know with pluto2 hardware is Andreas Oberritter. -- 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
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 04, 2009 3:06 PM To: sakari.ai...@maxwell.research.nokia.com Cc: DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia- D/Oulu); Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver On Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: Hans Verkuil wrote: On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. There might be situations where multiple device nodes would be beneficial even if they cannot be used simultaneously in all cases. Currently the omap34xxcam camera driver creates one device per camera. A camera in this case contains an isp (or camera controller), image sensor, lens and flash. The properties like maximum frame rate or resolution of a camera are usually (almost) completely defined by those of the sensor, lens and flash. This affects also cropping capabilities. Several programs can access video devices simultaneously. What happens if another program switches the input when the first one doesn't expect it? The original user won't notice the change, instead of getting -EBUSY when trying to open the other video device. It is actually quite common to be able to switch inputs using one program (e.g. v4l2-ctl) while another program also has the video node open. This will typically be used for debugging or experimenting. Depending on the hardware, switching inputs while capturing is in progress may or may not be allowed (the driver might just return -EBUSY in that case). In addition the application can also call VIDIOC_S_PRIORITY to protect it against outside interference, provided the driver supports this ioctl. As an aside: many applications don't use VIDIOC_S_PRIORITY since whether a driver implements it is hit-and-miss. As part of the new v4l2 framework I have a struct v4l2_fh planned that will integrate support of this ioctl in the framework, thus making it generic for all drivers. But this won't be available any time soon. As what I understand, we have 2 possible situations for multiple opens here: 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. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? I mean, the app should consciously make sure the input (sensor) is the correct one before performing any adjustments. I think our current approach avoids the user to be constantly checking if the input is still the same before updating gains... 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... In short, it's been just more clear to have one device per camera. There may be other reasons but these come to mind this time. I very much disagree here. Having multiple devices ONLY makes sense if you can capture from them in parallel. This situation is really just a straightforward case of multiple inputs you have to choose from. BTW, do I understand correctly that e.g. lens drivers also get their own /dev/videoX node? Please tell me I'm mistaken! Since that would be so very wrong. Yes, you're mistaken this time. :) The contents of a video devices are defined in platform data. I hope that the conversion to v4l2_subdev will take place soon. You are basically stuck in a technological dead-end :-( Making things working properly in camera and ISP drivers has taken much more time than was anticipated and v4l2_subdev framework has developed a lot during that time. You're right --- we'll start thinking of how and when to move to v4l2_subdev. Just contact me if you have any questions, I'll be happy to help. If you think there are missing bits in the framework, or find that you need to workaround some limitation, please contact me first. It might well be that I need to add something to support these devices, or that you should take a different
Re: AnyTV AUTV002 USB ATSC/QAM Tuner Stick
Hi, I have not been able to put any serious time into this project, and I'd like to reiterate my offer to buy one of these devices (http://www.dealextreme.com/details.dx/sku.15569) for an experienced v4l developer who would like to give it a try. I will stay in the loop for testing (FC10 on Dell SC1420). Blame my new girlfriend: My evenings are no longer my own. And I don't mind it one bit! -BobC Bob Cunningham wrote: Michael Krufky wrote: On Thu, Nov 27, 2008 at 11:11 AM, CityK ci...@rogers.com wrote: Bob Cunningham wrote: What are the next steps? 1. How much effort will be needed to make this driver work? 2. Do all of the pieces already exist? (All the chips seem to be mentioned somewhere in the DVB tree.) 3. What new code is needed? 4. How much reverse-engineering needs to be done? Will a full schematic be needed? Most importantly: 5. How can I help? I'm a real-time embedded systems programmer with 25 years experience, though most of what I've written runs on bare metal, often without an OS. I know nothing about Linux device drivers. However, I am very good at getting local hardware to play nice, first by poking it with a debugger, then generally by scripting through /dev/port. I've never worked with hardware across the USB bus, though I have brought up USB interface hardware from the CPU side, and have had to snoop USB traffic to diagnose problems. Unfortunately, I don't have a Windows system available to use to snoop the USB traffic from the driver provided by the vendor, though I haven't yet tried to get anything to work via Wine. I'll be taking lots of time off in December, and should have some time to put toward this project. If anyone else is curious, or wants to help, the product is here: http://www.dealextreme.com/details.dx/sku.15569 I also found a brief description of a reference design here: http://www.auvitek.com/AU8522%20MT%20USB%20TV%20Stick%20Design%20Brief_R1.0.pdf 1 - probably not a lot 2 - sounds like it, but I do not know how far developed the MT2131 driver is 3 - probably just the glue code to tie all the pieces together 4 - likely none (there may be a chance the the components are wired up slightly differently, such as in the case with GPIO pins, in which case you'd have to try to discover the true configurationschematics would obviously help, but probably 99.99% of cases are resolved without such aide ) 5 - you can add the support for the device ! :PBecause of the advanced state (component drivers already exist) you won't need any in depth knowledge about the developing device drivers. At this point, all you will need to do is figure out where to insert the necessary glue code in the existing modules - have a look in the source code of the respective components (eg. /linux/drivers/media/video/au0828/ ; /linux/drivers/media/dvb/frontends/ ; ). Note that the AU0828 does not currently support analog (http://marc.info/?l=linux-videom=122459807631633w=2). I suspect that solving the EEPROM issue is just a matter of adjusting the code so that it is not specifically expecting a Hauppauge signature. Getting the device to attach the correct tuner should be, I imagine, fairly straight forward too . It would appear that this device is highly similar to the Woodbury (see: http://marc.info/?l=linux-dvbm=122617795121243w=2); I do not know whether there is significant difference between the respective MT parts -- might be trivial, then again it might not be I am hosting experimental support for these devices in the following mercurial repository: http://linuxtv.org/hg/~mkrufky/teledongle Please generate any patches, if any, against the above tree. If you read the comments that I wrote in the changesets in that tree, it explains what I know about these devices. Ignore the syntek teledongle name for now -- there are so many of these different devices floating around with the same USB ID that the name really doesnt matter. If this works for you, please let me know. So far, the tda18271 version works, but the mt2131 version does not. -Mike Sorry for the delay! I got, built and installed the teledongle tree, and dmesg provided the following output: usb 1-2: new high speed USB device using ehci_hcd and address 7 usb 1-2: configuration #1 chosen from 1 choice usb 1-2: New USB device found, idVendor=05e1, idProduct=0400 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2: Product: USB 2.0 Video Capture Controller usb 1-2: Manufacturer: Syntek Semiconductor au0828 driver loaded au0828: i2c bus registered tda18271 4-0060: creating new instance Unknown device detected @ 4-0060, device not supported. Unknown device detected @ 4-0060, device not supported. tda18271_attach: error -22 on line 1171 tda18271 4-0060: destroying instance MT2131: successfully identified at address 0x60 DVB: registering new adapter (au0828) DVB: registering adapter 0 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... Registered device AU0828 [Syntek
Re: [PATCH] cx88: Add IR support to pcHDTV HD3000 HD5500
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. 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? 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. -- 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 5/5] LDP: Add support for built-in camera
From: Curran, Dominic
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto
Sent: Tuesday, March 03, 2009 2:44 PM
To: linux-media@vger.kernel.org; linux-o...@vger.kernel.org
Cc: Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel)
Kim;
MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon,
Nishanth
Subject: [PATCH 5/5] LDP: Add support for built-in camera
This patch adds support for the LDP builtin camera sensor:
- Primary sensor (/dev/video4): OV3640 (CSI2).
It introduces also a new file for storing all camera sensors board
specific related functions, like other platforms do (N800 for example).
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-ldp-camera.c | 203
+++
arch/arm/mach-omap2/board-ldp.c | 17 +++
arch/arm/plat-omap/include/mach/board-ldp.h |1 +
4 files changed, 223 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-ldp-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ee6..097bc58 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -63,7 +63,8 @@ obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-
omap3beagle.o \
mmc-twl4030.o \
twl4030-generic-scripts.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
- mmc-twl4030.o
+ mmc-twl4030.o \
+ board-ldp-camera.o
obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
board-apollon-mmc.o \
board-apollon-keys.o
diff --git a/arch/arm/mach-omap2/board-ldp-camera.c b/arch/arm/mach-
omap2/board-ldp-camera.c
new file mode 100644
index 000..0db085c
--- /dev/null
+++ b/arch/arm/mach-omap2/board-ldp-camera.c
@@ -0,0 +1,203 @@
+/*
+ * linux/arch/arm/mach-omap2/board-ldp0-camera.c
Minor typo, should be:
linux/arch/arm/mach-omap2/board-ldp-camera.c
Oops, fixed.
snip
+
+static struct omap34xxcam_sensor_config ov3640_hwc = {
+ .sensor_isp = 0,
+ .xclk = OMAP34XXCAM_XCLK_B,
+ .capture_mem = 2592 * 1944 * 2 * 2,
Should this be 2048 * 1536 * 2 * 2 ?
Yep, You're right. Fixed.
I'll repost after I fix Felipe Balbi's comments on MT sensor.
Thanks for your time!
Regards,
Sergio
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Wednesday 04 March 2009 22:46:07 Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 04, 2009 3:06 PM To: sakari.ai...@maxwell.research.nokia.com Cc: DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia- D/Oulu); Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver On Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: Hans Verkuil wrote: On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. There might be situations where multiple device nodes would be beneficial even if they cannot be used simultaneously in all cases. Currently the omap34xxcam camera driver creates one device per camera. A camera in this case contains an isp (or camera controller), image sensor, lens and flash. The properties like maximum frame rate or resolution of a camera are usually (almost) completely defined by those of the sensor, lens and flash. This affects also cropping capabilities. Several programs can access video devices simultaneously. What happens if another program switches the input when the first one doesn't expect it? The original user won't notice the change, instead of getting -EBUSY when trying to open the other video device. It is actually quite common to be able to switch inputs using one program (e.g. v4l2-ctl) while another program also has the video node open. This will typically be used for debugging or experimenting. Depending on the hardware, switching inputs while capturing is in progress may or may not be allowed (the driver might just return -EBUSY in that case). In addition the application can also call VIDIOC_S_PRIORITY to protect it against outside interference, provided the driver supports this ioctl. As an aside: many applications don't use VIDIOC_S_PRIORITY since whether a driver implements it is hit-and-miss. As part of the new v4l2 framework I have a struct v4l2_fh planned that will integrate support of this ioctl in the framework, thus making it generic for all drivers. But this won't be available any time soon. As what I understand, we have 2 possible situations for multiple opens here: 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. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? 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. I mean, the app should consciously make sure the input (sensor) is the correct one before performing any adjustments. Can you elaborate? I don't follow this, I'm afraid. I think our current approach avoids the user to be constantly checking if the input is still the same before updating gains... If I understand it correctly, the normal approach would be one application that might have a separate thread to do the gain adjustments, etc. Or do it all in the same thread, for example by doing the adjustments after every X frames captured. Doing this in two separate applications seems awkward to me. Usually the streaming thread and the adjustment thread need to communicate with one another or be directed from some the main application. 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?
Re: [PATCH] to gspca, to support SQ905C cameras.
On Wed, 4 Mar 2009, Mauro Carvalho Chehab wrote: On Tue, 3 Mar 2009 13:54:59 -0600 (CST) kilg...@banach.math.auburn.edu wrote: The SQ905C cameras (0x2770:0x905C) cameras, as well as two other closely related varieties (0x2770:0x9050 and 0x2770:0x913D) are supported in what follows. Please check your patch with checkpatch.pl. There are lots of troubles, maybe some introduced by your emailer, since you have tons of whitespace issues. OK, I will try it again in a following message, having gone through and checked everything, according to your suggestions. However, there was one thing which left me puzzled. It is the following: I did the checkpatch.pl thing at the office, before coming home. It showed that I was overconfident in my ability to produce clean code. However, there was also a more serious problem. In addition to finding whitespace issues, etc. checkpatch.pl said that the patch was corrupted. And it was. When I tried to apply it to a copy of J-F Moine's tree at the office, it would not apply, but instead gave me errors and rejects. I am a bit puzzled by that, because this patch was applied at home and there were no such complaints. All I did was to send it to the office, using scp. So I have no clue where *that* problem came from. Therefore, in case that such a problem reoccurs, could I kindly ask permission in advance to do something like gzip the patch file and send it as an attachment? I really do not understand how that part of the problem could have happened. The mailer had nothing to do with it. I was merely working with the same file that I sent over to the office via scp, which had not been mailed to anybody at all. Naturally, I will send the revised file in the regular way, in the body of an e-mail message, first. But please let me know if there is such a problem again. 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
[PATCH] libv4lconvert support for SQ905C decompression (revised)
Hans,
From an abundance of caution, I thought I had better run the v4lconvert
patch which supports the SQ905C compressed format through the
checkpatch.pl process, too. The result of that process appears here,
below the signed-off-by line.
Theodore Kilgore
-- Forwarded message --
Date: Sun, 1 Mar 2009 17:45:32 -0600 (CST)
From: kilg...@banach.math.auburn.edu
To: Hans de Goede hdego...@redhat.com, linux-media@vger.kernel.org
Subject: [PATCH] libv4lconvert support for SQ905C decompression
Hans,
Below is a patch for libv4lconvert, to support the decompression used by the
SQ905C cameras (0x2770:0x905C) and some other related cameras. There is at the
moment no support module for these cameras in streaming mode, but I intend to
submit one.
This contribution was created in whole by me, based upon code in libgphoto2
which was created in whole by me, and which was licensed for
libgphoto2 under the LGPL license.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
---
diff -uprN libv4lconvert-old/Makefile libv4lconvert-new/Makefile
--- libv4lconvert-old/Makefile 2009-03-01 15:37:38.0 -0600
+++ libv4lconvert-new/Makefile 2009-03-04 16:22:52.0 -0600
@@ -12,7 +12,7 @@ endif
CONVERT_OBJS = libv4lconvert.o tinyjpeg.o sn9c10x.o sn9c20x.o pac207.o \
mr97310a.o flip.o crop.o jidctflt.o spca561-decompress.o \
- rgbyuv.o spca501.o bayer.o
+ rgbyuv.o spca501.o sq905c.o bayer.o
TARGETS = $(CONVERT_LIB) libv4lconvert.pc
INCLUDES = ../include/libv4lconvert.h
diff -uprN libv4lconvert-old/libv4lconvert-priv.h
libv4lconvert-new/libv4lconvert-priv.h
--- libv4lconvert-old/libv4lconvert-priv.h 2009-03-01 15:37:38.0
-0600
+++ libv4lconvert-new/libv4lconvert-priv.h 2009-03-04 16:22:52.0
-0600
@@ -47,6 +47,10 @@
#define V4L2_PIX_FMT_MR97310A v4l2_fourcc('M','3','1','0')
#endif
+#ifndef V4L2_PIX_FMT_SQ905C
+#define V4L2_PIX_FMT_SQ905C v4l2_fourcc('9', '0', '5', 'C')
+#endif
+
#ifndef V4L2_PIX_FMT_PJPG
#define V4L2_PIX_FMT_PJPG v4l2_fourcc('P', 'J', 'P', 'G')
#endif
@@ -180,6 +184,9 @@ void v4lconvert_decode_pac207(const unsi
void v4lconvert_decode_mr97310a(const unsigned char *src, unsigned char *dst,
int width, int height);
+void v4lconvert_decode_sq905c(const unsigned char *src, unsigned char *dst,
+ int width, int height);
+
void v4lconvert_bayer_to_rgb24(const unsigned char *bayer,
unsigned char *rgb, int width, int height, unsigned int pixfmt);
diff -uprN libv4lconvert-old/libv4lconvert.c libv4lconvert-new/libv4lconvert.c
--- libv4lconvert-old/libv4lconvert.c 2009-03-01 15:37:38.0 -0600
+++ libv4lconvert-new/libv4lconvert.c 2009-03-04 16:22:52.0 -0600
@@ -61,6 +61,7 @@ static const struct v4lconvert_pixfmt su
{ V4L2_PIX_FMT_SN9C10X, V4LCONVERT_COMPRESSED },
{ V4L2_PIX_FMT_PAC207, V4LCONVERT_COMPRESSED },
{ V4L2_PIX_FMT_MR97310A, V4LCONVERT_COMPRESSED },
+ { V4L2_PIX_FMT_SQ905C, V4LCONVERT_COMPRESSED },
{ V4L2_PIX_FMT_PJPG, V4LCONVERT_COMPRESSED },
};
@@ -608,6 +609,7 @@ static int v4lconvert_convert_pixfmt(str
case V4L2_PIX_FMT_SN9C10X:
case V4L2_PIX_FMT_PAC207:
case V4L2_PIX_FMT_MR97310A:
+case V4L2_PIX_FMT_SQ905C:
{
unsigned char *tmpbuf;
@@ -633,6 +635,10 @@ static int v4lconvert_convert_pixfmt(str
v4lconvert_decode_mr97310a(src, tmpbuf, width, height);
src_pix_fmt = V4L2_PIX_FMT_SBGGR8;
break;
+ case V4L2_PIX_FMT_SQ905C:
+ v4lconvert_decode_sq905c(src, tmpbuf, width, height);
+ src_pix_fmt = V4L2_PIX_FMT_SRGGB8;
+ break;
}
src = tmpbuf;
/* Deliberate fall through to raw bayer fmt code! */
diff -uprN libv4lconvert-old/sq905c.c libv4lconvert-new/sq905c.c
--- libv4lconvert-old/sq905c.c 1969-12-31 18:00:00.0 -0600
+++ libv4lconvert-new/sq905c.c 2009-03-04 16:27:17.0 -0600
@@ -0,0 +1,217 @@
+/*
+ * sq905c.c
+ *
+ * Here is the decompression function for the SQ905C cameras. The functions
+ * used are adapted from the libgphoto2 functions for the same cameras,
+ * which was
+ * Copyright (c) 2005 and 2007 Theodore Kilgore kilg...@auburn.edu
+ * This version for libv4lconvert is
+ * Copyright (c) 2009 Theodore Kilgore kilg...@auburn.edu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General
RE: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 04, 2009 4:45 PM To: Aguirre Rodriguez, Sergio Alberto Cc: sakari.ai...@maxwell.research.nokia.com; DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver On Wednesday 04 March 2009 22:46:07 Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 04, 2009 3:06 PM To: sakari.ai...@maxwell.research.nokia.com Cc: DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia- D/Oulu); Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver On Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: Hans Verkuil wrote: On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. There might be situations where multiple device nodes would be beneficial even if they cannot be used simultaneously in all cases. Currently the omap34xxcam camera driver creates one device per camera. A camera in this case contains an isp (or camera controller), image sensor, lens and flash. The properties like maximum frame rate or resolution of a camera are usually (almost) completely defined by those of the sensor, lens and flash. This affects also cropping capabilities. Several programs can access video devices simultaneously. What happens if another program switches the input when the first one doesn't expect it? The original user won't notice the change, instead of getting -EBUSY when trying to open the other video device. It is actually quite common to be able to switch inputs using one program (e.g. v4l2-ctl) while another program also has the video node open. This will typically be used for debugging or experimenting. Depending on the hardware, switching inputs while capturing is in progress may or may not be allowed (the driver might just return -EBUSY in that case). In addition the application can also call VIDIOC_S_PRIORITY to protect it against outside interference, provided the driver supports this ioctl. As an aside: many applications don't use VIDIOC_S_PRIORITY since whether a driver implements it is hit-and-miss. As part of the new v4l2 framework I have a struct v4l2_fh planned that will integrate support of this ioctl in the framework, thus making it generic for all drivers. But this won't be available any time soon. As what I understand, we have 2 possible situations for multiple opens here: 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. Everytime a RAW10 Bayer formatted frame is received on the OMAP3ISP, statistics are being generated and when done, stored in buffers allocated internally on the driver (last 5 frames only), marking every stats buffer with the frame number associated. When requesting stats, the user needs to specify the frame number (since last streamon call) to the which he needs the statistics. Receives in return the associated buffer. So, going back to answering directly your question, the stats are related to the frame_number since last stream on call, making it impossible to request from one specific sensor. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? 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, makes sense. I mean, the app
RE: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Wed, 4 Mar 2009, Aguirre Rodriguez, Sergio Alberto wrote: As what I understand, we have 2 possible situations for multiple opens here: 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. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? I mean, the app should consciously make sure the input (sensor) is the correct one before performing any adjustments. It's usually perfectly legal to change inputs from one file handle while another file handle is capturing. If changing inputs while capturing is hard for your hardware and not supported, then S_INPUT could return EBUSY while capture is in progress. But in that case it doesn't matter which file descriptor is trying to change inputs. v4l2 is designed to allow a device to be controlled from multiple open file descriptors. Just like serial ports or audio mixers can be. In general, an application should not worry about someone changing inputs or frequencies while it is running. If using v4l2-ctl while and app is running leads to undesirable behavior there is a simple solution: Don't do that. If you want exclusive access you can use a solution external to v4l2. For instance most apps that use serial ports (pppd, minicom, etc.) use lock files in /var/lock to control access. V4L2 also gives you VIDIOC_[SG]_PRIORITY to do access control within v4l2, but it's not much used. It has little use because exclusive access just isn't something that important. In theory it seems important, but in practice no one seems to care much that it's missing. -- 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 0/5] Sensor drivers for OMAP3430SDP and LDP camera
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Tuesday, March 03, 2009 5:56 PM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: Re: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera On Tuesday 03 March 2009, Aguirre Rodriguez, Sergio Alberto wrote: This patch series depends on the following patches: - Add TWL4030 registers, posted by Tuukka Toivonen on March 2nd. http://marc.info/?l=linux-omapm=123597520231668w=2 I'd much rather see these drivers just use the regulator framework to switch any sensor power rails on/off. Hi, Sounds interesting. Is there any documentation on how to use this? As with the V4L2 interface changes, the twl4030 regulator support will be in mainline for the 2.6.30 kernels. - Dave -- 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 0/9] OMAP3 ISP and camera drivers
Hi Sakari, I'm also facing same issue with Hiremath. Here you are my kernel stack dump. Cheers, Nate [6.465606] [c019e194] (dev_driver_string+0x0/0x44) from [c01cc5e0] (omap34xxcam_device_register+0x110/0x2f8) [6.475952] [c01cc4d0] (omap34xxcam_device_register+0x0/0x2f8) from [c01b91a0] (__v4l2_int_device_try_attach_all+0xb0/0x108) [6.487609] r7: r6:c03e4fcc r5:cfbbf834 r4:c03e4f94 [6.493347] [c01b90f0] (__v4l2_int_device_try_attach_all+0x0/0x108) from [c01b9258] (v4l2_int_device_register+0x60/0x7c) [6.504638] r7:c03e4eec r6:cf9e5020 r5:c03e4f94 r4:c03e03f8 [6.510375] [c01b91f8] (v4l2_int_device_register+0x0/0x7c) from [c00182e4] (ce131f_probe+0x88/0xa8) [6.519836] r5: r4:cf9e5000 [6.523437] [c001825c] (ce131f_probe+0x0/0xa8) from [c01cefa4] (i2c_device_probe+0x78/0x90) [6.532226] r5:cf9e5000 r4:c001825c [6.535827] [c01cef2c] (i2c_device_probe+0x0/0x90) from [c01a1634] (driver_probe_device+0xd4/0x180) [6.545318] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020 [6.551025] [c01a1560] (driver_probe_device+0x0/0x180) from [c01a1748] (__driver_attach+0x68/0x8c) [6.560394] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020 [6.566131] [c01a16e0] (__driver_attach+0x0/0x8c) from [c01a0a8c] (bus_for_each_dev+0x4c/0x84) [6.575164] r7:c03e4eec r6:c01a16e0 r5:cf821cc8 r4: [6.580871] [c01a0a40] (bus_for_each_dev+0x0/0x84) from [c01a1478] (driver_attach+0x20/0x28) [6.589721] r7:cfb121a0 r6:c0018224 r5:c03e4eec r4: [6.595458] [c01a1458] (driver_attach+0x0/0x28) from [c01a1054] (bus_add_driver+0xa8/0x214) [6.604217] [c01a0fac] (bus_add_driver+0x0/0x214) from [c01a196c] (driver_register+0x98/0x120) [6.613250] r8: r7:c03ef760 r6:c0018224 r5:c03e4eec r4:c03e4ec0 [6.620025] [c01a18d4] (driver_register+0x0/0x120) from [c01cfffc] (i2c_register_driver+0x98/0xfc) [6.629425] [c01cff64] (i2c_register_driver+0x0/0xfc) from [c001823c] (ce131f_isp_init+0x18/0x38) [6.638702] r7:c03ef760 r6:c0018224 r5:c0022d78 r4:c0023128 [6.644439] [c0018224] (ce131f_isp_init+0x0/0x38) from [c002a2d0] (do_one_initcall+0x78/0x1d8) [6.653472] r5:c0022d78 r4:c0023128 [6.657073] [c002a258] (do_one_initcall+0x0/0x1d8) from [c0008720] (kernel_init+0x74/0xe0) [6.665740] r8: r7: r6: r5:c0022d78 r4:c0023128 [6.672515] [c00086ac] (kernel_init+0x0/0xe0) from [c005c234] (do_exit+0x0/0x684) [6.680419] r5: r4: [6.684020] Code: c036e993 e1a0c00d e92dd800 e24cb004 (e5903098) [6.690246] ---[ end trace cc13b15a4191e849 ]--- [6.694915] Kernel panic - not syncing: Attempted to kill init! On Thu, Mar 5, 2009 at 12:38 AM, Sakari Ailus sakari.ai...@maxwell.research.nokia.com wrote: Hiremath, Vaibhav wrote: [Hiremath, Vaibhav] Sakari, Let me ask you basic question, have you tested/verified these patch-sets? For the ISP and camera drivers, yes. That's actually the only thing that's contained in the patchset. The reason I am asking this question is, for me it was not working. I had to debug this and found that - - Changes missing in devices.c file, so isp_probe function will not be called at all, keeping omap3isp = NULL. You will end up into kernel crash in omap34xxcam_device_register. Anyway a crash shouldn't happen here. Could I see the kernel oops if there was such? - The patches from Hiroshi DOYU doesn't build as is, you need to add one include line #include linux/hardirq.h in iovmmu.c (I am using the patches submitted on 16th Jan 2009) Just pull the iommu branch, the Hiroshi's original patches are missing some hacks that you need to use them now. I'd expect Hiroshi to update the patchset when he comes back. I have attached git diff output here with this mail for reference. Please pull also the base branch. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication RD Centre 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: [RFC 0/5] Sensor drivers for OMAP3430SDP and LDP camera
On Wednesday 04 March 2009, Aguirre Rodriguez, Sergio Alberto wrote: I'd much rather see these drivers just use the regulator framework to switch any sensor power rails on/off. Hi, Sounds interesting. Is there any documentation on how to use this? Documentation/DocBook/regulator.tmpl Documentation/power/regulator/* I don't quite know how clear that is; the framework is still sorting itself out, a bit. The 2.6.30 kernel has some updates to programming interfaces, few of which should matter to any sensor code ... sensors would be consumers in that framework, calling regulator_get() and friends. The tricksy bits would be coupling the regulators to the sensor device nodes in the board-specfiic setup code. At some point I expect to see some cases where that setup needs framework updates, but so far that hasn't happened. - Dave -- 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
Hi tuukka, Chip identification could be used for many other camera devices. Not only for SMIA compatible sensors. It could be used for generic camera devices I guess for any other reasons, like checking chip version on factory assembly line in mass production. Something like G_CHIP_IDENT (as Hans mentioned) should be cool. Cheers, Nate On Wed, Mar 4, 2009 at 11:12 PM, Tuukka.O Toivonen tuukka.o.toivo...@nokia.com wrote: Hi, I am writing a generic driver for SMIA-compatible sensors. SMIA-sensors have registers containing: u16 model_id u16 revision_number u8 manufacturer_id which could be used to detect the sensor. However, since the driver is generic, it is not interested of these values. Nevertheless, in some cases user space applications want to know the exact chip. For example, to get the highest possible image quality, user space application might capture an image and postprocess it using sensor-specific filtering algorithms (which don't belong into kernel driver). I am planning to export the chip identification information to user space using VIDIOC_DBG_G_CHIP_IDENT. Here's a sketch: #define V4L2_IDENT_SMIA_BASE (0x53 24) then in sensor driver's VIDIOC_DBG_G_CHIP_IDENT ioctl handler: struct v4l2_dbg_chip_ident id; id.ident = V4L2_IDENT_SMIA_BASE | (manufacturer_id 16) | model_id; id.revision = revision_number; Do you think this is acceptable? 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? I'll start writing a patch as soon as you let me know which would be the best alternative. Thanks! - Tuukka -- 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 -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication RD Centre 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: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote: Which also makes me wonder about the same change for the mr97310a, is that cam already supported in a released kernel ? If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid we cannot make these changes. In that case if we ever need to header data we need to define a new PIXFMT for mr97310a with the header data, and deprecate the old one. I don't believe the driver has made it to any kernel yet. Even if it has, the user would need to have an unreleased version of libv4l. I think this change would inconvenience me and Theodore at most. Let's change it now. -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: [PATCH 3/5] OV3640: Add driver
On Tue, 3 Mar 2009, Aguirre Rodriguez, Sergio Alberto wrote:
+ {
+ /* Note: V4L2 defines RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4 g3
+*
+* We interpret RGB565 as:
+*
+* Byte 0Byte 1
+* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4 g3
The V4L2 spec was corrected to define the RGB565 the normal way.
--
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
Am Mittwoch, den 04.03.2009, 15:42 -0800 schrieb Trent Piepho: On Wed, 4 Mar 2009, Aguirre Rodriguez, Sergio Alberto wrote: As what I understand, we have 2 possible situations for multiple opens here: 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. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? I mean, the app should consciously make sure the input (sensor) is the correct one before performing any adjustments. It's usually perfectly legal to change inputs from one file handle while another file handle is capturing. If changing inputs while capturing is hard for your hardware and not supported, then S_INPUT could return EBUSY while capture is in progress. But in that case it doesn't matter which file descriptor is trying to change inputs. v4l2 is designed to allow a device to be controlled from multiple open file descriptors. Just like serial ports or audio mixers can be. In general, an application should not worry about someone changing inputs or frequencies while it is running. If using v4l2-ctl while and app is running leads to undesirable behavior there is a simple solution: Don't do that. If you want exclusive access you can use a solution external to v4l2. For instance most apps that use serial ports (pppd, minicom, etc.) use lock files in /var/lock to control access. V4L2 also gives you VIDIOC_[SG]_PRIORITY to do access control within v4l2, but it's not much used. It has little use because exclusive access just isn't something that important. In theory it seems important, but in practice no one seems to care much that it's missing. Just a note. All true, but if you fallback to a modem connection with kernel 2.6.22 on FC6 with at least one NIC and an external router/switch, the default route will still be assigned to eth0 and you can configure kppp to what ever you want, but it does not override it, but claims to do so at the GUI. (OK, I'm eight years away from pppd, but ...) You have to use route del default at first like in stoneage and I suspect there is more of this stuff around. To make more use of VIDIOC_S/G_PRIORITY I always did propagate :) The first use case was to capture on /dev/videoN and at once get vbi EPG data on /dev/vbiN. 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 0/9] OMAP3 ISP and camera drivers
Thanks,
Vaibhav Hiremath
-Original Message-
From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
Sent: Thursday, March 05, 2009 5:41 AM
To: Sakari Ailus
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen
Tuukka Olli Artturi; Hiroshi DOYU
Subject: Re: [RFC 0/9] OMAP3 ISP and camera drivers
Hi Sakari,
I'm also facing same issue with Hiremath.
Here you are my kernel stack dump.
[Hiremath, Vaibhav] I was getting same kernel crash, The reason is -
Since isp_probe doesn't get called, leaving omap3isp = NULL. So isp_get will
return -EBUSY from the very beginning of function. And the function
omap34xxcam_device_register which calls isp_get tries to access
vdev-vfd-dev where it crashes. Which is completely wrong, since the vfd gets
initialize later part of function
if (hwc.dev_type == OMAP34XXCAM_SLAVE_SENSOR) {
rval = isp_get();
if (rval 0) {
dev_err(vdev-vfd-dev, can't get ISP, sensor init
failed\n);
[Vaibhav] - Here it crashes.
goto err;
}
}
There are some instances where vdev-vfd is being accessed before initializing.
Cheers,
Nate
[6.465606] [c019e194] (dev_driver_string+0x0/0x44) from
[c01cc5e0] (omap34xxcam_device_register+0x110/0x2f8)
[6.475952] [c01cc4d0] (omap34xxcam_device_register+0x0/0x2f8)
from [c01b91a0] (__v4l2_int_device_try_attach_all+0xb0/0x108)
[6.487609] r7: r6:c03e4fcc r5:cfbbf834 r4:c03e4f94
[6.493347] [c01b90f0]
(__v4l2_int_device_try_attach_all+0x0/0x108) from [c01b9258]
(v4l2_int_device_register+0x60/0x7c)
[6.504638] r7:c03e4eec r6:cf9e5020 r5:c03e4f94 r4:c03e03f8
[6.510375] [c01b91f8] (v4l2_int_device_register+0x0/0x7c) from
[c00182e4] (ce131f_probe+0x88/0xa8)
[6.519836] r5: r4:cf9e5000
[6.523437] [c001825c] (ce131f_probe+0x0/0xa8) from
[c01cefa4]
(i2c_device_probe+0x78/0x90)
[6.532226] r5:cf9e5000 r4:c001825c
[6.535827] [c01cef2c] (i2c_device_probe+0x0/0x90) from
[c01a1634] (driver_probe_device+0xd4/0x180)
[6.545318] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
[6.551025] [c01a1560] (driver_probe_device+0x0/0x180) from
[c01a1748] (__driver_attach+0x68/0x8c)
[6.560394] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
[6.566131] [c01a16e0] (__driver_attach+0x0/0x8c) from
[c01a0a8c] (bus_for_each_dev+0x4c/0x84)
[6.575164] r7:c03e4eec r6:c01a16e0 r5:cf821cc8 r4:
[6.580871] [c01a0a40] (bus_for_each_dev+0x0/0x84) from
[c01a1478] (driver_attach+0x20/0x28)
[6.589721] r7:cfb121a0 r6:c0018224 r5:c03e4eec r4:
[6.595458] [c01a1458] (driver_attach+0x0/0x28) from
[c01a1054]
(bus_add_driver+0xa8/0x214)
[6.604217] [c01a0fac] (bus_add_driver+0x0/0x214) from
[c01a196c] (driver_register+0x98/0x120)
[6.613250] r8: r7:c03ef760 r6:c0018224 r5:c03e4eec
r4:c03e4ec0
[6.620025] [c01a18d4] (driver_register+0x0/0x120) from
[c01cfffc] (i2c_register_driver+0x98/0xfc)
[6.629425] [c01cff64] (i2c_register_driver+0x0/0xfc) from
[c001823c] (ce131f_isp_init+0x18/0x38)
[6.638702] r7:c03ef760 r6:c0018224 r5:c0022d78 r4:c0023128
[6.644439] [c0018224] (ce131f_isp_init+0x0/0x38) from
[c002a2d0] (do_one_initcall+0x78/0x1d8)
[6.653472] r5:c0022d78 r4:c0023128
[6.657073] [c002a258] (do_one_initcall+0x0/0x1d8) from
[c0008720] (kernel_init+0x74/0xe0)
[6.665740] r8: r7: r6: r5:c0022d78
r4:c0023128
[6.672515] [c00086ac] (kernel_init+0x0/0xe0) from [c005c234]
(do_exit+0x0/0x684)
[6.680419] r5: r4:
[6.684020] Code: c036e993 e1a0c00d e92dd800 e24cb004 (e5903098)
[6.690246] ---[ end trace cc13b15a4191e849 ]---
[6.694915] Kernel panic - not syncing: Attempted to kill init!
On Thu, Mar 5, 2009 at 12:38 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
Hiremath, Vaibhav wrote:
[Hiremath, Vaibhav] Sakari, Let me ask you basic question, have
you
tested/verified these patch-sets?
For the ISP and camera drivers, yes. That's actually the only
thing that's
contained in the patchset.
The reason I am asking this question is, for me it was not
working. I
had to debug this and found that -
- Changes missing in devices.c file, so isp_probe function will
not
be called at all, keeping omap3isp = NULL. You will end up into
kernel crash in omap34xxcam_device_register.
Anyway a crash shouldn't happen here. Could I see the kernel oops
if there
was such?
- The patches from Hiroshi DOYU doesn't build as is, you need to
add
one include line #include linux/hardirq.h in iovmmu.c (I am
using
the patches submitted on 16th Jan 2009)
Just pull the iommu branch, the Hiroshi's original patches are
missing some
hacks that you need to use them now. I'd expect Hiroshi to update
the
patchset when he comes back.
I have attached git
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
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.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new 2009-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?
I don't know if the camera will allow that to happen, but it's better to be
safe.
Agreed.
Note that this was a RFC. So if it is agreed that something needs to be
done, probably things should be put into a more formal patch structure.
Also I have a question of my own while thinking about this. It relates not
to the module but to the decompression code. What do we have over there?
Well,
void v4lconvert_decode_mr97310a(const unsigned char *inp, unsigned char
*outp,
int width, int height)
and then in my patch it does
/* remove the header */
inp += 12;
Perhaps this is not good, and what ought to be done instead is to pass
off the inp to an internal variable, and then increase it, instead.
Possibly an even better alternative exists. The easiest way, I think,
would be to take the two previous lines back out again, but
instead go back to the function
static inline unsigned char get_byte(const unsigned char *inp,
unsigned int bitpos)
{
const unsigned char *addr;
addr = inp + (bitpos 3);
return (addr[0] (bitpos 7)) | (addr[1] (8 - (bitpos
7)));
}
and put the 12-byte shift into the line which computes addr, like this:
addr = inp + 12 + (bitpos 3);
or if one really wants to get fancy about it then give a
#define MR97310a_HEADERSIZE 12
at the top of the file and then one could say
addr = inp + (bitpos 3) + MR97310a_HEADERSIZE;
As I said, if doing any of these then one would leave strictly alone the
decoding function and any of its contents. I am not sure if messing with
the start of the inp variable is a good idea. Frankly, I do not know
enough details to be certain. But on second look my instincts are against
screwing with something like that. The thing that worries me is that what
exactly happens to those 12 bytes. Do they disappear down a black hole, or
what? For, in the end they will have to be deallocated somewhere. And
what then? The alternative which I give above would do what is needed and
also does not mess with the start location of inp.
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 0/9] OMAP3 ISP and camera drivers
Hi,
You are right. I checked with my JTAG debugger.
It crashes just exactly there because of the reason you issued.
Cheers,
Nate
On Thu, Mar 5, 2009 at 12:53 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
Thanks,
Vaibhav Hiremath
-Original Message-
From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
Sent: Thursday, March 05, 2009 5:41 AM
To: Sakari Ailus
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen
Tuukka Olli Artturi; Hiroshi DOYU
Subject: Re: [RFC 0/9] OMAP3 ISP and camera drivers
Hi Sakari,
I'm also facing same issue with Hiremath.
Here you are my kernel stack dump.
[Hiremath, Vaibhav] I was getting same kernel crash, The reason is -
Since isp_probe doesn't get called, leaving omap3isp = NULL. So isp_get will
return -EBUSY from the very beginning of function. And the function
omap34xxcam_device_register which calls isp_get tries to access
vdev-vfd-dev where it crashes. Which is completely wrong, since the vfd
gets initialize later part of function
if (hwc.dev_type == OMAP34XXCAM_SLAVE_SENSOR) {
rval = isp_get();
if (rval 0) {
dev_err(vdev-vfd-dev, can't get ISP, sensor init
failed\n);
[Vaibhav] - Here it crashes.
goto err;
}
}
There are some instances where vdev-vfd is being accessed before
initializing.
Cheers,
Nate
[ 6.465606] [c019e194] (dev_driver_string+0x0/0x44) from
[c01cc5e0] (omap34xxcam_device_register+0x110/0x2f8)
[ 6.475952] [c01cc4d0] (omap34xxcam_device_register+0x0/0x2f8)
from [c01b91a0] (__v4l2_int_device_try_attach_all+0xb0/0x108)
[ 6.487609] r7: r6:c03e4fcc r5:cfbbf834 r4:c03e4f94
[ 6.493347] [c01b90f0]
(__v4l2_int_device_try_attach_all+0x0/0x108) from [c01b9258]
(v4l2_int_device_register+0x60/0x7c)
[ 6.504638] r7:c03e4eec r6:cf9e5020 r5:c03e4f94 r4:c03e03f8
[ 6.510375] [c01b91f8] (v4l2_int_device_register+0x0/0x7c) from
[c00182e4] (ce131f_probe+0x88/0xa8)
[ 6.519836] r5: r4:cf9e5000
[ 6.523437] [c001825c] (ce131f_probe+0x0/0xa8) from
[c01cefa4]
(i2c_device_probe+0x78/0x90)
[ 6.532226] r5:cf9e5000 r4:c001825c
[ 6.535827] [c01cef2c] (i2c_device_probe+0x0/0x90) from
[c01a1634] (driver_probe_device+0xd4/0x180)
[ 6.545318] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
[ 6.551025] [c01a1560] (driver_probe_device+0x0/0x180) from
[c01a1748] (__driver_attach+0x68/0x8c)
[ 6.560394] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
[ 6.566131] [c01a16e0] (__driver_attach+0x0/0x8c) from
[c01a0a8c] (bus_for_each_dev+0x4c/0x84)
[ 6.575164] r7:c03e4eec r6:c01a16e0 r5:cf821cc8 r4:
[ 6.580871] [c01a0a40] (bus_for_each_dev+0x0/0x84) from
[c01a1478] (driver_attach+0x20/0x28)
[ 6.589721] r7:cfb121a0 r6:c0018224 r5:c03e4eec r4:
[ 6.595458] [c01a1458] (driver_attach+0x0/0x28) from
[c01a1054]
(bus_add_driver+0xa8/0x214)
[ 6.604217] [c01a0fac] (bus_add_driver+0x0/0x214) from
[c01a196c] (driver_register+0x98/0x120)
[ 6.613250] r8: r7:c03ef760 r6:c0018224 r5:c03e4eec
r4:c03e4ec0
[ 6.620025] [c01a18d4] (driver_register+0x0/0x120) from
[c01cfffc] (i2c_register_driver+0x98/0xfc)
[ 6.629425] [c01cff64] (i2c_register_driver+0x0/0xfc) from
[c001823c] (ce131f_isp_init+0x18/0x38)
[ 6.638702] r7:c03ef760 r6:c0018224 r5:c0022d78 r4:c0023128
[ 6.644439] [c0018224] (ce131f_isp_init+0x0/0x38) from
[c002a2d0] (do_one_initcall+0x78/0x1d8)
[ 6.653472] r5:c0022d78 r4:c0023128
[ 6.657073] [c002a258] (do_one_initcall+0x0/0x1d8) from
[c0008720] (kernel_init+0x74/0xe0)
[ 6.665740] r8: r7: r6: r5:c0022d78
r4:c0023128
[ 6.672515] [c00086ac] (kernel_init+0x0/0xe0) from [c005c234]
(do_exit+0x0/0x684)
[ 6.680419] r5: r4:
[ 6.684020] Code: c036e993 e1a0c00d e92dd800 e24cb004 (e5903098)
[ 6.690246] ---[ end trace cc13b15a4191e849 ]---
[ 6.694915] Kernel panic - not syncing: Attempted to kill init!
On Thu, Mar 5, 2009 at 12:38 AM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
Hiremath, Vaibhav wrote:
[Hiremath, Vaibhav] Sakari, Let me ask you basic question, have
you
tested/verified these patch-sets?
For the ISP and camera drivers, yes. That's actually the only
thing that's
contained in the patchset.
The reason I am asking this question is, for me it was not
working. I
had to debug this and found that -
- Changes missing in devices.c file, so isp_probe function will
not
be called at all, keeping omap3isp = NULL. You will end up into
kernel crash in omap34xxcam_device_register.
Anyway a crash shouldn't happen here. Could I see the kernel oops
if there
was such?
- The patches from Hiroshi DOYU doesn't build as is, you need to
add
one include line #include linux/hardirq.h in iovmmu.c (I am
using
the patches submitted on 16th Jan
Re: [RFC 0/9] OMAP3 ISP and camera drivers
Hi Sakari, Reviewing your driver, I couldn't find JPEG sync mode or where to make programme ISP_CTRL with ISPCTRL_JPEG_FLUSH. Is JPEG sync mode is not the coverage of this version? or I'm missing something. If JPEG sync mode is not considered yet please let me know. Cheers, Nate On Tue, Mar 3, 2009 at 7:06 PM, Sakari Ailus sakari.ai...@maxwell.research.nokia.com wrote: Hi, So here's the patchset for OMAP 3 ISP and camera drivers plus the associated V4L changes. Sergio Aguirre has been posting a related patchset earlier, containing also sensor and lens driver used on SDP. This patchset is agains the linux-omap tree: URL:http://www.muru.com/linux/omap/README_OMAP_GIT So I and Sergio have synchronised our versions of the ISP and camera drivers and this is the end result. There is still a lot of work to do, though. You can find some comments in individual patch descriptions. If the todo list for a patch is empty it doesn't mean there wouldn't be anything left to do. ;) There's at least one major change to Sergio Aguirre's earlier patches which is that the ISP driver now uses the IOMMU from Hiroshi Doyu. Hiroshi is away for some time now so there are just some hacks on top of Hiroshi's older iommu patches to use with current linux-omap. This patchset does not contain the resizer or preview wrappers from TI but they have been left intentionally out. A proper interface (V4L) should be used for those and the camera driver should be somehow involved --- the wrappers are just duplicating much of the camera driver's functionality. I don't have any sensor or lens drivers to publish at this time. This patchset should work with the SDP and OMAPZoom boards although you need the associated sensor drivers + the board code from Sergio Aguirre to use it. You'll also need the IOMMU patchset from Hiroshi Doyu. Everything except the sensor / board stuff is available here: URL:http://www.gitorious.org/projects/omap3camera In short, on linux-omap: $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \ iommu omap3camera base Hiroshi's original iommu tree is here (branch iommu): URL:http://git.gitorious.org/lk/mainline.git Some of the camera and ISP driver development history is available, too. See the first link. Any feedback is appreciated. Sincerely, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- 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: RFC on proposed patches to mr97310a.c for gspca and v4l
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.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new 2009-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.
Since we know what the SOF looks like, we don't need to worry about losing the
FF FF 00 portion -- just copy sd-sof_read bytes from pac_sof_marker.
Unfortunately my brain is fried right now and I can't come up with a working
example.
I don't know if the camera will allow that to happen, but it's better to
be safe.
Agreed.
Note that this was a RFC. So if it is agreed that something needs to be
done, probably things should be put into a more formal patch structure.
Also I have a question of my own while thinking about this. It relates not
to the module but to the decompression code. What do we have over there?
Well,
void v4lconvert_decode_mr97310a(const unsigned char *inp, unsigned char
*outp,
int width, int height)
and then in my patch it does
/* remove the header */
inp += 12;
Perhaps this is not good, and what ought to be done instead is to pass
off the inp to an internal variable, and then increase it, instead.
Possibly an even better alternative exists. The easiest way, I think,
would be to take the two previous lines back out again, but
instead go back to the function
static inline unsigned char get_byte(const unsigned char *inp,
unsigned int bitpos)
{
const unsigned char *addr;
addr = inp + (bitpos 3);
return (addr[0] (bitpos 7)) | (addr[1] (8 - (bitpos
7)));
}
and put the 12-byte shift into the line which computes addr, like this:
addr = inp + 12 + (bitpos 3);
Let's not overcomplicate things. I think inp += 12 with a comment is fine for
now since we haven't completely reverse engineered the header yet. Use one
function to parse through the header, then use a different one to handle the
frame decompression. The header parser will call the correct decompressor
function with the correct offset into the frame buffer.
or if one really wants to get fancy about it then give a
#define MR97310a_HEADERSIZE 12
at the top of the file and then one could say
addr = inp + (bitpos 3) + MR97310a_HEADERSIZE;
I don't think we know this for sure yet. Maybe the header length is variable
and is specified along with the compression code?
As I said, if doing any of these then one would leave strictly alone the
decoding function and any of its contents. I am not sure if messing with
the start of the inp variable is a good idea. Frankly, I do not know
enough details to be certain. But on second look my instincts are against
screwing with something like that. The thing that worries me is that what
exactly happens to those 12 bytes. Do they disappear down a black hole, or
what? For, in the end they will have to be deallocated somewhere. And
what then? The alternative which I give above would do what is needed and
also does not mess with the start location of inp.
inp is a local variable, so changing it inside the decompressor function will
have no affect on
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
On Wed, 4 Mar 2009, 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.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new 2009-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.
True, and if you remove it then you can also delete some other things. Try
it and heed the compile warnings, and you will see.
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.
Yes, you are right. I was chasing through all of it, and I found the same
thing. I will point out, though, that this danger is not a new one. The
code which you originally had there suffers the same defect. The problem
is not whether one decides to keep the SOF marker in the frame output.
Rather, the problem is that one must *detect* it. And to detect it one
must needs be able to read all of it at once. If you read only three bytes
from it, and that is the end of the packet, then that will be analysed as
still belonging to the same frame. Then the next packet will continue to
be in the same frame, too.
A mitigating factor here is that when the next packet is in the same
frame then what will happen in practice is that the decompressor will
run, fill up the current frame, and stop when it reaches the end of the
frame and will toss the rest of the data. So in other words the next frame
will just get tossed.
Since we know what the SOF looks like, we don't need to worry about losing the
FF FF 00 portion
Yes, you do. You know what the marker looks like, and I know. But the FF
FF 00 is the end of the packet. So a computer will not know. It will not
be detected as part of an SOF marker. Instead, it will just be tacked onto
the data from the current frame and any special meaning will be lost.
However, the consequence is that the decompression algorithm will use
enough data to finish the current frame, stop before it has to use the FF
FF 00, and, since no marker has been detected in the next packet, either,
all new data will just be ignored as junk until another SOF marker comes
up and is detected. Then and only then a new output frame will be
initiated.
-- just copy sd-sof_read bytes from pac_sof_marker.
Unfortunately my brain is fried right now and I can't come up with a working
example.
I don't know if the camera will allow that to happen, but it's better to
be safe.
Agreed.
Maybe not. Perhaps according to my analysis above it is actually no big
deal. My analysis of what will happen is based upon the way the
decomressor function works (uses data until it is finished with a frame,
and then quits). So if it occasionally happens that an SOF marker is split
in two across two packets, then it just causes a frame's data to be
skipped. I can't imagine any other ill effect. Of course, if this bad
thing happens for 350 frames in succession, that would be quite
interesting.
Therefore, what I think is that the attempt to code around the possibility
that an SOF marker is split across two frames would be quite likely to
cause more trouble than it is worth. What would be needed is to consider
two successive packets at a time. If there is no SOF marker which can
start inside the first one and end in the second one, then put the data
Re: RFC on proposed patches to mr97310a.c for gspca and v4l
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.old 2009-02-23 23:59:07.0 -0600
+++ mr97310a.c.new 2009-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
--
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
Kyle Guinn wrote: On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote: Which also makes me wonder about the same change for the mr97310a, is that cam already supported in a released kernel ? If not we MUST make sure we get this change in before 2.6.29 final, if it is I'm afraid we cannot make these changes. In that case if we ever need to header data we need to define a new PIXFMT for mr97310a with the header data, and deprecate the old one. I don't believe the driver has made it to any kernel yet. Even if it has, the user would need to have an unreleased version of libv4l. I think this change would inconvenience me and Theodore at most. Let's change it now. +1 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 0/9] OMAP3 ISP and camera drivers
Hiremath, Vaibhav wrote:
Thanks,
Vaibhav Hiremath
-Original Message-
From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
Sent: Thursday, March 05, 2009 5:41 AM
To: Sakari Ailus
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; linux-
o...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen
Tuukka Olli Artturi; Hiroshi DOYU
Subject: Re: [RFC 0/9] OMAP3 ISP and camera drivers
Hi Sakari,
I'm also facing same issue with Hiremath.
Here you are my kernel stack dump.
[Hiremath, Vaibhav] I was getting same kernel crash, The reason is -
Since isp_probe doesn't get called, leaving omap3isp = NULL. So isp_get will return -EBUSY
from the very beginning of function. And the function omap34xxcam_device_register
which calls isp_get tries to access vdev-vfd-dev where it crashes. Which is completely
wrong, since the vfd gets initialize later part of function
if (hwc.dev_type == OMAP34XXCAM_SLAVE_SENSOR) {
rval = isp_get();
if (rval 0) {
dev_err(vdev-vfd-dev, can't get ISP, sensor init
failed\n);
[Vaibhav] - Here it crashes.
goto err;
}
}
There are some instances where vdev-vfd is being accessed before initializing.
Ooops.
Some parts of those dev_* were just mechanically changed from something
else. And I think Alexey Klimov already notified me about that problem.
I'm surprised that it was hit it so soon. ;)
Just removing the dev_err helps to resolve the crash, I guess. You could
use late_initcall instead of module_init in the sensor, but that's just
a hack, too.
If you are using modules, please load iommu2 and omap3-iommu before isp-mod.
--
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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Thursday 05 March 2009 00:30:24 Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 04, 2009 4:45 PM To: Aguirre Rodriguez, Sergio Alberto Cc: sakari.ai...@maxwell.research.nokia.com; DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver On Wednesday 04 March 2009 22:46:07 Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 04, 2009 3:06 PM To: sakari.ai...@maxwell.research.nokia.com Cc: DongSoo(Nathaniel) Kim; Hiremath, Vaibhav; Toivonen Tuukka.O (Nokia- D/Oulu); Aguirre Rodriguez, Sergio Alberto; linux-o...@vger.kernel.org; Nagalla, Hari; linux-media@vger.kernel.org Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver On Wednesday 04 March 2009 20:22:04 Sakari Ailus wrote: Hans Verkuil wrote: On Wednesday 04 March 2009 01:42:13 DongSoo(Nathaniel) Kim wrote: Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. That's wrong. Multiple devices should only be created if they can all be used at the same time. Otherwise there should be just one device that uses S_INPUT et al to select between the inputs. There might be situations where multiple device nodes would be beneficial even if they cannot be used simultaneously in all cases. Currently the omap34xxcam camera driver creates one device per camera. A camera in this case contains an isp (or camera controller), image sensor, lens and flash. The properties like maximum frame rate or resolution of a camera are usually (almost) completely defined by those of the sensor, lens and flash. This affects also cropping capabilities. Several programs can access video devices simultaneously. What happens if another program switches the input when the first one doesn't expect it? The original user won't notice the change, instead of getting -EBUSY when trying to open the other video device. It is actually quite common to be able to switch inputs using one program (e.g. v4l2-ctl) while another program also has the video node open. This will typically be used for debugging or experimenting. Depending on the hardware, switching inputs while capturing is in progress may or may not be allowed (the driver might just return -EBUSY in that case). In addition the application can also call VIDIOC_S_PRIORITY to protect it against outside interference, provided the driver supports this ioctl. As an aside: many applications don't use VIDIOC_S_PRIORITY since whether a driver implements it is hit-and-miss. As part of the new v4l2 framework I have a struct v4l2_fh planned that will integrate support of this ioctl in the framework, thus making it generic for all drivers. But this won't be available any time soon. As what I understand, we have 2 possible situations for multiple opens here: 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. Everytime a RAW10 Bayer formatted frame is received on the OMAP3ISP, statistics are being generated and when done, stored in buffers allocated internally on the driver (last 5 frames only), marking every stats buffer with the frame number associated. When requesting stats, the user needs to specify the frame number (since last streamon call) to the which he needs the statistics. Receives in return the associated buffer. So, going back to answering directly your question, the stats are related to the frame_number since last stream on call, making it impossible to request from one specific sensor. Situation 2 - Instance1: Select sensor1 as input. Begin streaming. - Instance2: Select sensor2 as input. Attempt to begin streaming. So, if I understood right, on Situation 2, if you attempt to do a S_INPUT to sensor2 while capturing from sensor1, it should return a -EBUSY, right? That is probably what the driver should do, yes. The V4L2 spec leaves it
