Hi Jean-Jacques,
On Wed, 8 Jan 2020 at 09:16, Jean-Jacques Hiblot jjhiblot@ti.com wrote:
Simon,
On 24/12/2019 16:58, Simon Glass wrote:
Hi Jean-Jacques,
On Mon, 16 Dec 2019 at 03:10, Jean-Jacques Hiblot jjhiblot@ti.com wrote:
Hi Simon,
On 10/12/2019 16:18, Simon Glass wrote:
Hi Jean-Jacques,
On Tue, 5 Nov 2019 at 04:47, Jean-Jacques Hiblot jjhiblot@ti.com wrote:
Some linux drivers provide their own read/write functions to access data from/of the regmap. Adding support for it.
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com
Changes in v2:
Only use custom accessors if {,SPL,TPL}_REGMAP_ACCESSORS is enabled
drivers/core/Kconfig | 25 +++++++++++++++++++++++++ drivers/core/regmap.c | 22 ++++++++++++++++++++-- include/regmap.h | 28 +++++++++++++++++++++++++--- 3 files changed, 70 insertions(+), 5 deletions(-)
Coming back to the discussion on driver model....
How do you specify the fields? I would expect that this would be done in the driver tree? Perhaps in a subnode of the device?
Just to state what I see as the advantages of using a separate device for access:
- Remove the #ifdef in the regmap struct
- Easy to specify the behaviour in a device-tree node
- Easy to extend as the child device can do what it likes with respect to access
That sure is a better abstraction. However the goal of this patch is only to use the same API as linux. It allows porting the drivers as-is and thus reduce the burden of maintenance.
So how do you specify the fields? See my question above.
The fields are filled when creating the regmap.
ex:
static struct regmap_config cfg = { .reg_write = regmaptest_write, .reg_read = regmaptest_read, }; and then regmap = devm_regmap_init(dev, NULL, &ctx, &cfg);
You can have a look at the tests in the last patch of the series.
JJ
It is not possible to use a similar API without importing the internal implementation. Linux's driver model is less homogenous.
Then I really think we should try to use driver model for the accessors too.
IMO the access method could be described in the device tree. But if not, we could bind the accessor driver as a child.
Regards, Simon