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
Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option
Janne Grunau wrote:
> Hi,
>
> Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
> result in deterministic dvb adapter numbers.
>
> V4L drivers have the {radio|vbi|video}_nr module options to allocate
> static minor numbers per driver.
> Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
> problems with device unplugging and repluging each driver holds
> a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
> options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
> reversed allocation of adapter numbers.
> With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
> are already in use it will allocate the lowest free adapter number.
>
> Besides following changes in dvb-core and dvb-usb core the patch adds to
> all drivers
> ...
While I don't care much whether there is an option for this in the
driver, I'd like to point out that this is the wrong approach (imho).
Citing Greg Kroah-Hartman (udev-113/docs/udev_vs_devfs):
|...
|2) udev does not care about the major/minor number schemes. If the
| kernel tomorrow switches to randomly assign major and minor numbers
| to different devices, it would work just fine (this is exactly
| what I am proposing to do in 2.7...)
|3) This is the main reason udev is around. It provides the ability
| to name devices in a persistent manner. More on that below.
|...
According to this, adding such an option is a step into the wrong
direction. The right way is to fix the udev scripts...
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
[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] 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
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, ¶ms), 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] [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
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
[linux-dvb] Terratec Cinergy DT XS Diversity remote woes
Hi,
I'm using Gentoo's v4l-dvb-hg package and the dvb-usb-dib0700-03-pre1.fwfirmware
The card works perfectly otherwise, but the module is very sluggish in
responding
to remote codes (and the remote seems to send different codes then defined
in dib0700_devices.c)
and I have to press buttons on the remote several times very fast for it to
respond.
How can I make it respond faster and why are the remote controller key codes
different in the source code?
Pressing the Power button of the remote in rapid succession for about 10
second
(I added the F,7E code to the key codes list myself)
Aug 4 17:56:21 fantasy dib0700: Unknown remote controller key : 17 3F
Aug 4 17:56:22 fantasy dib0700: got key[] = { 0, 1, 13,36}
Aug 4 17:56:22 fantasy dib0700: Unknown remote controller key : 13 36
Aug 4 17:56:22 fantasy dib0700: got key[] = { 0, 0, 17,3F}
Aug 4 17:56:22 fantasy dib0700: Unknown remote controller key : 17 3F
Aug 4 17:56:22 fantasy dib0700: got key[] = { 0, 1, F,7E}
Aug 4 17:56:22 fantasy dib0700: got key[] = { 0, 0, 17,3F}
Aug 4 17:56:22 fantasy dib0700: Unknown remote controller key : 17 3F
Aug 4 17:56:22 fantasy dib0700: got key[] = { 0, 1, F,7E}
Same for "OK" button:
Aug 4 18:00:54 fantasy dib0700: got key[] = { 0, 0, 13,21}
Aug 4 18:00:54 fantasy dib0700: Unknown remote controller key : 13 21
Aug 4 18:00:55 fantasy dib0700: got key[] = { 0, 1, 7,43}
Aug 4 18:00:55 fantasy dib0700: Unknown remote controller key : 7 43
Aug 4 18:00:55 fantasy dib0700: got key[] = { 0, 0, 13,21}
Aug 4 18:00:55 fantasy dib0700: Unknown remote controller key : 13 21
Aug 4 18:00:55 fantasy dib0700: got key[] = { 0, 1, 7,43}
Aug 4 18:00:55 fantasy dib0700: Unknown remote controller key : 7 43
Aug 4 18:01:00 fantasy dib0700: got key[] = { 0, 0, 13,21}
Aug 4 18:01:00 fantasy dib0700: Unknown remote controller key : 13 21
Also a snippet of the dib0700_devices.c
if (key[0]==0 && key[1]==0 && key[2]==0 && key[3]==0) return 0;
if (key[3-1]!=st->rc_toggle) {
err("got key[] = {%2X, %2X,
%2X,%2X}",(int)key[3-0],(int)key[3-1],(int)key[3-2],(int)key[3-3]);
for (i=0;iprops.rc_key_map_size; i++) {
if (keymap[i].custom == key[3-2] && keymap[i].data
== key[3-3]) {
*event = keymap[i].event;
*state = REMOTE_KEY_PRESSED;
st->rc_toggle=key[3-1];
return 0;
}
}
err("Unknown remote controller key : %2X
%2X",(int)key[3-2],(int)key[3-3]);
st->rc_toggle=key[3-1];
Br, Veli-Matti
___
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
[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
