From: Chen-Yu Tsai <[email protected]>
Hi,
This is a resend of the Allwinner D1 LDO driver series, separated by
subsystem. This part contains just the regulator driver bits. The sunxi
SRAM binding part will be sent out after the merge window due to a
conflict in next.
Original cover letter:
This series adds the binding and driver for one of the two pairs of LDOs
inside the Allwinner D1 SoC. I am splitting up the two pairs of LDOs to
unblock merging the SoC devicetree; the analog LDOs depend on the audio
codec binding, but they are not required to boot.
A binding and driver change is required for the SRAM controller, to
accept the regulators device as its child node.
The example for the regulator device binding is in SRAM controller
binding document, per Rob's request to keep MFD examples in one place.
Because of this, at least the first 3 patches need to be taken together
through the regulator tree, though it should be fine to merge the whole
series that way.
Changes in v5:
- Correct the voltage calculation for the non-linearity around 1.6 V.
Changes in v4:
- Fix the order of the maintainer/description sections
- Replace unevaluatedProperties with "additionalProperties: false"
- Drop the analog LDOs until the codec binding is ready
- Drop the analog LDOs until the codec binding is ready
- Remove unevaluatedProperties from regulators schema reference
- Check the compatible string instead of the node name
Changes in v3:
- Add "reg" property to bindings
- Add "unevaluatedProperties: true" to regulator nodes
- Minor changes to regulator node name patterns
- Remove system-ldos example (now added in the parent binding)
- Adjust control flow in sun20i_regulator_get_regmap() for clarity
- Require the regulators node to have a unit address
- Reference the regulator schema from the SRAM controller schema
- Move the system LDOs example to the SRAM controller schema
- Reorder the patches so the example passes validation
Changes in v2:
- Remove syscon property from bindings
- Update binding examples to fix warnings and provide context
- Use decimal numbers for .n_voltages instead of field widths
- Get the regmap from the parent device instead of a property/phandle
Samuel Holland (2):
regulator: dt-bindings: Add Allwinner D1 system LDOs
regulator: sun20i: Add Allwinner D1 LDOs driver
.../allwinner,sun20i-d1-system-ldos.yaml | 37 +++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/sun20i-regulator.c | 156 ++++++++++++++++++
4 files changed, 202 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
create mode 100644 drivers/regulator/sun20i-regulator.c
--
2.39.2
From: Samuel Holland <[email protected]>
The Allwinner D1 SoC contains two pairs of in-package LDOs. The pair of
"system" LDOs is for general purpose use. LDOA generally powers the
board's 1.8 V rail. LDOB powers the in-package DRAM, where applicable.
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Samuel Holland <[email protected]>
Signed-off-by: Chen-Yu Tsai <[email protected]>
---
.../allwinner,sun20i-d1-system-ldos.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
new file mode 100644
index 000000000000..ec6695c8d2e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1 System LDOs
+
+maintainers:
+ - Samuel Holland <[email protected]>
+
+description:
+ Allwinner D1 contains a pair of general-purpose LDOs which are designed to
+ supply power inside and outside the SoC. They are controlled by a register
+ within the system control MMIO space.
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun20i-d1-system-ldos
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^ldo[ab]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+...
--
2.39.2
From: Samuel Holland <[email protected]>
D1 contains two pairs of LDOs, "analog" LDOs and "system" LDOs. They are
similar and can share a driver, but only the system LDOs have a DT
binding defined so far.
The system LDOs have a single linear range. The voltage step is not an
integer, so a custom .list_voltage is needed to get the rounding right.
Signed-off-by: Samuel Holland <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Chen-Yu Tsai <[email protected]>
---
drivers/regulator/Kconfig | 8 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/sun20i-regulator.c | 156 +++++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 drivers/regulator/sun20i-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 7db0a29b5b8d..acdb02a4ac0c 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1415,6 +1415,14 @@ config REGULATOR_STW481X_VMMC
This driver supports the internal VMMC regulator in the STw481x
PMIC chips.
+config REGULATOR_SUN20I
+ tristate "Allwinner D1 internal LDOs"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select MFD_SYSCON
+ default ARCH_SUNXI
+ help
+ This driver supports the internal LDOs in the Allwinner D1 SoC.
+
config REGULATOR_SY7636A
tristate "Silergy SY7636A voltage regulator"
depends on MFD_SY7636A
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 46fb569e6be8..ba15fa5f30ad 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -163,6 +163,7 @@ obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
obj-$(CONFIG_REGULATOR_STM32_PWR) += stm32-pwr.o
obj-$(CONFIG_REGULATOR_STPMIC1) += stpmic1_regulator.o
obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
+obj-$(CONFIG_REGULATOR_SUN20I) += sun20i-regulator.o
obj-$(CONFIG_REGULATOR_SY7636A) += sy7636a-regulator.o
obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
obj-$(CONFIG_REGULATOR_SY8824X) += sy8824x.o
diff --git a/drivers/regulator/sun20i-regulator.c b/drivers/regulator/sun20i-regulator.c
new file mode 100644
index 000000000000..8af6b8037ee0
--- /dev/null
+++ b/drivers/regulator/sun20i-regulator.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (c) 2021-2022 Samuel Holland <[email protected]>
+//
+
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+
+#define SUN20I_SYS_LDO_CTRL_REG 0x150
+
+struct sun20i_regulator_data {
+ const struct regulator_desc *descs;
+ unsigned int ndescs;
+};
+
+/* regulator_list_voltage_linear() modified for the non-integral uV_step. */
+static int sun20i_d1_system_ldo_list_voltage(struct regulator_dev *rdev,
+ unsigned int selector)
+{
+ const struct regulator_desc *desc = rdev->desc;
+ unsigned int fraction, uV;
+
+ if (selector >= desc->n_voltages)
+ return -EINVAL;
+
+ uV = desc->min_uV + (desc->uV_step * selector);
+ fraction = selector + (desc->min_uV % 4);
+
+ if (uV > 1606667)
+ uV += 6667;
+ else
+ fraction++;
+
+ /* Produce correctly-rounded absolute voltages. */
+ return uV + (fraction / 3);
+}
+
+static const struct regulator_ops sun20i_d1_system_ldo_ops = {
+ .list_voltage = sun20i_d1_system_ldo_list_voltage,
+ .map_voltage = regulator_map_voltage_ascend,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+};
+
+static const struct regulator_desc sun20i_d1_system_ldo_descs[] = {
+ {
+ .name = "ldoa",
+ .supply_name = "ldo-in",
+ .of_match = "ldoa",
+ .ops = &sun20i_d1_system_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .n_voltages = 32,
+ .min_uV = 1593333,
+ .uV_step = 13333, /* repeating */
+ .vsel_reg = SUN20I_SYS_LDO_CTRL_REG,
+ .vsel_mask = GENMASK(7, 0),
+ },
+ {
+ .name = "ldob",
+ .supply_name = "ldo-in",
+ .of_match = "ldob",
+ .ops = &sun20i_d1_system_ldo_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .n_voltages = 64,
+ .min_uV = 1166666,
+ .uV_step = 13333, /* repeating */
+ .vsel_reg = SUN20I_SYS_LDO_CTRL_REG,
+ .vsel_mask = GENMASK(15, 8),
+ },
+};
+
+static const struct sun20i_regulator_data sun20i_d1_system_ldos = {
+ .descs = sun20i_d1_system_ldo_descs,
+ .ndescs = ARRAY_SIZE(sun20i_d1_system_ldo_descs),
+};
+
+static struct regmap *sun20i_regulator_get_regmap(struct device *dev)
+{
+ struct regmap *regmap;
+
+ /*
+ * First try the syscon interface. The system control device is not
+ * compatible with "syscon", so fall back to getting the regmap from
+ * its platform device. This is ugly, but required for devicetree
+ * backward compatibility.
+ */
+ regmap = syscon_node_to_regmap(dev->parent->of_node);
+ if (!IS_ERR(regmap))
+ return regmap;
+
+ regmap = dev_get_regmap(dev->parent, NULL);
+ if (regmap)
+ return regmap;
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+static int sun20i_regulator_probe(struct platform_device *pdev)
+{
+ const struct sun20i_regulator_data *data;
+ struct device *dev = &pdev->dev;
+ struct regulator_config config;
+ struct regmap *regmap;
+
+ data = of_device_get_match_data(dev);
+ if (!data)
+ return -EINVAL;
+
+ regmap = sun20i_regulator_get_regmap(dev);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "Failed to get regmap\n");
+
+ config = (struct regulator_config) {
+ .dev = dev,
+ .regmap = regmap,
+ };
+
+ for (unsigned int i = 0; i < data->ndescs; ++i) {
+ const struct regulator_desc *desc = &data->descs[i];
+ struct regulator_dev *rdev;
+
+ rdev = devm_regulator_register(dev, desc, &config);
+ if (IS_ERR(rdev))
+ return PTR_ERR(rdev);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id sun20i_regulator_of_match[] = {
+ {
+ .compatible = "allwinner,sun20i-d1-system-ldos",
+ .data = &sun20i_d1_system_ldos,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, sun20i_regulator_of_match);
+
+static struct platform_driver sun20i_regulator_driver = {
+ .probe = sun20i_regulator_probe,
+ .driver = {
+ .name = "sun20i-regulator",
+ .of_match_table = sun20i_regulator_of_match,
+ },
+};
+module_platform_driver(sun20i_regulator_driver);
+
+MODULE_AUTHOR("Samuel Holland <[email protected]>");
+MODULE_DESCRIPTION("Allwinner D1 internal LDO driver");
+MODULE_LICENSE("GPL");
--
2.39.2
On Tue, May 07, 2024 at 12:13:41PM +0800, Chen-Yu Tsai wrote:
> This is a resend of the Allwinner D1 LDO driver series, separated by
> subsystem. This part contains just the regulator driver bits. The sunxi
> SRAM binding part will be sent out after the merge window due to a
> conflict in next.
..
> A binding and driver change is required for the SRAM controller, to
> accept the regulators device as its child node.
This says that the driver depends on the SRAM change which isn't getting
merged this time round?
On Tue, May 7, 2024 at 10:46 PM Mark Brown <[email protected]> wrote:
>
> On Tue, May 07, 2024 at 12:13:41PM +0800, Chen-Yu Tsai wrote:
>
> > This is a resend of the Allwinner D1 LDO driver series, separated by
> > subsystem. This part contains just the regulator driver bits. The sunxi
> > SRAM binding part will be sent out after the merge window due to a
> > conflict in next.
>
> ...
>
> > A binding and driver change is required for the SRAM controller, to
> > accept the regulators device as its child node.
>
> This says that the driver depends on the SRAM change which isn't getting
> merged this time round?
The SRAM driver change was already merged. The regulator DT binding doesn't
depend on the SRAM binding change; it's the other way around: the SRAM
binding change adds a reference to the new regulator binding.
Hope that explains things.
ChenYu
On Tue, May 07, 2024 at 12:13:43PM +0800, Chen-Yu Tsai wrote:
> From: Samuel Holland <[email protected]>
>
> D1 contains two pairs of LDOs, "analog" LDOs and "system" LDOs. They are
> similar and can share a driver, but only the system LDOs have a DT
> binding defined so far.
This doesn't build on at least multi_v5_defconfig, multi_v7_defconfig
and arm64 defconfig:
/build/stage/linux/drivers/regulator/sun20i-regulator.c: In function ‘sun20i_reg
ulator_probe’:
/build/stage/linux/drivers/regulator/sun20i-regulator.c:111:16: error: implicit
declaration of function ‘of_device_get_match_data’ [-Werror=implicit-function-de
claration]
111 | data = of_device_get_match_data(dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~
/build/stage/linux/drivers/regulator/sun20i-regulator.c:111:14: warning: assignm
ent to ‘const struct sun20i_regulator_data *’ from ‘int’ makes pointer from inte
ger without a cast [-Wint-conversion]
111 | data = of_device_get_match_data(dev);
| ^
/build/stage/linux/drivers/regulator/sun20i-regulator.c: At top level:
/build/stage/linux/drivers/regulator/sun20i-regulator.c:136:34: error: array typ
e has incomplete element type ‘struct of_device_id’
136 | static const struct of_device_id sun20i_regulator_of_match[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~
/build/stage/linux/drivers/regulator/sun20i-regulator.c:136:34: warning: ‘sun20i
_regulator_of_match’ defined but not used [-Wunused-variable]
On Thu, May 9, 2024 at 12:50 PM Mark Brown <[email protected]> wrote:
>
> On Tue, May 07, 2024 at 12:13:43PM +0800, Chen-Yu Tsai wrote:
> > From: Samuel Holland <[email protected]>
> >
> > D1 contains two pairs of LDOs, "analog" LDOs and "system" LDOs. They are
> > similar and can share a driver, but only the system LDOs have a DT
> > binding defined so far.
>
> This doesn't build on at least multi_v5_defconfig, multi_v7_defconfig
> and arm64 defconfig:
>
> /build/stage/linux/drivers/regulator/sun20i-regulator.c: In function ‘sun20i_reg
> ulator_probe’:
> /build/stage/linux/drivers/regulator/sun20i-regulator.c:111:16: error: implicit
> declaration of function ‘of_device_get_match_data’ [-Werror=implicit-function-de
> claration]
> 111 | data = of_device_get_match_data(dev);
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> /build/stage/linux/drivers/regulator/sun20i-regulator.c:111:14: warning: assignm
> ent to ‘const struct sun20i_regulator_data *’ from ‘int’ makes pointer from inte
> ger without a cast [-Wint-conversion]
> 111 | data = of_device_get_match_data(dev);
> | ^
> /build/stage/linux/drivers/regulator/sun20i-regulator.c: At top level:
> /build/stage/linux/drivers/regulator/sun20i-regulator.c:136:34: error: array typ
> e has incomplete element type ‘struct of_device_id’
> 136 | static const struct of_device_id sun20i_regulator_of_match[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> /build/stage/linux/drivers/regulator/sun20i-regulator.c:136:34: warning: ‘sun20i
> _regulator_of_match’ defined but not used [-Wunused-variable]
Looks like the patch was from when of_device.h still included of.h.
I'll send a new version shortly.
ChenYu
On Tue, 07 May 2024 12:13:41 +0800, Chen-Yu Tsai wrote:
> This is a resend of the Allwinner D1 LDO driver series, separated by
> subsystem. This part contains just the regulator driver bits. The sunxi
> SRAM binding part will be sent out after the merge window due to a
> conflict in next.
>
> Original cover letter:
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/2] regulator: dt-bindings: Add Allwinner D1 system LDOs
commit: 622bab1884847fcf3f9bfdf1d534fac3a5fe859f
[2/2] regulator: sun20i: Add Allwinner D1 LDOs driver
commit: 4e70b26c873dfff317039458a6ea66314bbdce99
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark