Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Em Wed, 19 Aug 2009 10:32:07 -0500 "Karicheri, Muralidharan" escreveu: > Mauro, > > Kevin has approved the architecture part of this patch. When can I expect > these to be merged to linux-next? > > Thanks. > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > email: m-kariche...@ti.com > > >-Original Message- > >From: Karicheri, Muralidharan > >Sent: Tuesday, August 18, 2009 5:51 PM > >To: 'Mauro Carvalho Chehab' > >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- > >sou...@linux.davincidsp.com; khil...@deeprootsystems.com; Hans Verkuil > >Subject: RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif > >capture driver > > > >Mauro, > > > >Here are the patches from Chaithrika that I am referring to. > >http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html There's something wrong with this patch: $ patch -p1 -i 12453a.patch patching file arch/arm/mach-davinci/board-dm646x-evm.c Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #1 succeeded at 52 (offset -11 lines). Hunk #2 succeeded at 218 with fuzz 1 (offset -70 lines). Hunk #3 succeeded at 286 with fuzz 2 (offset -14 lines). Hunk #4 FAILED at 293. Hunk #5 succeeded at 254 (offset -79 lines). 1 out of 5 hunks FAILED -- saving rejects to file arch/arm/mach-davinci/board-dm646x-evm.c.rej patching file arch/arm/mach-davinci/dm646x.c Hunk #1 succeeded at 40 with fuzz 2 (offset 8 lines). Hunk #2 succeeded at 550 with fuzz 1 (offset -145 lines). Hunk #3 succeeded at 866 with fuzz 1 (offset 12 lines). patching file arch/arm/mach-davinci/include/mach/dm646x.h Hunk #1 succeeded at 47 with fuzz 2 (offset 18 lines). It seems that this patch is not based on my linux-next -git tree. Probably, this patch is dependent on some patch at Kevin tree. Kevin, As this patch touches only arch/arm/ stuff, I suspect that we'll have less conflicts if you could merge this one. From my side: Acked-by: Mauro Carvalho Chehab > >http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html Hmm... the second patch shows that bisect will be broken with the platform changes. This patch should be fold with the one that renamed the field, or before Kconfig/Makefile changes. I've applied this one on my tree, just before the Kbuild patch. Due to the DaVinci dependency order, I'll need to hold the DaVinci patches at the next upstream window to happen after Russell/Kevin trees, to avoid bisect troubles 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: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
Am Dienstag, den 18.08.2009, 10:07 -0400 schrieb Devin Heitmueller: > On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbach wrote: > > I would be interested to know if someone _actually_ managed > > to break their hardware by using buggy drivers. > > The short answer is *absolutely*. > > /me takes off "driver developer hat" and puts on "hardware developer hat" > > In a world of flash, eeproms, and software programmable clocks, there > are all sorts of ways where a driver bug can damage the hardware. > Looking for some simple examples? > > 1. Think of the "overclocking" community and what happens when they > reconfigure a GPU's software controlled clock to perform beyond its > maximum expected rating without extra cooling. > > 2. Think of all the reports of corrupted eeproms you read about on > the mailing list. Sure, in many cases a good developer can hack a way > to reprogram the eeprom in software, but in many cases the board won't > even come up, so you end up with an RMA. It's not "damaged" in the > more traditional sense, but the net effect is the same - the board is > rendered inoperable and has to be sent back to the manufacturer. > > 3. Try loading the xc3028 tuner firmware onto the low power version > of the chip (xc3028l). It took me a minute before I realized the > smell of burning plastic was coming from my tuner. > > Don't get me wrong, in many cases things can be designed into the > hardware to mitigate the effects of software bugs. In any hardware > design, your goal is to minimize the return rate, so you build > failsafes for the most likely to occur problems. However, in many > cases this adds additional cost to the BOM, and you make educated > decisions about the probability of certain classes of failure and > instead build the reliability into the driver instead (making sure > that the Windows driver can *never* put the hardware into a state). A > random open source developer doesn't know what these sorts of > decisions were, and would not be able to replicate the corresponding > checks in a Linux driver. > > 4. Ever see a user complaint of how a tuner runs "hot" under Linux > compared to the same device running under Windows? Almost certainly > an improperly GPIO configuration which resulted in a condition such as > having the digital demod powered on at the same time as the analog > decoder. Sure, it will work for a while but you're running the device > outside of the expected thermal profile and shortening the life of the > hardware. > > The above are just a few *simple* examples. The nastier ones are > often too difficult to explain in less than fifty words. > > > IANAL but > > I think that consumer electronics hardware which can be damaged by > > software is broken by design. A vendor selling such hardware is > > stupid because people would return the broken hardware and get > > a replacement. I don't see how a vendor could proof that the device > > was not damaged by an obscure bug in the Windows driver to get > > around their responsibility to replace broken hardware within > > the warranty period. > > Yeah, you're right. Usually they cannot tell right away and will > perform an RMA. And the board will end up on a lab bench with a > hardware engineering isolating which component failed, and then > working with the driver developer trying to figure out how the hell > their Windows driver put the board in such a state. The risk of > trusting some random Linux developer's driver work is a reason why > some vendors don't want to support Linux. If I were a vendor, and I > endorsed a Linux driver written by someone without the appropriate > knowledge of the hardware, I could end up with large number of product > returns, and I would incur the cost of those losses. > > Also, in many cases the board doesn't burn out immediately. But > because of crappy drivers it takes three or four months to burn out, > and the result is a board that is designed to run without problems for > tens of thousands of hours dies in a significantly shorter time. > > Good device driver developers realize and accept this risk whenever > they attempt to write a reverse engineered driver. I certainly don't > want to discourage people from learning how to write Linux drivers for > tuners, but caveat emptor - you can end up permanently damaging your > hardware. > > Devin > Hi, again, both can be right. I don't deny the smell you had, what a crap on the other hand. But Johannes is right too. I did not manage to burn a single Philips device during the last seven years. And i did all the worst every single day ;) So, there might be still a slight difference ... Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] saa7134-input: don't probe for the Pinnacle remotes anymore
With the recent improvements we don't need to probe anymore, if we know
the i2c address of the receiver.
The address of the receiver for the remote with the gray buttons is not
confirmed anywhere, but it is very unlikely to see it on something else.
We want to have that information anyway.
BTW, those remaining still probing, please join.
Signed-off-by: hermann pitton
diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Sun Aug 16 21:53:17
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Thu Aug 20 00:56:31
2009 +0200
@@ -782,6 +782,7 @@
#else
init_data.get_key = get_key_pinnacle_color;
init_data.ir_codes = ir_codes_pinnacle_color;
+ info.addr = 0x47;
#endif
} else {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 30)
@@ -790,6 +791,7 @@
#else
init_data.get_key = get_key_pinnacle_grey;
init_data.ir_codes = ir_codes_pinnacle_grey;
+ info.addr = 0x47;
#endif
}
break;
diff -r 3f7e382dfae5 linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Sun Aug 16 21:53:17 2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Thu Aug 20 00:56:31 2009 +0200
@@ -782,6 +782,7 @@
#else
init_data.get_key = get_key_pinnacle_color;
init_data.ir_codes = ir_codes_pinnacle_color;
+ info.addr = 0x47;
#endif
} else {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 30)
@@ -790,6 +791,7 @@
#else
init_data.get_key = get_key_pinnacle_grey;
init_data.ir_codes = ir_codes_pinnacle_grey;
+ info.addr = 0x47;
#endif
}
break;
Re: [PATCH 3/5 - v3] DaVinci: platform changes to support vpfe camera capture
On Monday 17 August 2009, m-kariche...@ti.com wrote:
> static struct i2c_board_info dm355evm_i2c_info[] = {
> { I2C_BOARD_INFO("dm355evm_msp", 0x25),
> .platform_data = dm355evm_mmcsd_gpios,
> },
> + {
> + I2C_BOARD_INFO("PCA9543A", 0x73),
> + },
> /* { plus irq }, */
> /* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
> };
The DM355 EVM board has no PCA9543A I2C multiplexor
chip, so this is not a good approach to use. (*)
If I understand correctly you are configuring some
particular add-on board, which uses a chip like that.
There are at least two such boards today, yes? And
potentially more. Don't preclude (or complicate)
use of different boards...
The scalable approach is to have a file for each
daughtercard, and Kconfig options to enable the
support for those cards. The EVM board init code
might call a dm355evm_card_init() routine, and
provide a weak binding for it which would be
overridden by the
- Dave
(*) Separate issue: there's ongoing work to get the
I2C stack to support such chips in generic ways;
you should plan to use that work, which ISTR wasn't
too far from being mergeable.
--
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-next: suspend tree build warnings
On Wed, 2009-08-19 at 16:36 -0700, Greg KH wrote:
> On Wed, Aug 19, 2009 at 11:38:03PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday 19 August 2009, Stephen Rothwell wrote:
> > > Hi Rafael,
> >
> > Hi,
> >
> > > Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> > >
> > > drivers/media/dvb/frontends/dib7000p.c: In function
> > > ‘dib7000p_i2c_enumeration’:
> > > drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of
> > > 2256 bytes is larger than 2048 bytes
> > > drivers/media/dvb/frontends/dib3000mc.c: In function
> > > ‘dib3000mc_i2c_enumeration’:
> > > drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of
> > > 2160 bytes is larger than 2048 bytes
> > >
> > > Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM:
> > > Introduce core framework for run-time PM of I/O devices (rev. 17)").
> >
> > Well.
> >
> > This commit increases the size of struct device quite a bit and both of the
> > drivers above create a "state" object on the stack that contains struct
> > device
> > among other things.
>
> Ick. struct device should _never_ be on the stack, why would this code
> want to do such a thing?
It appears that the state object is a dummy being used to detect and
twiddle some identical chips on the i2c bus. The functions called only
use the "i2c_adapter" and "cfg" member of the dummy state object, but
those functions want that state object as an input argument.
The simplest fix is dynamic allocation of the dummy state object with
kmalloc() and then to free it before exiting the function.
Regards,
Andy
> 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-next: suspend tree build warnings
On Wed, Aug 19, 2009 at 11:38:03PM +0200, Rafael J. Wysocki wrote:
> On Wednesday 19 August 2009, Stephen Rothwell wrote:
> > Hi Rafael,
>
> Hi,
>
> > Today's linux-next build (x86_64 allmodconfig) produced these warnings:
> >
> > drivers/media/dvb/frontends/dib7000p.c: In function
> > ‘dib7000p_i2c_enumeration’:
> > drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of
> > 2256 bytes is larger than 2048 bytes
> > drivers/media/dvb/frontends/dib3000mc.c: In function
> > ‘dib3000mc_i2c_enumeration’:
> > drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of
> > 2160 bytes is larger than 2048 bytes
> >
> > Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM:
> > Introduce core framework for run-time PM of I/O devices (rev. 17)").
>
> Well.
>
> This commit increases the size of struct device quite a bit and both of the
> drivers above create a "state" object on the stack that contains struct device
> among other things.
Ick. struct device should _never_ be on the stack, why would this code
want to do such a thing?
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: help: Can't get DViCO FusionHDTV DVB-T Dual Digital 4 to work with new kernels
On Thu, 20 Aug 2009 06:50:25 +0800 treblid wrote: > On Wed, Aug 19, 2009 at 3:02 PM, Bob Hepple wrote: > > 2.6.27 worked for me - exact same board (ignoring revisions - mine is > > an older board, rev.1, I think) > Mine is rev 1 too, I think.. :p > > > 2.6.28 and up failed for me in exactly this manner. Same with a > > head-of-tree v4l-dvb 'hg clone' > > > > AFAICT it's a v4l-dvb driver problem - at least no-one here refutes it > > since I reported it here on 20090615. > cool at least I'm not alone.. is this error related to the IR > receiver? coz I noticed the IR receiver is detected for 1 tuner and > not the other. > I don't _think_ it's anything to do with the IR. Mind you, I don't use the IR at all (I prefer using a bluetooth mini-keyboard for mythTV - the IR remote provided with the DViCO doesn't have enough functions/buttons for me). Anne Aileus also confirmed the regression on 20090727 and offered to do some tests if someone could provide guidance. Haven't heard any more on that thread so far. Cheers Bob -- Bob Hepple ph: 07-5584-5908 Fx: 07-5575-9550 -- 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: Hauppauge 2250 - second tuner is only half working
On Wed, 2009-08-19 at 07:12 -0700, s...@cyberseth.com wrote: > >> I'd really appreciate any help or guidance on this problem as i'm fully > >> perplexed by it. > > > > Hey Seth, > > > > I ran the same tests on my cable system (channel 103) on 669Mhz and had no > > issue, and my snr's reported as (0x172 and 0x17c). > > > > One possibility is that you're overwhelming the frontend. Try adding a > > small > > mount of attenuation to the signal for test purposes. > > > > Hard to believe but this is where I'd start looking. > > > > -- > > Steven Toth - Kernel Labs > > http://www.kernellabs.com > > > > > > Thank you for reply! Hearing that the same frequency works on another > card is pretty positive confirmation in my mind that this is a > hardware/setup issue. I tried stopping by a local radio shack last night, > but wouldn't you know they no longer carried simple attenuators. Looks > like i'll be picking one up online (or maybe ill lookup a schematic online > and try building a simple one). You can build a bridged-T, they are pretty simple. Z 2 +/\/\/\---+ | | | Z Z | | 0 0| V ---+--/\/\/\--+--/\/\/\--+ V i | o > > Z > 1 | | | = = = Assuming that the source impedance and load impedance (not shown) are also Z0 (e.g. 75 ohms) then Z = a Z 1 0 Z 0 Z = -- 2 a V o 1 -- = - V 1 i1 + - a V o Power Gain in dB = 20 log V i So pick an attenuation that you want to achieve, and that tells you "a". "a" will tell you the resistor values you need. Then try and pick ones that are close. All this of course assumes I created and solved my system of equations without making an error. Regards, Andy > On a side note - Thank you very much for hacking on the saa7164 - other > than this frequency glitch its been working great for me! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca - ov534: Fix ov772x
The scan of the image packets of the sensor ov772x was broken when
the sensor ov965x was added.
[ Based on upstream c874f3aa, modified slightly for v2.6.30.5 ]
Signed-off-by: Jim Paris
Acked-by: Jean-Francois Moine
---
Hi,
Commit 84fbdf87ab8eaa4eaefb317a7eb437cd4d3d0ebf:
"V4L/DVB (11105): gspca - ov534: Adjust the packet scan function"
broke the gspca ov534 driver for the Playstation Eye in 2.6.30.
Commit c874f3aa7e66158dccb2b9f3cfc46c65af6c223d:
"V4L/DVB (11973): gspca - ov534: Do the ov772x work again."
fixed it for 2.6.31.
c874f3aa depends on earlier patches, so this is a functionally
equivalent version for 2.6.30.x. With this patch, the Playstation Eye
camera works again.
Please consider for 2.6.30.6.
Thanks,
-jim
drivers/media/video/gspca/ov534.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/gspca/ov534.c
b/drivers/media/video/gspca/ov534.c
index 19e0bc6..504f849 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -832,9 +832,11 @@ static void sd_pkt_scan(struct gspca_dev *gspca_dev,
struct gspca_frame *frame,
__u32 this_pts;
u16 this_fid;
int remaining_len = len;
+ int payload_len;
+ payload_len = (sd->sensor == SENSOR_OV772X) ? 2048 : 2040;
do {
- len = min(remaining_len, 2040); /*fixme: was 2048*/
+ len = min(remaining_len, payload_len);
/* Payloads are prefixed with a UVC-style header. We
consider a frame to start when the FID toggles, or the PTS
--
1.5.6.5
--
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: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 5:35 PM, Stefano De Dionigi wrote: > Hello Devin, > > I own a HVR-900 R2 and if you need help in testing i'd be more than > happy to help. > It's nice to see that for this device could there finally be light at > the end of the tunnel. Hello Dedioste, Fortunately, in this case I have the device pretty well tested using the generator. I just have to get the firmware extract script written so that the changes can actually be released. Keep an eye on the Kernellabs blog (http://www.kernellabs.com/blog), since when I have a tree setup I will likely put out a call for testers before the changes go upstream into the v4l-dvb mainline. 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: linux-next: suspend tree build warnings
On Wednesday 19 August 2009, Stephen Rothwell wrote:
> Hi Rafael,
Hi,
> Today's linux-next build (x86_64 allmodconfig) produced these warnings:
>
> drivers/media/dvb/frontends/dib7000p.c: In function
> ‘dib7000p_i2c_enumeration’:
> drivers/media/dvb/frontends/dib7000p.c:1315: warning: the frame size of 2256
> bytes is larger than 2048 bytes
> drivers/media/dvb/frontends/dib3000mc.c: In function
> ‘dib3000mc_i2c_enumeration’:
> drivers/media/dvb/frontends/dib3000mc.c:853: warning: the frame size of 2160
> bytes is larger than 2048 bytes
>
> Introduced by commit 99307958cc9c1b0b2e0dad4bbefdafaf9ac5a681 ("PM:
> Introduce core framework for run-time PM of I/O devices (rev. 17)").
Well.
This commit increases the size of struct device quite a bit and both of the
drivers above create a "state" object on the stack that contains struct device
among other things.
I think they should allocate these objects using kmalloc() and I don't know
what I can do about this, really. Maybe except for modifying the drivers to
use kmalloc().
Thanks,
Rafael
--
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: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 3:42 PM, Devin Heitmueller wrote: > On Wed, Aug 19, 2009 at 7:01 AM, Miguel wrote: >> >> Hello, >> >> I am trying to set up the dvb-t device in my ubuntu 9.04. >> As far as i can see , this device has tm6000 chipset but I don't get it >> works. I have followed the guide of tvlinux.org: >> http://www.linuxtv.org/wiki/index.php/Trident_TM6000#TM6000_based_Devices >> >> how can I get this device run? >> >> thank you in advance. >> >> Miguel > > Hello Miguel, > > Can you confirm the exact model number of the device (or provide the > USB ID)? I suspect you probably have what is often referred to as an > HVR-900 R2, which is not currently supported under Linux. > > I've got it working here but still need to write the firmware extract > script so I can release it, but the work has been delayed due to other > priorities. > Hello Devin, I own a HVR-900 R2 and if you need help in testing i'd be more than happy to help. It's nice to see that for this device could there finally be light at the end of the tunnel. -- Thank you, regards, dedioste -- 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 Cinergy C HD tuning problems
Hello, I'm having some problems with my Terratec Cinergy C PCI DVB-C card. I installed the mantis driver via DKMS, following the instructions at http://www.linuxtv.org/wiki/index.php/Mantis_with_DKMS The card is recognized, and it even works, but after a while (typically 5 to 20 minutes) the card no longer tunes to any channels and the scan command no longer works. If I modprobe -r and modprobe -i the mantis module everything works again for a while, until the same thing happens. So I assume this is something driver related? Any help would be appreciated, I will be happy to provide any additional information if needed. Some information that may or may not be useful: uname -a : Linux ss-home-server 2.6.28-14-server #47-Ubuntu SMP Sat Jul 25 02:03:55 UTC 2009 x86_64 GNU/Linux lsmod | grep mantis : mantis 53892 4 lnbp21 11008 1 mantis mb86a1630464 1 mantis stb610016388 1 mantis tda10021 15364 1 mantis tda10023 15748 1 mantis ir_common 65924 1 mantis stb089945060 1 mantis stv029919720 1 mantis dvb_core 111792 2 mantis,stv0299 dmesg (after reloading mantis module): [50413.810181] mantis_core_exit (0): DMA engine stopping [50413.810185] mantis_dma_exit (0): DMA=0x3794 cpu=0x88003794 size=65536 [50413.810191] mantis_dma_exit (0): RISC=0x37953000 cpu=0x880037953000 size=1000 [50413.810195] mantis_hif_exit (0): Adapter(0) Exiting Mantis Host Interface [50413.810200] mantis_ca_exit (0): Unregistering EN50221 device [50413.810712] mantis_pci_remove (0): Removing -->Mantis irq: 21, latency: 32 [50413.810714] memory: 0xd080, mmio: 0xc200101ce000 [50413.810729] Mantis :02:00.0: PCI INT A disabled [50414.116512] Mantis :02:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 [50414.117498] irq: 21, latency: 32 [50414.117499] memory: 0xd080, mmio: 0xc200104fe000 [50414.117502] found a VP-2040 PCI DVB-C device on (02:00.0), [50414.117504] Mantis Rev 1 [153b:1178], irq: 21, latency: 32 [50414.117507] memory: 0xd080, mmio: 0xc200104fe000 [50414.120219] MAC Address=[00:08:ca:1e:10:7a] [50414.120238] mantis_alloc_buffers (0): DMA=0x3794 cpu=0x88003794 size=65536 [50414.120245] mantis_alloc_buffers (0): RISC=0xb58a4000 cpu=0x8800b58a4000 size=1000 [50414.120248] DVB: registering new adapter (Mantis dvb adapter) [50414.670213] mantis_frontend_init (0): Probing for CU1216 (DVB-C) [50414.673722] TDA10023: i2c-addr = 0x0c, id = 0x7d [50414.673724] mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c [50414.673727] mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success [50414.673731] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... [50414.673789] mantis_ca_init (0): Registering EN50221 device [50414.673865] mantis_ca_init (0): Registered EN50221 device [50414.673874] mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface [50414.673934] input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input11 [50414.840123] Mantis VP-2040 IR Receiver: unknown key: key=0x00 raw=0x00 down=1 [50414.940104] Mantis VP-2040 IR Receiver: unknown key: key=0x00 raw=0x00 down=0 /var/log/syslog (when tuning stops working): kernel: [55125.206428] mantis start feed & dma kernel: [55125.206633] mantis stop feed and dma kernel: [55125.206641] mantis start feed & dma kernel: [55125.206719] mantis stop feed and dma kernel: [55125.206736] mantis start feed & dma vdr: [16282] frontend 0 lost lock on channel 80, tp 162 vdr: [16282] frontend 0 timed out while tuning to channel 80, tp 162 kernel: [55141.275154] mantis stop feed and dma vdr: [16282] frontend 0 timed out while tuning to channel 70, tp 234 kernel: [55168.360122] mantis_ack_wait (0): Slave RACK Fail ! vdr: [16282] frontend 0 timed out while tuning to channel 84, tp 242 vdr: [16282] frontend 0 timed out while tuning to channel 90, tp 250 kernel: [55202.040188] mantis_ack_wait (0): Slave RACK Fail ! Regards, Daniel Sjöblom PS. The repository I checked out from http://mercurial.intuxication.org/hg/s2-liplianin was (and still is) broken. A bad merge in v4l/Kconfig, lines 3164-3168. -- 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] cx23885: fix support for TBS 6920 card
fix: GPIO initialization for TBS 6920
fix: wrong I2C address for demod on TBS 6920
fix: wrong I2C bus number for demod on TBS 6920
fix: wrong "gen_ctrl_val" value for TS1 port on TBS 6920 (and some other cards)
add: module_param "lnb_pwr_ctrl" as option to choose between "type 0" and "type
1" of LNB power control (two TBS 6920 boards no matter that they are marked as
the same hardware revision may have different types of LNB power control)
fix: LNB power control function for type 0 doesn't preserve the previous GPIO
state, which is critical
add: LNB power control function for type 1
Signed-off-by: Bob Liu
Signed-off-by: Konstantin Dimitrov
--- a/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19
14:11:49.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19
14:30:10.0 +0300
@@ -704,7 +704,14 @@ void cx23885_gpio_setup(struct cx23885_d
case CX23885_BOARD_TEVII_S470:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
- cx_write(MC417_RWD, 0x1800);
+
+ cx_set(MC417_RWD, 0x0002);
+ mdelay(200);
+
+ cx_clear(MC417_RWD, 0x0800);
+ mdelay(200);
+ cx_set(MC417_RWD, 0x0800);
+ mdelay(200);
break;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
/* GPIO-0 INTA from CiMax1
@@ -880,7 +887,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_TBS_6920:
case CX23885_BOARD_DVBWORLD_2005:
- ts1->gen_ctrl_val = 0x5; /* Parallel */
+ ts1->gen_ctrl_val = 0x4; /* Parallel */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
--- a/linux/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19
14:11:49.0 +0300
+++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19
15:25:57.0 +0300
@@ -55,6 +55,7 @@
#include "netup-eeprom.h"
#include "netup-init.h"
#include "lgdt3305.h"
+#include "tbs_lnb_pwr.h"
static unsigned int debug;
@@ -71,6 +72,10 @@ MODULE_PARM_DESC(alt_tuner, "Enable alte
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+static unsigned int lnb_pwr_ctrl;
+module_param(lnb_pwr_ctrl, int, 0644);
+MODULE_PARM_DESC(lnb_pwr_ctrl,"set LNB power control 0=default type, 1=another
type");
+
/* -- */
static int dvb_buf_setup(struct videobuf_queue *q,
@@ -419,22 +424,31 @@ static struct stv6110_config netup_stv61
.clk_div = 1,
};
-static int tbs_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
+static int tbs6920_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
{
struct cx23885_tsport *port = fe->dvb->priv;
struct cx23885_dev *dev = port->dev;
- if (voltage == SEC_VOLTAGE_18)
- cx_write(MC417_RWD, 0x1e00);/* GPIO-13 high */
- else if (voltage == SEC_VOLTAGE_13)
- cx_write(MC417_RWD, 0x1a00);/* GPIO-13 low */
- else
- cx_write(MC417_RWD, 0x1800);/* GPIO-12 low */
+ switch (voltage) {
+ case SEC_VOLTAGE_13:
+ cx_set(MC417_RWD, 0x0200);
+ cx_clear(MC417_RWD, 0x0400);
+ break;
+ case SEC_VOLTAGE_18:
+ cx_set(MC417_RWD, 0x0200);
+ cx_set(MC417_RWD, 0x0400);
+ break;
+ case SEC_VOLTAGE_OFF:
+ cx_clear(MC417_RWD, 0x0200);
+ break;
+ }
+
return 0;
}
static struct cx24116_config tbs_cx24116_config = {
- .demod_address = 0x05,
+ .demod_address = 0x55,
};
static struct cx24116_config tevii_cx24116_config = {
@@ -768,14 +782,18 @@ static int dvb_register(struct cx23885_t
}
break;
case CX23885_BOARD_TBS_6920:
- i2c_bus = &dev->i2c_bus[0];
+ i2c_bus = &dev->i2c_bus[1];
fe0->dvb.frontend = dvb_attach(cx24116_attach,
&tbs_cx24116_config,
&i2c_bus->i2c_adap);
- if (fe0->dvb.frontend != NULL)
- fe0->dvb.frontend->ops.set_voltage = tbs_set_voltage;
-
+ if (fe0->dvb.frontend != NULL) {
+ if (!lnb_pwr_ctrl)
+ fe0->dvb.frontend->ops.set_voltage =
tbs6920_set_voltage;
+ else
+ fe0->dvb.frontend->ops.set_voltage =
tbs_set_voltage;
+ }
+
break;
case CX23885_BOARD_TEVII_S470:
i2c_bus = &dev->i2c_bus[1];
@@ -784,7 +802,7 @@ static int dvb_register(struct cx23885_t
Re: [linux-dvb] USB technotrend CT-3650
Hello Jens, I'm also looking into the CT-3650. I posted a few days back about the support for this device for dvb-c. Are you trying to get dvb-c working or dvb-t? Can anyone else answer if dvb-c is indeed working with current linux? Regards, Bert > Wed, Aug 19, 2009 at 8:01 PM, Jens Kjellerup wrote: > I am not a developer and my programming skills dates back to the late 1970's > where i programmed insurance applications i Cobol – so they are a bit rusty. > > I have been given a Technotrend connect CT-3650 CI device as a birthday > present for my myth server (don't ask for my age). I run Mythbuntu 9.04. > > I have searched for drivers to get the unit up and running but can't find > any. I have read: > http://osdir.com/ml/linux-media/2009-03/msg01137.html > http://www.mail-archive.com/linux-media@vger.kernel.org/msg08610.html > http://www.spinics.net/linux/lists/linux-dvb/msg27678.html > and several others, but i haven't found any workable solution. > > I have tried to follow the recipee on this device – a sister product for > dvb-s2 > http://linuxtv.org/wiki/index.php/TechnoTrend_TT-connect_S2-3650_CI > > Up until now i have found no way to get the device running. > I have compiled and installed the newest v4l repository with no further > luck. I have extracted the newest firmware from the latest BDA files on the > the Technotrend site www.tt-pc.de > > > Dmesg only shows that the usb bus is detecting a tehcnotrend device > Lsusb shows the same. > > Can anyone point me in a direction to get it working patches, drivers etc. > > Alternatively has the community all together given up on this device. > > Sorry for this ”non development” question but i don't know where else to > turn to. If someone would help me i could make the testing and documentation > for the linuxtv site. > > Thank you in advance > JK > > > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- - 38 is NOT a random number -- 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]remove unnecessary power management primitive in stk-webcam
This patch removes an unneeded power management primitive. Power management is automatically enabled as probe ends. Signed-off-by: Oliver Neukum Hi, please accept this patch for the next merge window, as this patch changes no functionality and removes a primitive that won't be supported in the new generic framework. Regards Oliver -- commit eeada72856087eb90e8649692b75e5b875ba051d Author: Oliver Neukum Date: Wed Aug 19 20:31:56 2009 +0200 usb: remove unneeded power management primitive diff --git a/drivers/media/video/stk-webcam.c b/drivers/media/video/stk-webcam.c index b154bd9..0b996ea 100644 --- a/drivers/media/video/stk-webcam.c +++ b/drivers/media/video/stk-webcam.c @@ -1400,7 +1400,6 @@ static int stk_camera_probe(struct usb_interface *interface, } stk_create_sysfs_files(&dev->vdev); - usb_autopm_enable(dev->interface); return 0; -- 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: DM6467 VPIF adding support for HD resolution capture and display standards
On Wednesday 19 August 2009 19:44:24 Karicheri, Muralidharan wrote:
> Hans,
>
> You have done a great job in putting up a quick proposal. I was just trying
> to understand the intentions/rational behind your proposal to be on the same
> page. Thanks for the education. I think this will help others as well.
You're welcome :-)
It's not complete though. Other things to consider are:
1) How to detect what format is received on e.g. an HDMI or DVI-A/D receiver?
I think we need a VIDIOC_QUERY_DV_PRESET. Either this returns the actual
preset, or it returns V4L2_DV_CUSTOM and you have to call
VIDIOC_QUERY_DV_TIMINGS to get the full timings, or it returns something like
V4L2_DV_NO_SIGNAL (no input signal) or V4L2_DV_UNKNOWN.
When querying the timings we have to realize that not all fields may be filled
in. E.g. when receiving an HDMI or DVI-D signal quite often you can only get
hold of the width and height of the image and some framerate information.
Timings like front porch etc. may no be possible to obtain.
2) How to specify timings when using embedded syncs? We probably have to add
a flag to toggle between embedded (SAV/EAV codes) or separate syncs (actually,
it is possible to do both at the same time). For the timings we can just set
the sync length and porch length to 0 since those are no longer relevant for
embedded syncs.
3) What is the relationship (if any) between these new ioctls and the old
G/S/QUERY/ENUM_STD and the ENUM_FRAMESIZES/FRAMEINTERVALS ioctls? To prevent
terminal confusion this should be made very clear in the v4l2 spec.
> >> > __u32 width, height;
> >> > __u32 polarities;
> >> Is it a bit mask of polarities such as vsync, hsync etc?
> >
> >Yes.
> Then we would need to define POLARITIES as bit mask for user space usage.
> like
>
> #define V4L2_DV_VSYNC_POL 0x1
> #define V4L2_DV_HSYNC_POL 0x2
>
> and so forth?
Yes.
> >> > /* timings for bottom frame for interlaced formats */
> >> > __u32 il_hfrontporch, il_hsync, il_htotal;
> >> > __u32 il_vfrontporch, il_vsync, il_vtotal;
> >> Looking at a typical vesa timing values, I don't see them defined
> >separately for top and bottom fields. Is it for BT1120/BT656 and camera
> >capture timing?
> >
> >Front porch, sync length and htotal can be removed, but I think il_vtotal
> >can
> >be different from vtotal by one line so we should keep that one.
> >
>
> I think it is safer to keep them and mark them as experimental?.
No, they definitely can be removed. I wasn't thinking when I added them.
It's only the il_vtotal that we need to keep.
>
> >>
> >> >enum dv_timings_type {
> >> > V4L2_DV_BT_656_1120,
> >> Why combine BT656 and BT1120? They have different set of timing values.
> >Also if custom timing to be allowed, shouldn't there be a type
> >> V4L2_CUSTOM_TIMING as one of the type. So only then bt_timings values
> >will be used.
> >
> >No. BT656 and BT1120 define how bitstreams for video are formatted. There
> >is
> >very little difference between the two. I would have to do research as to
> >what
> >exactly the differences are, but based on my experience so far I think
> >there
> >is no need to separate them.
> >Also note that both use the same timing parameters, so the custom settings
> >are
> >actually following the bt656/1120 timings.
>
> What I see from the VPIF hardware spec is that they use different values for
> first line of top/bottom field, first line of active video, last line of
> active video and so forth. That means timing parameters are different, right?
But these parameters can all be defined in terms of the timings parameters.
The question is: are there differences in the generated signal that are not
covered by the timing parameters. One thing that springs to mind is how the
sync signal is formed. I remember reading about two or three level syncs. We
may well need to either specify the sync format or let it depend on the timings
type. Note that you can also have syncs embedded in the data stream (not to
be confused with the SAV/EAV codes). This is used for component inputs/outputs
where a sync signal is carried in the Y data signal.
However, I think we have to be careful not to attempt to do too much here.
A certain amount of intelligence can be expected from a driver.
>
>
>
> >
> >>
> >> >};
> >> VPIF supports SMPTE 296 mode in which different timing values are used
> >than BT1120. So I see V4L2_DV_SMPTE_296 as well to begin with.
> >
> >Someone needs to put these standards next to one another and research what
> >the differences are and whether those differences are enough to require
> >adding a new type. Do you have access to those standards and can you go
> >through them and see what the differences are exactly and whether those
> >require adding a special type + associated timings struct?
> >
>
> I don't have access to the specs. But VPIF hardware manual says hardware use
> different values for first line of top/bottom field, first line of active
> video, last line of active vid
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Aug 19 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12458:3f7e382dfae5 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc5-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: OK linux-2.6.23.12-m32r: ERRORS linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DM6467 VPIF adding support for HD resolution capture and display standards
Hans,
You have done a great job in putting up a quick proposal. I was just trying to
understand the intentions/rational behind your proposal to be on the same page.
Thanks for the education. I think this will help others as well.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
>> Shouldn't this be in fractional form? how do we represent 74.25 MHz?
>
>We represent that as 7425 :-) The unit is in Hz.
>
>A more interesting question is if we should make this a u64 to be prepared
>for frequencies >4GHz. Or am I paranoid?
>
The highest pixel clock that I have seen for DaVinci platforms is 128MHz. So I
believe it will be a while before someone use > 4GHz :)
>> >__u32 width, height;
>> >__u32 polarities;
>> Is it a bit mask of polarities such as vsync, hsync etc?
>
>Yes.
Then we would need to define POLARITIES as bit mask for user space usage.
like
#define V4L2_DV_VSYNC_POL 0x1
#define V4L2_DV_HSYNC_POL 0x2
and so forth?
>
>> >/* timings for bottom frame for interlaced formats */
>> >__u32 il_hfrontporch, il_hsync, il_htotal;
>> >__u32 il_vfrontporch, il_vsync, il_vtotal;
>> Looking at a typical vesa timing values, I don't see them defined
>separately for top and bottom fields. Is it for BT1120/BT656 and camera
>capture timing?
>
>Front porch, sync length and htotal can be removed, but I think il_vtotal
>can
>be different from vtotal by one line so we should keep that one.
>
I think it is safer to keep them and mark them as experimental?.
>>
>> >enum dv_timings_type {
>> >V4L2_DV_BT_656_1120,
>> Why combine BT656 and BT1120? They have different set of timing values.
>Also if custom timing to be allowed, shouldn't there be a type
>> V4L2_CUSTOM_TIMING as one of the type. So only then bt_timings values
>will be used.
>
>No. BT656 and BT1120 define how bitstreams for video are formatted. There
>is
>very little difference between the two. I would have to do research as to
>what
>exactly the differences are, but based on my experience so far I think
>there
>is no need to separate them.
>Also note that both use the same timing parameters, so the custom settings
>are
>actually following the bt656/1120 timings.
What I see from the VPIF hardware spec is that they use different values for
first line of top/bottom field, first line of active video, last line of active
video and so forth. That means timing parameters are different, right?
>
>>
>> >};
>> VPIF supports SMPTE 296 mode in which different timing values are used
>than BT1120. So I see V4L2_DV_SMPTE_296 as well to begin with.
>
>Someone needs to put these standards next to one another and research what
>the differences are and whether those differences are enough to require
>adding a new type. Do you have access to those standards and can you go
>through them and see what the differences are exactly and whether those
>require adding a special type + associated timings struct?
>
I don't have access to the specs. But VPIF hardware manual says hardware use
different values for first line of top/bottom field, first line of active
video, last line of active video and so forth. i.e they are different for
BT656, BT1120, & SMPTE 296.
>> >
>> >struct dv_timings {
>> >enum dv_timings_type type;
>> >union {
>> >struct bt_timings bt;
>> >__u32 reserved[32];
>> >};
>> >};
>> >
>> >and ioctls:
>> >
>> >VIDIOC_S/G_DV_PRESET, VIDIOC_ENUM_DV_PRESETS and VIDIOC_S/G_DV_TIMINGS.
>> >
>> >I don't think we need to have ioctls to determine what custom timings
>> >are possible: if you are going to use that, then we can safely assume
>that
>> >you know what you are doing.
>> >
>> >There are some details to hammer out: what does G_DV_TIMINGS return if
>e.g.
>> >the 720P60 preset is active? Does it return the timings for 720P60 or
>the
>> >last
>>
>> >set custom timings?
>> Why last set custom timing? If preset is used, then it should return
>preset timing which mostly will be standard timing values as defined in the
>respective standard, right?
>
>My reasoning was that returning the preset timings would require that a
>driver
>will need to know those timings. For some hardware a programmer can just
>write
>a single 'standards' register and the hardware will do its own timings
>lookup.
>So in those cases a driver would need to keep a timings table around just
>for
>this API.
Make sense.
>
>It is also slightly cleaner since if a driver only supports presets, then
>there
>is no need for the DV_TIMINGS ioctls.
>
Agree.
>Remember, this is just an initial API proposal that's quickly put together.
>
>For one thing, for the presets we really want to put that in a struct:
>
>struct v4l2_dv_preset {
> __u32 preset;
> __u32 reserved[4];
>};
>
>And instead of an enum I would use a list of #defines for the preset IDs.
>
>Using enum makes compat32 conversion harder (I believe they have different
>sizes under 32 vs 64 bits).
Re: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 1:02 PM, Miguel wrote: > oh, what a shame, :-s > > The USB id is: > > Bus 001 Device 011: ID 2040:6600 Hauppauge > > > is this the version you commented that is not supported? Ah, ok. So you really do have an HVR-900H and not an HVR-900 (either R1 or R2). Since this is the case, your device really is TM6000 based, but that development tree has not been worked on in a very long time and is known to be broken. Unfortunately, it is not clear when/if Mauro will ever get back to getting that bridge to a supported state (it hasn't had any active development in over nine months). 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: Problem with Hauppauge Nova-500
On Wed, Aug 19, 2009 at 12:19 PM, Lou Otway wrote: > Hi there, > > I have a Hauppauge Nova-T 500 that is displaying some odd behaviour. > > Often the device fails to tune after rebooting the host machine, due to a > failure to load firmware. > > when the firmware fails to load, dmesg shows: > > dib0700: loaded with support for 9 different device-types > dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try > to load a firmware > dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' > dib0700: firmware download failed at 7 with -22 > usbcore: registered new interface driver dvb_usb_dib0700 > > When firmware loading is successful I see: > > dib0700: loaded with support for 9 different device-types > dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. > DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) > DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... > MT2060: successfully identified (IF1 = 1242) > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. > DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) > DVB: registering adapter 2 frontend 0 (DiBcom 3000MC/P)... > MT2060: successfully identified (IF1 = 1233) > input: IR-receiver inside an USB DVB receiver as /class/input/input7 > dvb-usb: schedule remote query interval to 50 msecs. > dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and > connected. > usbcore: registered new interface driver dvb_usb_dib0700 > > Powering down the host machine seems to help as, so far, I have 100% success > when restarting this way, whereas after reboot the success is much lower, > firmware failing to load maybe 50% of the time. > > Has anyone seen this behaviour before, any advice on what the cause might > be? > > Many thanks, > > Lou Hello Lou, Yes, this is a known issue with the Nova-T 500 that others have reported. We believe it has something to do with the onboard Via USB host controller on the board. A user mailed me a card and it is out being repaired, but hopefully when it comes back I will be able to track down the problem. 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
Problem with Hauppauge Nova-500
Hi there, I have a Hauppauge Nova-T 500 that is displaying some odd behaviour. Often the device fails to tune after rebooting the host machine, due to a failure to load firmware. when the firmware fails to load, dmesg shows: dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' dib0700: firmware download failed at 7 with -22 usbcore: registered new interface driver dvb_usb_dib0700 When firmware loading is successful I see: dib0700: loaded with support for 9 different device-types dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... MT2060: successfully identified (IF1 = 1242) dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering adapter 2 frontend 0 (DiBcom 3000MC/P)... MT2060: successfully identified (IF1 = 1233) input: IR-receiver inside an USB DVB receiver as /class/input/input7 dvb-usb: schedule remote query interval to 50 msecs. dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 Powering down the host machine seems to help as, so far, I have 100% success when restarting this way, whereas after reboot the success is much lower, firmware failing to load maybe 50% of the time. Has anyone seen this behaviour before, any advice on what the cause might be? Many thanks, Lou -- 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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Mauro, Kevin has approved the architecture part of this patch. When can I expect these to be merged to linux-next? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com >-Original Message- >From: Karicheri, Muralidharan >Sent: Tuesday, August 18, 2009 5:51 PM >To: 'Mauro Carvalho Chehab' >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- >sou...@linux.davincidsp.com; khil...@deeprootsystems.com; Hans Verkuil >Subject: RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >Mauro, > >Here are the patches from Chaithrika that I am referring to. >http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html >http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html > >Let me know once they are merged... > >Murali Karicheri >Software Design Engineer >Texas Instruments Inc. >Germantown, MD 20874 >new phone: 301-407-9583 >Old Phone : 301-515-3736 (will be deprecated) >email: m-kariche...@ti.com > >>-Original Message- >>From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] >>Sent: Tuesday, August 18, 2009 1:28 PM >>To: Karicheri, Muralidharan >>Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux- >open- >>sou...@linux.davincidsp.com; khil...@deeprootsystems.com; Hans Verkuil >>Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >>capture driver >> >>Em Tue, 18 Aug 2009 11:06:54 -0500 >>"Karicheri, Muralidharan" escreveu: >> >>> Mauro, >>> >>> I need to send a set of patches for adding vpif capture driver. >Currently >>the linux-next doesn't have the last patch from Chaithrika applied for >vpif >>display. Is it possible to apply this asap so that I can create the vpif >>capture patch today? >> >>Sure. Could you please point me what's the patchwork ID(s)[1] of the patch >>you need >>me to apply at our development tree and at linux-next? >> [1] http://patchwork.kernel.org/project/linux-media/list/ >> >>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
V4L-DVB issue in systems with >4Gb RAM?
Hi, we are experiencing a problem with the V4L-DVB drivers. It seems that when the system has over 4Gb the drivers do no longer work properly. Either nothing or rubbish comes out of them, although tuning using szap seems to work. If we force the system to use only 4Gb by appending mem=4GB as a kernel parameter things are working like a charm. Our setup: Dell 2850 server with a Magma PCI extender. There are 6 DVB boards in the machine: 5 KNC TV STAR DVB-S and 1 Hauppauge Nova-S-Plus DVB-S. The system has 8GB of RAM and runs an up-to-date Centos5.3, kernel 2.6.18-128.4.1.el5 x86_64. The V4L-DVB driver we are using is v4l-dvb-2009.08.18.tar.bz2 On this setup some of the KNC boards are working, the Hauppauge does not. In a similar setup where we have only KNCs none of them is working unless you force the system to use 4Gb of the available memory. I would like to know if this is a known issue and if so what can be done to fix/work around the problem. Any help/suggestion/hint is highly welcome. Thanks in advance! Kind regards, Helmut -- 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: Hauppauge 2250 - second tuner is only half working
>> I'd really appreciate any help or guidance on this problem as i'm fully >> perplexed by it. > > Hey Seth, > > I ran the same tests on my cable system (channel 103) on 669Mhz and had no > issue, and my snr's reported as (0x172 and 0x17c). > > One possibility is that you're overwhelming the frontend. Try adding a > small > mount of attenuation to the signal for test purposes. > > Hard to believe but this is where I'd start looking. > > -- > Steven Toth - Kernel Labs > http://www.kernellabs.com > > Thank you for reply! Hearing that the same frequency works on another card is pretty positive confirmation in my mind that this is a hardware/setup issue. I tried stopping by a local radio shack last night, but wouldn't you know they no longer carried simple attenuators. Looks like i'll be picking one up online (or maybe ill lookup a schematic online and try building a simple one). On a side note - Thank you very much for hacking on the saa7164 - other than this frequency glitch its been working great for me! -- 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: USB Wintv HVR-900 Hauppauge
On Wed, Aug 19, 2009 at 7:01 AM, Miguel wrote: > > Hello, > > I am trying to set up the dvb-t device in my ubuntu 9.04. > As far as i can see , this device has tm6000 chipset but I don't get it > works. I have followed the guide of tvlinux.org: > http://www.linuxtv.org/wiki/index.php/Trident_TM6000#TM6000_based_Devices > > I have compile v4l-dvb, make, and make install and it seems that the > modules are loaded: > > > em28xx 90668 0 > ir_common 57732 1 em28xx > v4l2_common 25600 1 em28xx > videobuf_vmalloc 14724 1 em28xx > videobuf_core 26244 2 em28xx,videobuf_vmalloc > tveeprom 20228 1 em28xx > videodev 44832 3 em28xx,v4l2_common,uvcvideo > > > But by the moment, I don't know which driver I should you. Actually, > when I switch the usb wintv on , my so doesn't recognize it: > > [11107.449900] usb 1-3: new high speed USB device using ehci_hcd and > address 8 > [11107.593094] usb 1-3: configuration #1 chosen from 1 choice > > > how can I get this device run? > > thank you in advance. > > Miguel Hello Miguel, Can you confirm the exact model number of the device (or provide the USB ID)? I suspect you probably have what is often referred to as an HVR-900 R2, which is not currently supported under Linux. I've got it working here but still need to write the firmware extract script so I can release it, but the work has been delayed due to other priorities. 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: [Q] sensors, corrupting the top line
On Mon, Aug 17, 2009 at 7:09 PM, Guennadi Liakhovetski wrote: > Hi Hans, all > > In soc-camera since its first version we have a parameter "y_skip_top", > which the sensor uses to tell the host (bridge) driver "I am sending you > that many lines more than what is requested, and you should drop those > lines from the top of the image." I never investigated this in detail, > originally this was a "strong tip" that the top line is always corrupted. > Now I did investigate it a bit by setting this parameter to 0 and looking > what the sensors actually produce. I am working with four sensor: mt9m001, > mt9v022, mt9t031 and ov7725, of which only the first two had that > parameter set to 1 from the beginning, the others didn't have it and also > showed no signs of a problem. mt9m001 (monochrome) doesn't have the > problem either, but mt9v022 does. It does indeed deliver the first line > with "randomly" coloured pixels. Notice - this is not the top line of the > sensor, this is the first read-out line, independent of the cropping > position. So, it seems we do indeed need a way to handle such sensors. Do > you have a suggestion for a meaningful v4l2-subdev API for this? > Yep I also went through similar cases and I just skipped corrupted lines. That happens in various sensor devices isn't it? Moreover, we sometimes have whole corrupted image frames which are due to stabilization issue when we initialize the sensor device. In this case I decide to drop corresponding image frames with enough number.(3 frames enough in my experience). So, how about making an API which can cover all over these phonomenum? which can drop or skip line and frames. Host (bridge) queries through the API and get how many lines should skip or how many frames should drop or something like that.. Sounds fair to make an API which can cover general H/W defects or characteristics (even though that is not a defect) Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
USB Wintv HVR-900 Hauppauge
Hello, I am trying to set up the dvb-t device in my ubuntu 9.04. As far as i can see , this device has tm6000 chipset but I don't get it works. I have followed the guide of tvlinux.org: http://www.linuxtv.org/wiki/index.php/Trident_TM6000#TM6000_based_Devices I have compile v4l-dvb, make, and make install and it seems that the modules are loaded: em28xx 90668 0 ir_common 57732 1 em28xx v4l2_common25600 1 em28xx videobuf_vmalloc 14724 1 em28xx videobuf_core 26244 2 em28xx,videobuf_vmalloc tveeprom 20228 1 em28xx videodev 44832 3 em28xx,v4l2_common,uvcvideo But by the moment, I don't know which driver I should you. Actually, when I switch the usb wintv on , my so doesn't recognize it: [11107.449900] usb 1-3: new high speed USB device using ehci_hcd and address 8 [11107.593094] usb 1-3: configuration #1 chosen from 1 choice how can I get this device run? thank you in advance. Miguel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?
On 08/19/2009 10:42 AM, Pásztor Szilárd wrote: Thierry Lelegard: Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO 138181-1:2000/FDAM 3) Try VLC instead of mplayer. VLC does render H.264 HD video, provided you have a (very) good CPU. Thanks for the info. Anyway, mplayer also does render H.264 of course, it's the stream that's not very cleverly muxed, it seems. And with mplayer I have vdpau acceleration on my nvidia card that can render 1920x1...@50 fps in real time. Actually I met just similar case some months ago (I have also Anysee E30C and fi-3ktv cable). Only audio no video. HD-video PIDs were missing. I zapped to the channel and looked correct PIDs from dvbtraffic traffic output and added those to the channels.conf. Mplayer and Totem still resists to show video, but VLC does! After that I looked transmission parameters by using dvbsnoop and there was H.262 (MPEG2) set those H.264 (MPEG4-AVC) channels. I think that was reason for my problems. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?
Thierry Lelegard: > Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO > 138181-1:2000/FDAM 3) > > Try VLC instead of mplayer. VLC does render H.264 HD video, provided you > have a (very) good CPU. Thanks for the info. Anyway, mplayer also does render H.264 of course, it's the stream that's not very cleverly muxed, it seems. And with mplayer I have vdpau acceleration on my nvidia card that can render 1920x1...@50 fps in real time. s. - | After all is said and done, a hell of a lot more is said than done. | - -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-dvb] Anysee E30 C Plus + MPEG-4?
> Pásztor Szilárd: > With scan -vv I could find the video PIDs > for the HD channels and indeed they were missing in my channels.conf (values > were 0) as scan detected them as "OTHER", but with a "type 0x1b" addition with > which I don't know what to do for the time being... Stream type 0x1B precisely means AVC / H.264 video stream (cf. ISO 138181-1:2000/FDAM 3) Try VLC instead of mplayer. VLC does render H.264 HD video, provided you have a (very) good CPU. -Thierry -- 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: help: Can't get DViCO FusionHDTV DVB-T Dual Digital 4 to work with new kernels
2.6.27 worked for me - exact same board (ignoring revisions - mine is an older board, rev.1, I think) 2.6.28 and up failed for me in exactly this manner. Same with a head-of-tree v4l-dvb 'hg clone' AFAICT it's a v4l-dvb driver problem - at least no-one here refutes it since I reported it here on 20090615. Cheers Bob On Wed, 19 Aug 2009 12:09:24 +0800 treblid wrote: > Been grappling with this problem for a while now.. > I am using stock linux kernel 2.6.28.9 together with Mythtv (SVN trunk) > > For some reason I cannot use 2.6.29.x or 2.6.30.x (latest version I > tried is 2.6.30.5). > > Everytime i start mythbackend, the console is littered with the > following messages, and the keyboard input freezes sporadically. > the messages as below: > > dvb-usb: recv bulk message failed: -110 > cxusb: i2c read failed > > i googled for a solution and it seems some got around this by inserted > the IR receiver, I tried but it still doesn't work. > > is this a mythtv problem or cxusb issue? > > Please help, any pointers appreciated. > > regards, > -- > 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 -- Bob Hepple ph: 07-5584-5908 Fx: 07-5575-9550 -- 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
