From c9b41fcf272b4926b373d21c2b83dfe374313780 Mon Sep 17 00:00:00 2001 From: Bartosz Golaszewski Date: Wed, 6 Dec 2017 15:26:21 +0100 Subject: regmap: allow to disable all locking mechanisms We have a use case in the at24 EEPROM driver (recently converted to using regmap instead of raw i2c/smbus calls) where we read from/write to the regmap in a loop, while protecting the entire loop with a mutex. Currently this implicitly makes us use two mutexes - one in the driver and one in regmap. While browsing the code for similar use cases I noticed a significant number of places where locking *seems* redundant. Allow users to completely disable any locking mechanisms in regmap config. Signed-off-by: Bartosz Golaszewski Signed-off-by: Mark Brown --- include/linux/regmap.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'include/linux/regmap.h') diff --git a/include/linux/regmap.h b/include/linux/regmap.h index 15eddc1353ba..072a90229e34 100644 --- a/include/linux/regmap.h +++ b/include/linux/regmap.h @@ -264,6 +264,9 @@ typedef void (*regmap_unlock)(void *); * field is NULL but precious_table (see below) is not, the * check is performed on such table (a register is precious if * it belongs to one of the ranges specified by precious_table). + * @disable_locking: This regmap is either protected by external means or + * is guaranteed not be be accessed from multiple threads. + * Don't use any locking mechanisms. * @lock: Optional lock callback (overrides regmap's default lock * function, based on spinlock or mutex). * @unlock: As above for unlocking. @@ -333,6 +336,8 @@ struct regmap_config { bool (*readable_reg)(struct device *dev, unsigned int reg); bool (*volatile_reg)(struct device *dev, unsigned int reg); bool (*precious_reg)(struct device *dev, unsigned int reg); + + bool disable_locking; regmap_lock lock; regmap_unlock unlock; void *lock_arg; -- cgit v1.2.3-59-g8ed1b From a4887813c3a9481ab87c8a71ab1de50b975cc823 Mon Sep 17 00:00:00 2001 From: Baolin Wang Date: Mon, 25 Dec 2017 14:37:09 +0800 Subject: regmap: Add one flag to indicate if a hwlock should be used Since the hwlock id 0 is valid for hardware spinlock core, but now id 0 is treated as one invalid value for regmap. Thus we should add one extra flag for regmap config to indicate if a hardware spinlock should be used, then id 0 can be valid for regmap to request. Signed-off-by: Baolin Wang Signed-off-by: Mark Brown --- drivers/base/regmap/regmap.c | 2 +- include/linux/regmap.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) (limited to 'include/linux/regmap.h') diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index f25ab18ca057..d23a5c99b639 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -671,7 +671,7 @@ struct regmap *__regmap_init(struct device *dev, map->lock = config->lock; map->unlock = config->unlock; map->lock_arg = config->lock_arg; - } else if (config->hwlock_id) { + } else if (config->use_hwlock) { map->hwlock = hwspin_lock_request_specific(config->hwlock_id); if (!map->hwlock) { ret = -ENXIO; diff --git a/include/linux/regmap.h b/include/linux/regmap.h index 15eddc1353ba..c78e0057df66 100644 --- a/include/linux/regmap.h +++ b/include/linux/regmap.h @@ -317,6 +317,7 @@ typedef void (*regmap_unlock)(void *); * * @ranges: Array of configuration entries for virtual address ranges. * @num_ranges: Number of range configuration entries. + * @use_hwlock: Indicate if a hardware spinlock should be used. * @hwlock_id: Specify the hardware spinlock id. * @hwlock_mode: The hardware spinlock mode, should be HWLOCK_IRQSTATE, * HWLOCK_IRQ or 0. @@ -365,6 +366,7 @@ struct regmap_config { const struct regmap_range_cfg *ranges; unsigned int num_ranges; + bool use_hwlock; unsigned int hwlock_id; unsigned int hwlock_mode; }; -- cgit v1.2.3-59-g8ed1b