[PATCH] i2c_board_info can be local
Recent fixes to the em28xx and saa7134 drivers have been overzealous.
While the ir-kbd-i2c platform data indeed needs to be persistent, the
struct i2c_board_info doesn't, as it is only used by i2c_new_device().
So revert a part of the original fixes, to save some memory.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
linux/drivers/media/video/em28xx/em28xx-cards.c |9 +
linux/drivers/media/video/em28xx/em28xx.h |1 -
linux/drivers/media/video/saa7134/saa7134-input.c | 21 +++--
linux/drivers/media/video/saa7134/saa7134.h |1 -
4 files changed, 16 insertions(+), 16 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-09-26 13:10:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-10-02
10:05:47.0 +0200
@@ -2306,6 +2306,7 @@ void em28xx_register_i2c_ir(struct em28x
return;
}
#else
+ struct i2c_board_info info;
const unsigned short addr_list[] = {
0x30, 0x47, I2C_CLIENT_END
};
@@ -2313,9 +2314,9 @@ void em28xx_register_i2c_ir(struct em28x
if (disable_ir)
return;
- memset(dev-info, 0, sizeof(dev-info));
+ memset(info, 0, sizeof(struct i2c_board_info));
memset(dev-init_data, 0, sizeof(dev-init_data));
- strlcpy(dev-info.type, ir_video, I2C_NAME_SIZE);
+ strlcpy(info.type, ir_video, I2C_NAME_SIZE);
#endif
/* detect configure */
@@ -2361,8 +2362,8 @@ void em28xx_register_i2c_ir(struct em28x
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
if (dev-init_data.name)
- dev-info.platform_data = dev-init_data;
- i2c_new_probed_device(dev-i2c_adap, dev-info, addr_list);
+ info.platform_data = dev-init_data;
+ i2c_new_probed_device(dev-i2c_adap, info, addr_list);
#endif
}
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx.h 2009-09-26
13:10:09.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx.h 2009-10-02
10:13:10.0 +0200
@@ -625,7 +625,6 @@ struct em28xx {
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
/* I2C keyboard data */
- struct i2c_board_info info;
struct IR_i2c_init_data init_data;
#endif
};
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-09-26 13:10:09.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
10:15:04.0 +0200
@@ -745,6 +745,7 @@ void saa7134_probe_i2c_ir(struct saa7134
#endif
{
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
+ struct i2c_board_info info;
const unsigned short addr_list[] = {
0x7a, 0x47, 0x71, 0x2d,
I2C_CLIENT_END
@@ -771,9 +772,9 @@ void saa7134_probe_i2c_ir(struct saa7134
}
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
- memset(dev-info, 0, sizeof(dev-info));
+ memset(info, 0, sizeof(struct i2c_board_info));
memset(dev-init_data, 0, sizeof(dev-init_data));
- strlcpy(dev-info.type, ir_video, I2C_NAME_SIZE);
+ strlcpy(info.type, ir_video, I2C_NAME_SIZE);
#endif
switch (dev-board) {
@@ -791,7 +792,7 @@ void saa7134_probe_i2c_ir(struct saa7134
#else
dev-init_data.get_key = get_key_pinnacle_color;
dev-init_data.ir_codes =
ir_codes_pinnacle_color_table;
- dev-info.addr = 0x47;
+ info.addr = 0x47;
#endif
} else {
#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 30)
@@ -800,7 +801,7 @@ void saa7134_probe_i2c_ir(struct saa7134
#else
dev-init_data.get_key = get_key_pinnacle_grey;
dev-init_data.ir_codes = ir_codes_pinnacle_grey_table;
- dev-info.addr = 0x47;
+ info.addr = 0x47;
#endif
}
break;
@@ -824,7 +825,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev-init_data.name = MSI t...@nywhere Plus;
dev-init_data.get_key = get_key_msi_tvanywhere_plus;
dev-init_data.ir_codes = ir_codes_msi_tvanywhere_plus_table;
- dev-info.addr = 0x30;
+ info.addr = 0x30;
/* MSI t...@nywhere Plus controller doesn't seem to
respond to probes unless we read something from
an existing device. Weird...
@@ -875,22 +876,22 @@ void saa7134_probe_i2c_ir(struct saa7134
#else
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
- dev-info.addr = 0x40;
+ info.addr = 0x40;
#endif
break;
}
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
if (dev-init_data.name)
- dev-info.platform_data = dev-init_data;
+
[PATCH] Fix wrong sizeof
Which is why I have always preferred sizeof(struct foo) over sizeof(var). Signed-off-by: Jean Delvare kh...@linux-fr.org --- linux/drivers/media/dvb/dvb-usb/ce6230.c|2 +- linux/drivers/media/video/saa7164/saa7164-cmd.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/ce6230.c 2009-09-26 13:10:08.0 +0200 +++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/ce6230.c2009-10-02 11:03:17.0 +0200 @@ -105,7 +105,7 @@ static int ce6230_i2c_xfer(struct i2c_ad int i = 0; struct req_t req; int ret = 0; - memset(req, 0, sizeof(req)); + memset(req, 0, sizeof(req)); if (num 2) return -EINVAL; --- v4l-dvb.orig/linux/drivers/media/video/saa7164/saa7164-cmd.c 2009-09-26 13:10:09.0 +0200 +++ v4l-dvb/linux/drivers/media/video/saa7164/saa7164-cmd.c 2009-10-02 11:03:21.0 +0200 @@ -347,7 +347,7 @@ int saa7164_cmd_send(struct saa7164_dev /* Prepare some basic command/response structures */ memset(command_t, 0, sizeof(command_t)); - memset(response_t, 0, sizeof(response_t)); + memset(response_t, 0, sizeof(response_t)); pcommand_t = command_t; presponse_t = response_t; command_t.id = id; -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Zolid Hybrid PCI card add AGC control
On Thu, Sep 24, 2009 at 02:55:42PM -0400, Michael Krufky wrote:
On Tue, Sep 22, 2009 at 5:09 PM, s...@systol-ng.god.lan wrote:
Switches IF AGC control via GPIO 21 of the saa7134. Improves DTV reception
and
FM radio reception.
Signed-off-by: henk.vergo...@gmail.com
Reviewed-by: Michael Krufky mkru...@kernellabs.com
Henk,
This is *very* interesting... Have you taken a scope to the board to
measure AGC interference? This seems to be *very* similar to
Hauppauge's design for the HVR1120 and HVR1150 boards, which are
actually *not* based on any reference design.
I have no problems with this patch, but I would be interested to hear
that you can prove it is actually needed by using a scope. If you
don't have a scope, I understand but this certainly peaks my
interest.
Do you have schematics of that board?
Regards,
Mike Krufky
One note: I have tested the tda18271 signedness fixes in the debug
repository. This is a big improvement in reception.
Based on the latest testing with all the fixes I would say that
switching the AGC line via gpio is not needed and leaving it at 0 gives
the best results.
(This is purely based on SNR and BER readings from tzap)
So I would recomend: leaving config at zero.
static struct tda18271_config zolid_tda18271_config = {
.std_map = zolid_tda18271_std_map,
.gate= TDA18271_GATE_ANALOG,
- .config = 3,
+// .config = 3,
.output_opt = TDA18271_OUTPUT_LT_OFF,
};
Regards,
Henk
--
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
What is the status of the driver TT CT-3650
Hi I have recently bought such a card and tried to get it working. Does anyone know if it is possible. I have compiled the dvb drivers from s2-liplianin And tried to use the scan program from the dvb-apps mercurial tarball. I also compile scan-s2 and tried that, but I always get tuning failed Anyone know how to get this working or this card is in a working state under linux. Because if it not working yet I will stop wasting my time :-) Regards Hasse H. Johansen -- 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: What is the status of the driver TT CT-3650
On Fri, Oct 2, 2009 at 9:20 AM, Hasse Hagen Johansen hhj-linux-...@musikcheck.dk wrote: Hi I have recently bought such a card and tried to get it working. Does anyone know if it is possible. I have compiled the dvb drivers from s2-liplianin And tried to use the scan program from the dvb-apps mercurial tarball. I also compile scan-s2 and tried that, but I always get tuning failed Anyone know how to get this working or this card is in a working state under linux. Because if it not working yet I will stop wasting my time :-) it didn't work for me either, so I returned it and stick with my old DVB-T device again.. James -- 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
Mem2Mem V4L2 devices [RFC]
Hello, During the V4L2 mini-summit and the Media Controller RFC discussion on Linux Plumbers 2009 Conference a mem2mem video device has been mentioned a few times (usually in a context of a 'resizer device' which might be a part of Camera interface pipeline or work as a standalone device). We are doing a research how our custom video/multimedia drivers can fit into the V4L2 framework. Most of our multimedia devices work in mem2mem mode. I did a quick research and I found that currently in the V4L2 framework there is no device that processes video data in a memory-to-memory model. In terms of V4L2 framework such device would be both video sink and source at the same time. The main problem is how the video nodes (/dev/videoX) should be assigned to such a device. The simplest way of implementing mem2mem device in v4l2 framework would use two video nodes (one for input and one for output). Such an idea has been already suggested on V4L2 mini-summit. Each DMA engine (either input or output) that is available in the hardware should get its own video node. In this approach an application can write() source image to for example /dev/video0 and then read the processed output from for example /dev/video1. Source and destination format/params/other custom settings also can be easily set for either source or destination node. Besides a single image, user applications can also process video streams by calling stream_on(), qbuf() + dqbuf(), stream_off() simultaneously on both video nodes. This approach has a limitation however. As user applications would have to open 2 different file descriptors to perform the processing of a single image, the v4l2 driver would need to match read() calls done on one file descriptor with write() calls from the another. The same thing would happen with buffers enqueued with qbuf(). In practice, this would result in a driver that allows only one instance of /dev/video0 as well as /dev/video1 opened. Otherwise, it would not be possible to track which opened /dev/video0 instance matches which /dev/video1 one. The real limitation of this approach is the fact, that it is hardly possible to implement multi-instance support and application multiplexing on a video device. In a typical embedded system, in contrast to most video-source-only or video-sink-only devices, a mem2mem device is very often used by more than one application at a time. Be it either simple one-shot single video frame processing or stream processing. Just consider that the 'resizer' module might be used in many applications for scaling bitmaps (xserver video subsystem, gstreamer, jpeglib, etc) only. At the first glance one might think that implementing multi-instance support should be done in a userspace daemon instead of mem2mem drivers. However I have run into problems designing such a user space daemon. Usually, video buffers are passed to v4l2 device as a user pointer or are mmaped directly from the device. The main issue that cannot be easily resolved is passing video buffers from the client application to the daemon. The daemon would queue a request on the device and return results back to the client application after a transaction is finished. Passing userspace pointers between an application and the daemon cannot be done, as they are two different processes. Mmap-type buffers are similar in this aspect - at least 2 buffer copy operations are required (from client application to device input buffers mmaped in daemon's memory and then from device output buffers to client application). Buffer copying and process context switches add both latency and additional cpu workload. In our custom drivers for mem2mem multimedia devices we implemented a queue shared between all instances of an opened mem2mem device. Each instance is assigned to an open device file descriptor. The queue is serviced in the device context, thus maximizing the device throughput. This is achieved by scheduling the next transaction in the driver (kernel) context. This may not even require a context switch at all. Do you have any ideas how would this solution fit into the current v4l2 design? Another solution that came into my mind that would not suffer from this limitation is to use the same video node for both writing input buffers and reading output buffers (or queuing both input and output buffers). Such a design causes more problems with the current v4l2 design however: 1. How to set different color space or size for input and output buffer each? It could be solved by adding a set of ioctls to get/set source image format and size, while the existing v4l2 ioctls would only refer to the output buffer. Frankly speaking, we don't like this idea. 2. Input and output in the same video node would not be compatible with the upcoming media controller, with which we will get an ability to arrange devices into a custom pipeline. Piping together two separate input-output nodes to
IR device at I2C address 0x7a
Hi all,
[Executive summary: Upmost Purple TV adapter testers wanted!]
While investigating another issue, I have noticed the following message
in the kernel logs of a saa7134 user:
i2c-adapter i2c-0: Invalid 7-bit address 0x7a
The address in question is attempted by an IR device probe, and is only
probed on SAA7134 adapters. The problem with this address is that it is
reserved by the I2C specification for 10-bit addressing, and is thus
not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
new-style i2c device driver binding model, device probing was done by
ir-kbd-i2c itself so no check was done by i2c-core for address
validity. But since kernel 2.6.31, probing at address 0x7a will be
denied by i2c-core.
So, SAA7134 adapters with an IR device at 0x7a are currently broken.
Do we know how many devices use this address for IR and which they
are? Tracking the changes in the source code, this address was added
in kernel 2.6.8 by Gerd Knorr:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
So this would be used by the Upmost Purple TV adapter. Question is,
are there other?
Some web research has pointed me to the Yuan TUN-900:
http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
but it isn't clear to me whether the device at 0x7a on this adapter is
the same as the one on the Purple TV. And saa7134-cards says of the
TUN-900: Remote control not yet implemented so maybe we can just
ignore it for now.
If we have to, I could make i2c-core more permissive, but I am rather
reluctant to letting invalid addressed being probed, because you never
know how complying chips on the I2C bus will react. I am OK supporting
invalid addresses if they really exist out there, but the impact should
be limited to the hardware in question.
If we only have to care about the Upmost Purple TV, then the following
patch should solve the problem:
* * * * *
From: Jean Delvare kh...@linux-fr.org
Subject: saa7134: Fix IR support for Purple TV
The i2c core prevents us from probing I2C address 0x7a because it's
not a valid 7-bit address (reserved for 10-bit addressing.) So we must
stop probing this address, and explicitly list all adapters which use
it. Under the assumption that only the Upmost Purple TV adapter uses
this invalid address, this fix should do the trick.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-10-02 13:26:39.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
13:26:49.0 +0200
@@ -746,7 +746,7 @@ void saa7134_probe_i2c_ir(struct saa7134
{
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
const unsigned short addr_list[] = {
- 0x7a, 0x47, 0x71, 0x2d,
+ 0x47, 0x71, 0x2d,
I2C_CLIENT_END
};
@@ -813,6 +813,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev-init_data.name = Purple TV;
dev-init_data.get_key = get_key_purpletv;
dev-init_data.ir_codes = ir_codes_purpletv_table;
+ info.addr = 0x7a;
#endif
break;
case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885 audio
On 10/1/09 11:52 PM, David T.L. Wong wrote: Hi all, It there any cx23885 audio support on current v4l-dvb tree, Or any development tree for cx23885 audio? http://www.kernellabs.com/blog/?p=788 I'm about to start on this. -- Steven Toth - 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: cx23885 audio
Steven Toth wrote: On 10/1/09 11:52 PM, David T.L. Wong wrote: Hi all, It there any cx23885 audio support on current v4l-dvb tree, Or any development tree for cx23885 audio? http://www.kernellabs.com/blog/?p=788 I'm about to start on this. Cool, Let's work on that together. David -- 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 4/4] Zolid Hybrid PCI card add AGC control
On Fri, Oct 2, 2009 at 5:12 AM, s...@systol-ng.god.lan wrote:
On Thu, Sep 24, 2009 at 02:55:42PM -0400, Michael Krufky wrote:
On Tue, Sep 22, 2009 at 5:09 PM, s...@systol-ng.god.lan wrote:
Switches IF AGC control via GPIO 21 of the saa7134. Improves DTV reception
and
FM radio reception.
Signed-off-by: henk.vergo...@gmail.com
Reviewed-by: Michael Krufky mkru...@kernellabs.com
Henk,
This is *very* interesting... Have you taken a scope to the board to
measure AGC interference? This seems to be *very* similar to
Hauppauge's design for the HVR1120 and HVR1150 boards, which are
actually *not* based on any reference design.
I have no problems with this patch, but I would be interested to hear
that you can prove it is actually needed by using a scope. If you
don't have a scope, I understand but this certainly peaks my
interest.
Do you have schematics of that board?
Regards,
Mike Krufky
One note: I have tested the tda18271 signedness fixes in the debug
repository. This is a big improvement in reception.
Based on the latest testing with all the fixes I would say that
switching the AGC line via gpio is not needed and leaving it at 0 gives
the best results.
(This is purely based on SNR and BER readings from tzap)
So I would recomend: leaving config at zero.
static struct tda18271_config zolid_tda18271_config = {
.std_map = zolid_tda18271_std_map,
.gate = TDA18271_GATE_ANALOG,
- .config = 3,
+// .config = 3,
.output_opt = TDA18271_OUTPUT_LT_OFF,
};
I removed the patch from my tree awaiting merge, saa7134: add AGC
control for Zolid Hybrid PCI card.
It wasn't as simple as changing the 3 to a 0, since the function,
saa7134_tda18271_zolid_toggle_agc becomes a no-op.
Also, you've been sending the sign-off's in the wrong format in your
previous submissions.
Please send in the FM reception via RF_IN as a separate patch, and
include your sign-off using the actual format:
Signed-off-by: Your Name em...@addre.ss
Regards,
Mike
--
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
mt9t031-VPFE integration issues...
Hi Guennadi, I am currently integrating latest MT9T031 driver to vpfe_capture driver and see following issues:- 1) Currently MT9T031 Kconfig configuration variable has a dependency on SOC_CAMERA. We need to remove this dependency since this sensor can be used on other platforms like DM6446/DM355/DM365. This is trivial and I can send a patch to remove the dependency. 2) The code still has reference to soc_camera_device and associated changes. I think this should be removed so that it can be used on other platforms as well. I am expecting these will go away once the bus parameter as well data format related RFCs are approved. If this is true, I can wait until the same is approved. If not, we need to work together so that this driver can be integrated with vpfe capture driver. Please let me know what you think on this. Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.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
Programming sensor through firmware files bc of NDA
Hi all, I'm currently interested in knowing what is the stand on having a v4l2_subdev driver that uses some kind of binary for programming registers in a image sensor driver. NOTE: I must confess I currently don't know how to do it (Any pointers/samples for doing it on a proper way?) The only reason for doing this is to avoid potential violation of NDA with sensor manufacturer by exposing all register details. Please comment. Regards, Sergio-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix wrong sizeof
linux/drivers/media/video/saa7164/saa7164-cmd.c |2 +- Acked-By: Steven Toth st...@kernellabs.com -- Steven Toth - 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: Mem2Mem V4L2 devices [RFC]
Hi Marek, On Fri, 2009-10-02 at 13:45 +0200, Marek Szyprowski wrote: Hello, During the V4L2 mini-summit and the Media Controller RFC discussion on Linux Plumbers 2009 Conference a mem2mem video device has been mentioned a few times (usually in a context of a 'resizer device' which might be a part of Camera interface pipeline or work as a standalone device). We are doing a research how our custom video/multimedia drivers can fit into the V4L2 framework. Most of our multimedia devices work in mem2mem mode. I did a quick research and I found that currently in the V4L2 framework there is no device that processes video data in a memory-to-memory model. In terms of V4L2 framework such device would be both video sink and source at the same time. The main problem is how the video nodes (/dev/videoX) should be assigned to such a device. The simplest way of implementing mem2mem device in v4l2 framework would use two video nodes (one for input and one for output). Such an idea has been already suggested on V4L2 mini-summit. Each DMA engine (either input or output) that is available in the hardware should get its own video node. In this approach an application can write() source image to for example /dev/video0 and then read the processed output from for example /dev/video1. Source and destination format/params/other custom settings also can be easily set for either source or destination node. Besides a single image, user applications can also process video streams by calling stream_on(), qbuf() + dqbuf(), stream_off() simultaneously on both video nodes. This approach has a limitation however. As user applications would have to open 2 different file descriptors to perform the processing of a single image, the v4l2 driver would need to match read() calls done on one file descriptor with write() calls from the another. The same thing would happen with buffers enqueued with qbuf(). In practice, this would result in a driver that allows only one instance of /dev/video0 as well as /dev/video1 opened. Otherwise, it would not be possible to track which opened /dev/video0 instance matches which /dev/video1 one. The real limitation of this approach is the fact, that it is hardly possible to implement multi-instance support and application multiplexing on a video device. In a typical embedded system, in contrast to most video-source-only or video-sink-only devices, a mem2mem device is very often used by more than one application at a time. Be it either simple one-shot single video frame processing or stream processing. Just consider that the 'resizer' module might be used in many applications for scaling bitmaps (xserver video subsystem, gstreamer, jpeglib, etc) only. At the first glance one might think that implementing multi-instance support should be done in a userspace daemon instead of mem2mem drivers. However I have run into problems designing such a user space daemon. Usually, video buffers are passed to v4l2 device as a user pointer or are mmaped directly from the device. The main issue that cannot be easily resolved is passing video buffers from the client application to the daemon. The daemon would queue a request on the device and return results back to the client application after a transaction is finished. Passing userspace pointers between an application and the daemon cannot be done, as they are two different processes. Mmap-type buffers are similar in this aspect - at least 2 buffer copy operations are required (from client application to device input buffers mmaped in daemon's memory and then from device output buffers to client application). Buffer copying and process context switches add both latency and additional cpu workload. In our custom drivers for mem2mem multimedia devices we implemented a queue shared between all instances of an opened mem2mem device. Each instance is assigned to an open device file descriptor. The queue is serviced in the device context, thus maximizing the device throughput. This is achieved by scheduling the next transaction in the driver (kernel) context. This may not even require a context switch at all. Do you have any ideas how would this solution fit into the current v4l2 design? Another solution that came into my mind that would not suffer from this limitation is to use the same video node for both writing input buffers and reading output buffers (or queuing both input and output buffers). Such a design causes more problems with the current v4l2 design however: 1. How to set different color space or size for input and output buffer each? It could be solved by adding a set of ioctls to get/set source image format and size, while the existing v4l2 ioctls would only refer to the output buffer. Frankly speaking, we don't like this idea. I think that is not unusual one video device to define that it can support at
Re: [linux-dvb] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
On Fri, Oct 2, 2009 at 1:23 PM, Christophe Boyanique tof+linux-...@raceme.org wrote: Hello,, Is anyone on the list currently using a DVB-T card that has DUAL tuners (i.e. I'm looking to replace Hauppage 500's which work great). That is an excellent question and I am looking forward to here people about success stories. I am also looking for a device (PCIe preferred, or PCI or at worst USB stick) with a dual HD tuner which is buyable from France or Europe... I found this models which seem to be NOT supported: - TerraTec Cinergy 2400i DT (not supported from wiki) - TerraTec T5 Stick (no information found) - PCTV Stick Dual DVB-T Diversity (2001e) (not supported from wiki) - AVerMedia AVerTV Duo Hybrid PCI-E A188H (no information found) I found this card which seems to be supported: - Dvico FusionHDTV DVB-T Dual Express but I do not find any reseller in Europe. I found an online reseller in the USA here: http://www.cyberestore.com/hdtv-tv-tuner-cards/dvico-fusionhdtv-dvb-t-dual-express.html But I am not sure that a card sold in the USA will work in Europe as USA uses NTSC and ATSC (instead of PAL and DVB in Europe). Christophe. Have you looked at the HVR-2200 (PCIe, dual DVB-T)? 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: [Bulk] V4L-DVB Summit Day 3
Hans Verkuil wrote: I made the following list: - We created a new mc mailinglist: linux...@googlegroups.com This is a temporary mailinglist where we can post and review patches during prototyping of the mc API. We don't want to flood the linux-media list with those patches since that is already quite high-volume. The mailinglist should be active, although I couldn't find it yet from www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did something wrong. I'm scratching my head on this one. Seems the last thing that is needed is YET another mailing list. Further, it - fractures the development community. - persons unaware of the decision, and whom might be interested, would never find it . i.e. alienation - disinterested parties can simply hit the delete key and not bother with the message - blah blah blah .. PS. In regards to yesterday's business announcements, I hope your new forthcoming overlords are as kind to you as your last -- 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:Fri Oct 2 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13044:6b7617d4a0be gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.27-armv5-ixp: ERRORS linux-2.6.28-armv5-ixp: ERRORS linux-2.6.29.1-armv5-ixp: ERRORS linux-2.6.30-armv5-ixp: ERRORS linux-2.6.31-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29.1-powerpc64: ERRORS linux-2.6.30-powerpc64: ERRORS linux-2.6.31-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS sparse (linux-2.6.31): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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
saa716x compiling problem
Hello, I'm trying to compile saa716x module for kernel 2.6.30 but I'm getting some errors. It seems that sources need to be adapted to latest kernel versions to work. I'm using code located at http://www.jusst.de/hg/saa716x/ (last change was three months ago). Is there any patch to solve this problem? Jonathan -- 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: saa716x compiling problem
Hi, You could try http://mercurial.intuxication.org/hg/s2-liplianin I think the jusst.de version is outdated regarding the newer kernels. BR: Beepo - Original Message - From: Jonathan jkds...@gmail.com To: linux-media@vger.kernel.org Sent: Friday, October 2, 2009 9:44:05 PM GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: saa716x compiling problem Hello, I'm trying to compile saa716x module for kernel 2.6.30 but I'm getting some errors. It seems that sources need to be adapted to latest kernel versions to work. I'm using code located at http://www.jusst.de/hg/saa716x/ (last change was three months ago). Is there any patch to solve this problem? Jonathan -- 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: IR device at I2C address 0x7a
Hi,
Am Freitag, den 02.10.2009, 13:47 +0200 schrieb Jean Delvare:
Hi all,
[Executive summary: Upmost Purple TV adapter testers wanted!]
unlikely that anybody with such a card is on the new list currently or
any. I add some old known owners, but mail might bounce.
While investigating another issue, I have noticed the following message
in the kernel logs of a saa7134 user:
i2c-adapter i2c-0: Invalid 7-bit address 0x7a
The address in question is attempted by an IR device probe, and is only
probed on SAA7134 adapters. The problem with this address is that it is
reserved by the I2C specification for 10-bit addressing, and is thus
not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
new-style i2c device driver binding model, device probing was done by
ir-kbd-i2c itself so no check was done by i2c-core for address
validity. But since kernel 2.6.31, probing at address 0x7a will be
denied by i2c-core.
So, SAA7134 adapters with an IR device at 0x7a are currently broken.
Do we know how many devices use this address for IR and which they
are? Tracking the changes in the source code, this address was added
in kernel 2.6.8 by Gerd Knorr:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
So this would be used by the Upmost Purple TV adapter. Question is,
are there other?
Yes, currently 0x7a is only used by the Upmost Purple TV (Yuan Tun800).
Here are some more details.
http://archives.devshed.com/forums/linux-97/troubles-with-yuan-tun900-board-detected-as-upmost-purple-tv-1283673.html
Support for the card and the i2c remote was added by Wang-Chan Chen.
For testers it is useful to know that the card is still not fully
supported.
It has a NEC D64083GF video enhancer converting TV baseband video from
tuner to S-Video and shares the vmux = 7 with the S-Video input.
By default it comes up in external S-Video input mode.
There is a Pericom videomux on it and we don't know how to switch it.
Chen used to boot at first windows, switched there to tuner input and
rebooted to GNU/Linux ...
Some web research has pointed me to the Yuan TUN-900:
http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
but it isn't clear to me whether the device at 0x7a on this adapter is
the same as the one on the Purple TV. And saa7134-cards says of the
TUN-900: Remote control not yet implemented so maybe we can just
ignore it for now.
Yes, that card has a device at 0xf4/0x7a too.
I asked to test the remote with the Upmost Purple TV entry, but never
got a reply. As we know these days, radio amux is wrong too on Yuan
TUN900 card=66.
Last contact to Chen was four years back, but he confirmed that both
cards have the same PCI subsystem. Some bytes in the eeprom, meaning
unknown, are different, though.
If we have to, I could make i2c-core more permissive, but I am rather
reluctant to letting invalid addressed being probed, because you never
know how complying chips on the I2C bus will react. I am OK supporting
invalid addresses if they really exist out there, but the impact should
be limited to the hardware in question.
If we only have to care about the Upmost Purple TV, then the following
patch should solve the problem:
For what is known so far.
Acked-by: hermann pitton hermann-pit...@arcor.de
Cheers,
Hermann
* * * * *
From: Jean Delvare kh...@linux-fr.org
Subject: saa7134: Fix IR support for Purple TV
The i2c core prevents us from probing I2C address 0x7a because it's
not a valid 7-bit address (reserved for 10-bit addressing.) So we must
stop probing this address, and explicitly list all adapters which use
it. Under the assumption that only the Upmost Purple TV adapter uses
this invalid address, this fix should do the trick.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-10-02 13:26:39.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02
13:26:49.0 +0200
@@ -746,7 +746,7 @@ void saa7134_probe_i2c_ir(struct saa7134
{
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 30)
const unsigned short addr_list[] = {
- 0x7a, 0x47, 0x71, 0x2d,
+ 0x47, 0x71, 0x2d,
I2C_CLIENT_END
};
@@ -813,6 +813,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev-init_data.name = Purple TV;
dev-init_data.get_key = get_key_purpletv;
dev-init_data.ir_codes = ir_codes_purpletv_table;
+ info.addr = 0x7a;
#endif
break;
case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
--
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
Re: [Bulk] V4L-DVB Summit Day 3
On Fri, Oct 2, 2009 at 7:56 PM, CityK ci...@rogers.com wrote: Hans Verkuil wrote: I made the following list: - We created a new mc mailinglist: linux...@googlegroups.com This is a temporary mailinglist where we can post and review patches during prototyping of the mc API. We don't want to flood the linux-media list with those patches since that is already quite high-volume. The mailinglist should be active, although I couldn't find it yet from www.googlegroups.com. I'm not sure if it hasn't shown up yet, or if I did something wrong. I'm scratching my head on this one. Seems the last thing that is needed is YET another mailing list. Further, it - fractures the development community. this is what I think too. I'm mainly interested in keeping up compatibility with that framework The traffic on this mailinglist is rather small and it should be ok to mix up developer mails with a few support mails (whereas people usually use to CC anyone who might be involved anyway). - persons unaware of the decision, and whom might be interested, would never find it . i.e. alienation if you try to send an email as adviced to that googlemail mailinglist you'll just get an email back that it doesn't work :-) nothing else to write about it I totally agree. One question I have though, what is the impact to the existing API, will they start to require that MC interface? TI hardware is rather specialized and most other devices will not need any of those changes, I don't see the benefit of bloating up the API for devices which already work fine, for simple devices it should better remain simple. (This question is mainly because we also maintain our own player which supports the v4l2/dvbV(3/5) API, but the driver should still support legacy applications in the future) Best Regards, Markus -- 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
AVerTV MCE 116 Plus remote
Preliminary version of patch adding support for AVerTV MCE 116 Plus remote.
This board has an IR sensor is connected to EM78P153S, general purpose 8-bit
microcontroller with a 1024 × 13 bits of OTP-ROM. According to i2cdetect, it is
sitting on address 0x40.
Patch allows ir-kbd-i2c to probe cx2341x boards for this address. Manually
loading ir-kbd-i2c now detects remote, every key is working as expected.
As I understand, current I2C/probing code is being redesigned/refactored. Sheer
amount of #ifdefs for every second kernel version is making my eyes bleed, so
please somebody involved check if patch is ok.
Should I also add the 0x40 address to addr_list[] in ivtv-i2c.c? How to point
ivtv to this remote and autoload ir-kbd-i2c?
diff --git a/linux/drivers/media/video/ir-kbd-i2c.c
b/linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.c
+++ b/linux/drivers/media/video/ir-kbd-i2c.c
@@ -461,7 +461,7 @@
}
break;
case 0x40:
- name= AVerMedia Cardbus remote;
+ name= AVerMedia RM-FP/RM-KH remote;
ir-get_key = get_key_avermedia_cardbus;
ir_type = IR_TYPE_OTHER;
ir_codes= ir_codes_avermedia_cardbus_table;
@@ -706,8 +706,12 @@
ir_attach(adap, msg.addr, 0, 0);
}
- /* Special case for AVerMedia Cardbus remote */
- if (adap-id == I2C_HW_SAA7134) {
+ /* Special case for AVerMedia remotes:
+ * AVerTV Hybrid+FM Cardbus
+ * AVerTV MCE 116 Plus
+ * probably others with RM-FP, RM-KH remotes and microcontroller
+chip @ 0x40 */
+ if ((adap-id == I2C_HW_SAA7134) || (adap-id == I2C_HW_B_CX2341X)) {
unsigned char subaddr, data;
struct i2c_msg msg[] = { { .addr = 0x40, .flags = 0,
.buf = subaddr, .len = 1},
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
On Fri, Oct 02, 2009 at 01:48:17PM -0400, Devin Heitmueller wrote: I am also looking for a device (PCIe preferred, or PCI or at worst USB stick) with a dual HD tuner which is buyable from France or Europe... Have you looked at the HVR-2200 (PCIe, dual DVB-T)? This card sounds great but it does not seem to be HD :( Christophe. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Any PCIe DVB-T Dual Tuner cards yet working under Linux?
On Fri, Oct 2, 2009 at 6:27 PM, Christophe Boyanique tof+linux-...@raceme.org wrote: On Fri, Oct 02, 2009 at 01:48:17PM -0400, Devin Heitmueller wrote: I am also looking for a device (PCIe preferred, or PCI or at worst USB stick) with a dual HD tuner which is buyable from France or Europe... Have you looked at the HVR-2200 (PCIe, dual DVB-T)? This card sounds great but it does not seem to be HD :( Christophe. Yes, it does HD. 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: [RFC] Global video buffers pool
Laurent Pinchart laurent.pinchart at ideasonboard.com writes: Hi Stefan, On Monday 28 September 2009 16:04:58 Stefan.Kost at nokia.com wrote: hi, -Original Message- From: ext Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com] Sent: 16 September, 2009 18:47 To: linux-media at vger.kernel.org; Hans Verkuil; Sakari Ailus; Cohen David.A (Nokia-D/Helsinki); Koskipaa Antti (Nokia-D/Helsinki); Zutshi Vimarsh (Nokia-D/Helsinki); Kost Stefan (Nokia-D/Helsinki) Subject: [RFC] Global video buffers pool Hi everybody, I didn't want to miss this year's pretty flourishing RFC season, so here's another one about a global video buffers pool. Sorry for ther very late reply. No worries, better late than never. I have been thinking about the problem on a bit broader scale and see the need for something more kernel wide. E.g. there is some work done from intel for graphics: http://keithp.com/blogs/gem_update/ and this is not so much embedded even. If there buffer pools are v4l2specific then we need to make all those other subsystems like xvideo, opengl, dsp-bridges become v4l2 media controllers. The global video buffers pool topic has been discussed during the v4l2 mini- summit at Portland last week, and we all agreed that it needs more research. The idea of having pools at the media controller level has been dropped in favor of a kernel-wide video buffers pool. Whether we can make the buffers pool not v4l2-specific still needs to be tested. As you have pointed out, we currently have a GPU memory manager in the kernel, and being able to interact with it would be very interesting if we want to DMA video data to OpenGL texture buffers for instance. I'm not sure if that would be possible though, as the GPU and the video acquisition hardware might have different memory requirements, at least in the general case. I will contact the GEM guys at Intel to discuss the topic. If we can't share the buffers between the GPU and the rest of the system, we could at least create a V4L2 wrapper on top of the DSP bridge core (which will require a major cleanup/restructuring), making it possible to share video buffers between the ISP and the DSP. TI has been providing this sort of contiguous buffer support for quite a few years now. TI provides a SW package named LinuxUtils, and it contains a module named CMEM (stand for Contiguous MEMory manager). Latest LinuxUtils release, contains cdocs of CMEM: http://software- dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/2_24_03/exports/l inuxutils_2_24_03.tar.gz And the background/usage article here: http://tiexpressdsp.com/index.php/CMEM_Overview CMEM solves lots of the same sorts of things that the driver described in this thread does. However, it doesn't integrate into other drivers, and it's accessed through the CMEM user interface. Also, CMEM alleviates some of the issues raised in this thread since it uses memory not known to the kernel (user carves out a chunk by reducing kernel memory through u-boot mem= param), which IMO can be both good and bad (good - alleviates locking/unavailable memory issues, bad - doesn't cooperate with the kernel in getting memory, requiring user intervention). Regards, Robert Tivy MGTS Systems Software Texas Instruments, Santa Barbara -- 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: mt9t031-VPFE integration issues...
Hi Murali On Fri, 2 Oct 2009, Karicheri, Muralidharan wrote: I am currently integrating latest MT9T031 driver to vpfe_capture driver and see following issues:- 1) Currently MT9T031 Kconfig configuration variable has a dependency on SOC_CAMERA. We need to remove this dependency since this sensor can be used on other platforms like DM6446/DM355/DM365. This is trivial and I can send a patch to remove the dependency. 2) The code still has reference to soc_camera_device and associated changes. I think this should be removed so that it can be used on other platforms as well. I am expecting these will go away once the bus parameter as well data format related RFCs are approved. If this is true, I can wait until the same is approved. If not, we need to work together so that this driver can be integrated with vpfe capture driver. You're certainly right - soc-camera based drivers, including mt9t031, still depend on the soc-camera core, although most of the API has been converted to v4l2-subdev. Yes, the two biggest issues are bus-parameter and data-format negotiation. Also, we'll have to find a way to supply the data to the drivers, that is currently set in platform code. So, ideally, yes, we have to wait until the respective RFCs get implemented and until soc-camera gets completely converted, but if this is something urgent - maybe it would be acceptable to start modifying some drivers for dual operation - either with soc-camera API or in pure v4l2-subdev mode. This would be a bit of an extra work, and I don't know what others think about this. So, if you can wait, perhaps, this would be the best. Thanks Guennadi --- Guennadi Liakhovetski -- 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: pxa_camera + mt9m1111: Failed to configure for format 50323234
On Fri, 2 Oct 2009, Antonio Ospite wrote: Hi, after updating to 2.6.32-rc2 I can't capture anymore with the setup in the subject. Indeed:-( Please, verify, that this patch fixes your problem (completely untested), if it does, I'll push it for 2.6.32: pxa_camera: fix camera pixel format configuration A typo prevents correct picel format negotiation with client drivers. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c index 6952e96..aa831d5 100644 --- a/drivers/media/video/pxa_camera.c +++ b/drivers/media/video/pxa_camera.c @@ -1432,7 +1432,9 @@ static int pxa_camera_set_fmt(struct soc_camera_device *icd, icd-sense = sense; cam_f.fmt.pix.pixelformat = cam_fmt-fourcc; - ret = v4l2_subdev_call(sd, video, s_fmt, f); + ret = v4l2_subdev_call(sd, video, s_fmt, cam_f); + cam_f.fmt.pix.pixelformat = pix-pixelformat; + *pix = cam_f.fmt.pix; icd-sense = NULL; Thanks Guennadi Here's the message from userspace: # ./capture-example Cannot open '/dev/video0': 22, Invalid argument which is from the very first open() call. Here's the relevant snippet from dmesg with debug enabled: [ 15.613749] i2c /dev entries driver [ 15.626308] Linux video capture interface: v2.00 [ 15.640834] pxa27x-camera pxa27x-camera.0: Limiting master clock to 2600 [ 15.648696] pxa27x-camera pxa27x-camera.0: LCD clock 10400Hz, target freq 2600Hz, divisor 1 [ 15.656494] pxa27x-camera pxa27x-camera.0: got DMA channel 1 [ 15.665398] pxa27x-camera pxa27x-camera.0: got DMA channel (U) 2 [ 15.673461] pxa27x-camera pxa27x-camera.0: got DMA channel (V) 3 [ 15.686771] camera 0-0: Probing 0-0 [ 15.707545] pxa27x-camera pxa27x-camera.0: Registered platform device at cc889380 data c03a1e98 [ 15.715265] pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios [ 15.723488] pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0 [ 15.739092] mt9m111 0-005d: read reg.00d - 0008 [ 15.743812] mt9m111 0-005d: write reg.00d = 0008 - 0 [ 15.748702] mt9m111 0-005d: read reg.00d - 0008 [ 15.753237] mt9m111 0-005d: write reg.00d = 0009 - 0 [ 15.757864] mt9m111 0-005d: read reg.00d - 0009 [ 15.762386] mt9m111 0-005d: write reg.00d = 0029 - 0 [ 15.766938] mt9m111 0-005d: read reg.00d - 0029 [ 15.771670] mt9m111 0-005d: write reg.00d = 0008 - 0 [ 15.776136] mt9m111 0-005d: write reg.0c8 = 970b - 0 [ 15.781325] mt9m111 0-005d: read reg.106 - 700e [ 15.785695] mt9m111 0-005d: write reg.106 = 700e - 0 [ 15.792896] mt9m111 0-005d: read reg.000 - 143a [ 15.796790] mt9m111 0-005d: Detected a MT9M11x chip ID 143a [ 15.805505] pxa27x-camera pxa27x-camera.0: Providing format Planar YUV422 16 bit using CbYCrY 16 bit [ 15.813285] pxa27x-camera pxa27x-camera.0: Providing format CbYCrY 16 bit packed [ 15.820729] pxa27x-camera pxa27x-camera.0: Providing format CrYCbY 16 bit packed [ 15.828221] pxa27x-camera pxa27x-camera.0: Providing format YCbYCr 16 bit packed [ 15.835484] pxa27x-camera pxa27x-camera.0: Providing format YCrYCb 16 bit packed [ 15.842888] pxa27x-camera pxa27x-camera.0: Providing format RGB 565 packed [ 15.850455] pxa27x-camera pxa27x-camera.0: Providing format RGB 555 packed [ 15.858077] pxa27x-camera pxa27x-camera.0: Providing format Bayer (sRGB) 8 bit in pass-through mode [ 15.872455] pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 ... [ 70.377781] pxa27x-camera pxa27x-camera.0: Registered platform device at cc889380 data c03a1e98 [ 70.377866] pxa27x-camera pxa27x-camera.0: pxa_camera_activate: Init gpios [ 70.378259] pxa27x-camera pxa27x-camera.0: PXA Camera driver attached to camera 0 [ 70.378336] mt9m111 0-005d: mt9m111_s_fmt fmt=50323234 left=24, top=8, width=1280, height=1024 [ 70.379630] mt9m111 0-005d: write reg.002 = 0018 - 0 [ 70.380589] mt9m111 0-005d: write reg.001 = 0008 - 0 [ 70.382382] mt9m111 0-005d: write reg.1a0 = 0500 - 0 [ 70.383347] mt9m111 0-005d: write reg.1a3 = 0400 - 0 [ 70.384312] mt9m111 0-005d: write reg.1a1 = 0500 - 0 [ 70.385267] mt9m111 0-005d: write reg.1a4 = 0400 - 0 [ 70.386227] mt9m111 0-005d: write reg.1a6 = 0500 - 0 [ 70.387188] mt9m111 0-005d: write reg.1a9 = 0400 - 0 [ 70.393180] mt9m111 0-005d: write reg.1a7 = 0500 - 0 [ 70.394155] mt9m111 0-005d: write reg.1aa = 0400 - 0 [ 70.394224] mt9m111 0-005d: Pixel format not handled : 50323234 [ 70.394265] pxa27x-camera pxa27x-camera.0: Failed to configure for format 50323234 [ 70.394310] pxa27x-camera pxa27x-camera.0: PXA Camera driver detached from camera 0 Format 50323234 is 422P, it looks like pxa-camera is trying to force its native format to the sensor, but I am still investigating; I'll come back when I find more or if I come up with a solution. Thanks,
Skipping commercials?
Hello, I would like to skip commercials in my dvb recordings. I know mythtv has some methods but I don't really want the hassle of mythtv setup and use. It is relatively early stage software and besides, I prefer to have a normal window-based UI. I use kaffeine and except for absence of commercial skipping, like it. Ideally I would want a program to run on an already existing recording, to mark or cut out ads. A Windows program, comskip, exists. It is closed source and its configuration seems opaque. I will still try it under wine, but perhaps there is a better way? -- Yours, Mikhail Ramendik -- 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: Skipping commercials?
On Oct 2, 2009, at 9:44 PM, Mikhail Ramendik wrote: Hello, I would like to skip commercials in my dvb recordings. I know mythtv has some methods but I don't really want the hassle of mythtv setup and use. It is relatively early stage software Um. If you say so. Been happily using it for over six years now... and besides, I prefer to have a normal window-based UI. I use kaffeine and except for absence of commercial skipping, like it. Ideally I would want a program to run on an already existing recording, to mark or cut out ads. A Windows program, comskip, exists. It is closed source and its configuration seems opaque. I will still try it under wine, but perhaps there is a better way? MythTV is open-source. Look at the code specific to the mythcommflag binary. Adapt it for stand-alone use. It wouldn't even have to do the actual cutting, just output a cutlist something like gopchop, avidemux or similar could use to set cut points. -- Jarod Wilson ja...@wilsonet.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: IR device at I2C address 0x7a
On Oct 2, 2009, at 4:20 PM, hermann pitton wrote: Am Freitag, den 02.10.2009, 13:47 +0200 schrieb Jean Delvare: ... While investigating another issue, I have noticed the following message in the kernel logs of a saa7134 user: i2c-adapter i2c-0: Invalid 7-bit address 0x7a The address in question is attempted by an IR device probe, and is only probed on SAA7134 adapters. The problem with this address is that it is reserved by the I2C specification for 10-bit addressing, and is thus not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the new-style i2c device driver binding model, device probing was done by ir-kbd-i2c itself so no check was done by i2c-core for address validity. But since kernel 2.6.31, probing at address 0x7a will be denied by i2c-core. So, SAA7134 adapters with an IR device at 0x7a are currently broken. Do we know how many devices use this address for IR and which they are? Tracking the changes in the source code, this address was added in kernel 2.6.8 by Gerd Knorr: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a So this would be used by the Upmost Purple TV adapter. Question is, are there other? Yes, currently 0x7a is only used by the Upmost Purple TV (Yuan Tun800). Here are some more details. http://archives.devshed.com/forums/linux-97/troubles-with-yuan-tun900-board-detected-as-upmost-purple-tv-1283673.html Support for the card and the i2c remote was added by Wang-Chan Chen. For testers it is useful to know that the card is still not fully supported. It has a NEC D64083GF video enhancer converting TV baseband video from tuner to S-Video and shares the vmux = 7 with the S-Video input. By default it comes up in external S-Video input mode. There is a Pericom videomux on it and we don't know how to switch it. Chen used to boot at first windows, switched there to tuner input and rebooted to GNU/Linux ... Some web research has pointed me to the Yuan TUN-900: http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html but it isn't clear to me whether the device at 0x7a on this adapter is the same as the one on the Purple TV. And saa7134-cards says of the TUN-900: Remote control not yet implemented so maybe we can just ignore it for now. Yes, that card has a device at 0xf4/0x7a too. I asked to test the remote with the Upmost Purple TV entry, but never got a reply. As we know these days, radio amux is wrong too on Yuan TUN900 card=66. Last contact to Chen was four years back, but he confirmed that both cards have the same PCI subsystem. Some bytes in the eeprom, meaning unknown, are different, though. If we have to, I could make i2c-core more permissive, but I am rather reluctant to letting invalid addressed being probed, because you never know how complying chips on the I2C bus will react. I am OK supporting invalid addresses if they really exist out there, but the impact should be limited to the hardware in question. If we only have to care about the Upmost Purple TV, then the following patch should solve the problem: For what is known so far. Acked-by: hermann pitton hermann-pit...@arcor.de Seems like a sane thing to do to me too, and I've not seen nor heard of any other devices that use 0x7a. (Hell, I wasn't even aware of these ones 'til now). Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@wilsonet.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: Upgrading from FC4 to current Linux
On Oct 2, 2009, at 4:14 PM, Andy Walls wrote: Video used to be easy, plug in the capture device, install xawtv via rpm, and use. However, recent versions of Fedora simply don't work, even on the same hardware, due to /dev/dsp no longer being created and the applications like xawtv or tvtime still looking for it. (Non-emulated) OSS was ditched by the linux kernel folks long ago. And I thought xawtv and tvtime were abandon-ware. Yeah, seems that way. Though Devin's been talking about maybe starting up a new tvtime maintenance tree, which Fedora would be happy to contribute to and track... (nudge, nudge, Devin ;) The people who will be using this are looking for hardware which is still made and sold new, and software which can be installed by a support person who can plug in cards (PCI preferred) or USB devices, and install rpms. rpmfusion, ATrpms, and I even think Fedora have MythTV available now. mplayer is probably also available from 2 of those 3 resources. MythTV and mplayer are both only in RPM Fusion and ATrpms. Both rely on ffmpeg, which is no-go for Fedora itself. For any open source software that implements video and audio decoders, you will need to investigate if you must pay someone licensing fees to use the decoders you need to meet your usage requirements. Fedora has a mechanism in place by which you can pay for the non-free codecs, IIRC. Sort of. If you're using something gstreamer-based (like totem). Fedora used to have codeina (formerly codec-buddy) that would point you at Fluendo's site for some gstreamer codec plugins you could buy. The current world order is PackageKit with a codec plugin that tries to find a plugin that provides the codec in your configured yum repos. Can't recall if it points at Fluendo if nothing is found... -- Jarod Wilson ja...@wilsonet.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] i2c_board_info can be local
On Oct 2, 2009, at 4:47 AM, Jean Delvare kh...@linux-fr.org wrote: Recent fixes to the em28xx and saa7134 drivers have been overzealous. While the ir-kbd-i2c platform data indeed needs to be persistent, the struct i2c_board_info doesn't, as it is only used by i2c_new_device(). So revert a part of the original fixes, to save some memory. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Mauro Carvalho Chehab mche...@redhat.com Yeah, good call. Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@wilsonet.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
