[linux-dvb] Re: AV7110 stable protocol proposal

[Ralph Metzler <rjkm@metzlerbros.de>]

Emard writes:
 > > How are you going to keep this running? By polling? How else can you know
 > 
 > Yes, first by polling. I hope (not sure though) that 7146 can 
 > issue DEBI interrupt when something arrives from the other end,

That is not the question.
You need to know when the ARM is finished with transferring something.


 > Knowing that ARM finished transfer is not enough, there needs to be
 > some redundancy in the protocl. The protocol has to be designed that
 > it can work in polling mode, while if there's interrupt available,
 > it can speeds things up. Relying only on interrupt as a sign of 
 > data validity is not good.

The interrupt is also currently just a side product which guarantees
quick response from the PC. You could use the current protocol without
interrupts.

 
 > > How is this response transferred? Again by polling on the other side?
 > > Or do we need some kind of interrupt to keep this running without 
 > > much overhead? Hmm, let's just call it GPIO interrupt ...
 > 
 > OK let it be gpio, but again, the thing has to work in polling-only
 > mode for the guaranteed stability. Interrupts can happen twice,
 > overlap or be lost, while the data must always be consistant. So the
 > last intrinsic write must be a validity token for the transmission.

If such interrupts overlap something is broken and it should be fixed.
It should not happen. 
One problem I see is interrupt registers being set/reset in tasklets 
instead of the hardware IRQ. This should always be handled during the
hardware IRQ (when the IRQ itself is disabled) or it practically invites 
race conditions. Only lower level stuff like buffer queue processing 
should go into the tasklets.


 > > Finally, what exactly is the problem you are having with the 
 > > combined GPIO/DEBI IRQs?
 > > When do problems occur and with which firmware/driver?
 > 
 > Mutual exclusion of DEBI and GPIO is the problem. wait_for_debi_done()
 > and userspace communication with DEBI/GPIO is problem.

What is the maximum loop count you get in wait_for_debi_done()?


 > > Maybe something went wrong when moving to tasklets, which I (for
 > > good reasons) did not yet do.
 > 
 > Even without tasklets, this code still crashes in my tests. 
 > To prove the code stability, code has to pass fast reopening 
 > of the frontend and fast setting/resetting of promisc flag.
 > 
 > ifconfig dvb0_0 promisc; ifconfig dvb0_0 -promisc 

This has nothing to do with any IRQ instabilities. I have explained
before what causes it.
I also said before that it can also happen with budget cards if a
semaphore in dvb_sw_demux.c is down. It is just very unlikely 
because usually nobody opens any other filters when setting up
networking.
So, this example does not count :-)
What other crashes or oopses do you get?

 
Ralph


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.