* Re: [PATCH v3 4/4] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 14:10 UTC (permalink / raw)
To: Stephan Gerhold
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Allison Randal
In-Reply-To: <20200519132512.GC4623@gerhold.net>
On Tue, May 19, 2020 at 03:25:12PM +0200, Stephan Gerhold wrote:
> On Tue, May 19, 2020 at 02:43:54PM +0200, Jonathan Albrieux wrote:
> > According to AK09911 datasheet, if reset gpio is provided then
> > deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
> >
> > Without reset's deassertion during ak8975_power_on(), driver's probe fails
> > on ak8975_who_i_am while() checking for device identity for AK09911 chip.
> >
> > AK09911 has an active low reset gpio to handle register's reset.
> > AK09911 datasheed says that, if not used, reset pin should be connected
>
> Another minor typo: datasheed -> datasheet
>
> In any case, FWIW:
> Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
>
> > to VID. This patch emulates this situation.
> >
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> > ---
> > drivers/iio/magnetometer/ak8975.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> > index fd368455cd7b..a23422aad97d 100644
> > --- a/drivers/iio/magnetometer/ak8975.c
> > +++ b/drivers/iio/magnetometer/ak8975.c
> > @@ -358,6 +358,7 @@ struct ak8975_data {
> > u8 asa[3];
> > long raw_to_gauss[3];
> > struct gpio_desc *eoc_gpiod;
> > + struct gpio_desc *reset_gpiod;
> > int eoc_irq;
> > wait_queue_head_t data_ready_queue;
> > unsigned long flags;
> > @@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
> > "Failed to enable specified Vid supply\n");
> > return ret;
> > }
> > +
> > + gpiod_set_value_cansleep(data->reset_gpiod, 0);
> > +
> > /*
> > * According to the datasheet the power supply rise time is 200us
> > * and the minimum wait time before mode setting is 100us, in
> > @@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
> > /* Disable attached power regulator if any. */
> > static void ak8975_power_off(const struct ak8975_data *data)
> > {
> > + gpiod_set_value_cansleep(data->reset_gpiod, 1);
> > +
> > regulator_disable(data->vid);
> > regulator_disable(data->vdd);
> > }
> > @@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
> > struct ak8975_data *data;
> > struct iio_dev *indio_dev;
> > struct gpio_desc *eoc_gpiod;
> > + struct gpio_desc *reset_gpiod;
> > const void *match;
> > unsigned int i;
> > int err;
> > @@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
> > if (eoc_gpiod)
> > gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
> >
> > + /*
> > + * According to AK09911 datasheet, if reset GPIO is provided then
> > + * deassert reset on ak8975_power_on() and assert reset on
> > + * ak8975_power_off().
> > + */
> > + reset_gpiod = devm_gpiod_get_optional(&client->dev,
> > + "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(reset_gpiod))
> > + return PTR_ERR(reset_gpiod);
> > +
> > /* Register with IIO */
> > indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> > if (indio_dev == NULL)
> > @@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
> >
> > data->client = client;
> > data->eoc_gpiod = eoc_gpiod;
> > + data->reset_gpiod = reset_gpiod;
> > data->eoc_irq = 0;
> >
> > err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
> > --
> > 2.17.1
Thank you, will fix that typo too,
Best regards,
Jonathan Albrieux
^ permalink raw reply
* Re: [PATCH v3 2/4] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 14:09 UTC (permalink / raw)
To: Stephan Gerhold
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519132354.GB4623@gerhold.net>
On Tue, May 19, 2020 at 03:23:54PM +0200, Stephan Gerhold wrote:
> On Tue, May 19, 2020 at 02:43:52PM +0200, Jonathan Albrieux wrote:
> > Add reset-gpio support.
> >
> > Without reset's deassertion during ak8975_power_on(), driver's probe fails
> > on ak8975_who_i_am() while checking for device identity for AK09911 chip.
> >
> > AK09911 has an active low reset gpio to handle register's reset.
> > AK09911 datasheed says that, if not used, reset pin should be connected
>
> datasheed -> datasheet
>
Will fix that soon
> > to VID. This patch emulates this situation.
> >
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> > ---
> > .../devicetree/bindings/iio/magnetometer/ak8975.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > index 86e3efa693a8..a82c0ff5d098 100644
> > --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > @@ -37,6 +37,9 @@ properties:
> > mount-matrix:
> > description: an optional 3x3 mounting rotation matrix
> >
> > + reset-gpio:
> > + description: an optional pin needed for AK09911 to set the reset state
>
> Maybe add a comment that this should be "usually active low".
>
> > +
> > required:
> > - compatible
> > - reg
> > @@ -53,6 +56,7 @@ examples:
> > reg = <0x0c>;
> > gpios = <&gpj0 7 0>;
> > vdd-supply = <&ldo_3v3_gnss>;
> > + reset-gpio = <&msmgpio 111 1>;
>
> Same here, reset-gpio = <&msmgpio 111 GPIO_ACTIVE_LOW>,
> would be more clear.
>
> > mount-matrix = "-0.984807753012208", /* x0 */
> > "0", /* y0 */
> > "-0.173648177666930", /* z0 */
> > --
> > 2.17.1
Thank you for the suggestions, will work on them,
Best regards,
Jonathan Albrieux
^ permalink raw reply
* [PATCH v1 4/4] arm64: configs: add pca9450 pmic driver
From: Robin Gong @ 2020-05-19 22:05 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, catalin.marinas, will, shawnguo,
anson.huang, festevam, s.hauer, john.lee
Cc: linux-kernel, devicetree, linux-arm-kernel, kernel, linux-imx
In-Reply-To: <1589925907-9195-1-git-send-email-yibin.gong@nxp.com>
Add pca9450 pmic driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c6c7e7e..36fcfd8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -550,6 +550,7 @@ CONFIG_REGULATOR_HI6421V530=y
CONFIG_REGULATOR_HI655X=y
CONFIG_REGULATOR_MAX77620=y
CONFIG_REGULATOR_MAX8973=y
+CONFIG_REGULATOR_PCA9450=y
CONFIG_REGULATOR_PFUZE100=y
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_QCOM_RPMH=y
--
2.7.4
^ permalink raw reply related
* [PATCH v1 3/4] arm64: dts: imx8mn-evk: add pca9450 for i.mx8mn-evk board
From: Robin Gong @ 2020-05-19 22:05 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, catalin.marinas, will, shawnguo,
anson.huang, festevam, s.hauer, john.lee
Cc: linux-kernel, devicetree, linux-arm-kernel, kernel, linux-imx
In-Reply-To: <1589925907-9195-1-git-send-email-yibin.gong@nxp.com>
Add pca9450 pmic driver for i.mx8mn-evk board.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mn-evk.dts | 96 +++++++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 6 ++
2 files changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
index 61f3519..b846526 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dts
@@ -13,6 +13,102 @@
compatible = "fsl,imx8mn-evk", "fsl,imx8mn";
};
+&i2c1 {
+ pmic: pmic@25 {
+ compatible = "nxp,pca9450b";
+ reg = <0x25>;
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 GPIO_ACTIVE_LOW>;
+
+ regulators {
+ buck1: BUCK1{
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ };
+
+ buck4: BUCK4{
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5{
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2: LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
&A53_0 {
/delete-property/operating-points-v2;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 85fc0aa..98f5324 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -223,6 +223,12 @@
>;
};
+ pinctrl_pmic: pmicirq {
+ fsl,pins = <
+ MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
+ >;
+ };
+
pinctrl_reg_usdhc2_vmmc: regusdhc2vmmc {
fsl,pins = <
MX8MN_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
--
2.7.4
^ permalink raw reply related
* [PATCH v1 2/4] dt-bindings: regulator: add pca9450 regulator yaml
From: Robin Gong @ 2020-05-19 22:05 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, catalin.marinas, will, shawnguo,
anson.huang, festevam, s.hauer, john.lee
Cc: linux-kernel, devicetree, linux-arm-kernel, kernel, linux-imx
In-Reply-To: <1589925907-9195-1-git-send-email-yibin.gong@nxp.com>
Add device binding doc for pca9450 pmic driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
.../bindings/regulator/nxp,pca9450-regulator.yaml | 190 +++++++++++++++++++++
1 file changed, 190 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
new file mode 100644
index 00000000..c2b0a8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
@@ -0,0 +1,190 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/nxp,pca9450-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PCA9450A/B/C Power Management Integrated Circuit regulators
+
+maintainers:
+ - Robin Gong <yibin.gong@nxp.com>
+
+description: |
+ Regulator nodes should be named to BUCK_<number> and LDO_<number>. The
+ definition for each of these nodes is defined using the standard
+ binding for regulators at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+ Datasheet is available at
+ https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf
+
+#The valid names for PCA9450 regulator nodes are:
+#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6,
+#LDO1, LDO2, LDO3, LDO4, LDO5
+#Note: Buck3 removed on PCA9450B and connect with Buck1 on PCA9450C.
+
+properties:
+ compatible:
+ enum:
+ - nxp,pca9450a
+ - nxp,pca9450b
+ - nxp,pca9450c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: |
+ list of regulators provided by this controller
+
+ patternProperties:
+ "^LDO[1-5]$":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ Properties for single LDO regulator.
+
+ properties:
+ regulator-name:
+ pattern: "^LDO[1-5]$"
+ description:
+ should be "LDO1", ..., "LDO5"
+
+ unevaluatedProperties: false
+
+ "^BUCK[1-6]$":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ Properties for single BUCK regulator.
+
+ properties:
+ regulator-name:
+ pattern: "^BUCK[1-6]$"
+ description:
+ should be "BUCK1", ..., "BUCK6"
+
+ nxp,dvs-run-voltage:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ minimum: 600000
+ maximum: 2187500
+ description:
+ PMIC default "RUN" state voltage in uV. Only Buck1~3 have such
+ dvs(dynamic voltage scaling) property.
+
+ nxp,dvs-standby-voltage:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ minimum: 600000
+ maximum: 2187500
+ description:
+ PMIC default "STANDBY" state voltage in uV. Only Buck1~3 have such
+ dvs(dynamic voltage scaling) property.
+
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic: pmic@25 {
+ compatible = "nxp,pca9450b";
+ reg = <0x25>;
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ };
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ ldo2: LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ ldo3: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v1 1/4] regulator: pca9450: add pca9450 pmic driver
From: Robin Gong @ 2020-05-19 22:05 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, catalin.marinas, will, shawnguo,
anson.huang, festevam, s.hauer, john.lee
Cc: linux-kernel, devicetree, linux-arm-kernel, kernel, linux-imx
In-Reply-To: <1589925907-9195-1-git-send-email-yibin.gong@nxp.com>
Add NXP pca9450 pmic driver.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/pca9450-regulator.c | 859 ++++++++++++++++++++++++++++++++++
include/linux/regulator/pca9450.h | 219 +++++++++
4 files changed, 1087 insertions(+)
create mode 100644 drivers/regulator/pca9450-regulator.c
create mode 100644 include/linux/regulator/pca9450.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index e8f7a09..d94c8ef 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -729,6 +729,14 @@ config REGULATOR_PBIAS
This driver provides support for OMAP pbias modelled
regulators.
+config REGULATOR_PCA9450
+ tristate "NXP PCA9450A/PCA9450B/PCA9450C regulator driver"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say y here to support the NXP PCA9450A/PCA9450B/PCA9450C PMIC
+ regulator driver.
+
config REGULATOR_PCAP
tristate "Motorola PCAP2 regulator driver"
depends on EZX_PCAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f1633..356ca89 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -93,6 +93,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
+obj-$(CONFIG_REGULATOR_PCA9450) += pca9450-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
obj-$(CONFIG_REGULATOR_PV88080) += pv88080-regulator.o
diff --git a/drivers/regulator/pca9450-regulator.c b/drivers/regulator/pca9450-regulator.c
new file mode 100644
index 00000000..bdf256d
--- /dev/null
+++ b/drivers/regulator/pca9450-regulator.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 NXP.
+ * NXP PCA9450 pmic driver
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
+#include <linux/regulator/pca9450.h>
+
+struct pc9450_dvs_config {
+ unsigned int run_reg; /* dvs0 */
+ unsigned int run_mask;
+ unsigned int standby_reg; /* dvs1 */
+ unsigned int standby_mask;
+};
+
+struct pca9450_regulator_desc {
+ struct regulator_desc desc;
+ const struct pc9450_dvs_config dvs;
+};
+
+struct pca9450 {
+ struct device *dev;
+ struct regmap *regmap;
+ enum pca9450_chip_type type;
+ unsigned int rcnt;
+ int irq;
+};
+
+static const struct regmap_range pca9450_status_range = {
+ .range_min = PCA9450_REG_INT1,
+ .range_max = PCA9450_REG_PWRON_STAT,
+};
+
+static const struct regmap_access_table pca9450_volatile_regs = {
+ .yes_ranges = &pca9450_status_range,
+ .n_yes_ranges = 1,
+};
+
+static const struct regmap_config pca9450_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .volatile_table = &pca9450_volatile_regs,
+ .max_register = PCA9450_MAX_REGISTER - 1,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+/*
+ * BUCK1/2/3
+ * BUCK1RAM[1:0] BUCK1 DVS ramp rate setting
+ * 00: 25mV/1usec
+ * 01: 25mV/2usec
+ * 10: 25mV/4usec
+ * 11: 25mV/8usec
+ */
+static int pca9450_dvs_set_ramp_delay(struct regulator_dev *rdev,
+ int ramp_delay)
+{
+ int id = rdev_get_id(rdev);
+ unsigned int ramp_value;
+
+ switch (ramp_delay) {
+ case 1 ... 3125:
+ ramp_value = BUCK1_RAMP_3P125MV;
+ break;
+ case 3126 ... 6250:
+ ramp_value = BUCK1_RAMP_6P25MV;
+ break;
+ case 6251 ... 12500:
+ ramp_value = BUCK1_RAMP_12P5MV;
+ break;
+ case 12501 ... 25000:
+ ramp_value = BUCK1_RAMP_25MV;
+ break;
+ default:
+ ramp_value = BUCK1_RAMP_25MV;
+ }
+
+ return regmap_update_bits(rdev->regmap, PCA9450_REG_BUCK1CTRL + id * 3,
+ BUCK1_RAMP_MASK, ramp_value << 6);
+}
+
+static struct regulator_ops pca9450_dvs_buck_regulator_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_ramp_delay = pca9450_dvs_set_ramp_delay,
+};
+
+static struct regulator_ops pca9450_buck_regulator_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+static struct regulator_ops pca9450_ldo_regulator_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+};
+
+/*
+ * BUCK1/2/3
+ * 0.60 to 2.1875V (12.5mV step)
+ */
+static const struct regulator_linear_range pca9450_dvs_buck_volts[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0x00, 0x7F, 12500),
+};
+
+/*
+ * BUCK4/5/6
+ * 0.6V to 3.4V (25mV step)
+ */
+static const struct regulator_linear_range pca9450_buck_volts[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0x00, 0x70, 25000),
+ REGULATOR_LINEAR_RANGE(3400000, 0x71, 0x7F, 0),
+};
+
+/*
+ * LDO1
+ * 1.6 to 3.3V ()
+ */
+static const struct regulator_linear_range pca9450_ldo1_volts[] = {
+ REGULATOR_LINEAR_RANGE(1600000, 0x00, 0x03, 100000),
+ REGULATOR_LINEAR_RANGE(3000000, 0x04, 0x07, 100000),
+};
+
+/*
+ * LDO2
+ * 0.8 to 1.15V (50mV step)
+ */
+static const struct regulator_linear_range pca9450_ldo2_volts[] = {
+ REGULATOR_LINEAR_RANGE(800000, 0x00, 0x07, 50000),
+};
+
+/*
+ * LDO3/4
+ * 0.8 to 3.3V (100mV step)
+ */
+static const struct regulator_linear_range pca9450_ldo34_volts[] = {
+ REGULATOR_LINEAR_RANGE(800000, 0x00, 0x19, 100000),
+ REGULATOR_LINEAR_RANGE(3300000, 0x1A, 0x1F, 0),
+};
+
+/*
+ * LDO5
+ * 1.8 to 3.3V (100mV step)
+ */
+static const struct regulator_linear_range pca9450_ldo5_volts[] = {
+ REGULATOR_LINEAR_RANGE(1800000, 0x00, 0x0F, 100000),
+};
+
+static int buck_set_dvs(const struct regulator_desc *desc,
+ struct device_node *np, struct regmap *regmap,
+ char *prop, unsigned int reg, unsigned int mask)
+{
+ int ret, i;
+ uint32_t uv;
+
+ ret = of_property_read_u32(np, prop, &uv);
+ if (ret) {
+ if (ret != -EINVAL)
+ return ret;
+ return 0;
+ }
+
+ for (i = 0; i < desc->n_voltages; i++) {
+ ret = regulator_desc_list_voltage_linear_range(desc, i);
+ if (ret < 0)
+ continue;
+ if (ret == uv) {
+ i <<= ffs(desc->vsel_mask) - 1;
+ ret = regmap_update_bits(regmap, reg, mask, i);
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static int pca9450_set_dvs_levels(struct device_node *np,
+ const struct regulator_desc *desc,
+ struct regulator_config *cfg)
+{
+ struct pca9450_regulator_desc *data = container_of(desc,
+ struct pca9450_regulator_desc, desc);
+ const struct pc9450_dvs_config *dvs = &data->dvs;
+ unsigned int reg, mask;
+ char *prop;
+ int i, ret = 0;
+
+ for (i = 0; i < PCA9450_DVS_LEVEL_MAX; i++) {
+ switch (i) {
+ case PCA9450_DVS_LEVEL_RUN:
+ prop = "nxp,dvs-run-voltage";
+ reg = dvs->run_reg;
+ mask = dvs->run_mask;
+ break;
+ case PCA9450_DVS_LEVEL_STANDBY:
+ prop = "nxp,dvs-standby-voltage";
+ reg = dvs->standby_reg;
+ mask = dvs->standby_mask;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = buck_set_dvs(desc, np, cfg->regmap, prop, reg, mask);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+static const struct pca9450_regulator_desc pca9450a_regulators[] = {
+ {
+ .desc = {
+ .name = "buck1",
+ .of_match = of_match_ptr("BUCK1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK1,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK1_VOLTAGE_NUM,
+ .linear_ranges = pca9450_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK1OUT_DVS0,
+ .vsel_mask = BUCK1OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK1CTRL,
+ .enable_mask = BUCK1_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK1OUT_DVS0,
+ .run_mask = BUCK1OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK1OUT_DVS1,
+ .standby_mask = BUCK1OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck2",
+ .of_match = of_match_ptr("BUCK2"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK2,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK2_VOLTAGE_NUM,
+ .linear_ranges = pca9450_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK2OUT_DVS0,
+ .vsel_mask = BUCK2OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK2CTRL,
+ .enable_mask = BUCK1_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK2OUT_DVS0,
+ .run_mask = BUCK2OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK2OUT_DVS1,
+ .standby_mask = BUCK2OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck3",
+ .of_match = of_match_ptr("BUCK3"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK3,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK3_VOLTAGE_NUM,
+ .linear_ranges = pca9450_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK3OUT_DVS0,
+ .vsel_mask = BUCK3OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK3CTRL,
+ .enable_mask = BUCK3_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK3OUT_DVS0,
+ .run_mask = BUCK3OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK3OUT_DVS1,
+ .standby_mask = BUCK3OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck4",
+ .of_match = of_match_ptr("BUCK4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK4,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK4OUT,
+ .vsel_mask = BUCK4OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK4CTRL,
+ .enable_mask = BUCK4_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck4",
+ .of_match = of_match_ptr("BUCK4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK4,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK4OUT,
+ .vsel_mask = BUCK4OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK4CTRL,
+ .enable_mask = BUCK4_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck5",
+ .of_match = of_match_ptr("BUCK5"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK5,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK5_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK5OUT,
+ .vsel_mask = BUCK5OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK5CTRL,
+ .enable_mask = BUCK5_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck6",
+ .of_match = of_match_ptr("BUCK6"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK6,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK6_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK6OUT,
+ .vsel_mask = BUCK6OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK6CTRL,
+ .enable_mask = BUCK6_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo1",
+ .of_match = of_match_ptr("LDO1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO1,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO1_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo1_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo1_volts),
+ .vsel_reg = PCA9450_REG_LDO1CTRL,
+ .vsel_mask = LDO1OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO1CTRL,
+ .enable_mask = LDO1_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo2",
+ .of_match = of_match_ptr("LDO2"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO2,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO2_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo2_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo2_volts),
+ .vsel_reg = PCA9450_REG_LDO2CTRL,
+ .vsel_mask = LDO2OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO2CTRL,
+ .enable_mask = LDO2_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo3",
+ .of_match = of_match_ptr("LDO3"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO3,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO3_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo34_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo34_volts),
+ .vsel_reg = PCA9450_REG_LDO3CTRL,
+ .vsel_mask = LDO3OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO3CTRL,
+ .enable_mask = LDO3_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo4",
+ .of_match = of_match_ptr("LDO4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO4,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo34_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo34_volts),
+ .vsel_reg = PCA9450_REG_LDO4CTRL,
+ .vsel_mask = LDO4OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO4CTRL,
+ .enable_mask = LDO4_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo5",
+ .of_match = of_match_ptr("LDO5"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO5,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO5_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo5_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo5_volts),
+ .vsel_reg = PCA9450_REG_LDO5CTRL_H,
+ .vsel_mask = LDO5HOUT_MASK,
+ .enable_reg = PCA9450_REG_LDO5CTRL_H,
+ .enable_mask = LDO5H_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+};
+
+/*
+ * Buck3 removed on PCA9450B and conneced with Buck1 internal for dual phase
+ * on PCA9450C as no Buck3.
+ */
+static const struct pca9450_regulator_desc pca9450bc_regulators[] = {
+ {
+ .desc = {
+ .name = "buck1",
+ .of_match = of_match_ptr("BUCK1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK1,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK1_VOLTAGE_NUM,
+ .linear_ranges = pca9450_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK1OUT_DVS0,
+ .vsel_mask = BUCK1OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK1CTRL,
+ .enable_mask = BUCK1_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK1OUT_DVS0,
+ .run_mask = BUCK1OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK1OUT_DVS1,
+ .standby_mask = BUCK1OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck2",
+ .of_match = of_match_ptr("BUCK2"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK2,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK2_VOLTAGE_NUM,
+ .linear_ranges = pca9450_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK2OUT_DVS0,
+ .vsel_mask = BUCK2OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK2CTRL,
+ .enable_mask = BUCK1_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK2OUT_DVS0,
+ .run_mask = BUCK2OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK2OUT_DVS1,
+ .standby_mask = BUCK2OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck4",
+ .of_match = of_match_ptr("BUCK4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK4,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK4OUT,
+ .vsel_mask = BUCK4OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK4CTRL,
+ .enable_mask = BUCK4_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck5",
+ .of_match = of_match_ptr("BUCK5"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK5,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK5_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK5OUT,
+ .vsel_mask = BUCK5OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK5CTRL,
+ .enable_mask = BUCK5_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck6",
+ .of_match = of_match_ptr("BUCK6"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK6,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK6_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK6OUT,
+ .vsel_mask = BUCK6OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK6CTRL,
+ .enable_mask = BUCK6_ENMODE_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo1",
+ .of_match = of_match_ptr("LDO1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO1,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO1_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo1_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo1_volts),
+ .vsel_reg = PCA9450_REG_LDO1CTRL,
+ .vsel_mask = LDO1OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO1CTRL,
+ .enable_mask = LDO1_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo2",
+ .of_match = of_match_ptr("LDO2"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO2,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO2_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo2_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo2_volts),
+ .vsel_reg = PCA9450_REG_LDO2CTRL,
+ .vsel_mask = LDO2OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO2CTRL,
+ .enable_mask = LDO2_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo3",
+ .of_match = of_match_ptr("LDO3"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO3,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO3_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo34_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo34_volts),
+ .vsel_reg = PCA9450_REG_LDO3CTRL,
+ .vsel_mask = LDO3OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO3CTRL,
+ .enable_mask = LDO3_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo4",
+ .of_match = of_match_ptr("LDO4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO4,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo34_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo34_volts),
+ .vsel_reg = PCA9450_REG_LDO4CTRL,
+ .vsel_mask = LDO4OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO4CTRL,
+ .enable_mask = LDO4_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo5",
+ .of_match = of_match_ptr("LDO5"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO5,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO5_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo5_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo5_volts),
+ .vsel_reg = PCA9450_REG_LDO5CTRL_H,
+ .vsel_mask = LDO5HOUT_MASK,
+ .enable_reg = PCA9450_REG_LDO5CTRL_H,
+ .enable_mask = LDO5H_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+};
+
+static irqreturn_t pca9450_irq_handler(int irq, void *data)
+{
+ struct pca9450 *pca9450 = data;
+ struct regmap *regmap = pca9450->regmap;
+ unsigned int status;
+ int ret;
+
+ ret = regmap_read(regmap, PCA9450_REG_INT1, &status);
+ if (ret < 0) {
+ dev_err(pca9450->dev,
+ "Failed to read INT1(%d)\n", ret);
+ return IRQ_NONE;
+ }
+
+ if (status & IRQ_PWRON)
+ dev_warn(pca9450->dev, "PWRON interrupt.\n");
+
+ if (status & IRQ_WDOGB)
+ dev_warn(pca9450->dev, "WDOGB interrupt.\n");
+
+ if (status & IRQ_VR_FLT1)
+ dev_warn(pca9450->dev, "VRFLT1 interrupt.\n");
+
+ if (status & IRQ_VR_FLT2)
+ dev_warn(pca9450->dev, "VRFLT2 interrupt.\n");
+
+ if (status & IRQ_LOWVSYS)
+ dev_warn(pca9450->dev, "LOWVSYS interrupt.\n");
+
+ if (status & IRQ_THERM_105)
+ dev_warn(pca9450->dev, "IRQ_THERM_105 interrupt.\n");
+
+ if (status & IRQ_THERM_125)
+ dev_warn(pca9450->dev, "IRQ_THERM_125 interrupt.\n");
+
+ return IRQ_HANDLED;
+}
+
+static int pca9450_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ enum pca9450_chip_type type = (unsigned int)(uintptr_t)
+ of_device_get_match_data(&i2c->dev);
+ const struct pca9450_regulator_desc *regulator_desc;
+ struct regulator_config config = { };
+ struct pca9450 *pca9450;
+ unsigned int device_id, i;
+ int ret;
+
+ if (!i2c->irq) {
+ dev_err(&i2c->dev, "No IRQ configured?\n");
+ return -EINVAL;
+ }
+
+ pca9450 = devm_kzalloc(&i2c->dev, sizeof(struct pca9450), GFP_KERNEL);
+ if (!pca9450)
+ return -ENOMEM;
+
+ switch (type) {
+ case PCA9450_TYPE_PCA9450A:
+ regulator_desc = pca9450a_regulators;
+ pca9450->rcnt = ARRAY_SIZE(pca9450a_regulators);
+ break;
+ case PCA9450_TYPE_PCA9450BC:
+ regulator_desc = pca9450bc_regulators;
+ pca9450->rcnt = ARRAY_SIZE(pca9450bc_regulators);
+ break;
+ default:
+ dev_err(&i2c->dev, "Unknown device type");
+ return -EINVAL;
+ }
+
+ pca9450->irq = i2c->irq;
+ pca9450->type = type;
+ pca9450->dev = &i2c->dev;
+
+ dev_set_drvdata(&i2c->dev, pca9450);
+
+ pca9450->regmap = devm_regmap_init_i2c(i2c,
+ &pca9450_regmap_config);
+ if (IS_ERR(pca9450->regmap)) {
+ dev_err(&i2c->dev, "regmap initialization failed\n");
+ return PTR_ERR(pca9450->regmap);
+ }
+
+ ret = regmap_read(pca9450->regmap, PCA9450_REG_DEV_ID, &device_id);
+ if (ret) {
+ dev_err(&i2c->dev, "Read device id error\n");
+ return ret;
+ }
+
+ /* Check your board and dts for match the right pmic */
+ if (((device_id >> 4) != 0x1 && type == PCA9450_TYPE_PCA9450A) ||
+ ((device_id >> 4) != 0x3 && type == PCA9450_TYPE_PCA9450BC)) {
+ dev_err(&i2c->dev, "Device id(%x) mismatched\n",
+ device_id >> 4);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < pca9450->rcnt; i++) {
+ const struct regulator_desc *desc;
+ struct regulator_dev *rdev;
+ const struct pca9450_regulator_desc *r;
+
+ r = ®ulator_desc[i];
+ desc = &r->desc;
+
+ config.regmap = pca9450->regmap;
+ config.dev = pca9450->dev;
+
+ rdev = devm_regulator_register(pca9450->dev, desc, &config);
+ if (IS_ERR(rdev)) {
+ ret = PTR_ERR(rdev);
+ dev_err(pca9450->dev,
+ "Failed to register regulator(%s): %d\n",
+ desc->name, ret);
+ return ret;
+ }
+ }
+
+ ret = devm_request_threaded_irq(pca9450->dev, pca9450->irq, NULL,
+ pca9450_irq_handler,
+ (IRQF_TRIGGER_FALLING | IRQF_ONESHOT),
+ "pca9450-irq", pca9450);
+ if (ret != 0) {
+ dev_err(pca9450->dev, "Failed to request IRQ: %d\n",
+ pca9450->irq);
+ return ret;
+ }
+ /* Unmask all interrupt except PWRON/WDOG/RSVD */
+ ret = regmap_update_bits(pca9450->regmap, PCA9450_REG_INT1_MSK,
+ IRQ_VR_FLT1 | IRQ_VR_FLT2 | IRQ_LOWVSYS |
+ IRQ_THERM_105 | IRQ_THERM_125,
+ IRQ_PWRON | IRQ_WDOGB | IRQ_RSVD);
+ if (ret) {
+ dev_err(&i2c->dev, "Unmask irq error\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id pca9450_of_match[] = {
+ {
+ .compatible = "nxp,pca9450a",
+ .data = (void *)PCA9450_TYPE_PCA9450A,
+ },
+ {
+ .compatible = "nxp,pca9450b",
+ .data = (void *)PCA9450_TYPE_PCA9450BC,
+ },
+ {
+ .compatible = "nxp,pca9450c",
+ .data = (void *)PCA9450_TYPE_PCA9450BC,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pca9450_of_match);
+
+static struct i2c_driver pca9450_i2c_driver = {
+ .driver = {
+ .name = "nxp-pca9450",
+ .of_match_table = pca9450_of_match,
+ },
+ .probe = pca9450_i2c_probe,
+};
+
+static int __init pca9450_i2c_init(void)
+{
+ return i2c_add_driver(&pca9450_i2c_driver);
+}
+module_init(pca9450_i2c_init);
+
+static void __exit pca9450_i2c_exit(void)
+{
+ i2c_del_driver(&pca9450_i2c_driver);
+}
+module_exit(pca9450_i2c_exit);
+
+MODULE_AUTHOR("Robin Gong <yibin.gong@nxp.com>");
+MODULE_DESCRIPTION("NXP PCA9450 Power Management IC driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/regulator/pca9450.h b/include/linux/regulator/pca9450.h
new file mode 100644
index 00000000..1bbd301
--- /dev/null
+++ b/include/linux/regulator/pca9450.h
@@ -0,0 +1,219 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* Copyright 2020 NXP. */
+
+#ifndef __LINUX_REG_PCA9450_H__
+#define __LINUX_REG_PCA9450_H__
+
+#include <linux/regmap.h>
+
+enum pca9450_chip_type {
+ PCA9450_TYPE_PCA9450A = 0,
+ PCA9450_TYPE_PCA9450BC,
+ PCA9450_TYPE_AMOUNT,
+};
+
+enum {
+ PCA9450_BUCK1 = 0,
+ PCA9450_BUCK2,
+ PCA9450_BUCK3,
+ PCA9450_BUCK4,
+ PCA9450_BUCK5,
+ PCA9450_BUCK6,
+ PCA9450_LDO1,
+ PCA9450_LDO2,
+ PCA9450_LDO3,
+ PCA9450_LDO4,
+ PCA9450_LDO5,
+ PCA9450_REGULATOR_CNT,
+};
+
+enum {
+ PCA9450_DVS_LEVEL_RUN = 0,
+ PCA9450_DVS_LEVEL_STANDBY,
+ PCA9450_DVS_LEVEL_MAX,
+};
+
+#define PCA9450_BUCK1_VOLTAGE_NUM 0x80
+#define PCA9450_BUCK2_VOLTAGE_NUM 0x80
+#define PCA9450_BUCK3_VOLTAGE_NUM 0x80
+#define PCA9450_BUCK4_VOLTAGE_NUM 0x80
+
+#define PCA9450_BUCK5_VOLTAGE_NUM 0x80
+#define PCA9450_BUCK6_VOLTAGE_NUM 0x80
+
+#define PCA9450_LDO1_VOLTAGE_NUM 0x08
+#define PCA9450_LDO2_VOLTAGE_NUM 0x08
+#define PCA9450_LDO3_VOLTAGE_NUM 0x20
+#define PCA9450_LDO4_VOLTAGE_NUM 0x20
+#define PCA9450_LDO5_VOLTAGE_NUM 0x10
+
+enum {
+ PCA9450_REG_DEV_ID = 0x00,
+ PCA9450_REG_INT1 = 0x01,
+ PCA9450_REG_INT1_MSK = 0x02,
+ PCA9450_REG_STATUS1 = 0x03,
+ PCA9450_REG_STATUS2 = 0x04,
+ PCA9450_REG_PWRON_STAT = 0x05,
+ PCA9450_REG_SWRST = 0x06,
+ PCA9450_REG_PWRCTRL = 0x07,
+ PCA9450_REG_RESET_CTRL = 0x08,
+ PCA9450_REG_CONFIG1 = 0x09,
+ PCA9450_REG_CONFIG2 = 0x0A,
+ PCA9450_REG_BUCK123_DVS = 0x0C,
+ PCA9450_REG_BUCK1OUT_LIMIT = 0x0D,
+ PCA9450_REG_BUCK2OUT_LIMIT = 0x0E,
+ PCA9450_REG_BUCK3OUT_LIMIT = 0x0F,
+ PCA9450_REG_BUCK1CTRL = 0x10,
+ PCA9450_REG_BUCK1OUT_DVS0 = 0x11,
+ PCA9450_REG_BUCK1OUT_DVS1 = 0x12,
+ PCA9450_REG_BUCK2CTRL = 0x13,
+ PCA9450_REG_BUCK2OUT_DVS0 = 0x14,
+ PCA9450_REG_BUCK2OUT_DVS1 = 0x15,
+ PCA9450_REG_BUCK3CTRL = 0x16,
+ PCA9450_REG_BUCK3OUT_DVS0 = 0x17,
+ PCA9450_REG_BUCK3OUT_DVS1 = 0x18,
+ PCA9450_REG_BUCK4CTRL = 0x19,
+ PCA9450_REG_BUCK4OUT = 0x1A,
+ PCA9450_REG_BUCK5CTRL = 0x1B,
+ PCA9450_REG_BUCK5OUT = 0x1C,
+ PCA9450_REG_BUCK6CTRL = 0x1D,
+ PCA9450_REG_BUCK6OUT = 0x1E,
+ PCA9450_REG_LDO_AD_CTRL = 0x20,
+ PCA9450_REG_LDO1CTRL = 0x21,
+ PCA9450_REG_LDO2CTRL = 0x22,
+ PCA9450_REG_LDO3CTRL = 0x23,
+ PCA9450_REG_LDO4CTRL = 0x24,
+ PCA9450_REG_LDO5CTRL_L = 0x25,
+ PCA9450_REG_LDO5CTRL_H = 0x26,
+ PCA9450_REG_LOADSW_CTRL = 0x2A,
+ PCA9450_REG_VRFLT1_STS = 0x2B,
+ PCA9450_REG_VRFLT2_STS = 0x2C,
+ PCA9450_REG_VRFLT1_MASK = 0x2D,
+ PCA9450_REG_VRFLT2_MASK = 0x2E,
+ PCA9450_MAX_REGISTER = 0x2F,
+};
+
+/* PCA9450 BUCK ENMODE bits */
+#define BUCK_ENMODE_OFF 0x00
+#define BUCK_ENMODE_ONREQ 0x01
+#define BUCK_ENMODE_ONREQ_STBYREQ 0x02
+#define BUCK_ENMODE_ON 0x03
+
+/* PCA9450_REG_BUCK1_CTRL bits */
+#define BUCK1_RAMP_MASK 0xC0
+#define BUCK1_RAMP_25MV 0x0
+#define BUCK1_RAMP_12P5MV 0x1
+#define BUCK1_RAMP_6P25MV 0x2
+#define BUCK1_RAMP_3P125MV 0x3
+#define BUCK1_DVS_CTRL 0x10
+#define BUCK1_AD 0x08
+#define BUCK1_FPWM 0x04
+#define BUCK1_ENMODE_MASK 0x03
+
+/* PCA9450_REG_BUCK2_CTRL bits */
+#define BUCK2_RAMP_MASK 0xC0
+#define BUCK2_RAMP_25MV 0x0
+#define BUCK2_RAMP_12P5MV 0x1
+#define BUCK2_RAMP_6P25MV 0x2
+#define BUCK2_RAMP_3P125MV 0x3
+#define BUCK2_DVS_CTRL 0x10
+#define BUCK2_AD 0x08
+#define BUCK2_FPWM 0x04
+#define BUCK2_ENMODE_MASK 0x03
+
+/* PCA9450_REG_BUCK3_CTRL bits */
+#define BUCK3_RAMP_MASK 0xC0
+#define BUCK3_RAMP_25MV 0x0
+#define BUCK3_RAMP_12P5MV 0x1
+#define BUCK3_RAMP_6P25MV 0x2
+#define BUCK3_RAMP_3P125MV 0x3
+#define BUCK3_DVS_CTRL 0x10
+#define BUCK3_AD 0x08
+#define BUCK3_FPWM 0x04
+#define BUCK3_ENMODE_MASK 0x03
+
+/* PCA9450_REG_BUCK4_CTRL bits */
+#define BUCK4_AD 0x08
+#define BUCK4_FPWM 0x04
+#define BUCK4_ENMODE_MASK 0x03
+
+/* PCA9450_REG_BUCK5_CTRL bits */
+#define BUCK5_AD 0x08
+#define BUCK5_FPWM 0x04
+#define BUCK5_ENMODE_MASK 0x03
+
+/* PCA9450_REG_BUCK6_CTRL bits */
+#define BUCK6_AD 0x08
+#define BUCK6_FPWM 0x04
+#define BUCK6_ENMODE_MASK 0x03
+
+/* PCA9450_BUCK1OUT_DVS0 bits */
+#define BUCK1OUT_DVS0_MASK 0x7F
+#define BUCK1OUT_DVS0_DEFAULT 0x14
+
+/* PCA9450_BUCK1OUT_DVS1 bits */
+#define BUCK1OUT_DVS1_MASK 0x7F
+#define BUCK1OUT_DVS1_DEFAULT 0x14
+
+/* PCA9450_BUCK2OUT_DVS0 bits */
+#define BUCK2OUT_DVS0_MASK 0x7F
+#define BUCK2OUT_DVS0_DEFAULT 0x14
+
+/* PCA9450_BUCK2OUT_DVS1 bits */
+#define BUCK2OUT_DVS1_MASK 0x7F
+#define BUCK2OUT_DVS1_DEFAULT 0x14
+
+/* PCA9450_BUCK3OUT_DVS0 bits */
+#define BUCK3OUT_DVS0_MASK 0x7F
+#define BUCK3OUT_DVS0_DEFAULT 0x14
+
+/* PCA9450_BUCK3OUT_DVS1 bits */
+#define BUCK3OUT_DVS1_MASK 0x7F
+#define BUCK3OUT_DVS1_DEFAULT 0x14
+
+/* PCA9450_REG_BUCK4OUT bits */
+#define BUCK4OUT_MASK 0x7F
+#define BUCK4OUT_DEFAULT 0x6C
+
+/* PCA9450_REG_BUCK5OUT bits */
+#define BUCK5OUT_MASK 0x7F
+#define BUCK5OUT_DEFAULT 0x30
+
+/* PCA9450_REG_BUCK6OUT bits */
+#define BUCK6OUT_MASK 0x7F
+#define BUCK6OUT_DEFAULT 0x14
+
+/* PCA9450_REG_LDO1_VOLT bits */
+#define LDO1_EN_MASK 0xC0
+#define LDO1OUT_MASK 0x07
+
+/* PCA9450_REG_LDO2_VOLT bits */
+#define LDO2_EN_MASK 0xC0
+#define LDO2OUT_MASK 0x07
+
+/* PCA9450_REG_LDO3_VOLT bits */
+#define LDO3_EN_MASK 0xC0
+#define LDO3OUT_MASK 0x0F
+
+/* PCA9450_REG_LDO4_VOLT bits */
+#define LDO4_EN_MASK 0xC0
+#define LDO4OUT_MASK 0x0F
+
+/* PCA9450_REG_LDO5_VOLT bits */
+#define LDO5L_EN_MASK 0xC0
+#define LDO5LOUT_MASK 0x0F
+
+#define LDO5H_EN_MASK 0xC0
+#define LDO5HOUT_MASK 0x0F
+
+/* PCA9450_REG_IRQ bits */
+#define IRQ_PWRON 0x80
+#define IRQ_WDOGB 0x40
+#define IRQ_RSVD 0x20
+#define IRQ_VR_FLT1 0x10
+#define IRQ_VR_FLT2 0x08
+#define IRQ_LOWVSYS 0x04
+#define IRQ_THERM_105 0x02
+#define IRQ_THERM_125 0x01
+
+#endif /* __LINUX_REG_PCA9450_H__ */
--
2.7.4
^ permalink raw reply related
* [PATCH v1 0/4] Add pca9450 driver
From: Robin Gong @ 2020-05-19 22:05 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, catalin.marinas, will, shawnguo,
anson.huang, festevam, s.hauer, john.lee
Cc: linux-kernel, devicetree, linux-arm-kernel, kernel, linux-imx
Add pca9450 driver for i.mx8mn-evk board. PCA9450A/B/C supported now.
Please refer to below link for PCA9450 datasheet:
https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf
Robin Gong (4):
regulator: pca9450: add pca9450 pmic driver
dt-bindings: regulator: add pca9450 regulator yaml
arm64: dts: imx8mn-evk: add pca9450 for i.mx8mn-evk board
arm64: configs: add pca9450 pmic driver
.../bindings/regulator/nxp,pca9450-regulator.yaml | 190 +++++
arch/arm64/boot/dts/freescale/imx8mn-evk.dts | 96 +++
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 6 +
arch/arm64/configs/defconfig | 1 +
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/pca9450-regulator.c | 859 +++++++++++++++++++++
include/linux/regulator/pca9450.h | 219 ++++++
8 files changed, 1380 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
create mode 100644 drivers/regulator/pca9450-regulator.c
create mode 100644 include/linux/regulator/pca9450.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: iio: magnetometer: ak8975: convert txt format to yaml
From: Jonathan Albrieux @ 2020-05-19 14:03 UTC (permalink / raw)
To: Stephan Gerhold
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519132207.GA4623@gerhold.net>
On Tue, May 19, 2020 at 03:22:07PM +0200, Stephan Gerhold wrote:
> On Tue, May 19, 2020 at 02:43:51PM +0200, Jonathan Albrieux wrote:
> > Converts documentation from txt format to yaml.
> >
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> > ---
> > .../bindings/iio/magnetometer/ak8975.txt | 30 ---------
> > .../bindings/iio/magnetometer/ak8975.yaml | 66 +++++++++++++++++++
> > 2 files changed, 66 insertions(+), 30 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > deleted file mode 100644
> > index aa67ceb0d4e0..000000000000
> > --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > +++ /dev/null
> > @@ -1,30 +0,0 @@
> > -* AsahiKASEI AK8975 magnetometer sensor
> > -
> > -Required properties:
> > -
> > - - compatible : should be "asahi-kasei,ak8975"
> > - - reg : the I2C address of the magnetometer
> > -
> > -Optional properties:
> > -
> > - - gpios : should be device tree identifier of the magnetometer DRDY pin
> > - - vdd-supply: an optional regulator that needs to be on to provide VDD
> > - - mount-matrix: an optional 3x3 mounting rotation matrix
> > -
> > -Example:
> > -
> > -ak8975@c {
> > - compatible = "asahi-kasei,ak8975";
> > - reg = <0x0c>;
> > - gpios = <&gpj0 7 0>;
> > - vdd-supply = <&ldo_3v3_gnss>;
> > - mount-matrix = "-0.984807753012208", /* x0 */
> > - "0", /* y0 */
> > - "-0.173648177666930", /* z0 */
> > - "0", /* x1 */
> > - "-1", /* y1 */
> > - "0", /* z1 */
> > - "-0.173648177666930", /* x2 */
> > - "0", /* y2 */
> > - "0.984807753012208"; /* z2 */
> > -};
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > new file mode 100644
> > index 000000000000..86e3efa693a8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > @@ -0,0 +1,66 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: AsahiKASEI AK8975 magnetometer sensor
> > +
> > +maintainers:
> > + - can't find a mantainer, author is Laxman Dewangan <ldewangan@nvidia.com>
>
> Should probably add someone here, although I'm not sure who either.
>
Yep I couldn't find a maintainer for that driver..what to do in this case?
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - "asahi-kasei,ak8975"
> > + - "ak8975"
> > + - "asahi-kasei,ak8963"
> > + - "ak8963"
> > + - "asahi-kasei,ak09911"
> > + - "ak09911"
> > + - "asahi-kasei,ak09912"
> > + - "ak09912"
> > +
>
> I wonder if the ones without vendor prefix (asahi-kasei,) should be
> marked as deprecated somehow?
>
> Looking at some other schemas I see either a "# deprecated" comment, or:
>
> properties:
> compatible:
> oneOf:
> - const: asahi-kasei,ak8975
> - const: asahi-kasei,ak8963
> - const: asahi-kasei,ak09911
> - const: asahi-kasei,ak09912
> - const: ak8975
> deprecated: true
> - const: ak8963
> deprecated: true
> - const: ak09911
> deprecated: true
> - const: ak09912
> deprecated: true
>
> (e.g. in Documentation/devicetree/bindings/sound/samsung,odroid.yaml)
> I guess this one is preferred since it allows parsing those
> compatibles as deprecated?
>
Ok I'll work on it
> > + reg:
> > + maxItems: 1
> > + description: the I2C address of the magnetometer
> > +
> > + gpios:
> > + description: should be device tree identifier of the magnetometer DRDY pin
> > +
> > + vdd-supply:
> > + maxItems: 1
> > + description: |
> > + an optional regulator that needs to be on to provide VDD power to
> > + the sensor.
> > +
> > + mount-matrix:
> > + description: an optional 3x3 mounting rotation matrix
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> > + - |
> > + i2c@78b7000 {
> > + reg = <0x78b6000 0x600>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ak8975@c {
>
> Per device tree specification this should preferably use a generic name
> describing the function of the device, i.e. magnetometer@c.
>
> > + compatible = "asahi-kasei,ak8975";
> > + reg = <0x0c>;
> > + gpios = <&gpj0 7 0>;
>
Yes it would be better, I'll work on that too
> I think using the dt-bindings constants for the GPIO flags is preferred
> now, i.e. gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>.
>
> > + vdd-supply = <&ldo_3v3_gnss>;
> > + mount-matrix = "-0.984807753012208", /* x0 */
> > + "0", /* y0 */
> > + "-0.173648177666930", /* z0 */
> > + "0", /* x1 */
> > + "-1", /* y1 */
> > + "0", /* z1 */
> > + "-0.173648177666930", /* x2 */
> > + "0", /* y2 */
> > + "0.984807753012208"; /* z2 */
> > + };
> > + };
> > --
> > 2.17.1
Thank you for having took the time to review, will work on edits right now.
I just have a question: by creating the new patchset how can I deal with
the "Reviewed by"? It's the first patch I submit and still haven't dealt
with the full process,
Best regards,
Jonathan Albrieux
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Lukasz Stelmach @ 2020-05-19 14:02 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Geert Uytterhoeven, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <20200519131252.GD1551@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 5360 bytes --]
It was <2020-05-19 wto 14:12>, when Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 02:49:57PM +0200, Lukasz Stelmach wrote:
>> It was <2020-05-19 wto 13:27>, when Russell King - ARM Linux admin wrote:
>>> On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
>>>> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
>>>>> On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
>>>>>> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
>>>>>> <linux@armlinux.org.uk> wrote:
>>>>>>> On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
>>>>>>>> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
>>>>>>>>> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
>>>>>>>>>> Currently, the start address of physical memory is obtained by masking
>>>>>>>>>> the program counter with a fixed mask of 0xf8000000. This mask value
>>>>>>>>>> was chosen as a balance between the requirements of different platforms.
>>>>>>>>>> However, this does require that the start address of physical memory is
>>>>>>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>>>>>>> requirement is not fulfilled.
>>>>>>>>>>
>>>>>>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>>>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>>>>>>> Fall back to the traditional method when needed.
>> [...]
>>>>>>>>> Apparently reading physical memory layout from DTB breaks crashdump
>>>>>>>>> kernels. A crashdump kernel is loaded into a region of memory, that is
>>>>>>>>> reserved in the original (i.e. to be crashed) kernel. The reserved
>>>>>>>>> region is large enough for the crashdump kernel to run completely inside
>>>>>>>>> it and don't modify anything outside it, just read and dump the remains
>>>>>>>>> of the crashed kernel. Using the information from DTB makes the
>>>>>>>>> decompressor place the kernel outside of the dedicated region.
>>>>>>>>>
>>>>>>>>> The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
>>>>>>>>> 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
>>>>>>>>> it is decompressed to 0x00008000 (see r4 reported before jumping from
>>>>>>>>> within __enter_kernel). If I were to suggest something, there need to be
>>>>>>>>> one more bit of information passed in the DTB telling the decompressor
>>>>>>>>> to use the old masking technique to determain kernel address. It would
>>>>>>>>> be set in the DTB loaded along with the crashdump kernel.
>> [...]
>>>>>>>> Describing "to use the old masking technique" sounds a bit hackish to me.
>>>>>>>> I guess it cannot just restrict the /memory node to the reserved region,
>>>>>>>> as the crashkernel needs to be able to dump the remains of the crashed
>>>>>>>> kernel, which lie outside this region.
>>>>>>>
>>>>>>> Correct.
>>>>>>>
>>>>>>>> However, something under /chosen should work.
>>>>>>>
>>>>>>> Yet another sticky plaster...
>>>>>>
>>>>>> IMHO the old masking technique is the hacky solution covered by
>>>>>> plasters.
>>>>>
>>>>> One line of code is not "covered by plasters". There are no plasters.
>>>>> It's a solution that works for 99.99% of people, unlike your approach
>>>>> that has had a stream of issues over the last four months, and has
>>>>> required many reworks of the code to fix each one. That in itself
>>>>> speaks volumes about the suitability of the approach.
>>>>
>>>> As I have been working with kexec code (patches soon) I would like to
>>>> defend the DT approach a bit. It allows to avoid zImage relocation when
>>>> a decompressed kernel is larger than ~128MiB. In such case zImage isn't
>>>> small either and moving it around takes some time.
>>>
>>> ... which is something that has been supported for a very long time,
>>> before the days of DT.
>>
>> How? If a decompressed kernel requires >128M and a bootloader would like
>> to put a zImage high enough to *avoid* copying it once again, then the
>> decompressor can't see any memory below the 128M window it starts in and
>> can't decompress the kernel there.
>
> Do you have such a large kernel? It would be rather inefficient as
> branch instructions could not be used; every function call would have
> to be indirect. The maximum is +/- 32MB for a branch.
This number includes data, particularly initramfs which may be linked
into the kernel. Assuming kernel <32MB (15MB like min ATM) we are left
with slightly more than 100MB. Which isn't that much if you would like
it to be root file system for your device.
Of course initramfs could be loaded separately by a bootloader and yet
having both kernel and initramfs in one file has some advantages.
I am not here to argue. It's your call.
>> If we do not care about copying
>> zImage, then, indeed, everything works fine as it is today. You are
>> most probably right 99% doesn't require 128M kernel, but the case is
>> IMHO obvious enough, that it should be adressed somehow.
>
> If I have a kernel in excess of 4GB... "it should be addressed somehow"!
I believe software and hardware limitations should not be compared this
way.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply
* Re: [PATCH V1 1/7] dt-bindings: mmc: Add information for DLL register properties
From: sartgarg @ 2020-05-19 14:00 UTC (permalink / raw)
To: Rob Herring
Cc: adrian.hunter, ulf.hansson, vbadigan, stummala, linux-mmc,
linux-kernel, linux-arm-msm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-mmc-owner
In-Reply-To: <20200515025047.GA27895@bogus>
On 2020-05-15 08:20, Rob Herring wrote:
> On Thu, May 07, 2020 at 01:32:08PM +0530, Sarthak Garg wrote:
>> Add information regarding DLL register properties for getting target
>> specific configurations. These DLL register settings may vary from
>> target to target.
>>
>> Also new compatible string value for sm8250 target.
>>
>> Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 14
>> ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>> index 5445931..b8e1d2b 100644
>> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>> @@ -17,6 +17,7 @@ Required properties:
>> "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4"
>> "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4"
>> "qcom,msm8996-sdhci", "qcom,sdhci-msm-v4"
>> + "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5"
>> "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5"
>> "qcom,qcs404-sdhci", "qcom,sdhci-msm-v5"
>> "qcom,sc7180-sdhci", "qcom,sdhci-msm-v5";
>> @@ -46,6 +47,13 @@ Required properties:
>> "cal" - reference clock for RCLK delay calibration (optional)
>> "sleep" - sleep clock for RCLK delay calibration (optional)
>>
>> +- qcom,ddr-config: Certain chipsets and platforms require particular
>> settings
>> + for the DDR_CONFIG register. Use this field to specify the register
>> + value as per the Hardware Programming Guide.
>> +
>> +- qcom,dll-config: Chipset and Platform specific value. Use this
>> field to
>> + specify the DLL_CONFIG register value as per Hardware Programming
>> Guide.
>
> Board specific or SoC specific? If the latter, imply this from the
> compatible string.
Reposting again as can't find my comment on the
https://patchwork.kernel.org/ page.
Whatever DLL settings are SOC specific are being taken care with the
compatible string.
That is the reason we introduced qcom,sm8250-sdhci string.
The above listed two configuration can change from board to board
as-well.
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Ard Biesheuvel @ 2020-05-19 13:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux admin, Lukasz Stelmach, Dmitry Osipenko,
Nicolas Pitre, Arnd Bergmann, Eric Miao, Uwe Kleine-König,
Masahiro Yamada, Marek Szyprowski, Chris Brandt, Linux ARM,
Linux-Renesas, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <CAMuHMdU5DG06G4H=+PH+OONMT_9oE==KS=wP+bLgY9xVCez6Ww@mail.gmail.com>
On Tue, 19 May 2020 at 13:21, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Russell,
>
> CC devicetree
>
> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> > > > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > > > Currently, the start address of physical memory is obtained by masking
> > > > > the program counter with a fixed mask of 0xf8000000. This mask value
> > > > > was chosen as a balance between the requirements of different platforms.
> > > > > However, this does require that the start address of physical memory is
> > > > > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > > > > requirement is not fulfilled.
> > > > >
> > > > > Fix this limitation by obtaining the start address from the DTB instead,
> > > > > if available (either explicitly passed, or appended to the kernel).
> > > > > Fall back to the traditional method when needed.
> > > > >
> > > > > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > > > > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > > > > i.e. not at a multiple of 128 MiB.
> > > > >
> > > > > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > > > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> > > > > ---
> > > >
> > > > [...]
> > > >
> > > > Apparently reading physical memory layout from DTB breaks crashdump
> > > > kernels. A crashdump kernel is loaded into a region of memory, that is
> > > > reserved in the original (i.e. to be crashed) kernel. The reserved
> > > > region is large enough for the crashdump kernel to run completely inside
> > > > it and don't modify anything outside it, just read and dump the remains
> > > > of the crashed kernel. Using the information from DTB makes the
> > > > decompressor place the kernel outside of the dedicated region.
> > > >
> > > > The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> > > > 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> > > > it is decompressed to 0x00008000 (see r4 reported before jumping from
> > > > within __enter_kernel). If I were to suggest something, there need to be
> > > > one more bit of information passed in the DTB telling the decompressor
> > > > to use the old masking technique to determain kernel address. It would
> > > > be set in the DTB loaded along with the crashdump kernel.
> > >
> > > Shouldn't the DTB passed to the crashkernel describe which region of
> > > memory is to be used instead?
> >
> > Definitely not. The crashkernel needs to know where the RAM in the
> > machine is, so that it can create a coredump of the crashed kernel.
>
> So the DTB should describe both ;-)
>
> > > Describing "to use the old masking technique" sounds a bit hackish to me.
> > > I guess it cannot just restrict the /memory node to the reserved region,
> > > as the crashkernel needs to be able to dump the remains of the crashed
> > > kernel, which lie outside this region.
> >
> > Correct.
> >
> > > However, something under /chosen should work.
> >
> > Yet another sticky plaster...
>
> IMHO the old masking technique is the hacky solution covered by
> plasters.
>
I think debating which solution is the hacky one will not get us anywhere.
The simple reality is that the existing solution works fine for
existing platforms, and so any changes in the logic will have to be
opt-in in one way or the other.
Since U-boot supports EFI boot these days, one potential option is to
rely on that. I have some changes implementing this that go on top of
this patch, but they don't actually rely on it - it was just to
prevent lexical conflicts.
The only remaining options imo are a kernel command line option, or a
DT property that tells the decompressor to look at the memory nodes.
But using the DT memory nodes on all platforms like this patch does is
obviously just too risky.
On another note, I do think the usable-memory-region property should
be implemented for ARM as well - relying on this rounding to ensure
that the decompressor does the right thing is too fragile.
^ permalink raw reply
* Re: [PATCH v4 2/7] dt-bindings: mdf: ti,j721e-system-controller.yaml: Add J721e
From: Roger Quadros @ 2020-05-19 13:51 UTC (permalink / raw)
To: t-kristo, robh; +Cc: kishon, nm, nsekhar, vigneshr, devicetree, linux-kernel
In-Reply-To: <20200508082937.14171-3-rogerq@ti.com>
Add DT binding schema for J721e system controller.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Changelog:
v4
-address comments.
.../mfd/ti,j721e-system-controller.yaml | 76 +++++++++++++++++++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
new file mode 100644
index 000000000000..cb28dc480c4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,j721e-system-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI J721e System Controller Registers R/W Device Tree Bindings
+
+description: |
+ This represents the Control Module registers (CTRL_MMR0) on the SoC.
+ System controller node represents a register region containing a set
+ of miscellaneous registers. The registers are not cohesive enough to
+ represent as any specific type of device. The typical use-case is
+ for some other node's driver, or platform-specific code, to acquire
+ a reference to the syscon node (e.g. by phandle, node path, or
+ search using a specific compatible value), interrogate the node (or
+ associated OS driver) to determine the location of the registers,
+ and access the registers directly.
+
+maintainers:
+ - Kishon Vijay Abraham I <kishon@ti.com>
+ - Roger Quadros <rogerq@ti.com
+
+properties:
+ compatible:
+ anyOf:
+ - items:
+ - enum:
+ - ti,j721e-system-controller
+ - const: syscon
+ - const: simple-mfd
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges:
+ description:
+ Should translate from local addresses to bus addresses.
+
+# Optional children
+
+ "^serdes-ln-ctrl@[0-9a-f]+$":
+ type: object
+ description: |
+ This is the SERDES lane control mux. It should follow the bindings
+ specified in
+ Documentation/devicetree/bindings/mux/reg-mux.txt
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ scm_conf: scm-conf@100000 {
+ compatible = "ti,j721e-system-controller", "syscon", "simple-mfd";
+ reg = <0x00100000 0x1c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ serdes_ln_ctrl: serdes-ln-ctrl@4080 {
+ compatible = "mmio-mux";
+ reg = <0x00004080 0x50>;
+ };
+ };
+...
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* Re: [PATCH] dt-bindings: spi: ti_qspi.txt: fix unit address
From: Mark Brown @ 2020-05-19 13:40 UTC (permalink / raw)
To: Kangmin Park; +Cc: linux-spi, devicetree, linux-kernel, Rob Herring
In-Reply-To: <1589873541-5587-1-git-send-email-l4stpr0gr4m@gmail.com>
On Tue, 19 May 2020 16:32:21 +0900, Kangmin Park wrote:
> Fix unit address to match the first address specified in the reg
> property of the node in example.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-5.8
Thanks!
[1/1] spi: ti_qspi: fix unit address
commit: 73da2352075adb24868229f9463736a5dd331b95
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
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: Add renesas,em-gio bindings
From: Niklas Söderlund @ 2020-05-19 13:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring, Magnus Damm,
devicetree, linux-gpio, linux-renesas-soc
In-Reply-To: <20200519081157.29095-1-geert+renesas@glider.be>
Hi Geert,
Thanks for your patch.
On 2020-05-19 10:11:57 +0200, Geert Uytterhoeven wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile General
> Purpose I/O Interface.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> .../bindings/gpio/renesas,em-gio.yaml | 70 +++++++++++++++++++
> 1 file changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml b/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
> new file mode 100644
> index 0000000000000000..8bdef812c87c3771
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/renesas,em-gio.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/renesas,em-gio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas EMMA Mobile General Purpose I/O Interface
> +
> +maintainers:
> + - Magnus Damm <magnus.damm@gmail.com>
> +
> +properties:
> + compatible:
> + const: renesas,em-gio
> +
> + reg:
> + items:
> + - description: First set of contiguous registers
> + - description: Second set of contiguous registers
> +
> + interrupts:
> + items:
> + - description: Interrupt for the first set of 16 GPIO ports
> + - description: Interrupt for the second set of 16 GPIO ports
> +
> + gpio-controller: true
> +
> + '#gpio-cells':
> + const: 2
> +
> + gpio-ranges:
> + maxItems: 1
> +
> + ngpios:
> + minimum: 1
> + maximum: 32
> +
> + interrupt-controller: true
> +
> + '#interrupt-cells':
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - gpio-controller
> + - '#gpio-cells'
> + - gpio-ranges
> + - ngpios
> + - interrupt-controller
> + - '#interrupt-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + gpio0: gpio@e0050000 {
> + compatible = "renesas,em-gio";
> + reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
> + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&pfc 0 0 32>;
> + ngpios = <32>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> --
> 2.17.1
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH] ASoC: fsi: Add missing properties to DT bindings
From: Geert Uytterhoeven @ 2020-05-19 13:33 UTC (permalink / raw)
To: Mark Brown
Cc: Kuninori Morimoto, Liam Girdwood, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
ALSA Development Mailing List
In-Reply-To: <20200519124714.GA45550@sirena.org.uk>
Hi Mark,
On Tue, May 19, 2020 at 2:47 PM Mark Brown <broonie@kernel.org> wrote:
> On Tue, May 19, 2020 at 09:58:58AM +0200, Geert Uytterhoeven wrote:
> > make dtbs_check:
> >
> > arch/arm/boot/dts/r8a7740-armadillo800eva.dt.yaml: sound@fe1f0000: '#sound-dai-cells', 'clocks', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> This doesn't apply against current code, please check and resend.
It indeed doesn't apply to your sound/for-next branch.
It does apply to robh/for-next, which has commit 9f60a65bc5e6cd88
("dt-bindings: Clean-up schema indentation formatting"), so I guess
Rob will have to take it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: timer: Add renesas,em-sti bindings
From: Niklas Söderlund @ 2020-05-19 13:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Magnus Damm,
devicetree, linux-renesas-soc, linux-kernel
In-Reply-To: <20200519081101.28973-1-geert+renesas@glider.be>
Hi Geert,
Thanks for your work.
On 2020-05-19 10:11:01 +0200, Geert Uytterhoeven wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile System Timer.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> .../bindings/timer/renesas,em-sti.yaml | 46 +++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
> new file mode 100644
> index 0000000000000000..233d74d5402cf734
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/timer/renesas,em-sti.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas EMMA Mobile System Timer
> +
> +maintainers:
> + - Magnus Damm <magnus.damm@gmail.com>
> +
> +properties:
> + compatible:
> + const: renesas,em-sti
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: sclk
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + timer@e0180000 {
> + compatible = "renesas,em-sti";
> + reg = <0xe0180000 0x54>;
> + interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&sti_sclk>;
> + clock-names = "sclk";
> + };
> --
> 2.17.1
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v3 4/4] iio: magnetometer: ak8975: Add gpio reset support
From: Stephan Gerhold @ 2020-05-19 13:25 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Allison Randal
In-Reply-To: <20200519124402.26076-5-jonathan.albrieux@gmail.com>
On Tue, May 19, 2020 at 02:43:54PM +0200, Jonathan Albrieux wrote:
> According to AK09911 datasheet, if reset gpio is provided then
> deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am while() checking for device identity for AK09911 chip.
>
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheed says that, if not used, reset pin should be connected
Another minor typo: datasheed -> datasheet
In any case, FWIW:
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
> to VID. This patch emulates this situation.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> drivers/iio/magnetometer/ak8975.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> index fd368455cd7b..a23422aad97d 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -358,6 +358,7 @@ struct ak8975_data {
> u8 asa[3];
> long raw_to_gauss[3];
> struct gpio_desc *eoc_gpiod;
> + struct gpio_desc *reset_gpiod;
> int eoc_irq;
> wait_queue_head_t data_ready_queue;
> unsigned long flags;
> @@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
> "Failed to enable specified Vid supply\n");
> return ret;
> }
> +
> + gpiod_set_value_cansleep(data->reset_gpiod, 0);
> +
> /*
> * According to the datasheet the power supply rise time is 200us
> * and the minimum wait time before mode setting is 100us, in
> @@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
> /* Disable attached power regulator if any. */
> static void ak8975_power_off(const struct ak8975_data *data)
> {
> + gpiod_set_value_cansleep(data->reset_gpiod, 1);
> +
> regulator_disable(data->vid);
> regulator_disable(data->vdd);
> }
> @@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
> struct ak8975_data *data;
> struct iio_dev *indio_dev;
> struct gpio_desc *eoc_gpiod;
> + struct gpio_desc *reset_gpiod;
> const void *match;
> unsigned int i;
> int err;
> @@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
> if (eoc_gpiod)
> gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
>
> + /*
> + * According to AK09911 datasheet, if reset GPIO is provided then
> + * deassert reset on ak8975_power_on() and assert reset on
> + * ak8975_power_off().
> + */
> + reset_gpiod = devm_gpiod_get_optional(&client->dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(reset_gpiod))
> + return PTR_ERR(reset_gpiod);
> +
> /* Register with IIO */
> indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> if (indio_dev == NULL)
> @@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
>
> data->client = client;
> data->eoc_gpiod = eoc_gpiod;
> + data->reset_gpiod = reset_gpiod;
> data->eoc_irq = 0;
>
> err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH v3 2/4] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Stephan Gerhold @ 2020-05-19 13:23 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519124402.26076-3-jonathan.albrieux@gmail.com>
On Tue, May 19, 2020 at 02:43:52PM +0200, Jonathan Albrieux wrote:
> Add reset-gpio support.
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am() while checking for device identity for AK09911 chip.
>
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheed says that, if not used, reset pin should be connected
datasheed -> datasheet
> to VID. This patch emulates this situation.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> .../devicetree/bindings/iio/magnetometer/ak8975.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> index 86e3efa693a8..a82c0ff5d098 100644
> --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> @@ -37,6 +37,9 @@ properties:
> mount-matrix:
> description: an optional 3x3 mounting rotation matrix
>
> + reset-gpio:
> + description: an optional pin needed for AK09911 to set the reset state
Maybe add a comment that this should be "usually active low".
> +
> required:
> - compatible
> - reg
> @@ -53,6 +56,7 @@ examples:
> reg = <0x0c>;
> gpios = <&gpj0 7 0>;
> vdd-supply = <&ldo_3v3_gnss>;
> + reset-gpio = <&msmgpio 111 1>;
Same here, reset-gpio = <&msmgpio 111 GPIO_ACTIVE_LOW>,
would be more clear.
> mount-matrix = "-0.984807753012208", /* x0 */
> "0", /* y0 */
> "-0.173648177666930", /* z0 */
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH] dt-bindings: serial: Add renesas,em-uart bindings
From: Niklas Söderlund @ 2020-05-19 13:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Rob Herring, Magnus Damm, linux-serial,
devicetree, linux-renesas-soc
In-Reply-To: <20200519080945.28798-1-geert+renesas@glider.be>
Hi Geert,
Thanks for your work.
On 2020-05-19 10:09:45 +0200, Geert Uytterhoeven wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile UART
> Interface.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> .../bindings/serial/renesas,em-uart.yaml | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
>
> diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
> new file mode 100644
> index 0000000000000000..82aefdb0d45e5f1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/serial/renesas,em-uart.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Renesas EMMA Mobile UART Interface
> +
> +maintainers:
> + - Magnus Damm <magnus.damm@gmail.com>
> +
> +allOf:
> + - $ref: serial.yaml#
> +
> +properties:
> + compatible:
> + const: renesas,em-uart
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: sclk
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + uart0: serial@e1020000 {
> + compatible = "renesas,em-uart";
> + reg = <0xe1020000 0x38>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&usia_u0_sclk>;
> + clock-names = "sclk";
> + };
> --
> 2.17.1
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: iio: magnetometer: ak8975: convert txt format to yaml
From: Stephan Gerhold @ 2020-05-19 13:22 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200519124402.26076-2-jonathan.albrieux@gmail.com>
On Tue, May 19, 2020 at 02:43:51PM +0200, Jonathan Albrieux wrote:
> Converts documentation from txt format to yaml.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> .../bindings/iio/magnetometer/ak8975.txt | 30 ---------
> .../bindings/iio/magnetometer/ak8975.yaml | 66 +++++++++++++++++++
> 2 files changed, 66 insertions(+), 30 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> deleted file mode 100644
> index aa67ceb0d4e0..000000000000
> --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -* AsahiKASEI AK8975 magnetometer sensor
> -
> -Required properties:
> -
> - - compatible : should be "asahi-kasei,ak8975"
> - - reg : the I2C address of the magnetometer
> -
> -Optional properties:
> -
> - - gpios : should be device tree identifier of the magnetometer DRDY pin
> - - vdd-supply: an optional regulator that needs to be on to provide VDD
> - - mount-matrix: an optional 3x3 mounting rotation matrix
> -
> -Example:
> -
> -ak8975@c {
> - compatible = "asahi-kasei,ak8975";
> - reg = <0x0c>;
> - gpios = <&gpj0 7 0>;
> - vdd-supply = <&ldo_3v3_gnss>;
> - mount-matrix = "-0.984807753012208", /* x0 */
> - "0", /* y0 */
> - "-0.173648177666930", /* z0 */
> - "0", /* x1 */
> - "-1", /* y1 */
> - "0", /* z1 */
> - "-0.173648177666930", /* x2 */
> - "0", /* y2 */
> - "0.984807753012208"; /* z2 */
> -};
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> new file mode 100644
> index 000000000000..86e3efa693a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AsahiKASEI AK8975 magnetometer sensor
> +
> +maintainers:
> + - can't find a mantainer, author is Laxman Dewangan <ldewangan@nvidia.com>
Should probably add someone here, although I'm not sure who either.
> +
> +properties:
> + compatible:
> + enum:
> + - "asahi-kasei,ak8975"
> + - "ak8975"
> + - "asahi-kasei,ak8963"
> + - "ak8963"
> + - "asahi-kasei,ak09911"
> + - "ak09911"
> + - "asahi-kasei,ak09912"
> + - "ak09912"
> +
I wonder if the ones without vendor prefix (asahi-kasei,) should be
marked as deprecated somehow?
Looking at some other schemas I see either a "# deprecated" comment, or:
properties:
compatible:
oneOf:
- const: asahi-kasei,ak8975
- const: asahi-kasei,ak8963
- const: asahi-kasei,ak09911
- const: asahi-kasei,ak09912
- const: ak8975
deprecated: true
- const: ak8963
deprecated: true
- const: ak09911
deprecated: true
- const: ak09912
deprecated: true
(e.g. in Documentation/devicetree/bindings/sound/samsung,odroid.yaml)
I guess this one is preferred since it allows parsing those
compatibles as deprecated?
> + reg:
> + maxItems: 1
> + description: the I2C address of the magnetometer
> +
> + gpios:
> + description: should be device tree identifier of the magnetometer DRDY pin
> +
> + vdd-supply:
> + maxItems: 1
> + description: |
> + an optional regulator that needs to be on to provide VDD power to
> + the sensor.
> +
> + mount-matrix:
> + description: an optional 3x3 mounting rotation matrix
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + i2c@78b7000 {
> + reg = <0x78b6000 0x600>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ak8975@c {
Per device tree specification this should preferably use a generic name
describing the function of the device, i.e. magnetometer@c.
> + compatible = "asahi-kasei,ak8975";
> + reg = <0x0c>;
> + gpios = <&gpj0 7 0>;
I think using the dt-bindings constants for the GPIO flags is preferred
now, i.e. gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>.
> + vdd-supply = <&ldo_3v3_gnss>;
> + mount-matrix = "-0.984807753012208", /* x0 */
> + "0", /* y0 */
> + "-0.173648177666930", /* z0 */
> + "0", /* x1 */
> + "-1", /* y1 */
> + "0", /* z1 */
> + "-0.173648177666930", /* x2 */
> + "0", /* y2 */
> + "0.984807753012208"; /* z2 */
> + };
> + };
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Russell King - ARM Linux admin @ 2020-05-19 13:12 UTC (permalink / raw)
To: Lukasz Stelmach
Cc: Geert Uytterhoeven, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <dleftjzha43x8q.fsf%l.stelmach@samsung.com>
On Tue, May 19, 2020 at 02:49:57PM +0200, Lukasz Stelmach wrote:
> It was <2020-05-19 wto 13:27>, when Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
> >> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
> >>> On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> >>>> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> >>>> <linux@armlinux.org.uk> wrote:
> >>>>> On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> >>>>>> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
> >>>>>>> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> >>>>>>>> Currently, the start address of physical memory is obtained by masking
> >>>>>>>> the program counter with a fixed mask of 0xf8000000. This mask value
> >>>>>>>> was chosen as a balance between the requirements of different platforms.
> >>>>>>>> However, this does require that the start address of physical memory is
> >>>>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
> >>>>>>>> requirement is not fulfilled.
> >>>>>>>>
> >>>>>>>> Fix this limitation by obtaining the start address from the DTB instead,
> >>>>>>>> if available (either explicitly passed, or appended to the kernel).
> >>>>>>>> Fall back to the traditional method when needed.
> [...]
> >>>>>>> Apparently reading physical memory layout from DTB breaks crashdump
> >>>>>>> kernels. A crashdump kernel is loaded into a region of memory, that is
> >>>>>>> reserved in the original (i.e. to be crashed) kernel. The reserved
> >>>>>>> region is large enough for the crashdump kernel to run completely inside
> >>>>>>> it and don't modify anything outside it, just read and dump the remains
> >>>>>>> of the crashed kernel. Using the information from DTB makes the
> >>>>>>> decompressor place the kernel outside of the dedicated region.
> >>>>>>>
> >>>>>>> The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> >>>>>>> 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> >>>>>>> it is decompressed to 0x00008000 (see r4 reported before jumping from
> >>>>>>> within __enter_kernel). If I were to suggest something, there need to be
> >>>>>>> one more bit of information passed in the DTB telling the decompressor
> >>>>>>> to use the old masking technique to determain kernel address. It would
> >>>>>>> be set in the DTB loaded along with the crashdump kernel.
> [...]
> >>>>>> Describing "to use the old masking technique" sounds a bit hackish to me.
> >>>>>> I guess it cannot just restrict the /memory node to the reserved region,
> >>>>>> as the crashkernel needs to be able to dump the remains of the crashed
> >>>>>> kernel, which lie outside this region.
> >>>>>
> >>>>> Correct.
> >>>>>
> >>>>>> However, something under /chosen should work.
> >>>>>
> >>>>> Yet another sticky plaster...
> >>>>
> >>>> IMHO the old masking technique is the hacky solution covered by
> >>>> plasters.
> >>>
> >>> One line of code is not "covered by plasters". There are no plasters.
> >>> It's a solution that works for 99.99% of people, unlike your approach
> >>> that has had a stream of issues over the last four months, and has
> >>> required many reworks of the code to fix each one. That in itself
> >>> speaks volumes about the suitability of the approach.
> >>
> >> As I have been working with kexec code (patches soon) I would like to
> >> defend the DT approach a bit. It allows to avoid zImage relocation when
> >> a decompressed kernel is larger than ~128MiB. In such case zImage isn't
> >> small either and moving it around takes some time.
> >
> > ... which is something that has been supported for a very long time,
> > before the days of DT.
>
> How? If a decompressed kernel requires >128M and a bootloader would like
> to put a zImage high enough to *avoid* copying it once again, then the
> decompressor can't see any memory below the 128M window it starts in and
> can't decompress the kernel there.
Do you have such a large kernel? It would be rather inefficient as
branch instructions could not be used; every function call would have
to be indirect. The maximum is +/- 32MB for a branch.
> If we do not care about copying
> zImage, then, indeed, everything works fine as it is today. You are
> most probably right 99% doesn't require 128M kernel, but the case is
> IMHO obvious enough, that it should be adressed somehow.
If I have a kernel in excess of 4GB... "it should be addressed somehow"!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
^ permalink raw reply
* Re: [PATCH v3 4/4] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-19 13:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-kernel, ~postmarketos/upstreaming,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Allison Randal
In-Reply-To: <20200519125713.GI1634618@smile.fi.intel.com>
On Tue, May 19, 2020 at 03:57:13PM +0300, Andy Shevchenko wrote:
> On Tue, May 19, 2020 at 02:43:54PM +0200, Jonathan Albrieux wrote:
> > According to AK09911 datasheet, if reset gpio is provided then
> > deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
> >
> > Without reset's deassertion during ak8975_power_on(), driver's probe fails
> > on ak8975_who_i_am while() checking for device identity for AK09911 chip.
>
> Wrong position of (), but hold on, this is so minor, no need to send a new
> version because of this.
>
Ops, if this represents a problem I can fix it, there's absolutely no problem!
> > AK09911 has an active low reset gpio to handle register's reset.
> > AK09911 datasheed says that, if not used, reset pin should be connected
> > to VID. This patch emulates this situation.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> > ---
> > drivers/iio/magnetometer/ak8975.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> > index fd368455cd7b..a23422aad97d 100644
> > --- a/drivers/iio/magnetometer/ak8975.c
> > +++ b/drivers/iio/magnetometer/ak8975.c
> > @@ -358,6 +358,7 @@ struct ak8975_data {
> > u8 asa[3];
> > long raw_to_gauss[3];
> > struct gpio_desc *eoc_gpiod;
> > + struct gpio_desc *reset_gpiod;
> > int eoc_irq;
> > wait_queue_head_t data_ready_queue;
> > unsigned long flags;
> > @@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
> > "Failed to enable specified Vid supply\n");
> > return ret;
> > }
> > +
> > + gpiod_set_value_cansleep(data->reset_gpiod, 0);
> > +
> > /*
> > * According to the datasheet the power supply rise time is 200us
> > * and the minimum wait time before mode setting is 100us, in
> > @@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
> > /* Disable attached power regulator if any. */
> > static void ak8975_power_off(const struct ak8975_data *data)
> > {
> > + gpiod_set_value_cansleep(data->reset_gpiod, 1);
> > +
> > regulator_disable(data->vid);
> > regulator_disable(data->vdd);
> > }
> > @@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
> > struct ak8975_data *data;
> > struct iio_dev *indio_dev;
> > struct gpio_desc *eoc_gpiod;
> > + struct gpio_desc *reset_gpiod;
> > const void *match;
> > unsigned int i;
> > int err;
> > @@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
> > if (eoc_gpiod)
> > gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
> >
> > + /*
> > + * According to AK09911 datasheet, if reset GPIO is provided then
> > + * deassert reset on ak8975_power_on() and assert reset on
> > + * ak8975_power_off().
> > + */
> > + reset_gpiod = devm_gpiod_get_optional(&client->dev,
> > + "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(reset_gpiod))
> > + return PTR_ERR(reset_gpiod);
> > +
> > /* Register with IIO */
> > indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> > if (indio_dev == NULL)
> > @@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
> >
> > data->client = client;
> > data->eoc_gpiod = eoc_gpiod;
> > + data->reset_gpiod = reset_gpiod;
> > data->eoc_irq = 0;
> >
> > err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
> > --
> > 2.17.1
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Best regards,
Jonathan Albrieux
^ permalink raw reply
* Re: [PATCH v3 4/4] iio: magnetometer: ak8975: Add gpio reset support
From: Andy Shevchenko @ 2020-05-19 12:57 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Allison Randal
In-Reply-To: <20200519124402.26076-5-jonathan.albrieux@gmail.com>
On Tue, May 19, 2020 at 02:43:54PM +0200, Jonathan Albrieux wrote:
> According to AK09911 datasheet, if reset gpio is provided then
> deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am while() checking for device identity for AK09911 chip.
Wrong position of (), but hold on, this is so minor, no need to send a new
version because of this.
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheed says that, if not used, reset pin should be connected
> to VID. This patch emulates this situation.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> drivers/iio/magnetometer/ak8975.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> index fd368455cd7b..a23422aad97d 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -358,6 +358,7 @@ struct ak8975_data {
> u8 asa[3];
> long raw_to_gauss[3];
> struct gpio_desc *eoc_gpiod;
> + struct gpio_desc *reset_gpiod;
> int eoc_irq;
> wait_queue_head_t data_ready_queue;
> unsigned long flags;
> @@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
> "Failed to enable specified Vid supply\n");
> return ret;
> }
> +
> + gpiod_set_value_cansleep(data->reset_gpiod, 0);
> +
> /*
> * According to the datasheet the power supply rise time is 200us
> * and the minimum wait time before mode setting is 100us, in
> @@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
> /* Disable attached power regulator if any. */
> static void ak8975_power_off(const struct ak8975_data *data)
> {
> + gpiod_set_value_cansleep(data->reset_gpiod, 1);
> +
> regulator_disable(data->vid);
> regulator_disable(data->vdd);
> }
> @@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
> struct ak8975_data *data;
> struct iio_dev *indio_dev;
> struct gpio_desc *eoc_gpiod;
> + struct gpio_desc *reset_gpiod;
> const void *match;
> unsigned int i;
> int err;
> @@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
> if (eoc_gpiod)
> gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
>
> + /*
> + * According to AK09911 datasheet, if reset GPIO is provided then
> + * deassert reset on ak8975_power_on() and assert reset on
> + * ak8975_power_off().
> + */
> + reset_gpiod = devm_gpiod_get_optional(&client->dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(reset_gpiod))
> + return PTR_ERR(reset_gpiod);
> +
> /* Register with IIO */
> indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> if (indio_dev == NULL)
> @@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
>
> data->client = client;
> data->eoc_gpiod = eoc_gpiod;
> + data->reset_gpiod = reset_gpiod;
> data->eoc_irq = 0;
>
> err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 3/4] iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
From: Andy Shevchenko @ 2020-05-19 12:55 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, ~postmarketos/upstreaming,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron
In-Reply-To: <20200519124402.26076-4-jonathan.albrieux@gmail.com>
On Tue, May 19, 2020 at 02:43:53PM +0200, Jonathan Albrieux wrote:
> Minor comment style edits.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> drivers/iio/magnetometer/ak8975.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
> index 3c881541ae72..fd368455cd7b 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -385,9 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
> return ret;
> }
> /*
> - * According to the datasheet the power supply rise time i 200us
> + * According to the datasheet the power supply rise time is 200us
> * and the minimum wait time before mode setting is 100us, in
> - * total 300 us. Add some margin and say minimum 500us here.
> + * total 300us. Add some margin and say minimum 500us here.
> */
> usleep_range(500, 1000);
> return 0;
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Lukasz Stelmach @ 2020-05-19 12:49 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Geert Uytterhoeven, Dmitry Osipenko, Nicolas Pitre, Arnd Bergmann,
Eric Miao, Uwe Kleine-König, Masahiro Yamada, Ard Biesheuvel,
Marek Szyprowski, Chris Brandt, Linux ARM, Linux-Renesas,
Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Grant Likely
In-Reply-To: <20200519122706.GC1551@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]
It was <2020-05-19 wto 13:27>, when Russell King - ARM Linux admin wrote:
> On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
>> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
>>> On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
>>>> <linux@armlinux.org.uk> wrote:
>>>>> On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
>>>>>> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach <l.stelmach@samsung.com> wrote:
>>>>>>> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
>>>>>>>> Currently, the start address of physical memory is obtained by masking
>>>>>>>> the program counter with a fixed mask of 0xf8000000. This mask value
>>>>>>>> was chosen as a balance between the requirements of different platforms.
>>>>>>>> However, this does require that the start address of physical memory is
>>>>>>>> a multiple of 128 MiB, precluding booting Linux on platforms where this
>>>>>>>> requirement is not fulfilled.
>>>>>>>>
>>>>>>>> Fix this limitation by obtaining the start address from the DTB instead,
>>>>>>>> if available (either explicitly passed, or appended to the kernel).
>>>>>>>> Fall back to the traditional method when needed.
[...]
>>>>>>> Apparently reading physical memory layout from DTB breaks crashdump
>>>>>>> kernels. A crashdump kernel is loaded into a region of memory, that is
>>>>>>> reserved in the original (i.e. to be crashed) kernel. The reserved
>>>>>>> region is large enough for the crashdump kernel to run completely inside
>>>>>>> it and don't modify anything outside it, just read and dump the remains
>>>>>>> of the crashed kernel. Using the information from DTB makes the
>>>>>>> decompressor place the kernel outside of the dedicated region.
>>>>>>>
>>>>>>> The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
>>>>>>> 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
>>>>>>> it is decompressed to 0x00008000 (see r4 reported before jumping from
>>>>>>> within __enter_kernel). If I were to suggest something, there need to be
>>>>>>> one more bit of information passed in the DTB telling the decompressor
>>>>>>> to use the old masking technique to determain kernel address. It would
>>>>>>> be set in the DTB loaded along with the crashdump kernel.
[...]
>>>>>> Describing "to use the old masking technique" sounds a bit hackish to me.
>>>>>> I guess it cannot just restrict the /memory node to the reserved region,
>>>>>> as the crashkernel needs to be able to dump the remains of the crashed
>>>>>> kernel, which lie outside this region.
>>>>>
>>>>> Correct.
>>>>>
>>>>>> However, something under /chosen should work.
>>>>>
>>>>> Yet another sticky plaster...
>>>>
>>>> IMHO the old masking technique is the hacky solution covered by
>>>> plasters.
>>>
>>> One line of code is not "covered by plasters". There are no plasters.
>>> It's a solution that works for 99.99% of people, unlike your approach
>>> that has had a stream of issues over the last four months, and has
>>> required many reworks of the code to fix each one. That in itself
>>> speaks volumes about the suitability of the approach.
>>
>> As I have been working with kexec code (patches soon) I would like to
>> defend the DT approach a bit. It allows to avoid zImage relocation when
>> a decompressed kernel is larger than ~128MiB. In such case zImage isn't
>> small either and moving it around takes some time.
>
> ... which is something that has been supported for a very long time,
> before the days of DT.
How? If a decompressed kernel requires >128M and a bootloader would like
to put a zImage high enough to *avoid* copying it once again, then the
decompressor can't see any memory below the 128M window it starts in and
can't decompress the kernel there. If we do not care about copying
zImage, then, indeed, everything works fine as it is today. You are
most probably right 99% doesn't require 128M kernel, but the case is
IMHO obvious enough, that it should be adressed somehow.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox