Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
I didn't reviewed yet the tea5767 changes. I expect to do it later this week (maybe today night). Thank you -- I appreciate that. I did just a quick test yesterday. I didn't analyzed the source code yet. Basically, tea5767 didn't work: Those are the _normal_ logs from tip: Linux video capture interface: v2.00 cx88/0: cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt :05:07.0[A] - Link [APC2] - GSI 17 (level, low) - IRQ 74 cx88[0]: subsystem: :, board: PixelView PlayTV Ultra Pro (Stereo) [card=27,insmod option] cx88[0]: TV tuner type 59, Radio tuner type -1 tveeprom 0-0050: Huh, no eeprom present (err=-121)? input: cx88 IR (PixelView PlayTV Ultra as /class/input/input7 cx88[0]/0: found at :05:07.0, rev: 5, irq: 74, latency: 32, mmio: 0xc800 tuner 0-0060: TEA5767 detected. tuner 0-0060: chip found @ 0xc0 (cx88[0]) tuner 0-0060: type set to 62 (Philips TEA5767HN FM Radio) tuner 0-0061: chip found @ 0xc2 (cx88[0]) tuner 0-0061: type set to 59 (Ymec TVision TVF-5533MF) cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 cx88[0]/0: registered device radio0 On this log, tea5767 were correctly autodetected at 0x60 and TVF-5533MF at 0x61. -- Those are the logs with your patch series applied: Linux video capture interface: v2.00 cx88/0: cx2388x v4l2 driver version 0.0.6 loaded ACPI: PCI Interrupt :05:07.0[A] - Link [APC2] - GSI 17 (level, low) - IRQ 74 cx88[0]: subsystem: :, board: PixelView PlayTV Ultra Pro (Stereo) [card=27,insmod option] cx88[0]: TV tuner type 59, Radio tuner type -1 tveeprom 0-0050: Huh, no eeprom present (err=-121)? input: cx88 IR (PixelView PlayTV Ultra as /class/input/input6 cx88[0]/0: found at :05:07.0, rev: 5, irq: 74, latency: 32, mmio: 0xc800 i2c_adapter i2c-0: sendbytes: error - bailout. It is not a TEA5767. Received -14 bytes. tuner 0-0060: chip found @ 0xc0 (cx88[0]) tuner-simple 0-0060: type set to 59 (Ymec TVision TVF-5533MF) tuner 0-0060: type set to Ymec TVision TVF-5533MF tuner 0-0061: chip found @ 0xc2 (cx88[0]) cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 cx88[0]/0: registered device radio0 It seems that I2C reported -EFAULT (-14) to the autoprobe code. Since tea5767 weren't detected, TVF-5533MF were also missdetected as address 0x60, instead of 0x61. Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Mauro Carvalho Chehab wrote: I didn't reviewed yet the tea5767 changes. I expect to do it later this week (maybe today night). Thank you -- I appreciate that. I did just a quick test yesterday. I didn't analyzed the source code yet. Basically, tea5767 didn't work: i2c_adapter i2c-0: sendbytes: error - bailout. It is not a TEA5767. Received -14 bytes. It seems that I2C reported -EFAULT (-14) to the autoprobe code. Since tea5767 weren't detected, TVF-5533MF were also missdetected as address 0x60, instead of 0x61. Mauro, Thank you for testing -- otherwise we might not have noticed this problem right away. I have found the problem, and corrected it in my tree. During the autodetection function, an i2c read operation was unintentionally converted into an i2c write operation -- that is fixed now. Please update and test again. Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Hauppauge NOVA-T Stick 2: USB Disconnect with *-03-pre1.fw
Have you connected the Nova-T Stick directly to the computer? I have had USB disconnect problems with the WinTV PVR USB2 using a D-Link 7 ports USB hub but have had none with a 7 ports USB hub from Sandberg. Even though the quick start manual from Hauppauge says you should connect the Stick directly to the computer and avoid USB hubs I have had no problems connecting 8 sticks to Sandberg hubs. Have never seen a USB disconnect on these devices with this hub not even when connecting the two hubs in cascade. Peter 2007/8/9, Soeren Moch [EMAIL PROTECTED]: Unfortunately I have to report another USB disconnect. Using the *-03-pre1.fw for my Nova-T Stick 2 (DiB7000P) I had 1 disconnect within the last 10 days (1 disconnect within 5 minutes with older firmware and hg drivers). Although the new firmware is much better, all types of dib0700 devices still seem to suffer from the old disconnect problem (as reported by different people on the list). S:oren ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suspend/Resume support for budget-av
Oliver Endriss wrote: Marko Ristola wrote: I did for the Mantis branch a working solution for mem and disk cases. I haven't tested standby yet, but I think that it should be easy to extend if it doesn't work yet. I used linux/Documentation/power/*.txt while trying to understand how to implement suspend/resume. On my opinion, the easiest way to make standby+mem+disk work, is to implement suspend() so, that you assume that you might lose the power if the source transition is D0. If the source transition state is another one, you just turn some power off, but don't touch the saved state that resume() needs. (My implementation doesn't handle source transition at all now, because of my limited time.) Then you must implement resume() so, that it assumes, that you are recovering from a power loss. You might try to optimize resume() by checking from the device or from some previous kernel state, whether the device has actually lost it's power or not. My Mantis suspend/resume altered too many files, and thus it isn't final yet, but it is a working although not perfect version. In Linux code, there is a more simple PCI suspend/resume implementation in linux/drivers/pci/pci-driver.c. pci_device_suspend(): this does a very simple and basic PCI suspend operation. pci_default_resume(): this does a very simple and basic PCI resume operation. So I will try to learn from them some day to lessen changes in mantis_pci.c. My personal idea for the responsibilities is that: pci_save_state() and pci_restore_state() and other function calls found in pci-driver.c will handle saving and restoring PCI state, although I absolute must copy them into mantis_pci.c. Then on resume, I have to restore non-pci states, I mean those that aren't restored by pci_restore_state(), pci_set_master() and such. In Mantis there is according to Manu at least tuner power setting and retuning. I don't know the working and optimally small solution yet that Manu requires: there is still testing to be done for me in Mantis. With a very small understanding, I have been able to implement a working patch though. So I'd suggest for you to check out drivers/pci/pci-driver.c first to implement similar PCI functionality into budget-av. That might fix S2MEM and S2DISK. Or then there is still something more that has to be done. With my implementation I can use Kaffeine so, that after S2DISK, Kaffeine will continue showing the channel that it showed before. Kaffeine doesn't have to retune or restart DMA transfer. So only some frames were lost. Kaffeine didn't work properly with USB based sound output, and thus I needed motherboard internal sound output for the tests. Thanks for your response. Meanwhile I had a look at Documentation/power and did more tests. Great. For a proper suspend/restore implementation there is much more to be done. The state of the saa7146 must be saved/restored, which requires more than a few hours of work (and testing!). I put it on my todo list. Is there any way to find out the power state the system tries to enter (standby/mem/disk)? static int mantis_pci_suspend(struct pci_dev *pdev, pm_message_t mesg); Here mesg.event (defined in linux/pm.h) contains the state transition message on suspend() function. mesg.event suspend states (PM_EVENT_SUSPEND, PM_EVENT_FREEZE and PM_EVENT_PRETHAW) are documented in (latest Linus) kernel sources in Documentation/power/devices.txt. (I understood devices.txt better than the documentation in linux/pm.h). It seems to me that if mesg.event is PM_EVENT_PRETHAW, the computer is doing suspend() to disk and in that case the hardware state will be invalid on resume(). suspend() to mem: hardware state will not be invalid on resume. It seems that with these messages, it isn't easy to distinguish standby and suspend to mem target states. Maybe they are thought to behave similarily. For now, I could add support for standby mode and deny any attempt to enter mem or disk supend mode. Better than nothing... So maybe it suffices to deny the PM_EVENT_PRETHAW case and quiesce the driver in PM_EVENT_SUSPEND? CU Oliver CU Marko ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
On Sat, 18 Aug 2007, Michael Krufky wrote: For the past few months, I've been working on refactoring the analog tuner.ko module, such that all hardware-specific code can be separated into dvb_frontend style tuner modules. [...] Acked-by: Mike Isely [EMAIL PROTECTED] I've studied the code and it is undeniable that these changes lower the entropy here - long overdue. I've also read through the discussion thread here so I'll add my $0.02 as well... Looked at from where I'm sitting the core issue has to do with the intended use of the front end interface. Not being a DVB expert (I've spent my life here wading through the V4L side), the question has to be: Is the DVB front end interface supposed to provide a clean abstraction to operate tuners or is it primarily only ever for the use of the DVB core? If it is supposed to be that clean abstraction, then it makes sense to extend that interface to CLEANLY include the ability to operate things that perhaps the DVB core is not going to care about - and bolting on a hidden assumed interface through a void pointer (even if that has been the pattern in the past here) is hardly clean. In fact, if that void pointer is harboring a pile of function pointers, then the lack of type checking there is just going to be an open sore for run-time accidents in the future. Mike's approach to add another method which is by nature null-initialized and also explicitly null-checked by its caller, is a nice clean way to extend the API. As I said, if this API's current purpose (maybe not past purpose) is to correctly abstract operation of a tuner then it needs to be done cleanly and fairly for all possible uses of it, including those outside of DVB. What Mike has done fits in with that approach. If on the other hand the front end interface is forever to be ruled and driven only by the needs of the DVB core and nobody is going to accept extending the interface in ways that perhaps the DVB core isn't going to use (or otherwise even be bothered about) but others might use, then perhaps people should be considering a whole separate tuner API, designed from the ground up with the requirements for operation of all possible known tuners through it. That would provide the focal point for merging the two tuner sides together, and not be biased towards DVB or V4L. Of course the reality is that we want to merge this, right? And it needs to be done in an efficient manner, with minimal pain. Minimal pain would probably rule a whole new API. So how about we extend the DVB front end API? And if that can be done without impact to the existing use of the API - and without creating a type casting minefield, or additional CPU overhead, then I don't see a downside there. That's pretty much what Mike has here. Hans' suggestion to move the analog parameters struct definition out of the way is also fine with me, but I don't think it's really needed. -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
