Message ID | 20220401135048.23245-2-angelogioacchino.delregno@collabora.com |
---|---|
State | New |
Headers | show |
Series | Allow syscon to use spinlocks with regmap fast_io | expand |
diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index 191fdb87c424..3fcd9afdb9ef 100644 --- a/drivers/mfd/syscon.c +++ b/drivers/mfd/syscon.c @@ -101,6 +101,10 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_clk) } } + /* Checking for fast-io makes sense only if not using hwspinlock */ + if (!syscon_config.use_hwlock && of_property_read_bool(np, "fast-io")) + syscon_config.fast_io = true; + syscon_config.name = kasprintf(GFP_KERNEL, "%pOFn@%llx", np, (u64)res.start); syscon_config.reg_stride = reg_io_width;
On at least some SoCs accessing MMIO regions is very fast and in some cases acquiring a mutex for every IO operation brings a significant overhead: this is also the rationale of regmap's fast_io configuration parameter, which makes it switch to using a spinlock instead. Since the typical use-case for syscon is to give access to misc system registers (not representing any specific type of device) to one or more other drivers, and since this is done via regmap anyway, allow such devices to let syscon configure regmap with fast_io enabled and to let this happen, add a Devicetree property "fast-io": when this is found, syscon will set '.fast_io = true' in the regmap config. Of course, it makes little sense to do that if a syscon node declares a phandle to a hardware spinlock provider node, so we check for this property only if no hwlock is present. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> --- drivers/mfd/syscon.c | 4 ++++ 1 file changed, 4 insertions(+)