Re: Requested feedback on V4L2 driver design
On Monday 08 February 2010 21:23:00 Mauro Carvalho Chehab wrote: > Maupin, Chase wrote: > > All, > > > > Texas Instruments (TI) is working on the design for the V4L2 capture and > > display drivers for our next generation system-on-chip (SoC) processor and > > would like to solicit your feedback. Our new SoCs have been improved to > > allow for higher video resolutions and greater frame rates. To this end > > the display hardware has been moved to a separate processing block called > > the video processing subsystem (VPSS). The VPSS will be running a firmware > > image that controls the capture/display hardware and services requests from > > one or more host processors. > > > > Moving to a remote processor for the processing of video input and output > > data requires that commands to control the hardware be passed to this > > processing block using some form of inter-processor communication (IPC). > > TI would like to solicit your feedback on proposal for the V4L2 driver > > design to get a feel for whether or not this design would be accepted into > > the Linux kernel. To this end we have put together an overview of the > > design and usage on our wiki at > > http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Design. > > We would greatly appreciate feedback from community members on the > > acceptability of our driver design. > > > > If you have additional questions or need more information please feel free > > to contact us (we have setup a mailing list at > > vpss_driver_des...@list.ti.com) so we can answer them. > > > > Hi Chase, > > I'm not sure if I got all the details on your proposal, so let me try to give > my > understanding. > > First of all, for normal usage (e.g. capturing a stream or sending an stream > to an output device), the driver should work with only the standard V4L2 API. > I'm assuming that the driver will provide this capability. > > I understand that, being a SoC hardware, there are much more that can be done > than just doing the normal stream capture/output, already supported by V4L2 > API. > > For such advanced usages, we're open to a proposal to enhance the existing API > to support the needs. There are some important aspects that need to be > considered > when designing any Linux userspace API's: The full functionality of this device can be handled by the proposals made during last year's LPC and that are currently being implemented/prototyped for omap3. That's no coincidence, by the way :-) > > 1) kernel-userspace API's are forever. So, they need to be designed in > a way that new technology changes won't break the old API; > > 2) API's are meant to be generic. So, they needed to be designed in a > way > that, if another hardware with similar features require an API, the planned > one > should fit; > > 3) The API's should be, as much as possible, independent of the hardware > architecture. You'll see that even low-level architecture dependent stuff, > like > bus drivers are designed in a way that they are not bound to a particular > hardware, > but instead provide the same common methods to interact with the hardware to > other > device drivers. > > That's said, it would be interesting if you could give us a more deep detail > on > what kind of functionalities and how do you think you'll be implementing them. For me the core issue will be the communication between the main ARM and the ARM controlling the VPSS. Looking at the syslink part of the git tree it all looks way overengineered to me. In particular the multicore_ipc directory. Is all that code involved in setting up the communication path between the main and VPSS ARM? Is there some more detailed document describing how the syslink code works? What I would expect to see is standard mailbox functionality that is used in other places as well. I gather that at the bottom there actually seems to be a mailbox involved with syslink, but there also seems to be a lot of layers on top of that. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix compilation tm6000 module
Hi All
Fix compilation tm6000 module.
diff -r 690055993011 linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Sun Feb 07 22:26:10
2010 -0200
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Tue Feb 09 10:44:14
2010 +0900
@@ -45,6 +45,8 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
With my best regards, Dmitry.diff -r 690055993011 linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Sun Feb 07 22:26:10 2010 -0200
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Tue Feb 09 10:44:14 2010 +0900
@@ -45,6 +45,8 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
#define TM6010_BOARD_HAUPPAUGE_900H 9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER 11
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
Re: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Mon, Feb 8, 2010 at 11:43 PM, Richard Lemieux wrote: > Hi, > > I got some driver crashes after upgrading to kernel 2.6.32.7. It seems that > activating either TBS8920 (DVB-S) and HVR950Q (ATSC) after the other one has > run (and is no longer in use by an application) triggers a driver crash. Hello Richard, Have you tried any other kernel version? For example, do you know that it works properly in 2.6.32.6? Can you bisect and see when the problem was introduced? 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
Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
Hi, I got some driver crashes after upgrading to kernel 2.6.32.7. It seems that activating either TBS8920 (DVB-S) and HVR950Q (ATSC) after the other one has run (and is no longer in use by an application) triggers a driver crash. Each device individually works fine (as long as the other one does not run). I don't know how to investigate this by myself, but I am available to help. This is not critical. The system is otherwise stable. Here is the last event recorded in syslog. I activated the DVBS after turning off applications running ATSC. Feb 8 16:18:16 pc3 kernel: DVB: registering adapter 1 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... Feb 8 21:37:17 pc3 kernel: cx88[0]/0: unknown tv audio mode [0] Feb 8 23:00:45 pc3 kernel: cx88[0]/0: unknown tv audio mode [0] Feb 8 23:01:24 pc3 last message repeated 2 times Feb 8 23:04:00 pc3 kernel: BUG: unable to handle kernel NULL pointer dereference at 0004 Feb 8 23:04:00 pc3 kernel: IP: [] firmware_loading_store+0x68/0x1a0 Feb 8 23:04:00 pc3 kernel: *pdpt = 3650e001 *pde = Feb 8 23:04:00 pc3 kernel: Oops: [#1] SMP Feb 8 23:04:00 pc3 kernel: last sysfs file: /sys/class/firmware/:08:00.0/loading Feb 8 23:04:00 pc3 kernel: Modules linked in: xc5000 tuner au8522 au0828 videobuf_vmalloc snd_seq rtc hid_logitech ext4 jbd2 crc16 nls_iso8859_1 nls_cp437 bsd_comp ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc parport_pc lp parport joydev usb_storage usblp snd_usb_audio snd_usb_lib snd_rawmidi snd_seq_device usbhid snd_hwdep cx24116 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss cx8802 snd_mixer_oss cx8800 cx88xx snd_pcm ir_common i2c_i801 i2c_algo_bit v4l2_common snd_timer tveeprom ohci1394 sky2 ehci_hcd snd videodev v4l1_compat videobuf_dma_sg btcx_risc ieee1394 8250_pnp 8250 serial_core uhci_hcd bitrev nvidia(P) crc32 agpgart videobuf_core soundcore snd_page_alloc i2c_core usbcore sg evdev Feb 8 23:04:00 pc3 kernel: Feb 8 23:04:00 pc3 kernel: Pid: 6390, comm: firmware.agent Tainted: P (2.6.32.7 #1) P5E WS Pro Feb 8 23:04:00 pc3 kernel: EIP: 0060:[] EFLAGS: 00010296 CPU: 1 Feb 8 23:04:00 pc3 kernel: EIP is at firmware_loading_store+0x68/0x1a0 Feb 8 23:04:00 pc3 kernel: EAX: EBX: f66a1140 ECX: 0002 EDX: 2f1dc161 Feb 8 23:04:00 pc3 kernel: ESI: f7513440 EDI: f05b8380 EBP: 0002 ESP: f0c15f1c Feb 8 23:04:00 pc3 kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Feb 8 23:04:00 pc3 kernel: Process firmware.agent (pid: 6390, ti=f0c14000 task=f6e65850 task.ti=f0c14000) Feb 8 23:04:00 pc3 kernel: Stack: Feb 8 23:04:00 pc3 kernel: 0161 8000 0810b408 c430ed60 c10713d2 c11ae5c0 0002 c13ab7c0 Feb 8 23:04:00 pc3 kernel: <0> 0002 c11a6965 0002 f66dc940 f75242f8 c10cc0d9 0002 0810b408 Feb 8 23:04:00 pc3 kernel: <0> f66dc954 f7513448 f0c6cac0 0002 0810b408 c10cc040 c1086ff0 f0c15f9c Feb 8 23:04:00 pc3 kernel: Call Trace: Feb 8 23:04:00 pc3 kernel: [] ? handle_mm_fault+0x612/0x9f0 Feb 8 23:04:00 pc3 kernel: [] ? firmware_loading_store+0x0/0x1a0 Feb 8 23:04:00 pc3 kernel: [] ? dev_attr_store+0x25/0x40 Feb 8 23:04:00 pc3 kernel: [] ? sysfs_write_file+0x99/0x100 Feb 8 23:04:00 pc3 kernel: [] ? sysfs_write_file+0x0/0x100 Feb 8 23:04:00 pc3 kernel: [] ? vfs_write+0xa0/0x160 Feb 8 23:04:00 pc3 kernel: [] ? sys_write+0x41/0x70 Feb 8 23:04:00 pc3 kernel: [] ? sysenter_do_call+0x12/0x26 Feb 8 23:04:00 pc3 kernel: Code: 04 e8 dd c8 ec ff 8b 53 40 31 c9 8b 43 3c 8b 7b 34 c7 04 24 61 01 00 00 c7 44 24 04 00 00 00 80 e8 8e cf ec ff 89 47 04 8b 43 34 <8b> 78 04 85 ff 0f 84 f4 00 00 00 c7 43 44 00 00 00 00 8d 43 04 Feb 8 23:04:00 pc3 kernel: EIP: [] firmware_loading_store+0x68/0x1a0 SS:ESP 0068:f0c15f1c Feb 8 23:04:00 pc3 kernel: CR2: 0004 Feb 8 23:04:00 pc3 kernel: ---[ end trace c07258db2013e403 ]--- Here is another event. I booted in between. The system is stable otherwise. Feb 7 14:15:06 pc3 kernel: DVB: registering adapter 1 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)... Feb 7 14:15:30 pc3 udevd-event[15971]: run_program: '/lib/udev/firmware.sh' abnormal exit Feb 7 14:15:30 pc3 kernel: BUG: unable to handle kernel NULL pointer dereference at 0004 Feb 7 14:15:30 pc3 kernel: IP: [] firmware_loading_store+0x62/0x1a0 Feb 7 14:15:30 pc3 kernel: *pdpt = 36bc4001 *pde = Feb 7 14:15:30 pc3 kernel: Oops: 0002 [#1] SMP Feb 7 14:15:30 pc3 kernel: last sysfs file: /sys/class/firmware/7-4/loading Feb 7 14:15:30 pc3 kernel: Modules linked in: snd_usb_audio snd_usb_lib snd_rawmidi snd_hwdep xc5000 tuner au8522 au0828 videobuf_vmalloc nvidia(P) snd_seq snd_seq_device rtc hid_logitech ext4 jbd2 crc16 nls_iso8859_1 nls_cp437 bsd_comp ppp_deflate zlib_deflate ppp_async crc_ccitt ppp_generic slhc agpgart parport_pc lp parport joydev usb_storage usbhid usblp cx24116 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core snd_hd
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Am Montag, den 08.02.2010, 08:14 -0800 schrieb Linus Torvalds: > > On Mon, 8 Feb 2010, Chicken Shack wrote: > > > > This is a SCANDAL, not fun! This is SCANDALOUS! > > I agree that this whole thread has been totally inappropriate from > beginning to end. The initial problem was, how to find such software producing that oops at all. Uwe/Chicken only later friendly distributed it to us. Is there some alevt 1.7.0 (dvb-t/dvb-s :) anywhere else already? Since only then, we have been able to discover, that it is valid bug that needs investigation. Else I do agree with all your findings, you had him blacklisted on LKML already too, but v4l and dvb people are also somehow forced to work together, because of the hybrid devices everywhere now. Some don't like it and he is always on top of it again. We make progress in so far. 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
Creatix saa7134 card produces lots of glitches.
Hello. I use a Creatix ctx929 card as dvb-s adapter. Whenever I watch tv with it there are lots of glitches. The card has a TDA10086 tuner and a saa7134 chip. I am using kernel 2.6.32.5 at the moment. The card is autodetected as card number 93. (Medion 7134 Bridge #2) which is possibly right because Creatix made this card for Medion. The glitches are no matter of software, I tried vdr, mythtv, dvbstreamer and I also used szap and cat from /dev/dvb/adapter0/dvr0 to a file. When I load the module dvb-core with the options dvb_demux_tscheck=1 dvbdev_debug=1 I see the following in dmesg. PID=0x6e, which is shown in the last line, was the PID I tuned to. [14754.455710] TEI detected. PID=0x1a7f data1=0xfa [14754.455713] TS packet counter mismatch. PID=0x1a7f expected 0x13 got 0xb [14759.530543] __ratelimit: 7784 callbacks suppressed [14759.530551] TS packet counter mismatch. PID=0x54 expected 0xc got 0xb [14759.540640] TS packet counter mismatch. PID=0x456 expected 0x2 got 0x3 [14759.540646] TS packet counter mismatch. PID=0xd2 expected 0xc got 0x8 [14759.540652] TS packet counter mismatch. PID=0x136 expected 0xb got 0x5 [14759.540657] TS packet counter mismatch. PID=0x276 expected 0x4 got 0x7 [14759.540662] TS packet counter mismatch. PID=0x6e expected 0x1 got 0x4 and so on.. Does that mean there is data lost from within the TS stream? Can anybody tell me what I can do to correct this error (if it was an error)? Thanks Willem Bleymueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dib3000mc: reduce large stack usage
From: Randy Dunlap
This patch reduces static stack usage of one of the 2 top offenders
as listed by 'make checkstack':
Building with CONFIG_FRAME_WARN=2048 produces:
drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2224
bytes is larger than 2048 bytes
and in 'make checkstack', the stack usage goes from:
0x0bbd dib3000mc_i2c_enumeration [dib3000mc]: 2232
to unlisted with this patch.
I don't have the hardware that is needed to test this patch.
Signed-off-by: Randy Dunlap
Cc: Patrick Boettcher
---
drivers/media/dvb/frontends/dib3000mc.c | 35 +-
1 file changed, 22 insertions(+), 13 deletions(-)
--- lnx-2633-rc7.orig/drivers/media/dvb/frontends/dib3000mc.c
+++ lnx-2633-rc7/drivers/media/dvb/frontends/dib3000mc.c
@@ -813,42 +813,51 @@ EXPORT_SYMBOL(dib3000mc_set_config);
int dib3000mc_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8
default_addr, struct dib3000mc_config cfg[])
{
- struct dib3000mc_state st = { .i2c_adap = i2c };
+ struct dib3000mc_state *dmcst;
int k;
u8 new_addr;
static u8 DIB3000MC_I2C_ADDRESS[] = {20,22,24,26};
+ dmcst = kzalloc(sizeof(struct dib3000mc_state), GFP_KERNEL);
+ if (dmcst == NULL)
+ return -ENODEV;
+
+ dmcst->i2c_adap = i2c;
+
for (k = no_of_demods-1; k >= 0; k--) {
- st.cfg = &cfg[k];
+ dmcst->cfg = &cfg[k];
/* designated i2c address */
new_addr = DIB3000MC_I2C_ADDRESS[k];
- st.i2c_addr = new_addr;
- if (dib3000mc_identify(&st) != 0) {
- st.i2c_addr = default_addr;
- if (dib3000mc_identify(&st) != 0) {
+ dmcst->i2c_addr = new_addr;
+ if (dib3000mc_identify(dmcst) != 0) {
+ dmcst->i2c_addr = default_addr;
+ if (dib3000mc_identify(dmcst) != 0) {
dprintk("-E- DiB3000P/MC #%d: not
identified\n", k);
+ kfree(dmcst);
return -ENODEV;
}
}
- dib3000mc_set_output_mode(&st, OUTMODE_MPEG2_PAR_CONT_CLK);
+ dib3000mc_set_output_mode(dmcst, OUTMODE_MPEG2_PAR_CONT_CLK);
// set new i2c address and force divstr (Bit 1) to value 0 (Bit
0)
- dib3000mc_write_word(&st, 1024, (new_addr << 3) | 0x1);
- st.i2c_addr = new_addr;
+ dib3000mc_write_word(dmcst, 1024, (new_addr << 3) | 0x1);
+ dmcst->i2c_addr = new_addr;
}
for (k = 0; k < no_of_demods; k++) {
- st.cfg = &cfg[k];
- st.i2c_addr = DIB3000MC_I2C_ADDRESS[k];
+ dmcst->cfg = &cfg[k];
+ dmcst->i2c_addr = DIB3000MC_I2C_ADDRESS[k];
- dib3000mc_write_word(&st, 1024, st.i2c_addr << 3);
+ dib3000mc_write_word(dmcst, 1024, dmcst->i2c_addr << 3);
/* turn off data output */
- dib3000mc_set_output_mode(&st, OUTMODE_HIGH_Z);
+ dib3000mc_set_output_mode(dmcst, OUTMODE_HIGH_Z);
}
+
+ kfree(dmcst);
return 0;
}
EXPORT_SYMBOL(dib3000mc_i2c_enumeration);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dib7000p: reduce large stack usage
From: Randy Dunlap
This patch reduces static stack usage of one of the 2 top offenders
as listed by 'make checkstack':
Building with CONFIG_FRAME_WARN=2048 produces:
drivers/media/dvb/frontends/dib7000p.c:1367: warning: the frame size of 2320
bytes is larger than 2048 bytes
and in 'make checkstack', the stack usage goes from:
0x2409 dib7000p_i2c_enumeration [dib7000p]: 2328
to unlisted with this patch.
Also change one caller of dib7000p_i2c_enumeration() to check its
return value.
I don't have the hardware that is needed to test this patch.
Signed-off-by: Randy Dunlap
Cc: Patrick Boettcher
---
drivers/media/dvb/dvb-usb/cxusb.c |5 +--
drivers/media/dvb/frontends/dib7000p.c | 36 ++-
2 files changed, 25 insertions(+), 16 deletions(-)
--- lnx-2633-rc7.orig/drivers/media/dvb/dvb-usb/cxusb.c
+++ lnx-2633-rc7/drivers/media/dvb/dvb-usb/cxusb.c
@@ -1024,8 +1024,9 @@ static int cxusb_dualdig4_rev2_frontend_
cxusb_bluebird_gpio_pulse(adap->dev, 0x02, 1);
- dib7000p_i2c_enumeration(&adap->dev->i2c_adap, 1, 18,
-&cxusb_dualdig4_rev2_config);
+ if (dib7000p_i2c_enumeration(&adap->dev->i2c_adap, 1, 18,
+&cxusb_dualdig4_rev2_config) < 0)
+ return -ENODEV;
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap, 0x80,
&cxusb_dualdig4_rev2_config);
--- lnx-2633-rc7.orig/drivers/media/dvb/frontends/dib7000p.c
+++ lnx-2633-rc7/drivers/media/dvb/frontends/dib7000p.c
@@ -1323,46 +1323,54 @@ EXPORT_SYMBOL(dib7000p_pid_filter);
int dib7000p_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods, u8
default_addr, struct dib7000p_config cfg[])
{
- struct dib7000p_state st = { .i2c_adap = i2c };
+ struct dib7000p_state *dpst;
int k = 0;
u8 new_addr = 0;
+ dpst = kzalloc(sizeof(struct dib7000p_state), GFP_KERNEL);
+ if (!dpst)
+ return -ENODEV;
+
+ dpst->i2c_adap = i2c;
+
for (k = no_of_demods-1; k >= 0; k--) {
- st.cfg = cfg[k];
+ dpst->cfg = cfg[k];
/* designated i2c address */
new_addr = (0x40 + k) << 1;
- st.i2c_addr = new_addr;
- dib7000p_write_word(&st, 1287, 0x0003); /* sram lead in, rdy */
- if (dib7000p_identify(&st) != 0) {
- st.i2c_addr = default_addr;
- dib7000p_write_word(&st, 1287, 0x0003); /* sram lead
in, rdy */
- if (dib7000p_identify(&st) != 0) {
+ dpst->i2c_addr = new_addr;
+ dib7000p_write_word(dpst, 1287, 0x0003); /* sram lead in, rdy */
+ if (dib7000p_identify(dpst) != 0) {
+ dpst->i2c_addr = default_addr;
+ dib7000p_write_word(dpst, 1287, 0x0003); /* sram lead
in, rdy */
+ if (dib7000p_identify(dpst) != 0) {
dprintk("DiB7000P #%d: not identified\n", k);
+ kfree(dpst);
return -EIO;
}
}
/* start diversity to pull_down div_str - just for
i2c-enumeration */
- dib7000p_set_output_mode(&st, OUTMODE_DIVERSITY);
+ dib7000p_set_output_mode(dpst, OUTMODE_DIVERSITY);
/* set new i2c address and force divstart */
- dib7000p_write_word(&st, 1285, (new_addr << 2) | 0x2);
+ dib7000p_write_word(dpst, 1285, (new_addr << 2) | 0x2);
dprintk("IC %d initialized (to i2c_address 0x%x)", k, new_addr);
}
for (k = 0; k < no_of_demods; k++) {
- st.cfg = cfg[k];
- st.i2c_addr = (0x40 + k) << 1;
+ dpst->cfg = cfg[k];
+ dpst->i2c_addr = (0x40 + k) << 1;
// unforce divstr
- dib7000p_write_word(&st, 1285, st.i2c_addr << 2);
+ dib7000p_write_word(dpst, 1285, dpst->i2c_addr << 2);
/* deactivate div - it was just for i2c-enumeration */
- dib7000p_set_output_mode(&st, OUTMODE_HIGH_Z);
+ dib7000p_set_output_mode(dpst, OUTMODE_HIGH_Z);
}
+ kfree(dpst);
return 0;
}
EXPORT_SYMBOL(dib7000p_i2c_enumeration);
--
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] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Chicken Shack wrote: ok anonymous chicken you've managed a distinct first: i've installed a block filter on your email address. Rudy -- 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
linuxtv.org server move Wed, 10 Feb 2pm CET
Hi, the linuxtv.org server is going to be moved to a new location on Wednesday, around 2pm CET (UTC+1:00). There'll be a bit of downtime. Johannes -- 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/1] media: dvb-usb/af9015, fix disconnection crashes
On Thu, Feb 04, 2010 at 04:07:36PM +0200, Pekka Sarnila wrote: > Yes, my comment maybe criticizes more the basic architectural structure of > usb putting it's own work up to higher layer. The only practical thing is > that, if there is a non-HID device suffering from that FULLSPEED problem, > the quirk won't help it. Anyway in current kernel structure usb layer > doesn't handle endpoint setup at all, thus it simply can not do the job. Patches to the USB core to resolve this issue are always gladly appreciated :) thanks, greg k-h -- 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-pm] [PATCH/RESEND] soc-camera: add runtime pm support for subdevices
On Monday 08 February 2010, Guennadi Liakhovetski wrote:
> To save power soc-camera powers subdevices down, when they are not in use,
> if this is supported by the platform. However, the V4L standard dictates,
> that video nodes shall preserve configuration between uses. This requires
> runtime power management, which is implemented by this patch. It allows
> subdevice drivers to specify their runtime power-management methods, by
> assigning a type to the video device.
You need a support for that at the bus type/device type/device class level,
because the core doesn't execute the driver callbacks directly.
Rafael
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> I've posted this patch to linux-media earlier, but I'd also like to get
> comments on linux-pm, sorry to linux-media falks for a duplicate. To
> explain a bit - soc_camera.c is a management module, that binds video
> interfaces on SoCs and sensor drivers. The calls, that I am adding to
> soc_camera.c shall save and restore sensor registers before they are
> powered down and after they are powered up.
>
> diff --git a/drivers/media/video/soc_camera.c
> b/drivers/media/video/soc_camera.c
> index 6b3fbcc..53201f3 100644
> --- a/drivers/media/video/soc_camera.c
> +++ b/drivers/media/video/soc_camera.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -387,6 +388,11 @@ static int soc_camera_open(struct file *file)
> goto eiciadd;
> }
>
> + pm_runtime_enable(&icd->vdev->dev);
> + ret = pm_runtime_resume(&icd->vdev->dev);
> + if (ret < 0 && ret != -ENOSYS)
> + goto eresume;
> +
> /*
>* Try to configure with default parameters. Notice: this is the
>* very first open, so, we cannot race against other calls,
> @@ -408,10 +414,12 @@ static int soc_camera_open(struct file *file)
> return 0;
>
> /*
> - * First five errors are entered with the .video_lock held
> + * First four errors are entered with the .video_lock held
>* and use_count == 1
>*/
> esfmt:
> + pm_runtime_disable(&icd->vdev->dev);
> +eresume:
> ici->ops->remove(icd);
> eiciadd:
> if (icl->power)
> @@ -436,7 +444,11 @@ static int soc_camera_close(struct file *file)
> if (!icd->use_count) {
> struct soc_camera_link *icl = to_soc_camera_link(icd);
>
> + pm_runtime_suspend(&icd->vdev->dev);
> + pm_runtime_disable(&icd->vdev->dev);
> +
> ici->ops->remove(icd);
> +
> if (icl->power)
> icl->power(icd->pdev, 0);
> }
> @@ -1294,6 +1306,7 @@ static int video_dev_create(struct soc_camera_device
> *icd)
> */
> static int soc_camera_video_start(struct soc_camera_device *icd)
> {
> + struct device_type *type = icd->vdev->dev.type;
> int ret;
>
> if (!icd->dev.parent)
> @@ -1310,6 +1323,9 @@ static int soc_camera_video_start(struct
> soc_camera_device *icd)
> return ret;
> }
>
> + /* Restore device type, possibly set by the subdevice driver */
> + icd->vdev->dev.type = type;
> +
> return 0;
> }
>
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index dcc5b86..58b39a9 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -282,4 +282,12 @@ static inline void soc_camera_limit_side(unsigned int
> *start,
> extern unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link
> *icl,
> unsigned long flags);
>
> +/* This is only temporary here - until v4l2-subdev begins to link to
> video_device */
> +#include
> +static inline struct video_device *soc_camera_i2c_to_vdev(struct i2c_client
> *client)
> +{
> + struct soc_camera_device *icd = client->dev.platform_data;
> + return icd->vdev;
> +}
> +
> #endif
> ___
--
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: Requested feedback on V4L2 driver design
Maupin, Chase wrote: > All, > > Texas Instruments (TI) is working on the design for the V4L2 capture and > display drivers for our next generation system-on-chip (SoC) processor and > would like to solicit your feedback. Our new SoCs have been improved to > allow for higher video resolutions and greater frame rates. To this end the > display hardware has been moved to a separate processing block called the > video processing subsystem (VPSS). The VPSS will be running a firmware image > that controls the capture/display hardware and services requests from one or > more host processors. > > Moving to a remote processor for the processing of video input and output > data requires that commands to control the hardware be passed to this > processing block using some form of inter-processor communication (IPC). TI > would like to solicit your feedback on proposal for the V4L2 driver design to > get a feel for whether or not this design would be accepted into the Linux > kernel. To this end we have put together an overview of the design and usage > on our wiki at > http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Design. > We would greatly appreciate feedback from community members on the > acceptability of our driver design. > > If you have additional questions or need more information please feel free to > contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) > so we can answer them. > Hi Chase, I'm not sure if I got all the details on your proposal, so let me try to give my understanding. First of all, for normal usage (e.g. capturing a stream or sending an stream to an output device), the driver should work with only the standard V4L2 API. I'm assuming that the driver will provide this capability. I understand that, being a SoC hardware, there are much more that can be done than just doing the normal stream capture/output, already supported by V4L2 API. For such advanced usages, we're open to a proposal to enhance the existing API to support the needs. There are some important aspects that need to be considered when designing any Linux userspace API's: 1) kernel-userspace API's are forever. So, they need to be designed in a way that new technology changes won't break the old API; 2) API's are meant to be generic. So, they needed to be designed in a way that, if another hardware with similar features require an API, the planned one should fit; 3) The API's should be, as much as possible, independent of the hardware architecture. You'll see that even low-level architecture dependent stuff, like bus drivers are designed in a way that they are not bound to a particular hardware, but instead provide the same common methods to interact with the hardware to other device drivers. That's said, it would be interesting if you could give us a more deep detail on what kind of functionalities and how do you think you'll be implementing them. -- 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
zl10335 with tm6010 or tm6000
I have switched from hack to zl10353 module, and I have tested more different setups. I have found what wrong is, in function tl10353_read_status() and zl10353_read_snr(), not positive value. zl10353_read_status() reghas digitalhasn't digital 0x050x400x00 0x060x000x21 0x070x330x03 0x080x000x00 more than 0x00 0x090x580x00 zl10353_read_snr() reghas digitalhasn't digital 0x0f 0x28 inv ( 0xd8) =^87%0x2b inv (0xd5) =^ 84% 0x100x000x00 the function set_parameters is working. I have added (only for test) a full HAS_FE_* status, so that I tested the set_parameter function. -- Stefan Ringel -- 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:Mon Feb 8 19:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14164:690055993011 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: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-rc5-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK 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: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MT9T031: write xskip and yskip at each set_params call
Hi Val
On Mon, 8 Feb 2010, Valentin Longchamp wrote:
> > /*
> > * Power Management:
> > * This function does nothing for now but must be present for pm to work
> > */
> > static int mt9t031_runtime_suspend(struct device *dev)
> > {
> > return 0;
> > }
>
> First, can you confirm me that this function is needed even if it does nothing
> ? I have read in the code that if the function is not present,
> __pm_runtime_suspend is going to return -ENOSYS and will set runtime_status to
> RPM_ACTIVE, which is not what we want. That's why I left it.
Yes, I think, you're right - if neither bus, nor type, nor class suspend
is debined, -ENOSYS is returned (see __pm_runtime_suspend()).
> > /*
> > * Power Management:
> > * COLUMN_ADDRESS_MODE and ROW_ADDRESS_MODE are not rewritten if unchanged
> > * they are however changed at reset if the platform hook is present
> > * thus we rewrite them with the values stored by the driver
> > */
> > static int mt9t031_runtime_resume(struct device *dev)
> > {
> > struct video_device *vdev = to_video_device(dev);
> > struct soc_camera_device *icd = container_of(vdev->parent,
> > struct soc_camera_device, dev);
> > struct device *i2c_dev = container_of(icd, struct device,
> > platform_data);
> > struct i2c_client *client = to_i2c_client(i2c_dev);
> > struct mt9t031 *mt9t031 = to_mt9t031(client);
>
> Here I have a problem ... I am pretty sure that the third assignation has a
> problem, because platform_data is a pointer and not a normal member of struct
> device, and I thus cannot use container_of with it. What would then be the way
> to go from the soc_camera_device to the i2c_client (I'm a little bit confused
> with all the different structs and layers involved with i2c, soc-camera,
> v4l2_device and v4l2_subdevice) ?
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct i2c_client *client = sd->priv;
> Just as a remark, this is the exact reverse
> path of this that is present in your patch to add runtime pm support to
> soc-camera:
>
> /* This is only temporary here - until v4l2-subdev begins to link to
> video_device */
> #include
> static inline struct video_device *soc_camera_i2c_to_vdev(struct i2c_client
> *client)
> {
> struct soc_camera_device *icd = client->dev.platform_data;
> return icd->vdev;
> }
>
> >
> > int ret;
> > u16 xbin, ybin;
> >
> > xbin = min(mt9t031->xskip, (u16)3);
> > ybin = min(mt9t031->yskip, (u16)3);
> >
> > ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
> > ((xbin-1)<<4) | (mt9t031->xskip-1));
> > if (ret < 0)
> > return ret;
> >
> > ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
> > ((ybin-1)<<4) | (mt9t031->yskip-1));
> > if (ret < 0)
> > return ret;
> >
> > return 0;
> > }
> >
> > static struct dev_pm_ops mt9t031_dev_pm_ops = {
> > .runtime_suspend= mt9t031_runtime_suspend,
> > .runtime_resume = mt9t031_runtime_resume,
> > };
> >
> > static struct device_type mt9t031_dev_type = {
> > .name = "MT9T031",
> > .pm = &mt9t031_dev_pm_ops,
> > };
>
> Thank you in advance for your help.
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] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Am Montag, den 08.02.2010, 11:09 -0800 schrieb Linus Torvalds: > > On Mon, 8 Feb 2010, Chicken Shack wrote: > > ... > > Please stop emailing me. I'm simply not interested in your political > troubles with the DVB people. > > I see with my own eyes why people have issues with your way of > communication, and quite frankly, I'm not interested in discussing > name-calling with somebody who is anonymous. C R A P ! ! ! ! > > Linus > -- > 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 I admit I completely overestimated you. HOW POOR! SHAME ON YOU! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Stefan Ringel wrote: > Am 08.02.2010 19:14, schrieb Mauro Carvalho Chehab: >> Stefan Ringel wrote: >> >> We'll need some function to change between analog and digital modes, doing >> the right >> GPIO changes. See em28xx_set_mode() for a way of implementing it. >> >> > I don't mean that. I mean it loads the init table then goes to > tm600_cards_setup, then goes to return and loads the init table new and > then ... reset the demodulator or can it without the reset demodulator? > I can test it next weekend. Tests are required. Maybe you'll need to call it again. The tm6000 chip has lot of weird behaviours. In the case of xc3028 on analog, you need to re-load the firmware every time the stream starts. Also, it seems that tm6000 has a timeout: if the image is not ok for a few seconds, it cuts the tuner down. So, I ended to make it to re-load part of the firmware (the smaller part of the firmware) every time the channel changes, when I wrote the first version of the driver. I suspect that this behavior of tuner-xc2028 were removed on the last driver reviews, to speedup tuning with all other devices that use those chips. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
On Mon, 8 Feb 2010, Chicken Shack wrote: > ... Please stop emailing me. I'm simply not interested in your political troubles with the DVB people. I see with my own eyes why people have issues with your way of communication, and quite frankly, I'm not interested in discussing name-calling with somebody who is anonymous. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Am 08.02.2010 19:14, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>
>> Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>>
>>> Hi Stefan,
>>>
>>> First, a few comments about your patch series:
>>>
>>> I've committed almost of your patches, and added an extra patch to make the
>>> driver to compile it with -git. There were other broken things when
>>> compiling
>>> against -git.
>>>
>>> Several of your patches are adding leading whitespaces. Please review them
>>> before
>>> submitting. On -git, those whitespaces are shown with a red background
>>> color.
>>>
>>> I've re-made most of the patch descriptions. Please take a look on them and
>>> try
>>> to improve on a next time.
>>>
>>> We've got 2 submission for each patches. I just discarded the older one.
>>>
>>> I've removed the two BEHOLDER board descriptions from one of your patches.
>>> It is
>>> not related to your board, but it is another compilation fix.
>>>
>>> From your series, I didn't merge those 3 patches:
>>>
>>> [5/12] tm6000: update init table and sequence for tm6010
>>> http://patchwork.kernel.org/patch/77451
>>> [6/12] tm6000: tuner reset timeing optimation
>>> http://patchwork.kernel.org/patch/77459
>>> [11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and
>>> http://patchwork.kernel.org/patch/77462
>>>
>>> I'll send you separate comments why I didn't merge them, in reply to each
>>> email you've sent,
>>> starting with this one (patch 5/12).
>>>
>>>
>>> stefan.rin...@arcor.de wrote:
>>>
>>>
From: Stefan Ringel
---
drivers/staging/tm6000/tm6000-core.c | 179
--
1 files changed, 128 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 7ec13d5..a2e2af5 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
-
+
+ /* additional from Terratec Cinergy Hybrid XE */
+ { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+ { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+ { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+ { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+ { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+ { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+
/* set remote wakeup key:any key wakeup */
{ REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
{ REQ_07_SET_GET_AVREG, 0xda, 0xff },
@@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+ u8 buf[40];
if (dev->dev_type == TM6010) {
tab = tm6010_init_tab;
@@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
}
}
- msleep(5); /* Just to be conservative */
-
- /* Check board version - maybe 10Moons specific */
- board=tm6000_get_reg16 (dev, 0x40, 0, 0);
- if (board >=0) {
- printk (KERN_INFO "Board version = 0x%04x\n",board);
- } else {
- printk (KERN_ERR "Error %i while retrieving board
version\n",board);
- }
-
+ /* hack */
if (dev->dev_type == TM6010) {
- /* Turn xceive 3028 on */
- tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3,
0x01);
- msleep(11);
- }
>>> The above is board-specific. It is needed for the tm6010 device I have here
>>> (HVR900H), otherwise no xc3028 command will be handled.
>>>
>>> The better here is to add a setup routine to tm6000-cards and move all
>>> those GPIO codes to it. Then, add there your board-specific setup.
>>>
>>> I've added a patch that moves those GPIO board-specific setup to
>>> tm6000-cards:
>>> tm6000_cards_setup(). Please move your board specific GPIO init to there.
>>>
>>>
>>>
>>>
-
- /* Reset GPIO1 and GPIO4. */
- for (i=0; i< 2; i++) {
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev->tuner_reset_gpio, 0x00);
- if (rc<0) {
- printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
- return rc;
- }
-
- msleep(10); /* Just to be conservative */
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev->tuner_reset_gpio, 0x01);
- if (rc<0) {
- printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
- return rc;
- }
-
- msleep(10);
- rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
0);
Re: [PATCH 8/12] tm6000: add tuner parameter
Am 08.02.2010 16:55, schrieb Stefan Ringel:
> Am 08.02.2010 03:55, schrieb Mauro Carvalho Chehab:
>
>> stefan.rin...@arcor.de wrote:
>>
>>
>>
>>> + ctl.vhfbw7 = 1;
>>> + ctl.uhfbw8 = 1;
>>>
>>>
>> I don't think you need to set this, as the driver will automatically do the
>> firmware
>> tricks for the firmwares. This will probably just change the default to start
>> wit firmware 7/8.
>>
>>
>>
> if it's going to bw 7 it doesn't use DTV 7, it's use DTV 7 not DTV78, I
> have it tested. I think if it's switch between DTV7 and DTV 8 it's not
> always set DTV78. ( it's set DTV 7 DTV 8 or DTV78)
>
>
switch (bw) {
case BANDWIDTH_8_MHZ:
if (p->frequency < 47000)
priv->ctrl.vhfbw7 = 0;
else
priv->ctrl.uhfbw8 = 1;
type |= (priv->ctrl.vhfbw7 && priv->ctrl.uhfbw8) ? DTV78 : DTV8;
type |= F8MHZ;
break;
case BANDWIDTH_7_MHZ:
if (p->frequency < 47000)
priv->ctrl.vhfbw7 = 1;
else
priv->ctrl.uhfbw8 = 0;
type |= (priv->ctrl.vhfbw7 && priv->ctrl.uhfbw8) ? DTV78 : DTV7;
type |= F8MHZ;
break;
case BANDWIDTH_6_MHZ:
type |= DTV6;
priv->ctrl.vhfbw7 = 0;
priv->ctrl.uhfbw8 = 0;
break;
default:
tuner_err("error: bandwidth not supported.\n");
};
That is the actually part from tuner-xc2028.c, but I think here is the
checking wrong if Bandwidth 8 MHz & frequency < 470 MHz then DTV8, and
if Bandwidth 7 MHz & frequency => 470 MHz then DTV7. The first check in
code is OK, but the second check in code is not OK.
--
Stefan Ringel
--
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] MT9T031: write xskip and yskip at each set_params call
Hello Guennadi,
Guennadi Liakhovetski wrote:
First more details about what I do with the camera: I open the device, issue
the S_CROP / S_FMT calls and read images, the behaviour is fine, then close
the device.
Then if I reopen the device, reissue the S_CROP / S_FMT calls with the same
params, but the images is not the sames because of different xskip and yskip.
From what I have debugged in the driver at the second S_CROP /S_FMT, xskip and
yskip are computed by mt9t031_skip (and have the same value that the one
stored in the mt9t031 struct) and thus with the current code are not
rewritten.
However, if I read the register values containing bin and skip values on the
camera chip they have been reset (does a open/close do some reset to the cam
?) and thus different than the ones that should be written.
Yes, if hooks are provided by the platform, on last close we power down
cameras, on first open we power on and reset them.
I hope this clarifies the problem that I am experiencing. I don't think that
the API wants you to get two different images when you open the device and
issue the same parameters twice.
Yes, sorry, this is a different issue. The issue is - too crude power
management in soc-camera. What we should do is implement proper (runtime)
power-management in soc-camera (ideally, in v4l2-subdev API) and call
suspend() to save registers before powering down, and resume() after
powering on and resetting.
I gave it a shot and just posted a patch
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15686
(hm, would have been smart to cc you, sorry), doing just that. Below is an
example dummy implementation for mt9v022. Please, use it as example to
implement suspend / resume for mt9t031, for now, I think, it would suffice
if you just restore xskip and yskip in restore and skip suspend. If more
is needed in the future, we can always extend it.
OK, I agree with your analysis and I have tried to write the part for
runtime suspend and resume to solve this issue. I however find myself in
a deadend because of my limited knowledge of the kernel device model.
Here is my attempt with my questions in it (it compiles, but I have not
tested it yet because I am pretty sure something is wrong):
/*
* Power Management:
* This function does nothing for now but must be present for pm to work
*/
static int mt9t031_runtime_suspend(struct device *dev)
{
return 0;
}
First, can you confirm me that this function is needed even if it does
nothing ? I have read in the code that if the function is not present,
__pm_runtime_suspend is going to return -ENOSYS and will set
runtime_status to RPM_ACTIVE, which is not what we want. That's why I
left it.
/*
* Power Management:
* COLUMN_ADDRESS_MODE and ROW_ADDRESS_MODE are not rewritten if unchanged
* they are however changed at reset if the platform hook is present
* thus we rewrite them with the values stored by the driver
*/
static int mt9t031_runtime_resume(struct device *dev)
{
struct video_device *vdev = to_video_device(dev);
struct soc_camera_device *icd = container_of(vdev->parent,
struct soc_camera_device, dev);
struct device *i2c_dev = container_of(icd, struct device,
platform_data);
struct i2c_client *client = to_i2c_client(i2c_dev);
struct mt9t031 *mt9t031 = to_mt9t031(client);
Here I have a problem ... I am pretty sure that the third assignation
has a problem, because platform_data is a pointer and not a normal
member of struct device, and I thus cannot use container_of with it.
What would then be the way to go from the soc_camera_device to the
i2c_client (I'm a little bit confused with all the different structs and
layers involved with i2c, soc-camera, v4l2_device and v4l2_subdevice) ?
Just as a remark, this is the exact reverse path of this that is present
in your patch to add runtime pm support to soc-camera:
/* This is only temporary here - until v4l2-subdev begins to link to
video_device */
#include
static inline struct video_device *soc_camera_i2c_to_vdev(struct
i2c_client *client)
{
struct soc_camera_device *icd = client->dev.platform_data;
return icd->vdev;
}
int ret;
u16 xbin, ybin;
xbin = min(mt9t031->xskip, (u16)3);
ybin = min(mt9t031->yskip, (u16)3);
ret = reg_write(client, MT9T031_COLUMN_ADDRESS_MODE,
((xbin-1)<<4) | (mt9t031->xskip-1));
if (ret < 0)
return ret;
ret = reg_write(client, MT9T031_ROW_ADDRESS_MODE,
((ybin-1)<<4) | (mt9t031->yskip-1));
if (ret < 0)
return ret;
return 0;
}
static struct dev_pm_ops mt9t031_dev_pm_ops = {
.runtime_suspend= mt9t031_runtime_suspend,
.runtime_resume = mt9t031_runtime_resume,
};
static struct device_type mt9t031_dev_type = {
.name = "MT9T031",
.pm = &mt9t031_dev_pm_ops,
};
Re: [GIT PULL for 3.2.33] Fix regressions on dvb demux
Linus Torvalds wrote: > > On Mon, 8 Feb 2010, Mauro Carvalho Chehab wrote: >> are available in the git repository at: >> >> ssh://linuxtv.org/git/fixes.git v4l_for_linus > > I don't have ssh access to that thing, and git:// doesn't work. Sorry for the bad link. We've recently moved our master development trees to git also, in order to work internally the same way as upstream. The git URL is: git://linuxtv.org/fixes.git v4l_for_linus > > You probably meant > > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 > > but it's not pushed out to there yet. My push should be going simultaneously to both remotes, but it seems that only the replica at linuxtv got updated. I'll need to review my .git/config in order to fix it. Anyway, both places are now ok. So, you can pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Am Montag, den 08.02.2010, 08:14 -0800 schrieb Linus Torvalds: > > On Mon, 8 Feb 2010, Chicken Shack wrote: > > > > This is a SCANDAL, not fun! This is SCANDALOUS! > > I agree that this whole thread has been totally inappropriate from > beginning to end. Yes, as a matter of frustration and the way some people around here deal with kernel regressions (shrug shoulders, endless discussions etc.). > On all sides, btw. I would suggest that somebody who can't even use his > own name should be the last to complain about other peoples behavior. Interesting point of view. Would be valid to critically analyze the gesture behind. "Arrogance" would be the most harmless word behind it. Sharper evaluations I better avoid here! > I > have suspicions that the reason you're not using your own name and instead > go by "Chicken Shack" is that you're one of the DVB people that get > ignored because everybody knows you always just argue mindlessly, so now > you use made-up accounts just to not be immediately ignored. Richard Stallman told me: "Banning you as a punishment seems foolishly harsh, too." It's you, Linus Torvalds who makes those foolishly harsh punishments possible. They are very equivalent to a fallback in the middle ages when a term called "bourgeois rights" wasn't even utopic. > And if that is the case, you should take a hard look at your _own_ > behavior, and ask yourself why you get ignored on multiple accounts. When > people ignore your bug reports, maybe it's because they know that the pain > of interacting with you is simply NOT WORTH IT? Well thanks for the flowers, from somebody who goes like "I see that there is an issue, but I do not comprehend or know the what and why." Very helpful, very intelligent, isn't it? And how constructive!? > Anyway, the amount of just this kind of pure _crap_ in the whole DVB > development environment is scary. There are no other areas of Linux kernel > development where we see this kind of personal and _pointless_ invective. It was not not pointless at all. It was a kernel regression, and I found the kernel patch responsive for that. The way this regression is dealt with here is the only thing that is "pointless". > I realize that I probably see the absolute sewer of the whole discussion, > since people seem to Cc me only when things are going badly, but _still_. > I don't see that kind of childish behavior anywhere else in kernel > development. > > Guys, get a f*cking grip already. > > Here's the rule: > > - if somebody reports a regression, IT MUST BE FIXED. Not "discussed" for >two weeks. Not talked around. If we have a bisected commit that starts >oopsing with an existing setup that used to work, there is no >discussion. That commit absolutely _has_ to be reverted or fixed. No >ifs, buts, or maybes about it. Go tell that to guys like Devin Heitmueller. Not me! I really do not know for what kind of ideas or ideals people like him do struggle for when they start hacking here. But the "standard" answers you get when you come up with that first rule above, are: 1. Sorry, I am doing this only in my spare time, without getting paid. 2. Variation of 1.: Sorry, I am short in time. 3. You cannot expect anything unless you pay with a cheque. I am really wondering for what goddamn reason they keep on repeating this continuously. But when it's personally THEM to cause regressions, to fuck up the code, to break peripheral compatibilities, THEN, YES, THEN you do not hear any excuses for being short in time, or for being paid. I call that behaviour asocial, irresponsible, inacceptable. How would you call it, Linus Torvalds? Read Heitmueller's contribution and you know what this kiddy thinks and does not think. >Anybody who argues anything else is simply totally wrong. And >discussing various semantic changes or asking people to use other >programs instead of the one that causes the problem is totally >irrelevant until the oops has been fixed. Here we are! Fully accepted! >An oops is not acceptable in _any_ situation, and saying that the user >program is doing something wrong is totally ludicrous. So is breaking a >program that used to work. > > The fix, btw, for those that haven't seen it, seems to be here: > > http://patchwork.kernel.org/patch/77615/ > > and people should look at that fix, the explanation, and feel embarrassed > about th pure crazy invective that has been going on in this thread. It > was a simple bug, nothing more. It was not worth the intense level of > craziness seen in this thread. Yes, that is really a shame. > Btw, there's a very real reason I haven't replied to this thread before: I > don't like the DVB development process. I've seen the crazyness before, > and I don't know where it comes from. I am breathless. I simply cannot believe it! Ok! You like strict guidelines? Here they are: 1. There is one guy for instance who, from time to time, really
Re: [GIT PULL for 3.2.33] Fix regressions on dvb demux
On Mon, 8 Feb 2010, Mauro Carvalho Chehab wrote: > > are available in the git repository at: > > ssh://linuxtv.org/git/fixes.git v4l_for_linus I don't have ssh access to that thing, and git:// doesn't work. You probably meant git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 but it's not pushed out to there yet. Linus -- 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] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Op maandag 08-02-2010 om 14:43 uur [tijdzone +0100], schreef Chicken Shack: > Now if I were a cynical or ranter or another kind of dumb primitive > persona non grata I would just add "Lol" or stuff like that and turn > myself away. > > But this is no fun here. > > It's nothing but a big proof that one Brazilian person in Mr. Torvalds > "dream team of untouchables" needs to be URGENTLY replaced by another > real capable person. > > NO IDEA ABOUT DVB ISSUES, BUT DVB MAINTAINER! I would like to SINCERELY urge you to cut the ad hominems. If you feel you have arguments furthering your position, please let them stand for themselves. No need to involve someones nationality, religion, star-sign or whatever to make your point. I think people on this list have more pressing issues to deal with (like bisecting hard-to-find kernel oopses or digging up datasheets on undocumented mixer/PLLs and the like) than listening to rants about Brazilians not being team players. Please, just the facts, ma'am. Trolls can feed elsewhere. Sincerely, Alain -- 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: TM6000 Driver building
Richard wrote: > Hi all, > > Pardon my green-ness to the whole process of the v4l-dvb and would like > some pointers on how to build the TM6000 components of the drivers > > in v4l/ directtory I edited the .config to enable the TM6000_DVB=m > clause and rebuilt.. but lo and behold there were still no modules > built.. I am trying to hack on the WinTV-NOVA-S USB2 device and register > it as a Generic TM6000 to start my porting. > > Is there a special branch or a quick 'howto' so I can enable this module > > > Any help would be greatly appreciated. > Richard Richard, This driver is not ready yet for users. There are several flaws on tm6000 design and the driver is not providing enough workarounds to all those bugs. The current status is that the driver is not properly working yet. You should wait for some time for the fixes to be added there. That's said, after finishing the support for Analog and TV,someone will need to work at the DVB-S part of the driver. So, I'm afraid that you'll need to wait for some time in order to get it working with Nova-S. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Stefan Ringel wrote:
> Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
>> Hi Stefan,
>>
>> First, a few comments about your patch series:
>>
>> I've committed almost of your patches, and added an extra patch to make the
>> driver to compile it with -git. There were other broken things when compiling
>> against -git.
>>
>> Several of your patches are adding leading whitespaces. Please review them
>> before
>> submitting. On -git, those whitespaces are shown with a red background color.
>>
>> I've re-made most of the patch descriptions. Please take a look on them and
>> try
>> to improve on a next time.
>>
>> We've got 2 submission for each patches. I just discarded the older one.
>>
>> I've removed the two BEHOLDER board descriptions from one of your patches.
>> It is
>> not related to your board, but it is another compilation fix.
>>
>> From your series, I didn't merge those 3 patches:
>>
>> [5/12] tm6000: update init table and sequence for tm6010
>> http://patchwork.kernel.org/patch/77451
>> [6/12] tm6000: tuner reset timeing optimation
>> http://patchwork.kernel.org/patch/77459
>> [11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and
>> http://patchwork.kernel.org/patch/77462
>>
>> I'll send you separate comments why I didn't merge them, in reply to each
>> email you've sent,
>> starting with this one (patch 5/12).
>>
>>
>> stefan.rin...@arcor.de wrote:
>>
>>> From: Stefan Ringel
>>>
>>> ---
>>> drivers/staging/tm6000/tm6000-core.c | 179
>>> --
>>> 1 files changed, 128 insertions(+), 51 deletions(-)
>>>
>>> diff --git a/drivers/staging/tm6000/tm6000-core.c
>>> b/drivers/staging/tm6000/tm6000-core.c
>>> index 7ec13d5..a2e2af5 100644
>>> --- a/drivers/staging/tm6000/tm6000-core.c
>>> +++ b/drivers/staging/tm6000/tm6000-core.c
>>> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
>>> { REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>>>
>>> { REQ_05_SET_GET_USBREG, 0x18, 0x00 },
>>> -
>>> +
>>> + /* additional from Terratec Cinergy Hybrid XE */
>>> + { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
>>> + { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
>>> + { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
>>> + { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
>>> + { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
>>> + { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
>>> +
>>> /* set remote wakeup key:any key wakeup */
>>> { REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
>>> { REQ_07_SET_GET_AVREG, 0xda, 0xff },
>>> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
>>> {
>>> int board, rc=0, i, size;
>>> struct reg_init *tab;
>>> + u8 buf[40];
>>>
>>> if (dev->dev_type == TM6010) {
>>> tab = tm6010_init_tab;
>>> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
>>> }
>>> }
>>>
>>> - msleep(5); /* Just to be conservative */
>>> -
>>> - /* Check board version - maybe 10Moons specific */
>>> - board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>>> - if (board >=0) {
>>> - printk (KERN_INFO "Board version = 0x%04x\n",board);
>>> - } else {
>>> - printk (KERN_ERR "Error %i while retrieving board
>>> version\n",board);
>>> - }
>>> -
>>> + /* hack */
>>> if (dev->dev_type == TM6010) {
>>> - /* Turn xceive 3028 on */
>>> - tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3,
>>> 0x01);
>>> - msleep(11);
>>> - }
>>>
>> The above is board-specific. It is needed for the tm6010 device I have here
>> (HVR900H), otherwise no xc3028 command will be handled.
>>
>> The better here is to add a setup routine to tm6000-cards and move all
>> those GPIO codes to it. Then, add there your board-specific setup.
>>
>> I've added a patch that moves those GPIO board-specific setup to
>> tm6000-cards:
>> tm6000_cards_setup(). Please move your board specific GPIO init to there.
>>
>>
>>
>>> -
>>> - /* Reset GPIO1 and GPIO4. */
>>> - for (i=0; i< 2; i++) {
>>> - rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> - dev->tuner_reset_gpio, 0x00);
>>> - if (rc<0) {
>>> - printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>>> - return rc;
>>> - }
>>> -
>>> - msleep(10); /* Just to be conservative */
>>> - rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>>> - dev->tuner_reset_gpio, 0x01);
>>> - if (rc<0) {
>>> - printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>>> - return rc;
>>> - }
>>> -
>>> - msleep(10);
>>> - rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
>>> 0);
>>> - if (rc<0) {
>>> - printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>>> - return rc;
>>> - }
>>> -
>>> - msleep(10);
Re: [PATCH/RESEND] soc-camera: add runtime pm support for subdevices
Guennadi Liakhovetski wrote: > Hi Mauro > > Thanks for your comments. > > On Mon, 8 Feb 2010, Mauro Carvalho Chehab wrote: > >> Guennadi Liakhovetski wrote: >>> To save power soc-camera powers subdevices down, when they are not in use, >>> if this is supported by the platform. However, the V4L standard dictates, >>> that video nodes shall preserve configuration between uses. This requires >>> runtime power management, which is implemented by this patch. It allows >>> subdevice drivers to specify their runtime power-management methods, by >>> assigning a type to the video device. >> It seems a great idea to me. For sure we need some sort of power management >> control. > > Agree;) > >>> Signed-off-by: Guennadi Liakhovetski >>> --- >>> >>> I've posted this patch to linux-media earlier, but I'd also like to get >>> comments on linux-pm, sorry to linux-media falks for a duplicate. To >>> explain a bit - soc_camera.c is a management module, that binds video >>> interfaces on SoCs and sensor drivers. The calls, that I am adding to >>> soc_camera.c shall save and restore sensor registers before they are >>> powered down and after they are powered up. >>> >>> diff --git a/drivers/media/video/soc_camera.c >>> b/drivers/media/video/soc_camera.c >>> index 6b3fbcc..53201f3 100644 >>> --- a/drivers/media/video/soc_camera.c >>> +++ b/drivers/media/video/soc_camera.c >>> @@ -24,6 +24,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >> >> Hmm... wouldn't it be better to enable it at the subsystem level? We may for >> example call ? >> The subsystem can call vidioc_streamoff() at suspend and vidioc_streamon() at >> resume, if the device were streaming during suspend. We may add another ops >> to >> the struct for the drivers/subdrivers that needs additional care. >> >> That's said, it shouldn't be hard to implement some routine that will >> save/restore >> all registers if the device goes to power down mode. Unfortunately, very few >> devices successfully recovers from hibernation if streaming. One good example >> is saa7134, that even disables/re-enables IR IRQ's during suspend/resume. > > To clarify a bit - this patch implements not static PM, but dynamic > (runtime) power-management. Ok. > In this case it means, we are trying to save > power while the system is running, but we know, that the sensor is not > needed. Specifically, as long as no application is holding the video > device open. And this information is only available at the bridge driver > (soc-camera core) level - there is no subdev operation for open and close > calls, so, subdevices do not "know" whether they are in use or not. So, > only saving / restoring registers when streaming is not enough. Static PM > will also be interesting - as it has been mentioned before, we will have > to be careful, because sensors "sit" on two busses - i2c and video. So, > you have to resume after both are up and suspend before the first of them > goes down... So, that will be a different exciting topic;) In fact, on all drivers, there are devices that needs to be turn on only when streaming is happening: sensors, analog TV/audio demods, digital demods. Also, a few devices (for example: TV tuners) could eventually be on power off when no device is opened. As the V4L core knows when this is happening (due to open/close/poll/streamon/reqbuf/qbuf/dqbuf hooks, I think the runtime management can happen at V4L core level. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/12] tm6000: add tuner parameter
Stefan Ringel wrote: > Am 08.02.2010 03:55, schrieb Mauro Carvalho Chehab: >> stefan.rin...@arcor.de wrote: >> >> >>> + ctl.vhfbw7 = 1; >>> + ctl.uhfbw8 = 1; >>> >> I don't think you need to set this, as the driver will automatically do the >> firmware >> tricks for the firmwares. This will probably just change the default to start >> wit firmware 7/8. >> >> > > if it's going to bw 7 it doesn't use DTV 7, it's use DTV 7 not DTV78, I > have it tested. I think if it's switch between DTV7 and DTV 8 it's not > always set DTV78. ( it's set DTV 7 DTV 8 or DTV78) > Sorry but I didn't understand what you meant. Anyway, the patch were committed as-is. We may eventually need to revisit this code later. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
Stefan Ringel wrote:
> Am 08.02.2010 12:27, schrieb Mauro Carvalho Chehab:
>> stefan.rin...@arcor.de wrote:
>>
>>> From: Stefan Ringel
>>>
>>> Signed-off-by: Stefan Ringel
>>> ---
>>> drivers/media/common/tuners/tuner-xc2028.c |7 ++-
>>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
>>> b/drivers/media/common/tuners/tuner-xc2028.c
>>> index ed50168..fcf19cc 100644
>>> --- a/drivers/media/common/tuners/tuner-xc2028.c
>>> +++ b/drivers/media/common/tuners/tuner-xc2028.c
>>> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>>>
>>> /* All S-code tables need a 200kHz shift */
>>> if (priv->ctrl.demod) {
>>> - demod = priv->ctrl.demod + 200;
>>> + if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) &&
>>> + (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
>>> + ((type & DTV78) || (type & DTV8)))
>>> + demod = priv->ctrl.demod;
>>> + else
>>> + demod = priv->ctrl.demod + 200;
>>> /*
>>> * The DTV7 S-code table needs a 700 kHz shift.
>>> * Thanks to Terry Wu for reporting this
>>>
>> The idea behind this patch is right, but you should be testing it against
>> priv->firm_version, instead comparing with a file name.
>>
>> Also, this will likely cause regressions on other drivers, since the offsets
>> for
>> v3.6 firmwares were handled on a different way on other drivers. I prefer to
>> postpone
>> this patch and the discussion behind it after having tm6000 driver ready,
>> since
>> it makes no sense to cause regressions or request changes on existing
>> drivers due
>> to a driver that is not ready yet.
>>
>> So, please hold your patch on your queue for now.
>>
>> My suggestion is that you should use git and have this patch on a separate
>> branch where you
>> do your tests, having a branch without this patch for upstream submission.
>>
>>
> In this firmware is for ZARLINK two parts, first for QAM, DTV6 and DTV7
> with shift 200 kHz, and second for DTV78 and DTV8. I check the firmware
> 2.7 this use for ZARLINK for all this mode a 200 kHz shift. For the next
> source part it says that DTV7 have 700 kHz shift.
> That not for all firmware correct.
>
>
>From what we know, the name "zarlink" for the firmware is bogus: the firmware
>has nothing
special to work with zarlink, except for the IF offset. You may or select a
firmware with
-200 KHz IF offset or to do the adjustment by adding 200 KHz for firmwares up
to 2.7.
The problem is that the driver that originally added the v3.6 implemented it on
a different
place. So, we need to fix all the drivers at the patch that we're changing its
behavior,
to avoid breakages.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Stefan Ringel wrote: > Am 08.02.2010 18:34, schrieb Stefan Ringel: >> Am 08.02.2010 18:29, schrieb Mauro Carvalho Chehab: >> >>> Stefan Ringel wrote: >>> >>> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab: > Mauro Carvalho Chehab wrote: > > > >>> + tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, >>> buf, 2); >>> >>> >>> > > > >> Most of the calls there are read (0xc0). I don't know any device that >> requires >> a read for it to work. I suspect that the above code is just probing to >> check >> what i2c devices are found at the board. >> >> >> > Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an > idea > on what the above does: > > The register 0x7f is: > > CHIP_ID= 0x7F, > > So, basically, the above code is reading the ID of the chip, likely to be > sure that it > is a Zarlink 10353. > > 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 > > > yes, but that's for activating Zarlink zl10353 and checking it --> hello Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353. >>> Are you sure about that? Is this a new bug on tm6000? >>> >>> Anyway, the proper place for such code is inside zl10353 driver, not >>> outside. >>> >>> >>> >> It cannot activate after load xc3028 firmware. >> >> > That part is I think it's board specific or tm6010. > Probably yet-another-i2c-bug-on-tm6000... Ah, well... then, convert this call into an i2c call. You may get one example of such in em28xx-cards. In that specific case, em28xx-based webcams can be shipped with more than one different sensor. So, the driver needs to read the sensor from I2C: rc = i2c_master_recv(&dev->i2c_client, (char *)&version_be, 2); if (rc != 2) return -EINVAL; Of course, you need to be sure to register the i2c bus before calling i2c_master_recv. -- 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
[PATCH] Twinhan 1027 + IR Port support.
Ok. 3rd try (and i hope the last) to submit this stupid patch. This patch applies correctly to current mercurial revision (tried 2 times. patch -p 1 vp1027+ir.patch). Now about changes. Patch add support of TwinHan 1027 DVB-S card. Original author is Manu Abraham (abraham dot manu at gmail dot com). IR Port support is my job. -- WBR Sergey Kash Ivanov. vp1027+ir.patch Description: Binary data
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Am 08.02.2010 18:34, schrieb Stefan Ringel: > Am 08.02.2010 18:29, schrieb Mauro Carvalho Chehab: > >> Stefan Ringel wrote: >> >> >>> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab: >>> >>> Mauro Carvalho Chehab wrote: >> +tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, >> buf, 2); >> >> >> > Most of the calls there are read (0xc0). I don't know any device that > requires > a read for it to work. I suspect that the above code is just probing to > check > what i2c devices are found at the board. > > > Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea on what the above does: The register 0x7f is: CHIP_ID= 0x7F, So, basically, the above code is reading the ID of the chip, likely to be sure that it is a Zarlink 10353. 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 >>> yes, but that's for activating Zarlink zl10353 and checking it --> hello >>> Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353. >>> >>> >>> >> Are you sure about that? Is this a new bug on tm6000? >> >> Anyway, the proper place for such code is inside zl10353 driver, not outside. >> >> >> > It cannot activate after load xc3028 firmware. > > That part is I think it's board specific or tm6010. -- Stefan Ringel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Am 08.02.2010 18:29, schrieb Mauro Carvalho Chehab: > Stefan Ringel wrote: > >> Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab: >> >>> Mauro Carvalho Chehab wrote: >>> >>> > + tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, buf, 2); > > >>> >>> Most of the calls there are read (0xc0). I don't know any device that requires a read for it to work. I suspect that the above code is just probing to check what i2c devices are found at the board. >>> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an >>> idea >>> on what the above does: >>> >>> The register 0x7f is: >>> >>> CHIP_ID= 0x7F, >>> >>> So, basically, the above code is reading the ID of the chip, likely to be >>> sure that it >>> is a Zarlink 10353. >>> >>> 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 >>> >>> >> yes, but that's for activating Zarlink zl10353 and checking it --> hello >> Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353. >> >> > Are you sure about that? Is this a new bug on tm6000? > > Anyway, the proper place for such code is inside zl10353 driver, not outside. > > It cannot activate after load xc3028 firmware. -- Stefan Ringel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Am 08.02.2010 12:21, schrieb Mauro Carvalho Chehab:
> Hi Stefan,
>
> First, a few comments about your patch series:
>
> I've committed almost of your patches, and added an extra patch to make the
> driver to compile it with -git. There were other broken things when compiling
> against -git.
>
> Several of your patches are adding leading whitespaces. Please review them
> before
> submitting. On -git, those whitespaces are shown with a red background color.
>
> I've re-made most of the patch descriptions. Please take a look on them and
> try
> to improve on a next time.
>
> We've got 2 submission for each patches. I just discarded the older one.
>
> I've removed the two BEHOLDER board descriptions from one of your patches. It
> is
> not related to your board, but it is another compilation fix.
>
> From your series, I didn't merge those 3 patches:
>
> [5/12] tm6000: update init table and sequence for tm6010
> http://patchwork.kernel.org/patch/77451
> [6/12] tm6000: tuner reset timeing optimation
> http://patchwork.kernel.org/patch/77459
> [11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and
> http://patchwork.kernel.org/patch/77462
>
> I'll send you separate comments why I didn't merge them, in reply to each
> email you've sent,
> starting with this one (patch 5/12).
>
>
> stefan.rin...@arcor.de wrote:
>
>> From: Stefan Ringel
>>
>> ---
>> drivers/staging/tm6000/tm6000-core.c | 179
>> --
>> 1 files changed, 128 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/staging/tm6000/tm6000-core.c
>> b/drivers/staging/tm6000/tm6000-core.c
>> index 7ec13d5..a2e2af5 100644
>> --- a/drivers/staging/tm6000/tm6000-core.c
>> +++ b/drivers/staging/tm6000/tm6000-core.c
>> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
>> { REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>>
>> { REQ_05_SET_GET_USBREG, 0x18, 0x00 },
>> -
>> +
>> +/* additional from Terratec Cinergy Hybrid XE */
>> +{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
>> +{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
>> +{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
>> +{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
>> +{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
>> +{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
>> +
>> /* set remote wakeup key:any key wakeup */
>> { REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
>> { REQ_07_SET_GET_AVREG, 0xda, 0xff },
>> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
>> {
>> int board, rc=0, i, size;
>> struct reg_init *tab;
>> +u8 buf[40];
>>
>> if (dev->dev_type == TM6010) {
>> tab = tm6010_init_tab;
>> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
>> }
>> }
>>
>> -msleep(5); /* Just to be conservative */
>> -
>> -/* Check board version - maybe 10Moons specific */
>> -board=tm6000_get_reg16 (dev, 0x40, 0, 0);
>> -if (board >=0) {
>> -printk (KERN_INFO "Board version = 0x%04x\n",board);
>> -} else {
>> -printk (KERN_ERR "Error %i while retrieving board
>> version\n",board);
>> -}
>> -
>> +/* hack */
>> if (dev->dev_type == TM6010) {
>> -/* Turn xceive 3028 on */
>> -tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3,
>> 0x01);
>> -msleep(11);
>> -}
>>
> The above is board-specific. It is needed for the tm6010 device I have here
> (HVR900H), otherwise no xc3028 command will be handled.
>
> The better here is to add a setup routine to tm6000-cards and move all
> those GPIO codes to it. Then, add there your board-specific setup.
>
> I've added a patch that moves those GPIO board-specific setup to tm6000-cards:
> tm6000_cards_setup(). Please move your board specific GPIO init to there.
>
>
>
>> -
>> -/* Reset GPIO1 and GPIO4. */
>> -for (i=0; i< 2; i++) {
>> -rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> -dev->tuner_reset_gpio, 0x00);
>> -if (rc<0) {
>> -printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>> -return rc;
>> -}
>> -
>> -msleep(10); /* Just to be conservative */
>> -rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
>> -dev->tuner_reset_gpio, 0x01);
>> -if (rc<0) {
>> -printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
>> -return rc;
>> -}
>> -
>> -msleep(10);
>> -rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
>> 0);
>> -if (rc<0) {
>> -printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
>> -return rc;
>> -}
>> -
>> -msleep(10);
>> -rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
>> 1);
>> -if
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Stefan Ringel wrote: > Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab: >> Mauro Carvalho Chehab wrote: >> + tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, buf, 2); >> >>> Most of the calls there are read (0xc0). I don't know any device that >>> requires >>> a read for it to work. I suspect that the above code is just probing to >>> check >>> what i2c devices are found at the board. >>> >> Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an >> idea >> on what the above does: >> >> The register 0x7f is: >> >> CHIP_ID= 0x7F, >> >> So, basically, the above code is reading the ID of the chip, likely to be >> sure that it >> is a Zarlink 10353. >> >> 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 >> > > yes, but that's for activating Zarlink zl10353 and checking it --> hello > Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353. > Are you sure about that? Is this a new bug on tm6000? Anyway, the proper place for such code is inside zl10353 driver, not outside. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Linus Torvalds wrote: > - if somebody reports a regression, IT MUST BE FIXED. Not "discussed" for >two weeks. Not talked around. If we have a bisected commit that starts >oopsing with an existing setup that used to work, there is no >discussion. That commit absolutely _has_ to be reverted or fixed. No >ifs, buts, or maybes about it. >Anybody who argues anything else is simply totally wrong. And >discussing various semantic changes or asking people to use other >programs instead of the one that causes the problem is totally >irrelevant until the oops has been fixed. > >An oops is not acceptable in _any_ situation, and saying that the user >program is doing something wrong is totally ludicrous. So is breaking a >program that used to work. > > The fix, btw, for those that haven't seen it, seems to be here: > > http://patchwork.kernel.org/patch/77615/ Yes, this patch actually fixed the OOPS, although it were a report From Chicken saying that a previous patch got fixed it (http://patchwork.kernel.org/patch/76071/). I submitted you both fixes, plus a third one (http://patchwork.kernel.org/patch/76083/) for a potential usage of vmalloc during interrupt time. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
Am 08.02.2010 12:27, schrieb Mauro Carvalho Chehab:
> stefan.rin...@arcor.de wrote:
>
>> From: Stefan Ringel
>>
>> Signed-off-by: Stefan Ringel
>> ---
>> drivers/media/common/tuners/tuner-xc2028.c |7 ++-
>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
>> b/drivers/media/common/tuners/tuner-xc2028.c
>> index ed50168..fcf19cc 100644
>> --- a/drivers/media/common/tuners/tuner-xc2028.c
>> +++ b/drivers/media/common/tuners/tuner-xc2028.c
>> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>>
>> /* All S-code tables need a 200kHz shift */
>> if (priv->ctrl.demod) {
>> -demod = priv->ctrl.demod + 200;
>> +if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) &&
>> +(priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
>> +((type & DTV78) || (type & DTV8)))
>> +demod = priv->ctrl.demod;
>> +else
>> +demod = priv->ctrl.demod + 200;
>> /*
>> * The DTV7 S-code table needs a 700 kHz shift.
>> * Thanks to Terry Wu for reporting this
>>
> The idea behind this patch is right, but you should be testing it against
> priv->firm_version, instead comparing with a file name.
>
> Also, this will likely cause regressions on other drivers, since the offsets
> for
> v3.6 firmwares were handled on a different way on other drivers. I prefer to
> postpone
> this patch and the discussion behind it after having tm6000 driver ready,
> since
> it makes no sense to cause regressions or request changes on existing drivers
> due
> to a driver that is not ready yet.
>
> So, please hold your patch on your queue for now.
>
> My suggestion is that you should use git and have this patch on a separate
> branch where you
> do your tests, having a branch without this patch for upstream submission.
>
>
In this firmware is for ZARLINK two parts, first for QAM, DTV6 and DTV7
with shift 200 kHz, and second for DTV78 and DTV8. I check the firmware
2.7 this use for ZARLINK for all this mode a 200 kHz shift. For the next
source part it says that DTV7 have 700 kHz shift.
That not for all firmware correct.
--
Stefan Ringel
list action
firmware file name: xc3028-v27.fw
firmware name: xc2028 firmware
version:2.7 (519)
standards: 80
Firmware 0, type: BASE FW F8MHZ (0x0003), id: (), size:
8718
Firmware 1, type: BASE FW F8MHZ MTS (0x0007), id: (),
size: 8712
Firmware 2, type: BASE FW FM (0x0401), id: (), size: 8562
Firmware 3, type: BASE FW FM INPUT1 (0x0c01), id: (),
size: 8576
Firmware 4, type: BASE FW (0x0001), id: (), size: 8706
Firmware 5, type: BASE FW MTS (0x0005), id: (), size:
8682
Firmware 6, type: STD FW(0x), id: PAL/BG A2/A (00010007),
size: 161
Firmware 7, type: STD FWMTS (0x0004), id: PAL/BG A2/A
(00010007), size: 169
Firmware 8, type: STD FW(0x), id: PAL/BG A2/B (00020007),
size: 161
Firmware 9, type: STD FWMTS (0x0004), id: PAL/BG A2/B
(00020007), size: 169
Firmware 10, type: STD FW(0x), id: PAL/BG NICAM/A
(00040007), size: 161
Firmware 11, type: STD FWMTS (0x0004), id: PAL/BG NICAM/A
(00040007), size: 169
Firmware 12, type: STD FW(0x), id: PAL/BG NICAM/B
(00080007), size: 161
Firmware 13, type: STD FWMTS (0x0004), id: PAL/BG NICAM/B
(00080007), size: 169
Firmware 14, type: STD FW(0x), id: PAL/DK A2 (000300e0),
size: 161
Firmware 15, type: STD FWMTS (0x0004), id: PAL/DK A2
(000300e0), size: 169
Firmware 16, type: STD FW(0x), id: PAL/DK NICAM (000c00e0),
size: 161
Firmware 17, type: STD FWMTS (0x0004), id: PAL/DK NICAM
(000c00e0), size: 169
Firmware 18, type: STD FW(0x), id: SECAM/K1 (0020),
size: 161
Firmware 19, type: STD FWMTS (0x0004), id: SECAM/K1 (0020),
size: 169
Firmware 20, type: STD FW(0x), id: SECAM/K3 (0400),
size: 161
Firmware 21, type: STD FWMTS (0x0004), id: SECAM/K3 (0400),
size: 169
Firmware 22, type: STD FWD2633 DTV6 ATSC (0x00010030), id:
(), size: 149
Firmware 23, type: STD FWD2620 DTV6 QAM (0x0068), id:
(), size: 149
Firmware 24, type: STD FWD2633 DTV6 QAM (0x0070), id:
(), size: 149
Firmware 25, type: STD FWD2620 DTV7 (0x0088), id: (),
size: 149
Firmware 26, type: STD FWD2633 DTV7 (0x0090), id: (),
size: 149
Firmware 27, type: STD FWD2620 DTV78 (0x0108), id: (),
size: 149
Firmware 28, type: STD FWD2633 DTV78 (0x00
Re: Terratec H5 / Micronas
Hi On Monday 08 February 2010 17:49:29 Markus Rechberger wrote: > To write a driver with good quality it takes alot more than just 50 > hours, it took us > around 1 year to have a certain quality now. > We now support Linux, FreeBSD and MacOSX with the same driver as well as > embedded ARM devices with bugged compilers. > Just having it work will result in alot signal problems with some > cable providers. > The Micronas drivers are probably the most complex drivers this entire > project has ever > seen. Thank you for your quick reply. Well, that sounds pretty bad indeed. On the other hand, my goal is not to write a perfect driver, but start writing and see where that leads me. I might very well give up after a few unsuccessful attempts. > > My question is, did the Micronas legal department intervene because the > > linux driver built on top of their reference implementation and they > > weren't willing to gpl that, or did they also oppose on using the > > data-sheets? If it was only the reference driver, wouldn't it be > > whorthwhile trying to again get the data sheets and build a driver based > > solely on these? I couldn't find any post that would clarify this. > > it's an official statement, that they do not want to have their driver > opensourced. Yes, I understood that. The question was, does that also apply to writing a driver based only on the data sheets, without ever even looking at their reference driver code? > > However, I'm in no way an expert in v4l driver writing, so I > > don't know where this will lead to or if I'm going to brick the device on > > the very first occasion ;-) (btw: how easy is that, generally?) > > it's the most difficult device. Ah, let me clarify that. I wasn't asking how easy it is to write a driver, but actually quite the opposite: how easy is it to damage the typical dvb-t tuner by (accidentally) writing garbage to some registers? > In case you're looking for something that works with Linux better > return it asap, or sell it Thanks. I did consider that. But I have already accepted that the device isn't working and isn't going to work in the not so remote future. I was wondering if I could at least try to establish some communication with the device. Even if that won't result in a working driver, I might learn something. Best case: other people pick up some work and we get a working driver, maybe in 5 or 10 years ;-) Markus (M) -- 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: [Bugme-new] [Bug 15087] New: hauppauge nova-t 500 remote controller cause usb halt with Via usb controller
On Sat, Feb 6, 2010 at 12:14 PM, edm wrote: >> (switched to email. Please respond via emailed reply-to-all, not via the >> bugzilla web interface). > Hi, using the last version of v4l-dvb driver from hg, solved this > issue. I tested the card in the last days and it seems to work well > now; the IR receiver works, I tested it using irw, all the keys are > recognised. > I can't test the IR receiver with a specific program because the > .lircrc is ignored but I think it's a gnome-related problem :) > Is the option "dvb_usb_dib0700 force_lna_activation=1" still > necessary? Why this option is not activated at default? Hello edm, Sorry for the delayed response on this. Glad to hear it's now working for you. With regards to the force_lna_activation option, this was never actually related to the dib0700 firmware changes. That option simply may or may not be required depending on what your signal conditions are. Enabling the low noise amplifier is something that you will typically do only if your signal conditions are poor, which is why it is not enabled by default. The fix referred to in this bug report was strictly for the dib0700 problem introduced as a result to changes for IR required to support the 1.20 firmware. Cheers, 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: Terratec H5 / Micronas
On Mon, Feb 8, 2010 at 4:56 PM, Markus Moll wrote: > Hi > > I have just bought one of these terratec usb sticks (without looking at the > list of supported devices first, my fault, I know) and I guess I'm unable to > return it. Before I give it away for free or sell it at a much lower price, I > wanted to ask a few things. Let me recapitulate the story as I understood it. > Devin Heitmueller once worked on a driver implementation using official > Micronas data-sheets and their reference implementation. The Micronas legal > department then denied publication in a very late stage. Meanwhile, Markus > Rechberger wrote his own user-space closed-source driver, but has now stopped > distributing that and instead founded his own company Sundtek. Furthermore, > parts of Micronas have been bought by Trident Microsystems. > > I hope I'm correct up to here. I also saw an estimate of the amount of work > required to write a reverse engineered driver, it ranged around 50hrs. To write a driver with good quality it takes alot more than just 50 hours, it took us around 1 year to have a certain quality now. We now support Linux, FreeBSD and MacOSX with the same driver as well as embedded ARM devices with bugged compilers. Just having it work will result in alot signal problems with some cable providers. The Micronas drivers are probably the most complex drivers this entire project has ever seen. > My question is, did the Micronas legal department intervene because the linux > driver built on top of their reference implementation and they weren't willing > to gpl that, or did they also oppose on using the data-sheets? If it was only > the reference driver, wouldn't it be whorthwhile trying to again get the data > sheets and build a driver based solely on these? I couldn't find any post that > would clarify this. it's an official statement, that they do not want to have their driver opensourced. > > I would be willing to invest some time, play with the device and see if I can > improve the situation, probably even if I really had to reverse engineer. > However, I'm in no way an expert in v4l driver writing, so I don't know where > this will lead to or if I'm going to brick the device on the very first > occasion ;-) (btw: how easy is that, generally?) > it's the most difficult device. > I know that the general advice is to dump these devices and buy something > else, but as I said I'll have this hardware lying around anyway. So I'd like > to know if I missed something, if there is any prior work (unaffected by the > legal problems), or if I'm bound to fail because the task is just too big. > In case you're looking for something that works with Linux better return it asap, or sell it 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
[GIT PULL for 3.2.33] Fix regressions on dvb demux
The following changes since commit 6339204ecc2aa2067a99595522de0403f0854bb8: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../viro/vfs-2.6 are available in the git repository at: ssh://linuxtv.org/git/fixes.git v4l_for_linus Those patches addresses the regression on 2.3.32 on dvb core. Francesco Lavra (1): V4L/DVB: dvb-core: fix initialization of feeds list in demux filter Mauro Carvalho Chehab (2): V4L/DVB: Fix the risk of an oops at dvb_dmx_release V4L/DVB: dvb_demux: Don't use vmalloc at dvb_dmx_swfilter_packet drivers/media/dvb/dvb-core/dmxdev.c|2 +- drivers/media/dvb/dvb-core/dvb_demux.c | 20 +--- 2 files changed, 10 insertions(+), 12 deletions(-) -- 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
Terratec H5 / Micronas
Hi I have just bought one of these terratec usb sticks (without looking at the list of supported devices first, my fault, I know) and I guess I'm unable to return it. Before I give it away for free or sell it at a much lower price, I wanted to ask a few things. Let me recapitulate the story as I understood it. Devin Heitmueller once worked on a driver implementation using official Micronas data-sheets and their reference implementation. The Micronas legal department then denied publication in a very late stage. Meanwhile, Markus Rechberger wrote his own user-space closed-source driver, but has now stopped distributing that and instead founded his own company Sundtek. Furthermore, parts of Micronas have been bought by Trident Microsystems. I hope I'm correct up to here. I also saw an estimate of the amount of work required to write a reverse engineered driver, it ranged around 50hrs. My question is, did the Micronas legal department intervene because the linux driver built on top of their reference implementation and they weren't willing to gpl that, or did they also oppose on using the data-sheets? If it was only the reference driver, wouldn't it be whorthwhile trying to again get the data sheets and build a driver based solely on these? I couldn't find any post that would clarify this. I would be willing to invest some time, play with the device and see if I can improve the situation, probably even if I really had to reverse engineer. However, I'm in no way an expert in v4l driver writing, so I don't know where this will lead to or if I'm going to brick the device on the very first occasion ;-) (btw: how easy is that, generally?) I know that the general advice is to dump these devices and buy something else, but as I said I'll have this hardware lying around anyway. So I'd like to know if I missed something, if there is any prior work (unaffected by the legal problems), or if I'm bound to fail because the task is just too big. 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
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
On Mon, 8 Feb 2010, Chicken Shack wrote: > > This is a SCANDAL, not fun! This is SCANDALOUS! I agree that this whole thread has been totally inappropriate from beginning to end. On all sides, btw. I would suggest that somebody who can't even use his own name should be the last to complain about other peoples behavior. I have suspicions that the reason you're not using your own name and instead go by "Chicken Shack" is that you're one of the DVB people that get ignored because everybody knows you always just argue mindlessly, so now you use made-up accounts just to not be immediately ignored. And if that is the case, you should take a hard look at your _own_ behavior, and ask yourself why you get ignored on multiple accounts. When people ignore your bug reports, maybe it's because they know that the pain of interacting with you is simply NOT WORTH IT? Anyway, the amount of just this kind of pure _crap_ in the whole DVB development environment is scary. There are no other areas of Linux kernel development where we see this kind of personal and _pointless_ invective. I realize that I probably see the absolute sewer of the whole discussion, since people seem to Cc me only when things are going badly, but _still_. I don't see that kind of childish behavior anywhere else in kernel development. Guys, get a f*cking grip already. Here's the rule: - if somebody reports a regression, IT MUST BE FIXED. Not "discussed" for two weeks. Not talked around. If we have a bisected commit that starts oopsing with an existing setup that used to work, there is no discussion. That commit absolutely _has_ to be reverted or fixed. No ifs, buts, or maybes about it. Anybody who argues anything else is simply totally wrong. And discussing various semantic changes or asking people to use other programs instead of the one that causes the problem is totally irrelevant until the oops has been fixed. An oops is not acceptable in _any_ situation, and saying that the user program is doing something wrong is totally ludicrous. So is breaking a program that used to work. The fix, btw, for those that haven't seen it, seems to be here: http://patchwork.kernel.org/patch/77615/ and people should look at that fix, the explanation, and feel embarrassed about th pure crazy invective that has been going on in this thread. It was a simple bug, nothing more. It was not worth the intense level of craziness seen in this thread. Btw, there's a very real reason I haven't replied to this thread before: I don't like the DVB development process. I've seen the crazyness before, and I don't know where it comes from. Some people blame Mauro, but the thing is, this whole problem with the DVB development tone used to be _worse_. It's likely some deep social reason. I have a few suspicions, but they are just guesses. For example, I suspect it's partly because DVB gets a much less wide development audience - there are clearly some people in the DVB driver area that are totally unable to see anything but their own small area, and they are too focused on just some detail, and then they get upset when others care about other details or about the big picture. I admit that I used to think that it was because a lot of the people involved were Germans, and that the whole mindless bickering was somehow cultural. A _lot_ of the worst invective comes from exactly places like 'gmx.de', which seems to be one of the big mail servers in Germany. But there are lots of _good_ developers with that address too, so I suspect my "Oh, it's the Germans" explanation was just a funny/sad prejudice. Why can't DVB people be sane? Please, guys? And btw, don't in any way think that I think that the problem has just been that people have had a hard time just admitting that that commit that caused the oops need to be fixed. One of the reasons I think people had a hard time fixing the regression was that the original bug report, and all the invective was all just totally hiding the real issue. Instead of making a nice bugzilla and talking about the technical problem, the whole beginning of this thread from Chicken Shack has been all about shouting at people. I'm perfectly happy with shouting at people (I'm doing it right now), but damn, this thread has just been totally incoherent and stupid. Put some real _technical_ reasoning in your crazy rants. So damn it, stop cc'ing me on DVB issues. Chicken Shack - I very much mean you. I'm not interested in crazy bickering. If you Cc me, include proper technical details, and keep it at that level. And Mauro &co: get me that fix, and stop discussing anything else until the actual oops has been fixed. Everybody: start acting like adults, guys. Linus -- 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.ker
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Hello Mr. Shack, On Mon, Feb 8, 2010 at 8:43 AM, Chicken Shack wrote: > I vote for Andy Walls, Devin Heitmueller. There are a couple of capable > candidates here who can really do that job with a better output for the > whole Linux community. > There is ABSOLUTELY NO necessity to continue with Mauro Carvalho Chehab. I want to take this opportunity to thank you for your nomination and vote. It means so much to me to see this nomination coming from such a dedicated contributor to the project, given your years of service and hundreds of patches to the LinuxTV project. I've quietly sat back and watched this thread over the last few days. I've watched your abusive and condescending attitude toward the volunteers who have spent their limited time trying to help resolve the issue you reported. You seem to have forgotten that you are dealing with a group of volunteers, and that they have absolutely *no* obligation whatsoever to help you in making your application work. As a user, I can appreciate your frustration: your application used to work and now it doesn't. But *demanding* that developers stop what they are doing to fix your problem is not particularly productive. Unless you are cutting them a check, they have no obligation to do what you want. Was there a regression? Yup. Shit happens. Let's focus on what needs to be done to fix it. While you interpreted the extended thread of discussion of various options as counter-productive, this is actually how development works. Somebody reports a problem. Developers discuss the various potential approaches available to deal with the problem. Other developers point out why those approaches aren't appropriate or could cause other issues. "When you are dumb, you surround yourself with smart people. When you are smart, you surround yourself with smart people who disagree with you." In this case, while not doubting the reported problem was valid, the notion of rolling back functionality that made it into a stable kernel in order to address the problem is something that isn't desirable. The best case is when a fix can be made while preserving compatibility with both usage patterns. When that isn't possible, then hard decisions need to be made. And as someone who has both fixed bugs in the DVB core as well as having introduced them, I can appreciate how hard it can be to understand that piece of code. It's an inherently complicated problem, involving multiple threads of execution and concurrency, as well as a large number of applications that use the API in different ways. With regards to your concerns about Mauro being the maintainer, what can I say? Does he make mistakes? Sure. Does he sometimes do things I disagree with? Yup. Would I want his job? Absolutely not. It's a thankless job and people only notice what you do when you make a mistake. He has to evaluate patches not just in terms of how they effect whatever tuner the developer submitted them for, but also for all the other products that use the same code. When people submit patches that effect application behavior, he has put forth his best effort to ensure that it doesn't break other applications. This is a nontrivial exercise, and we should be thankful that Mauro has been willing to do it for as long as he has (most maintainers of large codebases experience "burn out" after a relatively short period of time). One of the things that is so empowering about open source is the ability to fix your own problems if it matters enough to you. You have the full source code to all the components, and if some issue is critical to you then you have everything you need to fix your own problems. You are only limited by your own commitment to learn how to program. Now I'm going to go back to working on my driver code. Cheers, 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 5/12] tm6000: update init table and sequence for tm6010
Am 08.02.2010 12:37, schrieb Mauro Carvalho Chehab: > Mauro Carvalho Chehab wrote: > >>> + tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, buf, 2); >>> > >> Most of the calls there are read (0xc0). I don't know any device that >> requires >> a read for it to work. I suspect that the above code is just probing to check >> what i2c devices are found at the board. >> > Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea > on what the above does: > > The register 0x7f is: > > CHIP_ID= 0x7F, > > So, basically, the above code is reading the ID of the chip, likely to be > sure that it > is a Zarlink 10353. > > 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 > yes, but that's for activating Zarlink zl10353 and checking it --> hello Zarlink? If doesn't use that sequence, then cannot use Zarlink zl10353. -- Stefan Ringel -- 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 8/12] tm6000: add tuner parameter
Am 08.02.2010 03:55, schrieb Mauro Carvalho Chehab: > stefan.rin...@arcor.de wrote: > > >> +ctl.vhfbw7 = 1; >> +ctl.uhfbw8 = 1; >> > I don't think you need to set this, as the driver will automatically do the > firmware > tricks for the firmwares. This will probably just change the default to start > wit firmware 7/8. > > if it's going to bw 7 it doesn't use DTV 7, it's use DTV 7 not DTV78, I have it tested. I think if it's switch between DTV7 and DTV 8 it's not always set DTV78. ( it's set DTV 7 DTV 8 or DTV78) -- Stefan Ringel -- 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: dvb-usb-remote woes [was: HID: ignore afatech 9016]
On Fri, 5 Feb 2010, Pekka Sarnila wrote: > > Can't be HID bus with a specific driver used instead now? > > Well it could, but this way it is much less work and more generic. I use many > different joysticks, yokes and pedals. And with some generic modifications and > improvements into generic HID layer and generic input layer all worked well. > Only joystick layer got to be completely rewritten. > > I did never put this upstream because by the time I got my own patches > integrated to the (new) kernel, the hid/input layer had developed so much that > the patches could no more be used in the latest kernel. So I hand applied them > again, and again kernel had moved on, and so on. Also to argue for patches > that cover several areas and several maintainers is difficult, and changing a > lot at once is always risky. So I gave up. > > If anyone is interested, I could take a look again and see if the changes > could be argued and applied incrementally instead of one big bunch. Hi Pekka, yes, we are definitely interested (or at least I am). The major rewrite of the HID core to be full-fledged bus was done exactly so that it's easier to add support for new devices, while keeping the main code clean. Even if you have problems porting the drivers to new infrastructure, you can always post wha you have -- I believe that we will be able to sort it out quickly. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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
TM6000 Driver building
Hi all, Pardon my green-ness to the whole process of the v4l-dvb and would like some pointers on how to build the TM6000 components of the drivers in v4l/ directtory I edited the .config to enable the TM6000_DVB=m clause and rebuilt.. but lo and behold there were still no modules built.. I am trying to hack on the WinTV-NOVA-S USB2 device and register it as a Generic TM6000 to start my porting. Is there a special branch or a quick 'howto' so I can enable this module Any help would be greatly appreciated. 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: Any saa711x users out there?
Hi Andy, Thanks for taking the time to do some testing in your environment. On Sun, Feb 7, 2010 at 7:10 PM, Andy Walls wrote: > My observations: > > 1. With the amplifier on and anti-alias filter off things looked fine. > 2. With the amplifier on and anti-alias filter on things looked fine. > 3. With the amplifier off and anti-alias filter off things looked fine. > 4. With the amplifier off and anti-alias filter on the screen washed > brighter/whiter. > > I guess the anti-alias filter peaks the luma a little or attenuates the color > a little. > The amplifier and AGC is probably essential when using the anti-alias filter. This all looks like good news, suggesting that under most conditions people won't notice the difference (except in the signal conditions I saw, in which case they will see a rather significant positive improvement). And since we don't let users independently control the AA filter nor the amplifier, we can be confident that there won't be a case when the amplifier is on but the AA filter is off. My vote is to just push the one line change then flipping on the AA filter in the saa7115_init_misc array of registers (essentially the patch below): http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/42272c1dd883 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
Requested feedback on V4L2 driver design
All, Texas Instruments (TI) is working on the design for the V4L2 capture and display drivers for our next generation system-on-chip (SoC) processor and would like to solicit your feedback. Our new SoCs have been improved to allow for higher video resolutions and greater frame rates. To this end the display hardware has been moved to a separate processing block called the video processing subsystem (VPSS). The VPSS will be running a firmware image that controls the capture/display hardware and services requests from one or more host processors. Moving to a remote processor for the processing of video input and output data requires that commands to control the hardware be passed to this processing block using some form of inter-processor communication (IPC). TI would like to solicit your feedback on proposal for the V4L2 driver design to get a feel for whether or not this design would be accepted into the Linux kernel. To this end we have put together an overview of the design and usage on our wiki at http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Design. We would greatly appreciate feedback from community members on the acceptability of our driver design. If you have additional questions or need more information please feel free to contact us (we have setup a mailing list at vpss_driver_des...@list.ti.com) so we can answer them. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.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: where I can get UVC svn repository
Hi, linuxtv uses mercurial (or git) not svn, please check the how-to: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers regards, Paulo 2010/2/8 loody : > Dear all: > I hear UVC is change its repository to linxutv. > But I tried several possible repositories like > svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/tags > svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/rev/75c97b2d1a2a > > But svn says the repository is incorrect. > Would anyone tell me where is the correct location? > appreciate your help, > miloody > -- > 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/RESEND] soc-camera: add runtime pm support for subdevices
Hi Mauro Thanks for your comments. On Mon, 8 Feb 2010, Mauro Carvalho Chehab wrote: > Guennadi Liakhovetski wrote: > > To save power soc-camera powers subdevices down, when they are not in use, > > if this is supported by the platform. However, the V4L standard dictates, > > that video nodes shall preserve configuration between uses. This requires > > runtime power management, which is implemented by this patch. It allows > > subdevice drivers to specify their runtime power-management methods, by > > assigning a type to the video device. > > It seems a great idea to me. For sure we need some sort of power management > control. Agree;) > > Signed-off-by: Guennadi Liakhovetski > > --- > > > > I've posted this patch to linux-media earlier, but I'd also like to get > > comments on linux-pm, sorry to linux-media falks for a duplicate. To > > explain a bit - soc_camera.c is a management module, that binds video > > interfaces on SoCs and sensor drivers. The calls, that I am adding to > > soc_camera.c shall save and restore sensor registers before they are > > powered down and after they are powered up. > > > > diff --git a/drivers/media/video/soc_camera.c > > b/drivers/media/video/soc_camera.c > > index 6b3fbcc..53201f3 100644 > > --- a/drivers/media/video/soc_camera.c > > +++ b/drivers/media/video/soc_camera.c > > @@ -24,6 +24,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > Hmm... wouldn't it be better to enable it at the subsystem level? We may for > example call ? > The subsystem can call vidioc_streamoff() at suspend and vidioc_streamon() at > resume, if the device were streaming during suspend. We may add another ops to > the struct for the drivers/subdrivers that needs additional care. > > That's said, it shouldn't be hard to implement some routine that will > save/restore > all registers if the device goes to power down mode. Unfortunately, very few > devices successfully recovers from hibernation if streaming. One good example > is saa7134, that even disables/re-enables IR IRQ's during suspend/resume. To clarify a bit - this patch implements not static PM, but dynamic (runtime) power-management. In this case it means, we are trying to save power while the system is running, but we know, that the sensor is not needed. Specifically, as long as no application is holding the video device open. And this information is only available at the bridge driver (soc-camera core) level - there is no subdev operation for open and close calls, so, subdevices do not "know" whether they are in use or not. So, only saving / restoring registers when streaming is not enough. Static PM will also be interesting - as it has been mentioned before, we will have to be careful, because sensors "sit" on two busses - i2c and video. So, you have to resume after both are up and suspend before the first of them goes down... So, that will be a different exciting topic;) 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
where I can get UVC svn repository
Dear all: I hear UVC is change its repository to linxutv. But I tried several possible repositories like svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/tags svn co http://linuxtv.org/hg/~pinchartl/uvcvideo/rev/75c97b2d1a2a But svn says the repository is incorrect. Would anyone tell me where is the correct location? appreciate your help, miloody -- 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] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Am Montag, den 08.02.2010, 13:24 +0100 schrieb Andreas Oberritter: > Hello Mauro, > > Mauro Carvalho Chehab wrote: > > Good catch, but it seems better to initialize both the mutex and the list > > head > > at dvb_dmx_dev_init. Please test if the following patch fixes the issue. If > > so, please > > sign. > > please apply Francesco's original patch. Yours won't work, because > "feed" is a union. It must be initialized each time DMX_SET_PES_FILTER > gets called, because the memory might have been overwritten by a > previous call to DMX_SET_FILTER, which uses "feed.sec". > > Regards, > Andreas Now if I were a cynical or ranter or another kind of dumb primitive persona non grata I would just add "Lol" or stuff like that and turn myself away. But this is no fun here. It's nothing but a big proof that one Brazilian person in Mr. Torvalds "dream team of untouchables" needs to be URGENTLY replaced by another real capable person. NO IDEA ABOUT DVB ISSUES, BUT DVB MAINTAINER! This is a SCANDAL, not fun! This is SCANDALOUS! 1. When you start to complain then this moron asks you why you are so late. 2. Instead of organizing or really trying to win people with the necessary skills he starts dumbest silliest thinkable flame wars with people who are not 100 % conform with him. Thus he does not stop the bleeding and runaway processes of real interested persons who are urgently needed. On the contrary he accelerates those processes. 3. When the situation was in balance and no help was in sight I decided to organize help from far outside the list. I was lucky finding Francesco Lavra. If there hadn't been him, endless effectless ranting would still be the way to go, and the kernel regression of a stable kernel would persist (!). In this situation our Brazilian counterproductive seat farter starts to demotivate you by: "It's too late to write compat levels now, we're too late in the release circle and blablablabla Blubblubblubblub. Blather blather blather blather. 4. Before the decisive patch was there our completely incapable Brazilian spurked out some completely ineffective and silly pseudo-patches who for each did not even touch the problem. Thus he did de facto nothing than stealing my time, attacking my humble nerves. The rule of our Brazilian: Even if I am a moron knowing absolutely nothing I must PRETEND some brainless activism. So show is everything, while manpower is being chased away. Competitive manpower is dangerous for the Brazilian pretender. 5. And when the decisive patch is there he wastes it for a reason that only he knows. Thanks to Andreas we all know now. That is exactly what he did with Markus Rechbergers contributions: He broke them by transforming them in a definitely unqualified manner. Until Markus ran away. With the effect that the Empia stuff is being hosted elsewhere now. Mauro Carvalho Chehab's behaviour and policy is so goddamn dumb, ineffective, destructive, . It is a secure way to put a project finally over the edge which has got real structural problems I want him to be replaced as soon as possible by a real fair, qualified and capable person. Every second that one tolerates Mauro Carvalho Chehab as a common V4l / DVB maintainer is a second of pain and catastrophe. I vote for Andy Walls, Devin Heitmueller. There are a couple of capable candidates here who can really do that job with a better output for the whole Linux community. There is ABSOLUTELY NO necessity to continue with Mauro Carvalho Chehab. I cced all relevant persons. I want Chehab away from here! It's enough now. My tolerance is at zero. PERIOD! CS P. S.: If the RedHat company can afford people like MCC then there is something wrong with the internal structures of RedHat. -- 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/RESEND] soc-camera: add runtime pm support for subdevices
Guennadi Liakhovetski wrote: > To save power soc-camera powers subdevices down, when they are not in use, > if this is supported by the platform. However, the V4L standard dictates, > that video nodes shall preserve configuration between uses. This requires > runtime power management, which is implemented by this patch. It allows > subdevice drivers to specify their runtime power-management methods, by > assigning a type to the video device. It seems a great idea to me. For sure we need some sort of power management control. > > Signed-off-by: Guennadi Liakhovetski > --- > > I've posted this patch to linux-media earlier, but I'd also like to get > comments on linux-pm, sorry to linux-media falks for a duplicate. To > explain a bit - soc_camera.c is a management module, that binds video > interfaces on SoCs and sensor drivers. The calls, that I am adding to > soc_camera.c shall save and restore sensor registers before they are > powered down and after they are powered up. > > diff --git a/drivers/media/video/soc_camera.c > b/drivers/media/video/soc_camera.c > index 6b3fbcc..53201f3 100644 > --- a/drivers/media/video/soc_camera.c > +++ b/drivers/media/video/soc_camera.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > #include Hmm... wouldn't it be better to enable it at the subsystem level? We may for example call ? The subsystem can call vidioc_streamoff() at suspend and vidioc_streamon() at resume, if the device were streaming during suspend. We may add another ops to the struct for the drivers/subdrivers that needs additional care. That's said, it shouldn't be hard to implement some routine that will save/restore all registers if the device goes to power down mode. Unfortunately, very few devices successfully recovers from hibernation if streaming. One good example is saa7134, that even disables/re-enables IR IRQ's during suspend/resume. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch] Kworld 315U remote support
Franklin Meng wrote:
> This patch adds remote support for the Kworld 315U device
>
> Note: I believe I got most of the mappings correct. Though the
> source and shutdown button probably could be mapped to something
> better.
>
> To be done: Still need to get the Kworld analog patch resubmitted.
> There are still some stuff I want to test with the analog patch before
> I resubmit it. Hopefully this patch will work ok.
>
> Please let me know if there are any issues applying the patch
Hi Franklin,
Could you please add a table with the full scan code?
There are currently two examples of such tables:
ir_codes_rc5_hauppauge_new_table - for RC5 keycodes
ir_codes_nec_terratec_cinergy_xs_table - for NEC keycodes
Basically, a full scan code has a 2-byte code instead of 1-byte,
and you need to specify the protocol at the table, like:
struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table = {
.scan = ir_codes_nec_terratec_cinergy_xs,
.size = ARRAY_SIZE(ir_codes_nec_terratec_cinergy_xs),
.ir_type = IR_TYPE_NEC,
};
The em28xx is already prepared to properly handle the protocol.
the advantage of using a full table is that it is easy to replace
the keytable and even the protocol if someone wants to use a different
Remote Controller to control the device.
As you've declared this xclk:
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
I suspect that your keycode is of the type NEC.
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: [SAA7134, REQUEST] slow register writing
On Mon, 2010-02-08 at 08:59 +0100, Hans Verkuil wrote:
> On Monday 08 February 2010 08:20:14 Dmitri Belimov wrote:
> > Hi All.
> >
> > I wrote SPI bitbang master over GPIO of saa7134. Speed of writing is much
> > slow then in a Windows systems.
> > I make some tests:
> >
> > Windows, SPI bitbang 97002 bytes x 2 time of writing is around 1.2 seconds
> > Linux, SPI bitbang with call saa7134_set_gpio time of writing is 18 seconds
> > Linux, SPI bitbang without call saa7134_set_gpio time of writing is
> > 0.25seconds.
> >
> > The overhead of SPI subsystem is 0.25 seconds. Writing speed to registers
> > of the saa7134
> > to slow.
> >
> > What you think about it?
>
> Internally the spi subsystem uses delays based on some nsecs parameter. I see
> some
> interesting code in spi_bitbang.h under #ifdef EXPAND_BITBANG_TXRX. My guess
> is
> that you use the default timings from the spi subsystem that are too high for
> this
> card.
>
> Try to discover what timings are currently in use and see if they match the
> hardware spec. If not, then you should figure out how to optimize that.
Dmitri,
When looking for timing problems in the kernel, I found the tracing
facility to be very useful.
Using tracing on the ivtv driver, I found that
ivtv-mailbox.c:ivtv_api_get_data() is a simple function being
simply inefficient. It's consuming about half the time used in
the ivtv_rq_handler() mostly doing uneeded PCI MMIO.
Here's a typical example where ivtv_api_get_data() takes over half of
the total execution time of the ivtv_irq_handler():
1) | ivtv_irq_handler() {
1) + 53.471 us |ivtv_api_get_data();
1) |stream_enc_dma_append() {
1) | ivtv_queue_move() {
1) 1.064 us|ivtv_queue_move_buf();
1) 2.943 us| }
1) 0.824 us| pci_dma_sync_single_for_device();
1) + 15.472 us |}
1) |ivtv_dma_enc_start() {
1) | ivtv_queue_move() {
1) 0.894 us|ivtv_queue_move_buf();
1) 2.730 us| }
1) | ivtv_dma_enc_start_xfer() {
1) 0.845 us|pci_dma_sync_single_for_device();
1) 7.282 us| }
1) + 13.088 us |}
1) + 91.243 us | }
And another example:
1) | ivtv_irq_handler() {
1) + 41.701 us |ivtv_api_get_data();
1) 0.884 us|pci_dma_sync_single_for_cpu();
1) |dma_post() {
1) 1.514 us| pci_dma_sync_single_for_cpu();
1) | ivtv_queue_move() {
1) 0.881 us|ivtv_queue_move_buf();
1) 2.879 us| }
1) + 12.360 us |}
1) + 64.144 us | }
Here's how I set up this sort of tracing on my Fedora 12 machine, in
case you wish to try something similar:
1. Set up access to the kernel tracer
$ su - root
# mount
# ls -al /sys/kernel/debug/
# mount -t debugfs debug /sys/kernel/debug/
# mount
# less /sys/kernel/debug/tracing/README
2. Enable dynamic function tracing
# cat /proc/sys/kernel/ftrace_enabled
# echo 1 > /proc/sys/kernel/ftrace_enabled
# cat /sys/kernel/debug/tracing/available_filter_functions
3. Perform a function_graph trace of the ivtv.ko module functions except
the I2C bus calls
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# echo 0 > /sys/kernel/debug/tracing/options/latency-format
# echo 0 > /sys/kernel/debug/tracing/options/verbose
# echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
# echo > /sys/kernel/debug/tracing/set_ftrace_filter
# nm --defined-only /lib/modules/`uname
-r`/kernel/drivers/media/video/ivtv/ivtv.ko | \
grep ' [Tt] ' | grep -v trace | grep -v 'ivtv_[sg]ets[cd][al]' | \
grep -v map_single | awk '{print $3}' >
/sys/kernel/debug/tracing/set_ftrace_filter
# echo 1 > /sys/kernel/debug/tracing/tracing_enabled
(perform 'cat /dev/video0 > foo.mpg' in another window for a bit)
# echo 0 > /sys/kernel/debug/tracing/tracing_enabled
# cat /sys/kernel/debug/tracing/trace > t1.txt
# less t1.txt
4. Perform a function latency trace of the ivtv.ko module functions
except for I2C bus calls
# echo function > /sys/kernel/debug/tracing/current_tracer
# echo 1 > /sys/kernel/debug/tracing/options/latency-format
# echo 1 > /sys/kernel/debug/tracing/options/verbose
# echo 0 > /sys/kernel/debug/tracing/tracing_max_latency
# echo > /sys/kernel/debug/tracing/set_ftrace_filter
# nm --defined-only /lib/modules/`uname
-r`/kernel/drivers/media/video/ivtv/ivtv.ko | \
grep ' [Tt] ' | grep -v trace | grep -v 'ivtv_[sg]ets[cd][al]' | \
grep -v map_single | awk '{print $3}' >
/sys/kernel/debug/tracing/set_ftrace_filter
# echo 1 > /sys/kernel/debug/tracing/tracing_enabled
(perform 'cat /dev/video0 > foo.mpg' in another window for a bit)
# echo 0 > /sys/kernel/debug/tracing/tracing_enabled
# cat /sys/kernel/debug/tracing/trace > t2.txt
# less t2.txt
Hopefully that can help you set up an experiment to find your timing
Re: [PATCH] dvb-core: fix initialization of feeds list in demux filter
Hello Mauro, Mauro Carvalho Chehab wrote: > Good catch, but it seems better to initialize both the mutex and the list head > at dvb_dmx_dev_init. Please test if the following patch fixes the issue. If > so, please > sign. please apply Francesco's original patch. Yours won't work, because "feed" is a union. It must be initialized each time DMX_SET_PES_FILTER gets called, because the memory might have been overwritten by a previous call to DMX_SET_FILTER, which uses "feed.sec". Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Mauro Carvalho Chehab wrote: >> +tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, buf, 2); > Most of the calls there are read (0xc0). I don't know any device that requires > a read for it to work. I suspect that the above code is just probing to check > what i2c devices are found at the board. Btw, by looking at drivers/media/dvb/frontends/zl10353_priv.h, we have an idea on what the above does: The register 0x7f is: CHIP_ID= 0x7F, So, basically, the above code is reading the ID of the chip, likely to be sure that it is a Zarlink 10353. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
>
> Signed-off-by: Stefan Ringel
> ---
> drivers/media/common/tuners/tuner-xc2028.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
> b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..fcf19cc 100644
> --- a/drivers/media/common/tuners/tuner-xc2028.c
> +++ b/drivers/media/common/tuners/tuner-xc2028.c
> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>
> /* All S-code tables need a 200kHz shift */
> if (priv->ctrl.demod) {
> - demod = priv->ctrl.demod + 200;
> + if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) &&
> + (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
> + ((type & DTV78) || (type & DTV8)))
> + demod = priv->ctrl.demod;
> + else
> + demod = priv->ctrl.demod + 200;
> /*
>* The DTV7 S-code table needs a 700 kHz shift.
>* Thanks to Terry Wu for reporting this
The idea behind this patch is right, but you should be testing it against
priv->firm_version, instead comparing with a file name.
Also, this will likely cause regressions on other drivers, since the offsets for
v3.6 firmwares were handled on a different way on other drivers. I prefer to
postpone
this patch and the discussion behind it after having tm6000 driver ready, since
it makes no sense to cause regressions or request changes on existing drivers
due
to a driver that is not ready yet.
So, please hold your patch on your queue for now.
My suggestion is that you should use git and have this patch on a separate
branch where you
do your tests, having a branch without this patch for upstream submission.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/12] tm6000: tuner reset timeing optimation
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
>
> Signed-off-by: Stefan Ringel
> ---
> drivers/staging/tm6000/tm6000-cards.c | 11 +++
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/tm6000/tm6000-cards.c
> b/drivers/staging/tm6000/tm6000-cards.c
> index 1167b01..5cf5d58 100644
> --- a/drivers/staging/tm6000/tm6000-cards.c
> +++ b/drivers/staging/tm6000/tm6000-cards.c
> @@ -271,11 +271,14 @@ static int tm6000_tuner_callback(void *ptr, int
> component, int command, int arg)
> switch (arg) {
> case 0:
> tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
> + dev->tuner_reset_gpio, 0x01);
> + msleep(60);
> + tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
> dev->tuner_reset_gpio, 0x00);
> - msleep(130);
> + msleep(75);
> tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
> dev->tuner_reset_gpio, 0x01);
> - msleep(130);
> + msleep(60);
> break;
> case 1:
> tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT,
> @@ -288,10 +291,10 @@ static int tm6000_tuner_callback(void *ptr, int
> component, int command, int arg)
> TM6000_GPIO_CLK, 0);
> if (rc<0)
> return rc;
> - msleep(100);
> + msleep(10);
> rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
> TM6000_GPIO_CLK, 1);
> - msleep(100);
> + msleep(10);
> break;
> }
> }
This sequence and the timeouts are board-specific. Please add a
switch(dev->model) and
test for your specific board, since your sequence will break for example
10moons, where
you really need a longer delay to work.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/12] tm6000: update init table and sequence for tm6010
Hi Stefan,
First, a few comments about your patch series:
I've committed almost of your patches, and added an extra patch to make the
driver to compile it with -git. There were other broken things when compiling
against -git.
Several of your patches are adding leading whitespaces. Please review them
before
submitting. On -git, those whitespaces are shown with a red background color.
I've re-made most of the patch descriptions. Please take a look on them and try
to improve on a next time.
We've got 2 submission for each patches. I just discarded the older one.
I've removed the two BEHOLDER board descriptions from one of your patches. It is
not related to your board, but it is another compilation fix.
>From your series, I didn't merge those 3 patches:
[5/12] tm6000: update init table and sequence for tm6010
http://patchwork.kernel.org/patch/77451
[6/12] tm6000: tuner reset timeing optimation
http://patchwork.kernel.org/patch/77459
[11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and
http://patchwork.kernel.org/patch/77462
I'll send you separate comments why I didn't merge them, in reply to each email
you've sent,
starting with this one (patch 5/12).
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
>
> ---
> drivers/staging/tm6000/tm6000-core.c | 179
> --
> 1 files changed, 128 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/staging/tm6000/tm6000-core.c
> b/drivers/staging/tm6000/tm6000-core.c
> index 7ec13d5..a2e2af5 100644
> --- a/drivers/staging/tm6000/tm6000-core.c
> +++ b/drivers/staging/tm6000/tm6000-core.c
> @@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
> { REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
>
> { REQ_05_SET_GET_USBREG, 0x18, 0x00 },
> -
> +
> + /* additional from Terratec Cinergy Hybrid XE */
> + { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
> + { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
> + { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
> + { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
> + { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
> + { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
> +
> /* set remote wakeup key:any key wakeup */
> { REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
> { REQ_07_SET_GET_AVREG, 0xda, 0xff },
> @@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
> {
> int board, rc=0, i, size;
> struct reg_init *tab;
> + u8 buf[40];
>
> if (dev->dev_type == TM6010) {
> tab = tm6010_init_tab;
> @@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
> }
> }
>
> - msleep(5); /* Just to be conservative */
> -
> - /* Check board version - maybe 10Moons specific */
> - board=tm6000_get_reg16 (dev, 0x40, 0, 0);
> - if (board >=0) {
> - printk (KERN_INFO "Board version = 0x%04x\n",board);
> - } else {
> - printk (KERN_ERR "Error %i while retrieving board
> version\n",board);
> - }
> -
> + /* hack */
> if (dev->dev_type == TM6010) {
> - /* Turn xceive 3028 on */
> - tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3,
> 0x01);
> - msleep(11);
> - }
The above is board-specific. It is needed for the tm6010 device I have here
(HVR900H), otherwise no xc3028 command will be handled.
The better here is to add a setup routine to tm6000-cards and move all
those GPIO codes to it. Then, add there your board-specific setup.
I've added a patch that moves those GPIO board-specific setup to tm6000-cards:
tm6000_cards_setup(). Please move your board specific GPIO init to there.
> -
> - /* Reset GPIO1 and GPIO4. */
> - for (i=0; i< 2; i++) {
> - rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> - dev->tuner_reset_gpio, 0x00);
> - if (rc<0) {
> - printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
> - return rc;
> - }
> -
> - msleep(10); /* Just to be conservative */
> - rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
> - dev->tuner_reset_gpio, 0x01);
> - if (rc<0) {
> - printk (KERN_ERR "Error %i doing GPIO1 reset\n",rc);
> - return rc;
> - }
> -
> - msleep(10);
> - rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
> 0);
> - if (rc<0) {
> - printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
> - return rc;
> - }
> -
> - msleep(10);
> - rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
> 1);
> - if (rc<0) {
> - printk (KERN_ERR "Error %i doing GPIO4 reset\n",rc);
> - return rc;
> - }
> -
> - if (!i) {
> -
[PATCH/RESEND] soc-camera: add runtime pm support for subdevices
To save power soc-camera powers subdevices down, when they are not in use,
if this is supported by the platform. However, the V4L standard dictates,
that video nodes shall preserve configuration between uses. This requires
runtime power management, which is implemented by this patch. It allows
subdevice drivers to specify their runtime power-management methods, by
assigning a type to the video device.
Signed-off-by: Guennadi Liakhovetski
---
I've posted this patch to linux-media earlier, but I'd also like to get
comments on linux-pm, sorry to linux-media falks for a duplicate. To
explain a bit - soc_camera.c is a management module, that binds video
interfaces on SoCs and sensor drivers. The calls, that I am adding to
soc_camera.c shall save and restore sensor registers before they are
powered down and after they are powered up.
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 6b3fbcc..53201f3 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -387,6 +388,11 @@ static int soc_camera_open(struct file *file)
goto eiciadd;
}
+ pm_runtime_enable(&icd->vdev->dev);
+ ret = pm_runtime_resume(&icd->vdev->dev);
+ if (ret < 0 && ret != -ENOSYS)
+ goto eresume;
+
/*
* Try to configure with default parameters. Notice: this is the
* very first open, so, we cannot race against other calls,
@@ -408,10 +414,12 @@ static int soc_camera_open(struct file *file)
return 0;
/*
-* First five errors are entered with the .video_lock held
+* First four errors are entered with the .video_lock held
* and use_count == 1
*/
esfmt:
+ pm_runtime_disable(&icd->vdev->dev);
+eresume:
ici->ops->remove(icd);
eiciadd:
if (icl->power)
@@ -436,7 +444,11 @@ static int soc_camera_close(struct file *file)
if (!icd->use_count) {
struct soc_camera_link *icl = to_soc_camera_link(icd);
+ pm_runtime_suspend(&icd->vdev->dev);
+ pm_runtime_disable(&icd->vdev->dev);
+
ici->ops->remove(icd);
+
if (icl->power)
icl->power(icd->pdev, 0);
}
@@ -1294,6 +1306,7 @@ static int video_dev_create(struct soc_camera_device *icd)
*/
static int soc_camera_video_start(struct soc_camera_device *icd)
{
+ struct device_type *type = icd->vdev->dev.type;
int ret;
if (!icd->dev.parent)
@@ -1310,6 +1323,9 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
return ret;
}
+ /* Restore device type, possibly set by the subdevice driver */
+ icd->vdev->dev.type = type;
+
return 0;
}
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index dcc5b86..58b39a9 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -282,4 +282,12 @@ static inline void soc_camera_limit_side(unsigned int
*start,
extern unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
unsigned long flags);
+/* This is only temporary here - until v4l2-subdev begins to link to
video_device */
+#include
+static inline struct video_device *soc_camera_i2c_to_vdev(struct i2c_client
*client)
+{
+ struct soc_camera_device *icd = client->dev.platform_data;
+ return icd->vdev;
+}
+
#endif
--
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
