The Spreadtrum platform uses a special set/clear method to update
registers' bits, thus this patch set registers a physical regmap
bus into syscon core to support this feature instead of using the
MMIO bus, which is not a physical regmap bus.
Any comments are welcome. Thanks.
Changes from RFC v2:
- Drop regmap change, which was applied by Mark.
- Add more information about how to use set/clear.
- Add checking to ensure the platform is compatible with
using a new physical regmap bus.
Changes from RFC v1:
- Add new helper to registers a physical regmap bus instead of
using the MMIO bus.
Baolin Wang (2):
mfd: syscon: Support physical regmap bus
soc: sprd: Add Spreadtrum special bits updating support
drivers/mfd/syscon.c | 23 +++++++++-
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/sprd/Kconfig | 16 +++++++
drivers/soc/sprd/Makefile | 2 +
drivers/soc/sprd/sprd_syscon.c | 82 ++++++++++++++++++++++++++++++++++
include/linux/mfd/syscon.h | 7 +++
7 files changed, 130 insertions(+), 2 deletions(-)
create mode 100644 drivers/soc/sprd/Kconfig
create mode 100644 drivers/soc/sprd/Makefile
create mode 100644 drivers/soc/sprd/sprd_syscon.c
--
2.17.1
The spreadtrum platform uses a special set/clear method to update
registers' bits, which can remove the race of updating the global
registers between the multiple subsystems. Thus we can register
a physical regmap bus into syscon core to support this.
Signed-off-by: Baolin Wang <[email protected]>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/sprd/Kconfig | 16 +++++++
drivers/soc/sprd/Makefile | 2 +
drivers/soc/sprd/sprd_syscon.c | 82 ++++++++++++++++++++++++++++++++++
5 files changed, 102 insertions(+)
create mode 100644 drivers/soc/sprd/Kconfig
create mode 100644 drivers/soc/sprd/Makefile
create mode 100644 drivers/soc/sprd/sprd_syscon.c
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 425ab6f7e375..8cfbf2dc518d 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -23,5 +23,6 @@ source "drivers/soc/versatile/Kconfig"
source "drivers/soc/xilinx/Kconfig"
source "drivers/soc/zte/Kconfig"
source "drivers/soc/kendryte/Kconfig"
+source "drivers/soc/sprd/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 36452bed86ef..7d156a6dd536 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_PLAT_VERSATILE) += versatile/
obj-y += xilinx/
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_SOC_KENDRYTE) += kendryte/
+obj-$(CONFIG_ARCH_SPRD) += sprd/
diff --git a/drivers/soc/sprd/Kconfig b/drivers/soc/sprd/Kconfig
new file mode 100644
index 000000000000..38d1f5971a28
--- /dev/null
+++ b/drivers/soc/sprd/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# SPRD SoC drivers
+#
+
+menu "Spreadtrum SoC drivers"
+ depends on ARCH_SPRD || COMPILE_TEST
+
+config SPRD_SYSCON
+ tristate "Spreadtrum syscon support"
+ depends on ARCH_SPRD || COMPILE_TEST
+ help
+ Say yes here to add support for the Spreadtrum syscon driver,
+ which is used to implement the atomic method of bits updating.
+
+endmenu
diff --git a/drivers/soc/sprd/Makefile b/drivers/soc/sprd/Makefile
new file mode 100644
index 000000000000..4d7715553cf6
--- /dev/null
+++ b/drivers/soc/sprd/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SPRD_SYSCON) += sprd_syscon.o
diff --git a/drivers/soc/sprd/sprd_syscon.c b/drivers/soc/sprd/sprd_syscon.c
new file mode 100644
index 000000000000..9b98127f1adb
--- /dev/null
+++ b/drivers/soc/sprd/sprd_syscon.c
@@ -0,0 +1,82 @@
+//SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Spreadtrum Communications Inc.
+ */
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#define SPRD_REG_SET_OFFSET 0x1000
+#define SPRD_REG_CLR_OFFSET 0x2000
+
+/*
+ * The Spreadtrum platform defines a special set/clear method to update
+ * registers' bits, which means it can write values to the register's SET
+ * address (offset is 0x1000) to set bits, and write values to the register's
+ * CLEAR address (offset is 0x2000) to clear bits.
+ *
+ * This set/clear method can help to remove the race of accessing the global
+ * registers between the multiple subsystems instead of using hardware
+ * spinlocks.
+ *
+ * Note: there is a potential risk when users want to set and clear bits
+ * at the same time, since the set/clear method will always do bits setting
+ * before bits clearing, which may cause some unexpected results if the
+ * operation sequence is strict. Thus we recommend that do not set and
+ * clear bits at the same time if you are not sure the results.
+ */
+static int sprd_syscon_update_bits(void *context, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ void __iomem *base = context;
+ unsigned int set, clr;
+
+ set = val & mask;
+ clr = ~set & mask;
+
+ if (set)
+ writel(set, base + reg + SPRD_REG_SET_OFFSET);
+
+ if (clr)
+ writel(clr, base + reg + SPRD_REG_CLR_OFFSET);
+
+ return 0;
+}
+
+static int sprd_syscon_read(void *context, unsigned int reg, unsigned int *val)
+{
+ void __iomem *base = context;
+
+ *val = readl(base + reg);
+ return 0;
+}
+
+static int sprd_syscon_write(void *context, unsigned int reg, unsigned int val)
+{
+ void __iomem *base = context;
+
+ writel(val, base + reg);
+ return 0;
+}
+
+static struct regmap_bus sprd_syscon_regmap = {
+ .fast_io = true,
+ .reg_write = sprd_syscon_write,
+ .reg_read = sprd_syscon_read,
+ .reg_update_bits = sprd_syscon_update_bits,
+ .val_format_endian_default = REGMAP_ENDIAN_LITTLE,
+};
+
+static int sprd_syscon_init(void)
+{
+ syscon_register_phys_regmap_bus(&sprd_syscon_regmap);
+
+ return 0;
+}
+core_initcall_sync(sprd_syscon_init);
+
+MODULE_DESCRIPTION("Spreadtrum syscon support");
+MODULE_AUTHOR("Baolin Wang <[email protected]>");
+MODULE_LICENSE("GPL v2");
--
2.17.1
On Fri, Apr 17, 2020 at 4:14 AM Baolin Wang <[email protected]> wrote:
> + *
> + * Note: there is a potential risk when users want to set and clear bits
> + * at the same time, since the set/clear method will always do bits setting
> + * before bits clearing, which may cause some unexpected results if the
> + * operation sequence is strict. Thus we recommend that do not set and
> + * clear bits at the same time if you are not sure the results.
Would it make sense to have a
WARN_ONCE(set && clk, "%s: non-atomic update", __func__);
in the code to check for this?
> +static int sprd_syscon_init(void)
> +{
> + syscon_register_phys_regmap_bus(&sprd_syscon_regmap);
> +
> + return 0;
> +}
> +core_initcall_sync(sprd_syscon_init);
This no longer breaks at runtime based on the changes in the other
patch, but I still don't like how you have to manually load this module
on spreadtrum platforms.
What I meant to suggest in my previous reply was to add the regmap_bus
instance into drivers/mfd/syscon.c itself.
Arnd
On Fri, Apr 17, 2020 at 9:39 PM Arnd Bergmann <[email protected]> wrote:
>
> On Fri, Apr 17, 2020 at 4:14 AM Baolin Wang <[email protected]> wrote:
> > + *
> > + * Note: there is a potential risk when users want to set and clear bits
> > + * at the same time, since the set/clear method will always do bits setting
> > + * before bits clearing, which may cause some unexpected results if the
> > + * operation sequence is strict. Thus we recommend that do not set and
> > + * clear bits at the same time if you are not sure the results.
>
> Would it make sense to have a
>
> WARN_ONCE(set && clk, "%s: non-atomic update", __func__);
>
> in the code to check for this?
Yes, will add.
>
> > +static int sprd_syscon_init(void)
> > +{
> > + syscon_register_phys_regmap_bus(&sprd_syscon_regmap);
> > +
> > + return 0;
> > +}
> > +core_initcall_sync(sprd_syscon_init);
>
> This no longer breaks at runtime based on the changes in the other
> patch, but I still don't like how you have to manually load this module
> on spreadtrum platforms.
>
> What I meant to suggest in my previous reply was to add the regmap_bus
> instance into drivers/mfd/syscon.c itself.
Sorry, I misunderstood your meaning before, but what you suggested
will add some vendor-specific things into the common syscon driver, if
other platforms have different update bits method, we will add another
vendor-specific regmap bus into the syscon.c, which will make syscon.c
more complicated.
But if you still prefer to add these vendor-specific things into the
syscon.c, I will follow your suggestion in next version. Thanks.
--
Baolin Wang
On Fri, Apr 17, 2020 at 4:10 PM Baolin Wang <[email protected]> wrote:
> On Fri, Apr 17, 2020 at 9:39 PM Arnd Bergmann <[email protected]> wrote:
> > On Fri, Apr 17, 2020 at 4:14 AM Baolin Wang <[email protected]> wrote:
> > > +static int sprd_syscon_init(void)
> > > +{
> > > + syscon_register_phys_regmap_bus(&sprd_syscon_regmap);
> > > +
> > > + return 0;
> > > +}
> > > +core_initcall_sync(sprd_syscon_init);
> >
> > This no longer breaks at runtime based on the changes in the other
> > patch, but I still don't like how you have to manually load this module
> > on spreadtrum platforms.
> >
> > What I meant to suggest in my previous reply was to add the regmap_bus
> > instance into drivers/mfd/syscon.c itself.
>
> Sorry, I misunderstood your meaning before, but what you suggested
> will add some vendor-specific things into the common syscon driver, if
> other platforms have different update bits method, we will add another
> vendor-specific regmap bus into the syscon.c, which will make syscon.c
> more complicated.
I think we can always deal with this once it gets too complex, as long
as the DT binding allows it.
> But if you still prefer to add these vendor-specific things into the
> syscon.c, I will follow your suggestion in next version. Thanks.
Yes, please do.
Arnd
On Fri, Apr 17, 2020 at 11:03 PM Arnd Bergmann <[email protected]> wrote:
>
> On Fri, Apr 17, 2020 at 4:10 PM Baolin Wang <[email protected]> wrote:
> > On Fri, Apr 17, 2020 at 9:39 PM Arnd Bergmann <[email protected]> wrote:
> > > On Fri, Apr 17, 2020 at 4:14 AM Baolin Wang <[email protected]> wrote:
> > > > +static int sprd_syscon_init(void)
> > > > +{
> > > > + syscon_register_phys_regmap_bus(&sprd_syscon_regmap);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +core_initcall_sync(sprd_syscon_init);
> > >
> > > This no longer breaks at runtime based on the changes in the other
> > > patch, but I still don't like how you have to manually load this module
> > > on spreadtrum platforms.
> > >
> > > What I meant to suggest in my previous reply was to add the regmap_bus
> > > instance into drivers/mfd/syscon.c itself.
> >
> > Sorry, I misunderstood your meaning before, but what you suggested
> > will add some vendor-specific things into the common syscon driver, if
> > other platforms have different update bits method, we will add another
> > vendor-specific regmap bus into the syscon.c, which will make syscon.c
> > more complicated.
>
> I think we can always deal with this once it gets too complex, as long
> as the DT binding allows it.
>
> > But if you still prefer to add these vendor-specific things into the
> > syscon.c, I will follow your suggestion in next version. Thanks.
>
> Yes, please do.
Sure. Thanks.
--
Baolin Wang