On Tue, 14 Jul 2015 16:45:52 +0200, Nariman Poushin wrote:
We treat a delay in a sequence the same way we treat a page change as they are logically similar in that you can coalesce all write before a delay (in the same way you can coalesce all writes before a page change is needed)
Signed-off-by: Nariman Poushin nariman@opensource.wolfsonmicro.com
drivers/base/regmap/regmap.c | 65 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index 0a849ee..a67473c2 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -18,6 +18,7 @@ #include <linux/of.h> #include <linux/rbtree.h> #include <linux/sched.h> +#include <linux/delay.h>
#define CREATE_TRACE_POINTS #include "trace.h" @@ -47,6 +48,17 @@ static int _regmap_bus_reg_write(void *context, unsigned int reg, static int _regmap_bus_raw_write(void *context, unsigned int reg, unsigned int val);
+static void regmap_sequence_delay(unsigned int delay_us) +{
- /* For small delays it isn't worth setting up the hrtimers
* so fall back on udelay*/- if (delay_us < 10)
udelay(delay_us);- else
usleep_range(delay_us, delay_us * 2);+}
I think usleep_range() can't be used for fast_io, which is performed inside a spinlock. And, the locking can't be known explicitly, e.g. the caller may set its own config->lock, so even the check for fast_io isn't enough.
Takashi