On Mon, 2010-01-18 at 19:06 -0600, Chris Kennedy wrote: > On Mon, Jan 18, 2010 at 07:37:29PM -0500, Andy Walls wrote: > > On Tue, 2010-01-19 at 00:53 +0100, Hans Verkuil wrote: > > > On Monday 18 January 2010 23:07:31 Andy Walls wrote: > > > > > > > > > > So there appears to be a tension between the embedded systems case > > > > (single processor with devices with hardware and resource limits) and > > > > the desktop/server case (multiple processor with very capable hardware). > > > > > > > > > > > > Hans, > > > > > > > > Now I understand your question better, if you were thinking along an > > > > embedded system context. > > > > > > Actually, I'm only getting more confused. > > > > Yeah, I am too. > > > > Which is likely why I find the warning with no recommended corrective > > action so annoying. (In general, detection without response is > > pointless.) > > > > > > > The Linux Device Drivers book says > > > something quite different from what I gather from this thread. And the > > > thread > > > itself fizzles out too without much of a conclusion. Apparently the > > > consensus > > > seems to be that this flag should be removed, but it's pretty fuzzy on > > > what > > > the consequences of that removal would be. > > > > Yup. I didn't even care at the time. I just wanted someone to tell me > > what the prefered action to take in light of the warning message. I > > received no answer. > > > > No answer is an answer in and of itself for me: do nothing. > > When I was experimenting with the driver, I tried removing SA_INTERRUPT > which seems to now be called IRQF_DISABLED. It resulted in random > lockups, hard lockups without any messages on the screen or logs. > At least if I remember correctly, I know I had removed it and know it > was put back in my tests. I am guessing it is part of the hardwares > buggy DMA issues and can't play well with other hardware without this.
Chris, That's good to know. > Maybe in the cx18 it isn't like that, not sure if it's used there, but > that chip has a lot better chances of not being buggy like this. The CX23418 is likely much better behaved. It has a different problem though: all buffer handovers are serialized through *ONE* mailbox. If you don't rush to pick up that mailbox, you can drop a buffer. The firmware doesn't wait long before it decides you're not going to ack the mailbox. The firmware then overwrites the mailbox with the next buffer notification. Letting the rush to pick up the mailbox be interrupted/delayed by another device will likely mean more dropped buffers for a single CX23418 card machine, where the card doesn't share an interrupt (the common case). I think .... Regards, Andy > Thanks, > Chris _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
