We don't want to bomb out early if we failed to get the cache any more,
just soldier on instead and we won't get confused and always return the
first block.
Reported-by: Philipp Zabel <p.zabel@pengutronix.de
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Rather than trying to soldier on with a partially allocated cache just
throw the cache away and pretend we don't have one in case we can get a
full cache next time around.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Return the start of the last block we tried to read rather than a position,
and also make sure we update the byte position while we're at it. Without
this reads that go into nonexistant areas get confused.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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>
In preparation for doing things a bit more quickly than a linear scan
factor out the initial seek from the debugfs register dump.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If count is less than the size of a register then we may hit integer
wraparound when trying to move backwards to check if we're still in
the buffer. Instead move the position forwards to check if it's still
in the buffer, we are unlikely to be able to allocate a buffer
sufficiently big to overflow here.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
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>
This seems to be the most common way of reporting register numbers, it's
certainly what we do for trace.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
val_bytes is of 'size_t', so it should be printed as '%zu'.
Fixes the following build warning on x86:
drivers/base/regmap/regmap.c:872:4: warning: format '%d' expects argument of type 'int', but argument 5 has type 'size_t' [-Wformat]
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The regmap_mmio and regmap_irq depend on regmap core, if not select,
we may not compile regmap core and meet compiling errors as follows
if REGMAP_MMIO is selected by client drivers:
drivers/mfd/syscon.c:94:15: error: variable 'syscon_regmap_config' has initializer but incomplete type
drivers/mfd/syscon.c:95:2: error: unknown field 'reg_bits' specified in initializer
drivers/mfd/syscon.c:95:2: warning: excess elements in struct initializer [enabled by default]
drivers/mfd/syscon.c:95:2: warning: (near initialization for 'syscon_regmap_config') [enabled by default]
drivers/mfd/syscon.c:96:2: error: unknown field 'val_bits' specified in initializer
drivers/mfd/syscon.c:96:2: warning: excess elements in struct initializer [enabled by default]
drivers/mfd/syscon.c:96:2: warning: (near initialization for 'syscon_regmap_config') [enabled by default]
drivers/mfd/syscon.c:97:2: error: unknown field 'reg_stride' specified in initializer
drivers/mfd/syscon.c:97:2: warning: excess elements in struct initializer [enabled by default]
drivers/mfd/syscon.c:97:2: warning: (near initialization for 'syscon_regmap_config') [enabled by default]
drivers/mfd/syscon.c: In function 'syscon_probe':
drivers/mfd/syscon.c:124:2: error: invalid use of undefined type 'struct regmap_config'
drivers/mfd/syscon.c:125:2: error: implicit declaration of function 'devm_regmap_init_mmio' [-Werror=implicit-function-declaration]
drivers/mfd/syscon.c:125:17: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
drivers/mfd/Kconfig:
config MFD_SYSCON
bool "System Controller Register R/W Based on Regmap"
depends on OF
select REGMAP_MMIO
help
Select this option to enable accessing system control registers
via regmap.
Signed-off-by: Dong Aisheng <dong.aisheng@linaro.org>
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>
Building regmap.o triggers this GCC warning:
drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Long story short: Jakub Jelinek pointed out that there is a type
mismatch between 'num' in regmap_volatile_range() and 'val_count' in
regmap_raw_read(). And indeed, converting 'num' to the type of
'val_count' (ie, size_t) makes this warning go away.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If a block write covers a paged memory region and crosses a window
boundary then rather than failing the write split the transfer up
into multiple writes, making the whole process more transparent for
drivers.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The range code was written to check for return codes less than zero as
errors but throughout the rest of the API return codes not equal to zero
are errors. Change all these checks to match the house style.
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>
Rather than just returning a single error code for every possible thing we
can notice print an error message saying what the problem was. This makes
it very much easier to figure out what's wrong and fix it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This makes things consistent with the rest of the API and is actually what
the documentation says. We don't currently have any in tree users so low
cost.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is useful for integration with other subsystems, especially MFD,
and provides an alternative API for users that request their own IRQs.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The primary handler will NOT be called if the interrupt nests into
another interrupt thread. Remove it to avoid confusing.
Signed-off-by: Yunfan Zhang <yfzhang@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently, regmap will write 1 to mask_base to mask
an interrupt and write 0 to unmask it.
But some chips do not have an interrupt mask register,
and only have interrupt enable register.
Then we should write 0 to disable interrupt and 1 to enable.
So add an mask_invert flag to handle this.
If it is not set, behavior is same as previous.
If set it to 1, the mask value will be inverted
before written to mask_base
Signed-off-by: Xiaofan Tian <tianxf@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some devices need to have a runtime PM reference while handling interrupts
to ensure that the register I/O is available. Support this with a flag in
the chip.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The kerneldoc for irq_set_irq_wake() says:
Enable/disable power management wakeup mode, which is
disabled by default.
regmap_irq_set_wake() clears bits to enable wake for an interrupt,
and sets bits to disable wake. Hence, we should set all bits in
wake_buf initially, to mirror the expected disabled state.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If a regmap-irq chip has no wake base:
* There's no point calling .irq_set_wake, hence IRQCHIP_SKIP_SET_WAKE.
* If some IRQs in the chip are enabled for wake and some aren't, we
should mask those interrupts that are not wake enabled, so that if
they occur during suspend, the system is not awoken. Hence,
IRQCHIP_MASK_ON_SUSPEND.
Note that IRQCHIP_MASK_ON_SUSPEND is handled by check_wakeup_irqs(),
which always iterates over every single interrupt in the system,
irrespective of whether an interrupt is a child of a controller whose
output interrupt has no wake-enabled inputs and hence is presumably
masked itself. Hence this change might cause interrupt unnecessary
masking operations and associated register I/O.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is intended to give each irq_chip a useful name, rather than hard-
coding them all as "regmap".
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This will allow later patches to adjust portions of the irq_chip
individually for each regmap_irq_chip that is created.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Don't write the full register, it's possible there's bits other than the
masks in the same register which we shouldn't be changing.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Stephen Warren <swarren@wwwdotorg.org>
A number of places in the code were printing error messages that included
the address of a register, but were not calculating the register address
in the same way as the access to the register. Use a temporary to solve
this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When bus->fast_io is set, the locking here is done with spinlocks.
This is currently true for the regmap-mmio bus implementation.
While holding a spinlock we can't go to sleep, various operations
like removing the debugfs entries or re-initializing the cache will
sleep, therefore, shift the locking up to the user.
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Sometimes for failures during very early init the trace infrastructure
isn't available early enough to be used. For this sort of problem
defining LOG_DEVICE will add printks for basic register I/O on a specific
device, allowing trace to be extracted when the trace system doesn't come
up early enough to work with.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
After page update, orginal work_buf has to be restored regardless of
the result.
Signed-off-by: Krystian Garbaciak <krystian.garbaciak@diasemi.com>
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>
Mark Brown