On Tue, Aug 4, 2015 at 11:56 AM, Greg KH <greg@xxxxxxxxx> wrote: > On Tue, Aug 04, 2015 at 10:23:12AM +1200, Charles Manning wrote: >> I am debugging an issue on the OMAP where the serial irq processing is >> normally low (around 1%) but can sometimes rise to much higher (well >> over 10%). >> >> This lead me to sniff around the locking.... >> >> I notice that in some drivers eg. omap-serial.c the whole interrupt >> handling loop is locked via spin_lock(). >> >> However, other drivers such as serial-tegra.c use spin_lock_irqsave() >> for a loop that pretty much has the same form. >> >> Why is it that they don't use the same locking strategy? What would be better? > > If something can be accessed from in interrupt, you have to use > spin_lock_irqsave everywhere else for that same lock to properly protect > the data. Thanks Greg So to repeat that back to make sure it was what I understand... Resource accesses from outside the interrupt must have spin_lock_irqsave() (eg. in set_termios or to kick off a tx) to prevent the interrupt from occurring while the registers are being touched. The interrupt itself just needs to do a spin_lock(). > > So it depends on the hardware implementation here, both are probably > necessary because of that. So by using a spin_lock_irqsave() within the interrupt, this is preventing another interrupt from occurring. Is it correct to assume spin_lock_irqsave() is needed when there are multiple interrupts for the same driver (eg. dma channels etc,) whereas spin_lock() is fine on simpler drivers with just one interrupt source (eg. "dumb" 16550 style drivers). Thanks for your help. -- Charles -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
