Generic register bitfield-based multiplexer that controls the multiplexer
producer defined under a parent node.
The driver corresponding to parent node provides register read/write
capabilities.
Signed-off-by: Pankaj Bansal <[email protected]>
---
Notes:
V6:
- No Change
V5:
- No Change
V4:
- As per Peter's suggestion fixup the NULL from dev_get_regmap as early as
possible using ternary operator.
V3:
- Added the patch in series with device tree binding patch
- Added the NULL return handling for regmap
V2:
- removed seperate driver regmap.c and added the regmap function in mmio.c
based on compatible field, the syscon or regmap function would be called
- Modified the KConfig as per Peter's comments
drivers/mux/Kconfig | 12 ++++++------
drivers/mux/mmio.c | 6 +++++-
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 7659d6c5f718..e5c571fd232c 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -46,14 +46,14 @@ config MUX_GPIO
be called mux-gpio.
config MUX_MMIO
- tristate "MMIO register bitfield-controlled Multiplexer"
- depends on (OF && MFD_SYSCON) || COMPILE_TEST
+ tristate "MMIO/Regmap register bitfield-controlled Multiplexer"
+ depends on OF || COMPILE_TEST
help
- MMIO register bitfield-controlled Multiplexer controller.
+ MMIO/Regmap register bitfield-controlled Multiplexer controller.
- The driver builds multiplexer controllers for bitfields in a syscon
- register. For N bit wide bitfields, there will be 2^N possible
- multiplexer states.
+ The driver builds multiplexer controllers for bitfields in either
+ a syscon register or a driver regmap register. For N bit wide
+ bitfields, there will be 2^N possible multiplexer states.
To compile the driver as a module, choose M here: the module will
be called mux-mmio.
diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c
index 935ac44aa209..44a7a0e885b8 100644
--- a/drivers/mux/mmio.c
+++ b/drivers/mux/mmio.c
@@ -28,6 +28,7 @@ static const struct mux_control_ops mux_mmio_ops = {
static const struct of_device_id mux_mmio_dt_ids[] = {
{ .compatible = "mmio-mux", },
+ { .compatible = "reg-mux", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mux_mmio_dt_ids);
@@ -43,7 +44,10 @@ static int mux_mmio_probe(struct platform_device *pdev)
int ret;
int i;
- regmap = syscon_node_to_regmap(np->parent);
+ if (of_device_is_compatible(np, "mmio-mux"))
+ regmap = syscon_node_to_regmap(np->parent);
+ else
+ regmap = dev_get_regmap(dev->parent, NULL) ?: ERR_PTR(-ENODEV);
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
dev_err(dev, "failed to get regmap: %d\n", ret);
--
2.17.1
HI Peter,
Have these changes been applied in any linux branch? I did not see these changes in https://elixir.bootlin.com/linux/v5.1-rc5/source/drivers/mux/mmio.c#L46
Regards,
Pankaj Bansal
> -----Original Message-----
> From: Pankaj Bansal [mailto:[email protected]]
> Sent: Thursday, 28 February, 2019 07:38 PM
> To: Leo Li <[email protected]>; Peter Rosin <[email protected]>
> Cc: Pankaj Bansal <[email protected]>; [email protected]
> Subject: [PATCH v6 2/2] drivers: mux: Add Generic regmap bitfield-based
> multiplexer in mmio-mux
>
> Generic register bitfield-based multiplexer that controls the multiplexer producer
> defined under a parent node.
> The driver corresponding to parent node provides register read/write
> capabilities.
>
> Signed-off-by: Pankaj Bansal <[email protected]>
> ---
>
> Notes:
> V6:
> - No Change
> V5:
> - No Change
> V4:
> - As per Peter's suggestion fixup the NULL from dev_get_regmap as early as
> possible using ternary operator.
> V3:
> - Added the patch in series with device tree binding patch
> - Added the NULL return handling for regmap
> V2:
> - removed seperate driver regmap.c and added the regmap function in mmio.c
> based on compatible field, the syscon or regmap function would be called
> - Modified the KConfig as per Peter's comments
>
> drivers/mux/Kconfig | 12 ++++++------
> drivers/mux/mmio.c | 6 +++++-
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig index
> 7659d6c5f718..e5c571fd232c 100644
> --- a/drivers/mux/Kconfig
> +++ b/drivers/mux/Kconfig
> @@ -46,14 +46,14 @@ config MUX_GPIO
> be called mux-gpio.
>
> config MUX_MMIO
> - tristate "MMIO register bitfield-controlled Multiplexer"
> - depends on (OF && MFD_SYSCON) || COMPILE_TEST
> + tristate "MMIO/Regmap register bitfield-controlled Multiplexer"
> + depends on OF || COMPILE_TEST
> help
> - MMIO register bitfield-controlled Multiplexer controller.
> + MMIO/Regmap register bitfield-controlled Multiplexer controller.
>
> - The driver builds multiplexer controllers for bitfields in a syscon
> - register. For N bit wide bitfields, there will be 2^N possible
> - multiplexer states.
> + The driver builds multiplexer controllers for bitfields in either
> + a syscon register or a driver regmap register. For N bit wide
> + bitfields, there will be 2^N possible multiplexer states.
>
> To compile the driver as a module, choose M here: the module will
> be called mux-mmio.
> diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c index
> 935ac44aa209..44a7a0e885b8 100644
> --- a/drivers/mux/mmio.c
> +++ b/drivers/mux/mmio.c
> @@ -28,6 +28,7 @@ static const struct mux_control_ops mux_mmio_ops = {
>
> static const struct of_device_id mux_mmio_dt_ids[] = {
> { .compatible = "mmio-mux", },
> + { .compatible = "reg-mux", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, mux_mmio_dt_ids); @@ -43,7 +44,10 @@ static
> int mux_mmio_probe(struct platform_device *pdev)
> int ret;
> int i;
>
> - regmap = syscon_node_to_regmap(np->parent);
> + if (of_device_is_compatible(np, "mmio-mux"))
> + regmap = syscon_node_to_regmap(np->parent);
> + else
> + regmap = dev_get_regmap(dev->parent, NULL) ?: ERR_PTR(-
> ENODEV);
> if (IS_ERR(regmap)) {
> ret = PTR_ERR(regmap);
> dev_err(dev, "failed to get regmap: %d\n", ret);
> --
> 2.17.1
On 2019-04-17 10:21, Pankaj Bansal wrote:
> HI Peter,
>
> Have these changes been applied in any linux branch? I did not see these changes in https://elixir.bootlin.com/linux/v5.1-rc5/source/drivers/mux/mmio.c#L46
>
Hi,
No they have not, I've been busy with other stuff... However, I don't think
these patches are -rcX material and you missed the last merge window which
is why this have taken so long. It was simply bad timing. Anyway, my plan
is to get them into linux-next soonish and then into this merge window for
5.2-rc1. I will Cc you when I push it to my upstream (Greg).
Thanks for your patience!
Cheers,
Peter