Re: [Q] udev and soc-camera
On Thu, Jan 28, 2010 at 00:25, Valentin Longchamp valentin.longch...@epfl.ch wrote: I have a system that is built with OpenEmbedded where I use a mt9t031 camera with the soc-camera framework. The mt9t031 works ok with the current kernel and system. However, udev does not create the /dev/video0 device node. I have to create it manually with mknod and then it works well. If I unbind the device on the soc-camera bus (and then eventually rebind it), udev then creates the node correctly. This looks like a timing issue at coldstart. OpenEmbedded currently builds udev 141 and I am using kernel 2.6.33-rc5 (but this was already like that with earlier kernels). Is this problem something known or has at least someone already experienced that problem ? You need to run udevadm trigger as the bootstrap/coldplug step, after you stared udev. All the devices which are already there at that time, will not get created by udev, only new ones which udev will see events for. The trigger will tell the kernel to send all events again. Or just use the kernel's devtmpfs, and all this should work, even without udev, if you do not have any other needs than plain device nodes. Kay -- 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: problem webcam gspca 2.6.32
ok solved in 2.6.32-6 thanks saca...@tiscali.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: saa7134 and üPD61151 MPEG2 coder
On Thursday 28 January 2010 03:09:41 Dmitri Belimov wrote:
HIi Hans
Hi Dmitri,
Just a quick note: the video4linux mailinglist is obsolete, just use
linux-media.
OK
On Wednesday 27 January 2010 06:36:37 Dmitri Belimov wrote:
Hi Hans.
I finished saa7134 part of SPI. Please review saa7134-spi.c and
diff saa7134-core and etc. I wrote config of SPI to board
structure. Use this config for register master and slave devices.
SPI other then I2C, do not need call request_module. Udev do it.
I spend 10 days for understanding :(
I'm almost certain that spi works the same way as i2c and that means
that you must call request_module. Yes, udev will load it for you,
but that is a delayed load: i.e. the module may not be loaded when we
need it. The idea behind this is that usually i2c or spi modules are
standalone, but in the context of v4l such modules are required to be
present before the bridge can properly configure itself.
The easiest way to ensure the correct load sequence is to do a
request_module at the start.
Now, I haven't compiled this, but I think this will work:
struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
struct spi_master *master, struct spi_board_info *info)
{
struct v4l2_subdev *sd = NULL;
struct spi_device *spi;
BUG_ON(!v4l2_dev);
if (module_name)
request_module(module_name);
There is one thing missing here: module_name should be passed in as argument
to v4l2_spi_new_subdev. Does this code actually compile? If so, then I suspect
module_name must be some global variable with some bogus value which causes
request_module to time out.
[ 240.476082] [f84c8f3b] ? v4l2_spi_new_subdev_board+0x2e/0x35
[v4l2_common]
[ 240.476086] [f84c8fa6] ? v4l2_spi_new_subdev+0x64/0x6c [v4l2_common]
Remove v4l2_spi_new_subdev_board. Just have a v4l2_spi_new_subdev as in my code.
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: Setting up white balance on a t613 camera
Hi, On 01/27/2010 07:37 PM, Jean-Francois Moine wrote: On Wed, 27 Jan 2010 15:17:53 -0200 Nicolau Wernecknwern...@gmail.com wrote: Answering my own question, and also a question in the t613 source code... Yes, the need for the reg_w(gspca_dev, 0x2087);, 0x2088 and 0x2089 commands are definitely tied to the white balance. These three set up the default values I found out. And (X 8 + 87) sets up the red channel parameter in general, and 88 is for green and 89 for blue. That means I can already just play with them and see what happens. My personal problem is that I bought this new lens, and the image is way too bright, and changing that seems to help. But I would like to offer these as parameters the user can set using v4l2 programs. I can try making that big change myself, but help from a more experienced developer would be certainly much appreciated!... Hello Nicolau, The white balance is set in setwhitebalance(). Four registers are changed: 87, 88, 89 and 80. Hi, About whitebalancing, currently libv4l does whitebalancing completely in software for camera's which cannot do it automatically in hardware. That is libv4l calculates and applies 3 software gains to get the average green red and blue values the same. In the future it might be an idea to start supporting hardware per color gains for this, but there are a number of issues with that: 1) The controls used for this then need to be standardized. 2) As we don't know the exact dB scale of the hardware gains we need some sort of approximation algorithm, like with autogain / exposure. Leading to potential overshoot, oscilating etc. Esp 2. makes me wonder if we want to use the hardware color gains (when the hardware cannot autoadjust them) at all. Calculating a software gain so that the averages become equal is trivial, and does not need any settling time etc. Note that in case of whitebalance the color correction gain can easily be done in software (as it is in the range of circa 0.7 - 1.3) unlike things like exposure and the main gain which we really must set correctly at the hardware level for a usable picture. To give libv4l's software whitebalance a try do: export LIBV4LCONTROL_FLAGS=8 And then run a webcam viewing app from the same commandline You can also run a control panel like v4l2ucp like this: export LIBV4LCONTROL_FLAGS=8 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp To get a whitebalance control with which you can toggle the whitebalance on/off while streaming so that you can see the effect it has on the picture. 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
medion dvb stick 1660:1921 workaround
hello, I have a medion dvb stick (id 1660:1921) which is not supported yet. This stick is made by creatix polymedia and is based on a dib7770 chip (like the terratec XXS id 0ccd:00ab). I managed to get it work this way on ubuntu 8.04 using kernel 2.6.24-26generic: -downloaded the latest sources using mercurial -made these changes in ~/v4l-dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h : replaced #define USB_VID_TERRATEC 0x0ccd with #define USB_VID_TERRATEC 0x1660 and #define USB_PID_TERRATEC_CINERGY_T_XXS_2 0x00ab with #define USB_PID_TERRATEC_CINERGY_T_XXS_2 0x1921 -downloaded firmware dvb-usb-dib0700-1.20.fw to /lib/firmware/2.6.24-26-generic -compiled and installed modules. the stick works perfectly with kaffeine, me-tv and vlc (no others software tested) on french networks, at least for viewing tv (I haven't tested the remote function). The only bug I found is if I unplug the stick and plug it back, it doesn't work anymore. I have to reboot to make it work again. It is recognized as a terratec stick, here is the dmesg output: [ 2665.191119] usb 5-2: new high speed USB device using ehci_hcd and address 5 [ 2665.324012] usb 5-2: configuration #1 chosen from 1 choice [ 2665.616682] dib0700: loaded with support for 14 different device-types [ 2665.617381] dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in cold state, will try to load a firmware [ 2665.641199] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 2665.846088] dib0700: firmware started successfully. [ 2666.040562] dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in warm state. [ 2666.040696] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 2666.040861] DVB: registering new adapter (Terratec Cinergy T USB XXS (HD)/ T3) [ 2666.260525] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 2666.502751] DiB0070: successfully identified [ 2666.502934] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb5/5-2/input/input9 [ 2666.551495] dvb-usb: schedule remote query interval to 50 msecs. [ 2666.551512] dvb-usb: Terratec Cinergy T USB XXS (HD)/ T3 successfully initialized and connected. [ 2666.552601] usbcore: registered new interface driver dvb_usb_dib0700 I know this way of making it work is not really clean. If I can do anything to help developing team to include this stick in the list of supported ones, just ask. Stéphane Elmaleh -- 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: cx18 fix patches
On Thu, 2010-01-28 at 00:40 -0200, Mauro Carvalho Chehab wrote: Hi Andy, I've made two fix patches to solve the issues with cx18 compilation. My original intention were to send you an email for your ack. Unfortunately, those got added at the wrong branch and went upstream. That proofs that my scripts aren't reliable yet, and that I need an independent tree for such patches... I hope I have enough disk for all those trees... I understand. As we can't rebase the -git tree without breaking the replicas, I'd like you to review the patches: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=701ca4249401fe9705a66ad806e933f15cb42489 http://git.linuxtv.org/v4l-dvb.git?a=commit;h=dd01705f6a6f732ca95d20959a90dd46482530df If a committed patch is bad, the remaining solution is to write a patch reverting it, and generating some dirty at the git logs. So, I hope both patches are ok... Please test. I had coordinated with Devin on IRC and was going to work up fixes tonight. Now I'll just review and test tonight (some time between 6:00 - 10:30 p.m. EST) Sorry for the mess. No problem. Regards, Andy Cheers, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with gspca and zc3xx
On Tue, 12 Jan 2010 00:35:28 -0800 Jean-Francois Moine wrote: Hi Jose Alberto and Hans, Hans, I modified a bit your patch to handle the 2 resolutions (also, the problem with pas202b does not exist anymore). May you sign or ack it? Jose Alberto, the attached patch is to be applied to the last version of the gspca in my test repository at LinuxTv.org http://linuxtv.org/hg/~jfrancois/gspca May you try it? Regards. Hi Jean-Francois, I applied your patch and it works, the 8 black lines at the bottom are disappeared. Without the patch I was getting tons of libv4lconvert: Error decompressing JPEG: unknown huffman code: error messages while now I get only once as soon as I launch svv. I'm wondering what is causing now this minor problem. Thanks, Fabio -- 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: [Q] udev and soc-camera
Kay Sievers wrote: On Thu, Jan 28, 2010 at 00:25, Valentin Longchamp valentin.longch...@epfl.ch wrote: I have a system that is built with OpenEmbedded where I use a mt9t031 camera with the soc-camera framework. The mt9t031 works ok with the current kernel and system. However, udev does not create the /dev/video0 device node. I have to create it manually with mknod and then it works well. If I unbind the device on the soc-camera bus (and then eventually rebind it), udev then creates the node correctly. This looks like a timing issue at coldstart. OpenEmbedded currently builds udev 141 and I am using kernel 2.6.33-rc5 (but this was already like that with earlier kernels). Is this problem something known or has at least someone already experienced that problem ? You need to run udevadm trigger as the bootstrap/coldplug step, after you stared udev. All the devices which are already there at that time, will not get created by udev, only new ones which udev will see events for. The trigger will tell the kernel to send all events again. Or just use the kernel's devtmpfs, and all this should work, even without udev, if you do not have any other needs than plain device nodes. Thanks a lot Kay, you pointed me exactly where I needed to watch. OpenEmbedded adds udevadm trigger a big list of --susbsystem-nomatch options as soon as you are not doing your first boot anymore and video4linux is among them. I either have to remove this option in the script or understand why my other /dev nodes are kept (ttys are doing fine with the same treatment for instance) and not video4linux ones (it looks like they are using DEVCACHE or something like this). But I would prefer the first alternative since cameras may be unplugged on some robots. Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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] gspca pac7302: add support for camera button
From: Márton Németh nm...@freemail.hu
Add support for snapshot button found on Labtec Webcam 2200.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 13:47:50 2010 +0100
@@ -5,6 +5,8 @@
* V4L2 by Jean-Francois Moine http://moinejf.free.fr
*
* Separated from Pixart PAC7311 library by M�rton N�meth nm...@freemail.hu
+ * Camera button input handling by Márton Németh nm...@freemail.hu
+ * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu
*
* 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
@@ -68,6 +70,7 @@
#define MODULE_NAME pac7302
+#include linux/input.h
#include media/v4l2-chip-ident.h
#include gspca.h
@@ -1164,6 +1167,37 @@
}
#endif
+#ifdef CONFIG_INPUT
+static int sd_int_pkt_scan(struct gspca_dev *gspca_dev,
+ u8 *data, /* interrupt packet data */
+ int len)/* interrput packet length */
+{
+ int ret = -EINVAL;
+ u8 data0, data1;
+
+ if (len == 2) {
+ data0 = data[0];
+ data1 = data[1];
+ if ((data0 == 0x00 data1 == 0x11) ||
+ (data0 == 0x22 data1 == 0x33) ||
+ (data0 == 0x44 data1 == 0x55) ||
+ (data0 == 0x66 data1 == 0x77) ||
+ (data0 == 0x88 data1 == 0x99) ||
+ (data0 == 0xaa data1 == 0xbb) ||
+ (data0 == 0xcc data1 == 0xdd) ||
+ (data0 == 0xee data1 == 0xff)) {
+ input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1);
+ input_sync(gspca_dev-input_dev);
+ input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0);
+ input_sync(gspca_dev-input_dev);
+ ret = 0;
+ }
+ }
+
+ return ret;
+}
+#endif
+
/* sub-driver description for pac7302 */
static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -1180,6 +1214,9 @@
.set_register = sd_dbg_s_register,
.get_chip_ident = sd_chip_ident,
#endif
+#ifdef CONFIG_INPUT
+ .int_pkt_scan = sd_int_pkt_scan,
+#endif
};
/* -- module initialisation -- */
--
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] gspca pac7302: add support for camera button
Hello Jean-Francois,
thank you for accepting this patch and for the previous suggestions which made
it possible
to reach the current state of this patchset. Also thanks for correcting the
character
encoding in my name.
Regards,
Márton Németh
Németh Márton írta:
From: Márton Németh nm...@freemail.hu
Add support for snapshot button found on Labtec Webcam 2200.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 07:58:51
2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 13:47:50
2010 +0100
@@ -5,6 +5,8 @@
* V4L2 by Jean-Francois Moine http://moinejf.free.fr
*
* Separated from Pixart PAC7311 library by M�rton N�meth nm...@freemail.hu
+ * Camera button input handling by Márton Németh nm...@freemail.hu
+ * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu
*
* 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
@@ -68,6 +70,7 @@
#define MODULE_NAME pac7302
+#include linux/input.h
#include media/v4l2-chip-ident.h
#include gspca.h
@@ -1164,6 +1167,37 @@
}
#endif
+#ifdef CONFIG_INPUT
+static int sd_int_pkt_scan(struct gspca_dev *gspca_dev,
+ u8 *data, /* interrupt packet data */
+ int len)/* interrput packet length */
+{
+ int ret = -EINVAL;
+ u8 data0, data1;
+
+ if (len == 2) {
+ data0 = data[0];
+ data1 = data[1];
+ if ((data0 == 0x00 data1 == 0x11) ||
+ (data0 == 0x22 data1 == 0x33) ||
+ (data0 == 0x44 data1 == 0x55) ||
+ (data0 == 0x66 data1 == 0x77) ||
+ (data0 == 0x88 data1 == 0x99) ||
+ (data0 == 0xaa data1 == 0xbb) ||
+ (data0 == 0xcc data1 == 0xdd) ||
+ (data0 == 0xee data1 == 0xff)) {
+ input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1);
+ input_sync(gspca_dev-input_dev);
+ input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0);
+ input_sync(gspca_dev-input_dev);
+ ret = 0;
+ }
+ }
+
+ return ret;
+}
+#endif
+
/* sub-driver description for pac7302 */
static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -1180,6 +1214,9 @@
.set_register = sd_dbg_s_register,
.get_chip_ident = sd_chip_ident,
#endif
+#ifdef CONFIG_INPUT
+ .int_pkt_scan = sd_int_pkt_scan,
+#endif
};
/* -- module initialisation -- */
--
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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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 28 19:00:03 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14064:31eaa9423f98 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-rc5-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-rc5-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-rc5-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-rc5-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-rc5-mips: WARNINGS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-rc5-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-rc5-x86_64: WARNINGS spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
On Wed, 27 Jan 2010, Németh Márton wrote:
Guennadi Liakhovetski wrote:
You didn't reply to my most important objection:
On Wed, 27 Jan 2010, Németh Márton wrote:
diff -r 31eaa9423f98 linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.h Mon Jan 25 15:04:15 2010 -0200
+++ b/linux/include/media/soc_camera.h Wed Jan 27 20:49:57 2010 +0100
@@ -264,9 +264,8 @@
common_flags;
}
-static inline void soc_camera_limit_side(unsigned int *start,
- unsigned int *length, unsigned int start_min,
- unsigned int length_min, unsigned int length_max)
+static inline void soc_camera_limit_side(int *start, int *length,
+ int start_min, int length_min, int length_max)
{
if (*length length_min)
*length = length_min;
I still do not believe this function will work equally well with signed
parameters, as it works with unsigned ones.
I implemented some test cases to find out whether the
soc_camera_limit_side() works correctly or not. My biggest problem is that I'm
not sure what is the expected working of the soc_camera_limit_side() function.
Well, the expected behaviour is simple: the function treats all its
parameters as unsigned, and puts the former two input/output parameters
within the limits, provided by the latter three parameters. Well, taking
into account, that when comparing a signed and an unsigned integers, the
comparison is performed unsigned, I think, it should be ok to do what I
suggested in the last email: change prototype to
+static inline void soc_camera_limit_side(int *start, int *length,
+ unsigned int start_min, unsigned int length_min,
+ unsigned int length_max)
Maybe also provide a comment above the function explaining, why the first
two parameters are signed. And cast explicitly in sh_mobile_ceu_camera.c:
soc_camera_limit_side(rect-left, rect-width,
(unsigned int)cap.bounds.left, 2,
(unsigned int)cap.bounds.width);
soc_camera_limit_side(rect-top, rect-height,
(unsigned int)cap.bounds.top, 4,
(unsigned int)cap.bounds.height);
Could you check if this would make both sparse and the compiler happy?
Thanks
Guennadi
Nevertheless I tried expect some values, you can probably verify whether my
expectations are correct or not (see the test attached).
The signed and unsigned version of the function works differently because
the unsigned version cannot accept negative values. These values will be
implicitly casted to an unsigned value which means that they will be
interpreted
as a big positive value.
Here are the test results:
Test Case 1: PASSED
Test Case 2: PASSED
Test Case 3: FAILED: start=50, length=8, start_unsigned=0,
length_unsigned=1600
Test Case 4: PASSED
Test Case 5: PASSED
Test Case 6: PASSED
Test Case 7: PASSED
Test Case 8: PASSED
There is a difference in case 3, but which is the correct one?
Regard,
Márton Németh
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote:
On Wed, 27 Jan 2010, Németh Márton wrote:
Guennadi Liakhovetski wrote:
You didn't reply to my most important objection:
On Wed, 27 Jan 2010, Németh Márton wrote:
diff -r 31eaa9423f98 linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.h Mon Jan 25 15:04:15 2010 -0200
+++ b/linux/include/media/soc_camera.h Wed Jan 27 20:49:57 2010 +0100
@@ -264,9 +264,8 @@
common_flags;
}
-static inline void soc_camera_limit_side(unsigned int *start,
- unsigned int *length, unsigned int start_min,
- unsigned int length_min, unsigned int length_max)
+static inline void soc_camera_limit_side(int *start, int *length,
+ int start_min, int length_min, int length_max)
{
if (*length length_min)
*length = length_min;
I still do not believe this function will work equally well with signed
parameters, as it works with unsigned ones.
I implemented some test cases to find out whether the
soc_camera_limit_side() works correctly or not. My biggest problem is that
I'm
not sure what is the expected working of the soc_camera_limit_side()
function.
Well, the expected behaviour is simple: the function treats all its
parameters as unsigned, and puts the former two input/output parameters
within the limits, provided by the latter three parameters. Well, taking
For the length parameter it is clear to put them between length_min and
length_max.
But for start there is only one limit given: start_min. Does this mean that
any *start value bigger than start_min is acceptable?
(I would like to find out the meaning, not to read back what is written in
the source code because it is no use to define test cases out of the source
code.)
into account, that when comparing a signed and an unsigned integers, the
comparison is performed unsigned, I think, it should be ok to do what I
suggested in the last email: change prototype to
+static inline void soc_camera_limit_side(int *start, int *length,
+ unsigned int start_min, unsigned int length_min,
+ unsigned int length_max)
Maybe also provide a comment above the function explaining, why the first
two parameters are signed. And cast explicitly in sh_mobile_ceu_camera.c:
soc_camera_limit_side(rect-left, rect-width,
(unsigned int)cap.bounds.left, 2,
(unsigned int)cap.bounds.width);
soc_camera_limit_side(rect-top, rect-height,
(unsigned int)cap.bounds.top, 4,
(unsigned int)cap.bounds.height);
I'm afraid that casting __s32 to unsigned int just cannot work. Let's take an
example on a 32bit machine:
-1 = 0x
(unsigned int)-1 = 0x = 4294967295
and
-2147483648 = 0x8000
(unsigned int)-2147483648 = 0x8000 = 2147483648
This means that any negative number will be mapped to a large positive number
when casting to (unsigned int) and I think this is not the wanted behaviour.
Could you check if this would make both sparse and the compiler happy?
There is no compiler warning nor sparse warning when applying the following
version of the patch. I'm not sure, however, that the simple cast will do
the right thing here.
Regards,
Márton Németh
---
From: Márton Németh nm...@freemail.hu
The parameters of soc_camera_limit_side() are either a pointer to
a structure element from v4l2_rect, or constants. The structure elements
of the v4l2_rect are signed (see linux/videodev2.h) so do the computations
also with signed values.
The *s_crop() functions may receive negative numbers through the c field of
struct v4l2_crop. These negative values then limited by the start_min and
length_min parameters of soc_camera_limit_side().
This will remove the following sparse warning (see make C=1):
* incorrect type in argument 1 (different signedness)
expected unsigned int *start
got signed int *noident
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 31eaa9423f98 linux/drivers/media/video/mt9v022.c
--- a/linux/drivers/media/video/mt9v022.c Mon Jan 25 15:04:15 2010 -0200
+++ b/linux/drivers/media/video/mt9v022.c Thu Jan 28 22:24:35 2010 +0100
@@ -326,7 +326,7 @@
if (ret 0)
return ret;
- dev_dbg(client-dev, Frame %ux%u pixel\n, rect.width, rect.height);
+ dev_dbg(client-dev, Frame %dx%d pixel\n, rect.width, rect.height);
mt9v022-rect = rect;
diff -r 31eaa9423f98 linux/drivers/media/video/rj54n1cb0c.c
--- a/linux/drivers/media/video/rj54n1cb0c.cMon Jan 25 15:04:15 2010 -0200
+++ b/linux/drivers/media/video/rj54n1cb0c.cThu Jan 28 22:24:35 2010 +0100
@@ -555,15 +555,15 @@
return ret;
}
-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
- u32 *out_w, u32 *out_h);
+static int rj54n1_sensor_scale(struct
Make failed - standard ubuntu 9.10
Please can someone assist, not sure what the cause of the below is? This is my second attempt to get linux tv to work, I suspect it's a basic level error - sorry I'm fairly new to Linux... output below, I'm running a fairly standard ubuntu 9.10 setup. make[1]: Entering directory `/home/david/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.31 File not found: /lib/modules/2.6.31-17-generic/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** No rule to make target `.myconfig', needed by `config-compat.h'. Stop. make[1]: Leaving directory `/home/david/v4l-dvb/v4l' make: *** [all] Error 2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18 fix patches
Andy Walls wrote: Now I'll just review and test tonight (some time between 6:00 - 10:30 p.m. EST) One more error (on x86_64): drivers/media/video/cx18/cx18-alsa-pcm.c: In function ‘cx18_alsa_announce_pcm_data’: drivers/media/video/cx18/cx18-alsa-pcm.c:82: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘size_t’ You should use %zu for size_t. 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: cx18 fix patches
On Thu, 2010-01-28 at 00:40 -0200, Mauro Carvalho Chehab wrote: Hi Andy, I've made two fix patches to solve the issues with cx18 compilation. My original intention were to send you an email for your ack. Unfortunately, those got added at the wrong branch and went upstream. That proofs that my scripts aren't reliable yet, and that I need an independent tree for such patches... I hope I have enough disk for all those trees... As we can't rebase the -git tree without breaking the replicas, I'd like you to review the patches: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=701ca4249401fe9705a66ad806e933f15cb42489 http://git.linuxtv.org/v4l-dvb.git?a=commit;h=dd01705f6a6f732ca95d20959a90dd46482530df If a committed patch is bad, the remaining solution is to write a patch reverting it, and generating some dirty at the git logs. So, I hope both patches are ok... Mauro, By visual inspection, compilation test, and module loading test on a kernel configured to be modular the patches are OK. I did not test with them statically recompiled in the kernel, but by inspection, they should be OK. Devin, I found interesting system interactions. On my dual core x86_64 Fedora 12 machine loading an HVR-1600 cold (no firmware has been loaded yet), the pulseaudio daemon opens up a CX23418 ALSA node almost immediately after it appears and has these effects: 1. Pulseaudio tries to perform some sort of op that starts a capture on the PCM stream before the APU and CPU firmware has finished loading. This results in error messages in the log and probably an undesirable driver state, if there was never any firmware loaded prior - such as at power up. 2. Pulseaudio grabs the ALSA control node for the CX23418 and won't let go. If I kill the Pulseaudio process that has the node open, it just respawns and grabs the control node again. This prevents unloading the cx18-alsa and cx18 module. 3. If Pulseaudio also keeps the PCM analog stream going, then TV image settings are fixed to the values at the time Pulseaudio started the stream. I don't think it does, but I'm not sure yet. My off the cuff ideas for fixes are: 1. Integrate cx18-alsa functions into the driver and no longer have it as a module, to better coordinate firmware loading with the ALSA nodes. (The modular architecture appears to have been a bad choice on my part.) 2. Add a module option to disable setting up the cx18-alsa device nodes. I'll try to work on these this Friday and Saturday. 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
Re: cx18 fix patches
On Fri, 2010-01-29 at 00:08 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: Now I'll just review and test tonight (some time between 6:00 - 10:30 p.m. EST) One more error (on x86_64): drivers/media/video/cx18/cx18-alsa-pcm.c: In function ‘cx18_alsa_announce_pcm_data’: drivers/media/video/cx18/cx18-alsa-pcm.c:82: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘size_t’ You should use %zu for size_t. Yes, I saw it. I'll handle it this weekend with some other cx18 fixes. I'll have to give you changes via -hg or as patches posted to the list, as I don't have a -git clone yet. Regards, Andy Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18 fix patches
Andy Walls wrote: On Thu, 2010-01-28 at 00:40 -0200, Mauro Carvalho Chehab wrote: Hi Andy, I've made two fix patches to solve the issues with cx18 compilation. My original intention were to send you an email for your ack. Unfortunately, those got added at the wrong branch and went upstream. That proofs that my scripts aren't reliable yet, and that I need an independent tree for such patches... I hope I have enough disk for all those trees... As we can't rebase the -git tree without breaking the replicas, I'd like you to review the patches: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=701ca4249401fe9705a66ad806e933f15cb42489 http://git.linuxtv.org/v4l-dvb.git?a=commit;h=dd01705f6a6f732ca95d20959a90dd46482530df If a committed patch is bad, the remaining solution is to write a patch reverting it, and generating some dirty at the git logs. So, I hope both patches are ok... Mauro, By visual inspection, compilation test, and module loading test on a kernel configured to be modular the patches are OK. I did not test with them statically recompiled in the kernel, but by inspection, they should be OK. Thanks for the test. I did the compilations and the errors disappeared. The only remaining one is that %d instead of %zd that appears with x86_64 (I sent you a report earlier today). 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] drivers/media/common: remove unnecessary casts of void *
H Hartley Sweeten wrote:
drivers/media/common: Remove unnecessary casts of void *
void pointers do not need to be cast to other pointer types.
diff --git a/drivers/media/common/saa7146_vbi.c
b/drivers/media/common/saa7146_vbi.c
index 74e2b56..301a795 100644
--- a/drivers/media/common/saa7146_vbi.c
+++ b/drivers/media/common/saa7146_vbi.c
@@ -3,7 +3,7 @@
static int vbi_pixel_to_capture = 720 * 2;
static int vbi_workaround(struct saa7146_dev *dev)
-{
+{.remove_casts.hhs~
What's this? It seems that your patch got corrupted somehow.
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
[Fwd: + radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh.patch added to -mm tree]
As akpm has consolidated the 3 patches into one, send to the ML to go
to Patchwork and be reviewed instead of the 3 previous patches.
Mensagem original
Assunto: + radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh.patch added
to -mm tree
Data: Tue, 26 Jan 2010 16:57:50 -0800
De: a...@linux-foundation.org
Para: mm-comm...@vger.kernel.org
CC: richard.rojf...@pelagicore.com, dougsl...@gmail.com, hverk...@xs4all.nl,
mche...@infradead.org
The patch titled
radio: add support for SAA7706H Car Radio DSP
has been added to the -mm tree. Its filename is
radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: radio: add support for SAA7706H Car Radio DSP
From: Richard Röjfors richard.rojf...@pelagicore.com
Initial support for the SAA7706H Car Radio DSP.
It is a I2C device and currently the mute control is supported.
When the device is unmuted it is brought out of reset and initiated using
the proposed intialisation sequence.
When muted the DSP is brought into reset state.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Douglas Schilling Landgraf dougsl...@gmail.com
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/radio/Kconfig | 12
drivers/media/radio/Makefile|1
drivers/media/radio/saa7706h.c | 450 ++
include/media/v4l2-chip-ident.h |3
4 files changed, 466 insertions(+)
diff -puN
include/media/v4l2-chip-ident.h~radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh
include/media/v4l2-chip-ident.h
---
a/include/media/v4l2-chip-ident.h~radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh
+++ a/include/media/v4l2-chip-ident.h
@@ -155,6 +155,9 @@ enum {
/* module adv7343: just ident 7343 */
V4L2_IDENT_ADV7343 = 7343,
+ /* module saa7706h: just ident 7706 */
+ V4L2_IDENT_SAA7706H = 7706,
+
/* module wm8739: just ident 8739 */
V4L2_IDENT_WM8739 = 8739,
diff -puN /dev/null drivers/media/radio/saa7706h.c
--- /dev/null
+++ a/drivers/media/radio/saa7706h.c
@@ -0,0 +1,450 @@
+/*
+ * saa7706.c Philips SAA7706H Car Radio DSP driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+
+#define DRIVER_NAME saa7706h
+
+/* the I2C memory map looks like this
+
+ $1C00 - $ Not Used
+ $2200 - $3FFF Reserved YRAM (DSP2) space
+ $2000 - $21FF YRAM (DSP2)
+ $1FF0 - $1FFF Hardware Registers
+ $1280 - $1FEF Reserved XRAM (DSP2) space
+ $1000 - $127F XRAM (DSP2)
+ $0FFFDSP CONTROL
+ $0A00 - $0FFE Reserved
+ $0980 - $09FF Reserved YRAM (DSP1) space
+ $0800 - $097F YRAM (DSP1)
+ $0200 - $07FF Not Used
+ $0180 - $01FF Reserved XRAM (DSP1) space
+ $ - $017F XRAM (DSP1)
+*/
+
+#define SAA7706H_REG_CTRL 0x0fff
+#define SAA7706H_CTRL_BYP_PLL 0x0001
+#define SAA7706H_CTRL_PLL_DIV_MASK 0x003e
+#define SAA7706H_CTRL_PLL3_62975MHZ0x003e
+#define SAA7706H_CTRL_DSP_TURBO0x0040
+#define SAA7706H_CTRL_PC_RESET_DSP10x0080
+#define SAA7706H_CTRL_PC_RESET_DSP20x0100
+#define SAA7706H_CTRL_DSP1_ROM_EN_MASK 0x0600
+#define SAA7706H_CTRL_DSP1_FUNC_PROM 0x
+#define SAA7706H_CTRL_DSP2_ROM_EN_MASK 0x1800
+#define SAA7706H_CTRL_DSP2_FUNC_PROM 0x
+#define SAA7706H_CTRL_DIG_SIL_INTERPOL 0x8000
+
+#define SAA7706H_REG_EVALUATION0x1ff0
+#define SAA7706H_EVAL_DISABLE_CHARGE_PUMP 0x01
Re: Make failed - standard ubuntu 9.10
David Henig wrote: Please can someone assist, not sure what the cause of the below is? This is my second attempt to get linux tv to work, I suspect it's a basic level error - sorry I'm fairly new to Linux... output below, I'm running a fairly standard ubuntu 9.10 setup. make[1]: Entering directory `/home/david/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.31 File not found: /lib/modules/2.6.31-17-generic/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** No rule to make target `.myconfig', needed by `config-compat.h'. Stop. make[1]: Leaving directory `/home/david/v4l-dvb/v4l' make: *** [all] Error 2 I think you don't have the kernel development files installed. The recommended reading would be: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Regards, Márton Németh -- 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 üPD61151 MPEG2 coder
Hi Hans
On Wednesday 27 January 2010 06:36:37 Dmitri Belimov wrote:
Hi Hans.
I finished saa7134 part of SPI. Please review saa7134-spi.c and
diff saa7134-core and etc. I wrote config of SPI to board
structure. Use this config for register master and slave
devices.
SPI other then I2C, do not need call request_module. Udev do
it. I spend 10 days for understanding :(
I'm almost certain that spi works the same way as i2c and that
means that you must call request_module. Yes, udev will load it
for you, but that is a delayed load: i.e. the module may not be
loaded when we need it. The idea behind this is that usually i2c
or spi modules are standalone, but in the context of v4l such
modules are required to be present before the bridge can properly
configure itself.
The easiest way to ensure the correct load sequence is to do a
request_module at the start.
Now, I haven't compiled this, but I think this will work:
struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device
*v4l2_dev, struct spi_master *master, struct spi_board_info *info)
{
struct v4l2_subdev *sd = NULL;
struct spi_device *spi;
BUG_ON(!v4l2_dev);
if (module_name)
request_module(module_name);
There is one thing missing here: module_name should be passed in as
argument to v4l2_spi_new_subdev. Does this code actually compile? If
so, then I suspect module_name must be some global variable with some
bogus value which causes request_module to time out.
[ 240.476082] [f84c8f3b] ? v4l2_spi_new_subdev_board+0x2e/0x35
[v4l2_common] [ 240.476086] [f84c8fa6] ?
v4l2_spi_new_subdev+0x64/0x6c [v4l2_common]
Remove v4l2_spi_new_subdev_board. Just have a v4l2_spi_new_subdev as
in my code.
I found my error. Calling request_module befor spi_new_device is good.
As I see new v4l2_subdev ops hooked and calling
[ 52.796008] DEBUG uPD61151: upd61151_s_std
My next task move our MPEG2 code to upd61151.c
Please review my changes for v4l2_spi_new_subdev.
[4.743008] Linux video capture interface: v2.00
[4.788866] saa7130/34: v4l2 driver version 0.2.15 loaded
[4.788946] saa7134 :04:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[4.788996] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency:
32, mmio: 0xe510
[4.789055] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7
[card=171,autodetected]
[4.789122] saa7133[0]: board init: gpio is 20
[4.789172] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[4.868459] HDA Intel :00:1b.0: PCI INT A - GSI 16 (level, low) - IRQ
16
[4.868533] HDA Intel :00:1b.0: setting latency timer to 64
[4.952004] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00
00 00 00 01
[4.952604] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.953202] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.953799] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.954397] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.954994] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.955592] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.956200] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.956798] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.957395] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.957993] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.958591] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.959189] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.959786] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.960394] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff
ff ff ff ff
[4.960991] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff
ff ff ff ff
[5.012044] tuner 1-0061: chip found @ 0xc2 (saa7133[0])
[5.128672] xc5000 1-0061: creating new instance
[5.136014] xc5000: Successfully identified at address 0x61
[5.136067] xc5000: Firmware has not been loaded previously
[ 33.425823] saa7134 :04:01.0: spi master registered: bus_num=32766
num_chipselect=1
[ 33.425883] saa7133[0]: found muPD61151 MPEG encoder
[ 33.425928] befor request_module upd61151
[ 33.435609] upd61151_probe function
[ 33.435654] Read test REG 0xD8 :
[ 33.437463] REG = 0x0
[ 33.437505] Write test 0x03 to REG 0xD8 :
[ 33.439310] Next read test REG 0xD8 :
[ 33.441123] REG = 0x3
[ 33.441167] befor spi_get_drvdata
[ 33.441210] subdev pointer = f646e7c0
[ 33.441253] befor register_subdev
[ 33.441297]
