commit 3f0fa9a808f98fa10a18ba2a73f13d65fda990fb upstream.
The use of WARN_ON() needs the definitions from bug.h, without it
you can get:
include/linux/regmap.h: In function 'regmap_write':
include/linux/regmap.h:525:2: error: implicit declaration of function 'WARN_ONCE' [-Werror=implicit-function-declaration]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 49ccc142f9cbc33fdda18e8fa90c1c5b4a79c0ad upstream.
regmap.h requires linux/err.h if CONFIG_REGMAP is not defined. Without it I get
error.
CC drivers/media/platform/exynos4-is/fimc-reg.o
In file included from drivers/media/platform/exynos4-is/fimc-reg.c:14:0:
include/linux/regmap.h: In function ‘regmap_write’:
include/linux/regmap.h:525:10: error: ‘EINVAL’ undeclared (first use in this function)
include/linux/regmap.h:525:10: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Mateusz Krawczuk <m.krawczuk@partner.samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mainly useful internally but exported since this is a public API that's
being checked for.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some mmio devices have a dedicated interface clock that needs
to be enabled to access their registers. This patch optionally
enables a clock before accessing registers in the regmap_bus
callbacks.
I added (devm_)regmap_init_mmio_clk variants of the init
functions that have an added clk_id string parameter. This
is passed to clk_get to request the clock from the clk
framework.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some use cases like firmware download can transfer a lot of data in quick
succession. With high speed buses these use cases can benefit from having
multiple transfers scheduled at once since this allows the bus to minimise
the delay between transfers.
Support this by adding regmap_raw_write_async(), allowing raw transfers to
be scheduled, and regmap_async_complete() to wait for them to finish.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This commit adds provision for "no-bus" usage of the regmap API. In
this configuration user can provide API with two callbacks 'reg_read'
and 'reg_write' which are to be called when reads and writes to one of
device's registers is performed. This is useful for devices that
expose registers but whose register access sequence does not fit the 'bus'
abstraction.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
While for I2C and SPI devices the overhead of using rbtree for devices with
only one block of registers is negligible the same isn't always going to
be true for MMIO devices where the I/O costs are very much lower. Cater
for these devices by adding a simple flat array type for them where the
lookups are simple array accesses, taking us right back to the original
ASoC cache implementation.
Thanks to Magnus Damm for the discussion which prompted this.
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>
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>
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>
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>
It's perfectly sensible to ask if there's a regmap for a device which
doesn't have one so the stubbed version shouldn't complain, the caller
should be prepared for this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Allow chips to provide a bank of registers for controlling the wake state
in a similar fashion to the masks and propagate the wake count to the
parent interrupt controller.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add a field to struct regmap_bus that allows bus drivers to request that
register addresses and values be formatted with a specific endianness.
The default endianness is unchanged from current operation: Big.
Implement native endian formatting/parsing for 16- and 32-bit values.
This will be enough to support regmap-mmio.c.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
In some chips the IRQ status registers are not contiguous in the register
map but spaced at even spaces. This is an easy case to handle with minor
changes. It is assume for this purpose that the stride for status is
equal to the stride for mask/ack registers as well.
Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This gets us up to date with the recommended current kernel infrastructure
and should transparently give us device tree interrupt bindings for any
devices using the framework. If an explicit IRQ mapping is passed in then
a legacy interrupt range is created, otherwise a simple linear mapping is
used. Previously a mapping was mandatory so existing drivers should not
be affected.
A function regmap_irq_get_virq() is provided to allow drivers to map
individual IRQs which should be used in preference to the existing
regmap_irq_chip_get_base() which is only valid if a legacy IRQ range is
provided.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Use devres to implement dev_get_regmap(). This should mean that in almost
all cases devices wishing to take advantage of framework features based on
regmap shouldn't need to explicitly pass the regmap into the framework.
This simplifies device setup a bit.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some devices does not support bulk read and write operations, for them
we have series of single write and read operations.
Signed-off-by: Anthony Olech <Anthony.Olech@diasemi.com>
Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com>
[Fixed coding style, don't check use_single_rw before assign --broonie ]
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
regmap_config.reg_stride is introduced. All extant register addresses
are a multiple of this value. Users of serial-oriented regmap busses will
typically set this to 1. Users of the MMIO regmap bus will typically set
this based on the value size of their registers, in bytes, so 4 for a
32-bit register.
Throughout the regmap code, actual register addresses are used. Wherever
the register address is used to index some array of values, the address
is divided by the stride to determine the index, or vice-versa. Error-
checking is added to all entry-points for register address data to ensure
that register addresses actually satisfy the specified stride. The MMIO
bus ensures that the specified stride is large enough for the register
size.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some devices have multiple separate register regions. Logically, one
regmap would be created per region. One issue that prevents this is that
each instance will attempt to create the same debugfs files. Avoid this
by allowing regmaps to be named, and use the name to construct the
debugfs directory name.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This is a basic memory-mapped-IO bus for regmap. It has the following
features and limitations:
* Registers themselves may be 8, 16, 32, or 64-bit. 64-bit is only
supported on 64-bit platforms.
* Register offsets are limited to precisely 32-bit.
* IO is performed using readl/writel, with no provision for using the
__raw_readl or readl_relaxed variants.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Some bus types have very fast IO. For these, acquiring a mutex for every
IO operation is a significant overhead. Allow busses to indicate their IO
is fast, and enhance regmap to use a spinlock for those busses.
[Currently limited to native endian registers -- broonie]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The only context needed by I2C and SPI bus definitions is the device
itself; this can be converted to an i2c_client or spi_device in order
to perform IO on the device. However, other bus types may need more
context in order to perform IO. Enable this by having regmap_init accept
a bus_context parameter, and pass this to all bus callbacks. The
existing callbacks simply pass the struct device here. Future bus types
may pass something else.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
"[RFC PATCH 0/2] audit of linux/device.h users in include/*"
https://lkml.org/lkml/2012/3/4/159
--
Nearly every subsystem has some kind of header with a proto like:
void foo(struct device *dev);
and yet there is no reason for most of these guys to care about the
sub fields within the device struct. This allows us to significantly
reduce the scope of headers including headers. For this instance, a
reduction of about 40% is achieved by replacing the include with the
simple fact that the device is some kind of a struct.
Unlike the much larger module.h cleanup, this one is simply two
commits. One to fix the implicit <linux/device.h> users, and then
one to delete the device.h includes from the linux/include/ dir
wherever possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPbNxLAAoJEOvOhAQsB9HWR6QQAMRUZ94O2069/nW9h4TO/xTr
Hq/80lo/TBBiRmob3iWBP76lzgeeMPPVEX1I6N7YYlhL3IL7HsaJH1DvpIPPHXQP
GFKcBsZ5ZLV8c4CBDSr+/HFNdhXc0bw0awBjBvR7gAsWuZpNFn4WbhizJi4vWAoE
4ydhPu55G1G8TkBtYLJQ8xavxsmiNBSDhd2i+0vn6EVpgmXynjOMG8qXyaS97Jvg
pZLwnN5Wu21coj6+xH3QUKCl1mJ+KGyamWX5gFBVIfsDB3k5H4neijVm7t1en4b0
cWxmXeR/JE3VLEl/17yN2dodD8qw1QzmTWzz1vmwJl2zK+rRRAByBrL0DP7QCwCZ
ppeJbdhkMBwqjtknwrmMwsuAzUdJd79GXA+6Vm+xSEkr6FEPK1M0kGbvaqV9Usgd
ohMewewbO6ddgR9eF7Kw2FAwo0hwkPNEplXIym9rZzFG1h+T0STGSHvkn7LV765E
ul1FapSV3GCxEVRwWTwD28FLU2+0zlkOZ5sxXwNPTT96cNmW+R7TGuslZKNaMNjX
q7eBZxo8DtVt/jqJTntR8bs8052c8g1Ac1IKmlW8VSmFwT1M6VBGRn1/JWAhuUgv
dBK/FF+I1GJTAJWIhaFcKXLHvmV9uhS6JaIhLMDOetoOkpqSptJ42hDG+89WkFRk
o55GQ5TFdoOpqxVzGbvE
=3j4+
-----END PGP SIGNATURE-----
Merge tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
Pull <linux/device.h> avoidance patches from Paul Gortmaker:
"Nearly every subsystem has some kind of header with a proto like:
void foo(struct device *dev);
and yet there is no reason for most of these guys to care about the
sub fields within the device struct. This allows us to significantly
reduce the scope of headers including headers. For this instance, a
reduction of about 40% is achieved by replacing the include with the
simple fact that the device is some kind of a struct.
Unlike the much larger module.h cleanup, this one is simply two
commits. One to fix the implicit <linux/device.h> users, and then one
to delete the device.h includes from the linux/include/ dir wherever
possible."
* tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
device.h: audit and cleanup users in main include dir
device.h: cleanup users outside of linux/include (C files)
The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.
Clean up the users as follows:
1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.
2) For headers not really using anything from device.h, simply
delete the include altogether.
3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h
4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).
Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.
Total removals from #1 and #2: 51. Total additions coming
from #3: 9. Total other implicit dependencies from #4: 7.
As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Ensure we have a forward declaration of struct regmap that isn't just
the return value of regmap_init() and make the definition of the
register defaults available.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Provide a regcache_sync_region() operation which allows drivers to
write only part of the cache back to the hardware. This is intended
for use in cases like power domains or DSP memories where part of the
device register map may be reset without fully resetting the device.
Fully supporting these devices is likely to require additional work to
make specific regions of the register map cache only while they are in
reset, but this is enough for most devices.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Kevin Hilman