Re: [linux-dvb] TwinhanDTV MagicBox Pro (DVB-T/Analogue)
On Tue, 13 Mar 2007, Christian Stoessel wrote:
Hello together,
I have a TwinhanDTV MagicBox Pro (DVB-T/Analogue) as listed in your
Unspecified/Unkown devices section at hand.
H, is there no linux driver for this one yet? I've got a Mac driver
for it in my CVS repository if anyone's interested (digital part only).
It uses a ULi M9207 so I imagine it'd be easy to add support for it,
seeing as how you guys have already got an M920X driver.
{P^/
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Random Oops
Yes, soft disconnect caused by something in the USB communication chain, exactly what I don´t know. Try a later or latest version of the dvb drivers or even start with a newer kernel and then newer dvb. Also check cables and other sources of interference. Search the archive for nova-t 500 and there will be al lot of threads about soft disconnects. /Henrik On 3/14/07, Benjamin Gillam [EMAIL PROTECTED] wrote: My card has not been (physically) disconnected from my computer for over 5 weeks, whilst this crash happened yesterday. Is it perhaps a soft disconnect (not sure of correct term)? If so, what can I do to prevent it from soft disconnecting in future? Is it issue with the card, or my computers USB ports, or USB controller chipset, or what? Any ideas gratefully received! Kind regards, and thank you for your fast response, Benjie Gillam Henrik Beckman wrote: Hi, [17267534.12] usb 1-3: USB disconnect, address 2 [17267534.12] dvb-usb: bulk message failed: -22 (1/-909000848) [17267534.124000] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully deinitialized and disconnected. Your DVB card is disconnected and that isn´t handled gracefully, DVB doesn´t handle hotplug. Then your mythbackend bites the dust. This happens when there is a disconnct during use, the disconnect is the problem. For someone to come with something useful, lsusb, kernelversion and hardware information probably need to be included, but I´m no expert. /Henrik On 3/13/07, *Benjamin Gillam* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Why am I getting these random kernel Oops? Is it DVB's fault or something else? I have no knowledge of DVB or kernel internals... Kind regards, Benjie. [17267534.12] ehci_hcd :00:10.4 : fatal error [17267534.12] ehci_hcd :00:10.4: HC died; cleaning up [17267534.12] usb 1-3: USB disconnect, address 2 [17267534.12] dvb-usb: bulk message failed: -22 (1/-909000848) [17267534.124000 ] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully deinitialized and disconnected. [17267534.132000] BUG: unable to handle kernel paging request at virtual address 2d31005f [17267534.132000 ] printing eip: [17267534.132000] f8d89b7e [17267534.132000] *pde = [17267534.132000] Oops: [#1] [17267534.132000] SMP [17267534.132000] Modules linked in: lirc_serial binfmt_misc ipt_TCPMSS xt_tcpudp ip_nat_irc ip_nat_ftp iptable_nat cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave cpufreq_ondemand cpufreq_conservative video tc1100_wmi sbs sony_acpi i2c_ec asus_acpi it87 hwmon_vid eeprom i2c_isa ipaq usbserial ppp_async ppp_generic crc_ccitt ip6table_filter ip6_tables sbp2 lirc_dev bt878 tvaudio saa7134_alsa tda9887 tuner snd_seq_dummy snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq nvidia bttv dvb_usb_dtt200u dvb_usb saa7134 snd_bt87x snd_via82xx dvb_core dvb_pll snd_cmipci snd_opl3_lib snd_hwdep snd_mpu401_uart snd_via82xx_modem snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_rawmidi snd_seq_device video_buf v4l1_compat ir_kbd_i2c ir_common analog via_agp agpgart pcspkr v4l2_common tveeprom videodev gameport snd soundcore snd_page_alloc usbhid vesafb fbcon tileblit font bitblit softcursor vga16fb vgastate capability commoncap fan thermal processor sata_via libata sd_mod generic ide_disk ide_cd cdrom ohci1394 ieee1394 uhci_hcd ehci_hcd ide_generic reiserfs evdev sg shpchp pci_hotplug btcx_risc i2c_algo_bit i2c_viapro compat_ioctl32 serio_raw skge psmouse sk98lin floppy tsdev slhc i2c_dev i2c_core usb_storage scsi_mod libusual usbtest usbcore af_packet md_mod dm_mod ipv6 via82cxxx ext2 ext3 jbd hotkey dev_acpi ac pcc_acpi button container battery lp parport_pc ppdev parport iptable_filter xt_state ip_conntrack_ftp ip_conntrack_irc ipt_REJECT ipt_TOS ipt_MASQUERADE ip_nat ip_conntrack nfnetlink ipt_LOG iptable_mangle ip_tables xt_limit x_tables rfcomm l2cap bluetooth [17267534.132000] CPU:0 [17267534.132000] EIP:0060:[f8d89b7e]Tainted: PF VLI [17267534.132000] EFLAGS: 00010246 (2.6.17-11-generic #2) [17267534.132000] EIP is at dvb_dvr_poll+0x3e/0x90 [dvb_core] [17267534.132000] eax: ebx: 0106 ecx: f8d89b40 edx: 2d310063 [17267534.132000 ] esi: ec931960 edi: 2d310033 ebp: f70c5e9c esp: f70c5c10 [17267534.132000] ds: 007b es: 007b ss: 0068 [17267534.132000] Process mythbackend (pid: 30166, threadinfo=f70c4000 task=f2726030) [17267534.132000 ] Stack: c012b7c0 f2726030 0020 ec931960 c017e085 f70c5c54 f70c5fac [17267534.132000]a39fe3f4 a39fe3fc f70c5e94
[linux-dvb] CRC 32 information for MPEG checksum
Hi to all,
I'm doing an application to off-line analyze and edit a generic DVB TS. I
have a lot og problems with CRC32 calculation on PSI/SI tables.
I'm using a fast calculation CRC32:
poly: 0x04c11db7
table: 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc,
0x17c56b6b, etc.
algorithm:
public long CRC(byte[] by)
{
ulong ulCRC = 0x;
long len;
len = by.Length;
for(long i = 0; i len; i++)
{
ulCRC = (ulCRC 8) ^ crcLookup[by[i] ^ (ulCRC 0xFF) ];
}
return Convert.ToInt64( ulCRC ^ 0x);
}
Anyway the CRC32 value is different from CRC32 value in the last 4 byte of
the packet. Which packet bytes I have to use for CRC calculation?
Could you help me please? I'm going crazy for CRC32.:-(
Best regards,
Paolo
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] CRC 32 information for MPEG checksum
On Wed, Mar 14, 2007 at 12:37:15PM +0100, Paolo Pasquali wrote:
Hi to all,
I'm doing an application to off-line analyze and edit a generic DVB TS. I
have a lot og problems with CRC32 calculation on PSI/SI tables.
I'm using a fast calculation CRC32:
poly: 0x04c11db7
table: 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc,
0x17c56b6b, etc.
algorithm:
public long CRC(byte[] by)
{
ulong ulCRC = 0x;
long len;
len = by.Length;
for(long i = 0; i len; i++)
{
ulCRC = (ulCRC 8) ^ crcLookup[by[i] ^ (ulCRC 0xFF) ];
}
return Convert.ToInt64( ulCRC ^ 0x);
}
Try this:
for (i = 0; i len; ++i)
CRC = (CRC8) ^ crc_tab[((CRC24)^*p++) 0xff];
Wolfgang
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR4000 Support
In message [EMAIL PROTECTED], Steven Toth wrote:
Bob wrote:
hi guys
On Tuesday 13 March 2007 14:34, Steven Toth wrote:
Hi,
I've created a new tree based on the current mainline v4l/dvb tree,
Manu's multiproto patches and the HVR400 specific patches. It can be
found here http://linuxtv.org/hg/~stoth/hvr4000
I don't have any immediate hardware available for test, so your mileage
may vary.
If you'd like to spend the time testing then I'll happy take
feedback/bugs via this ML.
Looking at the patch description:
1. DVB-T is not working, pending a GPIO change
2. DiSEqC is not working
Regular DVB-S and DVB-S2 should work fine. Remember you'll need apps
that support the multiproto API's to use the S2 functionality.
Lastly, see my posting to the ML last week for instructions on obtaining
the firmware.
I will test the above sometime later, yet in the meantime I retrofitted
the cx24116 demod driver into v4l-dvb hg minus the multiproto/dvb-s2 support
and it
functions. A bug was discovered which is probably the cause of the issue
detailed below.
There is a tarball for if you are interested, plus a scan output and kaffeine
channel config for Astra-28.2E at http://dev.kewl.org/tmp/hvr4000/
Oh goody, we're getting there.
When unloading the modules, I get:
isl6421 6656 4294967295
cx2411617664 4294967295
Forcing there removal does not seem to harm the system.
I'm not too sure whether it is handling the card correctly, although
it does see it
Mar 13 20:31:49 eth5 kernel: cx2388x alsa driver version 0.0.6 loaded
Mar 13 20:31:49 eth5 kernel: PCI: Enabling device :02:0a.1 (0110 - 0112)
Mar 13 20:31:49 eth5 kernel: ACPI: PCI Interrupt :02:0a.1[A] - GSI 22
(level, low) - IRQ 217
Mar 13 20:31:49 eth5 kernel: cx88[0]/1: CX88x/0: ALSA support for cx2388x
boards
Mar 13 20:31:49 eth5 kernel: cx2388x dvb driver version 0.0.6 loaded
Mar 13 20:31:49 eth5 kernel: cx8802_register_driver() -registering driver
type=dvb access=shared
Mar 13 20:31:49 eth5 kernel: CORE cx88[0]: subsystem: 0070:6902, board:
Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=57]
Mar 13 20:31:49 eth5 kernel: cx88[0]/2: cx2388x based dvb card
Mar 13 20:31:49 eth5 kernel: cx24116: cx24116_attach
Mar 13 20:31:49 eth5 kernel: DVB: registering new adapter (cx88[0]).
Mar 13 20:31:49 eth5 kernel: DVB: registering frontend 1 (Conexant
CX24116/CX24118)...
Mar 13 20:31:50 eth5 kernel: cx2388x blackbird driver version 0.0.6 loaded
Mar 13 20:31:50 eth5 kernel: cx8802_register_driver() -registering driver
type=blackbird access=shared
Mar 13 20:31:50 eth5 kernel: CORE cx88[0]: subsystem: 0070:6902, board:
Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=57]
Mar 13 20:31:50 eth5 kernel: cx8802_register_driver() -probe failed err =
-19
Other than that, I still cannot get DVB-S or SVB-S2 to work.
That could be because my knowledge of about the sat stuff
is sadly lacking.
Bob
Thanks for the feedback.
Gregoire reported an issue via IRC today. It looks like the HVR4000
demod driver never receives the set_params call, to actually tune. I
think this is probably a bug in dvb_core - manu's patches.
I plan to repro tomorrow, expect more progress in the next day or so.
There is a bug in set_fec which sets the local FEC value
to the value retrieved from the FEC array in error.
A fix for that is here: http://dev.kewl.org/tmp/hvr4000/stoth/cx24116.diff
This ought to solve the tuning issue, yet as I have not tested the multiproto
work, I cannot say for certain.
Bye
darron
--
// /
{:)==={ Darron Broad [EMAIL PROTECTED]
\\ \
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
I've been told that the fmd1216 uses the TUA6034. But in this case it doesn't really matter, all these I2C PLLs work this way. I have an 11 year old datasheet for a Philips tuner, and it's the same way. Ack I'd like to proceed this way: - first i correct the bug in the sleep function. - When your changes in dvb-pll are in mainstream, i will adapt the code in saa7134-dvb. (you might decide to kick me) OK? My plan was to come up with a patch that converted all the users of fmd1216 at once. FMD1216ME was recently replaced by the FMD1216MEX. Not sure if this impacts on your plans. I don't have the datasheet off hand but I'm told FM tuning has changed slightly. Regards, Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DSM-CC Synchronized Download Protocol
Zitat von timecop [EMAIL PROTECTED]: DSM-CC is used a lot in ISDB-T / ISDB-S for data broadcasting and firmware download. Have a poke around http://www.dibeg.org/aribstd/ARIBSTD.htm One of B-xx standards should cover DSM-CC related stuff. I know it does because I wrote a parser for DDI and DDB messages a few months ago. By the way, the stuff follows standard section table format. -t Theres some info about transmitting data with DSM-CC stuff in B24 Vol3, but still not what i was looking for. It only covers The object and data carousel, and a method called event message which seems to be equivalent to the DVB specified do it now stream events. But i found something in the ATSC specifications. According to this the synchronized download protocol is used for non-flow-controled transmission of data in DDB messages via DSM-CC sections. Synchronisation is done by inserting PTS-references in the adaptation header. Just in case anyone cares :-) But again i found nothing about DVB having adopted this method. regards, Thomas This message was sent using IMP, the Internet Messaging Program. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DSM-CC Synchronized Download Protocol
On Wed, 14 Mar 2007, [EMAIL PROTECTED] wrote: Zitat von timecop [EMAIL PROTECTED]: DSM-CC is used a lot in ISDB-T / ISDB-S for data broadcasting and firmware download. Have a poke around http://www.dibeg.org/aribstd/ARIBSTD.htm One of B-xx standards should cover DSM-CC related stuff. I know it does because I wrote a parser for DDI and DDB messages a few months ago. By the way, the stuff follows standard section table format. -t Theres some info about transmitting data with DSM-CC stuff in B24 Vol3, but still not what i was looking for. It only covers The object and data carousel, and a method called event message which seems to be equivalent to the DVB specified do it now stream events. But i found something in the ATSC specifications. According to this the synchronized download protocol is used for non-flow-controled transmission of data in DDB messages via DSM-CC sections. Synchronisation is done by inserting PTS-references in the adaptation header. Just in case anyone cares :-) But again i found nothing about DVB having adopted this method. regards, Thomas In DVB it is used for: - firmware download - MHEG (UK interactive TV i should perhaps say) Cheers, Rudy P.S. all download specs are NDA. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Wed, 14 Mar 2007, Steven Toth wrote: My plan was to come up with a patch that converted all the users of fmd1216 at once. FMD1216ME was recently replaced by the FMD1216MEX. Not sure if this impacts on your plans. I don't have the datasheet off hand but I'm told FM tuning has changed slightly. That shouldn't make a difference. If the tuner is different enough that it needs a different configuration, then it will just need to be added as a new tuner type. Shouldn't make any difference to existing users of the fmd1216me. Of course I'm sure the card makers will switch tuners without changing their model numbers! Leading to the problem of how do you tell which tuner the card has? Maybe they'll be so kind as to stick the tuner on a different i2c address as well as put something in the eeprom. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
Hi
Trent Piepho schrieb:
On Wed, 14 Mar 2007, Hartmut Hackmann wrote:
Trent Piepho schrieb:
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
My fmd1216 patch will have the tuner init function send {0xdd, 0xa0} to the
tuner. That will set the agc value (byte AB) to 0xa0, the same thing.
That's new for me. But if the data go to the upper bytes first, you are
right.
The way the PLL works is that if the first bit of data sent is a 1, then
the next two bytes are CB+BB (or CB+AB). If the first bit is a 0, then the
next two bytes are the divisor bytes. You can send the divisor first then
the control bytes (as dvb-pll does), or the control bytes first and then
the divisor bytes. Or just the control bytes, or just divisor bytes.
If you look in the v4l tuner module, there is a special case hack to send
the divisor first or second depending on if the new frequency is less than
or greater than the old frequency.
I found the datasheet. Right, its documented there (but was new for me).
Anyway, I don't think the frequency is valid either:
divisor = 0x0bdc, ratio bits = 1,1 = 62.5 kHz, so freq = 189.75 MHz
But, BB = 0x54, which is analog mode HIGH band. 189.75 MHz would be in the
LOW band. (remember to subtract the IF frequency to compare to the
bandswitch points used in the code)
Ratio bits are 1,0 so 167kHz. But i don't think ath this is so important..
No, they are 1,1.
CB is 0x86 = 1 0 000 11 0
^ identifies this as the control bytes
^ selects low charge pump current
^^^ sets the test mode to normal mode
^^ Ratio select 1,1 = 62.5 kHz
^ Turn the tuning voltage on
I was in the wrong area, sorry. I had 0x9c in mind.
How does that happen? I figured P4 just changed the SAW filters, but it
enables/disables the tda9887 too?
I have no idea why and how this is done, i just observed that...
I wonder if this is a problem for the v4l tuner module. If one doesn't
start and then stop the dvb frontend before using analog, how does the
tda9887 get turned on?
It is a BIG problem. The tuner initialization code turns the tda9886 on,
but now things depend on the module initialization order whether the tda
is found or not. I haven't used my board in analog mode after the tda9887
merge but things look like it doesn't work any more :-(
Unfortunately i know about at least one board that needs the opposite
load order.
The documentation for the Infineon TUA6034 should be easy to find if you
don't have it. It's pretty clear that you don't need to send the divisor
bytes each time. You can just send CB+BB or in this case CB+AB. And I've
verified that indeed you can set the AGC values with just two bytes.
If this is the used PLL chip, i should have a look.
Did you check whether it is allowed to cut off the lo?
I've been told that the fmd1216 uses the TUA6034. But in this case it
doesn't really matter, all these I2C PLLs work this way. I have an 11 year
old datasheet for a Philips tuner, and it's the same way.
Ack
I'd like to proceed this way:
- first i correct the bug in the sleep function.
- When your changes in dvb-pll are in mainstream, i will adapt the code in
saa7134-dvb. (you might decide to kick me)
OK?
My plan was to come up with a patch that converted all the users of fmd1216
at once.
Ok, less work for me.
Hartmut
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
That shouldn't make a difference. If the tuner is different enough that it needs a different configuration, then it will just need to be added as a new tuner type. Shouldn't make any difference to existing users of the fmd1216me. Of course I'm sure the card makers will switch tuners without changing their model numbers! Leading to the problem of how do you tell which tuner the card has? Maybe they'll be so kind as to stick the tuner on a different i2c address as well as put something in the eeprom. You are correct. However, I know Hauppauge identify it as a new tuner type in the eeprom, that will help a little. Regards, Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] 8051 firmware disassembly
I figure this may take only a minute for the right person, and it can't hurt to ask, so ... I have a 3k firmware image for 8051. Is there anybody who can disassemble this file for me? The file seems to contain some code and some data, so naturally the disassembly will need to deduce which is which. I think the first 3 bytes are a jump instruction so there is a known code entry point. Nick. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: TwinhanDTV MagicBox Pro (DVB-T/Analogue)
I have a TwinhanDTV MagicBox Pro (DVB-T/Analogue) as listed in your Unspecified/Unkown devices section at hand. H, is there no linux driver for this one yet? I've got a Mac driver for it in my CVS repository if anyone's interested (digital part only). It uses a ULi M9207 so I imagine it'd be easy to add support for it, seeing as how you guys have already got an M920X driver. Maybe someone can do something based on this Mac driver. I did not find anything about this Box/chipset in the internet. It was not just a 5 minute search. Just bad luck? lsusb tells the following: Bus 001 Device 002: ID 13d3:3211 IMC Networks This is what usbview says: http://cstoessel.de/extern/usbview Another thing I read today is, that it can only be connected to USB 2.0. I will check this on a Windows machine tomorrow. Greetings Christian ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] 8051 firmware disassembly
On Thu, 15 Mar 2007, Nick Andrew wrote: I figure this may take only a minute for the right person, and it can't hurt to ask, so ... I have a 3k firmware image for 8051. Is there anybody who can disassemble this file for me? The file seems to contain some code and some data, so naturally the disassembly will need to deduce which is which. I think the first 3 bytes are a jump instruction so there is a known code entry point. Nick. Take a look at this: http://members.naspa.net/djs/software/dis51.html It can also be found here: http://home.earthlink.net/~davesullins/software/dis51.html It's a simple C program that disassembles 8051 code. You suggest to it the entry points to start from and it will follow through every jump it sees, hopping around through the code and hopefully skipping the unexecuted data. I have a version of this disassembler that I've heavily hacked on, where I can define symbols text annotations to be interpolated into the output - great for interative exploration of a pile of opaque 8051 code. Typically what I've done is to feed it all the architecture-defined entry points for the various processor exception addresses (like for example the spot you suspect), look at what results, remove entry points that appear not to be in use (e.g. they disassemble into gibberish), try again, etc, etc. As I spot interesting looking functions, I'll tag those addresses with symbol names then run the disassembler again to see where else those symbols might surface. It's not perfect since I don't catch split instruction address calculations or computed gotos, but usually with enough bleary-eyed staring you can start to see a pattern - and if there's a computed goto in there it can be spotted from the telltale lookup table. Then I tag each table target with another fabricated symbol and iterate again. You can certainly start with the link above. If what you see from that looks promising, then if you ask nicely I might be convinced to pretty-up my hacks and make available the results on a web page. -Mike -- | Mike Isely | PGP fingerprint Spammers Die!! | | 03 54 43 4D 75 E5 CC 92 | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | | ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Wed, 14 Mar 2007, Hartmut Hackmann wrote: How does that happen? I figured P4 just changed the SAW filters, but it enables/disables the tda9887 too? I have no idea why and how this is done, i just observed that... I wonder if this is a problem for the v4l tuner module. If one doesn't start and then stop the dvb frontend before using analog, how does the tda9887 get turned on? It is a BIG problem. The tuner initialization code turns the tda9886 on, but now things depend on the module initialization order whether the tda is found or not. I haven't used my board in analog mode after the tda9887 merge but things look like it doesn't work any more :-( Unfortunately i know about at least one board that needs the opposite load order. In the datasheet for the Philips TUV1236D tuner, it describes how the TDA9885 is turned on and off by one of the GPIO pins of the NXT2004 demodulator. The same pin also powers off and on the digital IF section, whatever that is exactly (obviously the NXT2004 isn't powering itself down with its own GPIO pin). I imagine this is a big problem for v4l, needing to talk to the ATSC demodulator to turn the analog demodulator on. Anyway, the FMD1216ME datasheet doesn't say anything about turning the TDA9887 on or off. Still, it stands to reason that Philips would have added the ability to do this for the same reason they added it to the TUV1236D. Do you have a datasheet or design guide that explains about needing to turn the tda9887 on? Is it one of the TUA6034 ports that controls it? If analog doesn't work the fmd1216, then I don't think a dvb-pll integration patch should be obligated to fix it. But, I don't want to break anything that does work now. I wonder how the other users of the fmd1216, in the cx88 and cxusb driver, work in analog mode? Maybe they don't? My plan was to come up with a patch that converted all the users of fmd1216 at once. Ok, less work for me. If you want, I can make a simple patch that fixes the bug in fmd1216me_sleep quickly to apply first. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
