I actually caused this effect on accident by creating a new test & set bit:
#define IVTV_F_T_DEC_DMA_NEEDED 2
I should have given it a unique number, but instead gave it the one
that belonged to ENC_DMA_NEEDED.
Change the 2 to a 17 and then ENC & DEC work simultaneously again,
but the DEC dma stream gets corrupted.
DECtsb.diff
Description: Binary data
-Rick On Nov 20, 2005, at 5:13 PM, John Harvey wrote:
-----Original Message----- From: [EMAIL PROTECTED] [mailto:ivtv-devel- [EMAIL PROTECTED] On Behalf Of Hans Verkuil Sent: 20 November 2005 22:01 To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] ivtv framebuffer is broken with PVR350 On Sunday 20 November 2005 00:25, Ricardo Lugo wrote:"classic smp problems" means its time for more locking, no? So I played around with some of the locking of enc_work_handler and dec_work_handler: When enc_work_handler and dec_work_handler are blocked on the same lock, no freezes occur. (IE only one part of the card can work at a time: Encoder or Decoder) When I gave dec_work_handler its own lock (for all the code in the entire function), the freezes came back. (IE Encoder & Decoder working together)What is wierd about this is that I don't have to be using the Encoderfor the Decoder to freeze up! Conclusion: there must be something that the ENC functions do to (being called even when the ENC is idle) that invalidate the DEC dma stream on multi-processor (or multi-threaded) machines. IE we need more fine-grained locking.Rick, Can you mail me a patch with your changes that make it work on an smp machine? Thanks, HansAnd me as well or just mail it to the list. Thanks JOhn _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
