regmap: Add regmap dummy driver
Subsystems (2)
PATCH v2 1/1 regmap: Add regmap dummy driver
Add a pseudo-driver for debugging and stress-testing the regmap/regcache APIs. A standard set of tools for working with this driver (mainly sh scripts) will be put in a repo at https://github.com/quantumdream/regmap-tools
Some of these tests will require one to build with REGMAP_ALLOW_WRITE_DEBUGFS defined.
---
This is an initial implementation of the regdummy driver for regmap. This is mainly useful for debugging/stress-testing regcache as it removes the need for real hardware and can be done in an emulated environment very easily.
There'll be incremental patches adding more features such as, support for configurable volatile/readable/etc. registers via debugfs entries.
v2 updates:
- Factored out the access to the MMIO region into a separate function.
- Removed bogus Change-Id
drivers/base/regmap/Kconfig | 8 + drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-dummy.c | 609 +++++++++++++++++++++++++++++++++++++ 3 files changed, 618 insertions(+) create mode 100644 drivers/base/regmap/regmap-dummy.c
drivers/base/regmap/Kconfig +8 -0
@@ -20,3 +20,11 @@ config REGMAP_MMIO config REGMAP_IRQ bool + +config REGMAP_DUMMY + tristate + select REGMAP_MMIO + help + Say Y or M if you want to add the regdummy driver for regmap. + This is a pseudo-driver used for debugging and stress-testing + the regmap/regcache APIs.
drivers/base/regmap/Makefile +1 -0
@@ -5,3 +5,4 @@ obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o obj-$(CONFIG_REGMAP_IRQ) += regmap-irq.o +obj-$(CONFIG_REGMAP_DUMMY) += regmap-dummy.o
drivers/base/regmap/regmap-dummy.c new file +609 -0
609 lines not on this page · raw message
Signature · 1 line
1.7.11.3
Quoted 2 lines · Dimitris Papastamos
Add a pseudo-driver for debugging and stress-testing the regmap/regcache APIs. A standard set of tools for working
Overall this looks good, most of the stuff below is fairly small. As a very high level comment it'd be really helpful to split this into a series of commits, for example adding just the dummy device then building out the functionality. It'd make review much easier.
Quoted 2 lines
with this driver (mainly sh scripts) will be put in a repo at https://github.com/quantumdream/regmap-tools
Any reason not to put this in the tools directory?
Quoted 2 lines
Some of these tests will require one to build with
REGMAP_ALLOW_WRITE_DEBUGFSdefined.
Can we add a write mechanism specifically for this dummy driver?
drivers/base/regmap/regmap-dummy.c line 33
Quoted 4 lines
drivers/base/regmap/regmap-dummy.c new file +4
-0+/* Set when regdummy defaults have been modified. +* This is useful to know so we don't reinit the +* cache if there is no reason to do so. */ + unsigned int dirty:1;
Should we perhaps just reinit anyway? It's not like this is performance critical...
drivers/base/regmap/regmap-dummy.c line 53
Quoted 8 lines
drivers/base/regmap/regmap-dummy.c new file +8
-0+/* Default volatile register callback, this should +* normally be configured by the user via a debugfs +* entry */ +static bool regdummy_volatile_reg (struct device *dev, +unsigned int reg) +{ +return false; +}
All these functions just seem to be implementing the default behaviour, why are they needed?
drivers/base/regmap/regmap-dummy.c line 125
Quoted 5 lines
drivers/base/regmap/regmap-dummy.c new file +5
-0+/* If we're in the region the user is trying to read */ +if (p >= *ppos) { +/* ...but not beyond it */ +if (buf_pos >= count -1 - tot_len) +break ;
Any potential for code reuse? This stuff does look awfully familiar!
drivers/base/regmap/regmap-dummy.c line 382
Quoted 4 lines
drivers/base/regmap/regmap-dummy.c new file +4
-0+/* Allocate the new register defaults */ + regdef_num_new = rdevp->regs_size_new / config->reg_stride; + regdef_num_raw_new = regdef_num_new *sizeof (*regdef_new); + regdef_new =kzalloc (regdef_num_raw_new,GFP_KERNEL );
Can we factor this stuff out - there's a lot of overlap with the vanilla init?
drivers/base/regmap/regmap-dummy.c line 580
Quoted 4 lines
drivers/base/regmap/regmap-dummy.c new file +4
-0+static struct platform_device regdummy_device = { + .name ="regdummy" , + .id =0 , +};
Set id to -1 if there's only one of them.
Quoted 9 lines · Mark Brown
Quoted 2 lines · Dimitris Papastamos
Add a pseudo-driver for debugging and stress-testing the regmap/regcache APIs. A standard set of tools for working
Overall this looks good, most of the stuff below is fairly small. As a very high level comment it'd be really helpful to split this into a series of commits, for example adding just the dummy device then building out the functionality. It'd make review much easier.
Quoted 4 lines
Quoted 2 lines
with this driver (mainly sh scripts) will be put in a repo at https://github.com/quantumdream/regmap-tools
Any reason not to put this in the tools directory?
At the moment the repo is very bare bones. I was thinking more of an automated testing framework written in sh or similar. So it might grow out into its own repository anyhow.
Quoted 4 lines
Quoted 2 lines
Some of these tests will require one to build with
REGMAP_ALLOW_WRITE_DEBUGFSdefined.Can we add a write mechanism specifically for this dummy driver?
Sure yes.
Quoted 7 lines
drivers/base/regmap/regmap-dummy.c line 33
Quoted 4 lines
drivers/base/regmap/regmap-dummy.c new file +4
-0+/* Set when regdummy defaults have been modified. +* This is useful to know so we don't reinit the +* cache if there is no reason to do so. */ + unsigned int dirty:1;Should we perhaps just reinit anyway? It's not like this is performance critical...
Yea will remove it for simplicity.
Quoted 11 lines
drivers/base/regmap/regmap-dummy.c line 53
Quoted 8 lines
drivers/base/regmap/regmap-dummy.c new file +8
-0+/* Default volatile register callback, this should +* normally be configured by the user via a debugfs +* entry */ +static bool regdummy_volatile_reg (struct device *dev, +unsigned int reg) +{ +return false; +}All these functions just seem to be implementing the default behaviour, why are they needed?
Hm will remove them for now but it would be useful for these to be set by the user via debugfs or similar. These were mainly stubs for that sort of thing.
Quoted 7 lines
drivers/base/regmap/regmap-dummy.c line 125
Quoted 5 lines
drivers/base/regmap/regmap-dummy.c new file +5
-0+/* If we're in the region the user is trying to read */ +if (p >= *ppos) { +/* ...but not beyond it */ +if (buf_pos >= count -1 - tot_len) +break ;Any potential for code reuse? This stuff does look awfully familiar!
Might factor some of these things into a separate regmap-utils.c.
Quoted 7 lines
drivers/base/regmap/regmap-dummy.c line 382
Quoted 4 lines
drivers/base/regmap/regmap-dummy.c new file +4
-0+/* Allocate the new register defaults */ + regdef_num_new = rdevp->regs_size_new / config->reg_stride; + regdef_num_raw_new = regdef_num_new *sizeof (*regdef_new); + regdef_new =kzalloc (regdef_num_raw_new,GFP_KERNEL );Can we factor this stuff out - there's a lot of overlap with the vanilla init?
Sure.
Quoted 6 lines
drivers/base/regmap/regmap-dummy.c line 580
Quoted 4 lines
drivers/base/regmap/regmap-dummy.c new file +4
-0+static struct platform_device regdummy_device = { + .name ="regdummy" , + .id =0 , +};Set id to -1 if there's only one of them.
Ok.
Quoted 7 lines · Dimitris Papastamos
Quoted 1 line · Mark Brown
Any reason not to put this in the tools directory?
At the moment the repo is very bare bones. I was thinking more of an automated testing framework written in sh or similar. So it might grow out into its own repository anyhow.
It'd need to be pretty enormous for that I'd expect.
Quoted 6 lines
Quoted 2 lines
All these functions just seem to be implementing the default behaviour, why are they needed?
Hm will remove them for now but it would be useful for these to be set by the user via debugfs or similar. These were mainly stubs for that sort of thing.
I figured that was the idea but until there's code controlling them it's better to just not have anything.