Re: saa7134 and üPD61151 MPEG2 coder
Hi Dmitri,
Just a quick note: the video4linux mailinglist is obsolete, just use
linux-media.
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);
spi = spi_new_device(master, info);
if (spi == NULL || spi-dev.driver == NULL)
goto error;
if (!try_module_get(spi-dev.driver-owner))
goto error;
sd = spi_get_drvdata(spi);
/* Register with the v4l2_device which increases the module's
use count as well. */
if (v4l2_device_register_subdev(v4l2_dev, sd))
sd = NULL;
/* Decrease the module use count to match the first try_module_get. */
module_put(spi-dev.driver-owner);
error:
/* If we have a client but no subdev, then something went wrong and
we must unregister the client. */
if (spi sd == NULL)
spi_unregister_device(spi);
return sd;
}
EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
Note that you mixed up the spi master and spi client in your original code. So
it is no wonder you experienced crashes.
Also note that there is no need for a separate v4l2_spi_new_subdev_board
function.
And in v4l2_spi_subdev_init() you should use spi_set_drvdata instead of
dev_set_drvdata.
I hope this helps.
Regards,
Hans
I need help with v4l2-common.c - function v4l2_spi_new_subdev_board
The module of SPI slave loading after some time and spi device hasn't
v4l2_subdev structure
for v4l2_device_register_subdev.
Now I get kernel crash when call v4l2_device_register_subdev.
Need use a callback metod or other. I don't know.
Copy to Mauro Carvalho Chehab and mailing lists for review my code too.
Dmesg log without call v4l2_device_register_subdev.
[4.742279] Linux video capture interface: v2.00
[4.816171] saa7130/34: v4l2 driver version 0.2.15 loaded
[4.816253] saa7134 :04:01.0: PCI INT A - GSI 19 (level, low) - IRQ
19
[4.816304] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency:
32, mmio: 0xe510
[4.816363] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7
[card=171,autodetected]
[4.816430] saa7133[0]: board init: gpio is 20
[4.816481] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared
IRQs
[4.976010] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00
00 00 00 01
[4.976635] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.977231] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.977827] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.978423] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.979019] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.979615] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.980223] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.980820] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.981416] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.982012] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.982608] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.983204] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.983800] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[4.984437] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff
ff ff ff ff
[4.985033] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff
ff ff ff ff
[5.008041] tuner 1-0061:
RE: help: Leadtek DTV2000 DS
Date: Wed, 27 Jan 2010 02:21:32 +0200 From: cr...@iki.fi To: gavin_r...@hotmail.com CC: linux-media@vger.kernel.org Subject: Re: help: Leadtek DTV2000 DS Terve Gavin, On 01/25/2010 01:44 PM, Gavin Ramm wrote: Tried the current build of v4l-dvb (as of 25/01/2010) for a Leadtek DTV2000 DS. product site : http://www.leadtek.com/eng/tv_tuner/overview.asp?lineid=6pronameid=530check=f The chipset are AF9015 + AF9013 and the tuner is TDA18211.. Im running it on mythdora 10.21 *fedora 10* i've had no luck with this. Any help would be great.. im willing to test.. I added support for that device, could you test now? http://linuxtv.org/hg/~anttip/af9015/ I created a channels.conf via the output tried in xine and it worked.. tried in mythtv and it picked a few up only by importing the channels.conf. The auto scan in mythtv didn't work (which is out of scope i'd say) _ The card is up and running within mythtv also, forgot i rebuilt the box and didn't change it back to Australian freq... thanks alot for the help!! gav _ celebrated too soon! the adpater0 works but all the other adapters1/2/3 do not find anything. I've ran the identical scan -a 1 /usr/share/dvb/dvb-t/au-Bendigo on them all and only the first one works.. I've changed the physical arial cables also, this didn't help.. I have 2x of the cards installed. -gav _ Ok first up sorry for the spamming of message.. I took an old card out that was also in the box.. rebooted my pc and now it looks like they're all working.. Tried via scan -a 0 /usr/share/dvb/dvb-t/au-Bendigo for 0 1 2 and 3 and they all got channels. then tried on my mythfrontend and i could view channels on all adapters.. -gav _ Search for properties that match your lifestyle! Start searching NOW! http://clk.atdmt.com/NMN/go/157631292/direct/01/-- 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] radio: Add radio-timb
On Friday 22 January 2010 20:36:32 Richard Röjfors wrote:
Hans Verkuil wrote:
On Friday 22 January 2010 13:38:28 Richard Röjfors wrote:
This patch add supports for the radio system on the Intel Russellville
board.
It's a In-Vehicle Infotainment board with a radio tuner and DSP.
This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
when needed.
The RDS support is done by I/O memory accesses.
I gather from this source that you weren't aware of the RDS interface
specification:
http://www.linuxtv.org/downloads/v4l-dvb-apis/ch04s11.html
Please use the V4L2_CAP_RDS_CAPTURE capability in querycap and use the
struct v4l2_rds_data when reading the RDS data. Let us know if you run into
problems doing this. This API was only formalized in 2.6.32 (although based
on previous implementations), so it is pretty recent.
Thanks, I'll look into this. I like the idea of harmonising the RDS API. The
driver is actually
older than 2.6.32 so I wasn't aware of it.
Some more comments below.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/radio-timb.c
b/drivers/media/radio/radio-timb.c
new file mode 100644
index 000..3dbe9ad
--- /dev/null
+++ b/drivers/media/radio/radio-timb.c
@@ -0,0 +1,543 @@
+/*
+ * radio-timb.c Timberdale FPGA Radio 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/version.h
+#include linux/module.h
+#include linux/io.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include media/timb_radio.h
+
+#define DRIVER_NAME timb-radio
+
+#define RDS_BLOCK_SIZE 4
+#define RDS_BUFFER_SIZE (RDS_BLOCK_SIZE * 100)
+
+struct timbradio {
+ struct mutexlock; /* for mutual exclusion */
+ void __iomem*membase;
+ struct timb_radio_platform_data pdata;
+ struct v4l2_subdev *sd_tuner;
+ struct module *tuner_owner;
+ struct v4l2_subdev *sd_dsp;
+ struct module *dsp_owner;
+ struct video_device *video_dev;
+ /* RDS related */
+ int open_count;
+ int rds_irq;
+ wait_queue_head_t read_queue;
+ unsigned char buffer[RDS_BUFFER_SIZE];
+ unsigned int rd_index;
+ unsigned int wr_index;
+};
+
+
+static int timbradio_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v-driver, DRIVER_NAME, sizeof(v-driver));
+ strlcpy(v-card, Timberdale Radio, sizeof(v-card));
+ snprintf(v-bus_info, sizeof(v-bus_info), platform:DRIVER_NAME);
+ v-version = KERNEL_VERSION(0, 0, 1);
+ v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
+ return 0;
+}
+
+static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ int ret;
+
+ mutex_lock(tr-lock);
+ ret = v4l2_subdev_call(tr-sd_tuner, tuner, g_tuner, v);
+ mutex_unlock(tr-lock);
I'm not sure whether it is appropriate (or even needed!) to do the locking
here.
Perhaps it is better to do the locking in the tuner driver? This is just an
idea. I do not have the datasheets, so I don't know what is reasonable here.
+
+ return ret;
+}
+
+static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ int ret;
+
+ mutex_lock(tr-lock);
+ ret = v4l2_subdev_call(tr-sd_tuner, tuner, s_tuner, v);
+ mutex_unlock(tr-lock);
+
+ return ret;
+}
+
+static int timbradio_vidioc_g_input(struct file *filp, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int timbradio_vidioc_s_input(struct file *filp, void *priv,
+ unsigned int i)
+{
+ return i ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ a-index = 0;
+ strlcpy(a-name, Radio, sizeof(a-name));
+ a-capability = V4L2_AUDCAP_STEREO;
+ return 0;
+}
+
+
+static
Re: Setting up the exposure time of a webcam
HI Nicolau remember to send a SOB if the patch is working, and any change let me know so i can test with others t613 users. Best Regards On Tue, Jan 26, 2010 at 3:37 PM, Jean-Francois Moine moin...@free.fr wrote: On Tue, 26 Jan 2010 15:00:53 -0200 Nicolau Werneck nwern...@gmail.com wrote: Hello. I have this very cheap webcam that I sent a patch to support on gspca the other day. The specific driver is the t613. I changed the lens of this camera, and now my images are all too bright, what I believe is due to the much larger aperture of this new lens. So I would like to try setting up a smaller exposure time on the camera (I would like to do that for other reasons too). The problem is there's no exposure option to be set when I call programs such as v4lctl. Does that mean there is definitely no way for me to control the exposure time? The hardware itself was not designed to allow me do that? Or is there still a chance I can create some C program that might do it, for example? [snip] Hello Nicolau, There are brightness, contrast, colors, autogain and some other video controls for the t613 webcams. You must use a v4l2 compliant program to change them, as vlc or v4l2ucp (but not cheese). 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 -- 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, RFC] gspca: add input support for interrupt endpoints
Hi,
On 01/27/2010 07:34 AM, Németh Márton wrote:
Hello Jean-Francois,
do you have any comments or suggestions about this patch?
I've been playing around a bit with the latest incarnation
of this patch (with the resubmit issue fixed), and I can report
that it works very well. Once this is merged I've got patches
ready to add button support to pac207, pac7311 and zc3xx cameras
and more will follow as time permits.
Regards,
Hans
Regards,
Márton Németh
Hans de Goede wrote:
Hi,
Looks good to me now.
Regards,
Hans
On 01/18/2010 09:01 PM, Németh Márton wrote:
From: Márton Némethnm...@freemail.hu
Add support functions for interrupt endpoint based input handling.
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Mon Jan 18 20:43:55 2010 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
*
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Némethnm...@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 the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -41,6 +44,9 @@
#include gspca.h
+#includelinux/input.h
+#includelinux/usb/input.h
+
/* global values */
#define DEF_NURBS 3 /* default number of URBs */
#if DEF_NURBS MAX_NURBS
@@ -112,6 +118,186 @@
.close = gspca_vm_close,
};
+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+ struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+ int ret;
+
+ ret = urb-status;
+ switch (ret) {
+ case 0:
+ if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+ urb-transfer_buffer, urb-actual_length) 0) {
+ PDEBUG(D_ERR, Unknown packet received);
+ }
+ break;
+
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ENODEV:
+ case -ESHUTDOWN:
+ /* Stop is requested either by software or hardware is gone,
+* keep the ret value non-zero and don't resubmit later.
+*/
+ break;
+
+ default:
+ PDEBUG(D_ERR, URB error %i, resubmitting, urb-status);
+ urb-status = 0;
+ ret = 0;
+ }
+
+ if (ret == 0) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret 0)
+ PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+ }
+}
+
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+ struct input_dev *input_dev;
+ int err = 0;
+
+ dev-input_dev = NULL;
+ if (dev-sd_desc-int_pkt_scan) {
+ input_dev = input_allocate_device();
+ if (!input_dev)
+ return -ENOMEM;
+
+ usb_make_path(dev-dev, dev-phys, sizeof(dev-phys));
+ strlcat(dev-phys, /input0, sizeof(dev-phys));
+
+ input_dev-name = dev-sd_desc-name;
+ input_dev-phys = dev-phys;
+
+ usb_to_input_id(dev-dev,input_dev-id);
+
+ input_dev-evbit[0] = BIT_MASK(EV_KEY);
+ input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+ input_dev-dev.parent =dev-dev-dev;
+
+ err = input_register_device(input_dev);
+ if (err) {
+ PDEBUG(D_ERR, Input device registration failed
+ with error %i, err);
+ input_dev-dev.parent = NULL;
+ input_free_device(input_dev);
+ } else {
+ dev-input_dev = input_dev;
+ }
+ } else
+ err = -EINVAL;
+
+ return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+ unsigned int buffer_len;
+ int interval;
+ struct urb *urb;
+ struct usb_device *dev;
+ void *buffer = NULL;
+ int ret = -EINVAL;
+
+ buffer_len = ep-wMaxPacketSize;
+ interval = ep-bInterval;
+ PDEBUG(D_PROBE, found int in endpoint: 0x%x,
+ buffer_len=%u, interval=%u,
+ ep-bEndpointAddress, buffer_len, interval);
+
+ dev = gspca_dev-dev;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buffer = usb_buffer_alloc(dev,
Re: [PATCH 1/2] radio: Add radio-timb
Hans Verkuil wrote: The first time we run we could definitely do a 4l2_i2c_new_subdev*, but what if I rmmod the driver and insmod it again? When we do the do an open, then v4l2_i2c_new_subdev* would fail because the device is only on the bus and probed. So I would have to look for it anyway. Or am I wrong? I found this like the only generic way(?) Not sure I understand you. When you call v4l2_device_unregister any registered i2c devices will be automatically unloaded from the i2c bus. So when you do a new modprobe, then it is as if you did it for the first time. This should work. If not, then let me know and we can look at it. Thanks for the explanation! It should work, I will update accordingly. Is there a reason why you want to load them only on first use? It is customary to load them when this driver is loaded. Exceptions to that may be if the i2c device needs to load a firmware: this can be slow over i2c and so should be postponed until the i2c driver is needed for the first time. The main reason is actually that this is a platform device which might come available before the I2C bus in the system. So we postpone the use of the bus until needed, because we know for sure it's available at that point. The i2c busses are always initialized first. That's a change that went in a few kernel releases ago. Ok, in this case the I2C bus sits on top of a MFD device which might be installed late to reduce bootup time. Bootup time is actually also a reason to keep this code in open rather than in probe. --Richard -- 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 Sat, 23 Jan 2010, Németh Márton wrote:
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.
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
Well, it is interesting, but insufficient. And, unfortunately, I don't
have a good (and easy) recipe for how to fix this properly.
The problem is, that in soc_camera_limit_side all tests and arithmetics
are performed with unsigned in mind, now, if you change them to signed,
think what happens, if some of them are negative. No, I don't know when
negative members of struct v4l2_rect make sense, having them signed
doesn't seem a very good idea to me. But they cannot be changed - that's a
part of the user-space API...
Casting all parameters inside that inline to unsigned would be way too
ugly. Maybe we could at least keep start_min, length_min, and length_max
unsigned, and only change start and length to signed, and only cast those
two inside the function. Then, if you grep through all the drivers,
there's only one location, where soc_camera_limit_side() is called with
the latter 3 parameters not constant - two calls in
sh_mobile_ceu_camera.c. So, to keep sparse happy, you'd have to cast
there. Ideally, you would also add checks there for negative values...
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 2a50a0a1c951 linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.hSat Jan 23 00:14:32 2010 -0200
+++ b/linux/include/media/soc_camera.hSat Jan 23 10:09:41 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;
diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c
--- a/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 00:14:32 2010 -0200
+++ b/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 10:09:41 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 v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+s32 *out_w, s32 *out_h);
static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
struct v4l2_rect *rect = a-c;
- unsigned int dummy = 0, output_w, output_h,
+ int dummy = 0, output_w, output_h,
input_w = rect-width, input_h = rect-height;
int ret;
And these:
if (output_w max(512U, input_w / 2)) {
if (output_h max(384U, input_h / 2)) {
would now produce compiler warnings... Have you actually tried to compile
your patch? You'll also have to change formats in dev_dbg() calls here...
@@ -638,8 +638,8 @@
* the output one, updates the window sizes and returns an error or the
resize
* coefficient on success. Note: we only use the Fixed Scaling on this
camera.
*/
-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 v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+s32 *out_w, s32 *out_h)
{
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
@@ -1017,7 +1017,7 @@
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
const struct rj54n1_datafmt *fmt;
- unsigned int output_w, output_h, max_w, max_h,
+ int output_w, output_h, max_w, max_h,
input_w = rj54n1-rect.width, input_h = rj54n1-rect.height;
int ret;
and here.
Thanks
Guennadi
---
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 v2 1/2] radio: Add radio-timb
On Wednesday 27 January 2010 17:22:08 Richard Röjfors wrote:
This patch add supports for the radio system on the Intel Russellville board.
It's a In-Vehicle Infotainment board with a radio tuner and DSP.
This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
when needed.
The RDS support is done by I/O memory accesses.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/radio-timb.c
b/drivers/media/radio/radio-timb.c
new file mode 100644
index 000..276b105
--- /dev/null
+++ b/drivers/media/radio/radio-timb.c
@@ -0,0 +1,469 @@
+/*
+ * radio-timb.c Timberdale FPGA Radio 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/version.h
+#include linux/io.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include media/timb_radio.h
+
+#define DRIVER_NAME timb-radio
+
+#define RDS_BLOCK_SIZE 4
+#define RDS_BUFFER_SIZE (RDS_BLOCK_SIZE * 100)
+
+struct timbradio {
+ struct mutexlock; /* for mutual exclusion */
+ void __iomem*membase;
+ struct timb_radio_platform_data pdata;
+ struct v4l2_subdev *sd_tuner;
+ struct v4l2_subdev *sd_dsp;
+ struct video_device *video_dev;
+ struct v4l2_device v4l2_dev;
+ /* RDS related */
+ int open_count;
+ int rds_irq;
+ wait_queue_head_t read_queue;
+ unsigned char buffer[RDS_BUFFER_SIZE];
+ unsigned int rd_index;
+ unsigned int wr_index;
+};
+
+
+static int timbradio_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v-driver, DRIVER_NAME, sizeof(v-driver));
+ strlcpy(v-card, Timberdale Radio, sizeof(v-card));
+ snprintf(v-bus_info, sizeof(v-bus_info), platform:DRIVER_NAME);
+ v-version = KERNEL_VERSION(0, 0, 1);
+ v-capabilities =
+ V4L2_CAP_TUNER | V4L2_CAP_RADIO | V4L2_CAP_RDS_CAPTURE;
+ return 0;
+}
+
+static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, g_tuner, v);
+}
+
+static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_tuner, v);
+}
+
+static int timbradio_vidioc_g_input(struct file *filp, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int timbradio_vidioc_s_input(struct file *filp, void *priv,
+ unsigned int i)
+{
+ return i ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ a-index = 0;
+ strlcpy(a-name, Radio, sizeof(a-name));
+ a-capability = V4L2_AUDCAP_STEREO;
+ return 0;
+}
+
+
+static int timbradio_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ return a-index ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_s_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_frequency, f);
+}
+
+static int timbradio_vidioc_g_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, g_frequency, f);
+}
+
+static int timbradio_vidioc_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_dsp, core, queryctrl, qc);
+}
+
+static int timbradio_vidioc_g_ctrl(struct file *file, void *priv,
+ struct v4l2_control *ctrl)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_dsp, core, g_ctrl, ctrl);
+}
+
+static int timbradio_vidioc_s_ctrl(struct file *file, void *priv,
+ struct v4l2_control *ctrl)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_dsp, core, s_ctrl,
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote:
On Sat, 23 Jan 2010, Németh Márton wrote:
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.
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
Well, it is interesting, but insufficient. And, unfortunately, I don't
have a good (and easy) recipe for how to fix this properly.
The problem is, that in soc_camera_limit_side all tests and arithmetics
are performed with unsigned in mind, now, if you change them to signed,
think what happens, if some of them are negative. No, I don't know when
negative members of struct v4l2_rect make sense, having them signed
doesn't seem a very good idea to me. But they cannot be changed - that's a
part of the user-space API...
Casting all parameters inside that inline to unsigned would be way too
ugly. Maybe we could at least keep start_min, length_min, and length_max
unsigned, and only change start and length to signed, and only cast those
two inside the function. Then, if you grep through all the drivers,
there's only one location, where soc_camera_limit_side() is called with
the latter 3 parameters not constant - two calls in
sh_mobile_ceu_camera.c. So, to keep sparse happy, you'd have to cast
there. Ideally, you would also add checks there for negative values...
I'll have a look to see what can be done to handle the negative values properly.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 2a50a0a1c951 linux/include/media/soc_camera.h
--- a/linux/include/media/soc_camera.h Sat Jan 23 00:14:32 2010 -0200
+++ b/linux/include/media/soc_camera.h Sat Jan 23 10:09:41 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;
diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c
--- a/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 00:14:32 2010 -0200
+++ b/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 10:09:41 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 v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+ s32 *out_w, s32 *out_h);
static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
struct i2c_client *client = sd-priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
struct v4l2_rect *rect = a-c;
-unsigned int dummy = 0, output_w, output_h,
+int dummy = 0, output_w, output_h,
input_w = rect-width, input_h = rect-height;
int ret;
And these:
if (output_w max(512U, input_w / 2)) {
if (output_h max(384U, input_h / 2)) {
would now produce compiler warnings... Have you actually tried to compile
your patch? You'll also have to change formats in dev_dbg() calls here...
Interesting to hear about compiler warnings. I don't get them if I apply the
patch
on top of version 14064:31eaa9423f98 of http://linuxtv.org/hg/v4l-dvb/ . What
is your compiler version?
I used the attached configuration. Maybe some other options has to be
turned on?
localhost:/usr/src/linuxtv.org/v4l-dvb$ patch -p1
../soc_camera_signedness.patch
patching file linux/include/media/soc_camera.h
patching file linux/drivers/media/video/rj54n1cb0c.c
localhost:/usr/src/linuxtv.org/v4l-dvb$ make C=1 21 |tee result1.txt
make -C /usr/src/linuxtv.org/v4l-dvb/v4l
make[1]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l'
creating symbolic links...
make -C firmware prep
make[2]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
make[2]: Leaving directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
make -C firmware
make[2]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
make[2]: Nothing to be done for `default'.
make[2]: Leaving directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
Kernel build directory is /lib/modules/2.6.33-rc4/build
make -C /lib/modules/2.6.33-rc4/build SUBDIRS=/usr/src/linuxtv.org/v4l-dvb/v4l
modules
make[2]: Entering directory `/usr/src/linuxtv.org/pinchartl/uvcvideo/v4l-dvb'
CHECK /usr/src/linuxtv.org/v4l-dvb/v4l/mt9m001.c
CC [M] /usr/src/linuxtv.org/v4l-dvb/v4l/mt9m001.o
CHECK
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
On Wed, 27 Jan 2010, Németh Márton wrote:
Guennadi Liakhovetski wrote:
[snip]
And these:
if (output_w max(512U, input_w / 2)) {
if (output_h max(384U, input_h / 2)) {
would now produce compiler warnings... Have you actually tried to compile
your patch? You'll also have to change formats in dev_dbg() calls here...
Interesting to hear about compiler warnings. I don't get them if I apply the
patch
on top of version 14064:31eaa9423f98 of http://linuxtv.org/hg/v4l-dvb/ . What
is your compiler version?
Well, it's my built-in mental compiler, I haven't started versioning it
yet;) Strange, that (your) compiler doesn't complain - max() does
type-checking and now it's signed against unsigned, hm... In any case,
that one is easy to fix - just remove the Us, but I'm wondering why the
compiler didn't shout and whether there can be other similar mismatches...
Thanks
Guennadi
---
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: [mythtv] go7007 based devices
Hans Verkuil wrote: On Thursday 21 January 2010 09:07:47 TJ wrote: Jelle Foks wrote: TJ wrote: I am curious how many people are successfully using go7007 based capture devices with mythtv. I've done some patch work on go7007 driver to make it v4l2 compliant and was thinking of updating mythtv to stop using proprietary go7007 ioctls, but wanted to feel the ground first. -TJ PS: jelle you on this list? Yep, I'm on it, but I guess I don't check on it very often ;-)... You sure don't :) Myself, I'm using a bunch of plextors (with the go7007 chip), both M402's without tuner and TV402's with tuner on my mythbackend in the closet, using Ubuntu with a 2.6.31-11-generic-pae kernel and drivers that I made by combining the driver from the kernel staging tree and an older version that still worked, as I posted (with more details) on my blog at http://go70007.imploder.org . Somebody replied on the blog that it also works on 2.6.32.2, on ARM even... I actually don't know who maintains the go7007 driver in the staging tree, but I don't think it was the v4l guys. Actually, it is. So the linux-media list is the appropriate place to post patches on. It is currently maintained by Pete Eberlein from Sensoray. Try this patch. It runs against kernel source. I tried it on 2.6.32, 2.6.32-r1 and -r2. I basically did some general cleanup on the go7007 driver in the kernel tree, added few standard v4l2 commands and *temporarily* put back in proprietary go7007 ioctls from your package for continued mythtv support. I also added support for ADS Tech DVD Xpress DX2 board (which was the main reason I got into it). It runs well on my DX2 boxes. I've got about 100 of them and am currently testing it on 5. Please post this as well to the linux-media list. It would be great if someone would be willing to do more work on this driver and get it out of staging into the mainline. It's getting close, but it's not there yet. Regards, Hans Hans, My brother, pardon my ignorance, but would you please be so kind and shed some light for me on which way I should go. I was in touch with Pete on linux-media list and he's done quite a bit of work on updating the driver in the current linux-media hg tree. My patch runs against official linux kernel 2.6.32.x but won't run against hg tree. So, my thoughts were to go 2 ways: 1. Update my patch against current linux development kernel (2.6.33-rc5? or -next?) and submit it to be included with the next kernel release. It would still be in the staging category, but at least people will be able to immediately take advantage of the following things: - ADS Tech DX2 support (which I added, actually ported from some earlier release) - Mythtv support (as I included original ioctls) - Mythtv will now be able to be patched to use standard ioctls (I also kept and expanded all standard ioctls) - I found and fixt a few minor bugs 2. Keep working against current linux-media hg tree and tell people to hang tight. This might take a while though, cuz between now and Sept-Oct this year I won't be able to put a lot of time into it (worken on a big project). The things I dunno about and would appreciate anyone shedding some light on are: a. Is the current linux-media hg tree going to be included in 2.6.33 kernel? If so, then option 1 above is out of the question and I will keep working with Pete on the current hg driver. b. If the things didn't change much in the kernel tree since 2.6.32, I can probably quickly update my patch and submit it for inclusion into 2.6.33. If that's the case, which kernel should I make the patch against? Should I just git 2.6.33-rc5? Who do I submit my patch to? Again sorry for my ignorance, I don't do much collaborative work, but I am willing to help out the community. :) -TJ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
On Wednesday 27 January 2010 21:02:30 Németh Márton wrote: Hello Hans, Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. The last cron message I saw was on 23rd January, 2010. All warnings and errors were fixed since then ;-) or is there some problem with the cron job? The build server and my whole home network for that matter were undergoing a big upgrade. New harddisks and especially a new linux distro. It's now finished and the daily build has just started. So you should see the cron message in about two hours (it's a bit late today, tomorrow it is back to the normal schedule). Regards, Hans Regarsd, Márton Németh -- 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: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
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.hMon Jan 25 15:04:15 2010 -0200
+++ b/linux/include/media/soc_camera.hWed 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.
Thanks
Guennadi
---
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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
Stefan Ringel wrote: Hi, I have a problem with usb bulk transfer. After a while, as I scan digital channel (it found a few channel), it wrote this in the log: Jan 26 21:58:35 linux-v5dy kernel: [ 548.756585] tm6000: status != 0 I updated the tm6000_urb_received function so that I can read the Error code and it logged: Jan 27 17:41:28 linux-v5dy kernel: [ 3121.892793] tm6000: status = 0xffb5 Probablt it is this error: #define EOVERFLOW 75 /* Value too large for defined data type */ It would be good to make it display the error as a signed int. the tm6000-video error handler has some common causes for those status. In this particular case: case -EOVERFLOW: errmsg = Babble (bad cable?); break; This looks the same kind of errors I was receiving during the development of the driver: a large amount of frames are got broken, even if the device is programmed with the exact values used on the original driver. On my tests, changing the URB size were changing the position where such errors were occurring. Can you help me? Who I can calculate urb size? Take a look on tm6000-video: size = usb_maxpacket(dev-udev, pipe, usb_pipeout(pipe)); if (size dev-max_isoc_in) size = dev-max_isoc_in; It depends on the alternate interface used. The driver should select an alternate interface that is capable of receiving the entire size of a message. Maybe the tm6000 driver is missing the code that selects this size. Take a look on em28xx-core, at em28xx_set_alternate() code for an example on how this should work. The calculated size there assumes that each pixel has 16 bits, and has some magic that were experimentally tested on that device. 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: [mythtv] go7007 based devices
TJ wrote: Hans Verkuil wrote: On Thursday 21 January 2010 09:07:47 TJ wrote: Jelle Foks wrote: TJ wrote: I am curious how many people are successfully using go7007 based capture devices with mythtv. I've done some patch work on go7007 driver to make it v4l2 compliant and was thinking of updating mythtv to stop using proprietary go7007 ioctls, but wanted to feel the ground first. -TJ PS: jelle you on this list? Yep, I'm on it, but I guess I don't check on it very often ;-)... You sure don't :) Myself, I'm using a bunch of plextors (with the go7007 chip), both M402's without tuner and TV402's with tuner on my mythbackend in the closet, using Ubuntu with a 2.6.31-11-generic-pae kernel and drivers that I made by combining the driver from the kernel staging tree and an older version that still worked, as I posted (with more details) on my blog at http://go70007.imploder.org . Somebody replied on the blog that it also works on 2.6.32.2, on ARM even... I actually don't know who maintains the go7007 driver in the staging tree, but I don't think it was the v4l guys. Actually, it is. So the linux-media list is the appropriate place to post patches on. It is currently maintained by Pete Eberlein from Sensoray. Try this patch. It runs against kernel source. I tried it on 2.6.32, 2.6.32-r1 and -r2. I basically did some general cleanup on the go7007 driver in the kernel tree, added few standard v4l2 commands and *temporarily* put back in proprietary go7007 ioctls from your package for continued mythtv support. I also added support for ADS Tech DVD Xpress DX2 board (which was the main reason I got into it). It runs well on my DX2 boxes. I've got about 100 of them and am currently testing it on 5. Please post this as well to the linux-media list. It would be great if someone would be willing to do more work on this driver and get it out of staging into the mainline. It's getting close, but it's not there yet. Regards, Hans Hans, My brother, pardon my ignorance, but would you please be so kind and shed some light for me on which way I should go. I was in touch with Pete on linux-media list and he's done quite a bit of work on updating the driver in the current linux-media hg tree. My patch runs against official linux kernel 2.6.32.x but won't run against hg tree. So, my thoughts were to go 2 ways: 1. Update my patch against current linux development kernel (2.6.33-rc5? or -next?) and submit it to be included with the next kernel release. It would still be in the staging category, but at least people will be able to immediately take advantage of the following things: - ADS Tech DX2 support (which I added, actually ported from some earlier release) - Mythtv support (as I included original ioctls) - Mythtv will now be able to be patched to use standard ioctls (I also kept and expanded all standard ioctls) - I found and fixt a few minor bugs 2. Keep working against current linux-media hg tree and tell people to hang tight. This might take a while though, cuz between now and Sept-Oct this year I won't be able to put a lot of time into it (worken on a big project). The things I dunno about and would appreciate anyone shedding some light on are: a. Is the current linux-media hg tree going to be included in 2.6.33 kernel? If so, then option 1 above is out of the question and I will keep working with Pete on the current hg driver. b. If the things didn't change much in the kernel tree since 2.6.32, I can probably quickly update my patch and submit it for inclusion into 2.6.33. If that's the case, which kernel should I make the patch against? Should I just git 2.6.33-rc5? Who do I submit my patch to? Again sorry for my ignorance, I don't do much collaborative work, but I am willing to help out the community. :) Let me answer to your questions: The better is to generate your patch against the development -git tree: http://git.linuxtv.org/v4l-dvb.git This tree is merged upstream, at the upstream linux-next tree, and have all the patches that will go to 2.6.34 (patches against -rc trees are only for bug fixes). As the -hg tree has the same code as -git (it is manually updated when a change happens on -git), it is safe to generate your patch against -hg. The patch is handled by me, but you should send it to linux-media@vger.kernel.org only. If the patch doesn't have any whitespace trobules, it will be catched by http://patchwork.kernel.org, and I'll be able to see it at the web interface. You can read more about how to submit a patch at: http://linuxtv.org/wiki/index.php/Maintaining_Git_trees http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches and at the kernel development section of our wiki: http://linuxtv.org/wiki/ -TJ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
dmesg output with Pinnacle PCTV USB Stick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, below is my dmesh output for my Pinnacle PCTV Hybrid Pro hope it helps [ 8899.390876] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) [ 8899.391162] em28xx #0: chip ID is em2870 [ 8899.474026] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 70 28 c0 12 81 00 6a 22 00 00 [ 8899.474096] em28xx #0: i2c eeprom 10: 00 00 04 57 02 0d 00 00 00 00 00 00 00 00 00 00 [ 8899.474162] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 02 00 00 00 00 00 5b 00 00 00 [ 8899.474227] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 6d e0 a3 49 [ 8899.474311] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474376] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474441] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 8899.474506] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [ 8899.474571] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 8899.474640] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474706] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474789] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474854] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474919] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474984] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.475048] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.475117] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xf0ff19c0 [ 8899.475141] em28xx #0: EEPROM info: [ 8899.475146] em28xx #0: No audio on board. [ 8899.475151] em28xx #0: 500mA max power [ 8899.475175] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 8899.491654] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 8899.527409] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 8899.535029] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 8899.550027] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 8899.550054] em28xx #0: You may try to use card=n insmod option to workaround that. [ 8899.550061] em28xx #0: Please send an email with this log to: [ 8899.550085] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 8899.550091] em28xx #0: Board eeprom hash is 0xf0ff19c0 [ 8899.550115] em28xx #0: Board i2c devicelist hash is 0x4b800080 [ 8899.550121] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 8899.550128] em28xx #0: card=0 - Unknown EM2800 video grabber [ 8899.550153] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 8899.550160] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 8899.550188] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 8899.550212] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 8899.550219] em28xx #0: card=5 - MSI VOX USB 2.0 [ 8899.550242] em28xx #0: card=6 - Terratec Cinergy 200 USB [ 8899.550249] em28xx #0: card=7 - Leadtek Winfast USB II [ 8899.550255] em28xx #0: card=8 - Kworld USB2800 [ 8899.550280] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [ 8899.550287] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [ 8899.550312] em28xx #0: card=11 - Terratec Hybrid XS [ 8899.550318] em28xx #0: card=12 - Kworld PVR TV 2800 RF [ 8899.550342] em28xx #0: card=13 - Terratec Prodigy XS [ 8899.550349] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 8899.550374] em28xx #0: card=15 - V-Gear PocketTV [ 8899.550380] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [ 8899.550405] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [ 8899.550411] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 8899.550436] em28xx #0: card=19 - EM2860/SAA711X Reference Design [ 8899.550443] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [ 8899.550468] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 8899.550475] em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber [ 8899.550499] em28xx #0: card=23 - Huaqi DLCW-130 [ 8899.550505] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner [ 8899.550530] em28xx #0: card=25 - Gadmei UTV310 [ 8899.550536] em28xx #0: card=26 - Hercules Smart TV USB 2.0 [ 8899.550543] em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) [ 8899.550568] em28xx #0: card=28 - Leadtek Winfast USB II Deluxe [ 8899.550574] em28xx #0: card=29 - NULL [ 8899.550599] em28xx #0: card=30 - Videology 20K14XUSB USB2.0 [ 8899.550605] em28xx #0: card=31 - Usbgear VD204v9 [ 8899.550629] em28xx #0: card=32 - Supercomp USB 2.0 TV [ 8899.550635] em28xx #0: card=33 - NULL [ 8899.550659] em28xx #0: card=34 - Terratec
Re: dmesg output with Pinnacle PCTV USB Stick
On Wed, Jan 27, 2010 at 4:00 PM, Sebastian Spiess sebastian.spi...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, below is my dmesh output for my Pinnacle PCTV Hybrid Pro hope it helps [ 8899.390876] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) Are you absolutely sure this is a PCTV Hybrid Pro? What is the exact model number? Does it have the A/V cable for composite/svideo input? Based on the USB ID, I would have assumed this was a model 70e, which is a digital only device. It's on my TODO list, but it's a really low priority given how old it is. I actually did spend some time working on it, but ran into problems and without the hardware concluded it wasn't worth the time. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
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.
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
#include stdio.h
static inline void soc_camera_limit_side_UNSIGNED(unsigned int *start, unsigned int *length,
unsigned int start_min, unsigned int length_min, unsigned int length_max)
{
if (*length length_min)
*length = length_min;
else if (*length length_max)
*length = length_max;
if (*start start_min)
*start = start_min;
else if (*start start_min + length_max - *length)
*start = start_min + length_max - *length;
}
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;
else if (*length length_max)
*length = length_max;
if (*start start_min)
*start = start_min;
else if (*start start_min + length_max - *length)
*start = start_min + length_max - *length;
}
int main() {
int start, length;
unsigned int start_unsigned, length_unsigned;
printf(Test Case 1: );
start = 0;
length = 8;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(start, length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600);
if (start == 0 length == 8 start_unsigned == start length_unsigned == length) {
printf(PASSED\n);
} else {
printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned);
}
printf(Test Case 2: );
start = -5;
length = 1600;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(start, length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600);
if (start == 0 length == 1600 start_unsigned == start length_unsigned == length) {
printf(PASSED\n);
} else {
printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned);
}
printf(Test Case 3: );
start = 50;
length = -15;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(start, length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600);
if (start == 50 length == 8 start_unsigned == start length_unsigned == length) {
printf(PASSED\n);
} else {
printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned);
}
printf(Test Case 4: );
start = 500;
length = 2000;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(start, length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 0, 8, 1600);
if (start == 0 length == 1600 start_unsigned == start length_unsigned == length) {
printf(PASSED\n);
} else {
printf(FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n, start, length, start_unsigned, length_unsigned);
}
printf(Test Case 5: );
start = -20;
length = 1600;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(start, length, 100, 8, 1600);
soc_camera_limit_side_UNSIGNED(start_unsigned, length_unsigned, 100, 8, 1600);
if (start == 100 length == 1600 start_unsigned == start length_unsigned == length) {
[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:Wed Jan 27 21:00:05 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Wednesday 27 January 2010 22:48:24 Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. It's up and running again. Note that I upgraded to the latest gcc 4.4.3. I also updated all the kernels to their latest dot release. I'm only building the i686 and x86_64 on all kernels from 2.6.16 onwards. All other architectures are only built for 2.6.32 and 2.6.33. If someone wants to build one of those for older kernels also, then just let me know. Regards, Hans Results of the daily build of v4l-dvb: date:Wed Jan 27 21:00:05 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 -- 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
[PULL] firmware for Sensoray s2255 driver
The following changes since commit c024a251e1dd1a39de610bbdc2af65b36e42637d: David Woodhouse (1): Merge from fixed from-kernel tree to fix Matrox firmware binaries are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Mauro Carvalho Chehab (1): Firmware for Sensoray s2255 webcam drivers WHENCE | 13 + f2255usb.bin | Bin 0 - 180760 bytes 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 f2255usb.bin -- 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: IR device at I2C address 0x7a
Hi Jean, Am Mittwoch, den 27.01.2010, 10:38 +0100 schrieb Jean Delvare: Hi Hermann, Sorry for the late answer. On Sun, 10 Jan 2010 22:55:05 +0100, hermann pitton wrote: Am Sonntag, den 10.01.2010, 09:51 +0100 schrieb Jean Delvare: On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote: Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: Then I would suggest the following patch: * * * * * From: Jean Delvare kh...@linux-fr.org Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 Analog (card=146). However, by the time we find out, some card-specific initialization is missed. In particular, the fact that the IR is GPIO-based. Set it when we change the card type. Signed-off-by: Jean Delvare kh...@linux-fr.org Tested-by: Daro ghost-ri...@aster.pl just to note it, the ASUS TV-FM 7135 with USB remote is different to the Asus My Cinema P7134 Analog only, not only for the remote, but also for inputs, but they have the same PCI subsystem. --- linux/drivers/media/video/saa7134/saa7134-cards.c |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-12-11 09:47:47.0 +0100 +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 16:23:17.0 +0100 @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d printk(KERN_INFO %s: P7131 analog only, using entry of %s\n, dev-name, saa7134_boards[dev-board].name); + dev-has_remote = SAA7134_REMOTE_GPIO; } break; case SAA7134_BOARD_HAUPPAUGE_HVR1150: * * * * * Must have been broken at that time, IIRC. What must have been broken, and when? You are confusing. Sorry, I missed that thread until now. The above patch was tried previously by Roman. For the record, here is a link. http://www.spinics.net/lists/vfl/msg38869.html Thanks for the pointer, this was very helpful. I had missed the fact that the call to saa7134_input_init1() was before the card number change. So indeed my patch was insufficient. Roman's strategy to move saa7134_input_init1() to the late init section seems good to me. Honestly, I can't think of a good reason to init the remote control early. I doubt that anything else depends on that. I'll send an updated patch shortly. thanks for your time looking closer into it. Unfortunately I did not have any during the last two months. If we pass all the testing, your here announced and later following patch should be the best possible solution, as it stands now. To give some historical notes, Gerd did try to avoid eeprom detection on the saa7134 driver, likely hoping to see better PCI subsystem use by the manufacturers, since bttv was already very complex and difficult to maintain with all the specific detection stuff and workarounds. However, Hartmut Hackmann and me had to discover, that we still see the same disease with some saa713x OEMs, the same PCI subsystem for very different cards ... Hence we started with some eeprom detection, known now for having caused trouble already through all the ever ongoing changing init procedures we always have and very bad for transparent maintenance. For all, and for Asus specifically, this is still a unique case on the saa713x driver, IIRC. The rest is fine on Asus. To print something for that card like for IR you have to set the card=number should be also still enough. To remind, we run into those problems, because OEMs don't follow the rules of the chip manufacturer, excluding others by will on their m$ drivers, when initially buying greater amounts of chips. So we always run only after the tsunamis and it is not worth it, to give those breaking rules previously, some kind of moral instance to get their devices better detected on GNU/Linux later. Anyway, let's try. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Q] udev and soc-camera
Hello, 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 ? Thanks and best regards 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
AF9015 with tuner TDA18218
Hi, I've an adapter with USB ID 15a4:9016, with an AF9015 and tuner TDA18218. This is the fifth adatper that I try, 3 currently work, one should work, but I've no success, and this not work. I've seen in previous posts that it is not supported for now, but many people have done some experiment and some have obtained something, but nothing of full working. I want to know if it's possible to write a working driver using datasheet and starting from the code of TDA18271 using the difference from datasheet (at a first look they seems very similar); I'm not a programmer, but I'm able to do some logic operation if someone can explain me what I must do. I can do tester and report log of usbsnnop too, but starting from it and write a driver is too hard for me. If someone with this adapter want to try some experiment with me and work on it, I'm available to cowork. Thanks to all, Sebastian -- 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] firmware for Sensoray s2255 driver
Hi David, Mauro Carvalho Chehab wrote: The following changes since commit c024a251e1dd1a39de610bbdc2af65b36e42637d: David Woodhouse (1): Merge from fixed from-kernel tree to fix Matrox firmware binaries are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Sensoray sent us two more firmwares, under the same licence. So, I've added them on my tree also. For one of his driver to work, they'll need also the Micronas go7007 firmware. This firmware gives redistribution rights, but the condition for it is unusual: it requires that the README file of their public driver to be shipped together with the firmware. So, I added the clauses at WHENCE licence (based on their readme file), and added their unmodified README, just renaming it as README.go7007. I hope that's the right way of doing it. The 2 Sensoray patches, plus the go7007 firmware are at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git go7007 So, please pull from it if you're comfortable. This is the contents of the go7007 branch: Mauro Carvalho Chehab (3): Firmware for Sensoray s2255 webcam drivers Additional firmwares for Sensoray s2255 webcam drivers Add firmwares for go7007 driver README.go7007 | 375 +++ WHENCE | 33 + f2255usb.bin| Bin 0 - 180760 bytes go7007fw.bin| Bin 0 - 30800 bytes go7007tv.bin| Bin 0 - 124668 bytes s2250.fw| Bin 0 - 9508 bytes s2250_loader.fw | Bin 0 - 1092 bytes 7 files changed, 408 insertions(+), 0 deletions(-) create mode 100644 README.go7007 create mode 100644 f2255usb.bin create mode 100644 go7007fw.bin create mode 100644 go7007tv.bin create mode 100644 s2250.fw create mode 100644 s2250_loader.fw --- If, however, you think that the way the go7007 were imported is incorrect, then please pull at least the two Sensoray patches from the master branch. This is the contents for just the master branch, at ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Mauro Carvalho Chehab (2): Firmware for Sensoray s2255 webcam drivers Additional firmwares for Sensoray s2255 webcam drivers WHENCE | 14 ++ f2255usb.bin| Bin 0 - 180760 bytes s2250.fw| Bin 0 - 9508 bytes s2250_loader.fw | Bin 0 - 1092 bytes 4 files changed, 14 insertions(+), 0 deletions(-) create mode 100644 f2255usb.bin create mode 100644 s2250.fw create mode 100644 s2250_loader.fw -- 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
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);
spi = spi_new_device(master, info);
if (spi == NULL || spi-dev.driver == NULL)
goto error;
if (!try_module_get(spi-dev.driver-owner))
goto error;
sd = spi_get_drvdata(spi);
/* Register with the v4l2_device which increases the module's
use count as well. */
if (v4l2_device_register_subdev(v4l2_dev, sd))
sd = NULL;
/* Decrease the module use count to match the first
try_module_get. */ module_put(spi-dev.driver-owner);
error:
/* If we have a client but no subdev, then something went
wrong and we must unregister the client. */
if (spi sd == NULL)
spi_unregister_device(spi);
return sd;
}
EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
Not work
[6.048195] Linux video capture interface: v2.00
[6.112987] saa7130/34: v4l2 driver version 0.2.15 loaded
[6.113067] saa7134 :04:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[6.113117] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency:
32, mmio: 0xe510
[6.113176] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7
[card=171,autodetected]
[6.113241] saa7133[0]: board init: gpio is 20
[6.113292] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.264512] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00
00 00 00 01
[6.265136] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.265731] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.266327] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.266922] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.267517] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.268113] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.268718] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.269313] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.269908] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.270503] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.271098] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.271693] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.272289] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.272895] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff
ff ff ff ff
[6.273490] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff
ff ff ff ff
[6.360023] tuner 1-0061: chip found @ 0xc2 (saa7133[0])
[6.401952] xc5000 1-0061: creating new instance
[6.412005] xc5000: Successfully identified at address 0x61
[6.412054] xc5000: Firmware has not been loaded previously
[6.477742] HDA Intel :00:1b.0: PCI INT A - GSI 16 (level, low) - IRQ
16
[6.477816] HDA Intel :00:1b.0: setting latency timer to 64
[ 34.752763] saa7134 :04:01.0: spi master registered: bus_num=32766
num_chipselect=1
[ 34.752823] saa7133[0]: found muPD61151 MPEG encoder
[ 34.752883] befor request_module
[ 240.476013] INFO: task modprobe:1404 blocked for more than 120 seconds.
[ 240.476016] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 240.476018] modprobe D f6b913c0 0 1404 1
[ 240.476021]
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hans Verkuil wrote: On Wednesday 27 January 2010 22:48:24 Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. It's up and running again. Note that I upgraded to the latest gcc 4.4.3. I also updated all the kernels to their latest dot release. I'm happy to hear that this regular check is running again. I think this is an important tool to increase quality of v4l subsystem. 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
