* Re: [PATCH v2 7/9] dt-bindings: spi: Convert spi-pxa2xx to json-schema
From: Rob Herring @ 2020-05-28 23:03 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Thomas Gleixner, Alessandro Zummo, Jason Cooper, Ulf Hansson,
Marc Zyngier, devicetree, Bartosz Golaszewski, Alexandre Belloni,
Daniel Lezcano, Rob Herring, linux-kernel, Linus Walleij
In-Reply-To: <20200521091356.2211020-8-lkundrak@v3.sk>
On Thu, 21 May 2020 11:13:54 +0200, Lubomir Rintel wrote:
> A straightforward conversion of the the spi-pxa2xx binding to DT schema
> format using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Drop #address-cells and #size-cells
> - s/GPL-2.0-or-later/GPL-2.0-only/
>
> .../bindings/spi/marvell,mmp2-ssp.yaml | 56 +++++++++++++++++++
> .../devicetree/bindings/spi/spi-pxa2xx.txt | 27 ---------
> 2 files changed, 56 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-pxa2xx.txt
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 5/9] dt-bindings: media: Convert marvell,mmp2-ccic to json-schema
From: Rob Herring @ 2020-05-28 22:59 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Alexandre Belloni, Alessandro Zummo, Marc Zyngier, linux-kernel,
Ulf Hansson, Bartosz Golaszewski, Linus Walleij, Daniel Lezcano,
Jason Cooper, Thomas Gleixner, Rob Herring, devicetree
In-Reply-To: <20200521091356.2211020-6-lkundrak@v3.sk>
On Thu, 21 May 2020 11:13:52 +0200, Lubomir Rintel wrote:
> Convert the marvell,mmp2-ccic binding to DT schema format using
> json-schema. While at that this drops the "func" and "phy" clocks.
>
> The driver consumes clocks with those names, but it's not clear
> what are they for and they are not used in DT systems. "phy" is
> probably a clock for the sensor and it would belong in the sensor
> node.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Fix indentation
> - Drop clocks other than "axi"
> - s/GPL-2.0-or-later/GPL-2.0-only/
>
> .../bindings/media/marvell,mmp2-ccic.txt | 50 ----------
> .../bindings/media/marvell,mmp2-ccic.yaml | 97 +++++++++++++++++++
> 2 files changed, 97 insertions(+), 50 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt
> create mode 100644 Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: i2c: Convert i2c-pxa to json-schema
From: Rob Herring @ 2020-05-28 22:57 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Alessandro Zummo, Alexandre Belloni, Bartosz Golaszewski,
Daniel Lezcano, Jason Cooper, Linus Walleij, Marc Zyngier,
Thomas Gleixner, Ulf Hansson, devicetree, linux-kernel
In-Reply-To: <20200521091356.2211020-4-lkundrak@v3.sk>
On Thu, May 21, 2020 at 11:13:50AM +0200, Lubomir Rintel wrote:
> A conversion of the i2c-pxa binding to DT schema format using json-schema.
>
> This also cleans ups some errors in the binding: The compatible string
> description suggested that "mmp" in "mrvl,mmp-twsi" is to be substituted
> with a processor model, which wouldn't be a right thing to do and indeed
> nobody seems to have been doing that. There also was "Recommended
> properties" section that included optional as well as mandatory
> properties. Missing mandatory properties were added to the example.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - Add default GPL-2.0-only license tag
> - Fill in maintainers from MAINTAINERS file
>
> .../devicetree/bindings/i2c/i2c-pxa.txt | 31 --------
> .../devicetree/bindings/i2c/i2c-pxa.yaml | 72 +++++++++++++++++++
> 2 files changed, 72 insertions(+), 31 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-pxa.yaml
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> deleted file mode 100644
> index c30783c0eca0..000000000000
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -* Marvell MMP I2C controller
> -
> -Required properties :
> -
> - - reg : Offset and length of the register set for the device
> - - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a
> - compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
> - For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
> - as shown in the example below.
> - For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
> -
> -Recommended properties :
> -
> - - interrupts : the interrupt number
> - - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
> - status register of i2c controller instead.
> - - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
> -
> -Examples:
> - twsi1: i2c@d4011000 {
> - compatible = "mrvl,mmp-twsi";
> - reg = <0xd4011000 0x1000>;
> - interrupts = <7>;
> - mrvl,i2c-fast-mode;
> - };
> -
> - twsi2: i2c@d4025000 {
> - compatible = "mrvl,mmp-twsi";
> - reg = <0xd4025000 0x1000>;
> - interrupts = <58>;
> - };
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml
> new file mode 100644
> index 000000000000..19c81972243d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i2c/i2c-pxa.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell MMP I2C controller bindings
> +
> +maintainers:
> + - Rob Herring <robh+dt@kernel.org>
> +
> +allOf:
> + - $ref: /schemas/i2c/i2c-controller.yaml#
> + - if:
> + not:
> + required:
> + - mrvl,i2c-polling
> + then:
> + required:
> + - interrupts
> +
> +properties:
> + compatible:
> + enum:
> + - mrvl,mmp-twsi
> + - mrvl,pxa-i2c
> + - marvell,armada-3700-i2c
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + minItems: 1
> +
> + resets:
> + minItems: 1
> +
> + mrvl,i2c-polling:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + Disable interrupt of i2c controller. Polling status register of i2c
> + controller instead.
> +
> + mrvl,i2c-fast-mode:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: Enable fast mode of i2c controller.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - '#address-cells'
> + - '#size-cells'
Add:
unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/marvell,mmp2.h>
> + i2c@d4011000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4011000 0x1000>;
> + interrupts = <7>;
> + clocks = <&soc_clocks MMP2_CLK_TWSI1>;
> + mrvl,i2c-fast-mode;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> +...
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v2 2/2] media: cec: i2c: ch7322: Add ch7322 CEC controller driver
From: Jeff Chase @ 2020-05-28 22:55 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, mchehab, robh+dt, devicetree
In-Reply-To: <fe268ad4-1a46-b6de-54e1-c9e6731a96d3@xs4all.nl>
> > +
> > +/* This device is always enabled */
> > +static int ch7322_cec_adap_enable(struct cec_adapter *adap, bool enable)
> > +{
>
> I'd disable the interrupt here if enable is false.
Ok I can do that.
>
> There is a power down mode as well, so perhaps that's something that can be
> done here too.
>
I think I'd prefer to use power down mode in a potential follow up
patch that adds PM to the driver.
> > + return 0;
> > +}
> > +
> > +static int ch7322_cec_adap_log_addr(struct cec_adapter *adap, u8 log_addr)
> > +{
> > + struct ch7322 *ch7322 = cec_get_drvdata(adap);
> > + int ret;
> > +
> > + mutex_lock(&ch7322->mutex);
> > + ret = regmap_update_bits(ch7322->regmap, CH7322_ADDLW,
> > + CH7322_ADDLW_MASK, log_addr << 4);
> > + mutex_unlock(&ch7322->mutex);
>
> If log_addr is CEC_LOG_ADDR_INVALID, then that means that the current
> logical address configuration is to be cleared. In this case the logical
> address is set to 0xf (unregistered/broadcast). That should mean that the
> CEC device will not Ack any logical addresses, correct?
Correct.
>
> But it does receive broadcast messages and (I think) also messages from
> other logical addresses, except that those will not be Acked by this
> CEC adapter.
>
I was wrong about this before. It does not pass on messages from other LAs.
> If it still receives messages from other LAs, then that means that you can
> add the CEC_CAP_MONITOR_ALL capability. I.e., 'sudo cec-ctl -M' without
> configuring anything should see all CEC traffic.
>
> What is the default value of CH7322_ADDLW? It should start with 0xf as
> the logical address (i.e. no received messages should be Acked).
The default value is 0xf.
Thanks,
Jeff
^ permalink raw reply
* Re: [PATCH v2 1/9] dt-bindings: mmc: Convert sdhci-pxa to json-schema
From: Rob Herring @ 2020-05-28 22:54 UTC (permalink / raw)
To: Ulf Hansson
Cc: Lubomir Rintel, Alessandro Zummo, Alexandre Belloni,
Bartosz Golaszewski, Daniel Lezcano, Jason Cooper, Linus Walleij,
Marc Zyngier, Thomas Gleixner, DTML, Linux Kernel Mailing List
In-Reply-To: <CAPDyKFogpp+9d44Dgc8gXmeULj2CxoUzo4EhnLp+=_1YcvXT-g@mail.gmail.com>
On Wed, May 27, 2020 at 09:59:10AM +0200, Ulf Hansson wrote:
> On Thu, 21 May 2020 at 11:14, Lubomir Rintel <lkundrak@v3.sk> wrote:
> >
> > Convert the sdhci-pxa binding to DT schema format using json-schema.
> >
> > At the same time, fix a couple of issues with the examples discovered by
> > the validation tool -- a semicolon instead of a comma and wrong node names.
> >
> > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> Rob, are you fine with this v2? I am intending to queue it up via my
> mmc tree, unless you want to pick it?
You can take it if you drop my name from 'maintainers'. Ideally, it
shouldn't be your name either (should have called it 'owners'
instead...).
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v12 4/4] power: supply: bq25150 introduce the bq25150
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
In-Reply-To: <20200528225350.661-1-r-rivera-matos@ti.com>
Introduce the bq2515x family of chargers.
The BQ2515X family of devices are highly integrated battery management
ICs that integrate the most common functions for wearable devices
namely a charger, an output voltage rail, ADC for battery and system
monitoring, and a push-button controller.
Datasheets:
bq25150 - http://www.ti.com/lit/ds/symlink/bq25150.pdf
bq25155 - http://www.ti.com/lit/ds/symlink/bq25155.pdf
Signed-off-by: Ricardo Rivera-Matos <r-rivera-matos@ti.com>
---
drivers/power/supply/Kconfig | 13 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/bq2515x_charger.c | 1158 ++++++++++++++++++++++++
3 files changed, 1172 insertions(+)
create mode 100644 drivers/power/supply/bq2515x_charger.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index f3424fdce341..266193301e2d 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -589,6 +589,19 @@ config CHARGER_BQ24735
help
Say Y to enable support for the TI BQ24735 battery charger.
+config CHARGER_BQ2515X
+ tristate "TI BQ2515X battery charger family"
+ depends on I2C
+ depends on GPIOLIB || COMPILE_TEST
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the TI BQ2515X family of battery
+ charging integrated circuits. The BQ2515X are highly integrated
+ battery charge management ICs that integrate the most common
+ functions for wearable devices, namely a charger, an output voltage
+ rail, ADC for battery and system monitoring, and push-button
+ controller.
+
config CHARGER_BQ25890
tristate "TI BQ25890 battery charger driver"
depends on I2C
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 6c7da920ea83..8fcc175a7e22 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o
obj-$(CONFIG_CHARGER_BQ24257) += bq24257_charger.o
obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
+obj-$(CONFIG_CHARGER_BQ2515X) += bq2515x_charger.o
obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
diff --git a/drivers/power/supply/bq2515x_charger.c b/drivers/power/supply/bq2515x_charger.c
new file mode 100644
index 000000000000..f386484b5035
--- /dev/null
+++ b/drivers/power/supply/bq2515x_charger.c
@@ -0,0 +1,1158 @@
+// SPDX-License-Identifier: GPL-2.0
+// BQ2515X Battery Charger Driver
+// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/gpio/consumer.h>
+#include <linux/power_supply.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#define BQ2515X_MANUFACTURER "Texas Instruments"
+
+#define BQ2515X_STAT0 0x00
+#define BQ2515X_STAT1 0x01
+#define BQ2515X_STAT2 0x02
+#define BQ2515X_FLAG0 0x03
+#define BQ2515X_FLAG1 0x04
+#define BQ2515X_FLAG2 0x05
+#define BQ2515X_FLAG3 0x06
+#define BQ2515X_MASK0 0x07
+#define BQ2515X_MASK1 0x08
+#define BQ2515X_MASK2 0x09
+#define BQ2515X_MASK3 0x0a
+#define BQ2515X_VBAT_CTRL 0x12
+#define BQ2515X_ICHG_CTRL 0x13
+#define BQ2515X_PCHRGCTRL 0x14
+#define BQ2515X_TERMCTRL 0x15
+#define BQ2515X_BUVLO 0x16
+#define BQ2515X_CHARGERCTRL0 0x17
+#define BQ2515X_CHARGERCTRL1 0x18
+#define BQ2515X_ILIMCTRL 0x19
+#define BQ2515X_LDOCTRL 0x1d
+#define BQ2515X_MRCTRL 0x30
+#define BQ2515X_ICCTRL0 0x35
+#define BQ2515X_ICCTRL1 0x36
+#define BQ2515X_ICCTRL2 0x37
+#define BQ2515X_ADCCTRL0 0x40
+#define BQ2515X_ADCCTRL1 0x41
+#define BQ2515X_ADC_VBAT_M 0x42
+#define BQ2515X_ADC_VBAT_L 0x43
+#define BQ2515X_ADC_TS_M 0x44
+#define BQ2515X_ADC_TS_L 0x45
+#define BQ2515X_ADC_ICHG_M 0x46
+#define BQ2515X_ADC_ICHG_L 0x47
+#define BQ2515X_ADC_ADCIN_M 0x48
+#define BQ2515X_ADC_ADCIN_L 0x49
+#define BQ2515X_ADC_VIN_M 0x4a
+#define BQ2515X_ADC_VIN_L 0x4b
+#define BQ2515X_ADC_PMID_M 0x4c
+#define BQ2515X_ADC_PMID_L 0x4d
+#define BQ2515X_ADC_IIN_M 0x4e
+#define BQ2515X_ADC_IIN_L 0x4f
+#define BQ2515X_ADC_COMP1_M 0x52
+#define BQ2515X_ADC_COMP1_L 0X53
+#define BQ2515X_ADC_COMP2_M 0X54
+#define BQ2515X_ADC_COMP2_L 0x55
+#define BQ2515X_ADC_COMP3_M 0x56
+#define BQ2515X_ADC_COMP3_L 0x57
+#define BQ2515X_ADC_READ_EN 0x58
+#define BQ2515X_TS_FASTCHGCTRL 0x61
+#define BQ2515X_TS_COLD 0x62
+#define BQ2515X_TS_COOL 0x63
+#define BQ2515X_TS_WARM 0x64
+#define BQ2515X_TS_HOT 0x65
+#define BQ2515X_DEVICE_ID 0x6f
+
+#define BQ2515X_DEFAULT_ICHG_UA 10000
+#define BQ25150_DEFAULT_ILIM_UA 100000
+#define BQ25155_DEFAULT_ILIM_UA 500000
+#define BQ2515X_DEFAULT_VBAT_REG_UV 4200000
+#define BQ2515X_DEFAULT_IPRECHARGE_UA 2500
+
+#define BQ2515X_DIVISOR 65536
+#define BQ2515X_VBAT_BASE_VOLT 3600000
+#define BQ2515X_VBAT_REG_MAX 4600000
+#define BQ2515X_VBAT_REG_MIN 3600000
+#define BQ2515X_VBAT_STEP_UV 10000
+#define BQ2515X_UV_FACTOR 1000000
+#define BQ2515X_VBAT_MULTIPLIER 6
+#define BQ2515X_ICHG_DIVISOR 52429
+#define BQ2515X_ICHG_CURR_STEP_THRESH_UA 318750
+#define BQ2515X_ICHG_MIN_UA 0
+#define BQ2515X_ICHG_MAX_UA 500000
+#define BQ2515X_ICHG_RNG_1B0_UA 1250
+#define BQ2515X_ICHG_RNG_1B1_UA 2500
+#define BQ2515X_VLOWV_SEL_1B0_UV 3000000
+#define BQ2515X_VLOWV_SEL_1B1_UV 2800000
+#define BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA 18750
+#define BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA 37500
+#define BQ2515X_TWAKE2_MIN_US 1700000
+#define BQ2515X_TWAKE2_MAX_US 2300000
+
+#define BQ2515X_ILIM_150MA 0x2
+#define BQ2515X_ILIM_MASK 0x7
+#define BQ2515X_ILIM_MIN 50000
+#define BQ2515X_ILIM_MAX 600000
+#define BQ2515X_HEALTH_MASK 0xf
+#define BQ2515X_ICHGRNG_MASK 0x80
+#define BQ2515X_STAT0_MASK 0x0f
+#define BQ2515X_STAT1_MASK 0x1f
+#define BQ2515X_PRECHARGE_MASK 0x1f
+
+#define BQ2515X_TS_HOT_STAT BIT(0)
+#define BQ2515X_TS_WARM_STAT BIT(1)
+#define BQ2515X_TS_COOL_STAT BIT(2)
+#define BQ2515X_TS_COLD_STAT BIT(3)
+#define BQ2515X_SAFETY_TIMER_EXP BIT(5)
+
+#define BQ2515X_EN_VBAT_READ BIT(3)
+#define BQ2515X_EN_ICHG_READ BIT(5)
+
+#define BQ2515X_VIN_GOOD BIT(0)
+#define BQ2515X_CHRG_DONE BIT(5)
+#define BQ2515X_CV_CHRG_MODE BIT(6)
+
+#define BQ2515X_VIN_OVP_FAULT_STAT BIT(7)
+
+#define BQ2515X_WATCHDOG_DISABLE BIT(4)
+
+#define BQ2515X_ICHARGE_RANGE BIT(7)
+
+#define BQ2515X_VLOWV_SEL BIT(5)
+
+#define BQ2515X_CHARGER_DISABLE BIT(0)
+
+#define BQ2515X_HWRESET_14S_WD BIT(1)
+
+static const int bq2515x_ilim_lvl_values[] = {
+ 50000, 100000, 150000, 200000, 300000, 400000, 500000, 600000
+};
+
+/**
+ * struct bq2515x_init_data -
+ * @ilim: input current limit
+ */
+struct bq2515x_init_data {
+ int ilim;
+};
+
+enum bq2515x_id {
+ BQ25150,
+ BQ25155,
+};
+
+/**
+ * struct bq2515x_device -
+ * @mains: mains properties
+ * @battery: battery properties
+ * @regmap: register map structure
+ * @dev: device structure
+ *
+ * @reset_gpio: manual reset (MR) pin
+ * @powerdown_gpio: low power mode pin
+ * @ac_detect_gpio: power good (PG) pin
+ * @ce_gpio: charge enable (CE) pin
+ *
+ * @model_name: string value describing device model
+ * @device_id: value of device_id
+ * @mains_online: boolean value indicating power supply online
+ *
+ * @bq2515x_init_data init_data: charger initialization data structure
+ */
+struct bq2515x_device {
+ struct power_supply *mains;
+ struct power_supply *battery;
+ struct regmap *regmap;
+ struct device *dev;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *powerdown_gpio;
+ struct gpio_desc *ac_detect_gpio;
+ struct gpio_desc *ce_gpio;
+
+ char model_name[I2C_NAME_SIZE];
+ int device_id;
+ bool mains_online;
+
+ struct bq2515x_init_data init_data;
+};
+
+static struct reg_default bq25150_reg_defaults[] = {
+ {BQ2515X_FLAG0, 0x0},
+ {BQ2515X_FLAG1, 0x0},
+ {BQ2515X_FLAG2, 0x0},
+ {BQ2515X_FLAG3, 0x0},
+ {BQ2515X_MASK0, 0x0},
+ {BQ2515X_MASK1, 0x0},
+ {BQ2515X_MASK2, 0x71},
+ {BQ2515X_MASK3, 0x0},
+ {BQ2515X_VBAT_CTRL, 0x3C},
+ {BQ2515X_ICHG_CTRL, 0x8},
+ {BQ2515X_PCHRGCTRL, 0x2},
+ {BQ2515X_TERMCTRL, 0x14},
+ {BQ2515X_BUVLO, 0x0},
+ {BQ2515X_CHARGERCTRL0, 0x82},
+ {BQ2515X_CHARGERCTRL1, 0x42},
+ {BQ2515X_ILIMCTRL, 0x1},
+ {BQ2515X_LDOCTRL, 0xB0},
+ {BQ2515X_MRCTRL, 0x2A},
+ {BQ2515X_ICCTRL0, 0x10},
+ {BQ2515X_ICCTRL1, 0x0},
+ {BQ2515X_ICCTRL2, 0x0},
+ {BQ2515X_ADCCTRL0, 0x2},
+ {BQ2515X_ADCCTRL1, 0x40},
+ {BQ2515X_ADC_COMP1_M, 0x23},
+ {BQ2515X_ADC_COMP1_L, 0x20},
+ {BQ2515X_ADC_COMP2_M, 0x38},
+ {BQ2515X_ADC_COMP2_L, 0x90},
+ {BQ2515X_ADC_COMP3_M, 0x0},
+ {BQ2515X_ADC_COMP3_L, 0x0},
+ {BQ2515X_ADC_READ_EN, 0x0},
+ {BQ2515X_TS_FASTCHGCTRL, 0x34},
+ {BQ2515X_TS_COLD, 0x7C},
+ {BQ2515X_TS_COOL, 0x6D},
+ {BQ2515X_TS_WARM, 0x38},
+ {BQ2515X_TS_HOT, 0x27},
+ {BQ2515X_DEVICE_ID, 0x20},
+};
+
+static struct reg_default bq25155_reg_defaults[] = {
+ {BQ2515X_FLAG0, 0x0},
+ {BQ2515X_FLAG1, 0x0},
+ {BQ2515X_FLAG2, 0x0},
+ {BQ2515X_FLAG3, 0x0},
+ {BQ2515X_MASK0, 0x0},
+ {BQ2515X_MASK1, 0x0},
+ {BQ2515X_MASK2, 0x71},
+ {BQ2515X_MASK3, 0x0},
+ {BQ2515X_VBAT_CTRL, 0x3C},
+ {BQ2515X_ICHG_CTRL, 0x8},
+ {BQ2515X_PCHRGCTRL, 0x2},
+ {BQ2515X_TERMCTRL, 0x14},
+ {BQ2515X_BUVLO, 0x0},
+ {BQ2515X_CHARGERCTRL0, 0x82},
+ {BQ2515X_CHARGERCTRL1, 0xC2},
+ {BQ2515X_ILIMCTRL, 0x6},
+ {BQ2515X_LDOCTRL, 0xB0},
+ {BQ2515X_MRCTRL, 0x2A},
+ {BQ2515X_ICCTRL0, 0x10},
+ {BQ2515X_ICCTRL1, 0x0},
+ {BQ2515X_ICCTRL2, 0x40},
+ {BQ2515X_ADCCTRL0, 0x2},
+ {BQ2515X_ADCCTRL1, 0x40},
+ {BQ2515X_ADC_COMP1_M, 0x23},
+ {BQ2515X_ADC_COMP1_L, 0x20},
+ {BQ2515X_ADC_COMP2_M, 0x38},
+ {BQ2515X_ADC_COMP2_L, 0x90},
+ {BQ2515X_ADC_COMP3_M, 0x0},
+ {BQ2515X_ADC_COMP3_L, 0x0},
+ {BQ2515X_ADC_READ_EN, 0x0},
+ {BQ2515X_TS_FASTCHGCTRL, 0x34},
+ {BQ2515X_TS_COLD, 0x7C},
+ {BQ2515X_TS_COOL, 0x6D},
+ {BQ2515X_TS_WARM, 0x38},
+ {BQ2515X_TS_HOT, 0x27},
+ {BQ2515X_DEVICE_ID, 0x35},
+};
+
+static int bq2515x_wake_up(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ int val;
+
+ /* Read the STAT register if we can read it then the device is out
+ * of ship mode. If the register cannot be read then attempt to wake
+ * it up and enable the ADC.
+ */
+ ret = regmap_read(bq2515x->regmap, BQ2515X_STAT0, &val);
+ if (ret)
+ return ret;
+
+ /* Need to toggle LP and bring device out of ship mode. The device
+ * will exit the ship mode when the MR pin is held low for at least
+ * t_WAKE2 as shown in section 8.3.7.1 of the datasheet.
+ */
+ gpiod_set_value_cansleep(bq2515x->powerdown_gpio, 0);
+
+ gpiod_set_value_cansleep(bq2515x->reset_gpio, 0);
+ usleep_range(BQ2515X_TWAKE2_MIN_US, BQ2515X_TWAKE2_MAX_US);
+ gpiod_set_value_cansleep(bq2515x->reset_gpio, 1);
+
+ return regmap_write(bq2515x->regmap, BQ2515X_ADC_READ_EN,
+ (BQ2515X_EN_VBAT_READ | BQ2515X_EN_ICHG_READ));
+}
+
+static int bq2515x_update_ps_status(struct bq2515x_device *bq2515x)
+{
+ bool dc = false;
+ unsigned int val;
+ int ret;
+
+ if (bq2515x->ac_detect_gpio)
+ val = gpiod_get_value_cansleep(bq2515x->ac_detect_gpio);
+ else {
+ ret = regmap_read(bq2515x->regmap, BQ2515X_STAT0, &val);
+ if (ret)
+ return ret;
+ }
+
+ dc = val & BQ2515X_VIN_GOOD;
+
+ ret = bq2515x->mains_online != dc;
+
+ bq2515x->mains_online = dc;
+
+ return ret;
+}
+
+static int bq2515x_disable_watchdog_timers(struct bq2515x_device *bq2515x)
+{
+ int ret;
+
+ ret = regmap_update_bits(bq2515x->regmap, BQ2515X_CHARGERCTRL0,
+ BQ2515X_WATCHDOG_DISABLE, BQ2515X_WATCHDOG_DISABLE);
+ if (ret)
+ return ret;
+
+ return regmap_update_bits(bq2515x->regmap, BQ2515X_ICCTRL2,
+ BQ2515X_HWRESET_14S_WD, 0);
+}
+
+static int bq2515x_get_battery_voltage_now(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ int vbat_msb;
+ int vbat_lsb;
+ uint32_t vbat_measurement;
+
+ if (!bq2515x->mains_online)
+ bq2515x_wake_up(bq2515x);
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ADC_VBAT_M, &vbat_msb);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ADC_VBAT_L, &vbat_lsb);
+ if (ret)
+ return ret;
+
+ vbat_measurement = (vbat_msb << 8) | vbat_lsb;
+
+ return vbat_measurement * (BQ2515X_UV_FACTOR / BQ2515X_DIVISOR) *
+ BQ2515X_VBAT_MULTIPLIER;
+}
+
+static int bq2515x_get_battery_current_now(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ int ichg_msb;
+ int ichg_lsb;
+ uint32_t ichg_measurement;
+ u16 ichg_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
+ unsigned int ichg_reg_code, reg_code;
+ unsigned int icharge_range = 0, pchrgctrl;
+ unsigned int buvlo, vlowv_sel, vlowv = BQ2515X_VLOWV_SEL_1B0_UV;
+
+ if (!bq2515x->mains_online)
+ return -ENODATA;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ADC_ICHG_M, &ichg_msb);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ADC_ICHG_L, &ichg_lsb);
+ if (ret)
+ return ret;
+
+ ichg_measurement = (ichg_msb << 8) | ichg_lsb;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_BUVLO, &buvlo);
+ if (ret)
+ return ret;
+
+ vlowv_sel = buvlo & BQ2515X_VLOWV_SEL;
+
+ if (vlowv_sel)
+ vlowv = BQ2515X_VLOWV_SEL_1B1_UV;
+
+ if (bq2515x_get_battery_voltage_now(bq2515x) < vlowv) {
+ ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL,
+ &pchrgctrl);
+ if (ret)
+ return ret;
+
+ reg_code = pchrgctrl & BQ2515X_PRECHARGE_MASK;
+ } else {
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ICHG_CTRL,
+ &ichg_reg_code);
+ if (ret)
+ return ret;
+
+ reg_code = ichg_reg_code;
+ }
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
+ if (ret)
+ return ret;
+
+ icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
+
+ if (icharge_range)
+ ichg_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
+
+ return reg_code * (ichg_multiplier * ichg_measurement /
+ BQ2515X_ICHG_DIVISOR);
+}
+
+static bool bq2515x_get_charge_disable(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ int ce_pin;
+ int icctrl2;
+ int charger_disable;
+
+ ce_pin = gpiod_get_value_cansleep(bq2515x->ce_gpio);
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ICCTRL2, &icctrl2);
+ if (ret)
+ return ret;
+
+ charger_disable = icctrl2 & BQ2515X_CHARGER_DISABLE;
+
+ if (charger_disable || ce_pin)
+ return true;
+
+ return false;
+}
+
+static int bq2515x_set_charge_disable(struct bq2515x_device *bq2515x, int val)
+{
+ gpiod_set_value_cansleep(bq2515x->ce_gpio, val);
+
+ return regmap_update_bits(bq2515x->regmap, BQ2515X_ICCTRL2,
+ BQ2515X_CHARGER_DISABLE, val);
+}
+
+static int bq2515x_get_const_charge_current(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ u16 ichg_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
+ unsigned int ichg_reg_code;
+ unsigned int pchrgctrl;
+ unsigned int icharge_range;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ICHG_CTRL, &ichg_reg_code);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
+ if (ret)
+ return ret;
+
+ icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
+
+ if (icharge_range)
+ ichg_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
+
+ return ichg_reg_code * ichg_multiplier;
+}
+
+static int bq2515x_set_const_charge_current(struct bq2515x_device *bq2515x,
+ int val)
+{
+ int ret;
+ unsigned int ichg_reg_code;
+ u16 ichg_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
+ unsigned int icharge_range = 0;
+
+ if (val > BQ2515X_ICHG_MAX_UA || val < BQ2515X_ICHG_MIN_UA)
+ return -EINVAL;
+
+ if (val > BQ2515X_ICHG_CURR_STEP_THRESH_UA) {
+ ichg_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
+ icharge_range = BQ2515X_ICHARGE_RANGE;
+ }
+
+ bq2515x_set_charge_disable(bq2515x, 1);
+
+ ret = regmap_update_bits(bq2515x->regmap, BQ2515X_PCHRGCTRL,
+ BQ2515X_ICHARGE_RANGE, icharge_range);
+ if (ret)
+ return ret;
+
+ ichg_reg_code = val / ichg_multiplier;
+
+ ret = regmap_write(bq2515x->regmap, BQ2515X_ICHG_CTRL, ichg_reg_code);
+ if (ret)
+ return ret;
+
+ return bq2515x_set_charge_disable(bq2515x, 0);
+}
+
+static int bq2515x_get_precharge_current(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ unsigned int pchrgctrl;
+ unsigned int icharge_range;
+ u16 precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
+ unsigned int precharge_reg_code;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
+ if (ret)
+ return ret;
+
+ icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
+
+ if (icharge_range)
+ precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
+
+ precharge_reg_code = pchrgctrl & BQ2515X_PRECHARGE_MASK;
+
+ return precharge_reg_code * precharge_multiplier;
+}
+
+static int bq2515x_set_precharge_current(struct bq2515x_device *bq2515x,
+ int val)
+{
+ int ret;
+ unsigned int pchrgctrl;
+ unsigned int icharge_range;
+ unsigned int precharge_reg_code;
+ unsigned int precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
+ unsigned int precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
+ if (ret)
+ return ret;
+
+ icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
+
+ if (icharge_range) {
+ precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
+ precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
+ } else {
+ precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
+ precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
+ }
+ if (val > precharge_max_ua || val < BQ2515X_ICHG_MIN_UA)
+ return -EINVAL;
+
+ precharge_reg_code = val / precharge_multiplier;
+
+ ret = bq2515x_set_charge_disable(bq2515x, 1);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(bq2515x->regmap, BQ2515X_PCHRGCTRL,
+ BQ2515X_PRECHARGE_MASK, precharge_reg_code);
+ if (ret)
+ return ret;
+
+ return bq2515x_set_charge_disable(bq2515x, 0);
+}
+
+static int bq2515x_charging_status(struct bq2515x_device *bq2515x,
+ union power_supply_propval *val)
+{
+ bool status0_no_fault;
+ bool status1_no_fault;
+ bool ce_status;
+ bool charge_done;
+ unsigned int status;
+ int ret;
+
+ if (!bq2515x->mains_online) {
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ return 0;
+ }
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_STAT0, &status);
+ if (ret)
+ return ret;
+
+ /*
+ * The code block below is used to determine if any faults from the
+ * STAT0 register are disbaling charging or if the charge has completed
+ * according to the CHARGE_DONE_STAT bit.
+ */
+ if (((status & BQ2515X_STAT0_MASK) == true) &
+ ((status & BQ2515X_CHRG_DONE) == false)) {
+ status0_no_fault = true;
+ charge_done = false;
+ } else if (status & BQ2515X_CHRG_DONE) {
+ charge_done = true;
+ status0_no_fault = false;
+ } else {
+ status0_no_fault = false;
+ charge_done = false;
+ }
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_STAT1, &status);
+ if (ret)
+ return ret;
+ /*
+ * The code block below is used to determine if any faults from the
+ * STAT1 register are disbaling charging
+ */
+ if ((status & BQ2515X_STAT1_MASK) == false)
+ status1_no_fault = true;
+ else
+ status1_no_fault = false;
+
+ ce_status = (!bq2515x_get_charge_disable(bq2515x));
+
+ /*
+ * If there are no faults and charging is enabled, then status is
+ * charging. Otherwise, if charging is complete, then status is full.
+ * Otherwise, if a fault exists or charging is disabled, then status is
+ * not charging
+ */
+ if (status0_no_fault & status1_no_fault & ce_status)
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else if (charge_done)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else if (!(status0_no_fault & status1_no_fault & ce_status))
+ val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+
+ return 0;
+}
+
+static int bq2515x_get_batt_reg(struct bq2515x_device *bq2515x)
+{
+ int vbat_reg_code;
+ int ret;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_VBAT_CTRL, &vbat_reg_code);
+ if (ret)
+ return ret;
+
+ return BQ2515X_VBAT_BASE_VOLT + vbat_reg_code * BQ2515X_VBAT_STEP_UV;
+}
+
+static int bq2515x_set_batt_reg(struct bq2515x_device *bq2515x, int val)
+{
+ int vbat_reg_code;
+
+ if (val > BQ2515X_VBAT_REG_MAX || val < BQ2515X_VBAT_REG_MIN)
+ return -EINVAL;
+
+ vbat_reg_code = (val - BQ2515X_VBAT_BASE_VOLT) / BQ2515X_VBAT_STEP_UV;
+
+ return regmap_write(bq2515x->regmap, BQ2515X_VBAT_CTRL, vbat_reg_code);
+}
+
+static int bq2515x_get_ilim_lvl(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ int ilimctrl;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_ILIMCTRL, &ilimctrl);
+ if (ret)
+ return ret;
+
+ return bq2515x_ilim_lvl_values[ilimctrl & BQ2515X_ILIM_MASK];
+}
+
+static int bq2515x_set_ilim_lvl(struct bq2515x_device *bq2515x, int val)
+{
+ int i = 0;
+ unsigned int array_size = ARRAY_SIZE(bq2515x_ilim_lvl_values);
+
+ for (i = array_size - 1; i > 0; i--) {
+ if (val >= bq2515x_ilim_lvl_values[i])
+ break;
+ }
+ return regmap_write(bq2515x->regmap, BQ2515X_ILIMCTRL, i);
+}
+
+static int bq2515x_power_supply_property_is_writeable(struct power_supply *psy,
+ enum power_supply_property prop)
+{
+ switch (prop) {
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static int bq2515x_charger_get_health(struct bq2515x_device *bq2515x,
+ union power_supply_propval *val)
+{
+ int health = POWER_SUPPLY_HEALTH_GOOD;
+ int ret;
+ unsigned int stat1;
+ unsigned int flag3;
+
+ if (!bq2515x->mains_online)
+ bq2515x_wake_up(bq2515x);
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_FLAG3, &flag3);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(bq2515x->regmap, BQ2515X_STAT1, &stat1);
+ if (ret)
+ return ret;
+
+ if (stat1 & BQ2515X_HEALTH_MASK) {
+ switch (stat1 & BQ2515X_HEALTH_MASK) {
+ case BQ2515X_TS_HOT_STAT:
+ health = POWER_SUPPLY_HEALTH_HOT;
+ break;
+ case BQ2515X_TS_WARM_STAT:
+ health = POWER_SUPPLY_HEALTH_WARM;
+ break;
+ case BQ2515X_TS_COOL_STAT:
+ health = POWER_SUPPLY_HEALTH_COOL;
+ break;
+ case BQ2515X_TS_COLD_STAT:
+ health = POWER_SUPPLY_HEALTH_COLD;
+ break;
+ default:
+ health = POWER_SUPPLY_HEALTH_UNKNOWN;
+ break;
+ }
+ }
+
+ if (stat1 & BQ2515X_VIN_OVP_FAULT_STAT)
+ health = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+
+ if (flag3 & BQ2515X_SAFETY_TIMER_EXP)
+ health = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
+
+ val->intval = health;
+ return 0;
+}
+
+static int bq2515x_mains_set_property(struct power_supply *psy,
+ enum power_supply_property prop,
+ const union power_supply_propval *val)
+{
+ struct bq2515x_device *bq2515x = power_supply_get_drvdata(psy);
+ int ret;
+
+ switch (prop) {
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ ret = bq2515x_set_ilim_lvl(bq2515x, val->intval);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int bq2515x_battery_set_property(struct power_supply *psy,
+ enum power_supply_property prop,
+ const union power_supply_propval *val)
+{
+ struct bq2515x_device *bq2515x = power_supply_get_drvdata(psy);
+ int ret;
+
+ switch (prop) {
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ ret = bq2515x_set_batt_reg(bq2515x, val->intval);
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ ret = bq2515x_set_const_charge_current(bq2515x, val->intval);
+ break;
+ case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
+ ret = bq2515x_set_precharge_current(bq2515x, val->intval);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int bq2515x_mains_get_property(struct power_supply *psy,
+ enum power_supply_property prop,
+ union power_supply_propval *val)
+{
+ struct bq2515x_device *bq2515x = power_supply_get_drvdata(psy);
+ int ret = 0;
+
+ switch (prop) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = bq2515x->mains_online;
+ break;
+ case POWER_SUPPLY_PROP_HEALTH:
+ ret = bq2515x_charger_get_health(bq2515x, val);
+ if (ret)
+ val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
+ break;
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ ret = bq2515x_get_ilim_lvl(bq2515x);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = bq2515x->model_name;
+ break;
+ case POWER_SUPPLY_PROP_MANUFACTURER:
+ val->strval = BQ2515X_MANUFACTURER;
+ break;
+ case POWER_SUPPLY_PROP_STATUS:
+ ret = bq2515x_charging_status(bq2515x, val);
+ if (ret)
+ return ret;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static int bq2515x_battery_get_property(struct power_supply *psy,
+ enum power_supply_property prop,
+ union power_supply_propval *val)
+{
+ struct bq2515x_device *bq2515x = power_supply_get_drvdata(psy);
+ int ret;
+
+ ret = bq2515x_update_ps_status(bq2515x);
+ if (ret)
+ return ret;
+
+ switch (prop) {
+
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ ret = bq2515x_get_battery_voltage_now(bq2515x);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ ret = bq2515x_get_battery_current_now(bq2515x);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ ret = bq2515x_get_const_charge_current(bq2515x);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
+ ret = bq2515x_get_precharge_current(bq2515x);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+ ret = bq2515x_get_batt_reg(bq2515x);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static enum power_supply_property bq2515x_battery_properties[] = {
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_PRECHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
+};
+
+static enum power_supply_property bq2515x_mains_properties[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
+ POWER_SUPPLY_PROP_MODEL_NAME,
+ POWER_SUPPLY_PROP_MANUFACTURER,
+};
+
+static struct power_supply_desc bq2515x_mains_desc = {
+ .name = "bq2515x-mains",
+ .type = POWER_SUPPLY_TYPE_MAINS,
+ .get_property = bq2515x_mains_get_property,
+ .set_property = bq2515x_mains_set_property,
+ .properties = bq2515x_mains_properties,
+ .num_properties = ARRAY_SIZE(bq2515x_mains_properties),
+ .property_is_writeable = bq2515x_power_supply_property_is_writeable,
+};
+
+static struct power_supply_desc bq2515x_battery_desc = {
+ .name = "bq2515x-battery",
+ .type = POWER_SUPPLY_TYPE_BATTERY,
+ .get_property = bq2515x_battery_get_property,
+ .set_property = bq2515x_battery_set_property,
+ .properties = bq2515x_battery_properties,
+ .num_properties = ARRAY_SIZE(bq2515x_battery_properties),
+ .property_is_writeable = bq2515x_power_supply_property_is_writeable,
+};
+
+static int bq2515x_power_supply_register(struct bq2515x_device *bq2515x,
+ struct device *dev, struct power_supply_config psy_cfg)
+{
+ bq2515x->mains = devm_power_supply_register(bq2515x->dev,
+ &bq2515x_mains_desc,
+ &psy_cfg);
+ if (IS_ERR(bq2515x->mains))
+ return -EINVAL;
+
+ bq2515x->battery = devm_power_supply_register(bq2515x->dev,
+ &bq2515x_battery_desc,
+ &psy_cfg);
+ if (IS_ERR(bq2515x->battery))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int bq2515x_hw_init(struct bq2515x_device *bq2515x)
+{
+ int ret;
+ struct power_supply_battery_info bat_info = { };
+
+ ret = bq2515x_disable_watchdog_timers(bq2515x);
+ if (ret)
+ return ret;
+
+ if (bq2515x->init_data.ilim) {
+ ret = bq2515x_set_ilim_lvl(bq2515x, bq2515x->init_data.ilim);
+ if (ret)
+ return ret;
+ }
+
+ ret = power_supply_get_battery_info(bq2515x->mains, &bat_info);
+ if (ret) {
+ dev_warn(bq2515x->dev, "battery info missing, default values will be applied\n");
+
+ bat_info.constant_charge_current_max_ua =
+ BQ2515X_DEFAULT_ICHG_UA;
+
+ bat_info.constant_charge_voltage_max_uv =
+ BQ2515X_DEFAULT_VBAT_REG_UV;
+
+ bat_info.precharge_current_ua =
+ BQ2515X_DEFAULT_IPRECHARGE_UA;
+ }
+
+ ret = bq2515x_set_const_charge_current(bq2515x,
+ bat_info.constant_charge_current_max_ua);
+ if (ret)
+ return ret;
+
+ ret = bq2515x_set_batt_reg(bq2515x,
+ bat_info.constant_charge_voltage_max_uv);
+ if (ret)
+ return ret;
+
+ return bq2515x_set_precharge_current(bq2515x,
+ bat_info.precharge_current_ua);
+}
+
+static int bq2515x_read_properties(struct bq2515x_device *bq2515x)
+{
+ int ret;
+
+ ret = device_property_read_u32(bq2515x->dev,
+ "input-current-limit-microamp",
+ &bq2515x->init_data.ilim);
+ if (ret)
+ switch (bq2515x->device_id) {
+ case BQ25150:
+ bq2515x->init_data.ilim = BQ25150_DEFAULT_ILIM_UA;
+ break;
+ case BQ25155:
+ bq2515x->init_data.ilim = BQ25155_DEFAULT_ILIM_UA;
+ break;
+ }
+
+ bq2515x->ac_detect_gpio = devm_gpiod_get_optional(bq2515x->dev,
+ "ac-detect", GPIOD_IN);
+ if (IS_ERR(bq2515x->ac_detect_gpio)) {
+ ret = PTR_ERR(bq2515x->ac_detect_gpio);
+ if (ret != -ENODEV) {
+ dev_err(bq2515x->dev, "Failed to get ac detect");
+ return ret;
+ }
+ bq2515x->ac_detect_gpio = NULL;
+ }
+
+ bq2515x->reset_gpio = devm_gpiod_get_optional(bq2515x->dev,
+ "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(bq2515x->reset_gpio)) {
+ ret = PTR_ERR(bq2515x->reset_gpio);
+ if (ret != -ENODEV) {
+ dev_err(bq2515x->dev, "Failed to get reset");
+ return ret;
+ }
+ bq2515x->reset_gpio = NULL;
+ }
+
+ bq2515x->powerdown_gpio = devm_gpiod_get_optional(bq2515x->dev,
+ "powerdown", GPIOD_OUT_LOW);
+ if (IS_ERR(bq2515x->powerdown_gpio)) {
+ ret = PTR_ERR(bq2515x->powerdown_gpio);
+ if (ret != -ENODEV) {
+ dev_err(bq2515x->dev, "Failed to get powerdown");
+ return ret;
+ }
+ bq2515x->powerdown_gpio = NULL;
+ }
+
+ bq2515x->ce_gpio = devm_gpiod_get_optional(bq2515x->dev,
+ "charge-enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(bq2515x->ce_gpio)) {
+ ret = PTR_ERR(bq2515x->ce_gpio);
+ if (ret != -ENODEV) {
+ dev_err(bq2515x->dev, "Failed to get ce");
+ return ret;
+ }
+ bq2515x->ce_gpio = NULL;
+ }
+
+ return 0;
+}
+
+static bool bq2515x_volatile_register(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case BQ2515X_STAT0 ... BQ2515X_FLAG3:
+ case BQ2515X_ADC_VBAT_M ... BQ2515X_ADC_IIN_L:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config bq25150_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = BQ2515X_DEVICE_ID,
+ .reg_defaults = bq25150_reg_defaults,
+ .num_reg_defaults = ARRAY_SIZE(bq25150_reg_defaults),
+ .cache_type = REGCACHE_RBTREE,
+ .volatile_reg = bq2515x_volatile_register,
+};
+
+static const struct regmap_config bq25155_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = BQ2515X_DEVICE_ID,
+ .reg_defaults = bq25155_reg_defaults,
+ .num_reg_defaults = ARRAY_SIZE(bq25155_reg_defaults),
+ .cache_type = REGCACHE_RBTREE,
+ .volatile_reg = bq2515x_volatile_register,
+};
+
+static int bq2515x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = &client->dev;
+ struct bq2515x_device *bq2515x;
+ struct power_supply_config charger_cfg = {};
+ int ret;
+
+ bq2515x = devm_kzalloc(dev, sizeof(*bq2515x), GFP_KERNEL);
+ if (!bq2515x)
+ return -ENOMEM;
+
+ bq2515x->dev = dev;
+
+ strncpy(bq2515x->model_name, id->name, I2C_NAME_SIZE);
+
+ bq2515x->device_id = id->driver_data;
+
+ switch (bq2515x->device_id) {
+ case BQ25150:
+ bq2515x->regmap = devm_regmap_init_i2c(client,
+ &bq25150_regmap_config);
+ break;
+ case BQ25155:
+ bq2515x->regmap = devm_regmap_init_i2c(client,
+ &bq25155_regmap_config);
+ break;
+ }
+
+ if (IS_ERR(bq2515x->regmap)) {
+ dev_err(dev, "failed to allocate register map\n");
+ return PTR_ERR(bq2515x->regmap);
+ }
+
+ i2c_set_clientdata(client, bq2515x);
+
+ charger_cfg.drv_data = bq2515x;
+ charger_cfg.of_node = dev->of_node;
+
+ ret = bq2515x_read_properties(bq2515x);
+ if (ret) {
+ dev_err(dev, "Failed to read device tree properties %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = bq2515x_power_supply_register(bq2515x, dev, charger_cfg);
+ if (ret) {
+ dev_err(dev, "failed to register power supply\n");
+ return ret;
+ }
+
+ ret = bq2515x_hw_init(bq2515x);
+ if (ret) {
+ dev_err(dev, "Cannot initialize the chip\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct i2c_device_id bq2515x_i2c_ids[] = {
+ { "bq25150", BQ25150, },
+ { "bq25155", BQ25155, },
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, bq2515x_i2c_ids);
+
+static const struct of_device_id bq2515x_of_match[] = {
+ { .compatible = "ti,bq25150", },
+ { .compatible = "ti,bq25155", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, bq2515x_of_match);
+
+static struct i2c_driver bq2515x_driver = {
+ .driver = {
+ .name = "bq2515x-charger",
+ .of_match_table = bq2515x_of_match,
+ },
+ .probe = bq2515x_probe,
+ .id_table = bq2515x_i2c_ids,
+};
+module_i2c_driver(bq2515x_driver);
+
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_AUTHOR("Ricardo Rivera-Matos <r-rivera-matos@ti.com>");
+MODULE_DESCRIPTION("BQ2515X charger driver");
+MODULE_LICENSE("GPL v2");
--
2.26.2
^ permalink raw reply related
* [PATCH v12 3/4] dt-bindings: power: Add the bindings for the bq2515x family of chargers.
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
In-Reply-To: <20200528225350.661-1-r-rivera-matos@ti.com>
The BQ2515X family of devices are highly integrated battery management
ICs that integrate the most common functions for wearable devices
namely a charger, an output voltage rail, ADC for battery and system
monitoring, and a push-button controller.
Datasheets:
http://www.ti.com/lit/ds/symlink/bq25150.pdf
http://www.ti.com/lit/ds/symlink/bq25155.pdf
Signed-off-by: Ricardo Rivera-Matos <r-rivera-matos@ti.com>
---
.../bindings/power/supply/bq2515x.yaml | 91 +++++++++++++++++++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/bq2515x.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
new file mode 100644
index 000000000000..19cb336d581e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2020 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/power/supply/bq2515x.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: TI bq2515x 500-mA Linear charger family
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+ - Ricardo Rivera-Matos <r-rivera-matos@ti.com>
+
+description: |
+ The BQ2515x family is a highly integrated battery charge management IC that
+ integrates the most common functions for wearable devices, namely a charger,
+ an output voltage rail, ADC for battery and system monitoring, and
+ push-button controller.
+
+ Specifications about the charger can be found at:
+ http://www.ti.com/lit/ds/symlink/bq25150.pdf
+ http://www.ti.com/lit/ds/symlink/bq25155.pdf
+
+properties:
+ compatible:
+ enum:
+ - ti,bq25150
+ - ti,bq25155
+
+ reg:
+ maxItems: 1
+ description: I2C address of the charger.
+
+ ac-detect-gpios:
+ description: |
+ GPIO used for connecting the bq2515x device PG (AC Detect)
+ pin.
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO used for hardware reset.
+ maxItems: 1
+
+ powerdown-gpios:
+ description: GPIO used for low power mode of IC.
+ maxItems: 1
+
+ charge-enable-gpios:
+ description: GPIO used to turn on and off charging.
+ maxItems: 1
+
+ input-current-limit-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Maximum input current in micro Amps.
+ minimum: 50000
+ maximum: 500000
+
+ monitored-battery:
+ $ref: battery.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bat: battery {
+ compatible = "simple-battery";
+ constant-charge-current-max-microamp = <50000>;
+ precharge-current-microamp = <2500>;
+ constant-charge-voltage-max-microvolt = <4000000>;
+ };
+ #include <dt-bindings/gpio/gpio.h>
+ i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bq25150: charger@6b {
+ compatible = "ti,bq25150";
+ reg = <0x6b>;
+ monitored-battery = <&bat>;
+ input-current-limit-microamp = <100000>;
+
+ ac-detect-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>;
+ charge-enable-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+ };
+ };
--
2.26.2
^ permalink raw reply related
* [PATCH v12 0/4] Add JEITA properties and introduce the bq2515x charger
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
Hello,
This patchset adds additional health properties to the power_supply header.
These additional properties are taken from the JEITA specification. This
patchset also introduces the bq2515x family of charging ICs.
Dan Murphy (2):
power_supply: Add additional health properties to the header
dt-bindings: power: Convert battery.txt to battery.yaml
Ricardo Rivera-Matos (2):
dt-bindings: power: Add the bindings for the bq2515x family of
chargers.
power: supply: bq25150 introduce the bq25150
Documentation/ABI/testing/sysfs-class-power | 2 +-
.../bindings/power/supply/battery.txt | 82 +-
.../bindings/power/supply/battery.yaml | 143 ++
.../bindings/power/supply/bq2515x.yaml | 91 ++
drivers/power/supply/Kconfig | 13 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/bq2515x_charger.c | 1158 +++++++++++++++++
drivers/power/supply/power_supply_sysfs.c | 2 +-
include/linux/power_supply.h | 3 +
9 files changed, 1412 insertions(+), 83 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/supply/battery.yaml
create mode 100644 Documentation/devicetree/bindings/power/supply/bq2515x.yaml
create mode 100644 drivers/power/supply/bq2515x_charger.c
--
2.26.2
^ permalink raw reply
* [PATCH v12 2/4] dt-bindings: power: Convert battery.txt to battery.yaml
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
In-Reply-To: <20200528225350.661-1-r-rivera-matos@ti.com>
From: Dan Murphy <dmurphy@ti.com>
Convert the battery.txt file to yaml and fix up the examples.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../bindings/power/supply/battery.txt | 82 +---------
.../bindings/power/supply/battery.yaml | 143 ++++++++++++++++++
2 files changed, 144 insertions(+), 81 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/supply/battery.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
index 3049cf88bdcf..b9a81621ce59 100644
--- a/Documentation/devicetree/bindings/power/supply/battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/battery.txt
@@ -1,81 +1 @@
-Battery Characteristics
-
-The devicetree battery node provides static battery characteristics.
-In smart batteries, these are typically stored in non-volatile memory
-on a fuel gauge chip. The battery node should be used where there is
-no appropriate non-volatile memory, or it is unprogrammed/incorrect.
-
-Upstream dts files should not include battery nodes, unless the battery
-represented cannot easily be replaced in the system by one of a
-different type. This prevents unpredictable, potentially harmful,
-behavior should a replacement that changes the battery type occur
-without a corresponding update to the dtb.
-
-Required Properties:
- - compatible: Must be "simple-battery"
-
-Optional Properties:
- - voltage-min-design-microvolt: drained battery voltage
- - voltage-max-design-microvolt: fully charged battery voltage
- - energy-full-design-microwatt-hours: battery design energy
- - charge-full-design-microamp-hours: battery design capacity
- - precharge-current-microamp: current for pre-charge phase
- - charge-term-current-microamp: current for charge termination phase
- - constant-charge-current-max-microamp: maximum constant input current
- - constant-charge-voltage-max-microvolt: maximum constant input voltage
- - factory-internal-resistance-micro-ohms: battery factory internal resistance
- - ocv-capacity-table-0: An array providing the open circuit voltage (OCV)
- of the battery and corresponding battery capacity percent, which is used
- to look up battery capacity according to current OCV value. And the open
- circuit voltage unit is microvolt.
- - ocv-capacity-table-1: Same as ocv-capacity-table-0
- ......
- - ocv-capacity-table-n: Same as ocv-capacity-table-0
- - ocv-capacity-celsius: An array containing the temperature in degree Celsius,
- for each of the battery capacity lookup table. The first temperature value
- specifies the OCV table 0, and the second temperature value specifies the
- OCV table 1, and so on.
- - resistance-temp-table: An array providing the temperature in degree Celsius
- and corresponding battery internal resistance percent, which is used to look
- up the resistance percent according to current temperature to get a accurate
- batterty internal resistance in different temperatures.
-
-Battery properties are named, where possible, for the corresponding
-elements in enum power_supply_property, defined in
-https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h
-
-Batteries must be referenced by chargers and/or fuel-gauges
-using a phandle. The phandle's property should be named
-"monitored-battery".
-
-Example:
-
- bat: battery {
- compatible = "simple-battery";
- voltage-min-design-microvolt = <3200000>;
- voltage-max-design-microvolt = <4200000>;
- energy-full-design-microwatt-hours = <5290000>;
- charge-full-design-microamp-hours = <1430000>;
- precharge-current-microamp = <256000>;
- charge-term-current-microamp = <128000>;
- constant-charge-current-max-microamp = <900000>;
- constant-charge-voltage-max-microvolt = <4200000>;
- factory-internal-resistance-micro-ohms = <250000>;
- ocv-capacity-celsius = <(-10) 0 10>;
- ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;
- ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>, ...;
- ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>, ...;
- resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
- };
-
- charger: charger@11 {
- ....
- monitored-battery = <&bat>;
- ...
- };
-
- fuel_gauge: fuel-gauge@22 {
- ....
- monitored-battery = <&bat>;
- ...
- };
+The contents of this file has been moved to battery.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml
new file mode 100644
index 000000000000..f0b544a22219
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/battery.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/battery.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Battery Characteristics
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+description: |
+ The devicetree battery node provides static battery characteristics.
+ In smart batteries, these are typically stored in non-volatile memory
+ on a fuel gauge chip. The battery node should be used where there is
+ no appropriate non-volatile memory, or it is unprogrammed/incorrect.
+
+ Upstream dts files should not include battery nodes, unless the battery
+ represented cannot easily be replaced in the system by one of a
+ different type. This prevents unpredictable, potentially harmful,
+ behavior should a replacement that changes the battery type occur
+ without a corresponding update to the dtb.
+
+ Battery properties are named, where possible, for the corresponding elements
+ in enum power_supply_property, defined in include/linux/power_supply.h
+
+ Batteries must be referenced by chargers and/or fuel-gauges using a phandle.
+ The phandle's property should be named "monitored-battery".
+
+properties:
+ compatible:
+ const: simple-battery
+
+ voltage-min-design-microvolt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: drained battery voltage
+
+ voltage-max-design-microvolt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: fully charged battery voltage
+
+ energy-full-design-microwatt-hours:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: battery design energy
+
+ charge-full-design-microamp-hours:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: battery design capacity
+
+ precharge-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: current for pre-charge phase
+
+ charge-term-current-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: current for charge termination phase
+
+ constant-charge-current-max-microamp:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: maximum constant input current
+
+ constant-charge-voltage-max-microvolt:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: maximum constant input voltage
+
+ factory-internal-resistance-micro-ohms:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: battery factory internal resistance
+
+ ocv-capacity-table-0:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ An array providing the open circuit voltage (OCV)
+ of the battery and corresponding battery capacity percent, which is used
+ to look up battery capacity according to current OCV value. And the open
+ circuit voltage unit is microvolt.
+
+ ocv-capacity-table-1:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: Same as ocv-capacity-table-0
+
+ ocv-capacity-table-n:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: Same as ocv-capacity-table-0
+
+ ocv-capacity-celsius:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array containing the temperature in degree Celsius,
+ for each of the battery capacity lookup table. The first temperature value
+ specifies the OCV table 0, and the second temperature value specifies the
+ OCV table 1, and so on.
+
+ resistance-temp-table:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: |
+ An array providing the temperature in degree Celsius
+ and corresponding battery internal resistance percent, which is used to
+ look up the resistance percent according to current temperature to get an
+ accurate batterty internal resistance in different temperatures.
+
+ monitored-battery:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the battery node being monitored
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ power {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ battery:battery {
+ compatible = "simple-battery";
+ voltage-min-design-microvolt = <3200000>;
+ voltage-max-design-microvolt = <4200000>;
+ energy-full-design-microwatt-hours = <5290000>;
+ charge-full-design-microamp-hours = <1430000>;
+ precharge-current-microamp = <256000>;
+ charge-term-current-microamp = <128000>;
+ constant-charge-current-max-microamp = <900000>;
+ constant-charge-voltage-max-microvolt = <4200000>;
+ factory-internal-resistance-micro-ohms = <250000>;
+ ocv-capacity-celsius = <(-10) 0 10>;
+ ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>;
+ ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>;
+ resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
+ };
+
+ charger:charger@11 {
+ reg = <0x11>;
+ monitored-battery = <&battery>;
+ };
+
+ fuel_gauge:fuel-gauge@22 {
+ reg = <0x22>;
+ monitored-battery = <&battery>;
+ };
+ };
--
2.26.2
^ permalink raw reply related
* [PATCH v12 1/4] power_supply: Add additional health properties to the header
From: Ricardo Rivera-Matos @ 2020-05-28 22:53 UTC (permalink / raw)
To: sre, pali, robh
Cc: afd, r-rivera-matos, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil, Guru Das Srinagesh
In-Reply-To: <20200528225350.661-1-r-rivera-matos@ti.com>
From: Dan Murphy <dmurphy@ti.com>
Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken
from JEITA specification JISC8712:2015
Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
Documentation/ABI/testing/sysfs-class-power | 2 +-
drivers/power/supply/power_supply_sysfs.c | 2 +-
include/linux/power_supply.h | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
index bf3b48f022dc..9f3fd01a9373 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -190,7 +190,7 @@ Description:
Valid values: "Unknown", "Good", "Overheat", "Dead",
"Over voltage", "Unspecified failure", "Cold",
"Watchdog timer expire", "Safety timer expire",
- "Over current"
+ "Over current", "Warm", "Cool", "Hot"
What: /sys/class/power_supply/<supply_name>/precharge_current
Date: June 2017
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index f37ad4eae60b..d0d549611794 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -61,7 +61,7 @@ static const char * const power_supply_charge_type_text[] = {
static const char * const power_supply_health_text[] = {
"Unknown", "Good", "Overheat", "Dead", "Over voltage",
"Unspecified failure", "Cold", "Watchdog timer expire",
- "Safety timer expire", "Over current"
+ "Safety timer expire", "Over current", "Warm", "Cool", "Hot"
};
static const char * const power_supply_technology_text[] = {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index dcd5a71e6c67..8670e90c1d51 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -61,6 +61,9 @@ enum {
POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
POWER_SUPPLY_HEALTH_OVERCURRENT,
+ POWER_SUPPLY_HEALTH_WARM,
+ POWER_SUPPLY_HEALTH_COOL,
+ POWER_SUPPLY_HEALTH_HOT,
};
enum {
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 0/9] DT: Improve validation for Marvell SoCs
From: Rob Herring @ 2020-05-28 22:52 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Alessandro Zummo, Alexandre Belloni, Bartosz Golaszewski,
Daniel Lezcano, Jason Cooper, Linus Walleij, Marc Zyngier,
Thomas Gleixner, Ulf Hansson, devicetree, linux-kernel
In-Reply-To: <20200521091356.2211020-1-lkundrak@v3.sk>
On Thu, May 21, 2020 at 11:13:47AM +0200, Lubomir Rintel wrote:
> Hi,
>
> chained to this message is a second version of remaining patches from the
> first spin of the "DT: Improve validation for Marvell SoCs" [1] patch set.
>
> [1] https://lore.kernel.org/lkml/20200317093922.20785-1-lkundrak@v3.sk/
>
> I've attempted to address the review of the v1, each patch includes a
> detailed change log.
>
> Compared to v1, wherever the license or maintainer information was
> missing, I've filled in GPL-2.0-only and people listed in MAINTAINERS
> file. As I've indicated in v1 cover letter, am not sure whether this is
> the optimal course of action. However I've included the relevant people
> in v1 Cc list and asked for clarifications, but didn't really get any
> feedback to that.
Find someone that would care if the bindings are deleted. I'm fine
if you put yourself. Maybe subsystem maintainers are willing to take
orphans. I really only want my name on common things.
Rob
^ permalink raw reply
* Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge
From: Laurent Pinchart @ 2020-05-28 22:48 UTC (permalink / raw)
To: Rob Herring
Cc: Guido Günther, David Airlie, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20200528194804.GA541078@bogus>
Hi Rob,
On Thu, May 28, 2020 at 01:48:04PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:12:10PM +0200, Guido Günther wrote:
> > The bridge allows to select the input source via a mux controller.
> >
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > .../display/bridge/mux-input-bridge.yaml | 123 ++++++++++++++++++
> > 1 file changed, 123 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> > new file mode 100644
> > index 000000000000..4029cf63ee5c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> > @@ -0,0 +1,123 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: DRM input source selection via multiplexer
>
> DRM is not a hardware thing.
>
> The graph binding is already designed to support muxing. Generally,
> multiple endpoints on an input node is a mux. So either the device with
> the input ports knows how to select the input, or you just need a
> mux-control property for the port to have some other device implement
> the control.
The mux modelled by this binding is used by Guido with the NWL DSI
bridge integrated in the i.MX8. The NWL DSI is an IP core that has a
single input. The i.MX8 has an additional mux in front of the NWL DSI,
to select between the two display controllers in the SoC (eLCDIF and
DCSS). The mux doesn't belong to any of the display controller, it's
really glue logic between the display controllers and the NWL DSI
bridge.
I agree that the bindings shouldn't mention DRM. I would however prefer
not adding a mux-control property and multiple input ports to the NWL
DSI binding, as the mux isn't internal to that IP core (if we go that
route, we would need to add mux control to any IP core that would be
integrated in an SoC with a mux in front). As DT should describe the
hardware, I think describing the standalone mux between the display
controllers and the NWL DSI bridge makex sense.
We already have a DT binding for a video mux
(Documentation/devicetree/bindings/media/video-mux.txt). From a DT point
of view, I see no reason not to reuse that. From a driver point of view
that will be messy, as the driver that binds to the video-mux compatible
string is part of V4L2. That's a driver issue however (and not a new
one, we already have devices that can be part of a video capture
pipeline or a video display pipeline), and should be solved on the
software side, not the DT side. It will however not be easy work, which
explains why, so far, everybody has ignored the issue hoping that
someone else would be hit by it first. We may have reached that day.
> You could do it like you have below. That would be appropriate if
> there's a separate h/w device controlling the muxing. Say for example
> some board level device controlled by i2c.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Suman Anna @ 2020-05-28 22:47 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200528223228.GA785633@bogus>
Hi Rob,
On 5/28/20 5:32 PM, Rob Herring wrote:
> On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
>> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
>> Processor (DSP) subsystems that are comprised of either a TMS320C66x
>> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
>> Add the device tree bindings document for the C66x DSP devices on these
>> SoCs. The added example illustrates the DT nodes for the first C66x DSP
>> device present on the K3 J721E family of SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> v2:
>> - Updated the example to include the root-node to fix the bot errors from v1
>
> Pretty sure that was not why you had errors.
It is because of the default values used for #address-cells and
#size-cells in the example_template and example_start variables used in
the dt-extract-example script. They are 1 by default, so the generated
template ended up with the root-node using 1, and the actual example
using 2 resulting in the mismatch.
When I updated the script to use 2 for both #address-cells and
#size-cells, then the warnings go away. This is the reason, dtbs_check
on my actual dts files goes through fine.
>
>> - Added maxItems to resets, mboxes, memory-region, sram properties
>> - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
>> - Addressed the minor review comments from Mathieu
>> v1: https://patchwork.kernel.org/patch/11458571/
>>
>> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
>> 1 file changed, 190 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>> new file mode 100644
>> index 000000000000..cdf649655838
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>> @@ -0,0 +1,190 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI K3 DSP devices
>> +
>> +maintainers:
>> + - Suman Anna <s-anna@ti.com>
>> +
>> +description: |
>> + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
>> + that are used to offload some of the processor-intensive tasks or algorithms,
>> + for achieving various system level goals.
>> +
>> + These processor sub-systems usually contain additional sub-modules like
>> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
>> + controller, a dedicated local power/sleep controller etc. The DSP processor
>> + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
>> + TMS320C71x CorePac processor.
>> +
>> + Each DSP Core sub-system is represented as a single DT node. Each node has a
>> + number of required or optional properties that enable the OS running on the
>> + host processor (Arm CorePac) to perform the device management of the remote
>> + processor and to communicate with the remote processor.
>> +
>> +properties:
>> + compatible:
>> + const: ti,j721e-c66-dsp
>> + description:
>> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
>
> What else are you going to use? There's only one compatible string. Drop
> description.
Is updated in a subsequent binding update where I added the C71 support.
>
>> +
>> + reg:
>> + description: |
>> + Should contain an entry for each value in 'reg-names'.
>> + Each entry should have the memory region's start address
>> + and the size of the region, the representation matching
>> + the parent node's '#address-cells' and '#size-cells' values.
>
> Don't need generic descriptions. That's every 'reg'.
>
> What you can do is an 'items' list describing what each region is.
OK, I am bit confused here. I have listed the items under the reg-names,
while using just the minItems or maxItems here. What is the convention,
aren't reg and reg-names associative.
>
>> + minItems: 3
>> + maxItems: 3
>> +
>> + reg-names:
>> + description: |
>> + Should contain strings with the names of the specific internal
>> + memory regions, and should be defined in this order
>
> Again, drop.
OK
>
>> + maxItems: 3
>> + items:
>> + - const: l2sram
>> + - const: l1pram
>> + - const: l1dram
>> +
>> + ti,sci:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Should be a phandle to the TI-SCI System Controller node
>> +
>> + ti,sci-dev-id:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + Should contain the TI-SCI device id corresponding to the DSP core.
>> + Please refer to the corresponding System Controller documentation
>> + for valid values for the DSP cores.
>> +
>> + ti,sci-proc-ids:
>> + description: Should contain a single tuple of <proc_id host_id>.
>> + allOf:
>> + - $ref: /schemas/types.yaml#/definitions/uint32-array
>> + - maxItems: 1
>> + items:
>> + items:
>> + - description: TI-SCI processor id for the DSP core device
>> + - description: TI-SCI host id to which processor control
>> + ownership should be transferred to
>
> I assume these properties appear in multiple TI nodes? We don't need
> them defined multiple times. Create a schema for them that you can
> include here.
Only the remoteprocs, so they are limited to this binding and one more
R5F remoteproc binding.
>
>> +
>> + resets:
>> + description: |
>> + Should contain the phandle to the reset controller node
>> + managing the local resets for this device, and a reset
>> + specifier. Please refer to the following reset bindings
>> + for the reset argument specifier,
>> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>
> Drop.
Entire description or just the reference to the reset bindings file?
>
>> + maxItems: 1
>> +
>> + firmware-name:
>> + description: |
>> + Should contain the name of the default firmware image
>> + file located on the firmware search path
>> +
>> + mboxes:
>> + description: |
>> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
>> + communication with the remote processor. This property should match
>> + with the sub-mailbox node used in the firmware image. The specifier
>> + format is as per the bindings,
>> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>
> Drop. What mailbox provider is used is outside the scope of this
> binding.
OK.
>
>> + maxItems: 1
>> +
>> + memory-region:
>> + minItems: 2
>> + maxItems: 8
>> + description: |
>> + phandle to the reserved memory nodes to be associated with the remoteproc
>> + device. There should be at least two reserved memory nodes defined - the
>> + first one would be used for dynamic DMA allocations like vrings and vring
>> + buffers, and the remaining ones used for the firmware image sections. The
>> + reserved memory nodes should be carveout nodes, and should be defined as
>> + per the bindings in
>> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> items:
> - description: dynamic DMA allocations like vrings and vring buffers
> - description: firmware image section ???
> - description: firmware image section ???
Yeah, this is scalable if we will have multiple separate DDR regions. I
had to choose a decent maxItems value, so I chose 8. Wouldn't listing
the individual items override the number of minItems/maxItems?
>
>> +
>> +# Optional properties:
>> +# --------------------
>> +
>> + sram:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + minItems: 1
>> + maxItems: 4
>> + description: |
>> + phandles to one or more reserved on-chip SRAM regions. The regions
>> + should be defined as child nodes of the respective SRAM node, and
>> + should be defined as per the generic bindings in,
>> + Documentation/devicetree/bindings/sram/sram.yaml
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - ti,sci
>> + - ti,sci-dev-id
>> + - ti,sci-proc-ids
>> + - resets
>> + - firmware-name
>> + - mboxes
>> + - memory-region
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + / {
>> + model = "Texas Instruments K3 J721E SoC";
>> + compatible = "ti,j721e";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + /* DSP Carveout reserved memory nodes */
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa6000000 0x00 0x100000>;
>> + no-map;
>> + };
>> +
>> + c66_0_memory_region: c66-memory@a6100000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa6100000 0x00 0xf00000>;
>> + no-map;
>> + };
>> + };
>
> Drop all of this. Outside the scope of this binding. And will likely
> start failing validation as schemas become more complete.
This is a complete example because of the memory-region references below.
>
>> +
>> + cbass_main: bus@100000 {
>
> Drop unused labels.
OK.
regards
Suman
>
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
>> + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
>> + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
>> +
>> + /* J721E C66_0 DSP node */
>> + c66_0: dsp@4d80800000 {
>> + compatible = "ti,j721e-c66-dsp";
>> + reg = <0x4d 0x80800000 0x00 0x00048000>,
>> + <0x4d 0x80e00000 0x00 0x00008000>,
>> + <0x4d 0x80f00000 0x00 0x00008000>;
>> + reg-names = "l2sram", "l1pram", "l1dram";
>> + ti,sci = <&dmsc>;
>> + ti,sci-dev-id = <142>;
>> + ti,sci-proc-ids = <0x03 0xFF>;
>> + resets = <&k3_reset 142 1>;
>> + firmware-name = "j7-c66_0-fw";
>> + memory-region = <&c66_0_dma_memory_region>,
>> + <&c66_0_memory_region>;
>> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
>> + };
>> + };
>> + };
>> --
>> 2.26.0
>>
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Sebastian Reichel @ 2020-05-28 22:44 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki
Cc: linux-pm, devicetree, linux-kernel, kernel
In-Reply-To: <20200513185615.508236-1-sebastian.reichel@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 4042 bytes --]
Hi,
I queued this series to power-supply's for-next branch.
-- Sebastian
On Wed, May 13, 2020 at 08:55:56PM +0200, Sebastian Reichel wrote:
> This patchset improves support for SBS compliant batteries. Due to
> the changes, the battery now exposes 32 power supply properties and
> (un)plugging it generates a backtrace containing the following message
> without the first patch in this series:
>
> ---------------------------
> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> add_uevent_var: too many keys
> ---------------------------
>
> For references this is what an SBS battery status looks like after
> the patch series has been applied:
>
> cat /sys/class/power_supply/sbs-0-000b/uevent
> POWER_SUPPLY_NAME=sbs-0-000b
> POWER_SUPPLY_TYPE=Battery
> POWER_SUPPLY_STATUS=Discharging
> POWER_SUPPLY_CAPACITY_LEVEL=Normal
> POWER_SUPPLY_HEALTH=Good
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_TECHNOLOGY=Li-ion
> POWER_SUPPLY_CYCLE_COUNT=12
> POWER_SUPPLY_VOLTAGE_NOW=11441000
> POWER_SUPPLY_CURRENT_NOW=-26000
> POWER_SUPPLY_CURRENT_AVG=-24000
> POWER_SUPPLY_CAPACITY=76
> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1
> POWER_SUPPLY_TEMP=198
> POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600
> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
> POWER_SUPPLY_SERIAL_NUMBER=0000
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
> POWER_SUPPLY_ENERGY_NOW=31090000
> POWER_SUPPLY_ENERGY_FULL=42450000
> POWER_SUPPLY_ENERGY_FULL_DESIGN=41040000
> POWER_SUPPLY_CHARGE_NOW=2924000
> POWER_SUPPLY_CHARGE_FULL=3898000
> POWER_SUPPLY_CHARGE_FULL_DESIGN=3800000
> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=3000000
> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=12300000
> POWER_SUPPLY_MANUFACTURE_YEAR=2017
> POWER_SUPPLY_MANUFACTURE_MONTH=7
> POWER_SUPPLY_MANUFACTURE_DAY=3
> POWER_SUPPLY_MANUFACTURER=UR18650A
> POWER_SUPPLY_MODEL_NAME=GEHC
>
> -- Sebastian
>
> Jean-Francois Dagenais (1):
> power: supply: sbs-battery: add ability to disable charger broadcasts
>
> Sebastian Reichel (18):
> kobject: increase allowed number of uevent variables
> power: supply: core: add capacity error margin property
> power: supply: core: add manufacture date properties
> power: supply: core: add POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED
> power: supply: sbs-battery: Add TI BQ20Z65 support
> power: supply: sbs-battery: add
> POWER_SUPPLY_PROP_CAPACITY_ERROR_MARGIN support
> power: supply: sbs-battery: simplify read_read_string_data
> power: supply: sbs-battery: add PEC support
> power: supply: sbs-battery: add POWER_SUPPLY_PROP_CURRENT_AVG support
> power: supply: sbs-battery: Improve POWER_SUPPLY_PROP_TECHNOLOGY
> support
> power: supply: sbs-battery: add
> POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT/VOLTAGE_MAX support
> power: supply: sbs-battery: add MANUFACTURE_DATE support
> power: supply: sbs-battery: add
> POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED support
> power: supply: sbs-battery: fix idle battery status
> power: supply: sbs-battery: switch from of_property_* to
> device_property_*
> power: supply: sbs-battery: switch to i2c's probe_new
> power: supply: sbs-battery: constify power-supply property array
> dt-bindings: power: sbs-battery: Convert to yaml
>
> Documentation/ABI/testing/sysfs-class-power | 45 ++-
> .../power/supply/sbs,sbs-battery.yaml | 83 +++++
> .../bindings/power/supply/sbs_sbs-battery.txt | 27 --
> drivers/power/supply/power_supply_sysfs.c | 5 +
> drivers/power/supply/sbs-battery.c | 348 +++++++++++++-----
> include/linux/kobject.h | 2 +-
> include/linux/power_supply.h | 5 +
> 7 files changed, 404 insertions(+), 111 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
> delete mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
>
> --
> 2.26.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: sc16is7xx: Add flag to activate IrDA mode
From: Rob Herring @ 2020-05-28 22:42 UTC (permalink / raw)
To: Daniel Mack
Cc: devicetree, linux-serial, gregkh, jslaby, jringle, m.brock,
pascal.huerst
In-Reply-To: <20200521091152.404404-2-daniel@zonque.org>
On Thu, May 21, 2020 at 11:11:47AM +0200, Daniel Mack wrote:
> From: Pascal Huerst <pascal.huerst@gmail.com>
>
> This series of uart controllers is able to work in IrDA mode.
> This adds a property to the device tree to enable that feature on
> selected ports if needed.
>
> Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
> Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
> index c1091a923a89..4d1f55abe876 100644
> --- a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
> +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
> @@ -21,6 +21,8 @@ Optional properties:
> the second cell is used to specify the GPIO polarity:
> 0 = active high,
> 1 = active low.
> +- linux,irda-mode-ports: An array that lists the indices of the port that
> + should operate in IrDA mode.
Sorry, should have mentioned to drop 'linux,' too. With that,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v11 1/4] power_supply: Add additional health properties to the header
From: Ricardo Rivera-Matos @ 2020-05-28 22:42 UTC (permalink / raw)
To: Andrew F. Davis, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil,
Guru Das Srinagesh
In-Reply-To: <66823f18-dc74-107f-39ae-aade2d3738c0@ti.com>
On 5/28/20 9:16 AM, Andrew F. Davis wrote:
> On 5/28/20 10:05 AM, Ricardo Rivera-Matos wrote:
>> From: Dan Murphy <dmurphy@ti.com>
>>
>> Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
>>
>> HEALTH_WARM, HEALTH_COOL, and HEALTH_HOT properties are taken from the JEITA spec.
>
> Wouldn't hurt to list the specific version of the spec these are from,
> but not super important,
>
> Acked-by: Andrew F. Davis <afd@ti.com>
ACK. This originates from JISC8712:2015, but is more succinctly
explained in "A Guide to the Safe Use of Secondary Lithium Ion Batteries
in Notebook-type Personal Computer"
>
>
>> Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> Documentation/ABI/testing/sysfs-class-power | 2 +-
>> drivers/power/supply/power_supply_sysfs.c | 2 +-
>> include/linux/power_supply.h | 3 +++
>> 3 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
>> index bf3b48f022dc..9f3fd01a9373 100644
>> --- a/Documentation/ABI/testing/sysfs-class-power
>> +++ b/Documentation/ABI/testing/sysfs-class-power
>> @@ -190,7 +190,7 @@ Description:
>> Valid values: "Unknown", "Good", "Overheat", "Dead",
>> "Over voltage", "Unspecified failure", "Cold",
>> "Watchdog timer expire", "Safety timer expire",
>> - "Over current"
>> + "Over current", "Warm", "Cool", "Hot"
>>
>> What: /sys/class/power_supply/<supply_name>/precharge_current
>> Date: June 2017
>> diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
>> index f37ad4eae60b..d0d549611794 100644
>> --- a/drivers/power/supply/power_supply_sysfs.c
>> +++ b/drivers/power/supply/power_supply_sysfs.c
>> @@ -61,7 +61,7 @@ static const char * const power_supply_charge_type_text[] = {
>> static const char * const power_supply_health_text[] = {
>> "Unknown", "Good", "Overheat", "Dead", "Over voltage",
>> "Unspecified failure", "Cold", "Watchdog timer expire",
>> - "Safety timer expire", "Over current"
>> + "Safety timer expire", "Over current", "Warm", "Cool", "Hot"
>> };
>>
>> static const char * const power_supply_technology_text[] = {
>> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
>> index dcd5a71e6c67..8670e90c1d51 100644
>> --- a/include/linux/power_supply.h
>> +++ b/include/linux/power_supply.h
>> @@ -61,6 +61,9 @@ enum {
>> POWER_SUPPLY_HEALTH_WATCHDOG_TIMER_EXPIRE,
>> POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE,
>> POWER_SUPPLY_HEALTH_OVERCURRENT,
>> + POWER_SUPPLY_HEALTH_WARM,
>> + POWER_SUPPLY_HEALTH_COOL,
>> + POWER_SUPPLY_HEALTH_HOT,
>> };
>>
>> enum {
>>
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: simple-card: care missing address #address-cells
From: Rob Herring @ 2020-05-28 22:39 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Liam Girdwood, Mark Brown, Mark Rutland, devicetree, alsa-devel,
linux-kernel
In-Reply-To: <87pnay3ptb.wl-kuninori.morimoto.gx@renesas.com>
On Thu, May 21, 2020 at 12:54:56PM +0900, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current simple-card will get below error,
> because it doesn't care about #address-cells at some part.
>
> DTC Documentation/devicetree/bindings/sound/simple-card.example.dt.yaml
> Documentation/devicetree/bindings/sound/simple-card.example.dts:171.46-173.15: \
> Warning (unit_address_vs_reg): /example-4/sound/simple-audio-card,cpu@0: \
> node has a unit name, but no reg or ranges property
> Documentation/devicetree/bindings/sound/simple-card.example.dts:175.37-177.15: \
> Warning (unit_address_vs_reg): /example-4/sound/simple-audio-card,cpu@1: \
> node has a unit name, but no reg or ranges property
> ...
>
> This patch fixup this issue.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> .../bindings/sound/simple-card.yaml | 25 ++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml
> index cb2bb5fac0e1..6c4c2c6d6d3c 100644
> --- a/Documentation/devicetree/bindings/sound/simple-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml
> @@ -208,6 +208,11 @@ patternProperties:
> reg:
> maxItems: 1
>
> + "#address-cells":
> + const: 1
> + "#size-cells":
> + const: 0
> +
> # common properties
> frame-master:
> $ref: "#/definitions/frame-master"
> @@ -288,7 +293,6 @@ examples:
>
> #address-cells = <1>;
> #size-cells = <0>;
> -
> simple-audio-card,dai-link@0 { /* I2S - HDMI */
> reg = <0>;
> format = "i2s";
> @@ -392,11 +396,15 @@ examples:
> simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback",
> "ak4642 Playback", "DAI1 Playback";
>
> + #address-cells = <1>;
> + #size-cells = <0>;
> dpcmcpu: simple-audio-card,cpu@0 {
> + reg = <0>;
You need to add 'reg' to the schema. This isn't flagged because
'additionalProperties: false' is missing there too.
> sound-dai = <&rcar_sound 0>;
> };
>
> simple-audio-card,cpu@1 {
> + reg = <1>;
> sound-dai = <&rcar_sound 1>;
> };
>
> @@ -427,7 +435,12 @@ examples:
> "pcm3168a Playback", "DAI3 Playback",
> "pcm3168a Playback", "DAI4 Playback";
>
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> simple-audio-card,dai-link@0 {
> + reg = <0>;
> +
> format = "left_j";
> bitclock-master = <&sndcpu0>;
> frame-master = <&sndcpu0>;
> @@ -441,22 +454,30 @@ examples:
> };
>
> simple-audio-card,dai-link@1 {
> + reg = <1>;
> +
> format = "i2s";
> bitclock-master = <&sndcpu1>;
> frame-master = <&sndcpu1>;
>
> convert-channels = <8>; /* TDM Split */
>
> + #address-cells = <1>;
> + #size-cells = <0>;
> sndcpu1: cpu@0 {
> + reg = <0>;
> sound-dai = <&rcar_sound 1>;
> };
> cpu@1 {
> + reg = <1>;
> sound-dai = <&rcar_sound 2>;
> };
> cpu@2 {
> + reg = <2>;
> sound-dai = <&rcar_sound 3>;
> };
> cpu@3 {
> + reg = <3>;
> sound-dai = <&rcar_sound 4>;
> };
> codec {
> @@ -468,6 +489,8 @@ examples:
> };
>
> simple-audio-card,dai-link@2 {
> + reg = <2>;
> +
> format = "i2s";
> bitclock-master = <&sndcpu2>;
> frame-master = <&sndcpu2>;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy-qcom-usb-hs-phy: Add qcom,enable-vbus-pullup
From: Rob Herring @ 2020-05-28 22:34 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: devicetree, vkoul, bjorn.andersson, linux-kernel, linux-arm-msm,
Stephen Boyd, agross, robh+dt, kishon
In-Reply-To: <20200521005031.747162-2-bryan.odonoghue@linaro.org>
On Thu, 21 May 2020 01:50:30 +0100, Bryan O'Donoghue wrote:
> This patch adds a dt-binding for qcom,enable-vbus-pullup. The binding
> qcom,enable-vbus-pullup tells the HS USB PHY driver whether it should set
> and unset the internal VBUS pullup bits when starting/stopping the USB PHY.
>
> Setting the pullup bits is something you want to do if you have not routed
> VBUS to a GPIO on the SoC and thus cannot use extcon with the current
> switching logic in the PHY.
>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
From: Rob Herring @ 2020-05-28 22:32 UTC (permalink / raw)
To: Suman Anna
Cc: Bjorn Andersson, Mathieu Poirier, Lokesh Vutla, linux-remoteproc,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20200521001006.2725-3-s-anna@ti.com>
On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
> Some Texas Instruments K3 family of SoCs have one of more Digital Signal
> Processor (DSP) subsystems that are comprised of either a TMS320C66x
> CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
> Add the device tree bindings document for the C66x DSP devices on these
> SoCs. The added example illustrates the DT nodes for the first C66x DSP
> device present on the K3 J721E family of SoCs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v2:
> - Updated the example to include the root-node to fix the bot errors from v1
Pretty sure that was not why you had errors.
> - Added maxItems to resets, mboxes, memory-region, sram properties
> - Changed the ti,sci-proc-ids $ref to uint-array from uint-matrix
> - Addressed the minor review comments from Mathieu
> v1: https://patchwork.kernel.org/patch/11458571/
>
> .../bindings/remoteproc/ti,k3-dsp-rproc.yaml | 190 ++++++++++++++++++
> 1 file changed, 190 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> new file mode 100644
> index 000000000000..cdf649655838
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
> @@ -0,0 +1,190 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI K3 DSP devices
> +
> +maintainers:
> + - Suman Anna <s-anna@ti.com>
> +
> +description: |
> + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems
> + that are used to offload some of the processor-intensive tasks or algorithms,
> + for achieving various system level goals.
> +
> + These processor sub-systems usually contain additional sub-modules like
> + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory
> + controller, a dedicated local power/sleep controller etc. The DSP processor
> + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a
> + TMS320C71x CorePac processor.
> +
> + Each DSP Core sub-system is represented as a single DT node. Each node has a
> + number of required or optional properties that enable the OS running on the
> + host processor (Arm CorePac) to perform the device management of the remote
> + processor and to communicate with the remote processor.
> +
> +properties:
> + compatible:
> + const: ti,j721e-c66-dsp
> + description:
> + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs
What else are you going to use? There's only one compatible string. Drop
description.
> +
> + reg:
> + description: |
> + Should contain an entry for each value in 'reg-names'.
> + Each entry should have the memory region's start address
> + and the size of the region, the representation matching
> + the parent node's '#address-cells' and '#size-cells' values.
Don't need generic descriptions. That's every 'reg'.
What you can do is an 'items' list describing what each region is.
> + minItems: 3
> + maxItems: 3
> +
> + reg-names:
> + description: |
> + Should contain strings with the names of the specific internal
> + memory regions, and should be defined in this order
Again, drop.
> + maxItems: 3
> + items:
> + - const: l2sram
> + - const: l1pram
> + - const: l1dram
> +
> + ti,sci:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Should be a phandle to the TI-SCI System Controller node
> +
> + ti,sci-dev-id:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + Should contain the TI-SCI device id corresponding to the DSP core.
> + Please refer to the corresponding System Controller documentation
> + for valid values for the DSP cores.
> +
> + ti,sci-proc-ids:
> + description: Should contain a single tuple of <proc_id host_id>.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - maxItems: 1
> + items:
> + items:
> + - description: TI-SCI processor id for the DSP core device
> + - description: TI-SCI host id to which processor control
> + ownership should be transferred to
I assume these properties appear in multiple TI nodes? We don't need
them defined multiple times. Create a schema for them that you can
include here.
> +
> + resets:
> + description: |
> + Should contain the phandle to the reset controller node
> + managing the local resets for this device, and a reset
> + specifier. Please refer to the following reset bindings
> + for the reset argument specifier,
> + Documentation/devicetree/bindings/reset/ti,sci-reset.txt
Drop.
> + maxItems: 1
> +
> + firmware-name:
> + description: |
> + Should contain the name of the default firmware image
> + file located on the firmware search path
> +
> + mboxes:
> + description: |
> + OMAP Mailbox specifier denoting the sub-mailbox, to be used for
> + communication with the remote processor. This property should match
> + with the sub-mailbox node used in the firmware image. The specifier
> + format is as per the bindings,
> + Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
Drop. What mailbox provider is used is outside the scope of this
binding.
> + maxItems: 1
> +
> + memory-region:
> + minItems: 2
> + maxItems: 8
> + description: |
> + phandle to the reserved memory nodes to be associated with the remoteproc
> + device. There should be at least two reserved memory nodes defined - the
> + first one would be used for dynamic DMA allocations like vrings and vring
> + buffers, and the remaining ones used for the firmware image sections. The
> + reserved memory nodes should be carveout nodes, and should be defined as
> + per the bindings in
> + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
items:
- description: dynamic DMA allocations like vrings and vring buffers
- description: firmware image section ???
- description: firmware image section ???
> +
> +# Optional properties:
> +# --------------------
> +
> + sram:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + minItems: 1
> + maxItems: 4
> + description: |
> + phandles to one or more reserved on-chip SRAM regions. The regions
> + should be defined as child nodes of the respective SRAM node, and
> + should be defined as per the generic bindings in,
> + Documentation/devicetree/bindings/sram/sram.yaml
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - ti,sci
> + - ti,sci-dev-id
> + - ti,sci-proc-ids
> + - resets
> + - firmware-name
> + - mboxes
> + - memory-region
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + / {
> + model = "Texas Instruments K3 J721E SoC";
> + compatible = "ti,j721e";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + /* DSP Carveout reserved memory nodes */
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + c66_0_dma_memory_region: c66-dma-memory@a6000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa6000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + c66_0_memory_region: c66-memory@a6100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa6100000 0x00 0xf00000>;
> + no-map;
> + };
> + };
Drop all of this. Outside the scope of this binding. And will likely
start failing validation as schemas become more complete.
> +
> + cbass_main: bus@100000 {
Drop unused labels.
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */
> + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */
> + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */
> +
> + /* J721E C66_0 DSP node */
> + c66_0: dsp@4d80800000 {
> + compatible = "ti,j721e-c66-dsp";
> + reg = <0x4d 0x80800000 0x00 0x00048000>,
> + <0x4d 0x80e00000 0x00 0x00008000>,
> + <0x4d 0x80f00000 0x00 0x00008000>;
> + reg-names = "l2sram", "l1pram", "l1dram";
> + ti,sci = <&dmsc>;
> + ti,sci-dev-id = <142>;
> + ti,sci-proc-ids = <0x03 0xFF>;
> + resets = <&k3_reset 142 1>;
> + firmware-name = "j7-c66_0-fw";
> + memory-region = <&c66_0_dma_memory_region>,
> + <&c66_0_memory_region>;
> + mboxes = <&mailbox0_cluster3 &mbox_c66_0>;
> + };
> + };
> + };
> --
> 2.26.0
>
^ permalink raw reply
* [PATCH v4 00/11] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar
Cc: Serge Semin, Serge Semin, Alexey Malahov, Maxim Kaurkin,
Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
Alexey Kolotnikov, Thomas Bogendoerfer, Arnd Bergmann,
Andy Shevchenko, Rob Herring, linux-mips, dmaengine, devicetree,
linux-kernel
Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
with currently implemented in the kernel DW DMAC driver, but there are some
peculiarities which must be taken into account in order to have the device
fully supported.
First of all traditionally we replaced the legacy plain text-based dt-binding
file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
channels, which alas have different max burst length configuration.
In particular first two channels may burst up to 128 bits (16 bytes) at a time
while the rest of them just up to 32 bits. We must make sure that the DMA
subsystem doesn't set values exceeding these limitations otherwise the
controller will hang up. In third currently we discovered the problem in using
the DW APB SPI driver together with DW DMAC. The problem happens if there is no
natively implemented multi-block LLP transfers support and the SPI-transfer
length exceeds the max lock size. In this case due to asynchronous handling of
Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
the DMAC to asynchronously execute the transfers we'd have to at least warn
the user of the possible errors. In forth it's worth to set the DMA device max
segment size with max block size config specific to the DW DMA controller. It
shall help the DMA clients to create size-optimized SG-list items for the
controller. This in turn will cause less dw_desc allocations, less LLP
reinitializations, better DMA device performance.
Finally there is a bug in the algorithm of the nollp flag detection.
In particular even if DW DMAC parameters state the multi-block transfers
support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
by the driver true multi-block LLP functionality unusable. This happens cause'
if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
contiguous multi-block transfers will be only supported. We must take the
flag into account when detecting the LLP support otherwise the driver just
won't work correctly.
This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the properties. So do do with the
constraints in the DT binding.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property in the DT binding file.
- Discard default settings defined out of property enum constraint.
- Set default max-burst-len to 256 TR-WIDTH words in the DT binding.
- Discard noLLP and block_size accessors.
- Set max segment size of the DMA device structure with the DW DMA block size
config.
- Print warning if noLLP flag is set.
- Discard max burst length accessor.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator in noLLP flag setting.
Link: https://lore.kernel.org/dmaengine/20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru/
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
- Add more details into the property description about what limitations
snps,max-burst-len defines.
- Move commit fb7e3bbfc830 ("dmaengine: dw: Take HC_LLP flag into account for
noLLP auto-config") to the head of the series.
- Add a new patch "dmaengine: Introduce min burst length capability" as a
result of the discussion with Vinod and Andy regarding the burst length
capability.
- Add a new patch "dmaengine: Introduce max SG list entries capability"
suggested by Andy.
- Add a new patch "dmaengine: Introduce DMA-device device_caps callback" as
a result of the discussion with Vinud and Andy in the framework of DW DMA
burst and LLP capabilities.
- Add a new patch "dmaengine: dw: Add dummy device_caps callback" as a
preparation commit before setting the max_burst and max_sg_nents
DW DMA capabilities.
- Override the slave channel max_burst capability instead of calculating
the minimum value of max burst lengths and setting the DMA-device
generic capability.
- Add a new patch "dmaengine: dw: Initialize max_sg_nents with nollp flag".
This is required to fix the DW APB SSI issue of the Tx and Rx DMA
channels de-synchronization.
Link: https://lore.kernel.org/dmaengine/20200526225022.20405-1-Sergey.Semin@baikalelectronics.ru/
Changelog v4:
- Use explicit if-else statement when assigning the max_sg_nents field.
- Clamp the dst and src burst lengths in the generic dwc_config() method
instead of doing that in the encode_maxburst() callback.
- Define max_burst with u32 type in struct dw_dma_platform_data.
- Perform of_property_read_u32_array() with the platform data
max_burst member passed directly.
- Add a new patch "dmaengine: dw: Initialize min_burst capability",
which initializes the min_burst capability with 1.
- Fix of->if typo. It should be definitely "of" in the max_sg_list
capability description.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: dmaengine@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (11):
dt-bindings: dma: dw: Convert DW DMAC to DT binding
dt-bindings: dma: dw: Add max burst transaction length property
dmaengine: Introduce min burst length capability
dmaengine: Introduce max SG list entries capability
dmaengine: Introduce DMA-device device_caps callback
dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
dmaengine: dw: Set DMA device max segment size parameter
dmaengine: dw: Add dummy device_caps callback
dmaengine: dw: Initialize min_burst capability
dmaengine: dw: Introduce max burst length hw config
dmaengine: dw: Initialize max_sg_nents capability
.../bindings/dma/snps,dma-spear1340.yaml | 176 ++++++++++++++++++
.../devicetree/bindings/dma/snps-dma.txt | 69 -------
drivers/dma/dmaengine.c | 5 +
drivers/dma/dw/core.c | 47 ++++-
drivers/dma/dw/of.c | 5 +
drivers/dma/dw/regs.h | 3 +
include/linux/dmaengine.h | 14 ++
include/linux/platform_data/dma-dw.h | 4 +
8 files changed, 253 insertions(+), 70 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
--
2.26.2
^ permalink raw reply
* [PATCH v4 09/11] dmaengine: dw: Initialize min_burst capability
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
According to the DW APB DMAC data book the minimum burst transaction
length is 1 and it's true for any version of the controller since
isn't parametrised in the coreAssembler so can't be changed at the
IP-core synthesis stage. Let's initialise the min_burst member of the
DMA controller descriptor so the DMA clients could use it to properly
optimize the DMA requests.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v4:
- This is a new patch suggested by Andy.
---
drivers/dma/dw/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index ceded21537e2..a8cebb1dbb68 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1229,6 +1229,7 @@ int do_dma_probe(struct dw_dma_chip *chip)
dw->dma.device_issue_pending = dwc_issue_pending;
/* DMA capabilities */
+ dw->dma.min_burst = 1;
dw->dma.src_addr_widths = DW_DMA_BUSWIDTHS;
dw->dma.dst_addr_widths = DW_DMA_BUSWIDTHS;
dw->dma.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
--
2.26.2
^ permalink raw reply related
* [PATCH v4 04/11] dmaengine: Introduce max SG list entries capability
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Some devices may lack the support of the hardware accelerated SG list
entries automatic walking through and execution. In this case a burden of
the SG list traversal and DMA engine re-initialization lies on the
DMA engine driver (normally implemented by using a DMA transfer completion
IRQ to recharge the DMA device with a next SG list entry). But such
solution may not be suitable for some DMA consumers. In particular SPI
devices need both Tx and Rx DMA channels work synchronously in order
to avoid the Rx FIFO overflow. In case if Rx DMA channel is paused for
some time while the Tx DMA channel works implicitly pulling data into the
Rx FIFO, the later will be eventually overflown, which will cause the data
loss. So if SG list entries aren't automatically fetched by the DMA
engine, but are one-by-one manually selected for execution in the
ISRs/deferred work/etc., such problem will eventually happen due to the
non-deterministic latencies of the service execution.
In order to let the DMA consumer know about the DMA device capabilities
regarding the hardware accelerated SG list traversal we introduce the
max_sg_list capability. It is supposed to be initialized by the DMA engine
driver with 0 if there is no limitation for the number of SG entries
atomically executed and with non-zero value if there is such constraints,
so the upper limit is determined by the number set to the property.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinud and
Andy in the framework of DW DMA burst and LLP capabilities.
Changelog v4:
- Fix of->if typo. It should be definitely of.
---
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index b332ffe52780..ad56ad58932c 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -592,6 +592,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->directions = device->directions;
caps->min_burst = device->min_burst;
caps->max_burst = device->max_burst;
+ caps->max_sg_nents = device->max_sg_nents;
caps->residue_granularity = device->residue_granularity;
caps->descriptor_reuse = device->descriptor_reuse;
caps->cmd_pause = !!device->device_pause;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0c7403b27133..a7e4d8dfdd19 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -467,6 +467,9 @@ enum dma_residue_granularity {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number of entries.
* @cmd_pause: true, if pause is supported (i.e. for reading residue or
* for resume later)
* @cmd_resume: true, if resume is supported
@@ -481,6 +484,7 @@ struct dma_slave_caps {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool cmd_pause;
bool cmd_resume;
bool cmd_terminate;
@@ -773,6 +777,9 @@ struct dma_filter {
* should be checked by controller as well
* @min_burst: min burst capability per-transfer
* @max_burst: max burst capability per-transfer
+ * @max_sg_nents: max number of SG list entries executed in a single atomic
+ * DMA tansaction with no intermediate IRQ for reinitialization. Zero
+ * value means unlimited number of entries.
* @residue_granularity: granularity of the transfer residue reported
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
@@ -844,6 +851,7 @@ struct dma_device {
u32 directions;
u32 min_burst;
u32 max_burst;
+ u32 max_sg_nents;
bool descriptor_reuse;
enum dma_residue_granularity residue_granularity;
--
2.26.2
^ permalink raw reply related
* [PATCH v4 06/11] dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Full multi-block transfers functionality is enabled in DW DMA
controller only if CHx_MULTI_BLK_EN is set. But LLP-based transfers
can be executed only if hardcode channel x LLP register feature isn't
enabled, which can be switched on at the IP core synthesis for
optimization. If it's enabled then the LLP register is hardcoded to
zero, so the blocks chaining based on the LLPs is unsupported.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Add comment about why hardware accelerated LLP list support depends
on both MBLK_EN and HC_LLP configs setting.
- Use explicit bits state comparison operator.
Changelog v3:
- Move the patch to the head of the series.
---
drivers/dma/dw/core.c | 11 ++++++++++-
drivers/dma/dw/regs.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 21cb2a58dbd2..33e99d95b3d3 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1178,8 +1178,17 @@ int do_dma_probe(struct dw_dma_chip *chip)
*/
dwc->block_size =
(4 << ((pdata->block_size >> 4 * i) & 0xf)) - 1;
+
+ /*
+ * According to the DW DMA databook the true scatter-
+ * gether LLPs aren't available if either multi-block
+ * config is disabled (CHx_MULTI_BLK_EN == 0) or the
+ * LLP register is hard-coded to zeros
+ * (CHx_HC_LLP == 1).
+ */
dwc->nollp =
- (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
+ (dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0 ||
+ (dwc_params >> DWC_PARAMS_HC_LLP & 0x1) == 1;
} else {
dwc->block_size = pdata->block_size;
dwc->nollp = !pdata->multi_block[i];
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 3fce66ecee7a..1ab840b06e79 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -125,6 +125,7 @@ struct dw_dma_regs {
/* Bitfields in DWC_PARAMS */
#define DWC_PARAMS_MBLK_EN 11 /* multi block transfer */
+#define DWC_PARAMS_HC_LLP 13 /* set LLP register to zero */
/* bursts size */
enum dw_dma_msize {
--
2.26.2
^ permalink raw reply related
* [PATCH v4 05/11] dmaengine: Introduce DMA-device device_caps callback
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Andy Shevchenko, Rob Herring, linux-mips,
devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
There are DMA devices (like ours version of Synopsys DW DMAC) which have
DMA capabilities non-uniformly redistributed amongst the device channels.
In order to provide a way of exposing the channel-specific parameters to
the DMA engine consumers, we introduce a new DMA-device callback. In case
if provided it gets called from the dma_get_slave_caps() method and is
able to override the generic DMA-device capabilities.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- This is a new patch created as a result of the discussion with Vinod and
Andy in the framework of DW DMA burst and LLP capabilities.
---
drivers/dma/dmaengine.c | 3 +++
include/linux/dmaengine.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ad56ad58932c..edbb11d56cde 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -599,6 +599,9 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
caps->cmd_resume = !!device->device_resume;
caps->cmd_terminate = !!device->device_terminate_all;
+ if (device->device_caps)
+ device->device_caps(chan, caps);
+
return 0;
}
EXPORT_SYMBOL_GPL(dma_get_slave_caps);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index a7e4d8dfdd19..b303e59929e5 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -899,6 +899,8 @@ struct dma_device {
struct dma_chan *chan, dma_addr_t dst, u64 data,
unsigned long flags);
+ void (*device_caps)(struct dma_chan *chan,
+ struct dma_slave_caps *caps);
int (*device_config)(struct dma_chan *chan,
struct dma_slave_config *config);
int (*device_pause)(struct dma_chan *chan);
--
2.26.2
^ permalink raw reply related
* [PATCH v4 07/11] dmaengine: dw: Set DMA device max segment size parameter
From: Serge Semin @ 2020-05-28 22:23 UTC (permalink / raw)
To: Vinod Koul, Viresh Kumar, Andy Shevchenko, Dan Williams
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree, dmaengine,
linux-kernel
In-Reply-To: <20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru>
Maximum block size DW DMAC configuration corresponds to the max segment
size DMA parameter in the DMA core subsystem notation. Lets set it with a
value specific to the probed DW DMA controller. It shall help the DMA
clients to create size-optimized SG-list items for the controller. This in
turn will cause less dw_desc allocations, less LLP reinitializations,
better DMA device performance.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- This is a new patch created in place of the dropped one:
"dmaengine: dw: Add LLP and block size config accessors".
Changelog v3:
- Use the block_size found for the very first channel instead of looking for
the maximum of maximum block sizes.
- Don't define device-specific device_dma_parameters object, since it has
already been defined by the platform device core.
---
drivers/dma/dw/core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index 33e99d95b3d3..fb95920c429e 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1229,6 +1229,13 @@ int do_dma_probe(struct dw_dma_chip *chip)
BIT(DMA_MEM_TO_MEM);
dw->dma.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+ /*
+ * For now there is no hardware with non uniform maximum block size
+ * across all of the device channels, so we set the maximum segment
+ * size as the block size found for the very first channel.
+ */
+ dma_set_max_seg_size(dw->dma.dev, dw->chan[0].block_size);
+
err = dma_async_device_register(&dw->dma);
if (err)
goto err_dma_register;
--
2.26.2
^ permalink raw reply related
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