[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYj_gBQpRqPP4S3c-cPhzRGnGUahh+1L8G5qUxwG=cx0g@mail.gmail.com>
Date: Thu, 13 Aug 2015 13:24:13 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pinctrl: cherryview: Serialize all register access
On Mon, Aug 3, 2015 at 11:46 AM, Mika Westerberg
<mika.westerberg@...ux.intel.com> 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@...ux.intel.com>
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists