Re: [PATCH 1/2] Add Mars-Semi MR97310A format
On Wed, 14 Jan 2009 20:59:34 -0600 Kyle Guinn ely...@gmail.com wrote: Add a pixel format for the Mars-Semi MR97310A webcam controller. The MR97310A is a dual-mode webcam controller that provides compressed BGGR Bayer frames. The decompression algorithm for still images is the same as for video, and is currently implemented in libgphoto2. Hi Kyle, What is the difference of this pixel format from the other Bayer ones? Also, did you ask Hans de Goede to add the decoding to the v4l library? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gspca: Add MR97310A driver
On Wed, 14 Jan 2009 20:59:41 -0600
Kyle Guinn ely...@gmail.com wrote:
gspca: Add MR97310A driver
From: Kyle Guinn ely...@gmail.com
This patch adds support for USB webcams based on the MR97310A chip.
It was tested with an Aiptek PenCam VGA+ webcam.
Hi again,
Here are some remarks about your patch.
[snip]
+/* the bytes to write are in gspca_dev-usb_buf */
+static int reg_w(struct gspca_dev *gspca_dev,
+ __u16 index, int len)
+{
+ int rc;
+
+ rc = usb_bulk_msg(gspca_dev-dev,
+ usb_sndbulkpipe(gspca_dev-dev, 4),
+ gspca_dev-usb_buf, len, 0, 500);
+ if (rc 0)
+ PDEBUG(D_ERR, reg write [%02x] error %d, index,
rc);
+ return rc;
+}
The 'index' parameter is not useful: the register is always in the first
byte of the buffer.
[snip]
+/* this function is called at probe time */
+static int sd_config(struct gspca_dev *gspca_dev,
+ const struct usb_device_id *id)
+{
+ struct cam *cam;
+
+ cam = gspca_dev-cam;
+ cam-epaddr = 0x01;
This variable has been removed in the last versions of gspca.
+ cam-cam_mode = vga_mode;
+ cam-nmodes = ARRAY_SIZE(vga_mode);
+ return 0;
+}
[snip]
+static int sd_start(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ __u8 *data = gspca_dev-usb_buf;
+ int err_code;
+ int intpipe;
+
+ PDEBUG(D_STREAM, camera start, iface %d, alt 8,
gspca_dev-iface);
+ err_code = usb_set_interface(gspca_dev-dev,
gspca_dev-iface, 8);
+ if (err_code 0) {
+ PDEBUG(D_ERR|D_STREAM, Set packet size: set
interface error);
+ return err_code;
+ }
The usb_set_interface() is already done in the gspca main.
[snip]
+ sd-sof_read = 0;
+
+ intpipe = usb_sndintpipe(gspca_dev-dev, 0);
+ err_code = usb_clear_halt(gspca_dev-dev, intpipe);
Is this really needed?
+ data[0] = 0x00;
+ data[1] = 0x4d; /* ISOC transfering enable... */
+ reg_w(gspca_dev, data[0], 2);
+ return err_code;
+}
[snip]
--
Ken ar c'hentan | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] Siano 10234 big endian support
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1232021993 -7200
# Node ID 101e8cca3fad7a2f0fbc8249135bd35f5ca85b0e
# Parent d1b03bfce9d6d68ce586d7be33a41482f1b6cec7
Add big endian support
From: Uri Shkolnik u...@siano-ms.com
Add big endian support
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r d1b03bfce9d6 -r 101e8cca3fad linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileThu Jan 15 13:55:21 2009 +0200
+++ b/linux/drivers/media/dvb/siano/MakefileThu Jan 15 14:19:53 2009 +0200
@@ -31,7 +31,7 @@ SMS_SPI_PXA310_DRV := 0
# Default object, include in every build variant
-SMSOBJ := smscoreapi.o sms-cards.o
+SMSOBJ := smscoreapi.o sms-cards.o smsendian.o
EXTRA_CFLAGS += $(extra-cflags-y) $(extra-cflags-m)
diff -r d1b03bfce9d6 -r 101e8cca3fad linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cThu Jan 15 13:55:21
2009 +0200
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cThu Jan 15 14:19:53
2009 +0200
@@ -29,8 +29,10 @@
#include linux/uaccess.h
#include linux/firmware.h
+#include asm/byteorder.h
#include smscoreapi.h
+#include smsendian.h
#include sms-cards.h
#define MAX_GPIO_PIN_NUMBER31
@@ -475,9 +477,14 @@ static int smscore_load_firmware_family2
void *buffer, size_t size) {
struct SmsFirmware_ST *firmware = (struct SmsFirmware_ST *) buffer;
struct SmsMsgHdr_ST *msg;
- u32 mem_address = firmware-StartAddress;
+ u32 mem_address;
u8 *payload = firmware-Payload;
int rc = 0;
+
+ firmware-StartAddress = __le32_to_cpu(firmware-StartAddress);
+ firmware-Length = __le32_to_cpu(firmware-Length);
+
+ mem_address = firmware-StartAddress;
sms_info(loading FW to addr 0x%x size %d,
mem_address, firmware-Length);
@@ -496,6 +503,7 @@ static int smscore_load_firmware_family2
sms_debug(sending reload command.);
SMS_INIT_MSG(msg, MSG_SW_RELOAD_START_REQ,
sizeof(struct SmsMsgHdr_ST));
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)msg);
rc = smscore_sendrequest_and_wait(coredev, msg, msg-msgLength,
coredev-reload_start_done);
mem_address = *(u32 *) payload[20];
@@ -513,6 +521,7 @@ static int smscore_load_firmware_family2
DataMsg-MemAddr = mem_address;
memcpy(DataMsg-Payload, payload, payload_size);
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)msg);
if ((coredev-device_flags SMS_ROM_NO_RESPONSE)
(coredev-mode == DEVICE_MODE_NONE))
rc = coredev-sendrequest_handler(coredev-context,
@@ -544,6 +553,7 @@ DataMsg,
TriggerMsg-msgData[3] = 0; /* Parameter */
TriggerMsg-msgData[4] = 4; /* Task ID */
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)msg);
if (coredev-device_flags SMS_ROM_NO_RESPONSE) {
rc = coredev-sendrequest_handler(coredev-
context, TriggerMsg,
@@ -557,7 +567,7 @@ DataMsg,
} else {
SMS_INIT_MSG(msg, MSG_SW_RELOAD_EXEC_REQ,
sizeof(struct SmsMsgHdr_ST));
-
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)msg);
rc = coredev-sendrequest_handler(coredev-context, msg,
msg-msgLength);
}
@@ -706,6 +716,7 @@ static int smscore_detect_mode(struct sm
SMS_INIT_MSG(msg, MSG_SMS_GET_VERSION_EX_REQ,
sizeof(struct SmsMsgHdr_ST));
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)msg);
rc = smscore_sendrequest_and_wait(coredev, msg, msg-msgLength,
coredev-version_ex_done);
if (rc == -ETIME) {
@@ -829,6 +840,7 @@ int smscore_set_device_mode(struct smsco
sizeof(struct SmsMsgData_ST));
msg-msgData[0] = mode;
+ smsendian_handle_tx_message((struct SmsMsgHdr_ST *)msg);
rc = smscore_sendrequest_and_wait(coredev, msg,
msg-xMsgHeader. msgLength,
coredev-init_device_done);
@@ -1021,13 +1033,11 @@ void smscore_onresponse(struct smscore_d
data_total += cb-size;
/* If no client registered for type id,
* check for control client where type is not registered */
- sms_debug(phdr-msgType = %d t size = %d, phdr-msgType, data_total);
-
if (client)
rc = client-onresponse_handler(client-context, cb);
if (rc 0) {
-
Re: [v4l-dvb-maintainer] [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
On Tue, 2009-01-13 at 22:38 -0200, Mauro Carvalho Chehab wrote: On Tue, 13 Jan 2009 22:36:39 -0200 Mauro Carvalho Chehab mche...@infradead.org wrote: On Tue, 13 Jan 2009 19:26:31 -0500 Andy Walls awa...@radix.net wrote: Do you know what is the status when/if you could ask Mauro to apply the patch you send in the cx88-dvb: Fix order of frontend allocations... thread. Without that patch my system is at least crashing on 2.7.27.7 kernel when using the latest dvb-vl4 drivers. Not until Thursday night at the earliest. I never pushed the patch to my repo, and the patch only existed as a local diff and as a sent mail message on my hard drive that crashed. I have to fetch my patch from my backup or a mail archive, put it in a local repo, check that it is still OK, push it, and then submit a pull request. If you allow me, I will just apply it from what we have at linux-media. I forgot to post the link for it: http://patchwork.kernel.org/patch/1821/ Cheers, Mauro Acked-by: Andy Walls awa...@radix.net Fine by me. My day job has me working long hours this week. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix em28xx compilation warnings
Fix em28xx compilation warnings.
From: Nicola Soranzo nsora...@tiscali.it
Inline ac97_return_record_select() function to fix compilation warnings like:
CC [M] /home/nicola/v4l-dvb-11a5eb383205/v4l/em28xx-audio.o
/home/nicola/v4l-dvb-11a5eb383205/v4l/em28xx.h:326: warning:
'ac97_return_record_select' defined but not used
CC [M] /home/nicola/v4l-dvb-11a5eb383205/v4l/em28xx-video.o
/home/nicola/v4l-dvb-11a5eb383205/v4l/em28xx.h:326: warning:
'ac97_return_record_select' defined but not used
...
introduced by changeset 10228.
Priority: normal
Signed-off-by: Nicola Soranzo nsora...@tiscali.it
diff -ur v4l-dvb-11a5eb383205/linux/drivers/media/video/em28xx/em28xx.h v4l-
dvb-new/linux/drivers/media/video/em28xx/em28xx.h
--- v4l-dvb-11a5eb383205/linux/drivers/media/video/em28xx/em28xx.h
2009-01-14
08:58:36.0 +0100
+++ v4l-dvb-new/linux/drivers/media/video/em28xx/em28xx.h 2009-01-15
12:54:11.0 +0100
@@ -322,7 +322,7 @@
EM28XX_AOUT_PCM_PHONE = 7 8,
};
-static int ac97_return_record_select(int a_out)
+static inline int ac97_return_record_select(int a_out)
{
return (a_out 0x700) 8;
}
--
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] Siano 10236 SPI drv minor casting issue
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1232026755 -7200
# Node ID 50775d37b85469c33f4023203a6c54394163c4bd
# Parent 794f836ffef2b3300056c2f602768ad76ae25877
Fix minor casting issue
From: Uri Shkolnik u...@siano-ms.com
Fix minor casting issue in the SPI core driver
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 794f836ffef2 -r 50775d37b854
linux/drivers/media/dvb/siano/smsspicommon.c
--- a/linux/drivers/media/dvb/siano/smsspicommon.c Thu Jan 15 15:34:26
2009 +0200
+++ b/linux/drivers/media/dvb/siano/smsspicommon.c Thu Jan 15 15:39:15
2009 +0200
@@ -244,10 +244,11 @@ void smsspi_common_transfer_msg(struct _
if ((unused_bytes = 0) (bytes_to_transfer 0)) {
len = min(bytes_to_transfer, RX_PACKET_SIZE);
PRN_DBG((TXT(transfering block of %d bytes\n), len));
- dev-cb.transfer_data_cb(dev-phy_context, txbuf,
-tx_phy_addr,
-(char *)buf-ptr + offset,
-buf-phy_addr + offset, len);
+ dev-cb.transfer_data_cb(dev-phy_context,
+ (unsigned char *)txbuf,
+ tx_phy_addr,
+ (unsigned char *)buf-ptr + offset,
+ buf-phy_addr + offset, len);
}
missing_bytes =
smsspi_common_find_msg(dev, buf, offset, len,
--
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] The status and future of Mantis driver
Hans Werner wrote: Original-Nachricht Datum: Wed, 7 Jan 2009 15:58:08 +0200 Von: Igor M. Liplianin liplia...@tut.by An: linux-...@linuxtv.org Betreff: Re: [linux-dvb] The status and future of Mantis driver В сообщении от 6 January 2009 14:13:50 Pauli Borodulin написал(а): Heya! I found out that there is some new activity on Manu Abraham's Mantis driver, so I thought I could throw in some thoughts about it. I have been using Manu's Mantis driver (http://www.jusst.de/hg/mantis) for over two years now. I have a VP-2033 card (DVB-C) and at least for the last year the driver has worked without any hickups in my daily (VDR) use. For a long time I have thought that the driver should already be merged to the v4l-dvb tree. Igor M. Liplianin has created a new tree (http://mercurial.intuxication.org/hg/s2-liplianin) with the description DVB-S(S2) drivers for Linux. Mantis driver was merged into the tree in October and since then some fixes has also been applied to the driver. Some of these fixes already exist in Manu's tree, some don't. Both trees are missing the remote control support for VP-2033 and VP-2040. Until merging of the driver into s2-liplianin, there was a single tree for the Mantis driver development. Now that there are two trees, I fear that the development could scatter if there's no clear idea how the driver is going to get into v4l-dvb. Also, the driver is not only DVB-S(S2), but it also contains support for VP-2033 (DVB-C), VP-2040 (DVB-C) and VP-3030 (DVB-T). DVB-S(S2) stuff will probably greatly(?) delay getting the support for DVB-C/T Mantis cards into v4l-dvb. For my personal use I have created a patch against the latest v4l-dvb based on Manu's Mantis tree including the remote control support for VP-2033 and VP-2040. But what I would really like to see is Mantis driver merged into v4l-dvb and later into mainstream. Igor, what are your thoughts about the Mantis driver? How about the other Mantis users, like Marko Ristola, Roland Scheidegger, and Kristian Slavov? Anyone and everyone is permitted to take anything and everything from s2-liplianin. The tree was made for testing purposes. If it works, than it works:) Me and Manu Abraham is not a friends, so ask him to make a pull request for mantis. And after that we(we like community) with combined efforts bring it to v4l-dvb. Manu, will you issue the pull request for the mantis driver? The version at s2-liplianin is synchronised with the current kernel and is functional for a number of cards. No, the Mantis driver from the s2 liplianin tree will not be pulled in as it is. It is way under work. Look out for changes in the http://jusst.de/hg/mantis By just splitting up the user base, you have made this process a bit longer, that's what it is. Longer? On the contrary -- the s2-liplianin repository is well in advance of the one at jusst.de. I didn't split any userbase myself. I remind everyone that the repository at jusst.de does not compile with kernel 2.6.28 and does not use the current API, namely S2API. Fortunately the work to bring mantis up to date for the current kernel has already been done, just not by you, and it is in s2-liplianin. You could and should benefit rapidly from this like everyone else. To keep your userbase you need to get up to date and merge mantis into the kernel. Hans ___ 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 -- Release early, release often. Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a -- 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: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
On Thu, 15 Jan 2009 11:25:38 + Alec Christie alec.chris...@gmail.com wrote: I am getting the same with the Haupauge HVR-4000 after a recent Kernel Upgrade in Ubuntu Hardy (8.04). Any help greatly appreciated. Alec Christie 2009/1/15 Aaron Theodore aa...@bat.id.au Hi I'm running Debian with kernel: 2.6.24-etchnhalf.1-686 I recently baught a TeVii S420 DVB-S card and have been tring to get it to work. Firstly i built the v4l from: http://linuxtv.org/hg/v4l-dvb (hg clone) as the card was not detected. On first reboot after new modules are installed i get a kernel soft lockup cx88[0]/2: cx2388x based DVB/ATSC card BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1767] I just merged on http://linuxtv.org/hg/v4l-dvb a patch for fixing this bug. Please test. 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] Siano 10234 big endian support
On Thu, 15 Jan 2009, Uri Shkolnik wrote: + firmware-StartAddress = __le32_to_cpu(firmware-StartAddress); + firmware-Length = __le32_to_cpu(firmware-Length); Any reason you didn't just use le32_to_cpu()? -- 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://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx25840
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx25840 for the following: - cx25840: fix regression: fw not loaded on first use - cx25840: add comments explaining what the init() does. - v4l2 doc: explain why v4l2_device_unregister_subdev() has to be called. The first patch *must* go to 2.6.29, the other two are optional as they only change documentation and comments. Thanks to Mike Isely for finding this problem. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt |6 ++ drivers/media/video/cx25840/cx25840-core.c | 18 ++ include/media/cx25840.h | 12 3 files changed, 36 insertions(+) -- 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: KWorld ATSC 115 all static
On Thu, 15 Jan 2009 09:30:35 -0500 Michael Krufky mkru...@linuxtv.org wrote: Hey Hans, Hans Verkuil wrote: Hans Verkuil wrote: On Thursday 15 January 2009 06:01:28 CityK wrote: Hans Verkuil wrote: OK, I couldn't help myself and went ahead and tested it. It seems fine, so please test my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134 Let me know if it works. Hi Hans, It didn't work. No analog reception on either RF input. (as Mauro noted, DVB is unaffected; it still works). dmesg output looks right: tuner-simple 1-0061: creating new instance tuner-simple 1-0061: type set to 68 (Philips TUV1236D ATSC/NTSC dual in) I tried backing out of the modules and then reloading them, but no change. (including after fresh build or after rebooting) Can you give the full dmesg output? Also, is your board suppossed to have a tda9887 as well? Hans' changes are not enough to fix the ATSC115 issue. Ah, OK. I believe that if you can confirm that the same problem exists, but the previous workaround continues to work even after Hans' changes, then I believe that confirms that Hans' changes Do the Right Thing (tm). ATSC115 is broken not because the tuner type assignment has been removed from attach_inform. This is actually a huge problem across all analog drivers now, since we are no longer able to remove the tuner module and modprobe it again -- the second modprobe will not allow for an attach, as there will be no way for the module to be recognized without having the glue code needed inside attach_inform... Huh? Why would you want to rmmod and modprobe tuner? Anyway, drivers that use v4l2_subdev (like my converted saa7134) will increase the tuner module usecount, preventing it from being rmmod'ed. There was a load order dependency in the saa7134 driver. Some users have to remove tuner and modprobe it again in order to make analog tv work. Yes, that's a bug. The bug got worse when Mauro made changes to attach_inform -- I believe this was for the sake of some xceive tuners... I don't recall the details now. Anyway, long story short... there are many different bugs all manifesting themselves at once here. Load order dependency -- I don't think we ever understood why that issue exists. The fix for the load order dependency no longer works, as attach_inform no longer cares if a new tuner appears on the bus. It has nothing to do with the load order. It is related to i2c binding. With the current approach (before Hans patch), the i2c core will try to bind the tuner after having 2 conditions satisfied: 1) I2C bus were registered; 2) tuner code is available. So, if you load tuner before saa7134 (or have it compiled in-kernel), the code will try to probe tuners at the moment you register i2c bus. Otherwise, it will try to bind only when request_module is handled. Some devices with DVB has an internal i2c gate. For a subset of these, the i2c gate is inside the tuner. So, you need to bind the tuner device before probing for the frontends. On the other set of devices, the gate is inside the demod. So, you need to turn the i2c gate before running the i2c address seek for tuner. This generated lots of issues in the past, like machines with two boards doesn't work anymore. With two boards, and a tuner module, the first board probes tuner after opening the demod gateway. However, the second board will try to probe tuner before opening the i2c gateway. So, tuner is not found. - After having Hans patches working, we need to implement the following workflow inside the driver: 1) register the i2c bus and load tuner (the order shouldn't be relevant anymore, since the attachment is not related anymore with i2c bus register and/or with tuner load); 2) call the i2c open gate control, if it needs to open the demod i2c gate in order to access the tuner; 3) tuner type is determined via eeprom and/or board entry; 3) tuner i2c address is scanned and tuner is bound with the proper type; 4) the i2c open gate control is called, if needed in order to access the demod; 5) demod is bound. So, my ATSC115 hack-patch restored the attach_inform functionality for the sake of ATSC110/115 users. I am not pushing for its merge -- this *will* break the boards that Mauro was working on when he changed attach_inform. As I don't really understand what he was going for when he made those changes, I don't know how to fix this problem without creating new bugs on Mauro's cards. I put out that patch in hopes that somebody else would put the pieces together and make a better fix that would work for everybody. That hasn't happened yet :-( Hacks won't be needed anymore. All we need is to fix the board entries, properly identifying what is needed to access tuner and/or demod, and double check what devices need
Re: MSI DigiVox A/D II
Hm, now I installed the Intrepid Kernel via echo 'deb http://archive.ubuntu.com/ubuntu/ intrepid main restricted' | sudo tee /etc/apt/sources.list.d/intrepid-kernel.list sudo apt-get update sudo apt-get -y install linux linux-generic linux-headers-generic linux-image-generic linux-restricted-modules-generic sudo rm /etc/apt/sources.list.d/intrepid-kernel.list sudo apt-get update When I rebooted my pc and plugged in my tv stick, dmesg showed me it was detected as Kworld VS-DVB-T 323UR - the USB-ID is eb1a:e323. Well, this isn't my card, but it's the same USB-ID. When I started up tvtime, video was scrambled, but the audio device is listed in arecord -l. So I tried modprobe em28xx card=50, which is my MSI DigiVox A/D II - the video was alright, but when I ran arecord -D hw:1,0 -f dat | aplay -f dat , I only got buffer underruns. So I pulled a fresh copy from hg, compiled installed it, rebooted, plugged - now the stick gets detected without the card=50 option, but still only buffer underruns in arecord | aplay. what now? greetings, Bastian Devin Heitmueller wrote: On Tue, Jan 13, 2009 at 6:09 PM, Bastian Beekes bastian.bee...@gmx.de wrote: Hm, ok... thanks for your reply in *no time* :) So is the only option to upgrade to 8.10? I'd prefer to stick with the LTS release... Bastian I suspect there is some hackary you could do if you install the kernel source and recompile to include properly include CONFIG_SND, but nobody ever went through the effort (as far as I know). I believe Markus did in his codebase, which is why he has been distributing binaries for Ubuntu instead of having people build from source (but I could be wrong there). The core of the issue is Ubuntu provided an updated ALSA separate from the rest of the kernel distro, but then screwed up the kernel headers so that we think ALSA isn't present, so v4l-dvb doesn't compile any of the alsa modules. Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Add Freescale MC44S803 tuner driver
Hi Alexey,
+/* This functions tries to identify a MC44S803 tuner by reading the ID
+ register. This is hasty. */
+struct dvb_frontend *mc44s803_attach(struct dvb_frontend *fe,
+struct i2c_adapter *i2c, struct mc44s803_config *cfg)
+{
+ struct mc44s803_priv *priv = NULL;
Do you really need *priv set to NULL here ?
No, it's not needed. Will remove.
+ priv = kzalloc(sizeof(struct mc44s803_priv), GFP_KERNEL);
+ if (priv == NULL)
+ return NULL;
Maybe return -ENOMEM; ? I don't sure about return NULL, may be your
variant is right.
NULL is correct here. All tuners are supposed to return NULL on an error during
attach().
+ if (id != 0x14) {
+ printk(KERN_ERROR MC44S803: unsupported ID
You pass the name of driver directly to printk messages in few places.
Is it better to use such approach:
#define MC44S803_DRIVER_NAME mc44s803
printk (KERN_ERR MC44S803_DRIVER_NAME : something\n);
?
What do you think?
You're right.
Thanks for your comments.
Jochen
--
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] Siano 10226 Siano sub-system
--- On Thu, 1/15/09, Trent Piepho xy...@speakeasy.org wrote: From: Trent Piepho xy...@speakeasy.org Subject: Re: [PATCH] Siano 10226 Siano sub-system To: Uri Shkolnik uri...@yahoo.com Cc: linux-media@vger.kernel.org Date: Thursday, January 15, 2009, 7:44 PM On Tue, 13 Jan 2009, Uri Shkolnik wrote: --- On Wed, 1/14/09, Trent Piepho xy...@speakeasy.org wrote: From: Trent Piepho xy...@speakeasy.org Subject: Re: [PATCH] Siano 10226 Siano sub-system To: Uri Shkolnik uri...@yahoo.com Cc: linux-media@vger.kernel.org Date: Wednesday, January 14, 2009, 12:54 AM On Tue, 13 Jan 2009, Uri Shkolnik wrote: This patch adds Siano subsystem, which supports the CMMB and T-DMB DTV standards. The patch also adds Network interface (network driver) in order to support the DVB-H and DAB-IP standards. Commit messages should be wrapped to 75 columns. Thanks. Will be corrected ASAP. Where can I find checklist for that? (coding style and checkpatch.pl are for the source code itself. Which document that covers this?) In the commit message make commit you to fill in, it says 74 characters. In README.patches the instructions are slightly different, it says 68 characters for the title and 80 characters for the body of the commit message. That should probably be updated. I'm not sure where it says that commit messages in the kernel, or simply for git in general, should be 75 columns. If you use stgit, the initial commit message tells you that. I think most developers just notice that since git indents each line of the commit message by 4 spaces when you look at the commit with git log or git show, that they look like crap on an 80 column terminal if the lines aren't wrapped at 75 characters. I fully understand now. To be on the safe side (maybe too safe), I'll use the minimum (68), even if it might be wrong (7 characters won't effect it much anyway). Thanks for the explanation. Uri -- 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: KWorld ATSC 115 all static
On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: It has nothing to do with the load order. It is related to i2c binding. With the current approach (before Hans patch), the i2c core will try to bind the tuner after having 2 conditions satisfied: 1) I2C bus were registered; 2) tuner code is available. So, if you load tuner before saa7134 (or have it compiled in-kernel), the code will try to probe tuners at the moment you register i2c bus. Otherwise, it will try to bind only when request_module is handled. Some devices with DVB has an internal i2c gate. For a subset of these, the i2c gate is inside the tuner. So, you need to bind the tuner device before probing for the frontends. On the other set of devices, the gate is inside the demod. So, you need to turn the i2c gate before running the i2c address seek for tuner. I wonder if a better way to fix these problems is to use virtual I2C busses for the gate? When a device has some kind of i2c gate, it creates a new I2C adapter for the devices behind the gate. The code for this virtual i2c adapter can just open the gate, pass of the request to the main i2c adapter, then close the gate. Creating a new i2c adapter should trigger the i2c drivers that scan to do so and find new devices behind the gate. It seems like this would solve the scan order problem, since the bus the tuner/demod/whatever is on won't exist until the gate it is behind can be properly controlled. There are a number of additional benefits too. There are many devices that can be behind many different kinds of gates. So we have all these gate control functions that must be called manually from all over the place. This adds bloat and developers are always forgetting to call them, which doesn't cause any problem they notice because their card doesn't have a gate. With manual gate control, we must remember to close the gate when done with the device. But this isn't always done and the gate is left open. These gates are there for a reason, to shield RF devices from noise created by the I2C bus, and so leaving them opens impairs RF performance. And when the gate is only controlled by the driver in the kernel, it is hard to manually debug/test i2c devices from userspace with i2c-dev. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Thu Jan 15 19:00:04 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10241:7981bdd4e25a 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc1-armv5: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29-rc1-armv5-ixp: ERRORS linux-2.6.27-armv5-omap2: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-rc1-armv5-omap2: ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29-rc1-i686: ERRORS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc1-m32r: ERRORS linux-2.6.16.61-mips: OK linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29-rc1-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc1-powerpc64: ERRORS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK 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-rc1-x86_64: ERRORS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc1): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 -- 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: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
Mauro, Thanks for the speedy patch! My system can at least boot now, but has issues loading the frontend. Linux video capture interface: v2.00 cx88/0: cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt :05:08.0[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 cx88[0]: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73,autodetected], frontend(s): 1 cx88[0]: TV tuner type -1, Radio tuner type -1 cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded tuner' 2-0068: chip found @ 0xd0 (cx88[0]) cx88[0]/0: found at :05:08.0, rev: 5, irq: 18, latency: 32, mmio: 0xd800 cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 tuner' 2-0068: tuner type not set cx88[0]/2: cx2388x 8802 Driver Manager ACPI: PCI Interrupt :05:08.2[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 cx88[0]/2: found at :05:08.2, rev: 5, irq: 18, latency: 32, mmio: 0xd900 ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI Interrupt :00:04.0[A] - Link [APCJ] - GSI 22 (level, low) - IRQ 17 PCI: Setting latency timer of device :00:04.0 to 64 cx88/2: cx2388x dvb driver version 0.0.6 loaded cx88/2: registering cx8802 driver, type: dvb access: shared cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] cx88[0]/2: cx2388x based DVB/ATSC card cx8802_alloc_frontends() allocating 1 frontend(s) DVB: Unable to find symbol stv0299_attach() DVB: Unable to find symbol stv0288_attach() cx88[0]/2: frontend initialization failed cx88[0]/2: dvb_register failed (err = -22) cx88[0]/2: cx8802 probe failed, err = -22 thanks Aaron On 16/01/2009 2:55 AM, Mauro Carvalho Chehab wrote: On Thu, 15 Jan 2009 11:25:38 + Alec Christie alec.chris...@gmail.com wrote: I am getting the same with the Haupauge HVR-4000 after a recent Kernel Upgrade in Ubuntu Hardy (8.04). Any help greatly appreciated. Alec Christie 2009/1/15 Aaron Theodore aa...@bat.id.au Hi I'm running Debian with kernel: 2.6.24-etchnhalf.1-686 I recently baught a TeVii S420 DVB-S card and have been tring to get it to work. Firstly i built the v4l from: http://linuxtv.org/hg/v4l-dvb (hg clone) as the card was not detected. On first reboot after new modules are installed i get a kernel soft lockup cx88[0]/2: cx2388x based DVB/ATSC card BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1767] I just merged on http://linuxtv.org/hg/v4l-dvb a patch for fixing this bug. Please test. 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 -- 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: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
Firstly i built the v4l from: http://linuxtv.org/hg/v4l-dvb (hg clone) as the card was not detected. On first reboot after new modules are installed i get a kernel soft lockup cx88[0]/2: cx2388x based DVB/ATSC card BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1767] I just merged on http://linuxtv.org/hg/v4l-dvb a patch for fixing this bug. Please test. Works now ok for me, vdr-1.6.0 is able to show the dvb-t channels by using hvr-1300 and dvb-s channels by using the hvr-4000. vdr-1.7.3 works for me only for dvb-t channels but dvb-s/s2 channels with hvr-4000 does not tune. Mika -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4] Add Freescale MC44S803 tuner driver
Signed-off-by: Jochen Friedrich joc...@scram.de
---
Changes since v1:
- rebase against official linux tree. v1 was based against a local tree and
didn't apply cleanly.
Changes since v2:
- fix typo KERN_ERROR - KERN_ERR
Changes since v3:
- fix circuit adjust (reserved bits should be 1)
- don't initialize priv in mc44s803_attach()
- use a macro for printk to avoid duplicating the driver name over and over.
drivers/media/common/tuners/Kconfig |8 +
drivers/media/common/tuners/Makefile|1 +
drivers/media/common/tuners/mc44s803.c | 370 +++
drivers/media/common/tuners/mc44s803.h | 46
drivers/media/common/tuners/mc44s803_priv.h | 208 +++
5 files changed, 633 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/common/tuners/mc44s803.c
create mode 100644 drivers/media/common/tuners/mc44s803.h
create mode 100644 drivers/media/common/tuners/mc44s803_priv.h
diff --git a/drivers/media/common/tuners/Kconfig
b/drivers/media/common/tuners/Kconfig
index 6f92bea..7969b69 100644
--- a/drivers/media/common/tuners/Kconfig
+++ b/drivers/media/common/tuners/Kconfig
@@ -29,6 +29,7 @@ config MEDIA_TUNER
select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMIZE
select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMIZE
select MEDIA_TUNER_TDA9887 if !MEDIA_TUNER_CUSTOMIZE
+ select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMIZE
menuconfig MEDIA_TUNER_CUSTOMIZE
bool Customize analog and hybrid tuner modules to build
@@ -164,4 +165,11 @@ config MEDIA_TUNER_MXL5007T
help
A driver for the silicon tuner MxL5007T from MaxLinear.
+config MEDIA_TUNER_MC44S803
+ tristate Freescale MC44S803 Low Power CMOS Broadband tuners
+ depends on VIDEO_MEDIA I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ Say Y here to support the Freescale MC44S803 based tuners
+
endif # MEDIA_TUNER_CUSTOMIZE
diff --git a/drivers/media/common/tuners/Makefile
b/drivers/media/common/tuners/Makefile
index 4dfbe5b..4132b2b 100644
--- a/drivers/media/common/tuners/Makefile
+++ b/drivers/media/common/tuners/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_MEDIA_TUNER_QT1010) += qt1010.o
obj-$(CONFIG_MEDIA_TUNER_MT2131) += mt2131.o
obj-$(CONFIG_MEDIA_TUNER_MXL5005S) += mxl5005s.o
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
+obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/common/tuners/mc44s803.c
b/drivers/media/common/tuners/mc44s803.c
new file mode 100644
index 000..45d6160
--- /dev/null
+++ b/drivers/media/common/tuners/mc44s803.c
@@ -0,0 +1,370 @@
+/*
+ * Driver for Freescale MC44S803 Low Power CMOS Broadband Tuner
+ *
+ * Copyright (c) 2009 Jochen Friedrich joc...@scram.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.=
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/dvb/frontend.h
+#include linux/i2c.h
+
+#include dvb_frontend.h
+
+#include mc44s803.h
+#include mc44s803_priv.h
+
+#define mc_printk(level, format, arg...) \
+ printk(level mc44s803: format , ## arg)
+
+/* Writes a single register */
+static int mc44s803_writereg(struct mc44s803_priv *priv, u32 val)
+{
+ u8 buf[3];
+ struct i2c_msg msg = {
+ .addr = priv-cfg-i2c_address, .flags = 0, .buf = buf, .len = 3
+ };
+
+ buf[0] = (val 0xFF) 16;
+ buf[1] = (val 0xFF00) 8;
+ buf[2] = (val 0xFF);
+
+ if (i2c_transfer(priv-i2c, msg, 1) != 1) {
+ mc_printk(KERN_WARNING, I2C write failed\n);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+/* Reads a single register */
+static int mc44s803_readreg(struct mc44s803_priv *priv, u8 reg, u32 *val)
+{
+ u32 wval;
+ u8 buf[3];
+ u8 ret;
+ struct i2c_msg msg[] = {
+ { .addr = priv-cfg-i2c_address, .flags = I2C_M_RD,
+ .buf = buf, .len = 3 },
+ };
+
+ wval = MC44S803_REG_SM(MC44S803_REG_DATAREG, MC44S803_ADDR) |
+ MC44S803_REG_SM(reg, MC44S803_D);
+
+ ret = mc44s803_writereg(priv, wval);
+ if (ret)
+ return ret;
+
+ if (i2c_transfer(priv-i2c, msg, 1) != 1) {
+
RE: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
HVR4000 DVB-S/S2 now works for me (not sure about DVB-T as I don't use it), thanks for the speedy patch! Alec -Original Message- From: Mika Laitio [mailto:lam...@pilppa.org] Sent: 15 January 2009 20:14 To: Mauro Carvalho Chehab Cc: Alec Christie; linux-media@vger.kernel.org Subject: Re: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420) Firstly i built the v4l from: http://linuxtv.org/hg/v4l-dvb (hg clone) as the card was not detected. On first reboot after new modules are installed i get a kernel soft lockup cx88[0]/2: cx2388x based DVB/ATSC card BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:1767] I just merged on http://linuxtv.org/hg/v4l-dvb a patch for fixing this bug. Please test. Works now ok for me, vdr-1.6.0 is able to show the dvb-t channels by using hvr-1300 and dvb-s channels by using the hvr-4000. vdr-1.7.3 works for me only for dvb-t channels but dvb-s/s2 channels with hvr-4000 does not tune. Mika -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
On Fri, 16 Jan 2009 06:56:05 +1100 Aaron Theodore aa...@bat.id.au wrote: Mauro, Thanks for the speedy patch! You should thanks to Andy. He is the author of this patch ;) My system can at least boot now, but has issues loading the frontend. DVB: Unable to find symbol stv0299_attach() DVB: Unable to find symbol stv0288_attach() It seems that you didn't compile those two frontends. 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: eMPIA camera support?
hermann pitton wrote: Am Sonntag, den 28.12.2008, 21:54 -0500 schrieb CityK: hermann pitton wrote: schrieb CityK: While the bttv gallery remains a very useful resource, I don't believe that Gunther is maintaining it any more. In any regard let s use the V4L-DVB wiki (http://www.linuxtv.org/wiki/index.php/Main_Page), as it is best to keep the information all in one place (i.e. a centralized repository of knowledge and information), as opposed to spread out across multiple 3rd party sources. let's see. It still has lots of advantages. Hacking of hundreds of tuners and advanced gpio and eeprom detection was coordinated there on requests for research coming up on the lists and it has several thousand contributors. A wiki was not even in sight then. I would prefer to see it further maintained for easy searching on hard facts. At least don't call it third party. That is as mad as if you would call the video4linux-list or bytesex.org third party. It is/was to that point the official hardware resource and Gunther a leading tuner/hardware developer and nothing else. This is true, and I don't mean to offend anyone's sensibilities about it. Likewise, I did state that it remains a very useful resource. However, I haven't seen a word of boo from Gunther in probably two years time. Secondly, some of those users that I had, in the past, requested that they submit material to the bttv-gallery have later written/replied to me that their submissions went unanswered/unacknowledged. Thirdly, despite Gunther's distinguished history and involvement, it is likely unclear to an unassuming end user that there is anything other then a passing relation between the project and the bttv-gallery. That is all OK so far. But it is not about sensibilities, but usability in the first place. Your points are duly noted ... and I have attempted to convey the crux of your message in the note provided here: http://www.linuxtv.org/wiki/index.php/Development:_How_to_add_support_for_a_device#Don.27t_forget_to_send_info_to_the_Wiki_.21 I give an example in short. http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards This starts with some ASUS My Cinema P7131-Dual model and the photos are taken from there. But that user had a P7131 Hybrid and he was the only one ever reporting problems like this, DVB, VDR, (***unstable*** causes random memory corruption and crashes), but stays on top of all recent PCI cards with hybrid tuners and speaks for all Asus saa713x ... This should be meanwhile eight different cards including the not yet externally documented Asus Tiger 3in1 I guess. It of cause continues here. http://linuxtv.org/wiki/index.php/ASUS_My_Cinema-P7131_Hybrid Almost all is wrong or at least not differentiated enough. If you look at the bttv-gallery for the related cards, there is at least _nothing_ wrong. Well, in these particular regards, I can only reply with what I have previously noted in the wiki in several places, such as: - from the Main page welcome message: Like all other wikis, the V4L-DVB wiki relies upon the contributions of its users. Hence, it will only be as useful as we make it! - from the DVB-T PCI Cards' note entitled Please be aware that: The information contained here is likely non-exhaustive and, despite best efforts to do otherwise, may contain errors. (Please help to keep these lists up-to-date so that they are useful for everyone!) -- 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/2] Add Mars-Semi MR97310A format
On Thursday 15 January 2009 05:49:46 Jean-Francois Moine wrote: On Wed, 14 Jan 2009 20:59:34 -0600 Kyle Guinn ely...@gmail.com wrote: Add a pixel format for the Mars-Semi MR97310A webcam controller. The MR97310A is a dual-mode webcam controller that provides compressed BGGR Bayer frames. The decompression algorithm for still images is the same as for video, and is currently implemented in libgphoto2. Hi Kyle, What is the difference of this pixel format from the other Bayer ones? This is a standard BGGR Bayer format which is compressed using a vendor-specific compression algorithm, much like V4L2_PIX_FMT_PAC207. I don't believe the compression algorithm matches any of the other pixel formats. The first two pixels in the first two rows are stored as raw 8-bit values (the top-left BGGR square), but the rest is Huffman compressed. Take a look at precalc_table() and mars_decompress() in libgphoto2/camlibs/mars/mars.c for all of the details. If you recognize this as an existing pixel format, please let me know. Also, did you ask Hans de Goede to add the decoding to the v4l library? That is next on my TODO list. I have a patch ready to send, but I first want to make sure there are no problems with adding this pixel format. Regards, -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
Fw: [PATCH] E506r-composite-input
Message sent to the wrong address... it is not *-owner ;)
Forwarded message:
Date: Thu, 15 Jan 2009 21:58:55 +0900
From: Tim Farrington t...@iinet.net.au
To: Mauro Carvalho Chehab mche...@infradead.org,
linux-media-ow...@vger.kernel.org
Subject: [PATCH] E506r-composite-input
Make correction to composite input plus svideo input
to Avermedia E506R
Signed-off-by: Tim Farrington t...@iinet.net.au
Cheers,
Mauro
Only in .: E506r_composite.patch
diff -upr ./linux/drivers/media/video/saa7134/saa7134-cards.c ../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c
--- ./linux/drivers/media/video/saa7134/saa7134-cards.c 2009-01-15 21:42:05.0 +0900
+++ ../a/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-01-15 21:45:29.0 +0900
@@ -4362,13 +4362,13 @@ struct saa7134_board saa7134_boards[] =
.amux = TV,
.tv = 1,
}, {
- .name = name_comp,
- .vmux = 0,
+ .name = name_comp1,
+ .vmux = 3,
.amux = LINE1,
}, {
.name = name_svideo,
.vmux = 8,
- .amux = LINE1,
+ .amux = LINE2,
} },
.radio = {
.name = name_radio,
Re: KWorld ATSC 115 all static
Hans Verkuil wrote: is your board suppossed to have a tda9887 as well? Hi Hans, Yes, indeed, the device does contain the tda9887. Hans' changes are not enough to fix the ATSC115 issue. Ah, OK. I believe that if you can confirm that the same problem exists, but the previous workaround continues to work even after Hans' changes, then I believe that confirms that Hans' changes Do the Right Thing (tm). err, I'm afraid I might be reading to much into your statement Michael --- if you meant to question whether, after building Hans' changes, a modprobe tuner -r and modprobe tuner worked, then the answer is no, such did not work. (no results in dmesg are observed either, much like what was discussed later; specifically: we are no longer able to remove the tuner module and modprobe it again -- the second modprobe will not allow for an attach, as there will be no way for the module to be recognized If you had meant taking Hans' source and applying your hack patch to them, building and then proceeding with the modprobe steps, the answer is that I haven't tried yet. Will test -- might not be tonight though, as I have some other things that need attending too. Anyway, if the previous workaround works after Hans' changes, then I think his changes should be merged -- even though it doesnt fix ATSC115, it is indeed a step into the right direction. If the ATSC115 hack-fix patch doesn't apply anymore, please let me know -- I'll respin it. Given this statement, then perhaps it was a case of the latter. As mentioned, I will rebuild and test. Hans, given the discussion that is developed, I don't think the dmesg output is necessary at this point (if you really insist though I will provide :P ). P.S. I think Trent's idea sounds interesting/warrants some consideration. -- 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] Pinnacle dual Hybrid pro PCI-express - linuxTV!
Catimimi wrote: CityK a écrit : Could you put it in the wiki if its not already contained there. Thanks. It was done yesterday. Yep, saw that about 10 minutes later after I responded to this message :P . Thanks. -- 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] Siano 10226 Siano sub-system
Uri Shkolnik wrote: Where can I find checklist for that? (coding style and checkpatch.pl are for the source code itself. Which document that covers this?) In addition to the info Trent provided, if you haven't already found it, there are a couple of documents in /usr/src/linux/Documentation that are worthwhile skimming through. We have repeated them here in the wiki, under the development section: - http://www.linuxtv.org/wiki/index.php/Development:_Coding_Style - http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches - http://www.linuxtv.org/wiki/index.php/Development:_Linux_Kernel_patch_submittal_checklist - http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Drivers As well as providing our own brief notice: - http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] em28xx: Fix audio URB transfer buffer memory leak and race condition/corruption of capture pointer
Hi Robert, I don't know if you're aware, but we've recently switched mailing lists for which patches should be submitted (see Mauro's note: http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab) ... I've been busy trying to update the likes of articles such as http://www.linuxtv.org/wiki/index.php/Development:_How_to_submit_patches that may have still contained instructions/links to the older mailing lists. Sorry for the inconvenience. Unless Mauro, or a driver maintainer has already picked them up, please resend them to the new list. -- 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: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
I tried: make rmmod make rminstall Although there were still some drivers left over from tevii_linuxdriver_0815 /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s600.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s650.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36067.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36060.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36050.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/saa7134/saa7134-oss.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36016.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/tuner-3036.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/videocodec.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/dpc7146.ko so i just removed manually and rebooted. Same issue occurred on reboot. So i thought to try manually unloading and reloading the module barry:~# rmmod cx8802 barry:~# modprobe cx8802 kernel: cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded kernel: cx88[0]/2: cx2388x 8802 Driver Manager kernel: ACPI: PCI Interrupt :05:08.2[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 kernel: cx88[0]/2: found at :05:08.2, rev: 5, irq: 18, latency: 32, mmio: 0xd900 kernel: cx88/2: cx2388x dvb driver version 0.0.6 loaded kernel: cx88/2: registering cx8802 driver, type: dvb access: shared kernel: cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] kernel: cx88[0]/2: cx2388x based DVB/ATSC card kernel: cx8802_alloc_frontends() allocating 1 frontend(s) kernel: DVB: registering new adapter (cx88[0]) kernel: DVB: registering adapter 2 frontend 0 (ST STV0288 DVB-S)... This time it makes the devices in /dev/dvb/ Now unfortunately i can't test to see if it can actually Tune until a few hours time when i get home (i think i forgot to plug my satellite cable back in!) Will report back later Can i change the load order of kernel modules, it dosnt seem to like being loaded before my other dvb modules Aaron - Mauro Carvalho Chehab mche...@infradead.org wrote: On Fri, 16 Jan 2009 06:56:05 +1100 Aaron Theodore aa...@bat.id.au wrote: Mauro, Thanks for the speedy patch! You should thanks to Andy. He is the author of this patch ;) My system can at least boot now, but has issues loading the frontend. DVB: Unable to find symbol stv0299_attach() DVB: Unable to find symbol stv0288_attach() It seems that you didn't compile those two frontends. 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://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 15 Jan 2009 18:41:33 +0100 Carsten Meier c...@trexity.de wrote: OK. Well, the usage he wants is something that is better fitted by using sysfs info. There, you should have all information to uniquely identify a device: driver, bus location (on PCI this can be relevant), MAC (for dvb devices), etc. IMO, the proper way is to add the serial number at sysfs, and let the bus_info point to the proper bus location. Having the bus location, an userspace app can seek the sysfs and look for the udev info. For example, on an em28xx analog device I have here, bus_info returns 1-3. Ok, this is a very bad way to specify the bus. IMO, we should use usb_make_path() to generate the canonical name for USB buses. Anyway, by getting this information, and looking at sysfs, we'll see lots of very useful information [1]. By parsing the info, we know that: the v4l driver is em28xx; the audio driver is snd-usb-audio (card1); the event interface is input10; this device uses two i2c modules: saa7115 and tuner; the device has no dvb interface. It should be easy to extend it to provide more info, like the serial number. This will also help udev to create a permanent name for the known devices, as it does with internet interfaces. Cheers, Mauro Hi, I'm the originator of this topic. Sorry, but I don't agree here. If I start to parse the bus_info string, my app will only work with device-drivers which return a canonical sysfs-path here. Since some devices currently doesn't provide an unique name at bus_info, any solution will be applied on kernel 2.6.30 anyway. The window for such changes on 2.6.29 were already closed. To achive this, actually a new field in the capability-struct must be defined, Adding an extra string field for VIDIOC_QUERYCAP will break binary only compatibility. This is not allowed. because the specs don't put any contrains on the bus_info-string. (some space is left there) Any solution will need to review the specs. And even if I parse the string to somehow obtain a sysfs-path, then I have to distinguish devices which have a serial-no and which don't. This leads to a unmaintainable situation. Almost all devices don't provide a readable serial number, or we don't know how to obtain it. We just know the serial numbers on the devices for one manufacturer (and a few other USB ones that provide a serial number at the usb serial id field). What bus_info must be to make it of any use is that it must contain a string that won't change if the device reconnects (at least to the same port; manually or due to system-wakeup) A driver can do its best guess here (serial-no, slot or *constant* USB-port or whatever) I think this is the *only* V4L2-conforming solution to the problem. For usb devices, usb_make_path() provide a canonical name for the device. For PCI ones, we have pci_name() for the same function. in the case of pci devices, I suspect that all use pci_name(). We just need to use usb_make_path() at the usb ones. Currently, only the IR part of most of the drivers use the usb canonical name. It is trivial to convert the remaining ones to use it. It is just a matter of replacing the string copy function to a usb_make_path() call. Something like replacing: strlcpy(cap-bus_info,pvr2_hdw_get_bus_info(hdw), sizeof(cap-bus_info)); by: usb_make_path(hdw-usb_dev, cap-bus_info, sizeof(cap-bus_info)); 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
The pvrusb2 stuff you just pulled
Mauro: Do you not find it strange that you show up as the credited source for my recent changesets on the summary page http://linuxtv.org/hg/v4l-dvb? (See 10236 - 10240.) I suspect it's because you cherry picked them, but that doesn't make it right. I could have sworn in the past that I've been able to pull in changes / contributions into hg from other pvrusb2 users and successfully preserved the credit in the change list summary. What's the problem here? -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: kernel soft lockup on boot loading cx2388x based DVB-S card (TeVii S420)
Horay my TeVii DVB-S S420 is now working, only thing now is to work out why it wont load on boot before my DVB-T card On 16/01/2009 3:19 PM, Aaron Theodore wrote: I tried: make rmmod make rminstall Although there were still some drivers left over from tevii_linuxdriver_0815 /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s600.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/dvb-usb/dvb-usb-s650.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36067.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36060.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36050.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/saa7134/saa7134-oss.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/zr36016.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/tuner-3036.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/videocodec.ko /lib/modules/2.6.24-etchnhalf.1-686/kernel/drivers/media/video/dpc7146.ko so i just removed manually and rebooted. Same issue occurred on reboot. So i thought to try manually unloading and reloading the module barry:~# rmmod cx8802 barry:~# modprobe cx8802 kernel: cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded kernel: cx88[0]/2: cx2388x 8802 Driver Manager kernel: ACPI: PCI Interrupt :05:08.2[A] - Link [APC3] - GSI 18 (level, low) - IRQ 18 kernel: cx88[0]/2: found at :05:08.2, rev: 5, irq: 18, latency: 32, mmio: 0xd900 kernel: cx88/2: cx2388x dvb driver version 0.0.6 loaded kernel: cx88/2: registering cx8802 driver, type: dvb access: shared kernel: cx88[0]/2: subsystem: d420:9022, board: TeVii S420 DVB-S [card=73] kernel: cx88[0]/2: cx2388x based DVB/ATSC card kernel: cx8802_alloc_frontends() allocating 1 frontend(s) kernel: DVB: registering new adapter (cx88[0]) kernel: DVB: registering adapter 2 frontend 0 (ST STV0288 DVB-S)... This time it makes the devices in /dev/dvb/ Now unfortunately i can't test to see if it can actually Tune until a few hours time when i get home (i think i forgot to plug my satellite cable back in!) Will report back later Can i change the load order of kernel modules, it dosnt seem to like being loaded before my other dvb modules Aaron - Mauro Carvalho Chehab mche...@infradead.org wrote: On Fri, 16 Jan 2009 06:56:05 +1100 Aaron Theodore aa...@bat.id.au wrote: Mauro, Thanks for the speedy patch! You should thanks to Andy. He is the author of this patch ;) My system can at least boot now, but has issues loading the frontend. DVB: Unable to find symbol stv0299_attach() DVB: Unable to find symbol stv0288_attach() It seems that you didn't compile those two frontends. 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 -- 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
