Re: detection of Empire Media Pen Dual TV
2009/8/21 Devin Heitmueller dheitmuel...@kernellabs.com: On Fri, Aug 21, 2009 at 4:05 PM, Baggiusbagg...@gmail.com wrote: Hello Devin, I have an Empire Media Pen Dual TV and it has same layout as Kworld dvb-t 310u. while MSI Digivox A/D has similar layout and supports 1080i extra resolution, as http://www.msi.com/index.php?func=proddescmaincat_no=132prod_no=626 If you want I can capture usb device startup log using Usbsnoop/SniffUSB ... Giuseppe Hmmm... Let's hold off on a usb capture for now. Now that I understand that you have the Empire board, I am looking at the dmesg trace again and am a bit confused. Do you happen to have a card=49 parameter in your modprobe configuration? However, the code does appear to also recognize the board as the Empire board (see the Board detected as Empire dual TV). No, I havent' any card parameter in modprobe.conf, I commented out options em28xx ... line. Now some info on my system: Kernel is Linux box 2.6.29-sabayon #1 SMP Wed Aug 19 22:18:09 UTC 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux, Linux Distro is Sabayon 4.2 x86_64 Gnome edition, regularly updated, on Acer Aspire 5920G http://support.acer-euro.com/drivers/notebook/as_5920.html I agree that something appears to be wrong. I will have to take a look at the code and see where the Identified as messages comes from. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Well, after some searches I got from web another eeprom contents, from a similar board, a Conitech CN610DVB-DT http://www.conitech.it/conitech/ita/prod.asp?cod=CN610DVB-DT and using rebuil_eeprom.pl generated .sh script to change my eeprom contents. Here both eeproms bytes: empire media pen dual tv eeprom contents (vid=eb1a pid=e310): [11196.181543] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 10 e3 d0 12 5c 03 6a 22 00 00 [11196.181559] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 07 00 00 00 00 00 00 00 00 00 00 [11196.181572] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 01 00 00 00 00 00 5b 1e 00 00 [11196.181585] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [11196.181598] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181610] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181622] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [11196.181635] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 44 00 [11196.181648] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [11196.181660] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181673] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181685] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181698] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181710] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181722] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181735] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 conitech cn610dvb-dt eeprom contents (vid=eb1a pid=2881): [ 127.753053] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 03 6a 20 6a 00 [ 127.753073] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [ 127.753090] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 01 00 b8 00 00 00 5b 1e 00 00 [ 127.753107] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 [ 127.753123] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753140] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753156] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 00 [ 127.753173] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [ 127.753189] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [ 127.753206] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753222] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753239] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753255] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753271] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753288] em28xx #0: i2c eeprom e0: 5a 00 55 aa e5 2b 59 03 00 17 fc 01 00 00 00 00 [ 127.753305] em28xx #0: i2c eeprom f0: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 wrote new eeprom, I used card=48 as em28xx parameter (kworld 310U) and analog part, WITH audio, was ALL working (both tv and audio/video input) with extra feature of usb power management, as dmesg told: [19178.415552] em28xx #0: USB Remote wakeup capable Result was a less
Re: [RFC] v4l2_subdev_ir_ops
On Monday 24 August 2009 02:05:06 Mauro Carvalho Chehab wrote:
Em Sun, 23 Aug 2009 21:16:36 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On Sunday 23 August 2009 20:00:00 Mauro Carvalho Chehab wrote:
Em Sat, 22 Aug 2009 17:27:50 -0400
Andy Walls awa...@radix.net escreveu:
The more important one is what kind of IR interfaces a V4L2
device will open to lirc.
I was thinking a lirc-v4l2-subdev plugin for lirc-dev. If the
v4l2_subdev_ir_ops interface aligned or can easily translate to
supporting things LIRC needed, then follow on support for all video
related IR devices would fall out from implementing the
v4l2_subdev_ir_ops interface. (In my optimistic version of the
future ;] ).
This won't work, due to two reasons:
1) a subdev interface works for the devices with i2c interfaces (e.
g. the subdev's), but it won't work on other cases;
Subdev is actually independent of i2c, that was the one of the reasons
for making v4l2_subdev in the first place. Both the cx18 and ivtv
drivers use a non-i2c subdev in fact. It does rely on there being a
parent v4l2_device struct with which it will be registered. In other
words: while there may be good reasons for not using v4l2_subdev, this
reason isn't one of them.
See bellow.
2) even when you'll have this at i2c, you may still need to properly
lock the IR code to avoid that the IR operation to happen in the
middle of another i2c transfer.
I could well be wrong, but isn't the i2c_adapter already locking at the
bus level?
It won't lock. The issue is outside i2c code. Probably you haven't seen
the code I've posted on my previous email. Lirc does 2 separate
transfers, one for send and another for receive:
i2c_master_send(ir-c, keybuf, 1);
/* poll IR chip */
if (i2c_master_recv(ir-c, keybuf, sizeof(keybuf)) !=
sizeof(keybuf)) { dprintk(read error\n);
return -EIO;
}
Between the two independent transactions, an ioctl or a kernel thread may
happen doing some stuff at i2c. You'll then have an i2c send where an i2c
receive operation were expected to happen. This is known to cause some
problems with some i2c implementations on some chips, including some
eeprom's.
In this specific case, one possible solution could be to replace them by
i2c_master_xfer().
See above. This should be unified outside subdev, since, on most
cases, the IR is handled directly by the bridge code. Another
alternative would be to create a fake subdev for the IR handling
code, but, IMHO, such change will be large and I don't see much gain
on doing it. Also, since on several cases it shares the bridge IRQ
code, the IR handling code will be broken on just a layer interface
at the subdev, but the real work will be handled at the bridge
driver.
It is a perfectly legitimate approach to use a subdev for IR handling.
Usually it is some separate set of registers or IC block anyway,
whether it is a bridge driver or a complex chip like cx2584x.
No. Having a different sets of register for IR is generally the
exception. I guess that, on 80-90% of the cases, it uses the same GPIO
set of registers used by other parts of the driver. Just taking a few
real examples: almost all bttv and cx88 are based on GPIO poll; on
saa7134, just a few uses i2c. The great majority has a mix of GPIO poll
or GPIO IRQ. If you take a look at the IRQ code, it is the same code used
also by videobuf. On em28xx, you have 3 types: i2c, GPIO poll (mostly on
devices with em282x and em284x) and some dedicated IR registers found on
hardware with em286x/em288x (yet, a few of those devices still uses the
old strategy).
Ok, it would be possible to artificially add a layer in order to deal
with some bits of those common registers differently, and to create an
IRQ ops abstraction layer for IR but this is overkill. It will just add
an extra abstraction layer for nothing. It may even interfere at the IR
protocol handling, as, on those GPIO poll code, extra delays may
interfere at the decoding, since the processor is responsible for
measuring the times.
The v4l2_subdev approach
allows one to model such things in a relatively high-level manner. Andy
has experience doing exactly that in the cx18 driver, so he is very
well placed to investigate which approach is best.
The v4l2_subdev approach works fine for the communication between a
bridge driver and their ancillary sub-devices. There's nothing wrong on
proposing an IR interface for that usage, in the cases where a separate
IC chip is measuring the time or returning scan codes, like the cases
where Andy mentioned.
However, just letting lirc (or any other IR driver) to directly access a
v4l_subdev without passing it via the bridge driver is risky, since
bridge cannot protect the shared registers or avoid that another subdev
call won't be interfered by IR.
In other words, I'm
Re: Exposure set bug in stv06xx driver
Hi, On 08/23/2009 02:50 PM, James Blanford wrote: Well that was quick. These issues as well as the stream drops were remedied in 2.6.31-rc7, ?? I'm the author of the pb100 (046d:0840) support in the stv06xx driver, and AFAIK there have been no changes to it recently. except exposure and gain still cannot be set with v4l2ucp. They can be set if you disable autogain first, just uncheck the checkbox. As a bonus, I found the autogain white list in v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c. Is there a white list to turn on the gain and exposure manual controls? This whitelist is to enable software automatic gain + exposure for camera's which lack this in hardware (or we don't know how to do this), this is not relevant for the 046d:0840. While the autogain works great, the autoloss doesn't. Gain increases automatically, but is not decreased when light levels rise. It does, but it is slow when decreasing, give it some time. Also, updating the exposure readout in v4l2ucp decreases the exposure about 10% and incorrectly reports an exposure somewhere between the original level and the changed level. E.g., click the exposure update button and the exposure drops from 2 to 18000 and reports 19000. ??? I've not seen any problems like these. Note that the values returned when reading the controls are cached values of the last value set, not actually register values. Also the range for exposure is only 0 - 511, where are you getting values like 18000 - 2 from ? Are you sure you are using the in kernel gspcav2 stv06xx driver ? Hmm, you also write: is there any possibility of enabling autogain? Yet this already is enabled, does your 046d:0840, perhaps have a different sensor, mine says when plugged in: STV06xx: Photobit pb0100 sensor detected I'm not used to logitech having different camera's with the same usb-id, but you never know. Regards, Hans Thanks for all the work. - Jim On Sat, 22 Aug 2009 15:10:31 -0400 James Blanfordjhblanf...@gmail.com wrote: Quickcam Express 046d:0840 Driver versions: v 2.60 from 2.6.31-rc6 and v 2.70 from gspca-c9f3938870ab Problem: Overexposure and horizontal orange lines in cam image. Exposure and gain controls in gqcam and v4l2ucp do not work. By varying the default exposure and gain settings in stv06xx.h, the lines can be orange and/or blue, moving or stationary or a fine grid. Workaround: Using the tool set_cam_exp, any exposure setting removes the visual artefacts and reduces the image brightness for a given set of gain and exposure settings. By default: Aug 21 14:22:02 blackbart kernel: STV06xx: Writing exposure 5000, rowexp 0, srowexp 0 Note what happens when I set the default exposure to 1000: Aug 21 20:44:23 blackbart kernel: STV06xx: Writing exposure 1000, rowexp 0, srowexp 139438350 By the way, is there any possibility of enabling autogain? Thanks for your interest, - Jim -- 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: detection of Empire Media Pen Dual TV
2009/8/21 Devin Heitmueller dheitmuel...@kernellabs.com: On Fri, Aug 21, 2009 at 4:05 PM, Baggiusbagg...@gmail.com wrote: Hello Devin, I have an Empire Media Pen Dual TV and it has same layout as Kworld dvb-t 310u. while MSI Digivox A/D has similar layout and supports 1080i extra resolution, as http://www.msi.com/index.php?func=proddescmaincat_no=132prod_no=626 If you want I can capture usb device startup log using Usbsnoop/SniffUSB ... Giuseppe Hmmm... Let's hold off on a usb capture for now. Now that I understand that you have the Empire board, I am looking at the dmesg trace again and am a bit confused. Do you happen to have a card=49 parameter in your modprobe configuration? However, the code does appear to also recognize the board as the Empire board (see the Board detected as Empire dual TV). No, I havent' any card parameter in modprobe.conf, I commented out options em28xx ... line. Now some info on my system: Kernel is Linux box 2.6.29-sabayon #1 SMP Wed Aug 19 22:18:09 UTC 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux, Linux Distro is Sabayon 4.2 x86_64 Gnome edition, regularly updated, on Acer Aspire 5920G http://support.acer-euro.com/drivers/notebook/as_5920.html I agree that something appears to be wrong. I will have to take a look at the code and see where the Identified as messages comes from. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Well, after some searches I got from web another eeprom contents, from a similar board, a Conitech CN610DVB-DT http://www.conitech.it/conitech/ita/prod.asp?cod=CN610DVB-DT and using rebuil_eeprom.pl generated .sh script to change my eeprom contents. Here both eeproms bytes: empire media pen dual tv eeprom contents (vid=eb1a pid=e310): [11196.181543] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 10 e3 d0 12 5c 03 6a 22 00 00 [11196.181559] em28xx #0: i2c eeprom 10: 00 00 04 57 4e 07 00 00 00 00 00 00 00 00 00 00 [11196.181572] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 01 00 00 00 00 00 5b 1e 00 00 [11196.181585] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [11196.181598] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181610] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181622] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [11196.181635] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 44 00 [11196.181648] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [11196.181660] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181673] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181685] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181698] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181710] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181722] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [11196.181735] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 conitech cn610dvb-dt eeprom contents (vid=eb1a pid=2881): [ 127.753053] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 81 28 58 12 5c 03 6a 20 6a 00 [ 127.753073] em28xx #0: i2c eeprom 10: 00 00 04 57 64 57 00 00 60 f4 00 00 02 02 00 00 [ 127.753090] em28xx #0: i2c eeprom 20: 56 00 01 00 00 00 01 00 b8 00 00 00 5b 1e 00 00 [ 127.753107] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 00 00 00 00 00 00 [ 127.753123] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753140] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753156] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 00 [ 127.753173] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 38 00 31 00 20 00 56 00 [ 127.753189] em28xx #0: i2c eeprom 80: 69 00 64 00 65 00 6f 00 00 00 00 00 00 00 00 00 [ 127.753206] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753222] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753239] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753255] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753271] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 127.753288] em28xx #0: i2c eeprom e0: 5a 00 55 aa e5 2b 59 03 00 17 fc 01 00 00 00 00 [ 127.753305] em28xx #0: i2c eeprom f0: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 wrote new eeprom, I used card=48 as em28xx parameter (kworld 310U) and analog part, WITH audio, was ALL working (both tv and audio/video input) with extra feature of usb power management, as dmesg told: [19178.415552] em28xx #0: USB Remote wakeup capable Result was a less
Re: Nova-TD-500 (84xxx) problems (was Re: dib0700 diversity support)
Malcolm Caldwell wrote: Please can someone help... I have been trying to get my nova-td-500 to work, but no matter what I try I get a substandard signal, with lots of errors. This is about the same as described elsewhere on this list. I tried this code (posted by Patrick Boettcher below), hoping it may be a little better but, so far, it has not improved things at all. I have even replaced the antenna on my roof, in the hope of getting a better signal, but I still get errors. I have tried the top, the bottom and both antenna connectors, but it does not seem to make much difference. Is there anything else I could try? I really want a working system again. (I replaced an old buggy card with this one, not knowing it would be such a problem) On Tue, 2009-08-18 at 10:54 +0200, Patrick Boettcher wrote: Hi Paul, On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ In the best case they improve the situation for you. In the worst case (not wanted :) ) it will degrade. -- Patrick 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 -- 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 Have you tried adding: dvb_usb_dib0700.force_lna_activation=1 to the modprobe options? The device I had wouldn't tune without this. Cheers, 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: Nova-TD-500 (84xxx) problems (was Re: dib0700 diversity support)
On 24/08/2009, at 23:04, Lou Otway lot...@nildram.co.uk wrote: Malcolm Caldwell wrote: Please can someone help... I have been trying to get my nova-td-500 to work, but no matter what I try I get a substandard signal, with lots of errors. This is about the same as described elsewhere on this list. I tried this code (posted by Patrick Boettcher below), hoping it may be a little better but, so far, it has not improved things at all. I have even replaced the antenna on my roof, in the hope of getting a better signal, but I still get errors. I have tried the top, the bottom and both antenna connectors, but it does not seem to make much difference. Is there anything else I could try? I really want a working system again. (I replaced an old buggy card with this one, not knowing it would be such a problem) On Tue, 2009-08-18 at 10:54 +0200, Patrick Boettcher wrote: Hi Paul, On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ In the best case they improve the situation for you. In the worst case (not wanted :) ) it will degrade. -- Patrick 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 -- 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 Have you tried adding: dvb_usb_dib0700.force_lna_activation=1 to the modprobe options? The device I had wouldn't tune without this. I should have mentioned that I have tried this and buggy sfn workaround for the relavent modules. Cheers, 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: Nova-TD-500 (84xxx) problems (was Re: dib0700 diversity support)
On Tue, 2009-08-25 at 00:36 +0930, Malcolm Caldwell wrote: Have you tried adding: dvb_usb_dib0700.force_lna_activation=1 to the modprobe options? The device I had wouldn't tune without this. I should have mentioned that I have tried this and buggy sfn workaround for the relavent modules. I have read that sometimes the problem is not a low signal, but too strong a signal. Have you tried placing an attenuator in front of the card? Nico -- 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: How to handle devices sitting on multiple busses ?
On Mon, Aug 24, 2009 at 01:57:44PM +0200, Laurent Pinchart wrote: Hi Greg, while working on video input support for embedded platforms a few developers including myself ran independently into a Linux device model issue. We all came up with hackish solutions that we are not very happy with, and we'd like to fix this in a clean way. The problem comes from devices sitting on multiple busses, a situation commonly found with video sensors connected to an embedded System on Chip (SoC). The sensor is controlled through an I2C bus and sends video data on a parallel video bus, connected to a camera controller usually referred as an Image Signal Processor (ISP), Video Processing Front End (VPFE), CCD Controller (CCDC) or simply a bridge. The bridge and the I2C master controller on the SoC are completely independent from each other. The I2C master controller is not dedicated to the video function and is often used to communication with non-video I2C devices. Unfortunately, on the sensor side, I2C and video bus are not independent. The I2C slave controller usually requires an external clock to be present, and the clock is usually provided on the video bus by the SoC bridge. As the bridge and I2C master live their own life in the Linux device tree, they are initialized, suspended, resumed and destroyed independently. The sensor being an I2C slave device, Linux initializes it after the I2C master device is initialized, but doesn't ensure that the bridge is initialized first as well. A similar problem occurs during suspend/resume, as the I2C slave needs to be suspended before and resumed after the video bridge. Have you ever encountered such a situation before ? No, not really. Is there a clean way for a device to have multiple parents, or do you have plans for such a possibility in the future ? I do not know of any future plans to support something like this in the driver core code, sorry. I would be willing to give an implementation a try if you can provide me with some guidelines. Hm, I really don't know of any guidelines I can provide, as I've never thought about this before :) I really don't know what to suggest at the moment, sorry. 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Hi Mauro On Sun, 23 Aug 2009, Mauro Carvalho Chehab wrote: Em Mon, 17 Aug 2009 08:26:28 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: ...speaking about which, we should at some point start merging the soc-camera patch stack, which, however, requires some patches that are currently in next. Shall we pull those into the hg trees with the kernel-sync tag? Yes, that's fine. The only issue then is, that we will have to remember to push the patches to Linus in the 2.6.32 merge window after those 3 patches are there. The patches update 3 PXA platforms to the new soc-camera API. Ok. please put Priority: low on those patches. My scripts will put this at the pending tree, where I have already the DaVinci patches. They also have the same kind of restriction. So, I'll delay the pending -git tree to be sent after having the arch patches merged Ok, good, now, is there a git kernel tree to which I could rebase? If the current development tree is so far only available in hg, could you maybe push it into some git branch somewhere or just produce a patch series? 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: Technotrend TT-Connect S-2400
Markus Schuss wrote: Hi, i have some problems getting a technotrend tt-connect s-2400 usb dvb-s card to work. the problem is not unknown (as mentioned at http://lkml.org/lkml/2009/5/23/95) but i have no idea how to fix this. (any help according to the remote of this card would also be appreciated) This breakage was caused by USB changes introduced in 2.6.27, and it's still broken as of 2.6.30. The 2.6.31rc should have the fix, and I have a patch for 2.6.30 if you want it. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add driver for OmniVision OV9640 sensor
Hi Marek On Sat, 22 Aug 2009, Marek Vasut wrote: From 479aafc9a6540efec8a691a84aff166eb0218a72 Mon Sep 17 00:00:00 2001 From: Marek Vasut marek.va...@gmail.com Date: Sat, 22 Aug 2009 05:14:23 +0200 Subject: [PATCH 2/3] Add driver for OmniVision OV9640 sensor Signed-off-by: Marek Vasut marek.va...@gmail.com Ok, I see, you rebased your patches on my soc-camera patch-stack, this is good, thanks. But you missed a couple of my comments - you still have a few static functions in the ov9640.c marked inline: ov9640_set_crop() is not used at all, ov9640_set_bus_param() gets assigned to a struct member, so, cannot be inline. ov9640_alter_regs() is indeed only called at one location, but see Chapter 15 in Documentation/CodingStyle. You left at least one multi-line comment wrongly formatted. You left some broken printk format lines, etc. You moved your header under drivers/... - that's good. But, please, address all my comments that I provided in a private review, or explain why you do not agree. Otherwise I feel like I wasted my time. Besides, your mailer has wrapped lines. Please, read Documentation/email-clients.txt on how to configure your email client to send patches properly. In the worst case, you can inline your patches while reviewing, and then attach them for a final submission. This is, however, discouraged, because it makes review and test of your intermediate patches with wrapped lines more difficult. Also, please check your patches with scripts/checkpatch.pl. [patch skipped] 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: Technotrend TT-Connect S-2400
Hi David, On 24.08.2009 19:17, David wrote: still broken as of 2.6.30. The 2.6.31rc should have the fix, and I have a patch for 2.6.30 if you want it. Could please post a link to this patch? I think that a few people on this list, including me, are interested in a solution. Regards. André -- 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: WARNINGS, 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 Aug 24 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12500:28f8b0ebd224 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: OK linux-2.6.23.12-i686: OK 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: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-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: OK linux-2.6.23.12-x86_64: OK 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: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK 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: 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 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Em Mon, 24 Aug 2009 18:26:10 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro On Sun, 23 Aug 2009, Mauro Carvalho Chehab wrote: Em Mon, 17 Aug 2009 08:26:28 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: ...speaking about which, we should at some point start merging the soc-camera patch stack, which, however, requires some patches that are currently in next. Shall we pull those into the hg trees with the kernel-sync tag? Yes, that's fine. The only issue then is, that we will have to remember to push the patches to Linus in the 2.6.32 merge window after those 3 patches are there. The patches update 3 PXA platforms to the new soc-camera API. Ok. please put Priority: low on those patches. My scripts will put this at the pending tree, where I have already the DaVinci patches. They also have the same kind of restriction. So, I'll delay the pending -git tree to be sent after having the arch patches merged Ok, good, now, is there a git kernel tree to which I could rebase? If the current development tree is so far only available in hg, could you maybe push it into some git branch somewhere or just produce a patch series? You may use my linux-next tree. Be warned that I almost always rebase it, due to our (broken) upstream proccess of using an -hg tree. I used to push also the devel tree upstream, but, as sometimes I was needing to rebase (less often than linux-next, but still often), I've dropped it, since rebasing is very bad for kernel.org mirrors, so I've minimized the problem by just pushing my trees when I'm about to ask a merge. 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] saa7134: start to investigate the LNA mess on 310i and hvr1110 products
Hermann,
On Sat, Aug 22, 2009 at 9:54 PM, hermann pittonhermann-pit...@arcor.de wrote:
Am Freitag, den 21.08.2009, 01:49 +0200 schrieb hermann pitton:
There is a great maintenance mess for those devices currently.
All attempts, to get some further information out of those assumed to be
closest to the above manufactures, failed.
Against any previous advice, newer products with an additional LNA,
which needs to be configured correctly, have been added and we can't
make any difference to previous products without LNA.
Even more, the type of LNA configuration, either over tuner gain or some
on the analog IF demodulator, conflicts within this two devices itself.
Since we never had a chance, to see such devices with all details
reported to our lists, but might still be able to make eventually a
difference, to get out of that mess, we should prefer to start exactly
where it started.
Mauro, Douglas,
just mark it as an RFC.
Seems i lose any interest to follow up such further.
Never allow any guys to go out into the wild, ending up with that I have
to read their personal web blogs ..., out of lists.
Cheers,
Hermann
Signed-off-by: hermann pitton hermann-pit...@arcor.deiff -r d0ec20a376fe
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Aug 20
01:30:58 2009 +
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Aug 21
01:28:37 2009 +0200
@@ -3242,7 +3242,7 @@
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 1,
+ .tuner_config = 0,
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x00020,
.inputs = {{
@@ -3346,7 +3346,7 @@
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 1,
+ .tuner_config = 0,
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x0200100,
.inputs = {{
diff -r d0ec20a376fe linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Thu Aug 20
01:30:58 2009 +
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Fri Aug 21
01:28:37 2009 +0200
@@ -1144,12 +1144,12 @@
break;
case SAA7134_BOARD_PINNACLE_PCTV_310i:
if (configure_tda827x_fe(dev, pinnacle_pctv_310i_config,
- tda827x_cfg_1) 0)
+ tda827x_cfg_0) 0)
goto dettach_frontend;
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
if (configure_tda827x_fe(dev, hauppauge_hvr_1110_config,
- tda827x_cfg_1) 0)
+ tda827x_cfg_0) 0)
goto dettach_frontend;
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1150:
--
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
NACK.
Please do not change the LNA configuration for the HVR1110 -- I cannot
speak for the PCTV device, but I looked at the schematics for the
HVR1110 -- the LNA configuration should not be changed.
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx
On Tue, Aug 11, 2009 at 5:57 PM, Michael Krufkymkru...@kernellabs.com wrote: On Tue, Aug 11, 2009 at 1:01 PM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Sat, 1 Aug 2009 14:03:24 -0400 Michael Krufky mkru...@kernellabs.com escreveu: On Sat, Aug 1, 2009 at 12:40 AM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 31 Jul 2009 11:25:55 -0400 Michael Krufky mkru...@kernellabs.com escreveu: Please review this patch yourself -- you will see I am simply removing Hauppauge-specific handling that was incorrectly added by Uri, resulting in the crippling of these devices under Linux. Fair enough. I'll apply the patch. Yet, we should address with Udi what else is needed in order to sync their tree with ours without breaking support for any existing device. I cant stress enough how important it is that this changeset gets merged upstream to Linus asap. The 2.6.31-rc kernel is broken without this change. I'll add it on my next upstream changeset. Thanks for applying the fix patch. Now, at least those devices will work again, but there is still a regression since the previous kernels supported the LED and LNA functionality that my next patch restores. Hopefully we will hear from Udi soon. Just to be clear, the patch that we'd like Udi's comments on is this one: http://kernellabs.com/hg/~mkrufky/sms1xxx/rev/tip As this code is in the smsdvb common code, it calls into sms-cards and will return harmlessly to the caller on the non-hauppauge devices. The functionality is only changed for those cards that have this functionality defined in the sms-cards.c structures. Hopefully, Udi can agree to merge this into the 2.6.31 kernel, while we can work on Siano's internal event interface for the next kernel. Once that is working perfectly, we can remove the patch that I'm proposing now, and convert the Hauppauge devices to the newer event interface. Since: a) the pull request were sent on Jul, 28; b) we didn't have any answer from Siano up to today; c) a closer analysis showed that this patch won't affect non Hauppauge devices; I'm merging the fix today. Udi, the better is to work at the event interface in a way that it won't cause troubles with the existing Hauppauge devices. After having it done, we may just remove the legacy SMS code Mauro, Thank you for merging the fixes. Please be sure to send them both to Linus for the 2.6.31 kernel, as these patches actually fix regressions introduced only in this 2.6.31 kernel. Once the event interface works properly, I will be very happy to port the existing device-specific GPIO handling functionality to it. This will be a nice improvement in flexibility and in code cleanliness. Udi, Please let me know once this is ready -- I look forward to the testing. Regards, Mike Mauro, Would you please send the final GPIO fix to Linus to fix the regression on the Hauppauge devices. 2.6.31 is in -rc7 now, and I would hate for this regression to not yet be solved before the kernel is released. I apologize for nagging -- I just prefer for fixes to be merged upstream *before* a kernel release. Thank you. Just as a reminder, the changeset that is still waiting for upstream merge is: * sms1xxx: restore GPIO functionality for all Hauppauge devices Thanks regards, Mike Krufky -- 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
Kevin, How do we handle this? 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: Sunday, August 23, 2009 11:10 PM To: Karicheri, Muralidharan Cc: Kevin Hilman; Mauro Carvalho Chehab; linux-media@vger.kernel.org; Hans Verkuil Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver Em Thu, 20 Aug 2009 16:27:40 -0500 Karicheri, Muralidharan m-kariche...@ti.com escreveu: Kevin Mauro, Do I need to wait or this can be resolved by either of you for my work to proceed? Murali, If I fix your patch in order to apply it on my tree, backporting it to the old arch header files, we'll have merge troubles upstream, when Kevin merge his changes. It will also mean that he'll need to apply a diff patch on his tree, in order to convert the patch to the new headers, and that git bisect may break. I might merge his tree here, but this means that, if he needs to rebase his tree (and sometimes people need to rebase their linux-next trees), I'll have troubles here, and I'll loose my work. So, the better solution is if he could apply this specific patch, merging his tree upstream before your patches. 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] Anysee E30 Combo Plus startup mode
On 08/21/2009 04:21 PM, Alexander Saers wrote: Hello I have a Anysee E30 Combo Plus USB device. It's capable of both DVB-C and DVB-T. I currently use the device with ubuntu 9.04 64bit with mythtv. I have problem with selction of mode for the device The following way i can get DVB-T 1. Power up computer with E30 Combo Plus connected. 2. run dmesg Anyone experienced this problem? It would be nice to run DVB-C without having to disconnect and connect hardware. You are not alone. Looks like it is GPIO related problem. I don't have currently that device... It is a little bit hard to fix without knowing exactly how GPIO pins are connected in each device. There is too many different hardware revisions with different GPIOs, fix one break the other. From the anysee.c code you can find following entry: /* Try to attach demodulator in following order: model demod hw firmware 1. E30MT352 02 0.2.1 2. E30ZL10353 02 0.2.1 3. E30 Combo ZL10353 0f 0.1.2DVB-T/C combo 4. E30 Plus ZL10353 06 0.1.0 5. E30C Plus TDA10023 0a 0.1.0rev 0.2 E30C Plus TDA10023 0f 0.1.2rev 0.4 E30 Combo TDA10023 0f 0.1.2DVB-T/C combo */ 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
[PATCH] dvb: add driver for 774 Friio White USB ISDB-T receiver
From: Akihiro Tsukada ts...@yahoo.co.jp
This patch adds driver for 774 Friio White, ISDB-T USB receiver
Friio White is an USB 2.0 ISDB-T receiver. (http://www.friio.com/)
The device has a GL861 chip and a Comtech JDVBT90502 canned tuner module.
This driver ignores all the frontend_parameters except frequency,
as ISDB-T shares the same parameter configuration across the country
and thus the device can work like an intelligent one.
As this device does not include a CAM nor hardware descrambling feature,
the driver passes through scrambled TS streams.
There is Friio Black, a variant for ISDB-S, which shares the same USB
Vendor/Product ID with White, but it is not supported in this driver.
They should be identified in the initialization sequence,
but this feature is not tested.
Priority: normal
Signed-off-by: Akihiro Tsukada ts...@yahoo.co.jp
---
Currently, all the Japanese Digital TV broadcasters, including the
charge-free ones, scramble their programs except the tiny sized versions
for cellular phones (called 1 seg. program).
BCAS card is used to descramble those normal sized programs,
and a private agency named BS Conditional Systems exclusively issues
the cards only as a bundle for the approved receiver devices.
Friio White is not, so it does not include a BCAS card.
There are some descrambler software using a BCAS card from somewhere else
with a PC/SC reader. Examples of these software include,
filter command: http://www.marumo.ne.jp/junk/arib_std_b25-0.2.4.lzh
Gstreamer plugin: http://2sen.dip.jp/cgi-bin/dtvup/source/up0158.zip
But you have to note that their use may violate the card's license agreement.
diff --git a/linux/drivers/media/dvb/dvb-usb/Kconfig
b/linux/drivers/media/dvb/dvb-usb/Kconfig
--- a/linux/drivers/media/dvb/dvb-usb/Kconfig
+++ b/linux/drivers/media/dvb/dvb-usb/Kconfig
@@ -315,3 +315,9 @@ config DVB_USB_CE6230
select MEDIA_TUNER_MXL5005S if !MEDIA_TUNER_CUSTOMISE
help
Say Y here to support the Intel CE6230 DVB-T USB2.0 receiver
+
+config DVB_USB_FRIIO
+ tristate Friio ISDB-T USB2.0 Receiver support
+ depends on DVB_USB
+ help
+ Say Y here to support the Japanese DTV receiver Friio.
diff --git a/linux/drivers/media/dvb/dvb-usb/Makefile
b/linux/drivers/media/dvb/dvb-usb/Makefile
--- a/linux/drivers/media/dvb/dvb-usb/Makefile
+++ b/linux/drivers/media/dvb/dvb-usb/Makefile
@@ -79,6 +79,9 @@ obj-$(CONFIG_DVB_USB_CINERGY_T2) += dvb-
dvb-usb-ce6230-objs = ce6230.o
obj-$(CONFIG_DVB_USB_CE6230) += dvb-usb-ce6230.o
+dvb-usb-friio-objs = friio.o friio-fe.o
+obj-$(CONFIG_DVB_USB_FRIIO) += dvb-usb-friio.o
+
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/
# due to tuner-xc3028
EXTRA_CFLAGS += -Idrivers/media/common/tuners
diff --git a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -59,6 +59,7 @@
#define USB_VID_YUAN 0x1164
#define USB_VID_XTENSIONS 0x1ae7
#define USB_VID_HUMAX_COEX 0x10b9
+#define USB_VID_7740x7a69
/* Product IDs */
#define USB_PID_ADSTECH_USB2_COLD 0xa333
@@ -264,5 +265,6 @@
#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x0020
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
+#define USB_PID_FRIIO_WHITE0x0001
#endif
diff --git a/linux/drivers/media/dvb/dvb-usb/friio-fe.c
b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
new file mode 100644
--- /dev/null
+++ b/linux/drivers/media/dvb/dvb-usb/friio-fe.c
@@ -0,0 +1,483 @@
+/* DVB USB compliant Linux driver for the Friio USB2.0 ISDB-T receiver.
+ *
+ * Copyright (C) 2009 Akihiro Tsukada ts...@yahoo.co.jp
+ *
+ * This module is based off the the gl861 and vp702x modules.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation, version 2.
+ *
+ * see Documentation/dvb/README.dvb-usb for more information
+ */
+#include linux/init.h
+#include linux/string.h
+#include linux/slab.h
+
+#include friio.h
+
+struct jdvbt90502_state {
+ struct i2c_adapter *i2c;
+ struct dvb_frontend frontend;
+ struct jdvbt90502_config config;
+};
+
+/* NOTE: TC90502 has 16bit register-address? */
+/* register 0x0100 is used for reading PLL status, so reg is u16 here */
+static int jdvbt90502_reg_read(struct jdvbt90502_state *state,
+ const u16 reg, u8 *buf, const size_t count)
+{
+ int ret;
+ u8 wbuf[3];
+ struct i2c_msg msg[2];
+
+ wbuf[0] = reg 0xFF;
+ wbuf[1] = 0;
+ wbuf[2] = reg 8;
+
+ msg[0].addr = state-config.demod_address;
+
