On Mon, Aug 3, 2015 at 11:46 AM, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > There is a hardware issue in Intel Braswell/Cherryview where concurrent > GPIO register access might results reads of 0xffffffff and writes might get > dropped. > > Prevent this from happening by taking the serializing lock for all places > where it is possible that more than one thread might be accessing the > hardware concurrently. > > Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> Patch applied. When we are on the topic of this spinlock, I noticed that you take it in some IRQ functions: static void chv_gpio_irq_ack(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_to_pinctrl(gc); int pin = chv_gpio_offset_to_pin(pctrl, irqd_to_hwirq(d)); u32 intr_line; spin_lock(&pctrl->lock); (...) The Realtime tree have recently started to push raw spinlocks into GPIO drivers that handle IRQs. Can you look into this for the Intel drivers, I think maybe this needs to be a raw spinlock to play nicely with realtime. Cf: http://marc.info/?l=linux-gpio&m=143749603401220&w=2 Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html