Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Patch: fidbirq() with recovery after lost intr



Ralph,


1) in my patched version, there are several modifications:

I'm setting up the card with:

 saa7146_write(saa->mem, DD1_INIT, 0x020006c0);

Then, in interrupt handler I'm reading the actual field ID from the card:

   field=0x80&saa7146_read(av7110->saa_mem, PSR);

as opposite to the current code, which is changing[B DD1_INIT in every
fidbirq() call. 

With the current code, I've indeed seen calls to fidbirq with DMA pointer
below the end of the field, however, with the above modifications I've
not seen any corrupted data. 

I suspect problems you describe might appear when you write DD1_INIT for e.g. 
field 1 althouth the DMA is in field 0. Thus you need to check the real
DMA pointer in order to have real data. However, I suppose the card is
giving me always the correct field ID, so there's no packet corruption.

Could you please test my modification with your setup?

2) In case of missed interrupt - are you sure that the DMA is immediately
overwriting the old half-buffer? During debugging I've seen a lot of
occurencies when during the oldposition was below the new one,
e.g.   

TSF=1  DMApos=96256 oldpos=95880

however the data were intact (the old ones).


	With kind regards,

		M.





On Tue, Jan 21, 2003 at 02:31:36PM +0100, Ralph Metzler wrote:
> Marian Durkovic writes:
>  >    looking deeper into IRQ handler for NOVA cards I've realized that it's
>  > unnecessary complicated and lacks the functionality to recover after lost
>  > interrupt athough it's supported by hardware. 
>  > 
> 
> But that is not the reason for using the DMA pointer.
> The fidb IRQ is caused by a change in the field state input, not 
> the end of DMA transfer of one field. 
> It can happen that the DMA for one field is not yet finished when the 
> field interrupt is called. In this case some old data at the end of the 
> last field is passed down to the software filter.
> 
> It probably depends on many factors if and how often this occurs:
> processor speed, PCI hardware on board, DMA configuration and if
> other SAA DMA are running, etc.
> But it definitely does happen and caused corrupted data in the past
> until I put the "unnecessary" stuff in there.
> Btw., besides the code for handling the missed old buffer, your fidbirq() is 
> the same as our initial code without the DMA buffer checking.
> 
> The extra time from IRQ to tasklet in case of the Convergence driver 
> also might mask this case a little bit. There it might only happen
> on very fast and otherwise idle systems.
> 
> 
>  >    The card always provides access to two most recent half-buffers, which 
>  > means that if we miss one interrupt, we can always recover by outputting 
>  > the missing half-buffer in the next interrupt.
> 
> Here a similar thing can happen. Since the DMA already could have written to 
> the missed older half-buffer you are now passing some new bytes mixed
> with old bytes to the filters. Sorry, if you missed the IRQ it is too
> late. You would have to add more buffers. 
> 
> 
> Ralph


--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail: md@bts.sk        ----
----                                                                  ----
--------------------------------------------------------------------------


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



Home | Main Index | Thread Index