On Mon, Jul 25, 2005 at 12:39:55AM +0200, Johannes Stezenbach wrote:
> On Mon, Jul 25, 2005 at 12:05:59AM +0200, Adam Szalkowski wrote:
> > > Is the patch below what you meant? If yes, can you try a smaller
> > > msleep, maybe 15 msecs?
> > 15ms were to little but 30ms worked.
> > Still one little question remains: Why does that work?
> > And what about other hardware with cx24110?
>
> I've no idea, maybe Peter can comment? I'm comitting this
> to CVS now, let's see how it works for other people.
Actually, I think I may have an explanation for this:
for (i=500; i-- > 0 && !(cx24110_readreg(state,0x76)&0x40);)
; /* wait for LNB ready */
This code, besides hammering remoreselessly on the i2c bus, also returns
after 500 loops regardless whether the cx24110 has finished sending the
message or not. Besides, 500 is a rather arbitrary number.
The additional delay will probably help because either
- the previous message/burst was not completed after 500 i2c reads
- or the DiSEqC device expects some delay (say, 30 msec) between
two "transactions" (the message and the burst)
for (i=100; i-- > 0 && !(cx24110_readreg(state,0x76)&0x40);)
msleep(1); /* wait for LNB ready */
This is a far better solution, but I simply did not think of it.
How long does a cx24110_readreg take? Depends on the i2c implementation,
wheteher it uses the i2c HW of the 878 or a bit-banging algorithm, and
whether the i2c is running at 100 or 400 kHz. Back when I originally wrote
this code, the i2c was rather slow, and 500 was an adequate number. Today,
i2c handling may have changed, and may have speeded up...
- One question comes to mind... I assume waiting via msleep is "busy
waiting", i.e. no other task can run during this time? Is this a good idea
to have the whole machine wait for up to 100 msec? Imagine a box with more
than one dvb card, would it do to have all streams stall for 100ms just
because one of the dvb devices wants to switch to a different dish setting?
So, rather than waiting AFTER sending te message, we could return to user
mode immediately. When the next DiSEqC function is called, we then need to
check whether the DiSEqC hardware is free, and only wait if not. This would
give the application the chance to do a non-blocking wait.
Or is it possible to do an non-blocking wait within the driver?
- Other HW with the cx24110: I do not know of any other hardware using the
cx24110/hm1222 or cx24106/hm1221 chips.
Regards,
Peter
--
"Only wimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)"
(Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20050726/ac113b99/attachment.pgp
