Avoid doing a linear scan of the entire register map for each read() of
the debugfs register dump by recording the offsets where valid registers
exist when we first read the registers file. This assumes the set of
valid registers never changes, if this is not the case invalidation of
the cache will be required.

This could be further improved for large blocks of contiguous registers
by calculating the register we will read from within the block - currently
we do a linear scan of the block. An rbtree may also be worthwhile.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

No point in calculating them every time.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Many of the regmap enabled drivers implementing one or more of the
readable, writeable, volatile and precious methods use the same code
pattern:

	return ((reg >= X && reg <= Y) || (reg >= W && reg <= Z) || ...)

Switch to a data driven approach, using tables to describe
readable/writeable/volatile and precious registers ranges instead.
The table based check can still be overridden by passing the usual function
pointers via struct regmap_config.

Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

It is sometimes convenient for a regmap user to override the standard
regmap lock/unlock functions with custom functions.
For instance this can be useful in case an already existing spinlock
or mutex has to be used for locking a set of registers instead of the
internal regmap spinlock/mutex.
Note that the fast_io field of struct regmap_bus is ignored in case
custom locking functions are used.

Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

If a register range is named then provide a debugfs file showing the
contents of the range separately.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

For more useful diagnostics.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Devices with register paging or indirectly accessed registers can configure
register mapping to map those on virtual address range. During access to
virtually mapped register range, indirect addressing is processed
automatically, in following steps:
  1. selector for page or indirect register is updated (when needed);
  2. register in data window is accessed.

Configuration should provide minimum and maximum register for virtual range,
details of selector field for page selection, minimum and maximum register of
data window for indirect access.

Virtual range registers are managed by cache as well as direct access
registers. In order to make indirect access more efficient, selector register
should be declared as non-volatile, if possible.

struct regmap_config is extended with the following:
struct regmap_range_cfg	*ranges;
unsigned int		n_ranges;

[Also reordered debugfs init to later on since the cleanup code was
conflicting with the new cleanup code for ranges anyway -- broonie]

Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>