Den 02.01.2017 12:35, skrev Andy Shevchenko:
First of all, fbtft in current state doesn't allow to override GPIOs to be
optional, like "reset" one. It might be a bug somewhere, but rather out of
scope of this fix.
Second, not all GPIOs available on the board would be SoC based, some of them
might sit on I2C GPIO expanders, for example, on Intel Edison/Arduino, and thus
any communication with them might sleep.
Besides that using udelay() and mdelay() is kinda resource wasteful.
Summarize all of the above, convert fbtft_reset() function to non-atomic
variant by using gpio_set_value_cansleep(), usleep_range(), and msleep().
To avoid potential use in atomic context annotate it via might_sleep() macro.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
---
drivers/staging/fbtft/fbtft-core.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
index bbe89c9c4fb9..e8bf0d1ec11f 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -336,11 +336,14 @@ static void fbtft_reset(struct fbtft_par *par)
{
if (par->gpio.reset == -1)
return;
+
+ might_sleep();
gpio_set_value_cansleep() already does might_sleep().
So with that removed:
Reviewed-by: Noralf Trønnes <noralf@xxxxxxxxxxx>
+
fbtft_par_dbg(DEBUG_RESET, par, "%s()\n", __func__);
- gpio_set_value(par->gpio.reset, 0);
- udelay(20);
- gpio_set_value(par->gpio.reset, 1);
- mdelay(120);
+ gpio_set_value_cansleep(par->gpio.reset, 0);
+ usleep_range(20, 40);
+ gpio_set_value_cansleep(par->gpio.reset, 1);
+ msleep(120);
}
static void fbtft_update_display(struct fbtft_par *par, unsigned int start_line,
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
