On Thu, 5 Apr 2007, Trent Piepho wrote: > On Thu, 5 Apr 2007, Patrick Boettcher wrote: > > On Thu, 5 Apr 2007, Borgi2008 wrote: > > > Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä: > > > > > > > > Actually, looking at the code I cannot figure out why there has to be a > > > > spinlock in the first place. > > > > > > > > The lock is only taken in the interrupt handler which already runs in > > > > atomic context so there is no use in making the handler protected by a > > > > spinlock. Am I missing something here? > > > > > > > > I think the spinlock is unnecessary and should be removed entirely. > > > > Even on SMP systems? ISRs are only atomic on one CPU. > > I thought ISRs were normally atomic even on SMP systems. When an interrupt > occurs, that interrupt is disabled until the ISR returns. Except in fast > handlers (which flexcop is not) all interrupts aren't disabled, and so an > ISR can be interrupted by a _different_ ISR, and a different ISR could be > running at the same time on another CPU. But an ISR doesn't have to worry > about two copies of itself running at the same time. > > At least, that's how I think it works. > > I don't see how a spin lock that is only used from the ISR could be useful, > assuming the ISR is only called via an interrupt. There is no reason you > couldn't call the isr function from some system call handler, but that > would be an unusual thing to do. > > Normally an ISR does need a spinlock, to access data shared by the > non-interrupt part of the driver. I wonder if there is a bug in flexcop in > that nothing else uses irq_lock? You can only take a spinlock at IRQ-level and not at normal kernel level. So you cannot protect from shared data access without delegating the work to a lower level and there to use mutexes to protect. As there is only the isr which is at IRQ-level you might be right, it can be removed. Someone outthere with a SMP-system and a flexcop who could see if e.g. dvbscan or dvbtraffic is killing the system/flexcop when removing the irq_lock? Patrick.
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
