kernel/drivers/base/regmap/regmap-mmio.c, branch linux-4.16.y

Merge remote-tracking branches 'regmap/fix/be', 'regmap/fix/doc' and 'regmap/fix/spmi' into regmap-linus

2016-05-13T09:36:10Z

regmap: mmio: Explicitly say little endian is the defualt in the bus config

2016-03-31T20:41:12Z

Otherwise the DT parsing will default to big endian if nothing is specified. Reported-by: Krzysztof Kozlowski Signed-off-by: Mark Brown

regmap: mmio: Parse endianness definitions from DT

2016-03-30T15:46:15Z

Since we changed to do formatting in the bus we now skip all the format parsing that the core does for its data marshalling code. This means that we skip the DT parsing it does which breaks some systems, we need to add an explict call in the MMIO code to do this. Reported-by: Alexander Stein Tested-by: Alexander Stein Signed-off-by: Mark Brown

regmap: mmio: Fix value endianness selection

2016-03-23T13:41:06Z

Currently when selecting value endianness we check the register endiannes, not the value endianness. Reported-by: Alexander Stein Tested-by: Alexander Stein Signed-off-by: Mark Brown

regmap: mmio: Convert to regmap_bus and fix accessor usage

2016-01-27T20:04:50Z

Currently regmap-mmio uses the __raw accessors to read and write from memory. This is not safe as these interact poorly with spinlocks and are not guaranteed to generate emulated instructions on at least ARM where regmap is commonly used. The APIs that are provided all provide some byte swapping so this is difficult to do with the current regmap-mmio implementation which attempts to use the regmap core byte swapping. We can fix this by modernising the MMIO implementation to use reg_read() and reg_write() operations which were added after the API was implemented and pass simple unsigned integers through to the bus, making use of the formatting provided by the I/O accessors using a similar pattern to that used by the core. This will be less efficient for block I/O operations since we now enable and disable any required clocks per register but it is not clear that any users of regmap-mmio actually use block I/O and there is room to optimise later. This removes support for big endian I/O on 64 bit registers since no I/O accessors are provided, no current users were found and support can be added easily once they are available. In addition make the default endianness little endian. This was the behaviour prior to 29bb45f25ff305 (regmap-mmio: Use native endianness for read/write) and is the behaviour desired by most existing users, the users have been audited and those that need native endianness converted to request it explicitly. Previously native was documented as the default but due to the byte swapping in the accessors this was not correctly implemented. Fixes: 29bb45f25ff305 (regmap-mmio: Use native endianness for read/write) Reported-by: Johannes Berg Tested-by: Johannes Berg Signed-off-by: Mark Brown

regmap: mmio: Add regmap_mmio_get_min_stride

2015-12-08T17:05:50Z

Splite the minimal stride parsing into one signal function. Signed-off-by: Xiubo Li Signed-off-by: Mark Brown

regmap: mmio: remove the useless code

2015-12-08T17:05:50Z

Signed-off-by: Xiubo Li Signed-off-by: Mark Brown

regmap-mmio: Use native endianness for read/write

2015-11-16T09:43:54Z

The regmap API has an endianness setting for formatting reads and writes. This can be set by the usual DT "little-endian" and "big-endian" properties. To work properly the associated regmap_bus needs to read/write in native endian. The "syscon" DT device binding creates an mmio-based regmap_bus which performs all reads/writes as little-endian. These values are then converted again by regmap, which means that all of the MIPS BCM boards (which are big-endian) have been declared as "little-endian" to get regmap to convert them back to big-endian. Modify regmap-mmio to use the native-endian functions __raw_read*() and __raw_write*() instead of the little-endian functions read*() and write*(). Modify the big-endian MIPS BCM boards to use what will now be the correct endianness instead of pretending that the devices are little-endian. Signed-off-by: Simon Arlott Signed-off-by: Mark Brown

regmap: Move documentation to regmap.h

2015-08-11T16:21:44Z

Init functions defined in regmap*.c files are now prefixed with __, take lockdep key and class parameters, and should not be called directly: move the documentation to regmap.h, where the macros are defined. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown

regmap: Use different lockdep class for each regmap init call

2015-08-07T13:50:59Z

Lockdep validator complains about recursive locking and deadlock when two different regmap instances are called in a nested order. That happens anytime a regmap read/write call needs to access another regmap. This is because, for performance reason, lockdep groups all locks initialized by the same mutex_init() in the same lock class. Therefore all regmap mutexes are in the same lock class, leading to lockdep "nested locking" warnings if a regmap accesses another regmap. In general, it is impossible to establish in advance the hierarchy of regmaps, so we make sure that each regmap init call initializes its own static lock_class_key. This is done by wrapping all regmap_init calls into macros. This also allows us to give meaningful names to the lock_class_key. For example, in rt5677 case, we have in /proc/lockdep_chains: irq_context: 0 [ffffffc0018d2198] &dev->mutex [ffffffc0018d2198] &dev->mutex [ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock [ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock [ffffffc001b95448] &(&base->lock)->rlock The above would have resulted in a lockdep recursive warning previously. This is not the case anymore as the lockdep validator now clearly identifies the 2 regmaps as separate. Signed-off-by: Nicolas Boichat Signed-off-by: Mark Brown