[linux-dvb] Suspend/resume for Mantis 2033 driver
Hi Manu and all I have done small improvements into Mantis drivers: I have fixed the insmod/rmmod problem and I have implemented suspend/resume for cu1216. It does in mantis_dvb.c power off/ power on if no application uses the frontend. So with my suspend/resume and with non-USB sound output, I am able to suspend to disk and back so that Kaffeine will continue displaying the TV channel. I use now 2.6.22.1-41.fc7 kernel. cu1216 needed only small changes with the current version. Most changes went into dvb/mantis directory. resume uses fe-opt.init for cu1216, so it must do something. resume uses fe-opt.set_frontend(fe,NULL) currently, meaning please set the previous tuning values. I need to collect the patches and clean them up before sending them for you. Regards, Marko Ristola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suspend/resume for Mantis 2033 driver
COOL!!! First driver implementing suspend/resume! Do you plan add suspend/resume also to other drivers? I can help testing dib0700/dib7000/pluto2/opera drivers Michal Dne sobota 04 srpen 2007 08:02 Marko Ristola napsal(a): Hi Manu and all I have done small improvements into Mantis drivers: I have fixed the insmod/rmmod problem and I have implemented suspend/resume for cu1216. It does in mantis_dvb.c power off/ power on if no application uses the frontend. So with my suspend/resume and with non-USB sound output, I am able to suspend to disk and back so that Kaffeine will continue displaying the TV channel. I use now 2.6.22.1-41.fc7 kernel. cu1216 needed only small changes with the current version. Most changes went into dvb/mantis directory. resume uses fe-opt.init for cu1216, so it must do something. resume uses fe-opt.set_frontend(fe,NULL) currently, meaning please set the previous tuning values. I need to collect the patches and clean them up before sending them for you. Regards, Marko Ristola ___ 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
[linux-dvb] Issue compiling latest
Hi, I just updated to latest code since I saw that there was a bunch of new changes for the dib0700, using: hg pull -u http://linuxtv.org/hg/v4l-dvb Then when I compile I get this error: $ make make -C /home/hgu/dtv/v4l-dvb/v4l make[1]: Entering directory `/home/hgu/dtv/v4l-dvb/v4l' creating symbolic links... make -C /lib/modules/2.6.20-16-generic/build SUBDIRS=/home/hgu/dtv/v4l-dvb/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.20-16-generic' Building modules, stage 2. MODPOST 190 modules WARNING: dib0070_wbd_offset [/home/hgu/dtv/v4l-dvb/v4l/dvb-usb-dib0700.ko] undefined! make[2]: Leaving directory `/usr/src/linux-headers-2.6.20-16-generic' ./scripts/rmmod.pl check found 190 modules make[1]: Leaving directory `/home/hgu/dtv/v4l-dvb/v4l' Did a make clean first as well, this is the second make call. Did a search to try to find the issue in the v4l-dvb code, I'm new to this code but to me it looks like it export the symbol: $ grep -riI 'dib0070_wbd_offset' * linux/drivers/media/dvb/frontends/dib0070.c:u16 dib0070_wbd_offset(struct dvb_frontend *fe) linux/drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_wbd_offset); linux/drivers/media/dvb/frontends/dib0070.h:extern u16 dib0070_wbd_offset(struct dvb_frontend *); linux/drivers/media/dvb/dvb-usb/dib0700_devices.c: deb_info(WBD for DiB7000P: %d\n, offset + dib0070_wbd_offset(fe)); linux/drivers/media/dvb/dvb-usb/dib0700_devices.c: dib7000p_set_wbd_ref(fe, offset + dib0070_wbd_offset(fe)); v4l/dib0700_devices.c: deb_info(WBD for DiB7000P: %d\n, offset + dib0070_wbd_offset(fe)); v4l/dib0700_devices.c: dib7000p_set_wbd_ref(fe, offset + dib0070_wbd_offset(fe)); v4l/dib0070.c:u16 dib0070_wbd_offset(struct dvb_frontend *fe) v4l/dib0070.c:EXPORT_SYMBOL(dib0070_wbd_offset); v4l/dib0070.h:extern u16 dib0070_wbd_offset(struct dvb_frontend *); I did build 2 weeks ago without any problems. I run it on a Ubuntu 7.04machine: $ uname -a Linux hgu 2.6.20-16-generic #2 SMP Thu Jun 7 19:00:28 UTC 2007 x86_64 GNU/Linux Do I need to upgrade to a newer kernel, to use this latest code? Or maybe the dib0070 instead of dib0700 is a problem? I have a Hauppauge NOVA-T 500 PCI, so I use this specific module. I appreciate any help for finding the issue, as said before I'm new to the v4l-dvb code and compiling kernel modules. Harald ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suspend/resume for Mantis 2033 driver
Hi Marko,
On 8/4/07, Marko Ristola [EMAIL PROTECTED] wrote:
Hi Manu and all
I have done small improvements into Mantis drivers:
I have fixed the insmod/rmmod problem and I have implemented
suspend/resume for cu1216.
It does in mantis_dvb.c power off/ power on if no application
uses the frontend.
Normally we handle this in the frontend. ie in this case cu1216
You can put the CU1216 into STANDBY using Reg:0x00 Bit:7
So with my suspend/resume and with non-USB sound output,
I am able to suspend to disk and back so that Kaffeine will
continue displaying the TV channel.
I use now 2.6.22.1-41.fc7 kernel.
cu1216 needed only small changes with the current version.
Most changes went into dvb/mantis directory.
You will need 2 callbacks, one for suspend, one for resume: both
handling the power control to the frontend/tuner. This will control
power ON/OFF from the PCI interface POV, to the entire frontend,
rather than a STANDBY.
resume uses fe-opt.init for cu1216, so it must do something.
Probably, a tune again with the cached params would be all that's
needed, since init is empty.
The init should start by setting Reg:0x00 Bit:7, such that the
frontend resumes from Standby.
(A bit confused with all the different suspends, is this S2RAM or
S2DISK or Hibernate ? The suspend folks were discussing on how to
create a memory snapshot: wondering whether our memory states for the
previous successful states would be there)
resume uses fe-opt.set_frontend(fe,NULL) currently, meaning
please set the previous tuning values.
yeah, that would be a quick way to handle it, though it could be a
problem when the frontend_params is really null in a normal case.
A better way would be: from the resume callback, pass the cached
parameter straight away
to cu1216_set_parameters(). That way you wouldn't need to handle the
problem when params=NULL
You will have the last cached state in params:
struct cu1216_state {
struct i2c_adapter *i2c;
struct dvb_frontend_ops ops;
/* config settings */
const struct cu1216_config *config;
struct dvb_frontend frontend;
u8 pwm;
u8 reg0;
struct dvb_frontend_parameters params;
};
I need to collect the patches and clean them up before sending them for you.
Cool. The last update from my side is at: http://jusst.de/hg/v4l-dvb/
Thanks,
Manu
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suspend/resume for Mantis 2033 driver
Thankyou for your feedback. Maybe others can implement full suspend/resume on other drivers too, because we have one more working example. It is better that I try to concentrate on Mantis, because then I can be helpful without trying too much. My current focus is to implement suspend/resume (S2DISK, resume from there) into all Mantis drivers on Manu's branch with minimal Mantis frontend changes. All my changes went into dvb/mantis/ and dvb/frontends/cu1216.c, so that dvb/dvb_core/ directory didn't need any changes and thus my implementation should be copiable at least into all PCI based DVB cards. My plan is also, that with my initial implementation as a start, Mantis drivers can be made more fine-grained (S2MEM, Hibernate, ?). I don't know how to do suspend/resume with USB. Somebody else could try to figure out what is necessary with USB suspend/resume. My version does 1. Mantis driver suspend (did we have DMA transfer?) 2. Mantis driver PCI suspend (mantis_pci.c) 3. Linux completes the S2DISK and does full power off. 4. Computer gets power back and Linux starts with grub and Linux begins resume from DISK. 5. Mantis driver PCI resume (mantis_pci.c, restore PCI configuration) 6. Mantis driver resume (restore Mantis power configuration, tune frequency, restore DMA transfer). So tasks 2 and 5 are different for USB hardware. I will send patches into this email list for Manu. You can take source code copies for other drivers too. I will release my patches probably with GPLv3 so that they can be incorporated into Linux kernel and modified/copied when necessary for other drivers. I looked that pluto2 is a PCI device. Thus my future Mantis patches could be used as a sample to implement suspend/resume for it. For USB devices, cinergyT2 has suspend/resume implementation. If you or somebody wants, he can try to implement suspend/resume into pluto2 for example, and maybe I am able to help him to succeed. Best regards, Marko Ristola CIJOML wrote: COOL!!! First driver implementing suspend/resume! Do you plan add suspend/resume also to other drivers? I can help testing dib0700/dib7000/pluto2/opera drivers Michal Dne sobota 04 srpen 2007 08:02 Marko Ristola napsal(a): Hi Manu and all I have done small improvements into Mantis drivers: I have fixed the insmod/rmmod problem and I have implemented suspend/resume for cu1216. It does in mantis_dvb.c power off/ power on if no application uses the frontend. So with my suspend/resume and with non-USB sound output, I am able to suspend to disk and back so that Kaffeine will continue displaying the TV channel. I use now 2.6.22.1-41.fc7 kernel. cu1216 needed only small changes with the current version. Most changes went into dvb/mantis directory. resume uses fe-opt.init for cu1216, so it must do something. resume uses fe-opt.set_frontend(fe,NULL) currently, meaning please set the previous tuning values. I need to collect the patches and clean them up before sending them for you. Regards, Marko Ristola ___ 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] [RFC PATCH] Choose dvb adapter number with a driver specific module option
On Saturday 04 August 2007 07:00:42 you wrote: On 8/4/07, Manu Abraham [EMAIL PROTECTED] wrote: On 8/4/07, Michael Krufky [EMAIL PROTECTED] wrote: Manu Abraham wrote: On 8/4/07, Janne Grunau [EMAIL PROTECTED] wrote: On Saturday 04 August 2007 00:02:29 Manu Abraham wrote: Do we really want to have adapter numbers in DVB bridge drivers ? IMHO, it doesn't look pleasing to have that. I think it's worthwhile to have it. Is there any other possible better alternatives ? Something similiar is possible with udev rules but I wouldn't say that it is a better alternative. Why ? If you can achieve the same without any code change, doesn't that look better ? using a module option to specify adapter number is a _much_ more user friendly solution, as opposed to udev rules. Yuck. I just wonder why other char drivers in the Linux kernel do not have such a necessity, you have the same problem there as well. The video4linux driver have this. btw, though not directly related this thread on LK deals with the same root cause http://lkml.org/lkml/2007/8/2/82 The thread shows why I prefer my patch over a udev solution. 1. The numbers in the kernel log will match the contents of /dev/dvb 2. The patch will handle the replacement of one card with the same type and shuffling of cards in your PCI slots while udev will break one of them. Udev can either identify the cards by path (this will break shuffling of cards) or by ids (mac, usb serial no) (this will break replacement). So I think the patch has its merits. Janne ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Suspend/resume for Mantis 2033 driver
Manu Abraham wrote:
Hi Marko,
On 8/4/07, Marko Ristola [EMAIL PROTECTED] wrote:
Hi Manu and all
I have done small improvements into Mantis drivers:
I have fixed the insmod/rmmod problem and I have implemented
suspend/resume for cu1216.
It does in mantis_dvb.c power off/ power on if no application
uses the frontend.
Normally we handle this in the frontend. ie in this case cu1216
You can put the CU1216 into STANDBY using Reg:0x00 Bit:7
I have tested only S2DISK, so the PCI and all other hardware
loses all power.
I tried to implement both S2DISK and S2MEM initially, but
problem solving was too difficult and then I dropped S2MEM.
Maybe it is easier then to add S2MEM and hibernate support,
when S2DISK works.
So with my suspend/resume and with non-USB sound output,
I am able to suspend to disk and back so that Kaffeine will
continue displaying the TV channel.
I use now 2.6.22.1-41.fc7 kernel.
cu1216 needed only small changes with the current version.
Most changes went into dvb/mantis directory.
You will need 2 callbacks, one for suspend, one for resume: both
handling the power control to the frontend/tuner. This will control
power ON/OFF from the PCI interface POV, to the entire frontend,
rather than a STANDBY.
I used mantis_dvb.c's implementation of tuner power on/off.
I used cu1216_init (cu1216_init_none called it)
for fe-ops.init to reinitialize cu1216 on resume after S2DISK.
resume uses fe-opt.init for cu1216, so it must do something.
Probably, a tune again with the cached params would be all that's
needed, since init is empty.
The init should start by setting Reg:0x00 Bit:7, such that the
frontend resumes from Standby.
(A bit confused with all the different suspends, is this S2RAM or
S2DISK or Hibernate ? The suspend folks were discussing on how to
create a memory snapshot: wondering whether our memory states for the
previous successful states would be there)
With your help, the implementation might become a bit simpler
and a lot better and fine-grained.
resume uses fe-opt.set_frontend(fe,NULL) currently, meaning
please set the previous tuning values.
yeah, that would be a quick way to handle it, though it could be a
problem when the frontend_params is really null in a normal case.
A better way would be: from the resume callback, pass the cached
parameter straight away
to cu1216_set_parameters(). That way you wouldn't need to handle the
problem when params=NULL
Within mantis_dvb.c I tried to do on suspend
cu1216:get_parameters(fe, params), but that locked up almost always
and S2DISK didn't save it's state into swap space.
Thus I decided to not call get_parameters and used the NULL workaround
to inform cu1216_set_parameters() to do the previous tuning.
Currently I do set_parameters() only if DMA transfer was going on during
suspend.
So I did power up on mantis_dvb.c and then called cu1216.c init
and then called cu1216_set_parameters() to tune into the correct
frequency and then called mantis_dma_start() to restore DMA transfer.
I didn't have to wait for a lock to start the DMA transfer. Thus the resume
code is rather simple.
Of course I had to do all PCI stuff and Mantis init and internal Mantis
IRQ restore after computer
power off state.
You will have the last cached state in params:
struct cu1216_state {
struct i2c_adapter *i2c;
struct dvb_frontend_ops ops;
/* config settings */
const struct cu1216_config *config;
struct dvb_frontend frontend;
u8 pwm;
u8 reg0;
struct dvb_frontend_parameters params;
};
I need to collect the patches and clean them up before sending them for you.
Cool. The last update from my side is at: http://jusst.de/hg/v4l-dvb/
Thankyou. I downloaded it. It takes some time to make the patches.
Thanks,
Manu
Thanks,
Marko
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Terratec Cinergy DT XS Diversity remote woes
Solved. :) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Hauppauge NOVA-T-500 USB Disconnect with *-03-pre1.fw
Hi, Unfortunately I'm still seeing the USB disconnects even with the new firware and drivers on a new Hauppauge NOVA-T-500. I have confirmed that I am using the *-03-pre1.fw and that the dvb drivers/modules have all been built from hg. Details below: hg repository :- Latest taken 2 Aug 2007 using hg clone http://linuxtv.org/hg/v4l-dvb Firmware:- 0b39b8cceb1ccdb86d6fc932149aff25 dvb-usb-dib0700-03-pre1.fw System:- Linux mythtv-desktop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux ASUS Pundit P1-AH2 Error:-(just a small sample from the log) usb 3-1: USB disconnect, address 2 Aug 4 22:23:19 mythtv-desktop kernel: [27214.00] mt2060 I2C read failed Aug 4 22:23:19 mythtv-desktop kernel: [27214.008000] mt2060 I2C read failed Aug 4 22:23:19 mythtv-desktop kernel: [27214.016000] mt2060 I2C read failed Aug 4 22:23:19 mythtv-desktop kernel: [27214.124000] usb 3-1: USB disconnect, address 2 Aug 4 22:23:19 mythtv-desktop kernel: [27214.164000] mt2060 I2C write failed Aug 4 22:25:19 mythtv-desktop kernel: [27333.908000] mt2060 I2C write failed (len=2) Aug 4 22:25:19 mythtv-desktop kernel: [27333.908000] mt2060 I2C write failed (len=6) Any ideas? Is it related to the kernel version I am using? I would be happy to supply any additional data required. Andy ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problems with SMP (i.e. dualcore) system: dvb-ttpci: warning: timeout waiting in LoadBitmap
Sven Mueller wrote: Oliver Endriss wrote on 01/08/2007 00:27: Sven Mueller wrote: Hi. I don't know which hardware interrupts those are mapped from/to and currently don't know how to find out. If you need any further data to give a helpful answer, don't hesitate to ask. Which firmware are you using? Most recent AFAICT (261f). Nope, the most recent firmware is http://linuxtv.org/downloads/firmware/dvb-ttpci-01.fw-2622 or the latest experimental firmware http://www.suse.de/~werner/test_av-f12623.tar.bz2 A log showing driver startup might be useful. Do you mean this? dvb-ttpci: gpioirq unknown type=0 len=0 dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 8000261f dvb-ttpci: firmware @ card 1 supports CI link layer interface dvb-ttpci: Crystal audio DAC @ card 1 detected dvb-ttpci: found av7110-0. Does OSD work fine before the error occurres? Yes Does the VDR recover if you wait some time (1 or 2 minutes) before you press the next key? Sometimes (if I interpret things correctly though, this is due to an internal watchdog in VDR triggering a restart, which now, on my system, includes module unload/reload due to my problems). With recent firmware VDR should recover _without_ emergency exit. You might also try whether this driver improves things: http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring/ Will take a look into that later once I find some time. One think fixed the problem for me, for now though: noapic nolapic on the kernel commandline (grub). Are you sure that this did not disable SMP? However the system runs stable in every other aspect, so it seems to me that enabling apic/lapic does something which the dvb_ttpci driver doesn't handle properly on SMP systems. There is no special handling for SMP or non-SMP systems. Of course there might be a bug which will only show up with SMP. :-( CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
